Quand un auditeur examine vos journaux, il doit pouvoir faire confiance à ce qu'il voit : exactement ce qui s'est passé, aucun événement supprimé, aucun horodatage modifié, aucun enregistrement inséré après coup. Le chaînage de hachage cryptographique apporte cette garantie par les mathématiques, pas par une politique.

Qu'est-ce que le chaînage de hachage ?

Le chaînage de hachage est une technique où chaque enregistrement d'une séquence inclut un hachage cryptographique qui dépend de l'enregistrement précédent. Si un enregistrement de la chaîne est modifié, supprimé ou réordonné, les valeurs de hachage ne correspondent plus et l'altération est immédiatement détectable.

Le concept est simple mais puissant. Le hachage de chaque événement journalisé est calculé à partir de trois éléments : le hachage de l'événement précédent, le canonical_payload de l'événement en cours, et un horodatage précis à la milliseconde. Nous utilisons SHA-256, le même algorithme utilisé dans les certificats TLS, les signatures numériques et Bitcoin.

La formule de hachage

Chez AuditRails, le hachage de chaque événement journalisé est calculé comme suit :

hash = SHA-256(prev_hash + canonical_payload + timestamp_ms)

Où :

prev_hash est le hachage SHA-256 de l'événement immédiatement précédent dans la chaîne du même tenant
canonical_payload est une sérialisation JSON déterministe des champs essentiels de l'événement : log_id, tenant_id, action, actor_id, resource, et metadata
timestamp_ms est l'horodatage attribué par le serveur, en millisecondes depuis l'epoch Unix

Le canonical_payload exclut délibérément les champs ajoutés pendant le traitement (comme les données de géolocalisation IP, les champs d'enrichissement, et le hachage lui-même) afin de garantir que le hachage est calculé sur les données immuables fournies par l'application.

Chaînes par tenant et hachage genesis

Chaque tenant (organisation) maintient sa propre chaîne de hachage indépendante. C'est un choix de conception délibéré : l'isolation des tenants est un principe de sécurité fondamental, et mélanger des tenants dans une seule chaîne créerait des dépendances inter-tenants qui compliqueraient à la fois la sécurité et la scalabilité.

Chaque chaîne démarre avec un hachage genesis, une valeur de départ connue de 64 zéros :

genesis_hash = "0000000000000000000000000000000000000000000000000000000000000000"

Le premier événement de la chaîne d'un tenant utilise ce hachage genesis comme son prev_hash. À partir de là, chaque événement référence le hachage de l'événement qui le précède, créant une séquence ininterrompue.

Comment une altération rompt la chaîne

Prenons une chaîne de trois événements pour un tenant. Le hachage de chaque événement dépend du hachage de l'événement précédent :

Event #1:
  prev_hash:  0000000000000000...  (genesis)
  payload:    {"action": "user.login", "actor_id": "usr_abc", ...}
  timestamp:  1711929600000
  hash:       a1b2c3d4e5f6...

Event #2:
  prev_hash:  a1b2c3d4e5f6...     (hash of Event #1)
  payload:    {"action": "document.create", "actor_id": "usr_abc", ...}
  timestamp:  1711929601500
  hash:       f7e8d9c0b1a2...

Event #3:
  prev_hash:  f7e8d9c0b1a2...     (hash of Event #2)
  payload:    {"action": "document.share", "actor_id": "usr_abc", ...}
  timestamp:  1711929603000
  hash:       3344556677889900...

Supposons maintenant que quelqu'un modifie l'Événement n° 2, en changeant par exemple document.create en document.view pour masquer le fait qu'un document a été créé. Dès que le contenu de l'Événement n° 2 change, son hachage recalculé ne correspond plus à f7e8d9c0b1a2.... Et comme le hachage de l'Événement n° 3 a été calculé en utilisant le hachage d'origine de l'Événement n° 2 comme prev_hash, le hachage de l'Événement n° 3 devient lui aussi invalide. La corruption se propage à travers tous les événements suivants de la chaîne.

Même si un attaquant recalcule tous les hachages à partir de l'événement altéré, le nouveau hachage de tête de chaîne différera du hachage de tête de chaîne stocké, qu'AuditRails conserve dans un magasin séparé et protégé cryptographiquement. Il est impossible d'altérer un seul événement sans que cela soit détecté.

Stockage WORM : la seconde couche de protection

Le chaînage de hachage détecte l'altération. Le stockage WORM (Write Once, Read Many) l'empêche au niveau de l'infrastructure.

Chaque lot d'événements journalisés est écrit sur Amazon S3 avec Object Lock activé en mode compliance. Une fois écrites, les données ne peuvent être supprimées ni écrasées par personne, y compris les comptes root AWS, jusqu'à l'expiration de la période de rétention. Les périodes de rétention démarrent à 6 mois sur chaque offre et s'étendent automatiquement selon les frameworks de conformité auxquels vous êtes abonné, 7 ans pour SOX, jusqu'à 10 ans pour l'EU AI Act, l'exigence la plus longue parmi les 18, ou peuvent être prolongées davantage grâce à un module de rétention en self-service.

Cette approche à deux couches signifie que même si un attaquant obtenait un accès complet à la base de données, il ne pourrait pas modifier les copies du stockage froid, et toute modification du stockage chaud serait détectée par la vérification de la chaîne de hachage.

Comment cela se compare-t-il à la blockchain ?

Si le chaînage de hachage vous semble familier, c'est normal, c'est le même concept fondamental qui sous-tend la technologie blockchain. Chaque bloc d'une blockchain contient le hachage du bloc précédent, créant un registre immuable.

La différence essentielle est qu'AuditRails utilise une chaîne centralisée, par tenant plutôt qu'un mécanisme de consensus distribué. Nous n'avons besoin ni de preuve de travail, ni de minage, ni d'un réseau pair-à-pair. Le modèle de confiance est différent : au lieu de faire confiance à un réseau décentralisé, vous faites confiance à AuditRails en tant que dépositaire en ajout seul de votre piste d'audit, soutenu par une vérification cryptographique que vous pouvez exécuter de façon indépendante.

Cela vous donne les garanties d'inviolabilité de la technologie blockchain pour une fraction du coût et de la complexité, avec une latence d'écriture de l'ordre de la milliseconde au lieu des temps de confirmation de plusieurs secondes à plusieurs minutes typiques des registres distribués.

Le processus de vérification

AuditRails fournit un endpoint de vérification et une fonctionnalité du dashboard qui parcourt la chaîne de hachage et recalcule chaque hachage à partir de l'événement genesis. Le processus est simple :

Commencez avec le hachage genesis ( 0000...0000) comme valeur attendue du prev_hash
Pour chaque événement de la séquence, vérifiez que le prev_hash stocké correspond à la valeur attendue
Recalculez SHA-256(prev_hash + canonical_payload + timestamp_ms)
Vérifiez que le hachage recalculé correspond au hachage stocké
Utilisez le hachage stocké comme le prev_hash attendu pour l'événement suivant

Si une étape échoue, le rapport de vérification identifie l'événement exact où la chaîne se rompt ainsi que la nature de l'écart. Cela donne aux auditeurs une preuve concrète et mathématiquement vérifiable de l'intégrité des journaux.

Pourquoi cela compte pour les auditeurs

Les frameworks de conformité tels que SOC 2 (CC7.2), HIPAA (§164.312(b)) et ISO 27001 (A.12.4) exigent tous des organisations qu'elles maintiennent des pistes d'audit protégées contre toute modification non autorisée. Le chaînage de hachage apporte une preuve cryptographique que les journaux n'ont pas été altérés, pas seulement une déclaration de politique, mais une garantie mathématique.

Quand un auditeur demande « Comment garantissez-vous l'intégrité de vos journaux d'audit ? », la réponse n'est plus « Nous avons des contrôles d'accès sur la base de données. » C'est « Chaque événement journalisé est chaîné cryptographiquement avec SHA-256, stocké sur un stockage WORM, et vérifiable de façon indépendante. Voici le rapport de vérification. »

C'est la différence entre un contrôle qui pourrait fonctionner et un contrôle dont l'efficacité est démontrable.

Comment le chaînage de hachage cryptographique garantit des journaux inviolables