Llegamos a uno de los servicios más importantes de toda la nube: IAM. Controla quién puede hacer qué en tu cuenta de AWS. Si la VPC era la seguridad de tu red, IAM es la seguridad de tus identidades y permisos. Dominar sus cuatro conceptos básicos —usuarios, grupos, roles y políticas— es imprescindible para trabajar con AWS de forma segura.

IAM significa Identity and Access Management (Gestión de Identidades y Accesos). Es el servicio que gestiona:

• Quién puede acceder a tu cuenta de AWS (identidades).
• Qué puede hacer cada uno (permisos).

Dos datos importantes para empezar:

• IAM es gratuito.
• IAM es global: no pertenece a una región concreta; tus usuarios y permisos valen en toda tu cuenta.

Analogía general: IAM es el sistema de seguridad y tarjetas de acceso de un edificio de oficinas. Decide quién tiene tarjeta, a qué plantas puede entrar cada uno y qué puertas puede abrir. Sin IAM bien configurado, o nadie puede trabajar, o cualquiera puede entrar donde quiera (peligroso).

Un usuario IAM representa a una persona concreta (o a veces una aplicación) que necesita acceder a AWS. Tiene sus propias credenciales:

• Usuario y contraseña para entrar a la consola web.
• Claves de acceso (access keys) para usar la línea de comandos o programar contra AWS.

Analogía: Un usuario IAM es como la tarjeta de empleado de una persona. Es individual e intransferible: cada empleado tiene la suya.

Buena práctica: cada persona debe tener su propio usuario. Nunca compartáis un usuario entre varias personas, porque entonces no sabrías quién hizo qué (se pierde la trazabilidad).

Un grupo es un conjunto de usuarios que comparten los mismos permisos. En lugar de dar permisos uno a uno a cada persona, los das al grupo y metes a las personas en él.

Analogía: Un grupo es como un departamento. En vez de darle llaves a cada persona del departamento de contabilidad por separado, decides «todos los de contabilidad pueden entrar a la sala de finanzas» y luego añades o quitas personas del departamento.

Ejemplo: Creas un grupo Desarrolladores con permisos para gestionar servidores de prueba. Cuando entra un desarrollador nuevo, lo añades al grupo y hereda todos los permisos automáticamente. Cuando se va, lo quitas y pierde el acceso. Mucho más fácil que gestionar permisos persona a persona.

Los grupos no tienen credenciales propias; solo agrupan usuarios. Y un usuario puede estar en varios grupos a la vez.

Un rol es una identidad con permisos, pero sin credenciales fijas: no pertenece a una persona concreta, sino que se asume temporalmente cuando se necesita. Lo asumen tanto personas como, sobre todo, servicios y aplicaciones.

Analogía: Un rol es como un chaleco de "visitante autorizado" o un uniforme que te pones temporalmente para hacer una tarea. Mientras lo llevas, tienes ciertos permisos; cuando terminas, te lo quitas. No es tuyo en propiedad: lo usas mientras lo necesitas.

Este es probablemente el concepto que más cuesta al principio, pero es el más importante para la seguridad. Su uso típico:

Ejemplo clave: Tienes una instancia EC2 que necesita leer archivos de un bucket S3. ¿Cómo le das permiso? Mala idea: meter unas claves de acceso dentro del servidor (si alguien lo compromete, roba las claves). Buena idea: asignar un rol a la instancia EC2. La instancia «asume» el rol y obtiene permisos temporales para leer S3, sin que haya ninguna clave guardada en ningún sitio. AWS rota esas credenciales automáticamente.

Los roles son la base de la seguridad moderna en AWS. Los veremos más a fondo en el subcapítulo 7.4 (credenciales temporales) y son protagonistas en muchos capítulos posteriores.

Una política es un documento (en formato JSON) que define exactamente qué se permite o se deniega. Las políticas son las que de verdad contienen los permisos; los usuarios, grupos y roles simplemente tienen políticas adjuntas.

Analogía: Una política es la lista detallada de permisos escrita en un papel: «puede abrir las puertas A y B, pero no la C; puede leer los documentos del archivo, pero no modificarlos».

Una política responde a cuatro preguntas:

• Effect: ¿permitir o denegar?
• Action: ¿qué acción? (leer un bucket, lanzar una instancia…)
• Resource: ¿sobre qué recurso?
• (Opcional) Condition: ¿bajo qué condiciones?

Veremos las políticas en detalle en el subcapítulo 7.3.

• Las políticas contienen los permisos.
• Se adjuntan a usuarios (personas), grupos (conjuntos de usuarios) o roles (identidades temporales).
• Los grupos facilitan gestionar permisos de muchas personas a la vez.
• Los roles dan permisos temporales sin credenciales fijas (ideales para servicios).

Cuando creas una cuenta de AWS, obtienes el usuario root (el correo con el que te registraste). Este usuario tiene poder absoluto sobre todo, incluida la facturación. Es tan poderoso que es peligroso usarlo a diario.

Regla de oro: No uses el usuario root salvo para las poquísimas tareas que lo exigen. Crea un usuario IAM normal (con permisos de administrador si hace falta) para tu trabajo diario, y protege el root con MFA (subcapítulo 7.4). Lo veremos más en el subcapítulo 7.5.

• IAM controla quién puede hacer qué en tu cuenta. Es gratuito y global.
• Usuario: una identidad para una persona o app (con sus credenciales). Uno por persona, nunca compartido.
• Grupo: conjunto de usuarios que comparten permisos. Facilita la gestión.
• Rol: identidad con permisos temporales que se asume (ideal para servicios como EC2, evita guardar claves).
• Política: documento JSON que define los permisos y se adjunta a usuarios, grupos o roles.
• No uses el usuario root para el día a día.

En el siguiente subcapítulo veremos el principio más importante de toda la seguridad en la nube: el mínimo privilegio.