Um trilho de auditoria à prova de adulteração é aquele em que qualquer modificação a dados históricos é detetável. A técnica clássica — emprestada da blockchain mas muito mais simples — é a cadeia de hash: cada registo contém o hash criptográfico do anterior. Mexes em qualquer registo histórico e todos os hashes seguintes mudam.
A receita
Para cada fatura, calcula:
hash_n = SHA256(prev_hash || canonicalize(payload_n))
// onde canonicalize() produz uma sequência de bytes determinística
// (chaves ordenadas, sem whitespace, formato de números estável).Guarda o hash na própria fatura. Para provar a integridade de uma fatura, basta verificar que o seu hash é igual ao hash recalculado a partir do hash da fatura anterior e do payload canonicalizado. A ZATCA Fase 2 exige exatamente este esquema.
Porque a canonicalização é tudo
Duas serializações JSON byte-diferentes do mesmo objeto lógico produzem hashes diferentes. RFC 8785 (JCS — JSON Canonicalization Scheme) é a abordagem padrão: chaves ordenadas lexicograficamente, sem whitespace insignificante, números na forma única mais curta, strings escapadas segundo o RFC 8259.
Cadeias por tenant, não globais
Mantém uma cadeia separada por tenant em vez de uma global. Duas razões: (1) podes shardar storage e compute por tenant sem coordenar escritas, e (2) uma corrupção na cadeia de um tenant não envenena o audit trail de toda a gente.
Verificar a posteriori
Um auditor (ou tu, defensivamente) pode rejogar a cadeia desde o génesis: hash do payload da primeira fatura sem prev_hash, verifica que bate certo com o hash guardado, e itera. Qualquer desvio localiza o registo adulterado. O subtle.digest do Web Crypto dá-te SHA-256 em qualquer runtime moderno — Node, Deno ou browser.
A Invocie escreve um hash encadeado em cada fatura e em cada entrada de ComplianceLog. As duas cadeias são independentes: faturas para prova ao estilo ZATCA, logs para auditoria operacional.