CLF-C02
Deep Dive
AWS Identity and Access Management (IAM) es el servicio central de seguridad de AWS. Controla quién puede autenticarse y qué acciones puede realizar. Es global, gratuito y crítico para el examen CLF-C02.
Contenido
AWS IAM permite gestionar el acceso a los servicios y recursos de AWS de manera segura. Con IAM, puedes crear y administrar usuarios y grupos AWS, y usar permisos para permitir o denegar su acceso a los recursos.
Gratis
Costo
Sin costo adicional
Global
Alcance
No es por región
Identity
Tipo
AuthN + AuthZ
Deny all
Default
Sin permiso = denegado
IAM Users
Una identidad dentro de tu cuenta AWS que representa a una persona o servicio que interactúa con AWS. Tiene credenciales permanentes (contraseña para consola, Access Keys para CLI/API).
Cuándo usar
Cuándo NO usar / Cuidado
IAM Groups
Una colección de usuarios de IAM. Puedes especificar permisos para un grupo, lo que facilita la gestión de permisos para múltiples usuarios. Los grupos NO pueden contener otros grupos.
Cuándo usar
Cuándo NO usar / Cuidado
IAM Roles
Una identidad con permisos específicos. A diferencia de un usuario, un rol no tiene credenciales permanentes — sus credenciales son temporales y se generan automáticamente cuando alguien asume el rol.
Cuándo usar
Cuándo NO usar / Cuidado
IAM Policies
Documentos JSON que definen permisos. Una política especifica qué acciones están permitidas o denegadas en qué recursos y bajo qué condiciones. Se adjuntan a usuarios, grupos o roles.
Cuándo usar
Estructura de una política IAM (JSON)
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow", // Allow o Deny
"Action": "s3:GetObject", // Qué acción
"Resource": "arn:aws:s3:::mi-bucket/*", // En qué recurso
"Condition": { // Opcional: condiciones
"IpAddress": {"aws:SourceIp": "203.0.113.0/24"}
}
}
]
}⚠️ NO usar root para operaciones diarias
La cuenta root tiene acceso ilimitado a todo en tu cuenta AWS. Comprometer la root es catastrófico — no tiene límites de permisos.
Nunca usar root para:
✓ Cuándo SÍ es necesario root
Hay tareas que SOLO puede hacer la cuenta root. El examen las evalúa específicamente:
Best practice crítica para el examen
Después de crear la cuenta AWS: (1) Activar MFA en root, (2) Crear usuario IAM con permisos admin, (3) Usar ese usuario para todo. La cuenta root solo se usa para las tareas específicas listadas arriba.
Multi-Factor Authentication (MFA)
MFA añade una capa de seguridad adicional más allá de la contraseña. Con MFA, los usuarios deben proporcionar dos factores de autenticación: algo que saben (contraseña) + algo que tienen (token MFA).
Virtual MFA
App en smartphone (Google Authenticator, Authy). Genera código TOTP de 6 dígitos. El más común en el examen.
Ej: Google Authenticator, Microsoft Authenticator
Hardware MFA
Dispositivo físico de hardware que genera códigos. Más seguro que virtual pero más costoso.
Ej: Gemalto, YubiKey
U2F Security Key
Llave de seguridad USB que se conecta físicamente. Autenticación con toque físico.
Ej: YubiKey, Google Titan
Principio de mínimo privilegio (Principle of Least Privilege): otorga solo los permisos necesarios para realizar la tarea específica, nada más. Si un usuario solo necesita leer archivos de S3, no le des permisos de administrador.
❌ Mal enfoque
✓ Buen enfoque
| Dimensión | Access Keys (evitar) | IAM Roles (recomendado) |
|---|---|---|
| Tipo | Credenciales permanentes (Key ID + Secret) | Credenciales temporales (STS tokens) |
| Duración | Permanentes hasta que se roten/eliminen | Expiran automáticamente (15min–12h) |
| Si se comprometen | Compromiso permanente hasta rotar | Expiran solos, mínimo impacto |
| Rotación | Manual — muchos la olvidan | Automática — AWS STS lo gestiona |
| Almacenamiento | Riesgo de quedar en código, S3, logs | No hay credenciales que almacenar |
| Auditoría | Difícil saber qué proceso usó qué key | CloudTrail muestra el rol que ejecutó la acción |
| Caso de uso ideal | Desarrollo local (cuando no hay alternativa) | EC2, Lambda, ECS, EKS — cualquier servicio AWS |
Regla de oro para el examen
Si el escenario dice "una aplicación en EC2 necesita acceder a S3" → la respuesta correcta es siempre crear un IAM Role y adjuntarlo a la instancia EC2. Nunca hardcodear Access Keys en el código ni en variables de entorno.
La federación de identidad permite a los usuarios de sistemas de identidad externos (Active Directory corporativo, Google, Facebook) acceder a AWS sin crear usuarios IAM individuales.
SAML 2.0
Integración con Active Directory corporativo o cualquier proveedor SAML. Permite SSO para miles de empleados sin crear usuarios IAM individuales.
Ej: Microsoft AD, Okta, PingFederate
Web Identity Federation
Permite a usuarios autenticados con proveedores web (Cognito, Google, Facebook) asumir roles IAM para acceder a AWS.
Ej: Amazon Cognito para apps móviles
AWS SSO (IAM Identity Center)
Solución centralizada de SSO para gestionar acceso a múltiples cuentas AWS y aplicaciones empresariales.
Ej: Acceso centralizado a todas las cuentas en una organización AWS
AWS IAM Identity Center centraliza la gestión de acceso a múltiples cuentas AWS y aplicaciones de negocio. Reemplaza la necesidad de crear usuarios IAM en cada cuenta individual.
Características principales
Cuándo usar IAM Identity Center
Para el examen
IAM Identity Center = SSO para múltiples cuentas AWS. Se integra con AWS Organizations para gestión centralizada.
Cross-Account Roles — Acceso entre cuentas
Un usuario o servicio en la cuenta A puede asumir un rol en la cuenta B para acceder a sus recursos. Sin necesidad de crear usuarios adicionales. Las credenciales son temporales y se revocan automáticamente.
Caso de uso
Empresa con cuenta de producción y cuenta de seguridad separada. El equipo de auditoría en la cuenta de seguridad asume un rol de solo lectura en producción.
Cómo funciona
Cuenta B crea un rol con trust policy que permite a la cuenta A. Usuario en A ejecuta sts:AssumeRole y recibe credenciales temporales para B.
Amazon Cognito — Auth para aplicaciones web/móviles
Cognito proporciona autenticación, autorización y gestión de usuarios para aplicaciones web y móviles. No es para acceso a la consola de AWS — es para los usuarios de tus aplicaciones.
User Pools
Directorio de usuarios para autenticación. Gestiona registro, login, contraseñas, MFA, verificación de email. Devuelve tokens JWT.
Identity Pools
Concede a los usuarios autenticados credenciales temporales de AWS para acceder directamente a servicios (S3, DynamoDB) desde la app.
Service Control Policies (SCPs) — AWS Organizations
Las SCPs son políticas de límite de permisos que se aplican a cuentas miembro en AWS Organizations. Definen el máximo de permisos que los usuarios y roles de esa cuenta pueden tener.
Punto crítico del examen
Las SCPs NO conceden permisos — solo los restringen. Si un usuario tiene Allow en su política IAM pero la SCP de su cuenta tiene Deny, el usuario NO puede realizar la acción. SCPs aplican incluso al root de la cuenta miembro.
¿Entendiste este tema?
Pon a prueba lo que acabas de aprender
Un administrador de sistemas acaba de crear una nueva cuenta AWS para la empresa. Según las mejores prácticas de AWS, ¿cuál debería ser la primera acción respecto a la cuenta root?