21. Observabilidad y detección: logs, métricas, trazas, SIEM, alertas y auditoría cloud

21.1 Introducción

Cloud, contenedores y DevSecOps generan gran cantidad de señales: eventos administrativos, logs de aplicación, métricas de infraestructura, trazas distribuidas, registros de red, auditoría de Kubernetes, eventos de CI/CD y hallazgos de seguridad.

Recolectar todo sin criterio puede producir ruido, costos altos y alertas inútiles. La observabilidad de seguridad debe priorizar fuentes que permitan responder preguntas concretas: quién hizo qué, qué cambió, qué dato se accedió, qué servicio falló y qué comportamiento se desvió de lo esperado.

El objetivo es transformar eventos dispersos en detección, investigación y respuesta.

21.2 Observabilidad frente a monitoreo

Monitorear suele significar vigilar métricas y alertas conocidas. Observabilidad implica poder hacer preguntas nuevas sobre el sistema a partir de señales disponibles.

21.3 Fuentes de logs cloud

La auditoría cloud es una fuente fundamental. Debe registrar acciones administrativas, cambios de configuración, accesos a datos y eventos de red.

Fuentes habituales:

• Eventos de administración de cuentas, proyectos y suscripciones.
• Operaciones IAM: creación de usuarios, roles, claves y políticas.
• Acceso a almacenamiento, bases de datos y KMS.
• Logs de red: flow logs, firewalls, balanceadores, DNS y WAF.
• Eventos de Kubernetes: API server, audit logs, admission y runtime.
• Eventos de CI/CD: workflows, aprobaciones, artefactos y despliegues.
• Hallazgos de CSPM, escáneres y herramientas de seguridad.

21.4 Logs de aplicación

Los logs de aplicación aportan contexto que la plataforma no siempre conoce. Deben ayudar a investigar abuso sin exponer secretos ni datos sensibles innecesarios.

Buenas prácticas:

• Usar formato estructurado.
• Incluir identificadores de request, usuario, tenant o servicio cuando corresponda.
• Registrar eventos de autenticación, autorización y cambios críticos.
• No imprimir tokens, contraseñas, claves, cookies o datos personales innecesarios.
• Distinguir severidades: debug, info, warn, error y security.
• Sincronizar relojes y usar timestamps consistentes.

21.5 Métricas de seguridad

Las métricas permiten detectar tendencias y anomalías. No explican todo, pero ayudan a encontrar cambios de comportamiento.

21.6 Trazas distribuidas

Las trazas muestran el recorrido de una solicitud entre servicios. En arquitecturas de microservicios, son útiles para entender impacto, dependencias y puntos donde aparece comportamiento anómalo.

Para seguridad ayudan a:

• Vincular una acción de usuario con llamadas internas.
• Detectar rutas de ejecución inesperadas.
• Investigar abuso de APIs.
• Medir impacto de una dependencia comprometida.
• Relacionar errores con cambios o despliegues.

Las trazas no deben incluir payloads sensibles completos. Deben equilibrar utilidad y privacidad.

21.7 SIEM

Un SIEM centraliza eventos, normaliza datos, correlaciona señales y permite alertar e investigar. Su valor depende de la calidad de fuentes y reglas, no solo del volumen de logs.

Capacidades esperadas:

• Ingesta de logs cloud, Kubernetes, aplicación, red y CI/CD.
• Normalización de campos.
• Correlación entre eventos.
• Reglas de detección y alertas.
• Búsqueda e investigación histórica.
• Dashboards de postura y actividad.
• Integración con SOAR o ticketing.

21.8 Casos de detección

Las reglas de detección deben partir de escenarios concretos. Algunas detecciones útiles en cloud native:

• Creación de usuario o clave administrativa fuera de horario.
• Desactivación de logs de auditoría.
• Cambio de política IAM seguido de acceso a datos sensibles.
• Bucket o base de datos expuesta públicamente.
• Pod privilegiado creado en namespace productivo.
• Pipeline productivo ejecutado desde rama no esperada.
• Imagen no firmada desplegada en producción.
• Tráfico saliente anómalo desde workload crítico.

21.9 Correlación

Un evento aislado puede no ser suficiente. La correlación combina señales para reducir falsos positivos y aumentar contexto.

21.10 Retención y protección de logs

Los logs deben conservarse el tiempo suficiente para investigación, cumplimiento y análisis histórico. También deben protegerse contra modificación o borrado.

Controles recomendados:

• Centralizar logs en una cuenta o proyecto separado.
• Aplicar cifrado y control de acceso mínimo.
• Usar retención diferenciada por criticidad y costo.
• Proteger logs críticos con inmutabilidad o bloqueo de borrado.
• Monitorear desactivación de logging o cambios de retención.
• Evitar que cuentas productivas puedan borrar sus propias evidencias.

21.11 Calidad de señales

Una plataforma puede recolectar muchos datos y aun así no detectar bien. La calidad de señales depende de cobertura, contexto, normalización y acción posible.

Evaluar:

• ¿La señal identifica actor, recurso, acción y resultado?
• ¿Incluye cuenta, región, ambiente y aplicación?
• ¿Tiene timestamp confiable?
• ¿Puede correlacionarse con otros eventos?
• ¿Tiene dueño para investigación?
• ¿Genera una acción clara?

21.12 Alertas accionables

Una alerta útil debe tener contexto suficiente para que el equipo sepa qué hacer. Alertas vagas generan fatiga y baja respuesta.

Debe incluir:

• Qué ocurrió.
• Dónde ocurrió.
• Quién o qué identidad participó.
• Por qué importa.
• Severidad y confianza.
• Pasos iniciales de investigación.
• Enlaces a logs, dashboards o runbooks.

21.13 Runbooks

Un runbook documenta cómo responder a una alerta o incidente. Reduce improvisación y acelera investigación.

Debe contener:

• Descripción del escenario.
• Consultas o dashboards relevantes.
• Preguntas de triage.
• Acciones de contención permitidas.
• Criterios de escalamiento.
• Riesgos de falsos positivos.
• Pasos de cierre y aprendizaje.

21.14 Errores frecuentes

• Recolectar logs sin definir casos de detección.
• No activar auditoría en cuentas o clusters nuevos.
• Guardar logs en el mismo entorno que puede ser comprometido.
• Alertar todo cambio sin priorizar severidad.
• No proteger logs contra borrado o modificación.
• Incluir secretos o datos sensibles en logs.
• No tener runbooks para alertas críticas.
• No revisar alertas ruidosas hasta que el equipo las ignora.

21.15 Lista de verificación

• ¿Los logs de auditoría cloud están habilitados en todas las cuentas o proyectos?
• ¿Kubernetes, CI/CD, registries y aplicaciones envían eventos relevantes?
• ¿Los logs críticos se centralizan y protegen contra borrado?
• ¿Existen casos de detección documentados?
• ¿Las alertas incluyen contexto y pasos de investigación?
• ¿Se correlacionan eventos de identidad, red, cloud y workloads?
• ¿La retención cumple requisitos de investigación y cumplimiento?
• ¿Hay runbooks para escenarios críticos?

21.16 Qué debes recordar de este tema

• Observabilidad de seguridad convierte eventos en detección e investigación.
• Los logs de auditoría cloud y Kubernetes son fuentes críticas.
• SIEM aporta valor cuando correlaciona señales de calidad.
• Las alertas deben ser accionables y tener runbooks.
• Los logs son evidencia; deben protegerse como activos sensibles.

21.17 Conclusión

Una plataforma cloud native segura necesita visibilidad continua. Logs, métricas, trazas, SIEM y alertas permiten detectar cambios peligrosos, investigar incidentes y mejorar controles con evidencia real.

En el próximo tema estudiaremos respuesta a incidentes en cloud y contenedores: contención, evidencia y recuperación.