Usuarios, grupos, roles y políticas de IAM: mínimo privilegio, políticas basadas en identidad vs basadas en recursos y lógica de evaluación de políticas

AWS Identity and Access Management (IAM) decide quién puede hacer qué en una cuenta de AWS. Cada llamada a la API, ya venga de la consola, de la interfaz de línea de comandos (CLI), de un kit de desarrollo de software (SDK) o de otro servicio de AWS, es verificada por IAM antes de que ocurra cualquier cosa. Dominar IAM es la base de toda arquitectura segura en el examen Solutions Architect Associate (SAA-C03), y muchas preguntas que parecen tratar sobre S3, EC2 o Lambda en realidad evalúan si entiendes las identidades y las políticas. Hay tres tipos de identidad que debes conocer. Un usuario de IAM (IAM user) es una identidad de largo plazo para una persona o aplicación, con una contraseña de consola opcional y claves de acceso (access keys) opcionales para la API. Un grupo de IAM (IAM group) es un conjunto de usuarios que comparten permisos; los grupos no pueden iniciar sesión, no pueden anidarse dentro de otros grupos y no pueden nombrarse como principal en una política. Un rol de IAM (IAM role) es una identidad sin credenciales de largo plazo: un principal de confianza (un usuario, un servicio de AWS como EC2 o Lambda, otra cuenta o un usuario federado) lo asume y recibe credenciales temporales de AWS Security Token Service (STS). Para las cargas de trabajo, los roles son casi siempre la respuesta correcta, porque no hay claves que se puedan filtrar ni que haya que rotar. Una instancia EC2 obtiene un rol mediante un perfil de instancia (instance profile), y una función Lambda obtiene uno como su rol de ejecución (execution role). El usuario raíz (root user) de la cuenta, creado junto con ella, puede hacer casi todo y debe resguardarse con autenticación multifactor (MFA) y usarse solo para las pocas tareas que lo requieren.

Los permisos provienen de políticas, que son documentos JSON formados por declaraciones (statements). Cada declaración tiene un Effect (Allow o Deny), una Action (por ejemplo s3:GetObject), un Resource (un ARN, el Amazon Resource Name) y bloques Condition opcionales que usan claves como aws:SourceIp o aws:MultiFactorAuthPresent. El mínimo privilegio (least privilege) significa otorgar solo las acciones y los recursos que una tarea necesita, y ampliarlos únicamente cuando exista una necesidad comprobada. Las políticas administradas por AWS (AWS managed policies) son puntos de partida cómodos, pero suelen ser amplias; las políticas administradas por el cliente (customer managed policies) te permiten acotar el alcance y reutilizar el resultado; las políticas en línea (inline policies) están incrustadas en una sola identidad y se eliminan con ella.

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": ["s3:GetObject"],
    "Resource": "arn:aws:s3:::reports-bucket/*"
  }]
}

Las políticas basadas en identidad (identity-based policies) se adjuntan a usuarios, grupos y roles, e indican lo que esa identidad puede hacer. Las políticas basadas en recursos (resource-based policies) se adjuntan a un recurso, como una bucket policy de S3, una política de cola de SQS o una key policy de KMS, e incluyen un elemento Principal que nombra quién puede acceder. Las políticas basadas en recursos son la forma de dar acceso a otra cuenta sin que esa cuenta tenga que asumir un rol. La política de confianza (trust policy) de un rol es en sí misma una política basada en recursos: indica quién puede asumir el rol, mientras que las políticas de permisos del rol indican lo que el rol puede hacer una vez asumido.

La evaluación de políticas sigue una lógica fija. Toda solicitud comienza como una denegación implícita (implicit deny). AWS reúne todas las políticas aplicables: service control policies (SCPs) de AWS Organizations, políticas basadas en recursos, límites de permisos (permissions boundaries), políticas de sesión y políticas basadas en identidad. Si alguna contiene un Deny explícito que coincida, la solicitud se deniega, sin más. De lo contrario, la solicitud necesita un Allow, y cada capa de protección que aplique (SCPs, un permissions boundary, una política de sesión) también debe permitirla. Dentro de una misma cuenta, un Allow en la política de identidad o en la política del recurso suele ser suficiente; entre cuentas, tanto la política de identidad del llamante como la política del recurso deben permitir la acción. Un permissions boundary es una política administrada que se establece en un usuario o rol y que limita los permisos máximos que sus políticas de identidad pueden otorgar; por sí mismo no otorga nada. Los boundaries permiten que los desarrolladores creen roles para sus aplicaciones sin poder crear un rol con más poder del que ellos mismos tienen. El simulador de políticas de IAM (IAM policy simulator) e IAM Access Analyzer te ayudan a probar políticas y a encontrar accesos externos no deseados.

Veamos un ejemplo práctico. Una aplicación en EC2 necesita leer un bucket de S3, y un desarrollador propone pegar una clave de acceso en un archivo de configuración. En su lugar, el arquitecto crea un rol cuya trust policy permite ec2.amazonaws.com, le adjunta una política administrada por el cliente que permite solo s3:GetObject sobre los objetos de ese bucket y asocia el rol a la instancia mediante un instance profile. El SDK en la instancia encuentra automáticamente las credenciales temporales a través del servicio de metadatos de la instancia (instance metadata service) y las renueva antes de que caduquen. Más adelante, el equipo de seguridad agrega una bucket policy que deniega explícitamente todo acceso a menos que la solicitud use TLS; la aplicación sigue funcionando porque sus solicitudes van cifradas, y cualquier solicitud HTTP sin cifrar se rechaza sin importar el Allow del rol.

Errores comunes: guardar claves de acceso en instancias o en el código en lugar de usar roles; pensar que un permissions boundary o una SCP otorgan acceso (solo lo limitan); olvidar que un Deny explícito gana sobre cualquier Allow; intentar poner un grupo en el elemento Principal de una política; y usar el usuario raíz para el trabajo diario. Otra trampa es suponer que una política administrada por AWS aplica el mínimo privilegio; es un punto de partida que debes acotar una vez que sepas qué llama realmente la carga de trabajo.

Las preguntas del examen suelen describir un síntoma o un objetivo. 'Acceso denegado a pesar de un Allow' apunta a un Deny explícito, una SCP o un permissions boundary. 'Dar a una instancia EC2 o a una función Lambda acceso a un servicio' apunta a un rol de IAM, nunca a claves almacenadas. 'Permitir que los desarrolladores creen roles, pero limitar lo que esos roles pueden hacer' apunta a un permissions boundary, y 'dar a otra cuenta acceso a un bucket sin un rol' apunta a una bucket policy basada en recursos.

Términos clave

Rol de IAM (IAM role)

Una identidad con permisos pero sin credenciales de largo plazo, que un principal de confianza asume para recibir credenciales temporales.

Grupo de IAM (IAM group)

Un conjunto de usuarios de IAM que comparten las políticas adjuntas; no puede iniciar sesión, anidarse ni ser principal de una política.

Política basada en identidad (identity-based policy)

Una política adjunta a un usuario, grupo o rol que indica lo que esa identidad puede hacer.

Política basada en recursos (resource-based policy)

Una política adjunta a un recurso, como una bucket policy de S3, que nombra a los principales autorizados a acceder a él.

Deny explícito (explicit deny)

Una declaración Deny que coincide con una solicitud; anula cualquier Allow de cualquier política.

Límite de permisos (permissions boundary)

Una política administrada que establece los permisos máximos que puede tener un usuario o rol de IAM, sin otorgar ninguno por sí misma.

Perfil de instancia (instance profile)

El contenedor que pasa un rol de IAM a una instancia EC2 para que el software que corre en ella reciba credenciales temporales.

Comprueba lo que sabes