Modelo de Permisos de IAM con Políticas, Roles y Permission Boundary desde Cero hasta el Nivel Profesional
_Category: Identity & Access_
Todo lo relacionado con la seguridad en AWS termina desembocando en IAM. Quién puede hacer qué sobre cuál recurso: esa decisión fundamental es la base de cualquier arquitectura de seguridad y, a la vez, el dominio que más aparece en el examen SCS-C03. En este artículo recorremos los conceptos desde los fundamentos hasta los escenarios que más confunden en la práctica: accesos entre cuentas que fallan sin motivo aparente, confusión entre Permission Boundary y SCP, y Trust Policy ausentes que bloquean roles enteros.
---
El Núcleo del Modelo IAM: Principal, Action, Resource, Condition
IAM decide los permisos combinando cuatro elementos. Piénsalo como el sistema de control de acceso de un edificio moderno: no basta con tener credenciales, también importa a qué puertas quieres entrar, qué acción realizas y bajo qué circunstancias.
Principal: quién hace la solicitud. Puede ser un usuario IAM, un rol IAM, un servicio AWS o una cuenta externa. Action: qué operación se intenta ejecutar. Son llamadas de API como , o . Resource: sobre qué recurso concreto. Se especifica mediante ARN: un bucket específico, un rol, una clave KMS. Condition: bajo qué circunstancias. Dirección IP, franja horaria, presencia de MFA, región o etiquetas, entre otras.
Una política IAM es un documento JSON que describe estos cuatro elementos dentro de bloques Statement, cada uno con Effect (Allow o Deny), Principal, Action, Resource y Condition. Conocer las claves de condición más frecuentes permite leer los escenarios del examen con mucha más velocidad.
— bloqueo automático fuera de un período. Se aplica en el bloque Allow; si la condición no se cumple, entra en juego una Deny implícita. — verificación de MFA. Con credenciales de larga duración siempre devuelve false, por lo que conviene combinar con Deny cuando sea false. — restricción de región. Los servicios globales (IAM, CloudFront, Route 53) deben excluirse con NotAction para que no queden bloqueados. — bloqueo masivo de cuentas externas a la organización. + — combina restricción de VPC y etiquetas obligatorias en un AND.
---
Los Seis Tipos de Políticas IAM
IAM controla los permisos mediante seis categorías de políticas, cada una responsable de una capa distinta del proceso de evaluación. Entender en qué capa actúa cada tipo es fundamental para diagnosticar problemas de acceso.
| Tipo de política | Destino de aplicación | Función principal | Acceso entre cuentas | |------------------|-----------------------|-------------------|-----------------------| | Identity-based Policy | Usuarios, grupos y roles IAM | Define qué puede hacer el principal | No | | Resource-based Policy | Buckets S3, claves KMS, colas SQS, etc. | Define qué Principal puede acceder al recurso | Sí (especificando Principal) | | Permission Boundary | Usuarios o roles IAM individuales | Limita el techo máximo de permisos | No | | SCP (Service Control Policy) | OUs o cuentas de AWS Organizations | Define el rango máximo permitido para toda la cuenta | Toda la organización | | Session Policy | Sesiones temporales de STS | Restricción adicional a nivel de sesión | No | | ACL (Access Control List) | S3 y algunos servicios | Mecanismo heredado (no recomendado) | Sí |
Una metáfora para retenerlos: la Identity-based Policy es la lista de accesos personales de cada empleado; la Resource-based Policy es el cartel en la puerta de la sala de reuniones que dice quién puede entrar; la Permission Boundary es el pase de visitante que indica hasta qué piso puedes subir; la SCP es el reglamento general de seguridad del edificio; y la Session Policy es el gafete temporal para una visita puntual.
La Resource-based Policy es el único mecanismo que permite acceso entre cuentas de forma directa, porque se adjunta al recurso mismo. Tanto Permission Boundary como SCP solo restringen el rango de permisos: por sí solos nunca otorgan permisos nuevos.
---
Lógica de Evaluación de Políticas: Deny Explícita Primero
Cuando llega una solicitud, AWS recopila todas las políticas relevantes y las evalúa en un orden definido. El principio central es uno solo: una Deny explícita, venga de donde venga, tiene prioridad sobre cualquier Allow.
El orden de evaluación es: (1) Deny explícita → (2) SCP (en entornos de Organizations) → (3) Permission Boundary → (4) Resource-based Policy → (5) Identity-based Policy. Si no hay ningún Allow en ninguna etapa, se aplica una Deny implícita.
La diferencia entre acceso dentro de la misma cuenta y acceso entre cuentas es crítica.
| Tipo de acceso | Requisito | |----------------|-----------| | Acceso a S3 desde la misma cuenta | Basta con Allow en Identity-based Policy O en Resource-based Policy | | Acceso a S3 entre cuentas distintas | Se requiere Allow en Identity-based Policy Y en Resource-based Policy (bucket policy) |
Un rol con AdministratorAccess no puede acceder a un bucket de otra cuenta si la bucket policy de esa cuenta no lo permite explícitamente. Otra trampa frecuente: debe especificarse con el ARN del objeto () y no solo con el ARN del bucket, de lo contrario aparece Access Denied aunque el permiso esté definido.
---
Roles y AssumeRole: Permisos Temporales entre Cuentas y Servicios
Un IAM Role es como un pase temporal entre departamentos: te permite actuar con los permisos de otro contexto sin necesidad de credenciales permanentes. STS emite tokens temporales con una vigencia que va desde 15 minutos hasta 12 horas como máximo, y expiran automáticamente.
Todo rol necesita exactamente dos tipos de políticas para funcionar.
Trust Policy (política de confianza): define quién tiene permitido asumir el rol. En Principal se especifica una cuenta AWS, un rol IAM o un servicio AWS. Permission Policy (política de permisos): define qué puede hacer quien asume el rol.
Para que EC2 acceda a S3 se necesita: permiso de S3 en la Permission Policy y en la Trust Policy. Sin el servicio en la Trust Policy, la asunción del rol falla en el primer paso.
AssumeRole entre cuentas requiere cumplir dos condiciones simultáneamente: la Trust Policy del rol en la cuenta destino debe permitir la cuenta origen, y la Identity-based Policy del principal en la cuenta origen debe incluir . Ambas son necesarias; ninguna es suficiente por sí sola.
Prioridad de credenciales en AWS CLI: variables de entorno > archivo credentials > perfil config > IMDS (rol). Si un EC2 tiene un rol asociado pero también existe un archivo , el archivo tiene precedencia y el rol se ignora.
Mecanismos de credenciales temporales más relevantes: Instance Profile de EC2 (rotación automática vía IMDS), Cognito Identity Pool (basado en STS, incluye acceso para invitados no autenticados), e IAM Roles Anywhere (reemplaza claves de larga duración en servidores on-premises usando certificados X.509).
---
Permission Boundary vs SCP: Los Dos Conceptos que Más Confusión Generan
Permission Boundary y SCP comparten un propósito general — limitar permisos — pero actúan sobre destinos completamente distintos. Confundirlos es una de las causas más comunes de errores en el examen.
| Aspecto | Permission Boundary | SCP | |---------|---------------------|-----| | Destino | Usuario o rol IAM individual | OU o cuenta completa en Organizations | | Dónde se configura | Consola IAM (por usuario o rol) | Consola de Organizations | | Otorga permisos | No, solo define el techo | No, solo define el rango máximo permitido | | Cálculo de permisos efectivos | Identity-based Policy ∩ Permission Boundary | SCP ∩ Identity-based Policy ∩ Permission Boundary | | Caso de uso principal | Limitar el techo de roles creados por equipos de desarrollo | Restricción de regiones o servicios a nivel organizacional |
Permission Boundary se usa cuando quieres dar autonomía a un equipo de desarrollo para crear roles sin arriesgar que escalen privilegios hasta obtener permisos de administrador. El equipo de seguridad crea la política de Boundary y obliga a que se adjunte al crear roles mediante la condición en . Aunque el desarrollador cree un rol con AdministratorAccess, el Boundary bloquea cualquier permiso que exceda lo definido.
SCP se aplica a toda una OU o a toda una cuenta dentro de Organizations. La cuenta de gestión (management account) queda exenta de los SCP. Son para restricciones globales de organización: bloquear regiones, prohibir ciertos servicios o exigir etiquetas. Para restricciones individuales, la herramienta correcta es Permission Boundary, no SCP.
!Permission Boundary vs SCP
Federation e IAM Identity Center: Integración de Identidades Externas y SSO
Crear un usuario IAM para cada persona es ineficiente y aumenta la superficie de ataque. Federation permite que los empleados usen sus credenciales corporativas existentes (Active Directory u otro IdP) para acceder a AWS.
Federation con SAML 2.0 funciona así: el IdP autentica al usuario y emite un SAML Assertion; STS verifica esa aserción y emite credenciales temporales. Si la organización tiene múltiples cuentas AWS, hay que configurar la integración en cada una por separado, lo que puede volverse costoso de mantener.
Federation basado en OIDC (Web Identity Federation) se implementa a través de Cognito usando . Es la solución adecuada cuando usuarios de aplicaciones móviles que inician sesión con Google, Facebook u otro proveedor social necesitan acceder a recursos AWS sin tener cuentas IAM.
IAM Identity Center (anteriormente AWS SSO) ofrece gestión centralizada de SSO integrada con Organizations: los usuarios acceden a cientos de cuentas con una sola identidad. AD Connector autentica contra el Active Directory on-premises sin sincronizar el directorio a la nube, actuando como proxy.
Flujo de configuración de Identity Center: activar desde la cuenta de gestión de Organizations → elegir la fuente de identidad → crear Permission Sets → a