Errores de configuración en cloud que más se repiten

La mayoría de brechas en cloud no explotan un fallo de AWS, Azure o Google Cloud. Explotan algo que el cliente configuró mal. Es lo que dice el modelo de responsabilidad compartida: el proveedor responde de la seguridad de la nube (centros de datos, hipervisor, red física) y tú de la seguridad en la nube (identidades, datos, configuración de cada servicio). Gartner llegó a predecir que hasta 2025 el 99 % de los fallos de seguridad en cloud serían responsabilidad del cliente.

Esta es la lista corta que miraría primero en una cuenta cloud desconocida, ordenada por el daño que hace cada fallo.

1. Almacenamiento expuesto a internet

Buckets de S3, contenedores de Azure Blob o buckets de GCS con acceso público. Es el clásico de las filtraciones de datos. AWS activa Block Public Access por defecto en los buckets nuevos desde abril de 2023, pero los antiguos siguen como estaban y cualquiera con permisos puede desactivarlo.

Qué mirar: Block Public Access a nivel de cuenta, no solo de bucket, y una alerta si alguien lo cambia.

2. Claves de acceso de larga duración

Access keys de IAM creadas hace años, asignadas a un usuario que ya no existe en la empresa, con permisos de administrador y pegadas en algún script. Es la credencial ideal para un atacante: no caduca y no tiene MFA.

Qué mirar: claves con más de 90 días, claves sin uso reciente, y si se pueden sustituir por roles con credenciales temporales. Cuando una de esas claves acaba en un repositorio, el problema es el que cuento en cómo se filtran los secretos en Git.

3. Roles con permisos de más

Políticas con "Action": "*" o "Resource": "*" porque "así funcionaba". La brecha de Capital One de 2019 combinó un SSRF en una aplicación web con el servicio de metadatos de la instancia (IMDSv1) y un rol con acceso a demasiados buckets. Sin ese rol sobredimensionado, el SSRF se habría quedado en poca cosa.

Qué mirar: exigir IMDSv2 en las instancias, y usar las herramientas del propio proveedor (IAM Access Analyzer en AWS, por ejemplo) para ver qué permisos no se usan nunca.

4. Puertos de administración abiertos a 0.0.0.0/0

SSH (22) y RDP (3389) abiertos a todo internet en un security group o un NSG. Los escáneres los encuentran en minutos. La alternativa es un bastión, acceso a través del propio proveedor (Session Manager, Azure Bastion, IAP) o al menos restringir por IP de origen.

5. Logs apagados o sin retención

CloudTrail desactivado en alguna región, Azure Activity Log sin exportar, logs de acceso de almacenamiento sin habilitar. No impide el ataque, pero cuando llega el incidente no hay forma de saber qué pasó. Sin logs, la investigación se queda en suposiciones.

6. Identidad débil en la consola

La cuenta raíz de AWS sin MFA, o con access keys propias. Usuarios de consola sin MFA. Es la versión cloud del mismo problema de siempre, y se arregla con MFA resistente a phishing y mínimo privilegio.

Revisarlo una vez no sirve: CSPM

Todo lo anterior se puede revisar a mano, pero la configuración cambia cada día. Las herramientas de CSPM (Cloud Security Posture Management) comprueban la configuración de forma continua contra marcos como los CIS Benchmarks y avisan cuando algo se desvía. Los proveedores tienen la suya (AWS Security Hub, Microsoft Defender for Cloud) y plataformas como Trend Micro Vision One también lo cubren. Para empezar sin coste, Prowler es de código abierto y muy completo.

Preguntas frecuentes

¿Qué es el modelo de responsabilidad compartida?

El reparto de quién protege qué en la nube. El proveedor protege la infraestructura; el cliente, todo lo que configura encima. Cuanto más gestionado es el servicio (SaaS frente a IaaS), más parte asume el proveedor, pero las identidades y los datos siempre son tuyos.

¿Qué es CSPM?

Una categoría de herramientas que evalúan de forma continua la configuración de tus cuentas cloud contra buenas prácticas y normativas, y detectan desviaciones como un bucket que se ha vuelto público.

¿Por dónde empiezo si solo tengo una tarde?

MFA en la cuenta raíz y en todos los administradores, Block Public Access a nivel de cuenta y CloudTrail (o el equivalente) activo en todas las regiones.