Las malas configuraciones cloud más comunes (y cómo detectarlas)
La mayoría de los incidentes en la nube no empiezan con un zero-day ingenioso en AWS, Azure o Google Cloud. Empiezan con un ajuste: un bucket de almacenamiento público, un puerto de administración abierto a todo Internet, una clave de acceso subida a un repositorio, un rol de administrador concedido "solo de momento". Los proveedores protegen la plataforma; cómo la configuras depende de ti.
La buena noticia es que estos errores se repiten muchísimo. El mismo puñado de malas configuraciones aparece en distintos proveedores, equipos y sectores. Si sabes cuáles son y las revisas de forma continua, eliminas una gran parte del riesgo evitable en la nube. En este artículo repasamos las más recurrentes, explicamos el modelo de responsabilidad compartida que hay detrás y vemos por qué la gestión de la postura cloud tiene que ser continua y no una auditoría anual.
El modelo de responsabilidad compartida en un párrafo
Todos los grandes proveedores cloud publican un modelo de responsabilidad compartida. El proveedor es responsable de la seguridad de la nube: centros de datos, hardware, hipervisor e infraestructura de los servicios gestionados. Tú eres responsable de la seguridad en la nube: identidades y permisos, reglas de red, protección de datos, registros y la configuración de cada servicio. La frontera exacta varía según el tipo de servicio (IaaS, PaaS, SaaS), pero la configuración casi siempre queda de tu lado. Por eso la mala configuración es el riesgo cloud predominante: está justo en la mitad que le toca al cliente.
Las malas configuraciones que se repiten
1. Almacenamiento accesible públicamente
Almacenamiento de objetos como buckets de S3, contenedores de Azure Blob o buckets de Google Cloud Storage que permiten acceso anónimo o demasiado amplio. A veces es intencionado para recursos de una web y luego se reutiliza para algo sensible; otras es una prueba que nunca se limpió. Los proveedores ofrecen controles de "bloqueo de acceso público" a nivel de cuenta, y deberías usarlos por defecto.
2. Security groups y puertos de administración abiertos
Reglas de red que permiten tráfico entrante desde cualquier origen (0.0.0.0/0) a SSH, RDP, puertos de bases de datos o interfaces de administración. Herramientas automáticas los escanean sin parar. El acceso de administración debe pasar por un bastión, VPN, proxy con control de identidad o el gestor de sesiones del proveedor, nunca directamente desde Internet. Mira por qué la exposición a Internet cambia la prioridad.
3. Identidades con privilegios excesivos
Usuarios IAM, roles, service principals y cuentas de servicio con permisos comodín, roles amplios de "Owner" o "Administrator", o permisos que nunca usan. El exceso de privilegios convierte un pequeño punto de apoyo en el control total de la cuenta. Aplica mínimo privilegio, revisa los permisos sin uso y prefiere credenciales temporales de rol frente a usuarios de larga duración.
4. Cuentas privilegiadas y root sin MFA
Cuentas root o de administrador global sin MFA, o usuarios de consola que entran solo con contraseña. Son objetivos de alto valor, sobre todo cuando las credenciales se filtran a través de logs de infostealers.
5. Datos sin cifrar o sin protección
Discos, bases de datos y snapshots sin cifrado en reposo, bases de datos sin copias automáticas, snapshots compartidos públicamente o copias guardadas en la misma cuenta que un atacante comprometería. El cifrado suele ser una casilla; la capacidad de recuperación es una decisión de diseño que hay que tomar a propósito.
6. Registros y monitorización desactivados
Registros de auditoría (CloudTrail, Azure Activity Log, Cloud Audit Logs) apagados, sin retención o no habilitados en todas las regiones. Sin ellos no puedes detectar abusos ni investigar un incidente a posteriori.
7. Claves de acceso y secretos expuestos
Claves de acceso de larga duración incrustadas en código, imágenes de contenedor, variables de CI o repositorios públicos. Una clave filtrada con permisos amplios equivale a una contraseña de tu cuenta. Rota las claves, prioriza las identidades de workload y analiza el código y el historial de git en busca de secretos, como explicamos en nuestra guía de SAST, SCA, secretos e IaC.
Por qué la gestión de la postura debe ser continua
Los entornos cloud cambian cada día. Pipelines, desarrolladores y automatizaciones crean recursos nuevos; los permisos se desvían; una regla "temporal" se vuelve permanente. Una revisión puntual queda obsoleta casi en cuanto termina. La gestión de la postura de seguridad cloud (CSPM) resuelve esto conectándose a tus cuentas, inventariando recursos y evaluando su configuración de forma repetida frente a las buenas prácticas conocidas.
Una práctica de CSPM útil incluye:
- Inventario completo de todas las cuentas, suscripciones y proyectos, no solo de los que recuerdas.
- Escaneos programados y repetidos, para detectar la desviación poco después de que aparezca.
- Contexto de exposición: saber qué recursos son realmente accesibles desde Internet cambia qué arreglas primero.
- Responsables y seguimiento: hallazgos asignados al equipo dueño del recurso, con plazo, en lugar de un informe estático.
Errores a evitar
- Tratar todos los hallazgos por igual. Un bucket público con imágenes de marketing y otro con exportaciones de clientes no son el mismo problema. Prioriza por exposición y sensibilidad del dato.
- Corregir en la consola pero no en el código. Si la infraestructura se define como código, el siguiente despliegue reintroduce el problema. Corrige también la plantilla.
- Analizar un solo proveedor. La mayoría de organizaciones son multicloud en la práctica, aunque sea sin querer.
- Olvidar la relación con los workloads. Un security group mal configurado importa más cuando la máquina que protege tiene una vulnerabilidad explotable. Eso es una combinación tóxica.
Preguntas frecuentes
¿CSPM es lo mismo que un escáner de vulnerabilidades? No. CSPM evalúa cómo están configurados los servicios cloud; el escaneo de vulnerabilidades busca software con fallos en los workloads. Necesitas ambos, idealmente correlacionados.
¿El acceso de solo lectura limita lo que puede hacer un CSPM? Basta para inventariar recursos y evaluar la configuración, y evita dar a una herramienta de seguridad capacidad para modificar tu entorno.
¿Con qué frecuencia conviene escanear? Con la suficiente para que una desviación no dure semanas. Los escaneos programados con una cadencia regular son el mínimo.
Cómo ayuda priorIQ.ai
CloudIQ, el módulo CSPM de priorIQ.ai, se conecta en modo solo lectura a AWS, Azure, GCP y Cloudflare para construir el inventario de recursos, detectar malas configuraciones, mapear la topología de red y clasificar qué recursos están expuestos a Internet. Ejecuta escaneos programados, mide KPIs de postura y vincula los recursos cloud con los activos y agentes que ya monitorizas, de modo que una mala configuración y una vulnerabilidad en el mismo workload se ven juntas. PriorIQ Core deduplica y prioriza esos hallazgos con el resto de tus datos de exposición y puede enviarlos a Jira, ServiceNow o Freshservice.