AWS IAM: Guía completa de Identity and Access Management para principiantes

AWS IAM: Gestiona quién accede a qué en tu nube
Guía completa para entender Identity and Access Management
AWS Cloud Security  •  Nivel: Principiante-Intermedio 

¿Qué es AWS IAM y por qué debería importarte?
 
Imagina que tienes una empresa con cien empleados y todos comparten la misma llave del edificio. Cualquiera puede entrar a cualquier sala, acceder a cualquier archivo, tocar cualquier máquina. Caótico, ¿verdad? Eso es exactamente lo que ocurriría en AWS si no existiese IAM. >
 
AWS Identity and Access Management (IAM) es el servicio que te permite definir con precisión quirúrgica quién puede hacer qué dentro de tu cuenta de AWS. No se trata solo de seguridad: se trata de tener control real sobre tu infraestructura en la nube.
 
Acabé de obtener la certificación AWS Security Specialty y, sin duda, IAM es la piedra angular de todo lo que tiene que ver con seguridad en AWS. En este artículo te explico los conceptos fundamentales de forma clara y práctica.
 

Dato clave: IAM es un servicio completamente gratuito. No pagas por usuarios, grupos ni políticas. Solo pagas por los recursos de AWS a los que esos usuarios acceden.

 
Las identidades de IAM: users, groups y roles
 
IAM Users: personas o servicios
Un IAM User representa a una persona o aplicación que necesita interactuar con AWS. Cuando creas un usuario, este dispone de:
 
•        Un nombre de usuario único dentro de la cuenta

•        Una contraseña para acceder a la consola web de AWS

•        Hasta dos access keys para acceso programático (CLI, SDK, API)

 
Por defecto, un usuario recién creado no tiene ningún permiso. No puede hacer absolutamente nada. Esto es intencional y se alinea con el principio de mínimo privilegio: empieza sin acceso y ve añadiendo solo lo necesario.
 
IAM Groups: permisos a escala
Gestionar permisos usuario a usuario no escala. Si tienes un equipo de veinte desarrolladores que necesitan los mismos accesos, actualizar cada usuario individualmente es un caos. Los grupos resuelven esto.
 
Un grupo es simplemente una colección de usuarios. Asignas los permisos al grupo, y todos sus miembros los heredan automáticamente. Así, si contratas a alguien nuevo, lo añades al grupo y listo: tiene exactamente los accesos que necesita sin configuración adicional.
 

Importante: los grupos no pueden contener otros grupos. Solo usuarios. Tampoco pueden asumir roles de IAM.

 
IAM Roles: permisos temporales sin credenciales
Los roles son quizás el concepto más potente y, a la vez, el más malentendido de IAM. A diferencia de los usuarios, los roles no tienen credenciales permanentes (ni contraseña ni access keys). En su lugar, generan credenciales temporales cuando son asumidos.
 
¿Cuándo usar roles? Algunos casos típicos:
 
•        Una instancia EC2 que necesita leer archivos de S3 sin hardcodear credenciales en el código

•        Un empleado que necesita acceso temporal a recursos de otra cuenta de AWS

•        Una función Lambda que escribe en DynamoDB

•        Usuarios de tu empresa que se autentican con tu Active Directory corporativo

 
Esta es la magia de los roles: eliminan la necesidad de gestionar credenciales de larga duración, lo que reduce drásticamente la superficie de ataque.
 
IAM Policies: el lenguaje de los permisos
 
Una policy es un documento JSON que define qué acciones están permitidas o denegadas sobre qué recursos. Es el corazón del sistema de permisos de IAM.
 
Estructura de una policy
Toda policy tiene los mismos elementos fundamentales:
 
•        Effect: Allow o Deny. Define si el statement permite o deniega el acceso.

•        Action: la acción de AWS a controlar (ej: s3:GetObject, ec2:StartInstances)

•        Resource: el recurso específico al que aplica (puede ser * para todos)

•        Condition (opcional): condiciones adicionales como IP origen, hora del día, etc.

 
Una regla crítica: el Deny explícito siempre gana sobre cualquier Allow. Si una policy niega algo, no importa cuántas otras policies lo permitan: el acceso será denegado.
 
Tipos de policies
En AWS existen varios tipos de policies que conviene conocer:
 
•        AWS Managed Policies: creadas y mantenidas por AWS. Cómodas para empezar, pero a veces más permisivas de lo ideal.

•        Customer Managed Policies: las creas tú. Mayor control y precisión. Recomendadas para entornos de producción.

•        Inline Policies: embebidas directamente en un usuario, grupo o rol. Útiles para casos muy específicos, pero dificultan la gestión a escala.

•        Service Control Policies (SCPs): aplican a nivel de organización en AWS Organizations. Son el guardrail definitivo.

 
Seguridad en IAM: MFA y access keys
 
Multi-Factor Authentication (MFA)
La contraseña sola no es suficiente. Si alguien consigue tu contraseña, tiene acceso total a tu cuenta. El MFA añade una segunda capa de verificación: además de saber la contraseña, necesitas demostrar que tienes el dispositivo físico o virtual asociado.
 
AWS soporta varios tipos de MFA:
 
•        Aplicaciones de autenticación virtual (Google Authenticator, Authy)

•        Llaves de seguridad hardware (YubiKey, dispositivos FIDO2)

•        Dispositivos MFA de hardware de AWS

 
Regla de oro: activa MFA siempre en el usuario root y en todos los usuarios con privilegios elevados. Sin discusión.
 
Access Keys: acceso programático
Cuando un usuario o una aplicación necesita interactuar con AWS desde el terminal (CLI) o mediante código (SDK), necesita access keys. Cada access key está formada por dos partes:
 
•        Access Key ID: identificador público (similar a un nombre de usuario)

•        Secret Access Key: clave privada que nunca debes compartir ni subir a repositorios de código

 
Cada usuario puede tener hasta dos access keys activas simultáneamente, lo que facilita la rotación sin interrupciones. Una buena práctica es rotar las claves regularmente y desactivar las que no se usen.
 

Nunca hagas commit de access keys en repositorios de código. Es uno de los errores más comunes y costosos en AWS. Usa IAM Roles para aplicaciones que corren en servicios de AWS, no access keys.

 
Monitorización: IAM Access Analyzer
 
Crear permisos es solo la mitad del trabajo. El otro 50% es asegurarte de que esos permisos son los correctos y no hay accesos no deseados. Para eso existe IAM Access Analyzer.
 
Access Analyzer analiza continuamente tus políticas de IAM, buckets de S3, funciones Lambda y otros recursos para identificar:
 
•        Recursos compartidos con cuentas externas no esperadas

•        Políticas que otorgan más acceso del necesario (over-permissive)

•        Accesos cross-account no intencionados

 
Es una herramienta gratuita que debería estar activa en todas las cuentas de producción desde el día uno.
 
Mejores prácticas que todo profesional debe seguir
 
Después de trabajar con IAM y preparar la certificación, estas son las prácticas que más impacto tienen en la seguridad:
 
•        No uses el usuario root para tareas del día a día. Créate un usuario IAM con los permisos necesarios.

•        Aplica el principio de mínimo privilegio: da solo los permisos estrictamente necesarios para cada tarea.

•        Usa grupos para gestionar permisos, nunca asignes políticas directamente a usuarios individuales si puedes evitarlo.

•        Activa MFA en todos los usuarios con acceso a la consola, obligatorio en cuentas privilegiadas.

•        Usa roles en lugar de access keys para servicios de AWS (EC2, Lambda, etc.).

•        Rota las access keys con regularidad y elimina las que no se usen.

•        Revisa periódicamente los permisos con IAM Access Analyzer y el IAM Credential Report.

•        Define una password policy robusta: longitud mínima, complejidad, expiración y no reutilización.

 
Conclusión
 
IAM no es solo un servicio más de AWS: es la base sobre la que se construye toda la seguridad de tu infraestructura en la nube. Entenderlo bien, aplicar el principio de mínimo privilegio y mantenerse al día con las mejores prácticas marca la diferencia entre una cuenta segura y una potencial brecha de seguridad.
 
En el próximo artículo veremos cómo poner todo esto en práctica con un laboratorio paso a paso: crearemos usuarios, grupos y políticas personalizadas en una cuenta de AWS real. ¡No te lo pierdas!
 

Si este artículo te ha resultado útil, compártelo con alguien que esté empezando en cloud. Y si tienes dudas sobre IAM o certificaciones AWS, déjalas en los comentarios.