La gestión de la postura de seguridad en la nube (CSPM, por sus siglas en inglés) evalúa la configuración del plano de control de la nube frente a los requisitos de seguridad establecidos. En AWS, Azure y Google Cloud, la CSPM nos ayuda a determinar si los recursos, las identidades y las configuraciones a nivel de cuenta se ajustan a una postura definida. No inspecciona el contenido de los paquetes de aplicaciones ni sustituye la detección en tiempo de ejecución de un ataque activo.
[fuentes][/fuentes]
Por lo general, las herramientas de CSPM funcionan sin agentes. Utilizan credenciales de solo lectura para invocar las API de cada proveedor, crear un inventario de recursos y evaluar reglas sobre dicho inventario. Algunos ejemplos son AWS Config y Security Hub, Microsoft Defender for Cloud, Google Security Command Center y herramientas de escaneo de código abierto como Prowler y Steampipe. Cuando un recurso incumple alguna de estas reglas, la herramienta comunica el resultado como un hallazgo.
Un hallazgo es una declaración sobre un estado de configuración observable, como la configuración de acceso de un recurso de almacenamiento o el permiso asignado a una identidad. Su valor depende de la evidencia que el proceso de CSPM puede leer y de la regla utilizada para interpretar dicha evidencia.
[fuentes][/fuentes]
Ahora podemos identificar los límites del proveedor y las fuentes de evidencia que utiliza una evaluación de CSPM.
[fuentes][/fuentes]
La evidencia de configuración describe lo que el plano de control del proveedor reporta en el momento de la recopilación. Los registros de actividad aportan un historial de acciones de gestión, como cuando una entidad (principal) modifica una política o crea un recurso. En AWS, estas fuentes son AWS Config y CloudTrail; en Azure, Azure Resource Graph y Activity Log; y en Google Cloud, Cloud Asset Inventory y Cloud Audit Logs. En conjunto, estas fuentes pueden demostrar la existencia de una configuración e indicar quién la modificó, pero ninguna prueba que una solicitud de aplicación haya tenido éxito, que se haya accedido a datos o que un paquete de red fuera seguro.
La deriva de configuración (configuration drift) es la diferencia entre la configuración aprobada o esperada y la configuración actual observada. Esta deriva puede originarse por un cambio manual, un error de automatización, una reversión de despliegue que restauró un valor anterior o un recurso creado fuera del proceso de entrega previsto. La herramienta CSPM detecta la diferencia únicamente cuando el recurso forma parte de su inventario y la evidencia correspondiente está disponible.
Límite de la evidencia Un hallazgo de CSPM establece una condición de configuración dentro del ámbito del proveedor. Por sí solo, no determina la explotabilidad, el impacto empresarial ni la realización de un acceso exitoso.
Un hallazgo puede ser un falso positivo cuando la regla evaluada reporta un problema, aunque el requisito aplicable permita el estado observado. Por ejemplo, una regla redactada de forma genérica podría señalar un punto de conexión (endpoint) expuesto a Internet que es deliberadamente público y está protegido por controles que la regla no evalúa. La respuesta segura consiste en validar el requisito, el propósito del recurso, la ruta de exposición y los controles compensatorios antes de modificar la configuración de producción.
La falta de permisos de lectura genera el problema opuesto. Si la identidad de CSPM no puede listar un recurso, recuperar una política o inspeccionar una configuración relevante, la evaluación podría arrojar una cobertura incompleta en lugar de un resultado limpio. Un recurso no gestionado produce el mismo efecto práctico cuando se encuentra fuera del alcance de las cuentas, suscripciones, proyectos o inventarios que se están evaluando.
El modelo de responsabilidad compartida también establece límites. El proveedor de la nube opera el servicio subyacente, mientras que el cliente sigue siendo responsable de decisiones como la asignación de identidades, la exposición de red, las políticas de recursos y la configuración de acceso a datos. Superar una verificación de postura no transfiere dicha responsabilidad ni demuestra la eficacia de todos los controles gestionados por el cliente.
Regla de decisión Considere la ausencia de hallazgos como información útil únicamente tras confirmar el alcance, los permisos de recopilación, la aplicabilidad de la regla y la ventana temporal de la evidencia.
Utilizaremos una carga de trabajo deliberadamente pequeña denominada orders-api. Esta representa un servicio de aplicación que escucha en el puerto 8080 y almacena datos de pedidos en un recurso de almacenamiento de objetos nativo del proveedor. Cada versión permanece dentro de los límites de su propio proveedor, por lo que no se asume que ninguna identidad, permiso de almacenamiento o hallazgo trascienda de una nube a otra.
En AWS, orders-api utiliza el rol orders-api-role y el bucket orders-data-s3. En Azure, emplea la identidad administrada orders-api-mi y la cuenta de almacenamiento ordersdatast. En Google Cloud, utiliza la cuenta de servicio orders-api-sa y el bucket orders-data-gcs. Estos identificadores son ficticios, pero el límite que ilustran es reutilizable.
Podemos examinar cómo la identidad de cada carga de trabajo permanece restringida a los recursos de su propio proveedor.