Parte: 10 — Seguridad en la nube y contenedores · Fuente: AWS IAM User Guide y AWS Well-Architected: Identity and Access Management ⏱️ Duración estimada: 120 min · Nivel: Intermedio
Dominar la gestión de identidad y acceso (IAM) como el verdadero perímetro de la nube: cómo se modelan usuarios, grupos, roles y políticas; cómo se evalúa una petición; y cómo aplicar privilegio mínimo evitando las rutas de escalada de privilegios que buscan los atacantes.
Al finalizar, el alumno podrá:
iam:PassRole, iam:CreatePolicyVersion, etc.).| # | Tema | Por qué importa |
|---|---|---|
| 1 | Principals: usuarios, grupos, roles | Base del modelo de acceso |
| 2 | Políticas de identidad vs de recurso | Definen permisos desde dos lados |
| 3 | Roles asumibles y STS | Credenciales temporales en lugar de claves largas |
| 4 | Lógica de evaluación de permisos | Predecir si una acción se permite o deniega |
| 5 | Privilegio mínimo y límites de permisos | Reducen el blast radius |
| 6 | Escalada de privilegios IAM | Rutas que convierten un permiso menor en admin |
| 7 | Federación y SSO | Centralizar identidades corporativas |
Una decisión IAM no es «el usuario tiene un rol». Es la evaluación de una solicitud concreta: principal y sesión, acción, recurso, contexto, políticas aplicables y límites superiores. Esta clase usa AWS para estudiar la lógica explícita y después traduce el razonamiento a Azure RBAC y Google Cloud IAM.
El diagrama enseña que la credencial autentica y la política autoriza. En AWS una solicitud parte de denegación implícita; necesita un Allow aplicable y un Deny explícito prevalece. Sin embargo, la interacción exacta entre políticas de identidad, recurso, boundaries, SCP y sesiones cambia por tipo de principal y acceso cross-account. Memorizar «allow menos deny» no basta: se debe usar la documentación y el simulador con el contexto real.
Las personas deberían federarse desde un proveedor corporativo y obtener sesiones temporales con MFA o controles adaptativos. Las cargas usan identidades de servicio o roles vinculados a la plataforma. Una clave estática descargada crea un secreto que debe almacenarse, rotarse y atribuirse; una sesión temporal reduce duración, pero todavía puede ser robada y usada hasta expirar o ser revocada por mecanismos disponibles.
El permiso mínimo no se diseña una sola vez. Se parte de acciones necesarias, se acotan recursos, se agregan condiciones de región, red, etiquetas o servicio y se prueban casos permitidos y denegados. Luego se usan logs de acceso para retirar permisos no utilizados. Un Resource: "*" puede ser requerido por una API sin soporte granular, pero debe documentarse y compensarse; un wildcard no es automáticamente una vulnerabilidad ni automáticamente aceptable.
iam:PassRole no equivale por sí solo a administrador. Se vuelve peligroso cuando el principal puede pasarlo a un servicio que ejecutará acciones bajo un rol más potente y puede controlar esa carga. De modo similar, editar una trust policy, crear versiones de funciones o enlazar roles puede producir nuevas rutas. El análisis construye un grafo de relaciones y valida una cadena completa, no una lista de permisos «peligrosos» aislados.
Effect, Action, Resource y Condition. Clave: define permisos de forma declarativa.sts:AssumeRole: acción que cambia de identidad. Clave: base de la federación y de muchas rutas de escalada.PassRoleUna identidad puede crear funciones y pasar un rol con lectura de un bucket sensible. Si también puede definir el código, invocar la función y recuperar su salida, existe una ruta hacia esos datos. Si la política de confianza no admite Lambda, PassRole está condicionado a otro servicio o la función no puede devolver contenido, la cadena cambia.
La corrección no es eliminar todo PassRole: se restringe el ARN del rol, iam:PassedToService, acciones de creación y destino de salida; se separan roles de despliegue y ejecución. Las pruebas incluyen una operación legítima que debe funcionar y otra con un rol no autorizado que debe fallar.
Dominas la clase cuando puedes explicar una decisión con principal, sesión, acción, recurso, contexto y cada política aplicable; produces pruebas allow/deny; y demuestras o refutas una ruta de escalada completa sin llamar «admin» a un permiso aislado.
aws, az, gcloud) con una cuenta de laboratorio.# Enumerar usuarios y sus claves de acceso (AWS)
aws iam list-users
aws iam list-access-keys --user-name lab-user
# Simular si una acción está permitida
aws iam simulate-principal-policy \
--policy-source-arn arn:aws:iam::123456789012:user/lab-user \
--action-names s3:DeleteBucket
⚠️ Contenido con componente ofensivo. Ejecuta todo exclusivamente en tu propia cuenta de laboratorio.
lab-user sin permisos y un rol lab-admin-role con AdministratorAccess.lab-user una política que solo permita iam:PassRole y ec2:RunInstances.pmapper graph create y luego pmapper query "who can do iam:* with *". Observa cómo el usuario aparente-mínimo puede escalar a admin lanzando una instancia con el rol admin.lab-admin-role y obtén sus credenciales temporales desde el servicio de metadatos.lab-user y añade una Condition que restrinja qué roles puede pasar (iam:PassedToService). Repite el ataque y verifica que ahora falla.prowler aws -c iam_* y revisa hallazgos de claves inactivas y políticas con comodín *.Deny explícito y un Allow simultáneos.Condition que exija MFA para acciones destructivas.Parte de una política demasiado amplia ("Action": "*", "Resource": "*") y refactorízala a
privilegio mínimo para un caso de uso concreto (una app que lee de una tabla y escribe en una cola).
Criterio de aceptación: la política final solo incluye las acciones estrictamente necesarias sobre
los ARNs concretos, incluye al menos una Condition, y simulate-principal-policy confirma que las
acciones legítimas se permiten y una acción no relacionada se deniega.
| Síntoma / mensaje | Causa y cómo arreglar |
|---|---|
AccessDenied inesperado |
SCP u organización deniega arriba; revisa políticas heredadas y deny explícitos. |
Política con "Action": "*" en producción |
Privilegio excesivo; refactoriza a acciones concretas y usa Access Analyzer. |
| Claves de acceso en el código | Credenciales estáticas filtrables; migra a roles y rota/revoca de inmediato. |
iam:PassRole sin condición |
Ruta de escalada; restringe con Condition sobre servicio y rol destino. |
| Usuarios inactivos con claves activas | Falta de revisión; deshabilita credenciales sin uso > 90 días. |
❓ ¿Rol o usuario para una aplicación? Prefiere identidad de carga o rol temporal cuando la plataforma lo soporte. Reduce credenciales estáticas, pero todavía debes limitar permisos, proteger la carga y comprender expiración y revocación de sesiones.
❓ ¿Qué pasa si una política de identidad permite algo y una de recurso lo deniega?
Un Deny explícito aplicable prevalece sobre un Allow; sin Allow aplicable existe denegación implícita. La política relevante cambia por tipo de principal, recurso, sesión y acceso cross-account.
❓ ¿Cómo aplico privilegio mínimo sin frenar al equipo? Empieza permisivo pero mide: usa Access Analyzer/policy usage para ver qué se usa realmente y recorta lo no utilizado. Itera en vez de adivinar.
Clase 221 — Fundamentos de seguridad en la nube y responsabilidad compartida