Retención de logs: guardar lo necesario para investigar

Ciberseguridad · 2 min

Artículos de Fábio Ribeiro

Guardar logs sin criterio aumenta costos y ruido. Aprenda cómo definir una retención útil para seguridad, continuidad y auditoría.

Retención de logs: guardar lo necesario para investigar

TL;DR

La pregunta correcta no es cuánto guardar

Muchas organizaciones comienzan la política de retención de logs por la capacidad de la plataforma: cuánto espacio existe, cuánto cuesta almacenar y durante cuánto tiempo es técnicamente posible mantener eventos. La pregunta más útil es diferente: ¿qué información será necesaria para reconstruir un incidente, confirmar una alteración, responder a una auditoría o demostrar la ejecución de un control? Este enfoque evita dos extremos frecuentes: guardar todo sin contexto, creando costo y ruido, o guardar solo eventos agregados que no permiten investigar con confianza.

Definir escenarios antes de definir plazos

La retención debe diseñarse a partir de escenarios concretos: acceso administrativo indebido, alteración crítica de configuración, fallo de autenticación, exfiltración sospechosa, indisponibilidad de servicio o ejecución de acción privilegiada. Para cada escenario, es importante identificar fuentes, campos necesarios, necesidades de retención, período de análisis necesario y equipos involucrados. Las plataformas de [observabilidad y AIOps](/pt/solucoes/sistemas-monitorizacao) pueden ayudar a centralizar eventos, pero no sustituyen la decisión sobre qué logs tienen valor operacional, probatorio o de conformidad.

No todos los logs tienen el mismo valor

Los eventos de identidad, administración, red, sistemas, aplicaciones críticas, copias de seguridad y servicios cloud no deben ser tratados como si tuvieran el mismo peso. Algunos exigen mayor detalle y protección contra la alteración; otros pueden ser agregados o retenidos por menos tiempo. También es importante distinguir logs técnicos de telemetría voluminosa, registros con datos personales, evidencia de seguridad y métricas de rendimiento. Una política madura define clases de logs, propietarios, finalidad, ubicación, período de retención y criterios de eliminación.

El contexto es tan importante como el volumen

Los logs sin contexto rara vez aceleran una investigación. Un evento de acceso es más útil cuando puede relacionarse con identidad, dispositivo, aplicación, ubicación, alteración aprobada y servicio afectado. La conexión a inventarios, dependencias y procedimientos operativos mejora la interpretación de las señales. Cuando ocurre un incidente, los [runbooks bien definidos](/pt/blog/runbooks-automatizacao-resposta-incidentes) ayudan a transformar esos datos en decisiones repetibles: qué validar primero, a quién involucrar, qué evidencia preservar y cuándo escalar.

Proteger los logs contra abuso y pérdida

Los propios logs pueden volverse sensibles. Pueden revelar patrones de utilización, direcciones, nombres de usuarios, claves mal expuestas, errores de aplicación o información de clientes. Por ello, la retención debe incluir control de acceso, segregación de funciones, cifrado cuando sea adecuado, pistas de auditoría sobre la consulta y mecanismos de inmutabilidad cuando el riesgo lo justifique. En un modelo con [SOC/NOC as a Service](/pt/solucoes/soc-noc-as-a-service), conviene clarificar contractualmente quién puede consultar, exportar, modificar y eliminar registros.

Revisar la política basándose en el riesgo

Una política de retención de logs no debe quedar congelada. Nuevas aplicaciones, servicios SaaS, integraciones, cambios regulatorios, auditorías e incidentes deben llevar a revisiones periódicas. La decisión no es solo técnica: involucra seguridad, operaciones, legal, cumplimiento y responsables de negocio. El objetivo es mantener evidencia suficiente para investigar y demostrar control, sin acumular datos sin una finalidad clara. Una buena política ayuda a reducir la incertidumbre cuando ocurre un incidente y hace más predecible el equilibrio entre costo, riesgo y utilidad.

Referencias

  1. Guide to Computer Security Log Management
  2. TECHNICAL IMPLEMENTATION GUIDANCE