Pular para o conteúdo

Regulatório

Trilha de auditoria à prova de adulteração com hash encadeado

Um log de auditoria que o próprio administrador do banco pode editar não prova nada. Encadear cada registro ao hash do anterior transforma a trilha em evidência verificável — e custa pouquíssimo para implementar.

Equipe Omnix6 min de leitura

Pergunte ao seu fornecedor de LIS como a trilha de auditoria é protegida. Se a resposta for “só o administrador tem acesso”, a trilha não é evidência — é um registro de boa-fé que qualquer UPDATE desfaz sem deixar marca.

Num sistema regulado, isso importa: a auditoria existe justamente para o cenário em que alguém tem motivo para mudar o passado.

A ideia, em uma linha

Cada entrada da trilha grava, além dos próprios dados, um hash que inclui o hash da entrada anterior:

integrityHash = SHA-256( conteúdo da entrada atual + integrityHash da entrada anterior )

O efeito é o de um dominó ao contrário. Alterar uma entrada antiga muda o hash dela; como a entrada seguinte incorporou o hash antigo, ela deixa de fechar; e o mesmo vale para todas as posteriores. Não existe edição silenciosa: ou a cadeia inteira é recalculada — o que é detectável, porque exige reescrever tudo — ou a quebra aparece na primeira verificação.

O que cada entrada precisa carregar

Hash sem conteúdo é enfeite. A entrada útil tem:

  • contexto multi-tenant: tenant, laboratório e unidade — sem isso a trilha de uma rede vira um caldeirão;
  • quem: o usuário, com o papel que ele exercia naquele momento (papel muda; o registro histórico não pode mudar junto);
  • quando, com fuso horário;
  • ação e entidade: resultado.validar, amostra.rejeitar, fatura.cancelar — verbo e objeto, não uma frase livre;
  • o detalhe da mudança: o antes e o depois dos campos que mudaram;
  • o hash.

Um detalhe fácil de errar: o conteúdo que entra no hash precisa ser serializado de forma determinística. Se a ordem das chaves do JSON variar entre duas execuções, a verificação acusa adulteração onde não houve, e a equipe aprende a ignorar o alarme — que é o pior desfecho possível.

O que a norma pede e o que o hash entrega

A RDC 786/2023 espera rastreabilidade auditável dos atos: quem liberou o laudo, quem alterou o resultado, quem cancelou a cobrança. O hash encadeado não substitui esse registro — ele qualifica o registro, transformando “confie no nosso log” em “verifique você mesmo”.

Na inspeção, a diferença é concreta. Um relatório de verificação que percorre a cadeia e devolve “10.482 entradas, nenhuma quebra” é uma resposta. Uma tela de log é apenas uma tela.

Custo real de implementação

Menos do que parece. É uma coluna a mais na tabela, uma função de hash da biblioteca padrão e a disciplina de gravar a auditoria na mesma transação do ato auditado — porque auditoria gravada depois, fora da transação, é auditoria que some quando o processo cai no meio.

Três armadilhas comuns:

  1. Gravar em outra transação. O ato acontece, o log não. A trilha fica com buracos que ninguém explica meses depois.
  2. Guardar PII no detalhe sem necessidade. A trilha é imutável por construção; se ela carrega CPF por hábito, o direito de exclusão do titular esbarra na imutabilidade. Guarde o identificador, não o dado pessoal.
  3. Não ter rotina de verificação. Cadeia que ninguém verifica é cadeia que quebrou há oito meses sem aviso. A verificação precisa rodar periodicamente e falhar alto.

O teste de mesa

Peça para alguém com acesso ao banco alterar um valor antigo — em ambiente de homologação, com dado de teste. Depois rode a verificação da cadeia.

Se ela apontar a entrada exata onde a corrente quebrou, você tem trilha de auditoria. Se não apontar nada, você tem um histórico bonito, e o único obstáculo a mudar o passado é a honestidade de quem tem a senha.

Leitura relacionada