Si tu empresa opera en AWS, hay una verdad incómoda que nadie quiere escuchar: tener tu infraestructura en la nube no significa que esté segura. Los errores críticos de seguridad en AWS son más comunes de lo que creés — y la mayoría de los equipos los comete sin saberlo.
AWS opera bajo un modelo de responsabilidad compartida: ellos protegen la infraestructura física, vos protegés lo que construís encima. Y ahí es exactamente donde la mayoría de los equipos falla. En este post desglosamos los 6 errores más críticos que vemos repetirse una y otra vez — desde startups hasta empresas con equipos de DevOps maduros.
Buckets S3 con acceso público sin saberlo
Este es probablemente el error de seguridad en AWS más clásico y, aun así, sigue apareciendo en titulares. Empresas que exponen bases de datos completas, backups, documentos internos o información de clientes al internet público… sin darse cuenta.
Un desarrollador crea un bucket de prueba con acceso público “por un momento” y nunca lo revierte. Se configuran Bucket Policies o ACLs demasiado permisivas sin entender su alcance. Se deshabilita “Block Public Access” para hacer funcionar una integración rápida. O se usan scripts de Infrastructure as Code copiados de Stack Overflow sin revisar los permisos.
Un bucket S3 público es como dejar la puerta de tu oficina abierta con un letrero que dice “pase sin tocar”. Cualquier bot que escanee rangos de buckets puede descargar su contenido completo. Se han documentado filtraciones masivas de datos de salud, financieros y credenciales por este único error.
- Activá S3 Block Public Access a nivel de cuenta, no solo de bucket individual.
- Usá AWS Access Analyzer for S3 para identificar buckets con acceso externo.
- Implementá SCPs en AWS Organizations que impidan crear buckets públicos.
- Auditá regularmente con consultas de AWS Config que detecten cambios en políticas de acceso.
Security Groups abiertos al mundo con 0.0.0.0/0
Si alguna vez abriste el puerto 22 (SSH) o 3389 (RDP) a 0.0.0.0/0 para “probar algo rápido”, no estás solo. Pero esa regla temporal que nunca se eliminó es una de las puertas de entrada más explotadas por atacantes en AWS.
Muchos equipos confían en que “nadie va a encontrar esa IP”. Eso es falso: los escáneres de puertos automatizados recorren todo el rango de IPs de AWS en cuestión de horas. Un puerto SSH abierto combinado con credenciales débiles es una receta para el desastre.
Nunca usés 0.0.0.0/0 para puertos de administración. Usá AWS Systems Manager Session Manager para acceso sin ningún puerto abierto. Implementá reglas en AWS Config que marquen como no conforme cualquier Security Group con 0.0.0.0/0 en puertos sensibles, y activá VPC Flow Logs para monitorear tráfico sospechoso.
No cifrar datos en reposo ni en tránsito
Muchos equipos asumen que por estar en AWS sus datos “ya están protegidos”. La realidad es que el cifrado no viene habilitado por defecto en todos los servicios, y sin él, cualquier acceso no autorizado se convierte inmediatamente en una brecha de datos utilizable.
Sin cifrado en reposo, cualquier persona con acceso a un snapshot filtrado puede leer tus datos directamente. Sin cifrado en tránsito, un ataque man-in-the-middle puede interceptar tokens, credenciales o datos personales. Además, regulaciones como GDPR, HIPAA, SOC 2 y PCI-DSS exigen cifrado obligatorio — no tenerlo es un riesgo de cumplimiento legal, no solo técnico.
Habilitá el cifrado por defecto en EBS a nivel de cuenta. Usá AWS KMS con Customer Managed Keys (CMK) para servicios críticos. Configurá políticas de bucket S3 que rechacen uploads sin cifrado. Enforce TLS 1.2+ en todos los endpoints, load balancers y distribuciones CloudFront.
Usar la cuenta root de AWS para operaciones diarias
La cuenta root de AWS es la llave maestra de tu infraestructura. Tiene acceso ilimitado a todo: facturación, eliminación de recursos, cambio de configuraciones de seguridad y cierre de la cuenta. Usarla para tareas cotidianas es uno de los errores de seguridad en AWS más peligrosos que existen.
- El fundador o CTO configuró la cuenta original y sigue usando esas mismas credenciales.
- No se crearon usuarios IAM separados porque “somos un equipo pequeño”.
- Las credenciales root se comparten entre miembros del equipo por chat o email.
- No se activó MFA porque “nadie más tiene la contraseña”.
Si las credenciales root se comprometen, el atacante tiene control total. Puede eliminar todos tus recursos, crear nuevas cuentas de acceso, minar criptomonedas con tus instancias, exfiltrar todos tus datos y borrar los logs para cubrir sus huellas. No existe política IAM que restrinja a la cuenta root.
Activá MFA en la cuenta root inmediatamente — preferiblemente con un dispositivo de hardware como YubiKey. Eliminá todas las access keys asociadas a root. Creá usuarios IAM individuales para cada persona del equipo con permisos específicos. Usá AWS Organizations con SCPs para establecer barreras de protección a nivel organizacional.
Usar Access Keys estáticas en lugar de IAM Roles
Este es un error silencioso pero extremadamente peligroso. Muchos equipos generan Access Keys (AWS_ACCESS_KEY_ID / AWS_SECRET_ACCESS_KEY) para que sus aplicaciones o scripts se autentiquen con AWS. El problema no es la autenticación en sí, sino cómo se gestionan esas claves.
Existen bots que escanean GitHub en tiempo real buscando claves de AWS. En minutos, una clave expuesta puede ser usada para lanzar cientos de instancias EC2 para minar criptomonedas a tu costo. Las Access Keys son credenciales permanentes — no expiran a menos que las rotés manualmente.
Usá IAM Roles en lugar de Access Keys siempre que sea posible. EC2, Lambda, ECS, EKS y casi todos los servicios de AWS permiten asumir roles sin claves estáticas. Si necesitás claves programáticas, usá AWS STS para generar credenciales temporales. Agregá herramientas como git-secrets o truffleHog en tu pipeline de CI/CD.
Ignorar las alertas de AWS Config y Security Hub
Muchos equipos dan el primer paso correcto: activan AWS Config, Security Hub o GuardDuty. Pero luego cometen el error de no actuar sobre los hallazgos. Es como instalar una alarma de incendios y desconectar la sirena porque “suena mucho”.
- Se activan los servicios durante una auditoría y luego nadie los revisa.
- El dashboard acumula cientos de findings que nadie prioriza ni asigna.
- No se configuran notificaciones para findings críticos.
- El equipo sufre de “alert fatigue”: tantas alertas que todas parecen ruido.
Tener visibilidad sin acción es lo mismo que no tener visibilidad. Cada alerta ignorada es una ventana de oportunidad para un atacante. Peor aún: en caso de una auditoría, tener hallazgos documentados pero sin resolver demuestra negligencia con implicaciones legales.
Establecé un proceso de triage semanal de findings críticos y altos. Configurá notificaciones automáticas vía EventBridge → SNS → Slack/Teams para severidades CRITICAL y HIGH. Implementá remediación automática con AWS Config Auto Remediation o Lambda para los findings más comunes. Define ownership: cada tipo de finding debe tener un equipo o persona responsable.
| Error | Severidad | Primera acción |
|---|---|---|
| Buckets S3 públicos | Crítico | S3 Block Public Access a nivel de cuenta |
| Security Groups 0.0.0.0/0 | Crítico | SSM Session Manager + reglas AWS Config |
| Sin cifrado en reposo/tránsito | Crítico + Legal | EBS Encryption by Default + KMS CMK |
| Uso de cuenta root | Crítico | MFA en root + eliminar access keys |
| Access Keys estáticas | Crítico | IAM Roles + AWS STS credenciales temporales |
| Alertas ignoradas | Alto + Legal | Triage semanal + notificaciones automáticas |
Los errores de seguridad en AWS más comunes son: buckets S3 con acceso público no intencional, Security Groups abiertos a 0.0.0.0/0, ausencia de cifrado en reposo y en tránsito, uso de la cuenta root para operaciones diarias, Access Keys estáticas en lugar de IAM Roles, e ignorar los hallazgos de AWS Config y Security Hub. La mayoría son prevenibles con configuraciones que deberían existir desde el primer día de infraestructura. Corregirlos no requiere herramientas adicionales — requiere procesos y defaults correctos desde el inicio.
¿Y si todos estos errores no existieran desde el primer día?
SleakOps entrega infraestructura en AWS que nace segura: buckets con bloqueo público enforced, Security Groups restrictivos de base, cifrado habilitado en todos los servicios, cero Access Keys estáticas, y monitoreo activo con alertas configuradas desde el día uno.
Conocé SleakOps →