Curso AWS Cloud Practitioner CLF-C02

AWS Identity and Access Management, o IAM, es uno de los temas más importantes del examen CLF-C02 porque aparece en seguridad, cumplimiento, gobierno y operación diaria. IAM permite controlar quién puede acceder a AWS y qué acciones puede realizar sobre cada recurso.

Para este examen no necesitas ser experto escribiendo políticas JSON complejas. Lo que sí necesitas es entender muy bien la lógica: identidad, autenticación, autorización, permisos, roles, MFA, usuario raíz, credenciales temporales, mínimo privilegio y buenas prácticas. Muchas preguntas de CLF-C02 no te piden “configurar IAM”, sino elegir la opción más segura y adecuada para un escenario.

1. Qué problema resuelve IAM

Cuando una empresa usa AWS, no todo el mundo debe poder hacer todo. Un desarrollador quizá necesite desplegar una función Lambda. Un auditor solo necesita leer logs. Una aplicación en EC2 puede necesitar leer objetos de S3. Un equipo financiero puede necesitar ver facturación, pero no borrar recursos.

IAM permite crear ese control. Su objetivo es evitar accesos innecesarios, reducir riesgos y aplicar el principio de mínimo privilegio. En una cuenta AWS real, IAM es la base para separar responsabilidades entre personas, aplicaciones, servicios y cuentas.

2. Autenticación y autorización

Esta diferencia es fundamental para el examen:

• Autenticación: demostrar quién eres. Por ejemplo, iniciar sesión con usuario, contraseña y MFA.
• Autorización: determinar qué puedes hacer. Por ejemplo, permitir leer un bucket S3 pero no borrarlo.

Un usuario puede autenticarse correctamente y aun así no tener autorización para realizar una acción. Por ejemplo, puede iniciar sesión en la consola, pero no tener permiso para crear instancias EC2.

3. Usuario raíz de la cuenta AWS

El root user es la identidad inicial de la cuenta AWS. Tiene control completo sobre la cuenta y puede realizar acciones críticas. Por eso debe protegerse de forma especial.

Buenas prácticas para el usuario raíz:

• Activar MFA.
• No usarlo para tareas diarias.
• No compartir sus credenciales.
• No crear access keys para el root salvo necesidad excepcional.
• Usarlo solo para tareas que realmente lo requieran.

En el examen, si aparece una pregunta sobre proteger el usuario raíz, la respuesta suele incluir MFA, uso mínimo y separación mediante identidades IAM o IAM Identity Center.

4. Usuarios IAM

Un usuario IAM representa una identidad individual dentro de AWS. Puede tener credenciales para acceder a la consola y, si se permite, access keys para uso programático.

Un usuario IAM puede ser útil para personas o casos concretos, pero en entornos modernos se recomienda centralizar el acceso humano con IAM Identity Center cuando hay muchas cuentas, usuarios corporativos o necesidades de SSO.

Para CLF-C02, recuerda:

• Un usuario IAM es una identidad persistente.
• Puede tener permisos mediante políticas.
• No debe recibir más permisos de los necesarios.
• Las access keys deben protegerse y rotarse.
• No es buena práctica usar usuarios IAM para aplicaciones si puedes usar roles.

5. Grupos IAM

Un grupo IAM sirve para agrupar usuarios y asignar permisos comunes. Por ejemplo, puedes tener un grupo de Developers, otro de Auditors y otro de Billing.

La ventaja es la administración. Si diez usuarios necesitan los mismos permisos, no conviene administrar uno por uno. Creas un grupo, asignas la política al grupo y añades usuarios al grupo.

6. Roles IAM

Un rol IAM es una identidad que se puede asumir temporalmente. Es una de las ideas más importantes de IAM. Un rol no tiene credenciales permanentes como un usuario. Cuando alguien o algo asume el rol, AWS entrega credenciales temporales.

Los roles se usan mucho en estos escenarios:

• Una instancia EC2 necesita acceder a S3.
• Una función Lambda necesita escribir en DynamoDB.
• Una tarea ECS necesita leer un secreto.
• Un usuario de una cuenta necesita acceder temporalmente a otra cuenta.
• Una identidad federada necesita acceder a AWS sin crear un usuario IAM permanente.

7. Por qué los roles son tan importantes

Los roles reducen el uso de credenciales permanentes. Esto es clave para seguridad. Si guardas access keys en código, AMIs, repositorios o servidores, esas claves pueden filtrarse. Con roles, AWS proporciona credenciales temporales y las rota automáticamente.

Para el examen, cuando veas “servicio AWS necesita acceder a otro servicio AWS”, piensa casi siempre en rol IAM.

8. Políticas IAM

Las políticas IAM son documentos que definen permisos. Indican qué acciones están permitidas o denegadas, sobre qué recursos y bajo qué condiciones.

Componentes básicos de una política:

• Effect: Allow o Deny.
• Action: qué acción se permite o deniega, como s3:GetObject.
• Resource: sobre qué recurso aplica, como un bucket o una tabla.
• Condition: condiciones adicionales, como origen, etiqueta, MFA o IP.

No necesitas memorizar sintaxis JSON para CLF-C02, pero sí entender qué representa una política y cómo se usa para autorizar acciones.

9. Políticas basadas en identidad y políticas basadas en recursos

Hay dos familias muy importantes:

• Políticas basadas en identidad: se adjuntan a usuarios, grupos o roles. Responden a “qué puede hacer esta identidad”.
• Políticas basadas en recursos: se adjuntan al recurso. Por ejemplo, una bucket policy en S3. Responden a “quién puede acceder a este recurso”.

10. Políticas administradas por AWS y políticas del cliente

AWS proporciona políticas administradas por AWS, que son políticas predefinidas. También puedes crear políticas administradas por el cliente, adaptadas a tus necesidades.

Para el examen, recuerda que usar una política administrada por AWS puede ser cómodo, pero no siempre es lo más ajustado. En seguridad real se busca aplicar mínimo privilegio, creando permisos más específicos si hace falta.

11. Allow, deny y evaluación de permisos

IAM evalúa permisos combinando políticas. Para que una acción se permita, debe existir un allow aplicable. Pero si existe un deny explícito, ese deny prevalece sobre cualquier allow.

Esta idea aparece mucho en preguntas de seguridad:

• Por defecto, si no hay permiso, no se permite.
• Un allow explícito permite una acción si no hay ningún deny.
• Un deny explícito gana siempre.

12. Principio de mínimo privilegio

El principio de mínimo privilegio indica que cada identidad debe tener solo los permisos necesarios para realizar su tarea, nada más.

Ejemplo: si una aplicación solo necesita leer objetos de un bucket concreto, no debe tener permisos de administrador, ni permisos para borrar buckets, ni acceso a todos los servicios de la cuenta.

En CLF-C02, si una opción propone permisos amplios cuando existe una opción con permisos limitados y suficientes, normalmente la opción de mínimo privilegio es la correcta.

13. MFA: autenticación multifactor

MFA añade una segunda prueba de identidad además de la contraseña. Puede ser una app autenticadora, un token físico u otro mecanismo compatible.

MFA es especialmente importante para:

• Usuario raíz.
• Usuarios con permisos administrativos.
• Acceso a acciones sensibles.
• Entornos donde se quiere reducir riesgo ante robo de contraseña.

14. Access keys

Las access keys permiten acceso programático a AWS. Son útiles para CLI, scripts o aplicaciones, pero tienen riesgo si se almacenan mal.

Buenas prácticas:

• No guardar access keys en código fuente.
• No subirlas a repositorios.
• Rotarlas periódicamente si se usan.
• Eliminar las que no se necesiten.
• Preferir roles cuando sea posible.

15. Credenciales temporales y AWS STS

AWS Security Token Service, o AWS STS, permite obtener credenciales temporales. Los roles IAM se apoyan en este concepto: una entidad asume un rol y recibe credenciales válidas durante un tiempo limitado.

Las credenciales temporales reducen el riesgo frente a claves permanentes porque caducan. Son clave para roles, federación y acceso cross-account.

16. IAM Identity Center

IAM Identity Center permite centralizar el acceso de usuarios humanos a múltiples cuentas y aplicaciones. Se asocia con SSO, usuarios corporativos, permisos por cuenta y administración centralizada.

Para CLF-C02, si el escenario habla de usuarios humanos accediendo a varias cuentas AWS con una experiencia centralizada, IAM Identity Center suele ser la respuesta más adecuada.

17. Federación de identidades

La federación permite que usuarios de un proveedor externo de identidad accedan a AWS sin crear usuarios IAM permanentes para cada persona. Por ejemplo, una empresa puede integrar su directorio corporativo con AWS.

La idea clave es que el usuario se autentica en su proveedor de identidad y luego obtiene acceso temporal a AWS según los permisos configurados.

18. Acceso cross-account

El acceso cross-account permite que una identidad de una cuenta acceda a recursos o roles de otra cuenta. Suele hacerse mediante roles, no compartiendo contraseñas ni access keys.

En organizaciones con varias cuentas, este patrón es muy importante: una cuenta de seguridad puede auditar otras cuentas, una cuenta de operaciones puede administrar recursos o un proveedor externo puede asumir un rol limitado.

19. IAM Access Analyzer

IAM Access Analyzer ayuda a identificar recursos que pueden estar compartidos externamente y a analizar políticas. Es útil para detectar accesos no deseados a recursos como buckets S3, roles IAM, claves KMS u otros recursos compatibles.

Para CLF-C02, asócialo con:

• Análisis de acceso.
• Detección de recursos compartidos externamente.
• Revisión de políticas.
• Reducir exposición accidental.

20. Permission boundaries

Las permission boundaries establecen el máximo de permisos que una identidad puede llegar a tener. No conceden permisos por sí solas; limitan hasta dónde pueden llegar otros permisos.

Esto puede sonar parecido a las SCP de AWS Organizations, pero no es lo mismo. Una permission boundary aplica a una identidad IAM. Una SCP aplica a cuentas u OUs dentro de AWS Organizations.

21. SCP no es IAM, pero se relaciona con permisos

Las Service Control Policies pertenecen a AWS Organizations. No son políticas IAM normales. Sirven para establecer límites máximos de permisos en cuentas u OUs.

Un error típico es pensar que una SCP concede permisos. No los concede. Aunque una SCP permita una acción, la identidad todavía necesita permisos IAM. Si una SCP deniega una acción, la acción queda bloqueada aunque una política IAM la permita.

22. Tabla comparativa de identidades

23. Tabla comparativa de permisos

24. Escenarios típicos de examen

25. Diferencias que suelen confundir

26. Errores típicos

• Usar el usuario root para administración diaria.
• No activar MFA en el usuario raíz o en usuarios privilegiados.
• Guardar access keys en código, AMIs, repositorios o servidores.
• Conceder AdministratorAccess cuando solo se necesita lectura.
• Confundir autenticación con autorización.
• Usar usuarios IAM para aplicaciones cuando un rol sería más seguro.
• Pensar que una SCP concede permisos.
• Olvidar que un deny explícito prevalece sobre un allow.
• Dar permisos a todos los recursos cuando el escenario pide un recurso concreto.
• No diferenciar políticas basadas en identidad y políticas basadas en recursos.

27. Cómo estudiar IAM para CLF-C02

IAM se aprende muy bien con preguntas de decisión. Antes de mirar las respuestas, intenta identificar si el escenario habla de una persona, una aplicación, un servicio AWS o varias cuentas.

• Si habla de una persona individual, piensa en usuario IAM o Identity Center.
• Si habla de muchos usuarios con permisos iguales, piensa en grupo IAM.
• Si habla de servicio AWS accediendo a otro servicio, piensa en rol IAM.
• Si habla de multi-cuenta y usuarios corporativos, piensa en IAM Identity Center.
• Si habla de credenciales temporales, piensa en rol y STS.
• Si habla de detectar exposición externa, piensa en IAM Access Analyzer.
• Si habla de limitar permisos máximos a cuentas, piensa en SCP.
• Si habla de limitar permisos máximos de una identidad, piensa en permission boundary.

Resumen final

IAM es el centro del control de acceso en AWS. Debes dominar la diferencia entre usuario, grupo y rol; proteger el usuario raíz con MFA; aplicar mínimo privilegio; evitar access keys permanentes cuando puedas usar roles; entender políticas basadas en identidad y en recursos; recordar que el deny explícito prevalece; y reconocer IAM Identity Center, federación, STS, Access Analyzer, permission boundaries y SCP a nivel conceptual.

Para aprobar CLF-C02, no estudies IAM como teoría aislada. Estúdialo como decisiones de seguridad: quién accede, con qué identidad, durante cuánto tiempo, a qué recurso, con qué permisos y cómo se reduce el riesgo.