Un problema común: flexibilizar permisos durante despliegues
En muchos entornos corporativos, especialmente durante fases de desarrollo o despliegues urgentes, los equipos técnicos optan por simplificar las políticas IAM utilizando comodines (wildcards) como "Action": "*" o "Resource": "*". La intención suele ser agilizar procesos temporales, pero estos permisos demasiado amplios casi nunca se eliminan luego.
Esto crea una superficie de ataque significativa: cualquier actor con acceso a ese rol o usuario puede ejecutar operaciones no previstas, incluyendo la modificación de políticas, la creación de tokens de sesión o el borrado de recursos críticos.
En un cliente del sector financiero, detectamos una política heredada con "Effect": "Allow", "Action": "iam:*" y "Resource": "*" asignada a una instancia EC2 en producción. Esto permitió a un atacante interno generar nuevas claves de acceso para otros usuarios privilegiados, escalando privilegios sin generar alertas inmediatas.
Superficie de ataque ampliada y difícil de auditar
Los permisos wildcard no solo permiten más de lo necesario, sino que imposibilitan auditorías efectivas. Detección de mal uso, análisis de mínimo privilegio o validaciones de cumplimiento se vuelven imprecisas o ineficaces.
Amazon CloudTrail registra las acciones realizadas, pero sin conocimiento previo de qué acciones estaban realmente permitidas, es casi imposible distinguir entre uso legítimo y abuso. Esto complica los procesos de respuesta ante incidentes y aumenta el tiempo medio de contención.
- Errores de percepción: Muchos equipos asumen que
Action: *es aceptable si se limita conCondition, pero esto solo funciona si las condiciones están bien diseñadas, lo cual rara vez ocurre fuera de un modelo maduro de control de acceso. - Límites de herramientas de análisis: AWS Access Analyzer detecta wildcards, pero no interpreta contexto. Sin procesos de revisión manual y revisión de propósito, muchas violaciones pasan desapercibidas.
Casos típicos de abuso y escenarios viables de ataque
Un patrón que hemos visto repetidamente es la rotación de tokens o la modificación de roles usando permisos wildcard. Aplicaciones que operan con esas políticas pueden ser subvertidas fácilmente por atacantes internos o mediante vulnerabilidades en aplicaciones web expuestas.
En una auditoría de una empresa de retail digital, un rol otorgado a una lambda tenía acceso wildcard a kms:*. Tras comprometer la ejecución de esa lambda desde un endpoint vulnerable, un atacante obtuvo acceso a desencriptar secretos de múltiples clientes en producción.
Permitir s3:* o ec2:* sobre todos los recursos también facilita escenarios como:
- Data exfiltration: copiar buckets completos sin dejar trazabilidad inmediata.
- Persistence: crear nuevos instancias EC2 con claves personalizadas para mantener acceso persistente.
Cómo hacerlo en la práctica: revisión, detección y hardening
La corrección práctica implica tres pasos clave: identificación de políticas con comodines, análisis de uso efectivo y redefinición basada en privilegios necesarios.
Para identificar políticas con wildcard:
aws iam list-policies --scope Local | \
jq '.Policies[] | select(.Arn) | .Arn' | \
xargs -n1 aws iam get-policy-version --policy-arn <arn> --version-id <version>
Buscar en los JSON resultantes los patrones "Action": "*" o "Resource": "*". Estas deben ser auditadas manualmente. Amazon Identity Analyzer también permite revisar quién tiene acceso real a ciertos recursos, aunque su cobertura aún no es completa.
Al redefinir políticas, usar condiciones como "Condition": {"StringEquals": {"aws:RequestedRegion": "eu-west-1"}} debe ir acompañado de auditorías explícitas de uso. Los permisos deben documentarse con el propósito del uso real, no solo por tipo de servicio.
El anti-patrón: políticas generadas por herramientas automáticas
Una fuente frecuente de problemas son herramientas como AWS Console o frameworks IaC (CloudFormation, Terraform) que generan políticas predefinidas o demasiado amplias durante la creación rápida de recursos. Estas políticas rara vez se corrigen después y quedan como legados inseguros.
En un despliegue con CDK, el uso de iam.ManagedPolicy.fromAwsManagedPolicyName('AdministratorAccess') en entornos de no producción se «replicó» manualmente en producción por simetría. Esto dio acceso completo a todos los servicios sin restricción, con un costo operativo enorme cuando se hizo evidente durante una auditoría externa.
Este tipo de errores produce entornos donde ya no es posible determinar qué parte del sistema tiene permisos críticos. La única solución en esos casos es reescribir las políticas desde cero, lo cual requiere semanas de trabajo dependiendo del tamaño del entorno.
Recomendaciones para entornos corporativos
Reducir o eliminar el uso de permisos wildcard debe ser una prioridad en cualquier programa de hardening. Cada wildcard representa una zona gris en la que un atacante puede moverse con libertad.
Implementar modelos de mínimo privilegio requiere inversión en observabilidad y colaboración entre equipos de seguridad y plataforma. Las herramientas nativas de AWS, como IAM Access Analyzer y CloudTrail, deben integrarse con los procesos internos de revisión y control de cambios.
El diseño adecuado implica:
- Usar políticas gestionadas propias con scopes específicos por entorno y servicio.
- Automatizar la detección de wildcards como parte de pipelines CI/CD o revisiones pre-deploy.
- Capacitar a los equipos en escritura segura de políticas IAM siguiendo guías concretas por producto.
Este tipo de trabajo no se puede delegar solo al equipo de seguridad: debe formar parte del ciclo de vida de desarrollo y operaciones para tener eficacia real y sostenida.
¿Te interesa la seguridad en Cloud?
Comparto análisis técnicos, laboratorios prácticos y experiencias reales sobre Cloud Security.