¿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.
