CSPM - postura cloud

Cloud Security Posture Management escanea la configuración de cada cuenta contra baselines (CIS, PCI, NIST) y señala el drift antes de que se vuelva un incidente.

WizLaceworkPrisma CloudOrca Security

Qué es

CSPM () es el auditor continuo de tu nube. Se conecta a las cuentas (vía un rol de de solo lectura) y compara la configuración real contra baselines publicados (CIS, PCI, NIST 800-53, el benchmark interno de tu equipo). La diferencia entre el estado actual y el baseline es el finding: almacenamiento sin cifrar, un SG con 0.0.0.0/0, un usuario IAM sin MFA, un log group sin retención.

La idea es simple: la mayoría de los incidentes no empieza con un ataque sofisticado, empieza con un bucket abierto que se quedó abierto durante tres meses. CSPM existe para cerrar esa ventana automáticamente.

Cómo funciona: reglas y benchmarks

El motor de reglas es declarativo. Para cada control, una expresión evalúa la configuración: si el recurso coincide con el patrón peligroso, hay un finding. Los frameworks públicos se convierten en paquetes de reglas reutilizables.

Cuantas más reglas, más ruido. La mayoría de los equipos enciende el benchmark completo en el primer mes y pasa el resto del año apagando reglas que no aplican (Kubernetes 1.22 en un servicio legado, RDS sin CMK en dev). El filtro práctico es separar el baseline global (vale para toda cuenta) del baseline por entorno (dev recibe controles más débiles, prod recibe todo).

CIS Foundations: baseline de higiene general (MFA en root, CloudTrail activo, S3 sin acceso público)
PCI DSS: controles de pagos (cifrado en reposo, segmentación, audit log)
NIST 800-53 / 800-171: controles federales, exige compliance programático en organizaciones del gobierno estadounidense
Trust Services Criteria: seguridad, disponibilidad, confidencialidad, privacidad

Drift: el hallazgo que vuelve cada semana

El drift ocurre cuando la infraestructura vuelve a un estado inseguro sin que nadie lo haya pedido. Sucede por automatización concurrente (Terraform apply y consola al mismo tiempo), por un cambio manual durante un incidente, o por otro equipo tocando donde no debía. CSPM mide el drift mediante diff de configuración entre ejecuciones: la misma cuenta hoy y ayer deberían ser iguales, salvo cambios aprobados.

El valor del drift no es la alerta en sí, es la señal de que existe un cambio no aprobado. Encontrar el origen (consola de la nube, desactualizado, otro pipeline) es donde está el problema.

finding CSPM - drift detectadojson

{
  "rule_id": "S3-PUBLIC-READ-DRIFT",
  "framework": "CIS AWS Foundations 2.1.5",
  "severity": "high",
  "resource": "arn:aws:s3:::loja-customer-uploads",
  "account": "111122223333",
  "region": "us-east-1",
  "title": "Bucket que bloqueaba la lectura pública volvió a ser público",
  "drift": {
    "previous_state": {
      "public_access_block": "all_true",
      "evaluated_at": "2026-09-29T08:00:00Z"
    },
    "current_state": {
      "public_access_block_configuration": {
        "block_public_acls": false,
        "ignore_public_acls": false,
        "block_public_policy": false,
        "restrict_public_buckets": false
      },
      "evaluated_at": "2026-10-09T14:22:11Z"
    }
  },
  "remediation": "aws s3api put-public-access-block --bucket loja-customer-uploads --public-access-block-configuration BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true"
}

Multi-cloud y el problema del conector

Cada proveedor tiene APIs propias, y cada CSPM necesita aprender a hablar con AWS, Azure, GCP, OCI, Alibaba. Los mejores productos lo hacen de forma nativa; los peores parecen un traductor mal calibrado. Evaluar el soporte multi-cloud no es revisar el logo en la landing page, es ejecutar el mismo control CIS en dos cuentas idénticas (una AWS, una Azure) y ver si el finding sale igual.

La elección entre basado en agente y basado en API tiene impacto. Un CSPM puramente basado en API lee la configuración, no lo que corre dentro: ve el , no el proceso escuchando en el puerto. Para workloads en runtime entra (próximo tema).

Remediación: del hallazgo a la corrección

La remediación tiene tres niveles. Manual: el finding se vuelve un ticket en Jira, alguien lo corrige. Asistida: el CSPM genera el comando (terraform plan, aws cli) y un humano lo aprueba en un PR. Automática: el CSPM aplica la corrección por sí solo, con rollback si algo se rompe (un S3 Public Block que borra una política activa es el caso clásico).

El camino seguro es empezar con manual en todas las cuentas, pasar a asistida en entornos de dev/staging, y activar la automática en controles con pequeño (forzar logs, forzar encryption) y bajo cambio monitoreado. La auto-remediación en IAM con una clave de producción es receta para un incidente.

Dónde aparece

CSPM es detección continua, así que no hay un único 'dónde aparece': corre 24/7 contra la API del proveedor. En el flujo de cambios aparece en dos puntos: en el PR de IaC (evalúa antes del apply) y en el monitoreo posterior al apply (evalúa el estado real). El primero atrapa la regla antes de la falla; el segundo atrapa lo que derivó sin que nadie lo pidiera.

Puntos fuertes

visibilidad inmediata: en una hora tienes la lista de buckets abiertos, claves sin uso y security groups que se volvieron queso suizo
compliance programático: CIS/PCI/NIST deja de ser una auditoría anual y pasa a ser un dashboard diario
la detección de drift cierra el hueco entre IaC (lo que se aplica) y runtime (lo que corre)

Limitaciones

CSPM ve configuración, no comportamiento: un contenedor corriendo un crypto miner con un SG aparentemente correcto pasa el benchmark
el ruido es el talón de Aquiles: el benchmark completo se vuelve 500 findings la primera semana, y sin triage se vuelve un dashboard ignorado
la remediación automática tiene blast radius: corregir un bucket sin entender su uso rompe una aplicación en producción, y la corrección silenciosa esconde el bug que necesitaba un cambio de arquitectura

CSPMcloud security posture managementHerramienta que escanea la configuración de tu nube contra buenas prácticas y benchmarks (CIS, NIST), señalando buckets S3 públicos, IAM demasiado amplio, puertos expuestos. Hace la pregunta que los humanos olvidan: '¿qué está mal configurado AHORA?'.ver en el glosario →IAMidentity and access managementEl conjunto de políticas, roles y credenciales que dice quién es cada humano, servicio o workload, y qué puede hacer cada uno. En la nube, IAM se convirtió en el nuevo perímetro: el borde de red se volvió poroso, así que la identidad carga la autorización.ver en el glosario →SOC 2Un informe de un auditor sobre los controles de un proveedor de servicios en materia de seguridad y criterios relacionados, solicitado con frecuencia por los clientes.ver en el glosario →IaCinfraestructura como códigoDescribir la infraestructura en archivos versionados (Terraform, Ansible). Aporta revisión, historial y pruebas a la configuración, pero replica errores a escala si no se escanea.ver en el glosario →Grupo de seguridadsecurity groupLista de reglas stateful asociada a una instancia o interfaz de red en la nube: quién puede entrar por qué puerto, desde qué origen. Funciona como firewall de host a nivel de nube, y falla por defecto: si olvidas cerrar un puerto, queda abierto a 0.0.0.0/0.ver en el glosario →CWPPcloud workload protection platformProtección monitoreada para workloads en ejecución: VMs, contenedores, funciones serverless. Combina visibilidad de lo que corre (procesos, syscalls, red) con prevención (bloquear la ejecución, aislar anomalías). Es el endpoint security reformulado para la realidad efímera de la nube.ver en el glosario →Radio de impactoblast radiusEl tamaño del daño cuando algo se rompe: una cuenta, una región completa, un tenant. Un buen diseño de nube limita el radio mediante aislamiento (cuentas separadas, VPCs separadas, roles estrechos) para que una falla o un ataque no se convierta en un desastre total.ver en el glosario →

conexiones en el mapa

CSPM - postura cloudauditaIAM - identidad y acceso
CSPM - postura cloudaudita la posturaKubernetes - runtime seguro
Logging & detection - señales y alertasalimenta la posturaCSPM - postura cloud

actualizado el 14/10/2026 · fuentes para profundizar · reportar un error

en otros dominios

Reconocimiento y superficie de ataqueoffseclo que el atacante ve desde afuera, el CSPM lo ve desde adentro
A02 Security Misconfigurationowaspla verificación continua de la configuración
DevSecOpsappsecse vuelve política continua en producción
Infraestructura segura como códigosecengel CSPM ve el entorno; el IaC seguro corrige en el origen y detecta el drift

Estudia antes

pon a prueba lo que entendiste

Cargando preguntas…