Errores comunes de configuración en la nube

Las configuraciones incorrectas son la principal causa de las filtraciones de datos en la nube. A diferencia de las vulnerabilidades locales tradicionales, que requieren explotar errores de software, las configuraciones incorrectas de la nube suelen ser autoinfligidas y cualquier persona en Internet puede explotarlas fácilmente.

Los buckets de S3 con acceso público de lectura exponen a Internet todos los datos almacenados en ellos. Los atacantes buscan buckets abiertos mediante herramientas como GrayhatWarfare. Prevención: S3 Block Public Access a nivel de cuenta, S3 Object Ownership habilitado y auditorías periódicas de las políticas de los buckets.

Los grupos de seguridad con 0.0.0.0/0 en los puertos 22 (SSH), 3389 (RDP) o puertos administrativos crean superficies de ataque enormes. Restrinja las reglas de entrada a rangos CIDR específicos. Utilice AWS Systems Manager Session Manager en lugar de habilitar SSH públicamente.

Compartir accidentalmente snapshots de RDS de forma pública expone todo el contenido de la base de datos. Los snapshots automatizados son privados de forma predeterminada, pero los que se comparten manualmente pueden exponer datos confidenciales. Audite la visibilidad de los snapshots con describe-db-snapshots --include-public.

Los desarrolladores confirman claves de acceso de AWS, contraseñas de bases de datos y tokens de API en repositorios de Git. Los atacantes analizan GitHub y GitLab con herramientas como TruffleHog y GitLeaks. Prevención: utilice administradores de secretos, hooks de preconfirmación de git-secrets y análisis de secretos en toda la organización.

Sin CloudTrail habilitado en todas las regiones, las llamadas a la API no quedan registradas. Los atacantes aprovechan las brechas de registro para operar sin ser detectados. Habilite CloudTrail en toda la organización y envíe los registros a un bucket de S3 de una cuenta de seguridad independiente, con S3 Object Lock para protegerlos contra manipulaciones.

IMDSv1 permite que cualquier proceso de una instancia de EC2 consulte el servicio de metadatos sin autenticación, lo que posibilita ataques SSRF para robar las credenciales de la instancia. Aplique IMDSv2 (requiere token) en todas las instancias para exigir una autenticación basada en sesiones.

Por lo general, los grupos de seguridad permiten todo el tráfico saliente. Esto posibilita la exfiltración de datos y la comunicación con sistemas de mando y control desde instancias comprometidas. Utilice filtrado de salida mediante grupos de seguridad, NACL o un dispositivo firewall para restringir las conexiones salientes a destinos conocidos.

Los dashboards de Kubernetes, clústeres de Elasticsearch, instancias de MongoDB y notebooks de Jupyter que quedan expuestos en IP públicas sin autenticación se ven comprometidos habitualmente. Toda interfaz de administración debe requerir autenticación y estar restringida a nivel de red.

Los eventos de datos de S3 y los eventos de administración de CloudTrail por sí solos no registran las acciones a nivel de objeto (GetObject, PutObject). Habilite S3 Server Access Logging y los eventos de datos de S3 de CloudTrail para los buckets confidenciales a fin de detectar intentos de exfiltración de datos.

Las reglas de AWS Config con remediación automática (mediante documentos de automatización de SSM o Lambda) pueden corregir automáticamente las infracciones: hacer privados los buckets, cerrar reglas de grupos de seguridad o poner en cuarentena las credenciales, reduciendo el tiempo de exposición de días a minutos.

¿Cuál es el principal riesgo de dejar IMDSv1 habilitado en las instancias de EC2?

Las configuraciones incorrectas de la nube —buckets públicos, grupos de seguridad permisivos, credenciales codificadas y falta de registros— son la causa más común de las filtraciones en la nube. El análisis automatizado, las barreras de protección obligatorias y la supervisión continua son medidas defensivas esenciales.