Rastreabilidade de ponta a ponta

O COADF P-4 é publicado na íntegra. Um identificador é criado quando um documento dá entrada e viaja com cada etapa de processamento, cada avaliação de confiança, cada decisão humana e a saída publicada. A trilha é somente de inserção, uma consulta reconstrói a cadeia, e a cadeia se exporta em JSON para quem não construiu o sistema. O esquema publicado da trilha de auditoria nomeia os campos: trace_id, timestamp, event_type, actor, input, output, decision, source_hash e immutable.

Duas propriedades a sustentam. Continuidade: cada etapa carrega a mesma identidade, em cada fronteira que atravessa. Persistência: o registro de cada etapa sobrevive, e ninguém consegue editá-lo depois para que a resposta pareça melhor.

A pergunta a que o P-4 responde chega tarde e de fora. Meses depois da publicação, alguém pergunta de onde veio um valor, o que o leu e quem olhou para ele. A resposta precisa poder ser reconstruída por uma pessoa que não construiu o sistema, a partir de registros que ninguém poderia ter reescrito nesse meio-tempo.

Um trace distribuído não é uma trilha de auditoria de negócio

Esta é a distinção que a maioria das implementações borra, porque as ferramentas se parecem: as duas têm um identificador, as duas atravessam serviços, as duas mostram etapas em sequência. Elas respondem a perguntas diferentes e fazem promessas diferentes.

A especificação W3C Trace Context define o cabeçalho traceparent, e os SDKs do OpenTelemetry propagam tracecontext e baggage por padrão. Essa identidade é por execução. No OpenTelemetry, um trace que não é amostrado não é exportado, e o filter processor do Collector descarta a telemetria que corresponde a uma condição. Os dois são comportamento correto para diagnóstico e desqualificante para evidência.

Os dois se correlacionam: o trace_id de auditoria é gravado em cada span como atributo, e o identificador do trace distribuído, nos logs. Nenhum dos dois deve virar o outro. Uma única transação de negócio costuma abranger vários traces distribuídos: uma requisição de entrada, um job de processamento assíncrono, uma decisão tomada dias depois, a saída.

A correlação copia o identificador de auditoria para a telemetria, e a telemetria atravessa outras fronteiras: exportadores, fornecedores, regras de acesso e retenção normalmente mais frouxas que as do armazenamento de auditoria. O identificador deve ser classificado antes de sair: uma referência opaca, nunca dado pessoal nem segredo. Onde o identificador de auditoria carrega significado próprio, a correlação passa por uma referência separada e não sensível.

Gerar uma vez, na entrada

O identificador é criado onde a transação entra e em nenhum outro lugar. Todo componente posterior o exige e nenhum gera um. Um identificador ausente é um erro, nunca um motivo para criar um novo, e um valor padrão num modelo de mensagem é a forma mais comum de quebrar essa regra sem que ninguém perceba.

Carregá-lo explicitamente em cada fronteira

• No processo: um argumento de função ou o contexto da requisição.
• Entre serviços: um campo no contrato da requisição ou da mensagem, onde um esquema pode exigi-lo.
• Em trabalho agendado: um argumento do job.
• Em repouso: uma coluna em cada linha armazenada.

Bibliotecas de propagação carregam o contexto de execução por conta própria. A identidade de auditoria faz parte do contrato da aplicação e pertence ao payload.

Persistir somente por inserção

Várias realizações são válidas, e elas se combinam:

• Persistência somente de inserção. O repositório oferece inserir e ler, e nada mais.
• Privilégios do banco de dados. O papel da aplicação tem INSERT e SELECT na trilha, e nenhum UPDATE, DELETE ou TRUNCATE.
• Triggers que recusam reescritas, como defesa em profundidade para sessões que detêm direitos mais amplos, com um trigger em nível de instrução para TRUNCATE, porque no PostgreSQL TRUNCATE não dispara triggers ON DELETE.
• Um modelo de eventos imutável, no qual uma correção é um novo evento que substitui um anterior.
• Uma convenção de substituição. O valor atual de um atributo é a entrada mais recente para ele; o histórico são todas elas.

Event sourcing é uma forma de obter um histórico somente de inserção, e não a única; ver a nota técnica.

Gravar a entrada junto com a mudança

A entrada de auditoria é gravada na mesma transação de banco de dados que a mudança de estado que ela descreve, ou por meio de um outbox transacional, para que nenhuma das duas possa existir sem a outra.

Tornar as novas tentativas idempotentes

O horário da etapa é marcado quando a etapa roda, e a mesma entrada é reenviada numa nova tentativa. As entradas recebem uma chave única natural, para que uma escrita repetida seja absorvida em vez de duplicada. No PostgreSQL, ON CONFLICT DO NOTHING pula uma linha que conflita com uma restrição ou um índice único em vez de lançar um erro, e é exatamente por isso que não pode ser a resposta inteira: um conflito nem sempre é uma nova tentativa. A mesma chave com conteúdo diferente é um segundo escritor ou um bug. A entrada armazenada deve ser comparada antes de a escrita ser tratada como nova tentativa, e a falha deve ser ruidosa quando elas diferem.

Reconstruir com uma consulta, exportar em JSON

Se a reconstrução precisa de alguém que conheça o sistema, o P-4 não vale. Ordena-se por carimbo de tempo, e declara-se o que essa ordem não resolve: entradas com o mesmo carimbo de tempo não são ordenadas por nenhum dos campos publicados.

O que um trigger não oferece

Privilégios e triggers são controles dentro da própria fronteira de confiança do banco de dados. No PostgreSQL, um superusuário ignora todas as verificações de permissão, e o dono da tabela pode desativar seus triggers. Uma tabela somente de inserção é, portanto, um controle forte contra a aplicação e fraco contra seus administradores. A detectabilidade de adulteração diante de insiders privilegiados exige um controle fora do banco de dados, e é uma propriedade separada da persistência somente de inserção. Nenhuma das duas é, por si só, uma afirmação jurídica sobre evidência.

• Event sourcing. O event store é o histórico, e o estado é derivado dele. Propriedades de auditoria fortes, e um grande compromisso de arquitetura.
• Change data capture. Mudanças de linha lidas do log do banco de dados. Útil para replicação; registra o que mudou, não quem decidiu nem por quê, então não substitui as entradas de auditoria de negócio.
• Armazenamento de objetos de gravação única para cadeias exportadas, onde a retenção precisa sobreviver ao banco de dados.
• Armazenamentos de ledger ou com detectabilidade de adulteração, onde a adulteração por insiders faz parte do modelo de ameaças.

• O padrão não decide quais etapas são relevantes para uma regulamentação específica ou um produto específico.
• Persistência somente de inserção não é detectabilidade de adulteração, e nenhuma das duas é uma conclusão jurídica sobre evidência.
• Ele não define prazos de retenção.
• Ele depende de que todo componente honre o contrato. Um componente que não o honra é encontrado pelo teste de reconstrução, não impedido por ele.