Registros de eventos: o que guardar e por quanto tempo
Registros de eventos — os logs de sistemas, e-mail, firewall e aplicações — só valem algo se você guardar os tipos certos pelo tempo certo. A resposta prática para uma organização de médio porte é esta: priorize registros de autenticação, acesso a dados pessoais, ações administrativas e tráfego de perímetro; mantenha o essencial consultável por 90 dias, arquive por 12 meses o que sustenta investigação e descarte o resto seguindo uma regra escrita. Esses números são exemplo próprio desta equipe editorial, não exigência legal; o resto do artigo mostra como chegar à sua própria política sem contratar mais gente.
Nem é preciso começar pagando: o CISA mantém o Logging Made Easy (LME), uma solução gratuita e centralizada de log management e detecção de ameaças para organizações de pequeno e médio porte com recursos limitados, e a ferramenta pode ser baixada sem custo. O ponto central, porém, não é a ferramenta: é a decisão sobre o que registrar e por quanto tempo guardar, porque sem essa decisão o armazenamento vira custo e o vazio de registros vira risco no pior momento.
Quais registros guardar primeiro
A ordem de prioridade segue uma pergunta simples: se amanhã alguém suspeitar de invasão, qual registro responderia quem fez isso, quando e a partir de onde? Priorize o que liga identidade, tempo e ação. Para transformar isso em processo, e não em improviso, o guia do NIST sobre log management orienta desenvolver, implementar e manter práticas eficazes de gestão de registros em toda a organização; log management, em bom português, é exatamente essa disciplina contínua de coletar, proteger e usar registros de segurança.
Registrar tudo também não é resposta. Senhas, tokens e conteúdo de mensagens não devem ir para o log; quando o registro carrega dados pessoais, anote o identificador e a operação, não o conteúdo. Relógios sincronizados completam o básico: sem horário confiável, correlacionar dois registros de sistemas diferentes é adivinhação.
A tabela abaixo resume a ordem recomendada de cobertura. A coluna de retenção é sugestão inicial (exemplo próprio) para calibrar conforme o seu risco e a sua regulação:
| Tipo de registro | Por que guardar | Retenção inicial sugerida |
|---|---|---|
| Autenticação e MFA | Mostra quem entrou, de qual IP e quando | 90 dias ativos e 12 meses arquivado |
| Acesso a dados pessoais | Sustenta investigação de vazamento e resposta ao titular | 12 meses |
| Ações de administrador | Revela escalada de privilégio e mudança de configuração | 12 meses |
| E-mail e antispam | Permite rastrear o phishing que chegou e foi clicado | 90 dias ativos |
| Firewall e VPN | Registra a origem do acesso remoto e tráfego anômalo | 90 dias ativos |
| Antivírus e EDR | Guarda detecções e quarentenas para correlacionar | 90 dias ativos |
Por quanto tempo reter
O tempo de retenção equilibra dois custos opostos. Guardar pouco impede a investigação: ataques de ransomware costumam passar semanas escondidos antes da criptografia, e sem histórico você nunca descobre quando a invasão começou nem o que foi copiado. Guardar demais viola o princípio de minimização de dados pessoais, encarece o armazenamento e cria um cofre de informações sensíveis que também precisa de proteção.
Uma política de três camadas resolve o impasse na maioria das organizações: camada operacional de 30 dias com tudo em alta velocidade de consulta; camada de investigação de 90 dias com os tipos prioritários da tabela; camada de arquivo de 12 meses apenas para autenticação, acesso a dados pessoais e ações administrativas. Depois disso, descarte automático — guardar para sempre, por garantia, é decisão que ninguém consegue defender depois. O que não pode acontecer é cada sistema decidir sozinho: a regra precisa estar escrita, com dono e data de revisão.
Verifique também o padrão de cada ferramenta antes de assumir que a política está valendo: vários sistemas vêm de fábrica com rotação curta de registros e silenciosamente apagam em dias o que a sua política manda manter meses. A política só existe de verdade quando confere com a configuração real de cada fonte.
Duas regras protegem a credibilidade do que você guardou. Primeiro, restrinja o acesso ao cofre de logs: quem administra um sistema não deve poder apagar o registro das próprias ações. Segundo, preserve a integridade — uma cópia apenas leitura, separada da rede onde o incidente pode ter ocorrido, impede que o invasor apague os rastros.
Incidentes, LGPD e prazos
O registro é o que transforma um susto em uma resposta formal. No Brasil, a LGPD impõe aos controladores, em seu art. 48, o dever de comunicar à ANPD e aos titulares a ocorrência de incidentes que possam causar riscos ou danos relevantes. Sem logs de acesso, a organização não consegue saber quais dados foram afetados nem estimar o risco — e comunica mal, atrasa ou nem percebe. O registro também protege o caminho inverso: quando bem guardado, ele demonstra diligência e limita o alcance do incidente.
Para quem opera na União Europeia, a lógica de responsabilização é semelhante no RGPD, com deveres de segurança e de resposta que dependem das mesmas evidências; os deveres principais do RGPD para PME são detalhados em guia próprio deste site. Independentemente da jurisdição, o teste final da sua retenção é outro: conseguir responder em 48 horas o que aconteceu, quando começou e quais dados foram tocados — número ilustrativo de meta operacional, não prazo legal.
Na prática, anote junto ao incidente o que cada registro mostrou, com data e responsável. Essa memória curta vira o relatório que sustenta a comunicação, o seguro e qualquer reivindicação posterior. Sem esse hábito, a mesma investigação é refeita três vezes e as versões divergem.
Checklist mínimo de retenção
Este procedimento é um exemplo próprio, pensado para ser concluído em uma semana sem compra de ferramenta:
- Liste os sistemas que geram registros hoje e onde cada um guarda o próprio log.
- Marque quais tipos da tabela de prioridade já estão ativos e por quantos dias cada ferramenta retém.
- Escolha um ponto central de coleta — o LME do CISA é uma opção sem custo, e o servidor syslog que você já opera é outra.
- Defina por escrito a política de três camadas, com responsável e revisão semestral.
- Teste: gere um evento controlado em um sistema e cronometre quanto tempo leva para encontrá-lo na busca central.
- Documente o descarte e a proteção do próprio cofre de logs: quem pode ler, onde fica a cópia intocável.
Se a sua organização quer sair do papel com um diagnóstico do que já registra e do que falta, fale com a AtalaiaSec: a primeira conversa mapeia as lacunas de cobertura e de retenção antes de qualquer proposta de serviço.