Grupos IAM en AWS: Por Qué Nunca Deberías Adjuntar Políticas Directamente a Usuarios
Cuando el equipo crece de dos a veinte ingenieros, adjuntar políticas directamente a cada usuario de IAM deja de ser un problema de estilo y se convierte en un problema operacional real: permisos inconsistentes, auditorías imposibles y el clásico 'ese usuario tiene acceso a producción pero no sé por qué'. Los grupos de IAM existen precisamente para evitar ese caos.
TL;DR: Grupos IAM vs. Políticas Directas en Usuarios
| Criterio | Política directa en usuario | Política en grupo IAM |
|---|---|---|
| Escalabilidad | Cada usuario requiere gestión individual | Un cambio en el grupo afecta a todos los miembros |
| Consistencia de permisos | Alta probabilidad de desviación entre usuarios | Permisos uniformes garantizados por diseño |
| Auditoría | Requiere revisar cada usuario individualmente | Un solo punto de revisión por rol |
| Onboarding/Offboarding | Proceso manual y propenso a errores | Añadir o remover del grupo es suficiente |
| Principio de menor privilegio | Difícil de mantener a escala | Aplicable y auditable de forma centralizada |
Cómo Funcionan los Grupos IAM
Un grupo IAM no es una identidad — no puede autenticarse, no tiene credenciales y no puede ser principal en una política de recursos. Es un contenedor lógico que permite adjuntar políticas una sola vez y aplicarlas a todos los usuarios miembros simultáneamente.
Cuando un usuario pertenece a un grupo, IAM evalúa las políticas adjuntas al grupo exactamente igual que si estuvieran adjuntas directamente al usuario. La evaluación de permisos efectivos combina políticas del usuario, políticas de todos sus grupos y cualquier política de sesión aplicable.
(si existe)"] P1 --> EVAL["Evaluación IAM
Unión de permisos"] P2 --> EVAL P3 --> EVAL EVAL --> DENY{"¿Explicit Deny?"} DENY -- Sí --> BLOCK["Acceso Denegado"] DENY -- No --> ALLOW{"¿Allow aplicable?"} ALLOW -- Sí --> RESOURCE["Recurso AWS"] ALLOW -- No --> BLOCK2["Acceso Denegado
(implicit deny)"]
- Usuario IAM: La identidad que se autentica. Puede pertenecer a múltiples grupos (máximo 10 por usuario).
- Grupo 'Developers': Contiene la política de permisos para el rol de desarrollo. Un cambio aquí se propaga a todos los miembros automáticamente.
- Grupo 'ReadOnly': Un usuario puede pertenecer a ambos grupos simultáneamente; IAM une los permisos de todos los grupos.
- Evaluación IAM: Combina políticas de usuario + grupos. Un Explicit Deny en cualquier política bloquea el acceso independientemente de los Allow restantes.
- Recurso AWS: El acceso final depende también de políticas de recursos (bucket policies, etc.) y SCPs si aplican.
Por Qué las Políticas Directas en Usuarios Son un Anti-Patrón
La tentación es comprensible: el usuario necesita acceso a S3, adjuntas la política, listo. El problema aparece tres meses después cuando ese mismo permiso necesita ser actualizado para diez usuarios y nadie recuerda cuáles tienen qué variante de la política.
Gestionar permisos por usuario es como configurar reglas de firewall individualmente en cada servidor en lugar de usar grupos de seguridad. Funciona hasta que tienes que cambiar algo.
El problema estructural es la desviación de configuración: con el tiempo, cada usuario acumula permisos ligeramente diferentes según quién los configuró y cuándo. Auditar ese estado es costoso; corregirlo, más aún.
Hay un segundo problema menos obvio: las políticas inline adjuntas directamente a usuarios no son reutilizables. Si defines la misma política inline en diez usuarios, tienes diez copias independientes que pueden divergir. Las políticas administradas adjuntas a grupos son una sola fuente de verdad.
Implementación: Crear un Grupo IAM 'Developers' con AWS CLI
El flujo completo implica crear el grupo, adjuntar la política y añadir usuarios. Cada paso es independiente y auditable.
Paso 1 — Crear el grupo. Antes de cualquier otra acción, el grupo debe existir. Este es el contenedor que reemplazará todas las asignaciones directas dispersas.
aws iam create-group \
--group-name DevelopersPaso 2 — Adjuntar una política administrada al grupo. Adjuntar la política al grupo en lugar de a usuarios individuales es el cambio arquitectónico central. A partir de este momento, cualquier usuario que se añada al grupo hereda estos permisos automáticamente.
aws iam attach-group-policy \
--group-name Developers \
--policy-arn arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccessPaso 3 — Añadir un usuario al grupo. El onboarding de un nuevo desarrollador se reduce a este único comando. No hay que recordar qué políticas adjuntar — el grupo lo define.
aws iam add-user-to-group \
--group-name Developers \
--user-name juan.perezPaso 4 — Verificar la membresía del grupo. Confirmar que el usuario está en el grupo y que las políticas están adjuntas correctamente cierra el loop de verificación. Esto también es lo que ejecutarías durante una auditoría.
aws iam get-group \
--group-name Developersaws iam list-attached-group-policies \
--group-name DevelopersPaso 5 — Verificar los permisos efectivos del usuario. Los permisos efectivos de un usuario son la unión de todas sus políticas directas y de grupo. Este comando muestra exactamente qué puede hacer el usuario, independientemente de cómo llegaron esos permisos — crítico para auditorías y para depurar accesos inesperados.
aws iam list-groups-for-user \
--user-name juan.perezPolítica IAM Mínima para Gestionar Grupos
Si necesitas delegar la gestión de grupos a un administrador junior o a un proceso automatizado, esta es la política de menor privilegio para permitir solo las operaciones de membresía sin capacidad de modificar políticas.
🔽 Ver política IAM para gestión de grupos (click para expandir)
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "ManageGroupMembership",
"Effect": "Allow",
"Action": [
"iam:AddUserToGroup",
"iam:RemoveUserFromGroup",
"iam:GetGroup",
"iam:ListGroupsForUser"
],
"Resource": "arn:aws:iam::123456789012:group/Developers"
},
{
"Sid": "ListUsersAndGroups",
"Effect": "Allow",
"Action": [
"iam:ListUsers",
"iam:ListGroups",
"iam:ListAttachedGroupPolicies"
],
"Resource": "*"
}
]
}Nota: iam:ListUsers, iam:ListGroups y iam:ListAttachedGroupPolicies requieren "Resource": "*" porque son operaciones de listado que no soportan restricción a nivel de recurso específico según la Service Authorization Reference de IAM.
El Patrón que Rompe las Suposiciones: Múltiples Grupos y Deny Explícito
Aquí está la parte que la mayoría aprende de la peor manera posible en producción.
Un usuario pertenece al grupo Developers (con acceso a S3) y al grupo SecurityAudit. El equipo de seguridad adjunta una política al grupo SecurityAudit con un Deny explícito sobre s3:DeleteObject para todos los recursos. El desarrollador reporta que ya no puede eliminar objetos aunque 'tiene el permiso en su grupo'.
El comportamiento es correcto y documentado: un Explicit Deny siempre sobrescribe cualquier Allow, independientemente de en qué grupo o política esté ese Allow. La evaluación de políticas IAM aplica esta regla sin excepción. El error fue asumir que los permisos de grupos se suman sin interferencia.
s3:DeleteObject"] A --> EVAL["Evaluación IAM"] D --> EVAL EVAL --> RESULT["Acceso DENEGADO
Deny tiene precedencia absoluta"]
- Allow en grupo Developers: Otorga
s3:DeleteObject. - Explicit Deny en grupo SecurityAudit: Deniega
s3:DeleteObject. - Evaluación IAM: El Deny explícito tiene precedencia absoluta sobre cualquier Allow.
- Resultado: Acceso denegado, aunque el Allow existe en otro grupo.
Para diagnosticar este escenario sin revisar cada política manualmente:
aws iam simulate-principal-policy \
--policy-source-arn arn:aws:iam::123456789012:user/juan.perez \
--action-names s3:DeleteObject \
--resource-arns arn:aws:s3:::mi-bucket-produccion/*Este comando simula la evaluación completa de políticas para el usuario especificado, incluyendo todas las políticas de sus grupos, y devuelve el resultado efectivo con la razón de la decisión.
Offboarding: El Caso de Uso que Justifica los Grupos por Sí Solo
Un ingeniero deja la empresa. Con políticas directas, el proceso correcto es revocar cada política adjunta al usuario, verificar políticas inline, verificar membresías en grupos, deshabilitar credenciales y eliminar claves de acceso. Si alguien omite un paso, el usuario deshabilitado podría tener permisos residuales que compliquen una auditoría futura.
Con el modelo de grupos, los permisos funcionales están en los grupos. Remover al usuario de todos los grupos y deshabilitar sus credenciales es suficiente para revocar el acceso operacional inmediatamente, antes incluso de completar el proceso de eliminación formal.
aws iam remove-user-from-group \
--group-name Developers \
--user-name juan.perezaws iam update-login-profile \
--user-name juan.perez \
--password-reset-requiredaws iam list-access-keys \
--user-name juan.perezaws iam update-access-key \
--user-name juan.perez \
--access-key-id AKIAIOSFODNN7EXAMPLE \
--status InactiveLimitaciones Operacionales a Tener en Cuenta
Los grupos IAM tienen restricciones documentadas que afectan el diseño a escala:
- Un usuario puede pertenecer a un máximo de 10 grupos. Si tu modelo de permisos requiere más, es una señal de que la granularidad de los grupos necesita revisión.
- Los grupos no pueden anidarse. Un grupo no puede ser miembro de otro grupo. La jerarquía de permisos debe modelarse con múltiples grupos planos, no con herencia.
- Los grupos son específicos de una cuenta AWS. No se replican entre cuentas en entornos multi-cuenta — para ese caso, IAM Identity Center (sucesor de AWS SSO) es la herramienta apropiada.
Pricing y límites de cuotas de servicio varían — verifica siempre la documentación oficial de AWS para valores actualizados.
Conclusión: Grupos IAM y Próximos Pasos
La pregunta inicial tiene una respuesta directa: adjuntar políticas directamente a usuarios es un anti-patrón que escala mal, dificulta auditorías y aumenta el riesgo operacional. Los grupos IAM son la herramienta correcta para gestionar permisos a escala, y su adopción es el primer paso hacia un modelo de identidad auditable.
Para entornos multi-cuenta o equipos que ya superaron las limitaciones de IAM clásico, el siguiente paso natural es evaluar AWS IAM Identity Center, que extiende este modelo con gestión centralizada de acceso entre cuentas y soporte para proveedores de identidad externos.
Referencias oficiales:
Glosario de Términos Clave
| Término | Definición |
|---|---|
| Grupo IAM | Contenedor lógico de usuarios IAM que permite adjuntar políticas una vez y aplicarlas a todos los miembros. No es una identidad autenticable. |
| Política administrada | Política IAM standalone creada y gestionada independientemente de usuarios o grupos. Reutilizable y versionable. |
| Política inline | Política embebida directamente en un usuario, grupo o rol. No es reutilizable y se elimina con la entidad. |
| Explicit Deny | Declaración de denegación en una política IAM que tiene precedencia absoluta sobre cualquier Allow en cualquier otra política aplicable. |
| Principio de menor privilegio | Práctica de otorgar únicamente los permisos mínimos necesarios para realizar una tarea específica, reduciendo la superficie de riesgo. |
Comentarios
Publicar un comentario