Permisos excesivos por defecto: el camino fácil que sale caro
Una práctica común en muchas organizaciones es asignar roles o políticas con permisos demasiado amplios para «ganar tiempo» o «no bloquear entregas». El clásico AdministratorAccess, o incluso políticas personalizadas que terminan con comodines como "Action": "*", se convierten en la norma más que la excepción.
Esto suele comenzar como una medida temporal —durante un incidente o una migración— y queda instaurado por falta de revisión posterior. El resultado es una superficie de ataque innecesaria. Hemos visto casos donde un desarrollador con permisos amplios sobre IAM pudo crear usuarios persistentes sin detección, solo porque ningún control lo impedía.
- Acceso total a servicio sin justificación: dar a un equipo permisos sobre EC2 con
*en lugar de limitar a start/stop/reboot si no necesitan crear ni modificar instancias. - Reusar políticas de otras cuentas: copiar políticas de una cuenta sandbox a producción sin revisar el contexto produce efectos peligrosos, como habilitar escritura sobre buckets sensibles.
El anti-patrón aquí es asumir que documentar un uso correcto de los permisos es suficiente para evitar usos indebidos. No lo es. En seguridad, lo que no está explícitamente prohibido, está permitido.
Políticas mal segmentadas por falta de modelo de roles claro
Otro error frecuente surge al no establecer un modelo claro de roles, grupos y relaciones entre ellos. Muchas veces encontramos decenas (incluso cientos) de políticas con nombres similares, permisos duplicados y sin trazabilidad de quién usa qué.
Esto complica tanto el mantenimiento como las auditorías. Hemos trabajado con empresas donde el simple hecho de eliminar un permiso implicaba semanas de revisión funcional por temor a romper alguna integración invisible.
- Mala segmentación: juntar permisos de múltiples dominios (ej. S3, Lambda y RDS) en una sola política impide aplicar fácilmente el principio de mínimo privilegio.
- Grupos de IAM mal usados: dar permisos a través de grupos sin revisar periódicamente sus miembros termina generando «grupos Frankenstein» con privilegios acumulados que nadie se atreve a tocar.
Sugerimos trabajar con un modelo basado en tareas y no en equipos. No es lo mismo el «equipo de backend» que «usuarios que deben hacer deploy de funciones Lambda».
Falta de rotación y control en credenciales persistentes
En muchas empresas, los usuarios IAM con access keys persistentes siguen activos durante años sin rotación ni tracking de uso. Hemos visto organizaciones donde desarrolladores ya desvinculados seguían con claves activas conectadas a pipelines antiguos que nadie se atreve a desmontar.
AWS IAM no fuerza por defecto una política de expiración o rotación de claves. Depende del equipo de seguridad establecer límites y automatizaciones que impongan esta práctica.
- Access Keys sin rotación: claves activas por más de 90 días sin un registro de propósito o revisión presentan un alto riesgo.
- Claves en código: otro problema recurrente en CI/CD es dejar claves embebidas en scripts o repositorios, lo que agrava el impacto en caso de exfiltración.
Una política efectiva combina notificaciones automáticas, auditoría continua via CloudTrail y recertificación periódica por parte del propietario de cada clave.
Ignorar el uso de IAM Access Analyzer o CloudTrail como herramientas de control
IAM ofrece herramientas potentes para mitigar errores humanos, como IAM Access Analyzer y los logs de CloudTrail. A pesar de esto, en múltiples empresas aún se encuentran desactivados o sin monitoreo real. No es raro escuchar: “ni sabíamos que existía Access Analyzer”.
Estas herramientas permiten detectar cuando una política otorga acceso público o entre cuentas de forma no intencional. También ayudan a entender cómo se están utilizando realmente los permisos otorgados, un insumo clave para reducir privilegios de manera segura.
Un caso típico que encontramos es la exposición de buckets S3 o funciones Lambda a otras cuentas por error en las políticas de recurso. Access Analyzer lo habría alertado en minutos, pero nadie lo había configurado.
No usar estas funcionalidades es como operar un entorno productivo a ciegas: funcionalmente puede que todo esté bien, pero en seguridad es un enorme punto ciego.
Recomendaciones para entornos corporativos
Los errores en la gestión de IAM en AWS que hemos descrito no son hipotéticos: los vemos de forma repetida en empresas con estructuras complejas, equipos grandes y presiones de negocio. El denominador común es la falta de gobernanza proactiva sobre el ciclo de vida de los permisos.
Proponemos como líneas de acción prioritarias:
- Revisar y reducir sistemáticamente políticas con comodines
*. - Adoptar un modelo explícito de roles y tareas, con ownership definido por cada permiso.
- Auditar y forzar rotación de claves, con mecanismos automatizados de alerta.
- Activar y monitorear herramientas como IAM Access Analyzer y CloudTrail en todas las cuentas.
La madurez en IAM no se alcanza solo configurando bien, sino operando bien: monitorear, revisar, revocar y, sobre todo, tener control real del acceso en todo momento.
¿Te interesa la seguridad en Cloud?
Comparto análisis técnicos, laboratorios prácticos y experiencias reales sobre Cloud Security.