Auditoria de logs: quando o log vira banco de dados pessoais

Pergunte a um time de engenharia onde vivem os dados pessoais da empresa e a resposta quase sempre aponta para o banco de produção, talvez para a base de análise. Raramente alguém aponta para os logs. No entanto, o log de aplicação médio registra endereço IP (Internet Protocol), identificador de conta, e-mail embutido em parâmetro de requisição e cada ação do usuário com data e hora. Linha por linha, ele fala sobre pessoas.

A Lei Geral de Proteção de Dados (LGPD, Lei 13.709/2018) define dado pessoal no art. 5º, inciso I, como informação relacionada a pessoa natural identificada ou identificável. A definição não exige nome nem CPF (Cadastro de Pessoas Físicas) no registro: basta que a informação, sozinha ou combinada com outras, permita chegar a alguém. Sob essa régua, o arquivo de log que a sua aplicação escreve todos os dias já é um banco de dados pessoais. A diferença é que ele quase nunca aparece no inventário de tratamento, não tem dono definido, não tem prazo de descarte e costuma ser legível por qualquer pessoa com acesso ao servidor.

Este texto é para quem constrói ou audita sistemas que registram eventos: engenharia, segurança da informação e o encarregado de proteção de dados. O objetivo é sair daqui sabendo classificar os próprios logs, resolver o aparente conflito entre guarda obrigatória e minimização, e reconhecer os vazamentos que nascem dentro do log antes que uma auditoria os encontre.

Por que o art. 5º da LGPD alcança o seu log

O texto legal é curto e vale ler na fonte, no site do Planalto:

Dado pessoal: informação relacionada a pessoa natural identificada ou identificável (Lei 13.709/2018, art. 5º, I).

A palavra decisiva é identificável. Um endereço IP com data e hora não diz o nome de ninguém, mas cruzado com o cadastro do provedor de conexão ele aponta para um assinante. Um identificador interno de conta parece opaco, mas a própria empresa tem a tabela que o liga a um cliente concreto. Pseudônimo não é anonimização: como já mostramos ao tratar de anonimização e pseudonimização, o dado pseudonimizado continua sendo dado pessoal enquanto a chave de reversão existir em algum lugar.

Aplique esse teste ao seu log de aplicação. Se ele guarda IP de origem, identificador de sessão, conta que executou a ação e o que foi feito, ele é um repositório de dados pessoais comportamentais. E repositórios de dados pessoais têm obrigações: base legal, prazo, segurança, resposta ao titular. Nada disso deixa de valer porque o formato é texto puro rotacionado por dia.

Guarda obrigatória e minimização: o conflito é aparente

O contra-argumento clássico é que a lei manda guardar logs. Manda mesmo, e é bom conhecer os artigos exatos. O Marco Civil da Internet (Lei 12.965/2014, disponível no Planalto) obriga o provedor de conexão a guardar registros de conexão por 1 ano (art. 13) e o provedor de aplicações a guardar registros de acesso a aplicações por 6 meses (art. 15). A LGPD, por sua vez, reconhece o cumprimento de obrigação legal como base de tratamento no art. 7º, inciso II. Até aqui, nenhuma tensão: guardar o que o Marco Civil manda é tratamento lícito.

O conflito aparece quando a obrigação vira álibi. O próprio Marco Civil define registro de acesso a aplicações de forma estreita, no art. 5º, inciso VIII: o conjunto de informações referentes à data e hora de uso de uma determinada aplicação a partir de um determinado endereço IP. É isso que o art. 15 manda guardar por 6 meses. Não é o corpo da requisição, não é o histórico detalhado de navegação, não é o dump de erro com payload completo. Quem justifica um log de tudo para sempre citando o art. 15 está esticando a norma para cobrir dados que ela nunca pediu.

A resolução prática é escopo. Guarde o que a lei manda, pelo prazo que a lei manda, no formato que a lei descreve. Todo o resto é tratamento que precisa se sustentar em outra base, tipicamente o legítimo interesse, com prazo próprio e proporcionalidade demonstrável. O detalhe dos prazos e do que conta como registro de conexão e de acesso está destrinchado no nosso guia sobre guarda de logs no Marco Civil.

Os vazamentos clássicos nascem dentro do log

Auditorias de log costumam encontrar as mesmas três famílias de problema.

A primeira é o dado sensível em URL (Uniform Resource Locator). Servidores e proxies registram a linha de requisição por padrão, com a query string completa. Se a aplicação passa CPF, e-mail ou token por parâmetro de URL, esse dado está sendo copiado para o log de acesso de cada camada da infraestrutura, com retenção que ninguém controla.

A segunda é o payload completo logado em erro. O tratador de exceção que despeja o corpo da requisição no log para facilitar o diagnóstico transforma cada falha em uma cópia não gerenciada de tudo que o usuário enviou: documento, endereço, foto codificada em base64. O log de erro passa a conter exatamente os dados que o banco principal protege com criptografia e controle de acesso, só que em texto plano.

A terceira é o log de depuração ligado em produção. Em sistemas de verificação de identidade o risco é máximo: imagem de documento e dado biométrico transitando por um log de debug esquecido. Dado biométrico é dado sensível pelo art. 5º, inciso II, da LGPD, e um vazamento por essa via tem o mesmo peso de um vazamento do banco principal, como detalhamos no texto sobre incidente com dado biométrico.

Práticas que se defendem numa auditoria

Quatro práticas separam quem trata log como ativo de quem trata como entulho acumulado.

1. Classes de log com retenção própria. Separe o registro de acesso do art. 15, com seus 6 meses, do log operacional de diagnóstico, que raramente precisa de mais de 30 a 90 dias, e da trilha de auditoria de negócio, que pode exigir anos. Uma política única de retenção para tudo é sinal de que ninguém pensou no assunto.

1. Mascaramento na origem, não depois. O dado que não entra no log não vaza pelo log. Filtros de campo no próprio logger, com CPF truncado, token omitido e corpo de requisição bloqueado por padrão, valem mais do que qualquer varredura posterior, porque a varredura chega depois que a cópia já se espalhou por agregadores e backups.

1. Log como ativo, com trilha do próprio acesso. A LGPD exige, no art. 46, medidas de segurança aptas a proteger os dados pessoais de acessos não autorizados. Para logs, isso significa controle de acesso restrito e um princípio que surpreende quem nunca pensou nele: quem consultou o log também é evento auditável. A norma internacional de gestão de segurança da informação ISO/IEC 27001 (da International Organization for Standardization com a International Electrotechnical Commission) segue a mesma linha ao tratar o registro de eventos e a proteção da informação de log como objeto de controle específico.

1. Logs no inventário e no plano de incidente. Se o mapa de tratamento de dados da empresa não lista os logs, ele está incompleto. E o plano de resposta a incidente precisa prever o cenário em que a fonte do vazamento é o próprio log, porque a resposta, que passa por identificar titulares afetados e medir a extensão, depende de saber o que havia lá dentro.

Sinal de maturidade: auditoria imutável e separada

O estágio mais maduro dessa disciplina é separar fisicamente a trilha de auditoria do log operacional. O log operacional existe para diagnosticar o sistema e pode ser agressivamente minimizado e descartado. A trilha de auditoria existe para provar quem fez o quê e precisa ser imutável: escrita uma vez, sem edição nem deleção, idealmente em armazenamento de escrita única (WORM, write once, read many) ou em tabela sem caminho de atualização.

Esse desenho resolve o dilema aparente entre auditabilidade e minimização. Na UNIFOKAL, por exemplo, a trilha de auditoria de ações administrativas registra quem fez o quê, mas os metadados da trilha são desenhados para não carregar dado pessoal da pessoa verificada: a trilha prova a ação do operador sem duplicar o dado do titular. A auditoria fica completa e o log não vira uma segunda cópia do banco de dados pessoais.

O teste final é simples de aplicar na sua operação. Escolha um log qualquer e pergunte qual é a base legal dele, qual é o prazo, quem acessa e se ele aparece no inventário. Se alguma resposta for um não sei, você acabou de encontrar um banco de dados pessoais sem dono.

Fontes citadas

• Lei nº 13.709/2018 (Lei Geral de Proteção de Dados), arts. 5º, 7º e 46, texto no site do Planalto
• Lei nº 12.965/2014 (Marco Civil da Internet), arts. 5º, 13 e 15, texto no site do Planalto
• ISO/IEC 27001, norma internacional de gestão de segurança da informação