DEV Community: Terry Quispe Paniagua

🛡️ AWS IAM Access Analyzer — Parte 2/4

Terry Quispe Paniagua — Fri, 03 Jul 2026 00:46:28 +0000

External Access: el analizador sin costo adicional que deberías tener activo en todas tus cuentas

En AWS, el acceso no depende de una sola policy. Entre identity policies, resource-based policies, trust policies, SCPs, RCPs, boundaries y configuraciones por servicio, saber si un recurso está expuesto puede volverse confuso rápido.

Antes de entrar al análisis de permisos efectivos internos, conviene empezar por el analyzer más básico y más urgente: External Access Analyzer.

Este post es sobre ese primer baseline: detectar recursos que están accesibles desde fuera de tu zona de confianza. No tiene costo adicional por recurso analizado, se habilita por región y cubre automáticamente los recursos soportados en esa región. Su objetivo es detectar algo muy concreto: recursos accesibles desde fuera de la zona de confianza que defines.

¿Qué hace exactamente el External Access Analyzer?

El External Access Analyzer genera findings cuando detecta que un recurso dentro de tu zona de confianza puede ser accedido por un principal externo. Esa zona de confianza puede ser una cuenta individual o toda una AWS Organization.

Lo que evalúa depende del tipo de recurso soportado. En términos prácticos, revisa políticas o configuraciones como:

bucket policies y ACLs de S3
trust policies de roles IAM
key policies y grants de KMS
queue policies de SQS
topic policies de SNS
function policies de Lambda
resource policies de Secrets Manager, ECR, EFS, DynamoDB, entre otros

Si la policy de un recurso tiene un Principal: "*", una cuenta externa, un usuario federado externo o una condición que permite acceso fuera de tu zona de confianza, el analizador puede generar un finding.

Qué tipos de acceso externo detecta

Tipo de acceso	Ejemplo	Finding generado
Acceso público	`"Principal": "*"` sin condición restrictiva	✅ Sí
Acceso cross-account a otra cuenta de la misma org	ARN de cuenta en la misma organización	Solo si la zona de trust es la cuenta individual
Acceso cross-account fuera de la org	ARN de cuenta externa	✅ Sí
Acceso restringido por organización	`Condition: { "aws:PrincipalOrgID": "o-xxxx" }`	Normalmente no, si la zona de trust es esa organización
Acceso mediante federación externa	SAML/OIDC con IdP externo o federado	✅ Sí, si queda fuera de la zona de confianza

La diferencia entre configurar la zona de confianza como cuenta versus organización importa bastante.

Si la defines como organización, los accesos cross-account dentro de la misma AWS Organization no generan findings porque se consideran internos a la zona de confianza. Si la defines como cuenta, cualquier acceso cross-account, incluso desde una cuenta hermana de la misma organización, puede generar finding.

Por qué este analizador importa antes que cualquier otro

El Internal Access Analyzer tiene costo porque se cobra por recurso monitoreado. El Unused Access Analyzer también tiene costo porque se cobra por rol o usuario analizado. External Access Analyzer, en cambio, no tiene costo adicional y cubre automáticamente los recursos soportados de la región donde se habilita.

El problema que detecta es frecuente y de alto impacto:

bucket S3 con "Principal": "*" que alguien abrió para una prueba y nunca cerró
rol IAM con trust policy que confía en una cuenta externa que ya no existe como partner
clave KMS accesible desde otra cuenta por una integración que ya fue migrada
secret de Secrets Manager con resource policy demasiado permisiva
rol con trust policy heredada hacia Cognito Identity Pools

Estos recursos no necesariamente generan alarmas operacionales. La aplicación puede seguir funcionando normal. Nadie lo nota. El analizador los detecta porque observa la configuración de acceso, no porque espere a que ocurra un incidente.

Recurso recomendado para generar findings útiles

💡 Si quieres ver findings reales sin mucha configuración, este es el recurso más directo:

Crea un bucket S3 con una bucket policy que permita acceso desde una cuenta externa o desde "*". El analizador lo detecta y genera un finding con información como recurso, principal externo, origen del acceso y nivel de acceso.

Por qué S3 es un buen candidato para un lab:

Frecuente en la práctica: los findings externos más comunes suelen involucrar buckets con políticas demasiado abiertas.
Finding rápido: para S3, los cambios en bucket policy o ACL suelen reflejarse dentro de aproximadamente 30 minutos. Otros cambios, como Block Public Access a nivel de cuenta, pueden tardar más.
Finding detallado: muestra el recurso, el principal externo, cómo se compartió y el nivel de acceso.
Fácil de limpiar: eliminar o corregir la bucket policy resuelve el finding.

En la práctica, sin embargo, activar el analizador en un entorno real con AWS IAM Identity Center ya puede generar decenas de findings sin necesidad de crear un recurso de prueba. Eso fue exactamente lo que pasó aquí.

External Access Analyzer en acción: lo que encuentras en un entorno real

Configuración del analizador

El External Access Analyzer se crea desde la consola de IAM:

IAM > Access Analyzer > Analyzers > Create analyzer

Configuración del lab:

Nombre:        demo-external-access-analyzer
Tipo:          External Access Analysis
Zona de trust: AWS Organization

Un detalle importante: el analizador opera por región. Si tienes recursos en us-east-1 y us-east-2, necesitas un analizador en cada región donde quieras monitorear acceso externo. La zona de trust se define a nivel del analizador; si eliges la organización entera, los findings se calculan respecto a ese límite.

Lo que encontré al activarlo: 39 findings activos

No hizo falta crear ningún recurso de prueba. En cuanto el analizador quedó activo, apareció una lista larga de findings activos.

Al inicio tenía aplicado el filtro Public access = false, por eso veía 38 findings. Al quitar ese filtro apareció un finding adicional: un bucket S3 con acceso público (Public access = true). Por eso el total real del analizador era de 39 findings.

La mayoría correspondían a roles IAM relacionados con IAM Identity Center y federación, pero también apareció un bucket S3 con acceso externo. Esa mezcla fue útil porque mostró dos tipos de exposición:

trust policies en roles IAM
resource policies en S3

Esto es importante porque External Access Analyzer no se limita a roles. Su objetivo es detectar recursos soportados que están accesibles desde fuera de la zona de confianza definida para el analizador.

Grupo 1 — Roles SSO: federación esperada, pero no se archiva a ciegas

La mayoría de los findings corresponden a roles con nombres del tipo:

aws-reserved/sso.amazonaws.com/AWSReservedSSO_AdministratorAccess_<sufijo>
aws-reserved/sso.amazonaws.com/AWSReservedSSO_AWSReadOnlyAccess_<sufijo>
aws-reserved/sso.amazonaws.com/AWSReservedSSO_AWSPowerUserAccess_<sufijo>
aws-reserved/sso.amazonaws.com/AWSReservedSSO_AWSOrganizationsFullAccess_<sufijo>

Estos roles los crea AWS IAM Identity Center automáticamente en las cuentas donde asignas permission sets. Su trust policy permite que usuarios federados los asuman a través del SAML provider (en este caso yo tengo configurado cloud identity de google) asociado a IAM Identity Center:

{
  "Effect": "Allow",
  "Principal": {
    "Federated": "arn:aws:iam::<cuenta>:saml-provider/AWSSSO_<id>_DO_NOT_DELETE"
  },
    "Action": [
        "sts:AssumeRoleWithSAML",
        "sts:TagSession"
            ],
    "Condition": {
        "StringEquals": {
            "SAML:aud": "https://signin.aws.amazon.com/saml"
        }
    }
}

El analizador los marca porque, desde la perspectiva de External Access Analyzer, existe un principal federado que puede asumir el rol. En entornos con IAM Identity Center esto suele ser esperado y forma parte del funcionamiento normal de SSO.

En mi caso, la revisión sería:

confirmar que el permission set corresponde al acceso esperado
confirmar que la cuenta donde aparece el rol es la correcta
confirmar que los usuarios o grupos asignados siguen vigentes
confirmar que los permission sets administrativos están donde realmente deben estar

Si todo eso está correcto, estos findings son buenos candidatos para archive rule.

El nivel de acceso que muestra el analizador para estos roles es Write, Tagging, porque el finding está mirando la trust policy del rol: quién puede asumirlo. No está mostrando los permisos efectivos que tendrá la sesión después de asumir el rol.

Dicho de otra forma, en External Access Analyzer un finding sobre un IAM Role responde principalmente a esta pregunta:

¿Quién puede asumir este rol desde fuera de mi zona de confianza?

No responde directamente:

¿Qué puede hacer ese rol una vez asumido?

Grupo 2 — Roles con trust cross-account hacia una cuenta externa

Cuatro findings corresponden a roles con nombres como SSOSAdmin-Asumed, SSOCores-Asumed, SSOArchitech-Asumed y SSOGov-Asumed. Todos tienen el mismo tipo de principal: una cuenta de AWS que no es parte de la organización definida como zona de trust.

Entidad principal: Cuenta de AWS → <cuenta-externa>
Compartido a través de: Trust policy del rol
Nivel de acceso: Write

A diferencia de los roles SSO, aquí el trust es directo hacia una cuenta AWS específica. En este contexto, “cuenta externa” no significa una cuenta desconocida, sino una cuenta fuera de la AWS Organization definida como zona de confianza. En mi caso, ese cross-account fue creado adrede desde otra organización para el lab.

Aun así, el finding es útil porque recuerda algo importante: cuando la zona de trust es la organización, cualquier trust hacia una cuenta fuera de esa organización queda marcado como acceso externo.

La revisión práctica aquí no es “¿quién creó esto?”, sino:

¿este trust cross-account todavía se necesita?
¿la cuenta externa sigue siendo la correcta?
¿el rol tiene permisos acordes al caso de uso?
¿conviene agregar condiciones como sts:ExternalId, aws:PrincipalArn u otra restricción?
¿está documentado que esta cuenta externa puede asumir el rol?

Importante: aunque el rol tenga AdministratorAccess, el finding no muestra AdministratorAccess como acción. External Access Analyzer está evaluando la trust policy del rol, por eso muestra sts:AssumeRole.

El finding responde:

¿quién puede asumir este rol desde fuera de mi zona de confianza?

No responde directamente:

¿qué permisos tendrá esa sesión después de asumirlo?

Para medir el impacto real, hay que revisar también las policies adjuntas al rol. Si el rol confiado por una cuenta externa tiene AdministratorAccess, entonces el finding es más sensible, aunque en la consola solo aparezca sts:AssumeRole.

Grupo 3 — Federación con Google Workspace: SAML externo personalizado

Un finding apunta al rol SSOTestSamlWorkspace, con trust configurado hacia un SAML provider GoogleWorkspace:

Entidad principal: Usuario federado → arn:aws:iam::<cuenta>:saml-provider/GoogleWorkspace
Compartido a través de: Trust policy del rol
Nivel de acceso: Write

Este caso es diferente a los roles AWSReservedSSO_* gestionados por IAM Identity Center. Aquí la confianza está puesta directamente en un SAML provider personalizado.

En mi caso, este rol existe porque uso Google Workspace / Cloud Identity como parte del flujo de federación para entrar a AWS. El analyzer no está diciendo “esto está mal”; está diciendo “este proveedor federado puede asumir este rol”.

Y eso es justo lo valioso: aunque uno mismo lo haya creado, el analyzer lo pone sobre la mesa para decidir si sigue siendo necesario, si debe documentarse mejor, si debe restringirse más o si ya toca borrarlo.

Dicho en simple: gracias, analyzer, por recordarme que este camino de acceso sigue vivo.

Grupo 4 — Cognito: un rol que quedó vivo después de una prueba

Entre todos los findings, hay uno que tiene una naturaleza diferente al resto:

Recurso:    service-role/cognito-testing
Principal:  cognito-identity.amazonaws.com
Condición:  us-east-1:<id-del-pool>  ← pool de Cognito
Nivel:      Write
Tipo:       Público de Cognito

Este finding no venía de un Cognito User Pool, sino de una trust policy de IAM asociada a Cognito Identity Pools. La diferencia importa: el User Pool autentica usuarios, mientras que el Identity Pool puede entregar credenciales temporales de AWS mediante roles IAM.

En mi caso, esto venía de una prueba antigua. En algún momento creé un Identity Pool, luego lo eliminé, pero el rol cognito-testing quedó vivo con esta trust policy:

{
  "Effect": "Allow",
  "Principal": {
    "Federated": "cognito-identity.amazonaws.com"
  },
  "Action": "sts:AssumeRoleWithWebIdentity",
  "Condition": {
    "StringEquals": {
      "cognito-identity.amazonaws.com:aud": "<id-del-pool>"
    },
    "ForAnyValue:StringLike": {
      "cognito-identity.amazonaws.com:amr": "unauthenticated"
    }
  }
}

La conclusión no es que actualmente exista un Identity Pool público activo, porque al revisar la cuenta ya no había Identity Pools en esa región. La conclusión correcta es que quedó un rol IAM con una trust policy heredada de una prueba anterior.

Y justamente ahí está el valor del analyzer: no solo encuentra exposiciones activas evidentes, también te recuerda configuraciones viejas que quedaron dando vueltas.

Gracias, analyzer. Me olvidé de borrar el rol.

Grupo 5 — Bucket S3 con acceso público

Al quitar el filtro Public access = false, apareció un finding adicional sobre un bucket S3:

Recurso: demo-api-gw-s3-cors-555
Tipo:    S3 Bucket
Principal externo: Todas las entidades principales
Acceso público: true
Nivel de acceso: Write, Permissions, Tagging, Read, List
Compartido a través de: Política del bucket

Este bucket fue parte de una prueba de API Gateway + S3/CORS. Justamente por eso el finding es útil: no necesariamente es un recurso productivo comprometido, pero sí es una exposición real que quedó visible para revisión.

A diferencia de los roles SSO, aquí no hablamos de una trust policy de IAM. Hablamos de una bucket policy que permite acceso a todas las entidades principales.

Este finding merece remediación prioritaria porque combina dos señales fuertes:

el principal externo es público
el nivel de acceso incluye más que lectura

En mi caso, como era una prueba, la decisión correcta es simple: corregir la bucket policy, activar/verificar Block Public Access o eliminar el bucket si ya no se necesita.

Categorización práctica de los findings

Con este volumen de findings, la primera tarea es categorizarlos para saber qué revisar primero:

Categoría	Ejemplo	Acción recomendada
Roles SSO gestionados por AWS	`AWSReservedSSO_*` con SAML provider `DO_NOT_DELETE`	Validar permission set, cuenta y asignaciones; luego archivar con archive rule si es esperado
Roles custom con trust cross-account	`SSOSAdmin-Asumed` confiando en cuenta externa	Revisar si el acceso sigue vigente, documentado y justificado
Roles con SAML provider externo personalizado	`SSOTestSamlWorkspace` con GoogleWorkspace	Revisar si el provider y el rol siguen activos
Rol con trust heredada hacia Cognito	`cognito-testing` con `amr = unauthenticated` en la trust policy	Validar si el Identity Pool sigue existiendo; si no existe, eliminar o limpiar el rol
Bucket S3 público	`demo-api-gw-s3-cors-555` con principal público	Revisar bucket policy, Block Public Access y necesidad real de exposición pública

El orden de prioridad no depende solo del volumen. Los roles SSO pueden ser muchos, pero suelen ser esperados si IAM Identity Center está bien gobernado. En cambio, un bucket S3 público con permisos amplios o un rol con una trust policy heredada hacia Cognito pueden representar una superficie de exposición mucho más concreta.

Archive Rules: reducir el ruido esperado

Con decenas de findings de roles SSO esperados, crear una Archive Rule es lo más eficiente. Las archive rules sirven para archivar automáticamente nuevos findings que coincidan con un patrón. Para findings existentes, puedes revisarlos y archivarlos manualmente, o aplicar la regla cuando corresponda desde el flujo de revisión.

Se crean desde:

IAM > Access Analyzer > Analyzers > [tu analizador] > Archive rules > Create rule

Para los roles SSO, una condición útil es filtrar por el nombre del recurso:

Resource contains "aws-reserved/sso.amazonaws.com/AWSReservedSSO_"

Eso ayuda a archivar automáticamente los nuevos findings asociados a roles gestionados por IAM Identity Center, sin mezclar findings más sensibles como buckets públicos, roles custom con trust cross-account, SAML providers externos personalizados o Cognito.

Las condiciones disponibles para los filtros dependen de la consola/API, pero normalmente puedes filtrar por campos como:

Resource
Principal
Access level
Is public
Principal type

Importante: una archive rule no debe usarse para ocultar findings sin revisión. Primero se valida que el patrón sea esperado; recién después se automatiza el archivado.

Recursos soportados por External Access Analyzer

El analizador no solo cubre roles IAM. Estos son los tipos de recursos que puede analizar para external access:

Recurso	Qué evalúa
S3 Buckets	Bucket policy, ACLs, access points asociados y Multi-Region Access Points
S3 Directory Buckets	Directory bucket policy
IAM Roles	Trust policy
KMS Keys	Key policy y grants
Lambda Functions and Layers	Resource-based policies
SQS Queues	Queue policy
SNS Topics	Topic policy
Secrets Manager	Resource policy
ECR Repositories	Repository policy
EFS File Systems	File system policy
EBS Volume Snapshots	Snapshot sharing permissions
RDS DB Snapshots	Snapshot sharing permissions
RDS DB Cluster Snapshots	Snapshot sharing permissions
DynamoDB Streams	Resource policy
DynamoDB Tables	Resource policy

En este lab, la mayoría de findings fueron sobre roles IAM porque el entorno tenía muchos roles SSO y roles con trust policies hacia identidades externas. Sin embargo, también apareció un bucket S3 público. En entornos donde existan claves KMS compartidas, secretos con resource policies externas, colas SQS compartidas o snapshots públicos, el analizador también puede generar findings de esos tipos.

Qué hacer con un finding: Archive vs. remediar

Cuando un finding aparece, tienes dos caminos:

1. Si el acceso es intencional:

Haz clic en Archive. El finding pasa a estado Archived y queda fuera de la vista activa. También puedes crear archive rules para que findings similares se archiven automáticamente después de haber validado que ese patrón es esperado.

2. Si el acceso no es intencional:

Modifica o elimina la política o configuración que abre el acceso. En cuanto el recurso deja de tener acceso externo, el finding pasa a estado Resolved.

Archivar no es remediar. Archivar significa: “este acceso fue revisado y es intencional”. Si el acceso no debería existir, lo correcto no es archivarlo; lo correcto es corregir la policy.

External Access vs. Internal Access: cuándo usar cada uno

Antes de pasar al siguiente post, vale la pena separar ambos conceptos.

External Access Analyzer e Internal Access Analyzer pertenecen a IAM Access Analyzer, pero responden preguntas distintas. External mira hacia fuera: recursos accesibles desde fuera de la zona de confianza. Internal mira hacia dentro: identidades internas que tienen acceso a recursos seleccionados.

Criterio	External Access Analyzer	Internal Access Analyzer
Pregunta que responde	¿Qué recursos están accesibles desde fuera de mi zona de confianza?	¿Qué identidades internas tienen acceso a recursos críticos seleccionados?
Zona de confianza	Cuenta o AWS Organization	Cuenta o AWS Organization
Tipo de exposición	Acceso público o cross-account externo	Acceso interno dentro de la cuenta u organización
Qué analiza principalmente	Resource-based policies, trust policies, ACLs o grants según el tipo de recurso	Permisos efectivos sobre recursos específicos seleccionados
Ejemplos de recursos	Roles IAM, buckets S3, KMS keys, Lambda, SQS, SNS, Secrets Manager, ECR, EFS, snapshots, DynamoDB, entre otros recursos soportados	Recursos específicos que seleccionas para análisis interno
Cobertura	Recursos soportados en la región donde el analyzer está activo	Solo los recursos que seleccionas explícitamente
Costo	Sin costo adicional	Pagado por recurso monitoreado, por analyzer y por región
SCP/RCP	No es su objetivo principal como cálculo de permiso efectivo; se enfoca en exposición externa desde políticas de recurso, trust policies, ACLs o grants	Sí entra en el modelo de análisis de permiso efectivo, aunque la interpretación del action list requiere cuidado
Mejor uso	Baseline permanente para detectar exposición pública o externa	Auditoría específica de acceso interno sobre recursos sensibles
Recomendación práctica	Activarlo en todas las cuentas y regiones relevantes	Usarlo con criterio sobre recursos críticos por costo y alcance

La forma corta de verlo es esta:

External Access Analyzer sirve para detectar exposición hacia fuera.
Internal Access Analyzer sirve para revisar acceso interno sobre recursos críticos.
External debería ser baseline.
Internal debería usarse selectivamente donde realmente necesitas análisis de acceso efectivo.

Perspectiva de seguridad: por qué los findings deben revisarse antes de archivarse

External Access Analyzer también es útil desde una perspectiva de evaluación de seguridad.

Un usuario o rol con permisos suficientes para consultar Access Analyzer podría usar los findings como un mapa rápido de recursos expuestos externamente: buckets con acceso público, roles con trust policies hacia cuentas externas, proveedores SAML externos o configuraciones de Cognito que permitan identidades no autenticadas.

Eso no significa que cualquier finding sea automáticamente crítico. Significa que cada finding representa una ruta de acceso que existe y que merece clasificación.

Desde el lado defensivo, la prioridad es llegar antes:

Activar el analyzer.
Revisar los findings.
Separar accesos esperados de accesos no documentados.
Archivar lo intencional.
Remediar lo que no debería existir.

Los findings sin revisar son el problema real. Un bucket público intencional, documentado y monitoreado no tiene el mismo peso que un bucket público creado para una prueba y olvidado. Lo mismo aplica para roles federados, trusts cross-account o pools de Cognito.

En este lab, la mayoría de findings eran esperados por IAM Identity Center, pero el bucket S3 público y el rol con trust heredada hacia Cognito merecían revisión separada. Esa es precisamente la utilidad del analyzer: no reemplaza el criterio del equipo de seguridad, pero reduce mucho el tiempo necesario para encontrar qué revisar primero.

Lo que demuestra este lab

Activar el analizador en un entorno real con IAM Identity Center puede generar hallazgos desde los primeros minutos, sin necesidad de crear recursos de prueba. Eso ya dice algo: hay rutas de acceso que merecen revisión y que no siempre son visibles si solo revisas manualmente cada cuenta o cada policy.

Lo que vale de este analizador no es que reemplace el criterio del equipo de seguridad. Su valor está en que es continuo y automático: revisa los recursos soportados y genera findings cuando detecta acceso público o externo respecto a tu zona de confianza.

En términos prácticos:

✅ Sin costo adicional
✅ Cobertura automática de recursos soportados en la región donde se habilita
✅ Findings con detalle de recurso, principal, tipo de acceso y acciones reportadas
✅ Archive rules para reducir ruido esperado, como roles SSO gestionados por IAM Identity Center
✅ Estado Resolved cuando el acceso externo deja de existir

Y la lección más importante del lab: el volumen de findings no es el indicador principal de riesgo.

En mi caso, con el filtro Public access = false veía 38 findings. Al quitarlo, apareció un bucket S3 público y el total subió a 39. La mayoría eran roles SSO esperados, pero el bucket S3 público y el rol con trust heredada hacia Cognito merecían revisión separada. Ese es precisamente el punto: el analyzer no solo te muestra cuántos findings tienes, sino cuáles debes clasificar primero.

Conclusión

Si tienes una cuenta de AWS y no tienes External Access Analyzer activo, es uno de los primeros controles que habilitaría. No tiene costo adicional, se activa en minutos y te da visibilidad sobre accesos que normalmente no generan una alerta operacional por sí solos.

Lo que pasó en este lab es representativo de muchos entornos con IAM Identity Center: aparece un volumen alto de findings esperados, especialmente por roles SSO, pero entre ellos puede haber uno o dos findings que sí merecen atención inmediata.

La habilidad no está solo en activar el analyzer. La habilidad está en clasificar rápido:

qué es esperado
qué debe archivarse
qué debe documentarse
qué debe corregirse

En el siguiente post cubro Internal Access Analyzer: cómo analizar acceso interno efectivo sobre un recurso crítico, cómo se cruzan IAM policies, bucket policies y SCPs, y por qué no basta con revisar una sola policy.

💡 ¿Cuántos findings aparecen cuando activas el analizador por primera vez en tu entorno? El número suele ser una sorpresa — y la mayoría son esperados, pero entre ellos casi siempre hay algo que merece atención.

🔗 Si llegaste directo aquí, te recomiendo leer la Parte 1 para el contexto base. En la Parte 3 veremos Internal Access Analyzer con un lab de permisos efectivos, SCPs y acceso cross-account interno.

AWS #CloudSecurity #IAM #AccessAnalyzer #IAMIdentityCenter #SSO #CognitoSecurity #ExternalAccess #CloudGovernance #AWSOrganizations #LeastPrivilege

Referencias

AWS IAM Documentation — What is IAM Access Analyzer?
https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html
AWS IAM Documentation — IAM Access Analyzer supported resource types for external and internal access
https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-resources.html
AWS IAM Documentation — Create an IAM Access Analyzer external access analyzer
https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-create-external.html
AWS IAM Documentation — IAM Access Analyzer findings
https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-findings.html
AWS IAM Documentation — Archive rules
https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-archive-rules.html
AWS Pricing — IAM Access Analyzer pricing
https://aws.amazon.com/iam/access-analyzer/pricing/
AWS S3 Documentation — Reviewing bucket access using IAM Access Analyzer for S3
https://docs.aws.amazon.com/AmazonS3/latest/userguide/access-analyzer.html
AWS S3 Documentation — Blocking public access to your Amazon S3 storage
https://docs.aws.amazon.com/AmazonS3/latest/userguide/access-control-block-public-access.html

🛡️AWS IAM Access Analyzer — Parte 1/4

Terry Quispe Paniagua — Sun, 21 Jun 2026 01:14:43 +0000

¿Quién puede acceder realmente a tus recursos en AWS?

En el post anterior hablamos de SCPs, RCPs y IAM Policies. Si no lo leíste, te recomiendo empezar por ahí porque este post construye sobre eso.

Hoy quiero hacerte una pregunta incómoda:

"¿Puedes decirme, ahora mismo, qué identidades tienen acceso efectivo a este bucket S3?"

No el acceso que pensaste que configuraste. El acceso real, considerando todas las políticas en juego.

Si tardas más de 30 segundos en responder, este post es para ti.

El problema con el acceso en AWS

Cuando tienes una sola cuenta y cuatro usuarios, responder esa pregunta es fácil. Abres la consola, revisas las políticas y listo.

Pero hay una diferencia importante entre dos cosas que suelen confundirse:

Acceso esperado: lo que crees que configuraste, suponiendo que sea correcto.
Acceso efectivo: lo que AWS realmente permite después de evaluar todas las políticas

La brecha entre estas dos cosas es donde vive la mayoría de los incidentes de seguridad en AWS. No son ataques sofisticados. Son configuraciones que alguien dio por buenas porque "la IAM policy dice que sí" — sin considerar el resto de las capas.

En el mundo real, un entorno AWS medianamente serio se parece más a esto:

10, 20, 50 o más cuentas dentro de una AWS Organization
Decenas de roles que se asumen entre cuentas - en algunas ocasiones he visto miles -.
SCPs aplicadas a nivel de OU que limitan lo que pueden hacer las identidades.
RCPs que controlan quién puede acceder a tus recursos desde fuera.
Resource-based policies en S3, KMS, SQS, SNS, etc.
Permission Boundaries en algunos roles.
Trust policies que definen quién puede asumir cada rol.

Y ahí es donde la cosa se complica de verdad.

¿Qué determina realmente el acceso efectivo?

Cuando AWS evalúa si una acción está permitida, no se queda solo con la IAM policy que ves en el rol o usuario. Revisa todas las capas que aplican a esa solicitud y parte de una regla muy simple: si no hay un Allow, el acceso está denegado; y si aparece un Deny explícito, ese Deny gana siempre.

Dicho de forma simple, en una sola cuenta la evaluación se puede entender así:

¿Existe un Deny explícito aplicable?
    └── Sí → DENEGADO. Fin.
    └── No → continuar

¿Existe algún Allow válido?
    └── Puede venir de una IAM policy o de una resource-based policy
    └── Si no existe → DENEGADO

¿Hay algún límite que recorte ese permiso?
    └── SCP
    └── RCP
    └── Permission Boundary
    └── Session Policy

Si hay Allow y ningún límite lo bloquea → PERMITIDO

La parte importante es esta: IAM policies y resource-based policies pueden conceder permisos, pero SCPs, RCPs, Permission Boundaries y Session Policies funcionan más como límites. No agregan permisos por sí solos; más bien definen hasta dónde puede llegar un permiso que ya existe.

Resumido de forma práctica:

Acceso efectivo =
    permiso concedido
  - denies explícitos
  - límites organizacionales
  - boundaries o session policies aplicables

Si cualquiera de estas capas dice "No", la acción está bloqueada. No importa que las demás capas parezcan permitirlo. Este es el punto que la gente entiende en teoría pero subestima en la práctica. En cross-account hay matices adicionales, porque AWS evalúa tanto la cuenta del principal como la cuenta donde vive el recurso. Pero la idea base se mantiene: cualquier deny explícito aplicable bloquea la acción. Puedes revisar el flujo de evaluación en:

El problema a escala: con múltiples cuentas, cientos o miles de roles, innumerables recursos, varias OUs con diferentes SCPs y RCPs, hacer este análisis a mano para cada recurso crítico es inviable. Y si no lo haces, no sabes realmente qué acceso tienen tus identidades.

Tres escenarios donde el acceso falla aunque "debería" funcionar

Estos son los casos que más se repiten. Si has trabajado en entornos con Organizations, probablemente reconoces alguno.

Escenario 1: El admin que no puede hacer nada

Un usuario tiene la política AdministratorAccess en su cuenta. Intenta crear un bucket S3 en sa-east-1 y le da error de acceso denegado. No cambió nada. Todo funcionaba ayer.

Lo que pasó: alguien en el equipo de plataforma aplicó una SCP a nivel de OU que restringe la creación de recursos a us-east-1 únicamente - algo muy habitual y recomendado -. El admin ve un AccessDenied, pero también el motivo por el cual, ya que en el detalle de error se indica que la acción está vetada por una SCP - a veces no es tan detallado -.

La SCP es un límite máximo. AdministratorAccess dice "puede hacer todo", pero si la SCP dice "solo en us-east-1", el resultado es "puede hacer todo, solo en us-east-1".

Ejemplo: Eliminación de objeto con restricción por SCP

Ejemplo: Eliminación de objeto por CLI

Escenario 2: El bucket "público" que no lo es

Un desarrollador configura un bucket S3 con una bucket policy que permite s3:GetObject a "Principal": "*". Desde su cuenta local, el acceso funciona. Pero desde una cuenta externa de un proveedor, el acceso falla.

Lo que pasó: hay una RCP a nivel de organización que exige que cualquier acceso a recursos de S3 venga de un principal con aws:PrincipalOrgID igual al ID de la organización. El "*" de la bucket policy no se limita a sí mismo — la RCP sí lo limita desde afuera.

La RCP actúa sobre el recurso sin importar lo que diga la bucket policy. El desarrollador configuró el acceso "correctamente" según lo que entiende de S3, pero la capa organizacional lo restringe silenciosamente.

Escenario 3: El rol cross-account que IAM permite pero S3 no

Un rol en la Cuenta B tiene una IAM policy que permite s3:GetObject sobre el bucket arn:aws:s3:::datos-criticos/*. El equipo valida la policy, todo se ve bien. Pero cuando el rol intenta acceder al bucket, falla.

Lo que pasó: la bucket policy en la Cuenta A (donde vive el bucket) no lista el rol de Cuenta B como Principal permitido. En acceso cross-account, tanto la IAM policy del rol como la resource-based policy del recurso deben permitir la acción de forma explícita. Una sola no alcanza.

Este es uno de los errores más comunes con acceso cross-account: el equipo de Cuenta B configura sus políticas IAM perfectamente y asume que eso es suficiente. No lo es.

¿Qué es IAM Access Analyzer y qué tipos existen?

IAM Access Analyzer es el servicio de AWS que ayuda a identificar y revisar accesos sobre recursos e identidades. En vez de revisar políticas manualmente y cruzar capas en tu cabeza — lo que puede ser propenso a errores y muy complicado — , el analizador lo hace por ti y genera findings — hallazgos sobre accesos que merecen revisión.

Hay tres tipos de analizador, y es importante no confundirlos porque resuelven problemas distintos:

Tipo	¿Qué detecta?	¿Tiene costo?	¿Cuándo usarlo?
External Access	Recursos accesibles desde fuera de tu zona de confianza (otra cuenta, internet)	Sin costo adicional	Siempre. Es el punto de partida en cualquier cuenta
Internal Access	Qué principals dentro de tu org tienen acceso a recursos específicos, con permisos efectivos	Pagado ($9 USD/recurso/región/mes)	Recursos críticos: buckets, RDS o cluster snapshots, DynamoDB etc.
Unused Access	Roles y usuarios con permisos concedidos que no han sido utilizados	Pagado ($0.20 USD/rol o usuario/mes)	Revisiones de least privilege, limpieza de accesos obsoletos

La confusión más común es querer usar Internal Access para detectar accesos externos. No hace eso. Para eso existe External Access, que además es gratuito.

La novedad relevante que cubre esta serie es Internal Access, una de las capacidades más recientes de IAM Access Analyzer, que permite analizar el permiso efectivo considerando SCPs, RCPs y resource policies en conjunto.

¿Por qué importa esto para seguridad?

Auditorías y cumplimiento (PCI-DSS, ISO 27001, SOC 2)
En una auditoría, alguien va a pedirte evidencia de quién tiene acceso a tus datos sensibles. Access Analyzer te da eso en formato exportable, con el detalle de qué acciones puede realizar cada identidad. En vez de revisar cien políticas a mano, tienes un reporte automatizado.

Least privilege de verdad
Es fácil escribir "aplicamos least privilege" en un documento de arquitectura. Es difícil demostrarlo. Con análisis de permisos efectivos puedes ver exactamente qué permisos tiene cada identidad sobre cada recurso, y limpiar lo que sobra. No lo que crees que sobra — lo que el analizador te muestra que sobra.

Detección de configuraciones erróneas antes de que las encuentre alguien más
Un rol con "Resource": "*" donde debería tener un ARN específico. Una bucket policy que alguien amplió para una prueba y nunca revirtió. Un acceso cross-account que quedó abierto después de una migración. Estos hallazgos no generan alertas operacionales — el sistema funciona, el acceso existe, y nadie lo nota hasta que hay un incidente o una auditoría.

Esta serie da para más

Mientras armaba este post me di cuenta de que IAM Access Analyzer no se puede explicar bien en una sola publicación sin hacerlo pesado - la verdad los conceptos de acceso en cloud son pesados si no se aterrizan correctamente.

Por eso voy a separar la serie en tres partes mas una cuarta parte opcional como bonus con mcp: External Access, Internal Access y Unused Access. En cada una veremos el concepto, un caso práctico y un pequeño lab con evidencias, para aterrizarlo mejor y no quedarnos solo en la teoría.

ADVERTENCIA.
Algunos de los labs tendrán costos por lo que les pido precaución, lean antes y tengan controlado sus recursos.

¿Qué viene en la Parte 2?

En el siguiente post vamos al laboratorio. Vamos a:

Configurar un analizador Internal Access a nivel de organización
Crear tres roles con distintos niveles de acceso en una cuenta y un bucket en otra
Agregar una SCP que bloquea una acción aunque IAM y la bucket policy la permitan
Ver los findings de Access Analyzer y validar con CLI que el permiso efectivo es exactamente lo que el analizador reporta

💡 Reflexión: ¿Alguna vez encontraste un rol con más acceso del que debería tener, después de creer que todo estaba bien configurado? Es más común de lo que parece — y casi siempre la diferencia está entre el acceso esperado y el acceso efectivo.

🔜 Parte 2: Lab completo de IAM Access Analyzer Internal Access con SCPs, cross-account y validación por CLI.

AWS #CloudSecurity #IAM #AccessAnalyzer #AWSCommunityBuilder #CloudGovernance #AWSOrganizations

Referencias

🛡️ Entendiendo las Service Control Policies (SCPs) en AWS Organizations

Terry Quispe Paniagua — Tue, 02 Dec 2025 03:47:50 +0000

1. Introducción

¿Qué problema resuelven las SCPs?

Las SCPs, a diferencia de los permisos de IAM, no otorgan permisos, sino que los restringen. Popularmente llamados "guardrails" o "barandillas", son una herramienta clave para la gobernanza de AWS, así como también para fijar los lineamientos de seguridad y cumplimiento de la empresa.

Antes de proseguir debemos entender unos conceptos previos:

IAM Policy

Es un tipo de política de IAM que permite otorgar permisos a los usuarios y roles de AWS.

AWS Organizations

AWS Organizations es un servicio que permite administrar y gestionar de forma centralizada múltiples cuentas de AWS. Con Organizations puedes:

Crear y gestionar cuentas de AWS (Account Management)
Centralizar los costos de las cuentas de AWS (Billing)
Gestionar los permisos de las cuentas de AWS junto a IAM Identity Center (Identity and Access Management)
Aplicar políticas de seguridad a las cuentas de AWS (SCPs)
Habilitar servicios multicuentas (Multi-account)
Agrupar cuentas por Unidades Organizativas (Jerarquía de organización)
Auditar entorno multicuentas (Audit)
Compartir recursos en múltiples cuentas (Resource sharing)
Automatizar aprovisionamiento de múltiples cuentas mediante CloudFormation (Multi-account)

2. Service Control Policies (SCPs)

Es un tipo de política de AWS Organizations que permite restringir los permisos de las cuentas de AWS que pertenecen a la organización. Esta es una característica de AWS Organizations; existen otras políticas, pero nos centraremos en el tipo de servicio.

Estructura de una SCP

La estructura de una SCP es la siguiente:

Elementos principales de una SCP:

Elemento	¿Qué hace?
Statement	Es el contenedor principal de una política. Puedes tener varios statements en una SCP (cuidado: hay un límite de caracteres).
Effect	Define si el statement permite (`Allow`) o bloquea (`Deny`) acciones. Nota: `Allow` no permite condicionales.
Action	Especifica qué acciones de AWS se permiten o bloquean (ej: `s3:PutObject`).
Resource	Indica a qué recursos de AWS aplica la política (ej: un bucket específico).
Condition	(Opcional) Agrega condiciones para que el statement aplique solo en ciertos casos.
NotAction	Lo opuesto a `Action`: especifica acciones que quedan exentas de la SCP.
NotResource	Lo opuesto a `Resource`: especifica recursos que quedan exentos de la SCP.
Sid	(Opcional) Un nombre amigable para identificar el statement.
Version	Define la versión del lenguaje de políticas (siempre usa `"2012-10-17"`).

Comportamiento de una SCP

Para entender mejor cómo funcionan las SCPs, podemos agrupar sus comportamientos en cuatro categorías clave:

1. Principios Básicos

Naturaleza: No otorgan permisos, solo los restringen.
Evaluación: Un permiso solo se ejecuta si existe una política IAM que lo permita y una SCP que lo permita o no lo deniegue, en el caso de evaluación IAM y SCP. La evaluación final se encuentra en la documentación oficial de AWS.

2. Alcance: ¿A quién afecta?

Cuentas Miembro: Las SCPs restringen los permisos de todos los usuarios y roles, incluido el usuario root.
Administradores Delegados: Sí están afectados, ya que residen en cuentas miembro.
Excepción Clave: La Cuenta de Administración (Management Account) NO se ve afectada por las SCPs.

3. Interacción con otras Políticas

IAM Deny: Siempre tiene prioridad sobre cualquier SCP.
SCP Deny: Bloquea la acción explícitamente, incluso si IAM otorga AdministratorAccess.
Permission Boundaries: La evaluación final requiere: IAM Allow + SCP Allow + Boundary Allow.

4. Excepciones Técnicas

Service-Linked Roles: No se pueden restringir con SCPs, ya que son necesarios para que los servicios de AWS funcionen correctamente.
Resource-Based Policies: No se ven afectadas por SCPs; los accesos externos a recursos (como un bucket S3) siguen funcionando si la política del recurso lo permite.
Usuarios Externos: No se ven afectados, incluso si acceden a recursos dentro de una cuenta restringida.

¿Dónde se aplican las SCPs?

En AWS Organizations, las SCPs se aplican a las cuentas de AWS que pertenecen a la organización y también a las unidades organizativas. Una unidad organizativa es como un folder donde puedes agrupar cuentas de AWS.

A continuación una vista de una jerarquía de organización en AWS Organizations:

Componentes de una jerarquía de organización:

Cuenta raíz (Root): Es la cuenta principal de la organización, generalmente la cuenta de AWS que se creó al crear la organización. Importante: Aplicar una SCP a la cuenta raíz afecta a todas las cuentas de la organización sin excepción (mucho cuidado con esto).
Unidades organizativas (OUs): Son como folders donde puedes agrupar cuentas de AWS. Aplicar una SCP a una OU afecta a todas las cuentas que pertenecen a la OU.
Cuentas: Son las cuentas de AWS que pertenecen a la organización. Aplicar una SCP a una cuenta afecta solo a esa cuenta.

Nota: Las SCPs pueden aplicarse a múltiples cuentas por su característica de herencia.

3. Laboratorio: Creación de SCPs

Costo del laboratorio: $0

⚠️ Advertencia: Nunca debes aplicar una SCP a la cuenta productiva ni a un entorno con cuentas productivas. Siempre usa cuentas de prueba para validar el funcionamiento de la SCP antes de aplicarlo en múltiples cuentas.

A. Armando el laboratorio para probar SCPs

🔐 Requisitos previos

Tener una cuenta AWS principal (payer) desde la cual crearás la Organización.
Tener acceso administrativo a esa cuenta.
No necesitas método de pago adicional para la segunda cuenta.

✅ Paso 1: Crear una Organización en AWS (si aún no está creada)

1.1. Ingresa a la cuenta administradora (payer/root) de AWS.

1.2. Ve al servicio AWS Organizations.

1.3. Si todavía no tienes una organización:

Haz clic en Create Organization.
Confirmar creación de la organización.

🎉 Ahora tienes la capacidad de usar SCPs.

✅ Paso 2: Crear una Unidad Organizativa (OU) para pruebas

Las OU te ayudarán a aislar y probar SCPs sin afectar nada productivo o importante.

2.1. En AWS Organizations, ve a AWS accounts.

2.2. Selecciona la OU raíz (root) y haz clic en Actions.

2.3. Clic en Create new organizational unit (OU).

2.4. Pon un nombre claro (ej: lab-scp-test) y acepta.

✅ Paso 3: Crear una cuenta miembro dentro de la OU

Crearás una segunda cuenta AWS desde la cuenta administradora. Esta cuenta será tu "cuenta de pruebas" donde validarás las SCPs.

3.1. Desde AWS Organizations, ve a AWS Accounts → Add an AWS account → Create an AWS account.

3.2. Rellena:

Account name: lab-scp-member (o el nombre de tu elección, puedes cambiar el nombre a futuro)
Email address: Te aconsejo usar tu correo con el que creaste la cuenta administradora, pero con un alias de la siguiente manera:
```
 <tuemail_sin_@gmail.com>+labscp@gmail.com
```
Ejemplo: Si tu correo es pepito@gmail.com, tu segunda cuenta deberá ser: pepito+labscp@gmail.com

3.3. Clic en Create an AWS account.

✅ Paso 4: Mover la cuenta a la OU creada

4.1. Selecciona la cuenta, clic en Actions → Move AWS account.

4.2. Elige la OU creada.

4.3. Clic en Move AWS account.

🔹 Configuración inicial de la cuenta miembro

AWS enviará un correo para activar la cuenta. Necesitarás entrar a la cuenta para probar las SCPs. Para el primer ingreso lo harás con la cuenta root (podrías generar un ingreso mediante IAM Identity Center, pero se verá en otro artículo) y harás un reset de contraseña. Procura seguir las buenas prácticas de seguridad colocando MFA y una contraseña fuerte.

Adicionalmente, necesitarás crear un usuario IAM con permisos de administrador, solo con propósitos de prueba, ya que no usaremos la root.

Guía para crear un usuario IAM: https://docs.aws.amazon.com/es_es/IAM/latest/UserGuide/id_users_create.html

Luego de crear el usuario IAM, procederás a ingresar a la cuenta miembro con el usuario IAM creado para realizar las pruebas de SCPs. Recuerda: es solo para pruebas. Las SCPs solo se adjuntarán y crearán en la cuenta administradora de la organización; no podrás ver la organización desde la cuenta miembro.

B. Creación de SCPs

✅ Paso 1: Acceder a AWS Organizations

1.1. Desde la consola de AWS, busca y selecciona Organizations.

1.2. Asegúrate de estar en la cuenta raíz de la organización o en una cuenta con permisos de administración de la organización.

✅ Paso 2: Crear la SCP

2.1. En el menú lateral, selecciona Policies → Service control policies.

2.2. Haz clic en Create policy.

2.3. Ingresa un nombre y descripción para tu política.

2.4. Define el contenido de la política en formato JSON (ver ejemplos más adelante).

C. Vincular política SCP a una OU o cuenta

✅ Paso 1: Vincular SCP a la OU de pruebas

1.1. En AWS Organizations → AWS accounts, selecciona la OU objetivo, cuenta o folder raíz.

1.2. Haz clic en Policies → Service control policies → Attach.

1.3. Selecciona la SCP creada y haz clic en Attach policy.

D. Prueba de SCP

1.1. Ve a la cuenta miembro (cuenta de pruebas).

1.2. Accede con el usuario IAM creado.

1.3. Intenta realizar la acción que se definió en la SCP.

4. Ejemplos de SCP para control de recursos en AWS

Nos basamos en una organización con estructura de OUs y cuentas de prueba, donde puedes aplicar estas SCPs para validar su funcionamiento.

Ejemplo de jerarquía organizativa:

Root
└── OU: <root-ou>
    ├── Development
    │   ├── Sandbox Dev 01 (Cuenta)
    │   └── <deepracer-aft1> (Cuenta)
    ├── Management
    │   └── Administrator (Cuenta de administración)
    ├── Network
    │   └── Networking (Cuenta)
    └── Security
        ├── Audit (Cuenta)
        └── Log Archive (Cuenta)

Nota: Estas SCPs se pueden aplicar a la OU raíz, a una OU específica o a cuentas individuales, según el alcance que necesites. Recuerda que las denegaciones prevalecen y no se aplican a la cuenta administradora.

1️⃣ Denegar creación de buckets S3

Evita que cualquier cuenta cree buckets S3:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "DenyS3BucketCreation",
            "Effect": "Deny",
            "Action": "s3:CreateBucket",
            "Resource": "*"
        }
    ]
}

Aplicación: Colocar en la OU raíz para afectar a todas las cuentas de prueba, bloqueando la creación de buckets S3.

2️⃣ Restringir regiones de despliegue en las cuentas de Development

Evita que se utilicen regiones distintas a la permitida, dejando accesibles solo ciertos servicios esenciales:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Deny",
            "NotAction": [
                "budgets:*",
                "cloudfront:*",
                "config:*",
                "ec2:DescribeRegions",
                "ec2:DescribeTransitGateways",
                "ec2:DescribeVpnGateways",
                "iam:*",
                "networkmanager:*",
                "organizations:*",
                "route53:*",
                "s3:*",
                "shield:*",
                "sts:*",
                "support:*",
                "trustedadvisor:*",
                "waf:*"
            ],
            "Resource": "*",
            "Condition": {
                "StringNotEquals": {
                    "aws:RequestedRegion": [
                        "${REGION_NAME}"
                    ]
                }
            }
        }
    ]
}

Reemplaza ${REGION_NAME} por la región autorizada (ejemplo: "us-east-1").

Aplicación: Útil para controlar costos y garantizar que recursos solo se desplieguen en regiones aprobadas. Dado que mencionan el alcance hacia las cuentas Development se vinculara a la OU Development que es el folder de esas cuentas.

descripcion: En este caso se uso de NotAction para no afectar ciertos servicios de alcanza global, en este caso servicios como budgets, cloudfront, config, iam, networkmanager, organizations, route53, s3, shield, sts, support, trustedadvisor, waf no se veran afectados pero los demas si.

3️⃣ Restringir tipos de instancias RDS

Evita que se creen instancias RDS que no correspondan a un tipo aprobado:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "DenyUnapprovedRDSTypes",
            "Effect": "Deny",
            "Action": "rds:CreateDBInstance",
            "Resource": "*",
            "Condition": {
                "StringNotEquals": {
                    "rds:DatabaseClass": "${INSTANCEDBTYPE}"
                }
            }
        }
    ]
}

Reemplaza ${INSTANCEDBTYPE} por el tipo de instancia aprobado (ejemplo: "db.t3.medium").

Aplicación: Garantiza estándares de arquitectura y control de costos en RDS.

4️⃣ Denegar escritura en buckets S3 fuera de la organización

Evita que cualquier cuenta escriba en buckets S3 que no pertenezcan a la organización:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "DenyS3WritesToUnauthorizedBuckets",
            "Effect": "Deny",
            "Action": [
                "s3:Put*"
            ],
            "Resource": "*",
            "Condition": {
                "StringNotEquals": {
                    "aws:ResourceOrgID": "[O-XXXXX]"
                }
            }
        }
    ]
}

Reemplaza [O-XXXXX] por el ID de tu organización.

Aplicación: Útil para prevenir que los datos se escriban fuera de los buckets gestionados por tu organización, reforzando la seguridad y gobernanza de S3.

5. SCPs que toda cuenta debería tener

No existen SCPs que toda cuenta debería tener de forma universal, ya que cada organización tiene sus propias necesidades y requisitos. Sin embargo, bajo un modelo de seguridad básico, considero que las cuentas deberían tener al menos las siguientes SCPs:

🔐 5.1. Denegar la utilización de cuentas ROOT

Descripción: Evita que se realicen acciones críticas usando la cuenta raíz de AWS.

Beneficio: Protege la cuenta administrativa principal de accesos accidentales o maliciosos.

🚪 5.2. Denegar la acción de salir de la organización

Descripción: Impide que las cuentas miembros abandonen la organización.

Beneficio: Mantiene la gobernanza centralizada y evita pérdidas de control sobre cuentas.

👤 5.3. Denegar acciones en IAM que no sean usuarios y roles específicos

Descripción: Restringe la creación o modificación de políticas, roles y permisos que no estén permitidos.

Beneficio: Evita escalación de privilegios no controlada y mantiene la seguridad de la identidad.

🌍 5.4. Denegar regiones no utilizadas en la organización

Descripción: Bloquea la creación de recursos fuera de las regiones aprobadas.

Beneficio: Controla costos y asegura consistencia operativa en regiones autorizadas.

📝 5.5. Denegar borrado y modificación de registros específicos

Descripción: Protege logs críticos de CloudTrail, Config u otros registros importantes.

Beneficio: Garantiza trazabilidad y cumplimiento normativo.

🗄️ 5.6. Denegar borrado de buckets donde se guardan registros de auditoría

Descripción: Impide que se eliminen buckets S3 usados para almacenar logs de auditoría.

Beneficio: Asegura la integridad de los registros y evidencia de auditoría.

💰 5.7. Denegar servicios con alto coste no útiles para la organización

Descripción: Bloquea servicios como Redshift, SageMaker u otros que no estén aprobados.

Beneficio: Evita gastos innecesarios y recursos no autorizados.

Aunque muchas de estas SCPs están enfocadas principalmente en gobernanza y control, también actúan como capas adicionales de seguridad, creando barreras que protegen la organización de errores, mal uso o accesos no deseados.

6. Conclusión

Las Service Control Policies (SCPs) son una herramienta fundamental para establecer guardrails de seguridad, cumplimiento y gobernanza en AWS Organizations. A través de este artículo hemos aprendido:

Qué son las SCPs y cómo se diferencian de las políticas IAM tradicionales
Cómo funcionan y a quién afectan dentro de la organización
Dónde aplicarlas en la jerarquía organizativa
Cómo crear un laboratorio de pruebas sin costo para validar SCPs
Ejemplos prácticos de políticas comunes para controlar recursos
Recomendaciones básicas de SCPs que toda organización debería considerar

Recuerda siempre probar tus SCPs en entornos de prueba antes de aplicarlas en producción, ya que una política mal configurada puede bloquear operaciones críticas. Las SCPs son restrictivas por naturaleza: no otorgan permisos, solo los limitan.

Con una implementación cuidadosa, las SCPs te permitirán mantener el control centralizado de tu entorno multi-cuenta, reducir riesgos de seguridad y optimizar costos operativos.

7. Bonus RedTeam

Hemos hablado bastante de SCPs, pero ahora comprendes que tan importante es la management account para controlar todo el entorno. Si alguien tiene acceso no autorizado a la management account es lo mas peligroso que puede pasar, como recordaras estan excentas de las SCPs y puedes tomar acciones en las cuentas miembros desde crearlas, cerrarlas o expulsarlas de la organización. AWS organizations no es solo politicas de organización, es un servicio que integra muchos otro servicio de seguridad que veremos mas adelante.

8. Pregunta de reflexión final

¿Qué tan seguro crees que es tu entorno multi-cuenta? ¿Qué medidas adicionales consideras importantes para mejorar la seguridad de tu organización?

🚀 ¡Ahora es tu turno de implementar SCPs en tu organización!

9. Documentación y Referencias

AWS Policy Deep Dive

Terry Quispe Paniagua — Sun, 23 Nov 2025 23:37:11 +0000

Parte 1: ¿Crees que tus datos están seguros solo con IAM? Hablemos de SCPs y RCPs.

🛡️ La seguridad en la nube requiere una estrategia de defensa en profundidad. 🛡️
Cuando empecé en AWS, pensaba que con IAM bastaba. Pero al profundizar, me di cuenta de la importancia de capas adicionales como las SCPs y RCPs.

Entender la diferencia entre Identidad, Recurso y Control Organizacional es vital para proteger nuestros entornos. No es solo "dar permisos", es saber dónde aplicarlos para garantizar el menor privilegio y la máxima seguridad.

Aquí les comparto mi guía mental para no perderse y saber identificar cuando podemos o debemos usar cada una de estas.

1️⃣ Identity-based Policies (IAM Policies)

👉 El "Quién puede hacer qué" Son las más comunes. Se adjuntan a Usuarios, Grupos o Roles.
📝 Ejemplo: Un usuario de operaciones necesita iniciar o detener instancias EC2s, pero no puede crear, terminar ni modificar instancias.

Acción: Crear una Policy que permita ec2:StartInstances y ec2:StopInstances en la tabla de "Productos".
Resultado: Si intenta modificar o eliminar la instancia, AWS le dice "No".

2️⃣ Resource-based Policies

👉 El "Quién puede tocar ESTO" Aquí la regla vive en el recurso mismo (S3 Bucket, SQS, KMS Key), no en el usuario. Son vitales para accesos Cross-Account pero no restringidos a ellos. 📝 Ejemplo: Tienes un Bucket S3 de logs centralizados.

Acción: Colocas una Bucket Policy que dice: "Permitir s3:PutObject a la cuenta de Producción (Account B)".
Resultado: La cuenta B puede escribir logs ahí sin tener un usuario creado en tu cuenta de logs.

3️⃣ Service Control Policies (SCPs)

👉 Las "Reglas de la Casa" (Límites de Identidad, popularmente guardrail o barandilla de seguridad) Aquí es donde muchos se confunden. Las SCPs NO dan permisos. Solo definen el máximo permiso posible. Si la SCP dice "No", no importa si tienes AdminAccess, es un "No". 📝 Ejemplo: Seguridad Compliance.

Acción: Aplicas una SCP en la raíz de tu Organización que niega ec2:RunInstances en cualquier región que no sea us-east-1.

- Resultado: Aunque seas Admin, si intentas levantar un servidor en Tokyo, fallará.

Resource Control Policies (RCPs)

👉 El "Perímetro de Datos" (Límites de Recurso) Funcionan como las SCPs, pero enfocadas en restringir el acceso a tus recursos, sin importar quién sea el que llama (incluso si es externo). 📝 Ejemplo: Data Perimeter estricto.

Acción: Creas una RCP que dice: "Nuestros Buckets S3 solo pueden ser accedidos por Principals que pertenezcan a nuestra Organización (PrincipalOrgID)".
Resultado: Si alguien configura por error un Bucket como "Público" o intenta darle acceso a una cuenta externa de un proveedor, la RCP lo bloquea automáticamente. Ideal para prevenir ataques de exfiltración de datos

Resumen

Tipo de Política	Se aplica a...	Función Principal	¿Cuándo usarlo?
IAM Policy	Usuario/Rol/Grupo	Otorgar permisos	Para otorgar permisos a usuarios, grupos o roles
Resource Policy	S3, SQS, etc.	Otorgar acceso (incluso externo)	Para definir quien puede acceder a un recurso
SCP	Cuenta AWS (excepto cuenta administradora de la organización), Unidades Org	Restringir permisos máximos (Identidad)	Para establecer límites máximos sobre las identidades
RCP	Recursos de la Org, excepto recursos de la cuenta administradora de la organización	Restringir acceso máximo (Recurso)	Para establecer límites máximos sobre sobre quien accede a tus datos

🔥 Bonus: Perspectiva Red Team

Entender IAM, SCPs y RCPs no solo es vital para proteger tu cuenta y organización, también es un componente clave para reducir la superficie de ataque.

Por ejemplo:

Escenario de Red Team: un atacante intenta asumir roles o crear usuarios para escalar privilegios.
SCPs bloquean el movimiento lateral: aunque tenga AdminAccess en una cuenta hija, no podrá ejecutar acciones prohibidas por la SCP a nivel de Organización (ej: organizations:LeaveOrganization, iam:CreateUser).
RCPs evitan exfiltración de datos: un bucket mal configurado no permite accesos de cuentas externas aunque el atacante tenga privilegios en otra parte.
Conclusión: conocer y aplicar correctamente estas políticas es como poner murallas antes de que alguien llegue al nucleo de tu entorno.

💡 Pregunta de reflexión: ¿por qué es un riesgo crítico desplegar recursos productivos o mantener usuarios activos operando directamente en la cuenta administradora de la organización o también llamado Payer Account?

🔜 En el próximo post: Profundizaremos en las SCPs, cuales son las SCPs mas relevantes que toda cuenta debería tener y cómo configurarlas correctamente para dormir tranquilos.