La seguridad representa aproximadamente el 30% del examen SAA-C03. El primer desafio es disenar "quien puede acceder a que." Si piensas en IAM solo como una herramienta de gestion de usuarios, responderas mal las preguntas del examen. IAM es el nucleo de seguridad de todo AWS.
¿Que es IAM?
Imagina el sistema de seguridad de un edificio corporativo. Para entrar, necesitas una credencial de acceso. Cada credencial tiene reglas distintas: "cafeteria y lobby permitidos, sala de servidores prohibida." AWS IAM funciona exactamente asi.
IAM (Identity and Access Management) controla el acceso a los recursos de AWS. Responde la pregunta: "¿Puede esta persona (o servicio) realizar esta accion sobre este recurso?"
IAM tiene cuatro componentes principales:
Usuario: Representa a una persona real. Como una credencial de acceso personal. Grupo: Agrupacion de usuarios al estilo departamental. Dale permisos al grupo "Equipo de Dev" y todos los miembros los heredan. Rol: Credencial temporal asignada a servicios o aplicaciones, no a personas. Cuando una instancia EC2 necesita acceder a S3, usa un rol. Politica: Documento JSON con las reglas de permisos reales. Por ejemplo, "permitir lectura de buckets S3."
Cuatro tipos de politicas IAM
Las politicas difieren segun a que se adjuntan.
Las politicas basadas en identidad se adjuntan directamente a usuarios, grupos o roles. "Este empleado puede leer S3": le das el permiso a la identidad.
Las politicas basadas en recursos se adjuntan al propio recurso. La politica de bucket S3 es el ejemplo clasico. "Solo usuarios de esta cuenta especifica pueden acceder a este bucket": la regla vive en el recurso.
Los limites de permisos (Permission Boundaries) limitan los permisos maximos que una identidad puede tener. Aunque alguien otorgue admin completo, un limite de permisos puede restringir lo que ese usuario realmente puede hacer.
Las SCP (Service Control Policies) son reglas maestras aplicadas a nivel organizacional. Se aplican a todas las cuentas bajo una OU de AWS Organizations. Si una SCP bloquea una accion, ninguna politica IAM en esa cuenta puede anularla.
!4 tipos de políticas de IAM
Logica de evaluacion de politicas — Como decide AWS
Cuando llega una solicitud de acceso, AWS la evalua en este orden:
Paso 1: Si existe un Deny explicito en cualquier lugar, el acceso se bloquea de inmediato. Ningun Allow puede anular un Deny.
Paso 2: Si existe un Allow explicito, se concede el acceso.
Paso 3: Si no se encuentra ninguno de los dos, el resultado predeterminado es Deny implicito. AWS bloquea todo por defecto.
Regla clave: el Deny explicito siempre gana sobre cualquier Allow, sin excepciones.
Gestion multicuenta — AWS Organizations
Las grandes empresas operan multiples cuentas AWS: desarrollo, produccion, seguridad, finanzas. AWS Organizations permite gestionar todas como una sola organizacion.
Una OU (Organizational Unit) agrupa cuentas como departamentos. Podrias tener una "OU de Dev" y una "OU de Prod" con reglas diferentes.
Las SCP aplicadas a una OU establecen los permisos maximos para cada cuenta en ese grupo. Por ejemplo: "las cuentas en la OU de Dev nunca pueden eliminar bases de datos de produccion", sin importar lo que digan las politicas IAM.
AWS Control Tower se basa en Organizations para configurar automaticamente un entorno multicuenta siguiendo las mejores practicas de AWS. Aplica barreras de proteccion (guardrails) obligatorias y recomendadas para mantener la gobernanza en toda la organizacion.
Acceso entre cuentas — STS AssumeRole
Imagina una funcion Lambda en la Cuenta A que necesita leer un bucket S3 en la Cuenta B. Lo resuelves con roles entre cuentas y STS (Security Token Service).
El proceso funciona asi:
Paso 1: En la Cuenta B (donde vive el bucket S3), crea un rol IAM. En su politica de confianza, especifica "la Cuenta A puede asumir este rol."
Paso 2: La Lambda en la Cuenta A llama a STS AssumeRole y recibe credenciales temporales (validas de 15 minutos a 36 horas).
Paso 3: Usa esas credenciales temporales para acceder al bucket S3 de la Cuenta B.
Las credenciales temporales expiran automaticamente, lo que es mucho mas seguro que compartir claves de acceso permanentes.
Federacion — Conectar sistemas de inicio de sesion externos
Es tedioso para los empleados iniciar sesion en la consola de AWS por separado de sus cuentas corporativas. Si ya tienen una cuenta de Active Directory, deberian poder usarla para AWS tambien. Esto es la federacion.
IAM Identity Center (antes AWS SSO) proporciona inicio de sesion unico en multiples cuentas AWS. Se integra con proveedores de identidad externos como Microsoft Active Directory y Google Workspace.
Amazon Cognito gestiona la autenticacion de usuarios para aplicaciones moviles y web. Los User Pools gestionan el registro e inicio de sesion. Los Identity Pools otorgan a los usuarios autenticados acceso a recursos AWS.
Puntos clave para el examen
"Principio de minimo privilegio" — base de todo diseno de acceso; permite solo lo necesario
"Bloquear un servicio especifico en cuentas miembro" — SCP (aunque IAM lo permita, SCP anula)
"Tanto SCP como IAM deben permitir para que el acceso funcione" — evaluacion de interseccion de politicas
"Acceder a recursos en otra cuenta" — rol entre cuentas + STS AssumeRole
"SSO en multiples cuentas AWS" — IAM Identity Center
"Autenticacion de usuarios para apps moviles/web" — Amazon Cognito
"EC2 necesita acceder a S3" — rol IAM via perfil de instancia; nunca codificar claves de acceso
"Limitar los permisos maximos de un usuario IAM" — Permission Boundary
El Deny explicito siempre gana sobre cualquier Allow, sin excepciones