El rol de una instancia EC2 está configurado como `*:*` (administrador total) «para que funcione». ¿Por qué es peligroso y qué haces?
Respuesta breve
Un rol de instancia con privilegios excesivos convierte cualquier fallo a nivel de aplicación —especialmente un SSRF que alcanza el servicio de metadatos de la instancia— en una toma de control total de la cuenta, porque el atacante hereda las credenciales del rol. Sustituye el comodín por las acciones mínimas y los ARN de recursos que la carga de trabajo usa realmente, y exige IMDSv2 para endurecer el endpoint de metadatos. Una VPC no restringe el IAM en absoluto. Una sola regla de denegación es un juego del topo que deja todo lo demás permitido. Un balanceador de carga es irrelevante para el alcance del daño de la credencial.
Este escenario comprueba si un ingeniero sénior entiende el alcance del daño: la pregunta no es si la instancia es accesible, sino qué obtiene un atacante en cuanto consigue cualquier punto de apoyo. Un rol *:* significa que un solo error equivale a toda la cuenta.
Por qué el mínimo privilegio es la respuesta
Las credenciales de un rol de instancia están disponibles para cualquier cosa que se ejecute en la instancia (o que pueda forzarla a actuar). El camino clásico es el SSRF: una aplicación a la que se puede engañar para que haga una petición a http://169.254.169.254/... devolverá las credenciales temporales del rol. Si el rol es administrador, el atacante controla ahora toda la cuenta: leer cada bucket, crear usuarios, desactivar el registro y pivotar. Reducir el rol a las acciones y ARN de recursos específicos que usa la carga de trabajo hace que incluso un SSRF perfecto solo otorgue lo que esa carga ya podía hacer. Exigir IMDSv2 (basado en token, con límite de saltos) hace que el endpoint de metadatos sea mucho más difícil de alcanzar vía SSRF en primer lugar.
Por qué fallan los distractores
- «Está bien mientras esté en una VPC.» Una VPC es aislamiento de red; no restringe el IAM. Las credenciales robadas funcionan contra los endpoints públicos de la API de AWS sin importar dónde esté la instancia.
- Añadir una regla de denegación. Denegar una sola acción riesgosa deja miles de otras acciones privilegiadas permitidas. El mínimo privilegio es una lista de permitidos, no un juego del topo.
- Ponerla detrás de un balanceador de carga. Un balanceador cambia cómo llega el tráfico a la app; no cambia nada sobre lo que puede hacer la credencial filtrada.
Qué buscan los entrevistadores
Nombrar el SSRF + el servicio de metadatos como la vía de explotación realista, insistir en un mínimo privilegio basado en lista de permitidos en lugar de parches de denegación, y añadir IMDSv2 como defensa en profundidad. Un candidato sénior también menciona cómo derivar la política mínima de forma segura, por ejemplo ejecutando en una cuenta no productiva con IAM Access Analyzer o generación de políticas guiada por CloudTrail antes de ajustar.
Posibles preguntas de seguimiento
- ¿Cómo exfiltra exactamente un SSRF contra el servicio de metadatos las credenciales del rol, y cómo rompe IMDSv2 esa cadena?
- ¿Cómo derivarías la política mínima sin romper la carga de trabajo?
- ¿Cuál es la diferencia de alcance del daño entre un rol con privilegios excesivos y un usuario con privilegios excesivos?