Control de acceso en AWS IAM: Políticas, Roles y Mejores Prácticas

AWS Identity and Access Management (IAM) es el servicio que gobierna la autenticación y la autorización de cada llamada a la API que se realiza en tu entorno AWS. Determina quién puede iniciar sesión, qué acciones puede ejecutar y sobre qué recursos — en cada servicio de AWS, en cada región, en cada cuenta. Configurar IAM correctamente no es opcional; según los propios análisis post-incidente de AWS, las políticas de IAM mal configuradas están implicadas en la mayoría de las brechas de seguridad en la nube que llegan a divulgarse públicamente. Este artículo cubre la arquitectura de IAM, su lógica de evaluación de políticas, los patrones prácticos para escalar el control de acceso y los errores operativos que el SOC de Opsio encuentra repetidamente en cientos de cuentas de AWS.

Puntos clave

• AWS IAM es el servicio fundamental para controlar quién puede hacer qué en cada recurso de AWS, y su mala configuración es la causa raíz más habitual de los incidentes de seguridad en la nube.
• Un IAM eficaz exige combinar políticas de identidad, políticas de recurso, permission boundaries y Service Control Policies — no solo asignar políticas gestionadas a usuarios.
• Las organizaciones sujetas a NIS2, GDPR, ENS o DPDPA 2023 deben tratar la configuración de IAM como un control de cumplimiento normativo, no como una mera conveniencia operativa.
• ABAC (control de acceso basado en atributos) mediante etiquetas es el patrón de escalado recomendado actualmente para organizaciones con más de un puñado de cuentas, pero la mayoría de los equipos siguen recurriendo al RBAC por defecto.
• Los mayores fallos de IAM que investiga el SOC de Opsio no son escaladas de privilegios, sino credenciales obsoletas y roles de servicio sobre-permisivos que nadie revisa.

Cómo funciona AWS IAM: El modelo fundamental

IAM opera con un modelo de denegación por defecto. Cada solicitud a la API de AWS se evalúa contra un conjunto de políticas y, a menos que la evaluación produzca un Allow explícito — sin que ningún Deny lo anule —, la solicitud se rechaza. Comprender esta cadena de evaluación es el concepto más importante del control de acceso en AWS.

Principales, Acciones, Recursos y Condiciones

Cada sentencia de una política de IAM consta de cuatro componentes:

• Principal — la entidad que realiza la solicitud (usuario de IAM, rol de IAM, identidad federada, servicio de AWS)
• Action — la operación API específica (s3:GetObject, ec2:RunInstances, iam:CreateUser)
• Resource — los ARN a los que se aplica la acción
• Condition — restricciones opcionales (IP de origen, estado de MFA, hora del día, etiquetas del recurso)

Una política es un documento JSON que contiene una o más sentencias, cada una con un Effect de Allow o Deny. La potencia — y la complejidad — reside en cómo interactúan múltiples políticas durante la evaluación.

La cadena de evaluación de políticas

Cuando un principal realiza una solicitud dentro de una AWS Organization, la evaluación sigue este orden:

1. Service Control Policies (SCPs) — controles a nivel de organización que establecen los permisos máximos para las cuentas miembro

2. Políticas basadas en recurso — adjuntas al propio recurso (p. ej., políticas de bucket de S3, políticas de clave de KMS)

3. IAM permission boundaries — los permisos máximos que puede tener una entidad de IAM, independientemente de sus políticas de identidad

4. Políticas de sesión — pasadas al asumir un rol, delimitando aún más la sesión

5. Políticas basadas en identidad — las políticas adjuntas al usuario, grupo o rol de IAM

Un Deny explícito en cualquier nivel anula todas las sentencias Allow. Este modelo por capas permite imponer controles a nivel de toda la organización (mediante SCPs) incluso si los administradores de cuentas individuales intentan conceder acceso más amplio.

Comprender esta cadena no es un ejercicio académico — el NOC de Opsio traza habitualmente errores de acceso denegado hasta restricciones de SCP que los administradores de cuenta desconocían. Si estás depurando un 403 en una llamada API donde la política de identidad dice claramente Allow, revisa primero los SCPs.

Componentes de IAM en la práctica

IAM Users vs. IAM Roles vs. Identidades federadas

Los usuarios de IAM son identidades de larga duración con credenciales permanentes. Siguen existiendo y funcionando, pero para operadores humanos deben considerarse un modelo heredado. La guía actual de AWS — y la posición operativa de Opsio — es federar el acceso humano a través de IAM Identity Center (anteriormente AWS SSO), que emite credenciales temporales mediante SAML 2.0 u OIDC.

Los roles de IAM son los caballos de batalla del IAM moderno en AWS. Un rol no tiene credenciales permanentes; en su lugar, los principales asumen el rol y reciben tokens de seguridad temporales (a través de AWS STS). Los roles se utilizan para:

• Acceso entre cuentas (una carga de trabajo en la Cuenta A asume un rol en la Cuenta B)
• Acceso servicio a servicio (un instance profile de EC2, un execution role de Lambda)
• Acceso humano mediante federación (asumir un rol tras autenticarse con tu IdP)

Las identidades federadas se autentican contra un proveedor de identidad externo (Okta, Azure AD / Entra ID, Google Workspace) y asumen roles de IAM. Este es el patrón que toda organización con más de diez ingenieros debería utilizar para acceder a la consola y la CLI.

Políticas de IAM: Gestionadas, Inline y Personalizadas

Las políticas gestionadas de AWS (p. ej., ReadOnlyAccess, PowerUserAccess) son mantenidas por AWS y cubren patrones habituales. Son prácticas pero a menudo demasiado amplias para producción. AdministratorAccess es la política gestionada que el SOC de Opsio encuentra con más frecuencia en los hallazgos de auditoría — y casi nunca está justificada para las operaciones diarias.

Las políticas gestionadas por el cliente son el enfoque correcto por defecto. Escríbelas tú mismo, delimítalas a tus cargas de trabajo reales, versiónalas en Git y despliégalas mediante Infrastructure as Code (Terraform, CloudFormation o CDK).

Las políticas inline están incrustadas directamente en un usuario, grupo o rol. Mantienen una relación estricta 1:1. Úsalas solo cuando una política no debe ser adjuntada accidentalmente a otra entidad — lo cual es infrecuente.

Service Control Policies (SCPs)

Los SCPs son la capa más potente — y más incomprendida — de la pila de IAM. No conceden permisos; definen el límite máximo de lo que cualquier principal en una cuenta miembro puede hacer. Un SCP que deniega s3:DeleteBucket significa que nadie en esa cuenta puede eliminar un bucket, ni siquiera con AdministratorAccess.

Patrones de SCP que Opsio despliega habitualmente para sus clientes:

• Restricción de región — denegar todas las acciones fuera de eu-south-2 (España), eu-west-3 (París) y ap-south-1 (Bombay) para cumplir con la soberanía de datos según GDPR, ENS y DPDPA
• SCPs de protección — impedir desactivar CloudTrail, eliminar VPC flow logs o modificar el rol de IAM de auditoría
• Lista de denegación de servicios — bloquear servicios que la organización no utiliza (p. ej., Lightsail, GameLift) para reducir la superficie de ataque

Controles de seguridad en la nube

RBAC vs. ABAC: Elegir el modelo adecuado

RBAC (Control de acceso basado en roles)

RBAC en AWS consiste en crear roles de IAM diferenciados para cada función laboral — DevOps-Engineer, Data-Analyst, Security-Auditor — y adjuntar políticas a esos roles. Es intuitivo y funciona bien cuando:

• Tienes menos de ~20 roles distintos
• Los equipos están claramente separados
• La proliferación de cuentas es limitada

El inconveniente es la explosión combinatoria. Si tienes 5 funciones laborales, 4 entornos (dev/staging/prod/sandbox) y 3 proyectos, podrías necesitar 60 definiciones de rol — cada una con políticas separadas.

ABAC (Control de acceso basado en atributos)

ABAC utiliza etiquetas tanto en los principales como en los recursos para tomar decisiones de autorización. En lugar de 60 roles, escribes un conjunto reducido de políticas con condiciones como:

```json

"Condition": {

"StringEquals": {

"aws:ResourceTag/Project": "${aws:PrincipalTag/Project}",

"aws:ResourceTag/Environment": "${aws:PrincipalTag/Environment}"

}

}

```

Esto permite que un desarrollador etiquetado con Project=payments, Environment=dev acceda únicamente a los recursos etiquetados de la misma forma — sin crear roles específicos por proyecto o por entorno.

La documentación de IAM de AWS recomienda explícitamente ABAC como modelo preferido para el escalado. En la práctica, la mayoría de las organizaciones que gestiona Opsio utilizan un modelo híbrido: RBAC para la separación amplia por función laboral, ABAC para el control de acceso granular a recursos dentro de esos roles.

La trampa operativa: ABAC solo funciona si tu etiquetado es disciplinado. Si los equipos no etiquetan los recursos de forma consistente, las condiciones fallan de manera abierta o cerrada de forma impredecible. Impón el etiquetado con SCPs y reglas de AWS Config antes de apostar por ABAC.

Gobernanza de etiquetas y FinOps

Mejores prácticas de IAM: Lo que realmente importa

El pilar de Seguridad del AWS Well-Architected Framework define mejores prácticas de IAM en cinco áreas. Esto es lo que vemos que marca la diferencia en producción — no la teoría:

1. Eliminar las claves de acceso de larga duración

Cada clave de acceso es una credencial que puede ser exfiltrada. El SOC de Opsio ha investigado incidentes en los que claves de acceso publicadas en repositorios públicos de GitHub fueron explotadas en minutos por escáneres automatizados. La solución:

• Usar roles de IAM con credenciales temporales para todas las cargas de trabajo (instance profiles de EC2, task roles de ECS, execution roles de Lambda)
• Federar el acceso humano a través de IAM Identity Center
• En los casos excepcionales en que las claves de acceso sean inevitables (integraciones legacy), exigir la rotación mediante la regla de AWS Config access-keys-rotated con una antigüedad máxima de 90 días

2. Imponer MFA — en todo lo que importa

MFA en la cuenta root es lo mínimo. Pero también debe imponerse para:

• Todos los usuarios de IAM humanos (si aún los tienes)
• La asunción de roles sensibles (iam:AssumeRole con Condition: { "Bool": { "aws:MultiFactorAuthPresent": "true" }})
• El flujo de autenticación de IAM Identity Center (MFA con notificación push, no SMS)

3. Aplicar el mínimo privilegio de forma iterativa

Nadie acierta con el mínimo privilegio a la primera. El enfoque práctico:

1. Empezar con políticas gestionadas de AWS algo más amplias de lo necesario

2. Activar IAM Access Analyzer para monitorizar qué permisos se utilizan realmente

3. Tras 30-90 días, generar una política de mínimo privilegio basada en la actividad de acceso registrada en CloudTrail

4. Sustituir la política amplia por la generada

5. Repetir trimestralmente

La funcionalidad de generación de políticas de IAM Access Analyzer es genuinamente útil e infrautilizada. Lee los registros de CloudTrail y produce una política ajustada que incluye únicamente las acciones y recursos realmente invocados.

4. Usar permission boundaries para la administración delegada

Si permites a los desarrolladores o responsables de equipo crear roles de IAM (p. ej., para funciones Lambda), establece un permission boundary que limite lo que esos roles creados pueden hacer. Sin esto, un desarrollador puede crear un rol con AdministratorAccess — lo que constituye una vía de escalada de privilegios.

5. Auditar de forma continua, no anual

Una revisión anual de IAM es un ejercicio de marcar casillas. En su lugar:

• Ejecutar IAM Access Analyzer de forma continua para detectar accesos externos y no utilizados
• Monitorizar llamadas anómalas a la API de IAM mediante CloudTrail + Amazon GuardDuty
• Utilizar reglas de AWS Config para señalar automáticamente configuraciones de IAM no conformes
• Canalizar los hallazgos hacia un SIEM centralizado o la cadena de alertas de tu SOC

Monitorización SOC 24/7

IAM en una AWS Organization multicuenta

Los entornos AWS de una sola cuenta son cada vez más raros en producción. AWS Organizations, combinado con IAM Identity Center, es el patrón estándar para gestionar el acceso a través de decenas o cientos de cuentas.

IAM Identity Center (anteriormente AWS SSO)

IAM Identity Center proporciona un punto único para gestionar el acceso humano a todas las cuentas de tu organización. Los usuarios se autentican una vez (a través de tu IdP corporativo o el directorio integrado) y reciben credenciales temporales para la cuenta y el conjunto de permisos que seleccionen.

Los permission sets en IAM Identity Center son abstracciones que crean roles de IAM en cada cuenta destino. Se definen una vez de forma centralizada y se asignan a usuarios o grupos por cuenta. Esto es drásticamente más sencillo que gestionar roles de IAM de forma independiente en cada cuenta.

Asunción de roles entre cuentas

Para el acceso servicio a servicio entre cuentas (p. ej., un pipeline de CI/CD en la cuenta de herramientas que despliega en producción), el patrón es:

1. Crear un rol en la cuenta destino con una trust policy que permita el rol de la cuenta origen

2. La carga de trabajo origen llama a sts:AssumeRole para obtener credenciales temporales

3. Utilizar external IDs para prevenir ataques de tipo confused deputy cuando intervienen terceros

Opsio configura el acceso entre cuentas con un modelo hub-and-spoke: una cuenta central de seguridad contiene roles de auditoría que pueden leer (pero no escribir) en todas las cuentas miembro. Este diseño soporta tanto las operaciones SOC como la recopilación de evidencias de cumplimiento.

Estrategia multicuenta

Dimensiones de cumplimiento normativo: NIS2, GDPR, ENS y DPDPA 2023

La configuración de IAM es referenciada directamente en todos los marcos normativos principales que Opsio gestiona:

Directiva NIS2 (UE) — El artículo 21 exige "políticas de control de acceso" incluyendo la gestión de accesos privilegiados. Las organizaciones clasificadas como entidades esenciales o importantes deben demostrar que los controles de IAM son proporcionados al riesgo, que el acceso privilegiado se monitoriza y que las revisiones de acceso se realizan periódicamente. En AWS, esto se traduce en SCPs, CloudTrail, IAM Access Analyzer y procedimientos documentados de revisión de acceso.

GDPR — El artículo 32 exige "la capacidad de garantizar la confidencialidad, integridad, disponibilidad y resiliencia permanentes de los sistemas y servicios de tratamiento", lo que los reguladores interpretan como inclusivo de la gestión de identidades y accesos. Los responsables del tratamiento deben demostrar que el acceso a datos personales está limitado al personal que lo necesita — lo que implica políticas de IAM delimitadas a tablas específicas de DynamoDB, prefijos de S3 o instancias de RDS que contengan datos de carácter personal.

ENS (Esquema Nacional de Seguridad, España) — El ENS exige la implementación de controles de acceso basados en el principio de mínimo privilegio, la identificación y autenticación de usuarios, y la trazabilidad de las acciones. Para las entidades del sector público español y sus proveedores que operan en eu-south-2 (España) o eu-west-3 (París), esto significa políticas de IAM documentadas, registros de auditoría mediante CloudTrail y evidencia de revisión periódica alineada con las categorías de seguridad del ENS. La AEPD, como autoridad de control en materia de protección de datos, refuerza estos requisitos en lo relativo al tratamiento de datos personales.

DPDPA 2023 (India) — Las obligaciones de la sección 8 para los responsables de datos incluyen implementar "medidas de seguridad razonables". Para las empresas indias que ejecutan cargas de trabajo en ap-south-1 (Bombay) o ap-south-2 (Hyderabad), esto se traduce en controles de IAM documentados, pistas de auditoría y evidencia de revisión periódica — similares en espíritu a los requisitos del artículo 32 del GDPR.

El denominador común: los cuatro marcos exigen no solo que los controles existan, sino que se monitoricen y revisen. La configuración de IAM sin registro mediante CloudTrail y revisiones de acceso periódicas no satisface ninguno de ellos.

Errores habituales de IAM que encuentra el SOC de Opsio

Basados en incidentes reales y hallazgos de auditoría en nuestras cuentas gestionadas:

1. ARN de recurso con comodín en políticas de producción — "Resource": "*" es aceptable durante el prototipado. En producción, significa que un principal comprometido puede acceder a todos los recursos de ese tipo en la cuenta.

2. Roles de servicio con AdministratorAccess — Las funciones Lambda y las tareas ECS deben tener execution roles estrictamente delimitados. Adjuntar acceso de administrador "porque es más fácil" convierte cada vulnerabilidad de aplicación en un compromiso completo de la cuenta.

3. Cuentas miembro sin SCPs de protección — Sin SCPs, cualquier administrador de cuenta puede concederse cualquier permiso. Los SCPs son el único mecanismo que restringe incluso al usuario root de la cuenta (en cuentas miembro).

4. Usuarios de IAM y claves de acceso obsoletos — Encontramos habitualmente usuarios de IAM de empleados que dejaron la organización hace meses o años. Utiliza la regla iam-user-unused-credentials-check de AWS Config y configúrala para alertar sobre credenciales sin uso durante 45 días.

5. Ignorar las políticas basadas en recurso — Las políticas de bucket de S3, las políticas de clave de KMS y las políticas de cola de SQS pueden conceder acceso de forma independiente a las políticas de identidad. Un bucket de S3 con "Principal": "*" en su política es accesible públicamente, independientemente de lo restrictivos que sean tus roles de IAM.

Cómo empezar: Una secuencia práctica

Para organizaciones que no han formalizado la gobernanza de IAM, este es el orden que produce resultados más rápido:

1. Activar CloudTrail en todas las cuentas y todas las regiones, registrando en un bucket de S3 centralizado en una cuenta de archivo de logs

2. Activar IAM Access Analyzer en cada cuenta (es gratuito)

3. Migrar el acceso humano de usuarios de IAM a IAM Identity Center con MFA

4. Desplegar SCPs de línea base — denegar regiones no utilizadas, proteger la infraestructura de auditoría, exigir cifrado

5. Auditar los roles y políticas de IAM existentes — utilizar los hallazgos de Access Analyzer para identificar roles sin uso y políticas sobre-permisivas

6. Implementar Infrastructure as Code para todos los recursos de IAM — no más ClickOps en la consola de IAM

Migración y modernización en la nube

Esta secuencia funciona tanto si tienes 2 cuentas como 200. La diferencia está en cuánto tarda el paso 5.

Preguntas frecuentes

¿Qué son los controles de acceso de IAM?

Los controles de acceso de IAM son las políticas, los roles y los mecanismos dentro de AWS Identity and Access Management que determinan qué principales (usuarios, roles, servicios) pueden ejecutar qué acciones sobre qué recursos. Funcionan con un modelo de denegación por defecto: a menos que una política permita explícitamente una acción, esta se deniega. Los controles incluyen políticas basadas en identidad, políticas basadas en recurso, permission boundaries, políticas de sesión y Service Control Policies a nivel de organización.

¿IAM es RBAC o ABAC?

AWS IAM soporta ambos modelos. El control de acceso basado en roles (RBAC) se implementa creando roles de IAM con conjuntos de permisos específicos y asignándolos a usuarios o grupos. El control de acceso basado en atributos (ABAC) utiliza etiquetas en los principales y en los recursos para tomar decisiones de autorización dinámicas. AWS recomienda ABAC para escalar en múltiples cuentas porque reduce el número de políticas distintas que gestionar. La mayoría de los entornos de producción emplean un modelo híbrido de ambos.

¿Qué es el acceso IAM en AWS?

El acceso IAM en AWS se refiere a la capacidad autenticada y autorizada de un principal — un usuario de IAM, una identidad federada o un rol de IAM — para interactuar con los servicios y recursos de AWS. Cada llamada a la API de AWS se evalúa contra las políticas de IAM. El acceso solo se concede cuando las políticas aplicables producen un Allow explícito y ninguna política aplicable produce un Deny explícito.

¿Cuáles son los 4 pilares de IAM?

Los cuatro pilares habitualmente referenciados en la gestión de identidades son: autenticación (demostrar quién eres), autorización (qué tienes permitido hacer), administración (gestionar identidades y políticas a escala) y auditoría (registrar y revisar la actividad de acceso). En términos de AWS, se corresponden respectivamente con los mecanismos de autenticación de IAM, las políticas de IAM, AWS Organizations/IAM Identity Center y AWS CloudTrail.

¿Cómo se relaciona AWS IAM con el cumplimiento de NIS2?

NIS2 exige que las entidades esenciales e importantes implementen políticas de control de acceso proporcionadas al riesgo, mantengan capacidades de respuesta ante incidentes y demuestren responsabilidad sobre el acceso privilegiado. AWS IAM proporciona los controles técnicos — MFA, políticas de mínimo privilegio, SCPs, registro con CloudTrail — pero el cumplimiento requiere procesos documentados, revisiones periódicas de acceso y evidencia de que dichos controles se monitorizan activamente. Un SOC gestionado cubre la brecha entre tener los controles y demostrar que funcionan.