AWS en México: los 10 errores de configuración más peligrosos

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-bucket

Có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-rol

Có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 required

Error 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.