AWS IAM explicado:

políticas, roles y los errores que abren un bucket al mundo

Seguridad en la nube  |  unfantasmaenelsistema.com

Casi todas las brechas graves en la nube que llegan a la prensa tienen la misma raíz: no un fallo de AWS, sino una configuración de permisos hecha con prisa. Un rol de confianza demasiado abierto, una política con un comodín de más, una clave de acceso olvidada dentro de un repositorio. IAM (Identity and Access Management) es el servicio que decide quién puede hacer qué sobre cada recurso de una cuenta, y entenderlo bien es la diferencia entre una infraestructura razonablemente sólida y un incidente esperando a ocurrir.

Este artículo explica el modelo de IAM desde los cimientos: las cuatro piezas básicas, cómo se escribe una política, cómo se evalúa una petición cuando hay reglas que se contradicen, y el catálogo de errores clásicos que aparecen una y otra vez en las auditorías. El enfoque es defensivo: cómo revisar tu propia cuenta y cerrar los huecos antes de que lo haga otro.

1. Las cuatro piezas: usuarios, grupos, roles y políticas

IAM se construye sobre cuatro objetos. Confundir sus papeles es el primer error, así que conviene fijarlos antes de seguir.

1.1 Identidades: usuarios, grupos y roles

• Usuario IAM: una identidad permanente con credenciales de larga vida (contraseña para la consola, claves de acceso para la API). Pensado para personas o sistemas fuera de AWS que necesitan un acceso estable
• Grupo: un contenedor de usuarios al que se asignan políticas. No es una identidad — nada «asume» un grupo — solo una forma cómoda de dar los mismos permisos a varias personas
• Rol: una identidad sin credenciales fijas que cualquier principal autorizado puede asumir temporalmente. Al asumirlo, AWS entrega credenciales que caducan (de 15 minutos a 12 horas). Es el mecanismo recomendado para servicios, para acceso entre cuentas y, con IAM Identity Center, también para personas

1.2 Políticas: el documento que concede o niega permisos

Una política es un documento JSON con una lista de permisos. Por sí sola no hace nada: hay que adjuntarla a una identidad o a un recurso. Distinguimos dos grandes familias:

• Basadas en identidad (identity-based): se adjuntan a un usuario, grupo o rol y dicen qué puede hacer esa identidad. Pueden ser gestionadas por AWS, gestionadas por el cliente, o inline (incrustadas en una sola identidad)
• Basadas en recurso (resource-based): se adjuntan directamente al recurso (un bucket S3, una cola SQS, una función Lambda) y dicen quién puede actuar sobre él. Incluyen un elemento Principal que las de identidad no tienen

2. Anatomía de una política IAM

Toda política sigue la misma estructura: una o más sentencias (Statement), y cada sentencia combina un efecto, unas acciones, unos recursos y, opcionalmente, unas condiciones.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "LecturaSoloDeUnBucket",
      "Effect": "Allow",
      "Action": ["s3:GetObject", "s3:ListBucket"],
      "Resource": [
        "arn:aws:s3:::mi-bucket-informes",
        "arn:aws:s3:::mi-bucket-informes/*"
      ],
      "Condition": {
        "IpAddress": { "aws:SourceIp": "203.0.113.0/24" }
      }
    }
  ]
}

• Effect: `Allow` o `Deny`. No hay término medio
• Action: operaciones del API, con el formato `servicio:Operación`. Admite comodines (`s3:Get*`), pero cada comodín de más amplía la superficie
• Resource: el ARN o ARNs sobre los que aplica. `»*»` significa «cualquier recurso» y es la fuente número uno de sobre-permisos
• Condition: restricciones adicionales (IP de origen, MFA presente, etiqueta del recurso, hora del día). Es la herramienta más infrautilizada de IAM y la que más ayuda al mínimo privilegio

3. Cómo evalúa AWS una petición

Cuando una identidad hace una llamada al API, AWS reúne todas las políticas que aplican y las resuelve en un orden fijo. La regla mental corta es: un deny explícito siempre gana, y sin un allow explícito la respuesta es no.

Las SCP y las permissions boundaries no conceden permisos: solo ponen un techo. Una SCP que permite `s3:*` no le da acceso a S3 a nadie; simplemente no se lo quita. El acceso real sigue viniendo de una política de identidad o de recurso.

4. El rol de instancia y por qué el SSRF lo pone en peligro

Cuando una máquina EC2, un contenedor ECS o una función Lambda necesita hablar con otros servicios de AWS, no se le ponen claves de acceso: se le asigna un rol. El entorno de ejecución obtiene credenciales temporales de ese rol a través del servicio de metadatos de la instancia (IMDS), accesible desde dentro en la dirección `169.254.169.254`.

El problema aparece cuando una aplicación en esa máquina tiene una vulnerabilidad de tipo SSRF (Server-Side Request Forgery): el atacante consigue que el servidor haga una petición a la URL que él elige. Si esa URL es la del endpoint de metadatos, la respuesta contiene las credenciales temporales del rol de instancia, y a partir de ahí el atacante actúa con los permisos de ese rol desde fuera. Es exactamente la mecánica de la brecha de Capital One en 2019. Lo cubrimos a fondo en nuestro artículo SSRF: cómo una petición del servidor acaba leyendo las credenciales de tu nube.

• Exige IMDSv2 (orientado a sesión con token) en todas las instancias: obliga a un PUT previo con cabecera propia, lo que rompe la mayoría de SSRF ingenuos
• Reduce el hop limit de IMDS a 1 para que un contenedor no alcance el endpoint del nodo
• Da al rol de instancia solo los permisos que la aplicación usa de verdad, para que robar sus credenciales sirva de poco

5. Los errores que abren un bucket al mundo

Estos patrones se repiten en auditoría tras auditoría. Ninguno es exótico; todos se detectan con las herramientas de la sección siguiente.

6. Auditar tu propia cuenta

AWS y el ecosistema open source ofrecen herramientas que revisan una cuenta completa en minutos. Todas se ejecutan con credenciales de solo lectura sobre tu propia infraestructura.

# Informe de credenciales de toda la cuenta (usuarios, claves, MFA, ultimo uso)
aws iam generate-credential-report
aws iam get-credential-report --query Content --output text | base64 -d > report.csv
 
# Cuando se uso por ultima vez cada servicio para un rol concreto
aws iam generate-service-last-accessed-details --arn arn:aws:iam::111122223333:role/mi-rol
 
# Auditoria completa de solo lectura con Prowler
prowler aws --profile auditoria --output-formats html csv

7. Mínimo privilegio en la práctica

«Mínimo privilegio» suena bien y se aplica mal. En la práctica es un proceso, no un estado:

• Empieza permisivo solo en desarrollo, registra el uso real con CloudTrail, y usa Access Analyzer para generar la política ajustada antes de pasar a producción
• Prefiere roles a usuarios, y credenciales temporales a claves de larga vida, siempre que se pueda
• Usa Condition para acotar: `aws:MultiFactorAuthPresent`, `aws:SourceIp`, `aws:PrincipalTag`, `s3:prefix`. Una política con condiciones vale por diez sin ellas
• Separa entornos en cuentas distintas bajo AWS Organizations y pon las barreras duras (regiones permitidas, prohibir desactivar CloudTrail) como SCP
• Revisa trimestralmente: informe de credenciales, accesos sin usar, políticas con comodines, trust policies abiertas

Conclusión

IAM no es complicado por su tecnología, sino por su acumulación: cada permiso que se concede y no se retira, cada comodín que se añade «por si acaso», cada clave que se copia a un sitio nuevo. El modelo en sí es sencillo — identidades, políticas, un orden de evaluación fijo donde el deny gana — y cabe en una tarde de lectura.

La disciplina que marca la diferencia es aburrida y constante: roles en vez de claves, condiciones en las políticas, Block Public Access activado de serie, y una revisión periódica que caduque lo que ya nadie usa. Las herramientas de auditoría son gratuitas o open source y tardan minutos. El bucket abierto al mundo casi nunca es un ataque sofisticado: es una casilla que nadie volvió a mirar.

unfantasmaenelsistema.com | Seguridad, sistemas y todo lo que no debería funcionar (pero funciona)