Tema 8
La postura cloud es el estado real de seguridad de la plataforma: qué recursos existen, cómo están configurados, qué riesgos presentan y qué tan lejos están de las políticas aprobadas.
Cloud cambia constantemente. Nuevos recursos, permisos, redes, buckets, bases de datos, funciones, claves y reglas pueden aparecer todos los días. Si la organización no monitorea su postura, la seguridad queda basada en una foto antigua que ya no representa la realidad.
El monitoreo de postura cloud permite comparar el estado real contra políticas esperadas. Detecta recursos públicos, cifrado deshabilitado, permisos excesivos, logs apagados, regiones no aprobadas, reglas de red peligrosas y otras desviaciones.
La meta no es acumular alertas, sino construir un proceso de visibilidad, priorización, remediación y mejora continua.
La postura cloud es el conjunto de condiciones de seguridad observables en los recursos desplegados. Incluye configuraciones, identidades, exposición, cifrado, logging, etiquetas, cumplimiento y relación entre servicios.
Ejemplos de preguntas de postura:
CSPM significa Cloud Security Posture Management. Es una categoría de herramientas y procesos orientados a descubrir recursos cloud, evaluar configuraciones, detectar desviaciones, priorizar riesgos y facilitar remediación.
Un CSPM suele ofrecer:
El inventario es la base de la postura. Debe responder qué existe, dónde está, quién lo posee, qué función cumple, qué datos procesa y qué riesgo presenta.
| Dato de inventario | Utilidad | Riesgo si falta |
|---|---|---|
| Dueño | Asignar responsabilidad de remediación | Hallazgos sin responsable claro |
| Ambiente | Distinguir desarrollo, staging y producción | Priorización incorrecta |
| Criticidad | Ordenar riesgos según impacto | Tratar todos los recursos igual |
| Datos procesados | Aplicar controles de privacidad y cifrado | Exposición de datos sensibles sin detección |
| Origen de creación | Saber si proviene de IaC, consola o pipeline | Drift y cambios manuales no gestionados |
Para detectar desviaciones, primero hay que definir qué significa "seguro". Esa referencia puede basarse en políticas internas, guías del proveedor, benchmarks, requisitos regulatorios y decisiones de arquitectura.
Ejemplos de reglas esperadas:
Drift es la diferencia entre el estado esperado y el estado real. Puede aparecer cuando alguien cambia recursos manualmente, cuando una plantilla queda desactualizada o cuando un servicio modifica configuraciones por dependencia operativa.
Tipos frecuentes de drift:
| Hallazgo | Riesgo | Remediación inicial |
|---|---|---|
| Almacenamiento público | Exposición de datos | Bloquear acceso público y revisar políticas |
| MFA deshabilitado | Compromiso de cuentas por robo de contraseña | Exigir MFA y revisar usuarios privilegiados |
| Puertos administrativos abiertos | Fuerza bruta o acceso remoto no autorizado | Cerrar exposición y usar bastion, VPN o sesión gestionada |
| Logs desactivados | Baja trazabilidad ante incidentes | Habilitar auditoría centralizada y retención |
| Claves antiguas | Mayor ventana de abuso ante filtración | Rotar, reemplazar por roles temporales o eliminar |
Un error común es tratar todos los hallazgos igual. La priorización debe considerar severidad, exposición, sensibilidad de datos, criticidad del recurso, facilidad de explotación y contexto.
Factores útiles:
Detectar sin corregir no mejora la seguridad. La remediación debe integrarse con equipos responsables, herramientas de ticketing, pipelines, infraestructura como código y procesos de excepción.
Opciones de remediación:
La remediación automática debe usarse con cuidado. Puede causar interrupciones si no distingue contexto, criticidad y dependencias.
No toda desviación puede corregirse inmediatamente. Algunas configuraciones responden a necesidades reales, migraciones o limitaciones técnicas. Lo importante es que las excepciones sean explícitas y temporales.
Una excepción debería incluir:
La postura cloud no debería controlarse solo después del despliegue. Las mismas reglas deben aplicarse antes, durante y después de crear recursos.
| Etapa | Control | Objetivo |
|---|---|---|
| Diseño | Patrones aprobados y landing zone | Evitar decisiones inseguras desde el inicio |
| Pull request | IaC scanning y revisión de políticas | Detectar problemas antes de aplicar cambios |
| Pipeline | Policy as code y gates de seguridad | Bloquear despliegues fuera de estándar |
| Runtime | CSPM, alertas y drift detection | Detectar cambios reales en la plataforma |
| Operación | Tickets, métricas y revisiones periódicas | Corregir, aprender y mejorar la postura |
Las métricas permiten evaluar si el programa mejora o solo genera ruido. Deben orientar decisiones, no convertirse en un tablero decorativo.
Métricas útiles:
Un programa de postura cloud necesita responsables y proceso. De lo contrario, los hallazgos se acumulan y los equipos dejan de prestar atención.
Roles típicos:
Monitorear la postura cloud permite convertir configuraciones dispersas en información accionable. La combinación de inventario, reglas, drift detection, priorización y remediación ayuda a mantener una plataforma segura mientras evoluciona.
En el próximo tema comenzaremos el bloque de contenedores con sus fundamentos: imágenes, capas, runtimes y superficie de ataque.