Tema 23

23. Cumplimiento, gobierno y gestión de riesgos en plataformas cloud nativas

Gobernar cloud native significa definir reglas claras, medir cumplimiento continuamente, gestionar excepciones y tomar decisiones de riesgo con evidencia. El objetivo no es solo pasar auditorías, sino operar plataformas confiables.

Objetivo Convertir seguridad en gobierno medible y sostenible
Enfoque Riesgo, cumplimiento, evidencia, políticas y excepciones
Resultado Tomar decisiones auditables sobre seguridad cloud native

23.1 Introducción

Las plataformas cloud nativas cambian rápido. Nuevas cuentas, clusters, pipelines, servicios administrados y dependencias aparecen constantemente. En este contexto, el cumplimiento no puede depender solo de auditorías manuales anuales.

El gobierno define cómo se toman decisiones, quién es responsable, qué controles son obligatorios, cómo se gestionan excepciones y qué evidencia demuestra cumplimiento.

La gestión de riesgos conecta controles técnicos con impacto de negocio, requisitos regulatorios y prioridades operativas.

23.2 Gobierno cloud native

Gobierno cloud native es el conjunto de políticas, procesos, roles y controles que guían el uso seguro de cloud, contenedores y DevSecOps.

Incluye:

  • Modelo de cuentas, proyectos y ambientes.
  • Políticas de identidad, red, datos y logging.
  • Guardrails preventivos y detectivos.
  • Gestión de riesgos y excepciones.
  • Inventario y ownership de activos.
  • Evidencia automatizada para auditoría.
  • Métricas de postura y cumplimiento.
El gobierno efectivo no busca frenar cloud. Busca que la velocidad tenga límites, trazabilidad y responsabilidad.

23.3 Riesgo, control y evidencia

Un programa maduro conecta riesgos con controles y evidencia. Si una organización no puede demostrar que un control funciona, el cumplimiento queda basado en declaraciones.

Elemento Pregunta Ejemplo
Riesgo ¿Qué puede salir mal? Datos sensibles expuestos públicamente
Control ¿Qué reduce ese riesgo? Bloqueo de buckets públicos y alertas CSPM
Evidencia ¿Cómo demostramos que opera? Reporte de políticas, logs de cambios y hallazgos cerrados
Dueño ¿Quién responde por el control? Equipo de plataforma o seguridad cloud
Frecuencia ¿Cada cuánto se valida? Continuo, diario, mensual o por release

23.4 Cumplimiento continuo

El cumplimiento continuo mide controles de forma automatizada y recurrente. Es más adecuado para cloud que auditorías manuales aisladas.

Ejemplos:

  • Verificar MFA y usuarios privilegiados diariamente.
  • Detectar recursos sin cifrado o sin logs.
  • Validar que los pipelines ejecutan escaneos obligatorios.
  • Comprobar que imágenes productivas están firmadas.
  • Revisar excepciones vencidas.
  • Generar evidencia automática desde SIEM, CSPM, CI/CD e IaC.

23.5 Políticas y estándares internos

Las políticas definen qué se espera. Los estándares traducen esas políticas en requisitos técnicos aplicables.

Política Estándar técnico Evidencia
Proteger datos sensibles Cifrado obligatorio, clasificación y acceso mínimo Reporte KMS, IAM y clasificación
Controlar acceso privilegiado MFA, roles temporales y revisión periódica Logs de identidad y reportes IAM
Asegurar despliegues CI/CD con escaneo, firma y aprobación Ejecuciones de pipeline y artefactos firmados
Auditar actividad Logs centralizados e inmutables Configuración de logging y retención

23.6 Ownership e inventario

Todo recurso relevante debe tener dueño. Sin ownership, los hallazgos quedan sin responsable y las excepciones se vuelven permanentes.

Datos mínimos:

  • Aplicación o servicio.
  • Dueño técnico y dueño de negocio.
  • Ambiente.
  • Criticidad.
  • Clasificación de datos.
  • Centro de costo.
  • Repositorio o pipeline asociado.
  • Fecha de revisión o vencimiento si es temporal.

23.7 Etiquetado obligatorio

El etiquetado permite gobierno, costos, inventario y respuesta. Debe validarse en IaC, políticas cloud y revisiones de postura.

Etiquetas comunes:

  • owner: responsable técnico.
  • application: aplicación o servicio.
  • environment: dev, test, staging o prod.
  • data_classification: pública, interna, confidencial o restringida.
  • cost_center: imputación de costos.
  • criticality: impacto de negocio.
  • managed_by: Terraform, pipeline, consola u otra fuente.
Un recurso sin dueño es un riesgo operativo. No se puede remediar, auditar ni justificar correctamente.

23.8 Gestión de excepciones

Las excepciones permiten aceptar temporalmente un riesgo cuando existe justificación. Deben gobernarse para que no se conviertan en deuda permanente.

Una excepción debe incluir:

  • Control incumplido.
  • Recurso, aplicación y ambiente.
  • Riesgo aceptado.
  • Motivo técnico o de negocio.
  • Control compensatorio.
  • Aprobador.
  • Fecha de vencimiento.
  • Plan de remediación.

23.9 Gestión de riesgos

La gestión de riesgos prioriza decisiones. No todos los hallazgos tienen el mismo impacto, y no todos los controles tienen el mismo costo o urgencia.

Un riesgo debe evaluarse por:

  • Probabilidad.
  • Impacto.
  • Exposición.
  • Datos afectados.
  • Controles existentes.
  • Requisitos legales o contractuales.
  • Capacidad de detección y recuperación.

23.10 Evidencia automatizada

La evidencia automatizada reduce carga manual y mejora confiabilidad. Debe generarse desde sistemas reales, no a partir de capturas aisladas.

Fuente Evidencia Control demostrado
CI/CD Escaneos, aprobaciones, artefactos firmados Entrega segura
CSPM Postura de recursos y desviaciones Configuración segura cloud
IAM MFA, roles, accesos privilegiados Control de identidad
SIEM Alertas, investigaciones y logs Detección y auditoría
IaC Pull requests, planes y policy checks Cambios revisados y gobernados

23.11 Marcos y requisitos

Las organizaciones pueden mapear controles internos contra marcos externos. El objetivo no es copiar controles sin contexto, sino traducir requisitos en prácticas operables.

Áreas comunes:

  • Control de acceso.
  • Cifrado y protección de datos.
  • Registro y monitoreo.
  • Gestión de vulnerabilidades.
  • Respuesta a incidentes.
  • Continuidad y backups.
  • Gestión de proveedores.
  • Seguridad del ciclo de desarrollo.

23.12 Gobierno de costos y seguridad

Costos y seguridad se relacionan. Recursos huérfanos, logs sin retención definida, snapshots olvidados o ambientes temporales activos pueden crear riesgo y gasto.

Controles útiles:

  • Etiquetas de costo obligatorias.
  • Presupuestos y alertas por cuenta o proyecto.
  • Limpieza automática de recursos temporales.
  • Retención diferenciada de logs.
  • Revisión de recursos sin dueño.
  • Control de servicios de alto costo.

23.13 Métricas ejecutivas

Las métricas ejecutivas deben mostrar riesgo y tendencia, no detalles técnicos excesivos.

  • Porcentaje de recursos críticos cubiertos por guardrails.
  • Hallazgos críticos abiertos por más de X días.
  • Excepciones vencidas.
  • Cobertura de logs y auditoría.
  • Porcentaje de despliegues con controles DevSecOps completos.
  • Tiempo medio de remediación.
  • Recursos sin dueño o sin clasificación.
  • Incidentes por causa raíz repetida.

23.14 Errores frecuentes

  • Tratar cumplimiento como actividad anual y manual.
  • Crear políticas que no pueden medirse técnicamente.
  • No asignar dueños de recursos y controles.
  • Permitir excepciones sin vencimiento.
  • Recolectar evidencia en capturas manuales en lugar de sistemas fuente.
  • Medir controles sin evaluar riesgo real.
  • Ignorar costos como señal de recursos no gobernados.
  • No mapear controles DevSecOps a requisitos de auditoría.
Cumplimiento sostenible es evidencia continua de controles reales, no documentación creada justo antes de una auditoría.

23.15 Lista de verificación

  • ¿Los recursos tienen dueño, ambiente, criticidad y clasificación?
  • ¿Las políticas internas se traducen en controles técnicos medibles?
  • ¿Las excepciones tienen aprobación, vencimiento y remediación?
  • ¿La evidencia se genera desde CI/CD, CSPM, IAM, SIEM e IaC?
  • ¿Los riesgos se priorizan por impacto y exposición?
  • ¿Los controles se mapean a requisitos regulatorios o contractuales?
  • ¿Hay métricas ejecutivas de postura, remediación y excepciones?
  • ¿El gobierno contempla costos, recursos huérfanos y ambientes temporales?

23.16 Qué debes recordar de este tema

  • Gobierno cloud native define reglas, responsables, evidencia y excepciones.
  • El cumplimiento debe medirse continuamente, no solo en auditorías puntuales.
  • Riesgo, control y evidencia deben estar conectados.
  • El ownership y etiquetado son bases operativas para remediación y auditoría.
  • Las métricas deben mostrar tendencia de riesgo y capacidad de mejora.

23.17 Conclusión

Cumplimiento y gobierno en cloud native requieren automatización, evidencia y responsabilidad clara. Cuando las políticas se traducen en controles medibles, la organización puede operar con velocidad sin perder trazabilidad ni gestión de riesgo.

En el próximo tema cerraremos el curso diseñando una estrategia integral de seguridad cloud native y mejora continua.