¿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.
Top comments (0)