IAM: usuarios, grupos, roles y políticas

AWS Identity and Access Management (IAM) responde dos preguntas en cada llamada a AWS: quién eres (autenticación) y qué puedes hacer (autorización). Es un servicio global y toca todo lo demás: si un permiso no está en IAM, la acción no ocurre.

La regla base es simple: todo está negado por defecto. Una identidad nueva no puede hacer nada hasta que una política le dé permiso.

Las cuatro piezas

• 

  Usuario de IAM

  Una identidad con credenciales de larga duración: contraseña para la consola o llaves de acceso para la CLI. Hoy se recomienda solo para casos que no pueden usar otra cosa.
• 

  Grupo

  Una colección de usuarios que comparten políticas. Simplifica la administración. Un grupo no se puede anidar ni usar como principal en una política.
• 

  Rol

  Una identidad sin contraseña ni llaves fijas. Se asume y entrega credenciales temporales. La usan personas, servicios de AWS (una EC2, una Lambda) y otras cuentas.
• 

  Política

  Un documento JSON que dice qué acciones se permiten o niegan, sobre qué recursos y bajo qué condiciones.

Leer una política JSON

Una política tiene una o más declaraciones (Statement). Cada una responde: ¿permite o niega (Effect)? ¿qué acciones (Action)? ¿sobre qué recursos (Resource)? ¿bajo qué condiciones (Condition)?

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "LeerFacturas",
      "Effect": "Allow",
      "Action": ["s3:GetObject", "s3:ListBucket"],
      "Resource": [
        "arn:aws:s3:::facturas-acme",
        "arn:aws:s3:::facturas-acme/*"
      ],
      "Condition": {
        "Bool": { "aws:SecureTransport": "true" }
      }
    },
    {
      "Sid": "NuncaBorrar",
      "Effect": "Deny",
      "Action": "s3:DeleteObject",
      "Resource": "arn:aws:s3:::facturas-acme/*"
    }
  ]
}

En español: quien tenga esta política puede listar el bucket facturas-acme y leer sus objetos, solo por HTTPS. Y nunca puede borrar objetos de ese bucket, aunque otra política se lo permita.

Así decide AWS cada solicitud:

1. 1

   Por defecto, negado

   Si ninguna política dice nada, la respuesta es no.
2. 2

   Una negación explícita gana siempre

   Si alguna política aplicable tiene Deny para esa acción, la respuesta es no. No importa cuántos Allow haya.
3. 3

   Si hay un permiso explícito, sí

   Sin negaciones y con al menos un Allow que coincida, la acción se permite (dentro de los límites de otras capas, como las SCP de una organización).

Tipos de políticas

Hay dos formas de pegar una política. Las basadas en identidad se adjuntan a un usuario, grupo o rol: dicen qué puede hacer esa identidad. Las basadas en recursos se adjuntan al recurso, como una política de bucket de S3 o de cola de SQS: dicen quién puede usar ese recurso, e incluyen un campo Principal.

Menor privilegio y credenciales temporales

El principio de menor privilegio dice: da solo los permisos necesarios para la tarea, sobre los recursos necesarios, por el tiempo necesario. Empieza con poco y agrega cuando haga falta. "Action": "*" sobre "Resource": "*" es el carné que abre todo: úsalo solo para administradores.

Si todavía tienes usuarios de IAM con contraseña, define una política de contraseñas de la cuenta (longitud mínima, tipos de caracteres, vencimiento, no reutilizar) y exige MFA.

Revisar quién tiene qué

• IAM Access Analyzer: señala recursos compartidos con identidades externas a tu cuenta u organización, encuentra permisos que no se usan, valida políticas y puede generar una política a partir de la actividad real registrada en CloudTrail.
• Informe de credenciales: un CSV con todos los usuarios de la cuenta y el estado de sus contraseñas, llaves y MFA.
• Último acceso: muestra cuándo una identidad usó cada servicio por última vez. Lo que nunca se usa, se quita.

Cuando la empresa crece, crear usuarios de IAM uno por uno no escala. El siguiente paso es Acceso para equipos: Identity Center y federación.