AWS IAM

Qué es

AWS Identity and Access Management (IAM) es el sistema de permisos de AWS. Define quién (una persona, una aplicación, un servicio) puede hacer qué acción sobre qué recurso, y en qué condiciones. Cada llamada a la API (Application Programming Interface: interfaz para que los programas se comuniquen) de AWS se autentica y se autoriza contra IAM. Es un servicio global (no pertenece a una región) y no tiene coste.

Conceptos clave

• Usuario raíz (root): la identidad con la que se crea la cuenta. Tiene acceso total y no se puede limitar con políticas de IAM. Se protege con MFA (Multi-Factor Authentication: inicio de sesión con un segundo factor), sin claves de acceso, y solo se usa para las pocas tareas que lo exigen.
• Usuarios y grupos: identidades de larga duración para personas o aplicaciones. Los grupos solo sirven para agrupar usuarios y asignarles políticas; no son identidades que puedan autenticarse.
• Roles: identidades sin credenciales permanentes que se asumen para obtener credenciales temporales (vía AWS STS (Security Token Service)). Son la forma recomendada de dar permisos a servicios (EC2 (Elastic Compute Cloud), Lambda), a otras cuentas y a usuarios federados.
• Políticas: documentos JSON (JavaScript Object Notation: formato de datos en texto) con Effect (Allow/Deny), Action, Resource y, opcionalmente, Condition. Pueden ser gestionadas por AWS, gestionadas por el cliente o insertadas (inline).
• Tipos de política: basadas en identidad (asociadas a usuario, grupo o rol), basadas en recurso (en el propio recurso, como una bucket policy de S3 (Simple Storage Service), e incluyen Principal), límites de permisos (permissions boundaries), políticas de sesión, y las políticas de AWS Organizations: SCP (máximo que pueden hacer las identidades de las cuentas) y RCP (máximo que se puede hacer sobre los recursos de las cuentas).
• Lógica de evaluación: todo empieza denegado implícitamente; un Allow lo permite; un Deny explícito gana siempre. Con SCP, límites de permisos o políticas de sesión, el permiso efectivo es la intersección de todos ellos.
• Relación de confianza (trust policy): política basada en recurso del rol que dice quién puede asumirlo.
• IAM Access Analyzer: detecta recursos compartidos con entidades externas, permisos no usados y valida políticas.

Casos de uso típicos

• Dar a una instancia EC2 o a una función Lambda acceso a S3 o DynamoDB mediante un rol (en EC2, a través de un perfil de instancia).
• Acceso entre cuentas: un rol en la cuenta B que la cuenta A puede asumir.
• Federación: usuarios de un proveedor de identidad corporativo (SAML (Security Assertion Markup Language: estándar de inicio de sesión federado) u OIDC (OpenID Connect: estándar de identidad sobre OAuth 2.0)) que asumen roles, normalmente gestionado con IAM Identity Center.
• Delegar la creación de roles a desarrolladores sin riesgo de escalada, usando límites de permisos.
• CI/CD (Continuous Integration / Continuous Delivery: integración y entrega continuas) sin claves permanentes: GitHub Actions u otros sistemas que asumen un rol con OIDC.

Cuándo NO usarlo

• Para el inicio de sesión de los usuarios finales de tu aplicación: eso es Amazon Cognito, no IAM.
• Para gestionar el acceso de muchas personas a muchas cuentas: mejor IAM Identity Center con un proveedor de identidad, en vez de crear usuarios IAM en cada cuenta.
• Para guardar secretos de aplicación: eso es AWS Secrets Manager o Parameter Store.

Comparativa con servicios parecidos

Modelo de precios

IAM no tiene coste: usuarios, roles, políticas y evaluaciones son gratuitos. Pagas por los servicios a los que das acceso. Algunas funciones de IAM Access Analyzer, como el análisis de acceso no usado, sí tienen coste.

Seguridad y alta disponibilidad

• Mínimo privilegio: empezar sin permisos y añadir solo lo necesario, con recursos concretos en vez de *.
• Preferir credenciales temporales (roles) a claves de acceso de larga duración; si existen claves, rotarlas.
• MFA para el usuario raíz y para usuarios con privilegios.
• Usar condiciones (aws:SourceIp, aws:PrincipalOrgID, aws:SecureTransport, aws:MultiFactorAuthPresent) para acotar.
• IAM es un servicio global y replicado; los cambios de permisos pueden tardar unos instantes en propagarse (consistencia eventual).

Así lo uso en Kopi

En Kopi, mi proyecto personal, todas las funciones Lambda comparten un rol de ejecución limitado a las acciones que necesitan: lectura y escritura solo sobre las tablas con el prefijo del proyecto, S3 solo sobre el bucket de medios, unas pocas acciones administrativas de Cognito y escribir logs. El despliegue desde GitHub Actions usa otra identidad, que solo puede actualizar código y configuración de funciones, subir el frontend e invalidar la caché de CloudFront. Nunca crear ni borrar recursos. Una lección práctica: algunas acciones, como lambda:ListFunctions, no admiten restringir el recurso y exigen "Resource": "*".

Trampas de examen

• "Deny explícito" siempre gana, aunque otra política permita la acción.
• Si una aplicación en EC2 o Lambda necesita acceso a AWS, la respuesta es un rol, nunca claves de acceso en el código o en variables de entorno.
• Las SCP no conceden permisos: solo limitan. Tampoco afectan a la cuenta de administración de la organización.
• "Evitar que un desarrollador se dé más permisos" apunta a límites de permisos.
• "Acceso entre cuentas": rol asumible con trust policy o política basada en recurso con Principal de la otra cuenta.
• Los grupos no pueden anidarse ni usarse como Principal.

Preguntas de práctica

Preguntas originales escritas para estos apuntes. No son preguntas reales de examen.

Fuentes

• What is IAM?, documentación de AWS (consultada el 25/09/2026).
• Policies and permissions in AWS Identity and Access Management, documentación de AWS (consultada el 25/09/2026).
• Policy evaluation logic, documentación de AWS (consultada el 25/09/2026).
• Security best practices in IAM, documentación de AWS (consultada el 25/09/2026).