IAM y Organizations en AWS: permisos, cuentas y guardrails explicado fácil

1. IAM no es solo “crear usuarios”

Cuando empezamos en AWS, es normal pensar que IAM sirve para crear usuarios y darles permisos. Y sí, sirve para eso. Pero IAM es mucho más importante que una simple pantalla de usuarios.

AWS Identity and Access Management, o IAM, es el servicio que permite controlar el acceso a recursos de AWS. Dicho de forma sencilla: IAM decide quién puede hacer qué dentro de tu cuenta AWS.

Por ejemplo:

• Quién puede crear una instancia EC2.
• Quién puede leer objetos de un bucket S3.
• Qué aplicación puede escribir en DynamoDB.
• Qué Lambda puede acceder a Secrets Manager.
• Quién puede borrar una base de datos RDS.
• Qué administrador puede cambiar políticas de seguridad.

En una cuenta pequeña puede parecer fácil. Pero en cuanto tienes varios usuarios, aplicaciones, entornos, equipos y servicios, IAM se convierte en una pieza crítica.

2. La pregunta básica de IAM: quién puede hacer qué

Para no liarte, piensa en IAM como una forma de responder cuatro preguntas:

Pregunta	Qué significa	Ejemplo
Quién	La identidad que intenta hacer algo	Usuario, rol, aplicación, servicio AWS
Qué acción	La operación que quiere ejecutar	s3:GetObject, ec2:StartInstances
Sobre qué recurso	El recurso afectado	Bucket S3, instancia EC2, tabla DynamoDB
Bajo qué condiciones	Contexto adicional	MFA, región, IP origen, etiquetas

Ejemplo sencillo:

“El rol de la aplicación puede leer objetos del bucket de contenidos, pero solo de ese bucket y no de todos los buckets de la cuenta”.

Eso es pensar bien en IAM. No se trata de dar permisos enormes para que “funcione”, sino de dar justo lo necesario.

3. La cuenta root: tocar lo mínimo

Cuando creas una cuenta AWS, existe una identidad principal llamada root user. Esta identidad tiene acceso total a la cuenta.

Y cuando digo acceso total, es total de verdad. Puede cambiar facturación, cerrar la cuenta, modificar configuraciones críticas y hacer prácticamente cualquier cosa.

Por eso, una de las primeras buenas prácticas es:

• No usar la cuenta root para tareas del día a día.
• Activar MFA en la cuenta root.
• Guardar sus credenciales de forma segura.
• Usarla solo para tareas muy concretas que realmente la requieren.

4. Usuarios, grupos y roles: no son lo mismo

IAM tiene varios tipos de identidades. Los más básicos son usuarios, grupos y roles. Conviene diferenciarlos bien porque en el examen pueden aparecer en escenarios muy parecidos.

Elemento	Qué es	Uso típico
Usuario IAM	Identidad asociada normalmente a una persona o uso específico	Acceso de una persona a la consola o API
Grupo IAM	Conjunto de usuarios con políticas comunes	Grupo “Developers”, “Auditors” o “ReadOnly”
Rol IAM	Identidad asumible con credenciales temporales	EC2 accediendo a S3, Lambda accediendo a DynamoDB, acceso cross-account

La diferencia importante está en los roles. Un rol no tiene credenciales permanentes como un usuario. Se asume temporalmente y AWS entrega credenciales temporales.

Esto es muy útil para aplicaciones y servicios, porque evita tener claves permanentes guardadas en servidores, repositorios o ficheros de configuración.

5. Roles y credenciales temporales: una idea importantísima

En AWS, las aplicaciones no deberían depender de access keys permanentes guardadas en código.

Ejemplo malo:

Una aplicación en EC2 necesita leer de S3, así que alguien mete una access key y una secret key en un fichero de configuración.

Eso puede funcionar, pero es mala idea. Si esas claves se filtran, alguien podría usarlas desde fuera. Además, rotarlas y controlarlas se vuelve más difícil.

Ejemplo mejor:

Asignas un IAM Role a la instancia EC2. Ese rol tiene permiso para leer el bucket necesario. La aplicación usa credenciales temporales que AWS proporciona automáticamente.

Esto también aplica a Lambda, ECS, EKS y otros servicios.

6. Qué es una política IAM

Una política IAM es un documento, normalmente en formato JSON, que define permisos.

La política dice qué acciones se permiten o deniegan, sobre qué recursos y bajo qué condiciones.

Elemento	Pregunta que responde	Ejemplo
Effect	¿Permite o deniega?	Allow o Deny
Action	¿Qué acción puede ejecutar?	s3:GetObject, ec2:DescribeInstances
Resource	¿Sobre qué recurso?	Un bucket, una tabla, una clave KMS
Condition	¿Bajo qué contexto?	MFA, IP origen, etiqueta, región

Ejemplo conceptual:

“Permitir leer objetos del bucket de apuntes, pero no permitir borrar objetos”.

Eso sería una política que permite s3:GetObject, pero no concede s3:DeleteObject.

7. Allow, Deny y denegación explícita

En IAM hay una idea muy importante: por defecto, todo está denegado salvo que exista un permiso que lo permita.

Pero además existe el explicit deny, o denegación explícita. Y esa denegación gana sobre un Allow.

Esto es clave:

• Si no hay ningún Allow, no puedes hacer la acción.
• Si hay un Allow, podrías hacerla.
• Pero si hay un Deny explícito, no puedes hacerla aunque exista un Allow.

Ejemplo sencillo:

Un usuario tiene una política que permite administrar S3. Pero otra política le deniega explícitamente borrar buckets. Resultado: podrá hacer muchas cosas en S3, pero no podrá borrar buckets.

8. Mínimo privilegio: la base de todo

El principio de mínimo privilegio dice que una identidad debe tener solo los permisos que necesita para hacer su trabajo, ni más ni menos.

Esto parece obvio, pero en la práctica se rompe mucho. Cuando algo no funciona, la tentación es dar permisos de administrador “para probar”. Y claro, funciona. Pero también abres una puerta enorme.

Ejemplos de mínimo privilegio:

• Una Lambda que solo necesita leer una tabla DynamoDB no debería poder borrar tablas.
• Una aplicación que solo necesita escribir logs no debería poder administrar IAM.
• Un usuario de auditoría puede necesitar lectura, pero no permisos de modificación.
• Un entorno de desarrollo no debería poder tocar recursos de producción.

En seguridad cloud, mínimo privilegio no es una frase bonita. Es una forma de reducir daño cuando alguien se equivoca o cuando una credencial se ve comprometida.

9. MFA: una capa básica que no deberías saltarte

MFA significa Multi-Factor Authentication. Es decir, autenticación multifactor.

La idea es que no baste con conocer la contraseña. Además, necesitas un segundo factor, como una app de autenticación, una llave física o un dispositivo autorizado.

En AWS, MFA es especialmente importante para:

• La cuenta root.
• Usuarios administradores.
• Accesos sensibles.
• Operaciones críticas.

Para CLF-C02, quédate con esto: MFA mejora la seguridad de acceso y es una buena práctica fundamental.

10. Permission boundaries: límites para permisos

Las permission boundaries son un concepto un poco más avanzado, pero conviene conocer la idea.

Una permission boundary define el máximo de permisos que una identidad IAM puede llegar a tener.

No concede permisos por sí sola. Solo pone un límite.

Ejemplo:

Un equipo puede crear roles para sus aplicaciones, pero la empresa quiere asegurarse de que esos roles nunca puedan administrar IAM ni desactivar CloudTrail. Una permission boundary puede ayudar a marcar ese límite.

Esto se usa mucho cuando quieres delegar cierta libertad a equipos, pero sin permitir que se salgan de unas reglas de seguridad.

11. Políticas de identidad y políticas de recurso

En AWS no todos los permisos vienen solo de políticas pegadas a usuarios o roles.

Hay dos tipos importantes:

Tipo de política	Dónde se aplica	Ejemplo
Política de identidad	Usuario, grupo o rol IAM	Un rol puede leer objetos de S3
Política de recurso	Directamente sobre el recurso	Bucket policy de S3, key policy de KMS

Ejemplo muy típico: Amazon S3.

Puedes dar permisos a un rol mediante IAM, pero también puedes tener una bucket policy que controle quién accede al bucket.

Esto es importante porque el permiso efectivo puede depender de varias capas. No siempre basta con mirar una única política.

12. Cómo puede aparecer IAM en CLF-C02

En el examen, IAM suele aparecer en preguntas de seguridad, responsabilidad compartida, acceso seguro y buenas prácticas.

Preguntas típicas pueden ir por aquí:

• Qué servicio gestiona usuarios, grupos, roles y permisos.
• Qué práctica mejora la seguridad del usuario root.
• Qué principio recomienda dar solo permisos necesarios.
• Qué usar para que una EC2 acceda a S3 sin claves permanentes.
• Qué mecanismo añade una segunda capa de autenticación.
• Qué significa una denegación explícita.
• Qué servicio registra llamadas API para auditoría.

Asociaciones rápidas

Necesidad	Servicio o concepto
Gestionar identidades y permisos	AWS IAM
Dar acceso temporal a una aplicación	IAM Role
Evitar claves permanentes en EC2 o Lambda	Roles y credenciales temporales
Añadir segundo factor de acceso	MFA
Dar solo permisos necesarios	Mínimo privilegio
Registrar actividad API	AWS CloudTrail
Analizar permisos públicos o cross-account	IAM Access Analyzer

13. AWS Organizations: cuando una cuenta ya no basta

Al principio, muchas personas usan una sola cuenta AWS para todo: pruebas, producción, facturación, usuarios, redes, bases de datos, seguridad, etc.

Para aprender está bien. Para una empresa real, normalmente no.

Cuando una organización crece, mezclar todo en una sola cuenta genera varios problemas:

• Producción y desarrollo quedan demasiado cerca.
• Es más fácil cometer errores graves.
• Los permisos se vuelven difíciles de controlar.
• La facturación es menos clara.
• Los logs de seguridad pueden quedar expuestos a los mismos equipos que operan cargas.
• El impacto de un fallo o una credencial comprometida puede ser mayor.

AWS Organizations permite gestionar varias cuentas AWS de forma centralizada.

14. Por qué usar varias cuentas AWS

Separar cuentas no es solo una cuestión de orden. Es una medida de seguridad y gobierno.

Una cuenta AWS actúa como una frontera fuerte. Si separas producción, desarrollo, seguridad y logs, reduces el impacto de errores y mejoras el control.

Cuenta	Uso típico	Por qué importa
Producción	Aplicaciones reales de negocio	Debe estar muy protegida
Desarrollo	Pruebas y cambios frecuentes	Permite experimentar sin tocar producción
Seguridad	Servicios de detección y gobierno	Centraliza visibilidad y controles
Log archive	Logs protegidos	Dificulta manipulación tras un incidente
Sandbox	Aprendizaje y pruebas controladas	Permite practicar con límites
Networking	Red compartida, conectividad híbrida	Centraliza conectividad cuando aplica

Este enfoque reduce el blast radius. Es decir, reduce el radio de impacto si algo sale mal.

Si un usuario se equivoca en una cuenta sandbox, el daño no debería alcanzar producción.

15. Organizational Units: ordenar cuentas por grupos

En AWS Organizations puedes agrupar cuentas en Organizational Units, o OUs.

Una OU es como una carpeta lógica donde metes cuentas relacionadas.

Ejemplo de estructura sencilla:

• OU Producción
• OU Desarrollo
• OU Seguridad
• OU Sandbox
• OU Infraestructura

Esto permite aplicar reglas comunes a grupos de cuentas. Por ejemplo, puedes aplicar controles más estrictos a producción y controles más flexibles a sandbox.

No hay una única estructura perfecta. Depende del tamaño de la empresa, equipos, entornos, cumplimiento y modelo operativo.

16. SCP: guardrails, no permisos

Las Service Control Policies, o SCP, son una de las piezas más importantes de AWS Organizations.

Y también una de las que más se confunden.

Una SCP no concede permisos.

Repito, porque esto cae mucho: una SCP no da permisos.

Una SCP define el máximo de acciones que pueden llegar a permitirse en una cuenta o en una OU.

Si una SCP deniega una acción, nadie dentro de esa cuenta podrá ejecutarla, aunque tenga una política IAM con Allow.

Ejemplo:

Una cuenta de desarrollo tiene usuarios con permisos amplios. Pero la organización aplica una SCP que impide desactivar CloudTrail. Resultado: aunque un administrador de esa cuenta tenga permisos IAM, no podrá desactivar CloudTrail.

Eso es un guardrail.

17. Qué son los guardrails

Un guardrail es una barrera de seguridad o gobierno que evita que alguien haga algo peligroso, incluso por error.

No está pensado para bloquear el trabajo normal, sino para impedir acciones que nunca deberían ocurrir.

Ejemplos de guardrails:

• Impedir desactivar CloudTrail.
• Impedir borrar logs de auditoría.
• Impedir crear recursos en regiones no aprobadas.
• Impedir desactivar cifrado en servicios críticos.
• Impedir eliminar buckets importantes.
• Impedir crear usuarios IAM con access keys sin control.

Una buena plataforma AWS no se basa solo en confiar en que todo el mundo haga lo correcto. También pone límites razonables para evitar errores graves.

18. Diferencia entre IAM y SCP

Esta diferencia es fundamental.

Elemento	Qué hace	Qué no hace
IAM Policy	Concede o deniega permisos a identidades o recursos	No gobierna por sí sola toda la organización multi-cuenta
SCP	Define límites máximos para cuentas u OUs	No concede permisos directamente

Ejemplo sencillo:

• IAM dice: “este rol puede crear instancias EC2”.
• SCP dice: “en esta cuenta no se pueden crear instancias fuera de eu-west-1”.
• Resultado: el rol podrá crear EC2 solo si cumple ese límite.

Una forma fácil de pensarlo:

IAM da permisos. SCP pone techo.

19. Facturación consolidada

AWS Organizations también permite facturación consolidada.

Esto significa que puedes tener varias cuentas AWS, pero ver y gestionar la facturación de forma centralizada.

Ventajas:

• Visión global de costes.
• Separación de consumo por cuenta.
• Mejor control financiero.
• Posible aprovechamiento de descuentos agregados según servicios y condiciones.
• Más facilidad para asignar costes a equipos, proyectos o entornos.

Para CLF-C02, lo importante es asociar AWS Organizations con gestión multi-cuenta y facturación consolidada.

20. CloudTrail: saber quién hizo qué

La seguridad no solo consiste en impedir acciones. También consiste en saber qué ha pasado.

AWS CloudTrail registra llamadas API y actividad de la cuenta. Es decir, te ayuda a responder preguntas como:

• ¿Quién creó esta instancia?
• ¿Quién borró este bucket?
• ¿Qué rol modificó esta política?
• ¿Desde dónde se hizo esta llamada?
• ¿Cuándo se cambió esta configuración?

CloudTrail es una pieza clave para auditoría, investigación de incidentes y cumplimiento.

21. IAM Access Analyzer: detectar exposiciones

IAM Access Analyzer ayuda a identificar recursos que pueden estar compartidos públicamente o con otras cuentas.

Esto es muy útil para detectar configuraciones peligrosas, como:

• Buckets S3 accesibles desde fuera de la cuenta.
• Roles que puede asumir otra cuenta.
• Políticas de recurso demasiado abiertas.
• Acceso cross-account que quizá no debería existir.

Para nivel base, quédate con la idea: IAM Access Analyzer ayuda a analizar accesos y detectar permisos externos o públicos.

22. Landing Zone: cuando AWS deja de ser una cuenta suelta

Cuando AWS deja de ser una cuenta de pruebas y empieza a ser una plataforma real, aparece el concepto de landing zone.

Una landing zone es una base preparada para operar AWS de forma ordenada: cuentas, red, seguridad, logging, gobierno, identidad y facturación.

No hace falta complicarlo desde el día uno, pero sí conviene tener una estructura clara.

Una landing zone suele incluir:

• Estructura multi-cuenta.
• OUs organizadas.
• Guardrails con SCP.
• Logging centralizado.
• Cuenta de seguridad.
• Cuenta de logs.
• Configuración de red base.
• Políticas de acceso.
• Controles de coste.

AWS ofrece servicios como AWS Control Tower para ayudar a crear y gobernar una landing zone con buenas prácticas.

23. AWS Control Tower explicado fácil

AWS Control Tower es un servicio que ayuda a desplegar y gestionar una landing zone multi-cuenta.

En vez de construir desde cero toda la estructura de cuentas, guardrails y controles, Control Tower proporciona una forma más guiada de empezar.

Puede ayudarte con:

• Creación de cuentas.
• Organización de cuentas.
• Aplicación de guardrails.
• Gobierno básico.
• Integración con AWS Organizations.
• Buenas prácticas iniciales de seguridad.

Para un alumno base, la idea principal es esta: si Organizations es la base multi-cuenta, Control Tower ayuda a gobernarla de forma más estructurada.

24. Ejemplo práctico: empresa con desarrollo y producción

Imagina una empresa que empieza con una sola cuenta AWS. Tiene una web, una base de datos, usuarios de desarrollo y recursos de prueba.

Al principio todo parece cómodo. Pero empiezan los problemas:

• Un desarrollador puede ver recursos de producción.
• Los costes de pruebas y producción se mezclan.
• Un error en desarrollo podría afectar sistemas reales.
• Los logs están en la misma cuenta donde trabajan todos.
• No hay límites claros para regiones o servicios permitidos.

Una mejora sería pasar a un modelo multi-cuenta:

• Cuenta de producción.
• Cuenta de desarrollo.
• Cuenta de seguridad.
• Cuenta de logs.
• Cuenta sandbox para pruebas.

Y después aplicar guardrails como:

• No desactivar CloudTrail.
• No borrar logs centralizados.
• No crear recursos fuera de regiones aprobadas.
• No usar servicios no permitidos en sandbox.
• No permitir acceso público a ciertos recursos.

Así la empresa no solo “usa AWS”, sino que empieza a gobernar AWS.

25. Seguridad por capas: no existe una única barrera

Una idea importante en AWS es que la seguridad se construye por capas.

No basta con una sola política, una sola contraseña o una sola configuración.

En un entorno real puedes tener:

• MFA para proteger accesos humanos.
• IAM para permisos detallados.
• SCP para límites de organización.
• CloudTrail para auditoría.
• GuardDuty para detección de amenazas.
• Config para revisar cumplimiento.
• KMS para cifrado.
• Security Hub para centralizar hallazgos.
• Logs centralizados para investigación.

Para CLF-C02 no necesitas dominarlo todo en profundidad, pero sí entender que IAM y Organizations forman parte de una estrategia más amplia de seguridad y gobierno.

26. Errores típicos con IAM y Organizations

Estos errores son bastante comunes, sobre todo cuando se empieza:

• Usar la cuenta root para el día a día.
  La cuenta root debe protegerse con MFA y usarse solo cuando sea necesario.
• Crear usuarios IAM para aplicaciones.
  Para workloads en AWS, normalmente es mejor usar roles y credenciales temporales.
• Guardar access keys en código.
  Es una mala práctica y aumenta mucho el riesgo si el repositorio se filtra.
• Dar AdministratorAccess para solucionar cualquier problema.
  Funciona rápido, pero rompe el principio de mínimo privilegio.
• No separar producción y desarrollo.
  Aumenta el riesgo de errores y dificulta controlar costes.
• Confundir SCP con IAM.
  Las SCP no conceden permisos. Solo ponen límites.
• No activar CloudTrail o no proteger sus logs.
  Sin auditoría, investigar incidentes se vuelve mucho más difícil.
• No revisar accesos públicos o cross-account.
  Puedes tener recursos expuestos sin darte cuenta.
• No usar MFA en usuarios privilegiados.
  Una contraseña comprometida puede causar un problema serio.
• No documentar quién tiene acceso a qué.
  Los permisos crecen con el tiempo y se vuelven difíciles de controlar.

27. Cómo explicarlo en una entrevista o comité técnico

Si tienes que explicar IAM y Organizations de forma profesional, no lo plantees solo como “crear permisos”. Plantéalo como reducción de riesgo.

Una buena explicación podría ser:

“IAM controla qué identidades pueden hacer qué acciones sobre qué recursos. Se debe aplicar mínimo privilegio, usar roles con credenciales temporales para workloads y proteger accesos humanos con MFA. Cuando la plataforma crece, AWS Organizations permite separar cuentas por entorno o función, aplicar SCP como guardrails y centralizar facturación y gobierno.”

Eso demuestra que entiendes el enfoque completo: identidad, permisos, cuentas, límites y auditoría.

Si te preguntan por mínimo privilegio, aterrízalo con ejemplos:

• Roles por aplicación.
• Permisos limitados por recurso.
• Condiciones por región o etiqueta.
• SCP para bloquear acciones peligrosas.
• CloudTrail para auditar actividad.

28. Cómo puede aparecer Organizations en CLF-C02

En CLF-C02, Organizations suele aparecer en preguntas sobre gobierno, facturación, multi-cuenta y control centralizado.

Necesidad en la pregunta	Servicio o concepto probable
Gestionar varias cuentas AWS de forma centralizada	AWS Organizations
Agrupar cuentas por entorno o función	Organizational Units
Aplicar límites máximos de permisos a cuentas	Service Control Policies
Ver costes de varias cuentas juntos	Facturación consolidada
Crear una landing zone gobernada	AWS Control Tower
Registrar llamadas API	AWS CloudTrail
Analizar acceso externo a recursos	IAM Access Analyzer

29. Checklist para revisar una base de seguridad IAM

Antes de dar por buena una cuenta o plataforma AWS, revisa esto:

• ¿La cuenta root tiene MFA activado?
  Es una de las primeras buenas prácticas de seguridad.
• ¿Se evita usar root para tareas diarias?
  El día a día debería hacerse con identidades controladas.
• ¿Los usuarios humanos tienen permisos adecuados?
  No todo el mundo necesita permisos de administrador.
• ¿Las aplicaciones usan roles en lugar de access keys permanentes?
  Esto reduce mucho el riesgo de credenciales filtradas.
• ¿Se aplica mínimo privilegio?
  Cada identidad debe tener solo lo que necesita.
• ¿Producción y desarrollo están separados?
  Idealmente en cuentas distintas cuando el entorno crece.
• ¿CloudTrail está activado y protegido?
  Necesitas auditoría para saber quién hizo qué.
• ¿Se revisan permisos públicos o cross-account?
  IAM Access Analyzer puede ayudar a detectarlos.
• ¿Hay SCP para acciones que nunca deberían permitirse?
  Por ejemplo, desactivar logging o usar regiones no aprobadas.
• ¿La facturación está organizada por cuenta, proyecto o entorno?
  El gobierno también incluye controlar costes.

30. Resumen para quedarte con lo importante

Si estás preparando CLF-C02, quédate con estas ideas:

• IAM controla identidades y permisos en AWS.
• La cuenta root debe protegerse con MFA y no usarse para el día a día.
• Usuarios, grupos y roles no son lo mismo.
• Los roles permiten credenciales temporales y son ideales para workloads.
• El mínimo privilegio consiste en dar solo los permisos necesarios.
• Un Deny explícito gana sobre un Allow.
• AWS Organizations permite gestionar múltiples cuentas.
• Las OUs agrupan cuentas de forma lógica.
• Las SCP son guardrails: no conceden permisos, ponen límites.
• CloudTrail registra actividad API y ayuda en auditoría.
• Control Tower ayuda a crear y gobernar una landing zone.

Conclusión

IAM y Organizations son dos piezas fundamentales para entender seguridad en AWS. No son temas “solo de administradores avanzados”; son conceptos que cualquier persona que prepare CLF-C02 debería dominar a nivel básico.

IAM responde a la pregunta: quién puede hacer qué sobre qué recurso. Organizations responde a cómo gobernar varias cuentas AWS de forma ordenada, con límites, facturación centralizada y separación de responsabilidades.

Cuando entiendes usuarios, roles, políticas, mínimo privilegio, SCP y separación de cuentas, empiezas a ver AWS con mentalidad más profesional. Ya no piensas solo en crear recursos, sino en protegerlos, auditarlos y limitar el impacto de errores.