Por qué AWS en México tiene tantas brechas de configuración
Según Gartner, el 99% de los fallos de seguridad en la nube hasta 2025 fueron responsabilidad del cliente, no de AWS. El modelo de responsabilidad compartida de Amazon es claro: AWS protege la infraestructura; tú proteges lo que pones encima.
El problema es que AWS es extremadamente flexible. En minutos puedes exponer una base de datos a Internet, dar permisos de administrador a una función Lambda o dejar un bucket S3 público sin darte cuenta. En México, el uso de AWS creció exponencialmente en los últimos 3 años — y la madurez en seguridad cloud no creció al mismo ritmo.
Estos son los errores que encontramos con más frecuencia en nuestros pentestings de nube en empresas mexicanas.
Error 1 — S3 Buckets públicos con datos sensibles
El más clásico. Un bucket S3 configurado como público expone todo su contenido a cualquier persona en Internet. Hemos encontrado buckets con:
- Backups de bases de datos completas
- Facturas y contratos con clientes
- Credenciales de acceso en archivos de configuración
- Expedientes de empleados con datos personales
Cómo detectarlo:
aws s3api get-bucket-acl --bucket nombre-del-bucket
aws s3api get-bucket-policy --bucket nombre-del-bucketCómo corregirlo: Habilita “Block Public Access” a nivel de cuenta AWS, no solo por bucket. Audita todos tus buckets con AWS Trusted Advisor o Security Hub.
Error 2 — Roles IAM con permisos AdministratorAccess
El principio de menor privilegio es la regla más violada en AWS. Es fácil asignar AdministratorAccess para “que funcione” durante el desarrollo y olvidarse de restringirlo antes de ir a producción.
Un rol con AdministratorAccess comprometido le da al atacante control total de tu cuenta AWS: puede crear usuarios, acceder a todos los servicios, destruir infraestructura o usarla para minería de criptomonedas.
Cómo detectarlo:
aws iam list-attached-role-policies --role-name nombre-del-rolCómo corregirlo: Aplica políticas con permisos específicos por recurso y acción. Usa AWS IAM Access Analyzer para identificar accesos excesivos.
Error 3 — Access Keys en repositorios de código
Las credenciales de AWS hardcodeadas en código que se sube a GitHub, GitLab o Bitbucket son uno de los vectores más explotados. GitHub tiene bots que escanean repositorios públicos buscando access keys en tiempo real — en minutos de subir una key válida, ya fue encontrada y usada.
Cómo detectarlo: Busca en tu historial de Git:
git log -p | grep -i "aws_access_key\|aws_secret"Cómo corregirlo: Usa variables de entorno, AWS Secrets Manager o Parameter Store. Configura git-secrets o similar para prevenir commits con credenciales.
Error 4 — Security Groups demasiado permisivos
Reglas de Security Group que permiten tráfico de 0.0.0.0/0 (todo Internet) en puertos sensibles como:
- Puerto 22 (SSH): expone el servidor a ataques de fuerza bruta constantes
- Puerto 3389 (RDP): objetivo frecuente de ransomware
- Puerto 3306 (MySQL) o 5432 (PostgreSQL): bases de datos accesibles desde Internet
Cómo corregirlo: Restringe el acceso SSH/RDP a IPs específicas. Usa AWS Systems Manager Session Manager para acceso sin abrir puertos.
Error 5 — CloudTrail deshabilitado o incompleto
CloudTrail es el registro de auditoría de AWS — sin él, no puedes saber qué pasó durante un incidente. Hemos encontrado cuentas donde CloudTrail está deshabilitado, solo cubre algunas regiones, o los logs se guardan en un bucket sin protección contra eliminación.
Un atacante que compromete tu cuenta puede deshabilitar CloudTrail para borrar sus huellas — si no tienes alertas configuradas para ese evento, no sabrás que ocurrió.
Cómo corregirlo: Habilita CloudTrail en todas las regiones con validación de integridad de logs. Configura una alarma CloudWatch para DeleteTrail y StopLogging.
Error 6 — Instancias EC2 con metadata service sin IMDSv2
El servicio de metadatos de EC2 (http://169.254.254.254/) expone credenciales temporales del rol IAM de la instancia. En aplicaciones web con vulnerabilidades SSRF, un atacante puede hacer que el servidor haga una petición a esa URL y obtenga las credenciales.
IMDSv2 agrega una capa de protección requerida que mitiga este ataque. IMDSv1 no tiene esta protección.
Cómo corregirlo: Fuerza IMDSv2 en todas tus instancias EC2 desde la consola o con:
aws ec2 modify-instance-metadata-options \
--instance-id i-xxxx \
--http-tokens requiredError 7 — RDS sin cifrado y accesible públicamente
Bases de datos RDS con publicly accessible: yes y sin cifrado de datos en reposo. Aunque tengas un Security Group restrictivo hoy, un cambio accidental puede exponer la base de datos directamente a Internet.
Cómo corregirlo: Deshabilita acceso público en RDS. Coloca las instancias en subnets privadas. Habilita cifrado con AWS KMS (no se puede activar después de crear la instancia — requiere snapshot y restore).
Error 8 — Sin MFA en la cuenta root y usuarios IAM
La cuenta root de AWS tiene acceso ilimitado a todos los recursos. Si no tiene MFA y las credenciales son comprometidas, el atacante tiene control total de tu cuenta AWS.
Lo mismo aplica para usuarios IAM con permisos elevados que no tienen MFA configurado.
Cómo corregirlo: Habilita MFA virtual o hardware en la cuenta root inmediatamente. Crea una política de IAM que deniegue todas las acciones a usuarios sin MFA activo.
Error 9 — Lambda con variables de entorno en texto plano
Funciones Lambda con credenciales de bases de datos, API keys y tokens en variables de entorno sin cifrar. Cualquier persona con acceso de lectura a la configuración de Lambda puede ver esos valores.
Cómo corregirlo: Usa AWS Secrets Manager o Parameter Store (SecureString) para almacenar secretos. La función Lambda los recupera en tiempo de ejecución con los permisos IAM adecuados.
Error 10 — Sin separación de entornos (dev/staging/prod en la misma cuenta)
Tener desarrollo, staging y producción en la misma cuenta AWS significa que un error en desarrollo puede afectar producción, y que un desarrollador con acceso a dev tiene visibilidad sobre datos de producción.
Cómo corregirlo: Usa AWS Organizations con cuentas separadas por entorno. Control Tower facilita la gestión multi-cuenta con guardrails de seguridad preconfigurados.
¿Cómo saber si tu entorno AWS tiene estos problemas?
Un pentesting de nube evalúa todos estos puntos y más, con explotación real de las vulnerabilidades encontradas para demostrar el impacto. Nuestro equipo cuenta con la certificación MCRTA (Multi-Cloud Red Team Analyst) especializada en AWS, Azure y GCP.
Solicita una evaluación de tu entorno cloud — propuesta técnica en menos de 48 horas.