Log de auditoria imutável: como provar que o registro não foi alterado

Quase todo sistema regulado afirma ter trilha de auditoria imutável, e a evidência costuma ser a mesma: uma tabela no banco de produção em que a aplicação só insere e nunca atualiza, o chamado append-only, registro só de acréscimo. Isso é uma afirmação sobre o comportamento do código, não uma propriedade do armazenamento.

A diferença que importa é entre um registro que você garante e um que se sustenta sem a sua palavra: no primeiro, a prova é a declaração do operador; no segundo, alterar a trilha exige quebrar algo verificável por quem não confia em você.

Este texto é para quem projeta ou audita a trilha de eventos de um produto regulado.

A pergunta que derruba a maioria das implementações

A pergunta é curta: quem pode apagar uma linha dessa tabela? Quase sempre, a credencial de administração do banco. Ela apaga a linha, derruba a restrição que impedia a atualização, altera a definição da tabela e, em muitos desenhos, limpa o registro disso.

O adversário que importa não é o invasor genérico da internet, é o insider com acesso legítimo. Contra quem administra a base, uma tabela append-only protegida pela mesma credencial do resto do sistema não prova nada: a convenção de nunca atualizar só é obedecida pelo código da aplicação, e o adversário não passa por ali.

A recomendação clássica ataca isso pelo lado da permissão. Na seção de segurança de logs do SP 800-92, Guide to Computer Security Log Management, de setembro de 2006, o NIST (National Institute of Standards and Technology) pede limitar o acesso aos arquivos de log, conceder privilégio de acréscimo apenas e não deixar que usuários os renomeiem ou apaguem. Escrita para arquivo, ela vale igual para tabela.

As camadas que encarecem adulterar, em ordem crescente

Separação de credencial e de permissão. Quem escreve não pode apagar: a aplicação recebe permissão de inserção na tabela de auditoria e nada além. O SP 800-92 recomenda separação de funções, com a revisão dos logs a cargo de quem não administra o sistema revisado, como no desenho de quem vê e age dentro do painel de verificação.

Encadeamento por resumo criptográfico. Cada registro guarda o resumo do próprio conteúdo e o do anterior, então alterar ou remover um evento antigo deixa de custar uma linha e passa a custar a cauda inteira. Só que encadear não impede adulterar, encarece: quem tem a credencial refaz a cauda e entrega uma corrente internamente coerente. E num caso nem refazer é preciso, o de cortar o fim: apagados os últimos registros, o que sobra continua consistente consigo mesmo. O SP 800-92 já recomendava resumos criptográficos para os logs arquivados.

Ancoragem periódica do resumo. Fecha os dois buracos acima, e também não previne: torna detectável. Publicado o resumo de ontem onde você não manda sozinho, a corrente refeita, ou cortada, não bate com aquele valor, e quem confere dispensa a sua palavra. Vale guardar a âncora sob outra administração ou pedir carimbo de tempo a um terceiro, padronizado pela RFC (Request for Comments) 3161, de agosto de 2001: a autoridade de carimbo assina o resumo junto com o instante, e a assinatura é dela, não sua.

Retenção imutável no armazenamento. A impossibilidade sai da convenção e entra na camada de objeto: armazenamento de escrita única e leitura múltipla, o modelo WORM (write once, read many), com prazo travado. Vale conferir se o modo de bloqueio contratado deixa uma conta privilegiada encurtar esse prazo, porque o modo permissivo devolve ao administrador o poder que se queria tirar dele.

Saída para fora do host. Se a trilha só existe onde o sistema roda, quem toma o sistema toma a trilha, e a âncora do degrau anterior prova o estrago sem devolver o conteúdo. Encaminhar os eventos, perto do tempo real, para infraestrutura sob outra administração preserva a cópia.

Árvore de Merkle: prova de inclusão e de consistência

Log verificável por terceiro não precisa ser inventado: o Certificate Transparency, que registra publicamente a emissão de certificados TLS (Transport Layer Security), está em produção há mais de uma década. A RFC 6962, de junho de 2013, foi substituída pela RFC 9162, Certificate Transparency Version 2.0, de dezembro de 2021, ambas experimentais.

Vale copiar a estrutura, não o domínio. Os eventos entram como folhas de uma árvore de Merkle binária: cada folha é o resumo de um evento, cada nó acima é o resumo dos filhos, e o topo condensa o log num único valor. Sobre isso a RFC 9162 define duas provas: a de inclusão, que mostra que um registro está na árvore sem ler o log inteiro, e a de consistência, que mostra que a árvore de hoje contém a de ontem, ou seja, que o log só cresceu.

São as duas provas que faltam na tabela append-only comum: com elas, um auditor confirma que o seu registro está lá e que o histórico não foi reescrito. A própria RFC 9162 marca o limite disso: as provas valem contra o topo assinado que o log apresenta, e um log que mostre árvores diferentes a partes diferentes contorna a auditoria, razão pela qual o documento ainda o trata como terceiro confiável. Flagrar essa divergência depende de os verificadores compararem entre si os topos recebidos, técnica que a RFC nomeia gossip e deixa fora do próprio escopo. E não é blockchain: não há consenso distribuído nem moeda, e a árvore roda num banco relacional comum.

Entregar para fora sem perder nem duplicar

A regra que funciona lá fora é entrega ao menos uma vez com desduplicação do outro lado: o exportador mantém um cursor persistido, só o avança depois que o destino confirma o recebimento, e cada registro carrega identificador estável derivado do evento, não do relógio. Avançar o cursor antes da confirmação inverte o risco: troca duplicata, que a desduplicação resolve, por perda, que nada resolve.

O caso que quebra implementações ingênuas é o destino fora do ar por horas: a fila acumula, o cursor fica parado e o alerta dispara por atraso do cursor, não por erro isolado de requisição. E o exportador nunca pula registros para alcançar o presente. A leitura de volta merece a disciplina de um teste de restauração de backup: trilha que ninguém releu inteira não é trilha verificada.

O que o auditor efetivamente pede

A régua é modesta e específica: para cada evento relevante, quem fez, o que fez, quando, de onde e sobre qual objeto, com horário sincronizado, fuso explícito e o instante do fato separado do da gravação.

E com retenção pelo prazo da norma aplicável, longo no perímetro do Banco Central do Brasil: a Circular BCB 3.978/2020 manda conservar por no mínimo dez anos, no artigo 67, as informações do conhecimento do cliente. A ISO/IEC 27001, da International Organization for Standardization com a International Electrotechnical Commission, também põe registro de eventos e proteção da informação de log entre seus objetos de controle. E o defeito que a auditoria encontra, catalogado nos erros que reprovam em auditoria, quase nunca é de criptografia: é evento relevante que ninguém registrou.

O limite honesto da promessa

Nenhuma dessas camadas impede que se escreva mentira no log. Encadeamento, ancoragem, retenção imutável e exportação protegem o que já foi escrito contra alteração e apagamento, e nada dizem sobre a correspondência entre registro e mundo. Um sistema que grava a aprovação sem o motivo produz trilha íntegra e inútil. Resolvida a integridade, o difícil volta a ser decidir o que entra no registro.

Trilha de auditoria também costuma conter dado pessoal, e por isso responde à minimização e ao prazo do princípio da necessidade, artigo 6º, inciso III, da Lei 13.709/2018, a LGPD (Lei Geral de Proteção de Dados). Uma corrente de resumos não admite apagar linha do meio: a saída de projeto é manter o dado pessoal fora do bloco encadeado, referenciando identificadores em vez de repetir conteúdo, tema do artigo sobre auditoria de logs e dados pessoais.

Fontes citadas

• NIST SP 800-92, Guide to Computer Security Log Management, setembro de 2006, seção de segurança de logs, no CSRC do NIST; versão em vigor, com a revisão 1 ainda em rascunho
• RFC 9162, Certificate Transparency Version 2.0, dezembro de 2021, árvore de Merkle, provas de inclusão e de consistência e a ressalva sobre visões inconsistentes do log; obsoleta a RFC 6962, de junho de 2013
• RFC 3161, Internet X.509 Public Key Infrastructure Time-Stamp Protocol, agosto de 2001, carimbo de tempo por autoridade terceira
• ISO/IEC 27001, gestão de segurança da informação, registro de eventos e proteção da informação de log
• Circular BCB 3.978/2020, do Banco Central do Brasil, artigo 67, conservação por no mínimo dez anos
• Lei nº 13.709/2018 (LGPD), artigo 6º, inciso III, princípio da necessidade, no site do Planalto