En 2024, las organizaciones sufrieron una media de nueve incidentes de seguridad cloud, y casi nueve de cada diez reconocen que la cifra sigue aumentando año tras año (fuente: estudio IDC / Microsoft).
El diagnóstico es claro: cada recurso que se añade al cloud es una nueva superficie que defender. Y algunas derivas se cuelan sin que nadie las detecte: un Security Group modificado a toda prisa durante una sesión de debug y que nunca se reconfigura puede dejar un servicio expuesto durante meses sin que nadie se dé cuenta.
Es exactamente este tipo de deriva silenciosa, aparentemente trivial pero potencialmente crítica, lo que el CSPM (Cloud Security Posture Management) está diseñado para corregir: identificar de forma continua los recursos expuestos, detectar desviaciones de configuración, priorizar los riesgos y orquestar la remediación.
En este artículo desglosamos el CSPM: por qué se ha vuelto imprescindible y cómo Cyberwatch permite llevarlo a la práctica, integrando además la protección de workloads (CWPP) y de contenedores, para un enfoque CNAPP completo.
¿Qué es el CSPM y por qué se ha vuelto imprescindible?
Definición y principios fundamentales
El CSPM es un enfoque de ciberseguridad diseñado para evaluar, supervisar y mejorar de forma continua la postura de seguridad de los entornos cloud.
El objetivo es claro: garantizar que los recursos cloud de una organización estén correctamente configurados, expuestos solo en la medida necesaria y alineados con las buenas prácticas de seguridad.
Qué abarca realmente la exposición cloud
La superficie cloud de una organización va mucho más allá de un simple inventario de máquinas virtuales.
Incluye todos los recursos desplegados en los distintos proveedores (AWS, Azure, GCP, OpenStack), así como:
- Las configuraciones asociadas a cada servicio
- Las identidades y los permisos de acceso
- Los datos almacenados en el cloud (buckets S3, bases de datos, copias de seguridad, Azure Blob Storage…)
- Los recursos expuestos públicamente en internet, a veces sin querer
- Los parámetros de red (reglas de seguridad, subredes, interconexiones)
- Los mecanismos de seguridad aplicados (cifrado, autenticación, registro de actividad)
La exposición cloud abarca, en definitiva, todo aquello que en el entorno cloud puede estar accesible, mal configurado o insuficientemente protegido, especialmente si se contrasta con marcos de referencia como los CIS Benchmarks.
Por qué el cloud genera nuevos puntos ciegos
A diferencia de las infraestructuras on-premise, los entornos cloud no son ni estáticos ni centralizados. La adopción masiva del multicloud, ya sea público, privado o híbrido, multiplica los puntos de entrada y fragmenta la visibilidad: los recursos se distribuyen entre varias plataformas, cada una con su propio modelo de gestión.
Pero lo que realmente agrava la situación es la velocidad. Las arquitecturas modernas— contenedores, orquestadores Kubernetes, pipelines CI/CD— generan recursos con ciclos de vida que se miden en minutos, a veces en segundos.
Un pod de Kubernetes puede aparecer, quedar expuesto y desaparecer antes de que nadie haya tenido tiempo de inventariarlo. Una imagen desplegada automáticamente a través de una pipeline CI/CD puede introducir una vulnerabilidad antes de que ningún equipo haya podido detectarla.
A esta complejidad dinámica se suman puntos ciegos más clásicos, pero igual de críticos:
- Entornos de prueba que siguen activos mucho después de haber dejado de usarse
- Permisos de acceso que se acumulan sin revisiones periódicas
- Shadow IT cloud que escapa por completo al radar de los equipos de seguridad
Sin una herramienta dedicada, mantener una visión fiable y actualizada de lo que está realmente expuesto se vuelve imposible.
Una presión regulatoria cada vez mayor
A estos retos técnicos se suma un entorno normativo que no para de endurecerse. La directiva NIS2, aplicable desde octubre de 2024, impone obligaciones reforzadas de gestión del riesgo cibernético con sanciones que pueden alcanzar el 2% de la facturación anual mundial.
ISO 27001, RGPD, SecNumCloud: los marcos normativos que afectan directamente a la seguridad de los entornos cloud se multiplican y exigen ahora una trazabilidad continua, muy por encima de la auditoría anual.
En este contexto, el CSPM se ha convertido en una herramienta tanto de cumplimiento normativo como de seguridad operativa.
El CSPM en la práctica: las 4 funciones clave
1) Inventario automatizado de recursos cloud
Si no lo ves, no puedes protegerlo.
La primera función del CSPM es identificar automáticamente todos los activos desplegados en el cloud— máquinas virtuales, contenedores, servicios gestionados, cuentas de almacenamiento, recursos de red— sea cual sea el proveedor.
Este inventario tiene que ser dinámico: un recurso creado hoy debe aparecer en el perímetro supervisado sin ninguna intervención manual. Es el requisito indispensable para mantener un mapa fiable en entornos donde los despliegues se suceden sin parar.
2) Detección y priorización de riesgos
Una vez identificados los activos, las soluciones CSPM analizan su exposición real. Esto implica detectar las vulnerabilidades conocidas (CVE) que les afectan, pero también identificar desviaciones de configuración: un puerto abierto innecesariamente, un protocolo obsoleto, una clave de acceso desprotegida.
Pero detectar no es suficiente: hay que saber qué corregir primero.
En entornos cloud donde las vulnerabilidades se cuentan por miles, priorizar únicamente en función de la puntuación CVSS bruta se queda corto. El contexto tiene que entrar en juego: la criticidad del activo para el negocio, su nivel de exposición en red y la probabilidad real de que la vulnerabilidad sea explotada.
3) Control continuo del cumplimiento normativo
El CSPM supervisa de forma permanente las configuraciones de los recursos cloud para detectar desviaciones respecto a los marcos de seguridad reconocidos, principalmente los CIS Benchmarks, así como respecto a las políticas internas de cada organización.
Este control continuo es fundamental: una configuración que hoy cumple con los requisitos puede dejar de hacerlo mañana tras una actualización, una modificación manual o un nuevo despliegue. La auditoría anual ya no da la talla.
4) Remediación y orquestación de parches
La última función del CSPM es convertir la detección en acción. Eso significa ofrecer recomendaciones precisas y accionables: no limitarse a señalar una anomalía, sino indicar exactamente qué versión corregir, qué configuración modificar, qué acceso revocar.
En los entornos actuales, la remediación tiene que integrarse de forma natural en los flujos de trabajo existentes: conectarse a las herramientas de ticketing, a las soluciones de patch management y encajar en los procesos de los equipos IT sin generar fricción adicional.
El CSPM con Cyberwatch: del descubrimiento a la remediación
Descubrimiento multicloud (AWS, Azure, GCP, OpenStack)
La visibilidad sobre los activos cloud es el punto de partida de cualquier estrategia CSPM. Cyberwatch la garantiza mediante mecanismos de descubrimiento nativos capaces de identificar automáticamente las máquinas desplegadas en los principales proveedores cloud.
En detalle:
Descubrimientos AWS: Cyberwatch consulta directamente la API de Amazon EC2 para listar todas las instancias y sus metadatos (ID, IP, estado, tags). Utiliza un rol IAM con permisos exclusivamente de lectura, en cumplimiento estricto del principio de mínimo privilegio. También es posible segmentar el descubrimiento por rol IAM para compartimentar los entornos.
Descubrimientos Azure: A través de la API de Azure Resource Manager, Cyberwatch inventaría las máquinas virtuales y sus atributos (nombre, IP, grupo de recursos) mediante una cuenta de servicio con permisos de lectura sobre los recursos de cómputo.
Descubrimientos Google Cloud Platform: El descubrimiento se apoya en la API de GCP y permite listar las VM y sus metadatos (zona, IP, estado) usando una cuenta de servicio con permisos de lectura sobre Compute Engine.
Descubrimientos OpenStack: Para infraestructuras privadas, Cyberwatch se conecta a la API de OpenStack para recuperar las instancias y sus características, lo que resulta especialmente útil para organizaciones que combinan cloud público y cloud privado.
Más allá del descubrimiento por API, Cyberwatch también soporta mecanismos de conexión adaptados a contextos técnicos específicos. Para una instancia AWS, por ejemplo, un conector SSH estándar puede complementarse con acceso a través de AWS Systems Manager (SSM), lo que permite interactuar con ciertas máquinas sin exposición de red directa y refuerza tanto la seguridad como la flexibilidad operativa.
La creación de un activo de tipo proyecto cloud también desencadena un inventario automático de todos los servicios y recursos gestionados asociados: servicios de almacenamiento (S3, Cloud Storage), bases de datos gestionadas (RDS), recursos de red, usuarios y roles IAM.
Todos estos activos— máquinas virtuales, servicios gestionados e identidades— quedan centralizados en un inventario exhaustivo y actualizado de forma continua. Es el prerrequisito indispensable para cualquier estrategia CSPM: sin esta visibilidad completa, los recursos expuestos o mal configurados pueden pasar desapercibidos y la superficie de ataque nunca estará realmente bajo control.
Priorización 3D: CVSS-BTE, EPSS, CISA KEV
Cyberwatch no se limita a detectar vulnerabilidades: las prioriza mediante un enfoque contextual en tres dimensiones.
La priorización se basa en una política de criticidad definida para cada activo según sus requisitos de seguridad (Confidencialidad, Integridad, Disponibilidad). Esta política aplica las métricas ambientales del estándar CVSS (v2, v3, v4) para calcular una puntuación ajustada, el CVSS-BTE, que integra tanto la gravedad intrínseca de la vulnerabilidad como su impacto potencial sobre el activo afectado.
En la práctica, un servidor completamente aislado de la red puede ver cómo la criticidad de sus vulnerabilidades explotables de forma remota se rebaja automáticamente. Por el contrario, una vulnerabilidad que afecta a un sistema expuesto en producción mantiene un nivel de prioridad elevado.
Esta contextualización se complementa con dos indicadores adicionales:
- La puntuación EPSS, que refleja la probabilidad real de explotación en el mundo
- La presencia en catálogos de referencia reconocidos como CISA KEV o CERT-FR ALE, que señalan las vulnerabilidades que están siendo explotadas activamente
El resultado: el riesgo ya no se evalúa como una severidad teórica global, sino como exposición real para un activo concreto.
Cumplimiento de los CIS Benchmarks para entornos cloud
Cyberwatch garantiza un control continuo de las configuraciones cloud mediante los CIS Benchmarks, con cobertura para AWS, Microsoft Azure, Google Cloud Platform y Microsoft 365. En la práctica, esto se traduce en cientos de reglas de bastionado verificadas de forma automática y permanente.
Algunos ejemplos concretos de los controles aplicados:
Microsoft Azure:
- CIS-Azure-4.1: Secure transfer required activado en las cuentas de almacenamiento
- CIS-Azure-4.4: Regeneración periódica de las claves de acceso de las Storage Accounts
- CIS-Azure-4.6: Public Network Access desactivado para las cuentas de almacenamiento
- CIS-Azure-7.1: Evaluación y restricción del acceso RDP desde internet
Google Cloud Platform:
- CIS-GCP-3.1: Eliminación de la red por defecto en los proyectos
- CIS-GCP-3.3: Activación de DNSSEC para Cloud DNS
- CIS-GCP-4.1: Prohibición del uso de la cuenta de servicio por defecto en las instancias
- CIS-GCP-4.3: Activación del bloqueo de claves SSH a nivel de proyecto para las VM
AWS:
- CIS-AWS-1.4: Verificación de la ausencia de claves de acceso en la cuenta root
- CIS-AWS-1.5: Activación del MFA para la cuenta root
- CIS-AWS-1.8: Política de contraseñas con una longitud mínima de 14 caracteres
- CIS-AWS-1.12: Creación de un rol de soporte dedicado para la gestión segura de incidentes
Más allá de los marcos estándar, Cyberwatch también permite definir reglas personalizadas adaptadas a las políticas internas de cada organización.
Remediación integrada e integraciones ITSM
Cyberwatch proporciona acciones correctivas precisas basadas en los avisos oficiales de los proveedores. Cada recomendación indica la versión corregida o el parche a aplicar, teniendo en cuenta las particularidades de cada sistema, incluidas las ramas específicas de las distribuciones Linux.
Para la implementación, la plataforma aprovecha los mecanismos nativos de cada sistema:
- Linux: gestores de paquetes (APT, YUM, DNF) para aplicar los parches
- Windows: Windows Update para desplegar los KB necesarios
- Productos Microsoft de terceros: winget para instalar o actualizar aplicaciones
Cyberwatch también se integra con las herramientas existentes de los equipos IT: soluciones de patch management (WAPT, Ivanti, Intune) y herramientas de ticketing (ServiceNow, Jira, GLPI). Una vulnerabilidad validada puede transformarse automáticamente en un ticket pre-rellenado con todo el contexto: activo afectado, nivel de criticidad y corrección recomendada.
Del CSPM al CNAPP: cómo Cyberwatch unifica la seguridad de tus entornos cloud
Cyberwatch cubre plenamente las necesidades de un CSPM moderno, pero no se queda ahí.
Los entornos cloud de hoy van mucho más allá de las máquinas virtuales: contenedores, clústeres Kubernetes, pipelines CI/CD y workloads híbridos conviven en arquitecturas cada vez más complejas.
Para responder a ello, Cyberwatch incorpora capacidades propias del CWPP (Cloud Workload Protection Platform), sentando las bases de una estrategia CNAPP (Cloud-Native Application Protection Platform) verdaderamente unificada.
La protección de workloads con el CWPP
El CWPP tiene como objetivo proteger los workloads— máquinas virtuales, servidores, contenedores, componentes de infraestructura— frente a vulnerabilidades, configuraciones incorrectas y las amenazas que pueden derivarse de ellas.
Mientras el CSPM se centra en la postura cloud, el CWPP desciende al nivel de los propios workloads, ya sean cloud, on-premise o híbridos.
Cyberwatch unifica en una sola plataforma el inventario, la clasificación y el análisis de todos los workloads, independientemente de su naturaleza o ubicación:
- Infraestructuras locales: hipervisores, servidores, appliances de red, mediante descubrimientos dedicados que cubren VMware vSphere/ESXi, Microsoft Hyper-V, Proxmox, Nutanix, Active Directory, Fortinet, Stormshield…
- Cloud público: AWS, Azure, GCP, OpenStack, con los mismos mecanismos de descubrimiento descritos en la sección CSPM
- Exposición a internet: mediante enumeración DNS, Certificate Transparency y datos WHOIS, Cyberwatch identifica dominios, servicios o máquinas expuestos públicamente, a veces mal referenciados u olvidados, que pueden representar una superficie de ataque significativa
Este enfoque exhaustivo permite comprender la exposición real de un sistema de información con independencia de dónde se ejecuten los workloads.
Esta visibilidad va acompañada de una capacidad de análisis en profundidad, respaldada por una cobertura de más de 80.000 tecnologías. Cyberwatch inspecciona los sistemas, las dependencias de las aplicaciones (Pip, npm, Gem…) y los componentes embebidos en los contenedores, garantizando un nivel de análisis homogéneo tanto si el workload está en el cloud como en un entorno on-premise.
Seguridad de contenedores y Kubernetes
Cyberwatch analiza los contenedores mediante un enfoque en dos fases. Dado que una imagen Docker se construye habitualmente alrededor de un entorno mínimo que aloja un componente aplicativo, la plataforma comienza analizando todos los paquetes del sistema operativo subyacente. Esta primera capa permite identificar las vulnerabilidades que afectan a la base del sistema de la imagen.
A continuación profundiza en la detección de las dependencias de software utilizadas por la aplicación: bibliotecas, runtimes y dependencias de ecosistemas como Pip, Gem o npm.
Este doble enfoque pone al descubierto simultáneamente las vulnerabilidades que afectan al sistema operativo y las que provienen de los componentes aplicativos.
Más allá de la propia imagen, Cyberwatch extiende su cobertura a los entornos de ejecución. La plataforma gestiona el descubrimiento y el inventario de clústeres Kubernetes (AKS, EKS, OpenShift, Rancher), Docker Swarm y registros de imágenes (Amazon ECR, Harbor, GitLab Registry). Las imágenes recién desplegadas pueden escanearse automáticamente, lo que garantiza un control continuo a lo largo de todo el ciclo de vida de los workloads en contenedores.
DevSecOps e integración CI/CD
Cyberwatch se integra de forma nativa en las prácticas DevSecOps gracias a su compatibilidad con el escáner de Harbor y a su inserción directa en pipelines CI/CD de GitLab. Esta capacidad refuerza la prevención antes del despliegue: las imágenes no conformes o vulnerables pueden bloquearse antes de llegar a producción.
Esa es la lógica del CNAPP: la postura cloud, la protección de workloads y la seguridad de los contenedores dejan de tratarse en silos para formar parte de un continuo coherente y automatizado, desde el primer inventario hasta la remediación.
En resumen
En 2026, el multicloud se ha convertido en la norma. Sin embargo, muchas organizaciones todavía no tienen una visión fiable y actualizada de lo que realmente se ejecuta en su entorno cloud ni de lo que está genuinamente expuesto.
El enfoque CSPM responde exactamente a ese reto: identificar de forma continua los recursos cloud, detectar desviaciones de configuración, priorizar los riesgos reales y orquestar la remediación. Ya no es opcional, es innegociable para cualquier organización que se tome en serio la ciberseguridad.
Con Cyberwatch, ese enfoque se vuelve plenamente operativo:
- Un inventario automatizado y centralizado de todos tus recursos cloud (AWS, Azure, GCP, OpenStack), actualizado de forma continua
- Una priorización contextual de vulnerabilidades basada en CVSS-BTE, EPSS y los catálogos CISA KEV y CERT-FR ALE, para concentrar los esfuerzos donde el riesgo es real
- Un control continuo del cumplimiento normativo mediante los CIS Benchmarks para AWS, Azure, GCP y Microsoft 365
- Una remediación integrada, trazable y conectada a tus herramientas existentes (ServiceNow, Jira, GLPI, Intune…)
- Una cobertura extendida a workloads, contenedores y clústeres Kubernetes, para un enfoque CNAPP verdaderamente unificado
Solicita una demo gratuita y descubre exactamente a qué estás expuesto.
Preguntas frecuentes
¿Cuál es la diferencia entre un CSPM y un escáner de vulnerabilidades tradicional?
Un escáner de vulnerabilidades tradicional analiza los activos que tú le indicas explícitamente. El CSPM va más allá: descubre automáticamente todos tus recursos cloud, incluidos los que desconoces, analiza sus configuraciones y supervisa su cumplimiento de forma continua, no solo en el momento del escaneo.
¿Cuál es la diferencia entre CSPM y CWPP?
El CSPM se centra en la postura y las configuraciones de los entornos cloud. El CWPP (Cloud Workload Protection Platform) desciende al nivel de los propios workloads— máquinas virtuales, servidores, contenedores— para analizarlos y protegerlos frente a vulnerabilidades y configuraciones incorrectas, ya estén en el cloud, on-premise o en entornos híbridos.
¿El CSPM ayuda a cumplir con los requisitos de NIS2?
Sí. El artículo 21 de la directiva NIS2 impone a las entidades afectadas una serie de medidas de gestión del riesgo cibernético, entre las que se incluyen la gestión de vulnerabilidades, el control de configuraciones, la seguridad de la cadena de suministro y la trazabilidad de las acciones de remediación. El CSPM da respuesta directa a varios de estos requisitos: inventario continuo de activos, detección de desviaciones de configuración, priorización contextual de vulnerabilidades y seguimiento de los parches aplicados. También genera la evidencia necesaria en caso de auditoría o control por parte de la autoridad competente.
¿El CSPM es solo para grandes empresas con entornos multicloud complejos?
Históricamente sí, pero las soluciones actuales están al alcance de cualquier organización. Cyberwatch, por ejemplo, está diseñado para adaptarse tanto a grandes empresas como a organizaciones de tamaño medio, con un despliegue rápido e integración sencilla en las herramientas existentes.
¿Qué diferencia hay entre CSPM y CNAPP?
El CSPM se centra en la postura y las configuraciones cloud. El CNAPP es un enfoque más amplio que lo engloba y añade la protección de workloads, la seguridad de contenedores y la integración DevSecOps. El CSPM es un componente esencial del CNAPP, pero el CNAPP va más lejos.
¿Cómo encaja el CSPM en una estrategia DevSecOps?
Desplazando los controles de seguridad lo antes posible en el ciclo de desarrollo: escaneo de imágenes de contenedores antes del despliegue, bloqueo de imágenes vulnerables en la pipeline CI/CD e integración con las herramientas de los equipos (GitLab, Harbor…). El objetivo es hacer de la seguridad una parte continua del ciclo de vida de las aplicaciones, no una etapa final.