Retenção de logs: guardar o necessário para investigar

Cibersegurança · 2 min

Artigos de Fábio Ribeiro

Guardar logs sem critério aumenta custos e ruído. Saiba como definir retenção útil para segurança, continuidade e auditoria.

Retenção de logs: guardar o necessário para investigar

TL;DR

A pergunta certa não é quanto guardar

Muitas organizações começam a política de retenção de logs pela capacidade da plataforma: quanto espaço existe, quanto custa armazenar e durante quanto tempo é tecnicamente possível manter eventos. A pergunta mais útil é diferente: que informação será necessária para reconstruir um incidente, confirmar uma alteração, responder a uma auditoria ou demonstrar a execução de um controlo? Esta abordagem evita dois extremos frequentes: guardar tudo sem contexto, criando custo e ruído, ou guardar apenas eventos agregados que não permitem investigar com confiança.

Definir cenários antes de definir prazos

A retenção deve ser desenhada a partir de cenários concretos: acesso administrativo indevido, alteração crítica de configuração, falha de autenticação, exfiltração suspeita, indisponibilidade de serviço ou execução de ação privilegiada. Para cada cenário, importa identificar fontes, campos necessários, necessidades de retenção, período de análise necessário e equipas envolvidas. Plataformas de [observabilidade e AIOps](/pt/solucoes/sistemas-monitorizacao) podem ajudar a centralizar eventos, mas não substituem a decisão sobre que logs têm valor operacional, probatório ou de conformidade.

Nem todos os logs têm o mesmo valor

Eventos de identidade, administração, rede, sistemas, aplicações críticas, cópias de segurança e serviços cloud não devem ser tratados como se tivessem o mesmo peso. Alguns exigem maior detalhe e proteção contra alteração; outros podem ser agregados ou retidos por menos tempo. Também é importante distinguir logs técnicos de telemetria volumosa, registos com dados pessoais, evidência de segurança e métricas de desempenho. Uma política madura define classes de logs, proprietários, finalidade, localização, período de retenção e critérios de eliminação.

Contexto é tão importante quanto volume

Logs sem contexto raramente aceleram uma investigação. Um evento de acesso é mais útil quando pode ser relacionado com identidade, dispositivo, aplicação, localização, alteração aprovada e serviço afetado. A ligação a inventários, dependências e procedimentos operacionais melhora a interpretação dos sinais. Quando existe um incidente, [runbooks bem definidos](/pt/blog/runbooks-automatizacao-resposta-incidentes) ajudam a transformar esses dados em decisões repetíveis: o que validar primeiro, quem envolver, que evidência preservar e quando escalar.

Proteger os logs contra abuso e perda

Os próprios logs podem tornar-se sensíveis. Podem revelar padrões de utilização, endereços, nomes de utilizadores, chaves mal expostas, erros de aplicação ou informação de clientes. Por isso, a retenção deve incluir controlo de acesso, segregação de funções, cifragem quando adequada, trilhos de auditoria sobre a consulta e mecanismos de imutabilidade quando o risco o justificar. Num modelo com [SOC/NOC as a Service](/pt/solucoes/soc-noc-as-a-service), convém clarificar contratualmente quem pode consultar, exportar, modificar e eliminar registos.

Rever a política com base no risco

Uma política de retenção de logs não deve ficar congelada. Novas aplicações, serviços SaaS, integrações, alterações regulatórias, auditorias e incidentes devem levar a revisões periódicas. A decisão não é apenas técnica: envolve segurança, operações, jurídico, conformidade e responsáveis de negócio. O objetivo é manter evidência suficiente para investigar e demonstrar controlo, sem acumular dados sem finalidade clara. Uma boa política ajuda a reduzir incerteza quando ocorre um incidente e torna mais previsível o equilíbrio entre custo, risco e utilidade.

Referências

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