Por quanto tempo guardar log: o que a lei brasileira exige

O que a lei brasileira realmente exige quando fala de "log"

Antes de definir prazo de retenção, é preciso separar o que a legislação brasileira chama de registro. O Marco Civil da Internet (Lei 12.965/2014) trabalha com duas categorias distintas: registro de conexão e registro de acesso a aplicações de internet. São coisas diferentes, com obrigados diferentes e prazos diferentes — e é exatamente aí que a maioria das empresas erra ao montar sua política de retenção.

Registro de conexão é o conjunto de informações referentes à data e hora de início e término de uma conexão à internet, sua duração e o endereço IP utilizado pelo terminal. Quem tem obrigação legal de guardar isso é o provedor de conexão — ou seja, a operadora, o ISP. O prazo, definido no artigo 13 do Marco Civil, é de um ano, e a guarda é obrigatória, sob sigilo, em ambiente controlado e seguro.

Registro de acesso a aplicações é o conjunto de informações referentes à data e hora de uso de uma determinada aplicação de internet a partir de um determinado endereço IP. Aqui o obrigado é o provedor de aplicação — todo site, sistema web, portal, e-commerce, SaaS ou intranet exposta. O prazo, no artigo 15, é de seis meses. E a obrigação recai sobre quem exerce essa atividade de forma organizada, profissionalmente e com fins econômicos, o que abrange praticamente qualquer empresa que mantenha um sistema acessível pela internet.

Os prazos que importam na prática — e por que seis meses não é o teto

O erro mais comum é tratar os seis meses do Marco Civil como se fossem o prazo máximo de retenção. Não são. São o prazo mínimo obrigatório para um tipo específico de registro. A legislação é explícita ao permitir que a autoridade policial, administrativa ou o Ministério Público requeiram a guarda por período superior, e que o próprio provedor guarde por mais tempo se houver base legal para isso.

Além do Marco Civil, outros prazos incidem sobre logs corporativos dependendo do setor e do tipo de dado envolvido:

• Marco Civil, art. 13 — registro de conexão: 1 ano (provedor de conexão)
• Marco Civil, art. 15 — registro de acesso a aplicações: 6 meses (provedor de aplicação)
• Lei 9.613/1998 (prevenção à lavagem de dinheiro) — registros de operações e cadastro: 5 anos, aplicável a setores obrigados
• Resoluções do Banco Central e normativos CVM — trilhas de auditoria de sistemas financeiros: comumente 5 anos
• Código Civil — prescrição de pretensões contratuais e reparatórias: até 10 anos em algumas hipóteses, o que na prática puxa a retenção de trilhas de auditoria de contratos e transações
• Normas trabalhistas — logs que sustentem controle de jornada ou acesso de colaboradores: alinhados ao prazo prescricional de 5 anos

Quando dois prazos incidem sobre o mesmo registro, vale o maior. Um log de autenticação em um sistema financeiro não é apagado aos seis meses porque o Marco Civil se satisfaz com isso — o normativo setorial manda guardar por cinco anos, e é esse que governa. Uma política de retenção madura documenta essa sobreposição por tipo de log, não por servidor.

LGPD: retenção não é só obrigação, é também limite

A Lei Geral de Proteção de Dados muda a lógica da conversa. Enquanto o Marco Civil diz "guarde no mínimo", a LGPD diz "não guarde além do necessário". Log de acesso contém endereço IP, identificador de usuário, horário e comportamento — dado pessoal por definição, e em alguns contextos dado que revela padrão de vida. Retenção indefinida deixa de ser prudência e passa a ser exposição.

O artigo 16 da LGPD determina a eliminação dos dados após o término do tratamento, ressalvadas hipóteses como cumprimento de obrigação legal, estudo por órgão de pesquisa, transferência a terceiro com observância dos requisitos legais, e uso exclusivo do controlador em forma anonimizada. Guardar log por obrigação do Marco Civil ou de normativo setorial se encaixa perfeitamente na primeira ressalva — mas isso precisa estar escrito, com o prazo definido e a base legal apontada.

Log guardado sem prazo definido e sem base legal documentada é passivo duplo: falha de compliance com a LGPD por retenção excessiva, e falha de defesa em incidente porque ninguém sabe o que existe nem onde procurar.

A consequência operacional é direta: a política precisa ter data de expurgo tanto quanto tem data de início. Um sistema que só acumula e nunca elimina não está em conformidade — está apenas postergando o problema até o dia da fiscalização ou do vazamento. E o expurgo precisa ser demonstrável, com registro de que ocorreu, quando e sobre qual conjunto de dados.

Integridade e cadeia de custódia: log que não prova nada

Guardar pelo prazo certo resolve metade do problema. A outra metade é garantir que aquele registro tenha valor probatório quando for preciso apresentá-lo. Um arquivo de texto em um diretório onde o administrador local tem permissão de escrita não sustenta uma tese em juízo nem numa apuração interna, porque não há como demonstrar que não foi alterado.

Os controles que dão integridade a um acervo de log são conhecidos e implementáveis sem grande complexidade:

1. Centralização — log sai do host de origem em tempo quase real para um coletor dedicado. Se o host é comprometido, o atacante não alcança o histórico já enviado.
2. Append-only / imutabilidade — armazenamento com WORM ou object lock, onde nem a conta administrativa consegue sobrescrever antes do prazo. Retenção com bloqueio de exclusão é hoje recurso padrão em armazenamento de objetos.
3. Sincronização de tempo — NTP confiável em todos os nós. Timestamp divergente entre servidores destrói a correlação e enfraquece a prova.
4. Hash e selo temporal — assinatura periódica dos blocos de log, permitindo demonstrar que o conteúdo é o mesmo daquele momento.
5. Controle de acesso segregado — quem administra o sistema monitorado não administra o repositório de log. Sem essa separação, a trilha de auditoria audita quem a controla.
6. Registro do próprio acesso ao log — consulta ao acervo também gera registro, atendendo à exigência de sigilo do Marco Civil.

Vale lembrar que o Marco Civil impõe sigilo sobre esses registros e condiciona a entrega de conteúdo à ordem judicial. Isso significa que a área de TI não pode tratar o repositório de log como base de consulta livre para gestores. Precisa haver processo formal: quem pede, com que justificativa, quem autoriza e o que é entregue.

Como guardar anos de log sem estourar o armazenamento

A objeção prática mais frequente é custo. Log corporativo cresce rápido: firewall de borda, controlador de domínio, servidor de e-mail, aplicação web e endpoints somam volume considerável por dia numa empresa média. Retenção de cinco anos em disco quente é economicamente inviável para a maioria — e desnecessária.

A saída é retenção em camadas, dimensionada por utilidade ao longo do tempo:

• Camada quente (0 a 30 dias) — log indexado e pesquisável em segundos, alimentando detecção, alerta e resposta a incidente. É a camada caras e a menor.
• Camada morna (30 dias a 6 meses) — log comprimido, ainda pesquisável mas com latência de minutos. Cobre o prazo do Marco Civil e a janela típica de investigação de incidente descoberto com atraso.
• Camada fria (6 meses a 5 anos) — arquivamento comprimido em armazenamento de objetos com object lock, restaurado sob demanda. Cobre prazos setoriais, prescrição e litígio. Custo por terabyte é uma fração da camada quente.

Três decisões de engenharia reduzem drasticamente o volume sem perder valor legal ou forense. Primeira: filtrar na origem o que é puro ruído operacional — mensagens de debug, heartbeat de serviço, verificação de saúde. Isso não é registro de acesso e não precisa de retenção longa. Segunda: normalizar antes de arquivar, gravando campo estruturado em vez de linha de texto redundante; a compressão sobre dado estruturado é muito mais eficiente. Terceira: separar por classe de log, aplicando retenção longa apenas ao que a lei exige — autenticação, acesso a aplicação, alteração de privilégio, acesso a dado pessoal — e retenção curta ao resto.

Fechando o ciclo, a política precisa ser testada. Restauração periódica de um trecho da camada fria, medindo o tempo até o dado ficar disponível, é o único jeito de saber se o acervo responde quando a autoridade der prazo de dez dias. Backup ou arquivo que nunca foi restaurado é hipótese, não controle.

Transformando exigência legal em controle que funciona

Montar retenção de log conforme a lei brasileira é um projeto que cruza jurídico, TI e negócio: mapear quais sistemas geram registro de acesso a aplicação, identificar prazos setoriais aplicáveis, dimensionar as camadas de armazenamento, implementar imutabilidade, definir o processo de atendimento a ordem judicial e documentar tudo no inventário de tratamento exigido pela LGPD. Nenhuma dessas etapas é especialmente difícil isoladamente — a dificuldade está em fazê-las de forma coerente e mantê-las vivas depois que o projeto acaba.

É esse trabalho que a Duk Informática & Cloud entrega há mais de 18 anos para os 550+ clientes que atende. Como Microsoft Gold Partner, a Duk implementa centralização de log, retenção em camadas com imutabilidade, sincronização de tempo e segregação de acesso ao acervo usando a infraestrutura que a empresa já tem — seja no data center próprio em Alphaville, seja em nuvem — com SLA e suporte 24/7 para quando a solicitação chegar com prazo curto.

Se sua empresa não sabe hoje onde estão os logs dos últimos seis meses, quem pode alterá-los ou quanto tempo levaria para responder a uma requisição judicial, o momento de resolver isso é antes de precisar. Fale com a Duk para um diagnóstico da sua política de retenção: mapeamento das obrigações que se aplicam ao seu setor, avaliação do que já existe e desenho da arquitetura de guarda dimensionada para o seu volume real.