Un registro de auditoría a prueba de manipulación es uno en el que cualquier modificación de datos históricos es detectable. La técnica clásica — tomada de blockchain pero mucho más simple — es la cadena de hash: cada registro contiene el hash criptográfico del anterior. Toca cualquier registro histórico y todos los hashes posteriores cambian.
La receta
Para cada factura, calcula:
hash_n = SHA256(prev_hash || canonicalize(payload_n))
// donde canonicalize() produce una secuencia de bytes determinista
// (claves ordenadas, sin espacios en blanco, formato de números estable).Guarda el hash en la factura misma. Para probar la integridad de cualquier factura individual solo necesitas verificar que su hash es igual al hash recalculado a partir del hash de la factura anterior y el payload canonicalizado. ZATCA Fase 2 exige exactamente este esquema.
Por qué la canonicalización lo es todo
Dos serializaciones JSON byte-distintas del mismo objeto lógico producen hashes diferentes. RFC 8785 (JCS — JSON Canonicalization Scheme) es el enfoque estándar: claves ordenadas lexicográficamente, sin espacios irrelevantes, números en su forma única más corta, strings escapados según RFC 8259.
Cadenas por tenant, no globales
Lleva una cadena separada por tenant en lugar de una global. Dos razones: (1) puedes shardar storage y cómputo por tenant sin coordinar escrituras, y (2) una corrupción en la cadena de un tenant no envenena el audit trail de todos.
Verificar a posteriori
Un auditor (o tú, defensivamente) puede reproducir la cadena desde el origen: hashea el payload de la primera factura sin prev_hash, comprueba que coincide con el hash almacenado, e itera. Cualquier desviación localiza el registro manipulado. El subtle.digest de Web Crypto te da SHA-256 en cualquier runtime moderno — Node, Deno o el navegador.
Invocie escribe un hash encadenado en cada factura y en cada entrada de ComplianceLog. Las dos cadenas son independientes: facturas para prueba estilo ZATCA, logs para auditoría operativa.