Ce qu'« inviolable » veut vraiment dire pour un journal d'audit
Tous les éditeurs de rapprochement disent avoir un journal d'audit. Peu peuvent prouver qu'il n'a pas été modifié. Voici ce qu'exige réellement l'inviolabilité — stockage en ajout seul, chaînage de hachage et une étape de vérification — et quoi demander à un éditeur.
« Nous avons un journal d'audit complet » fait partie de ces affirmations qui sonnent comme un contrôle sans en être un. Un journal d'audit que l'on peut discrètement modifier — ou qu'un administrateur avec accès à la base peut réécrire — ne prouve rien. Pour le rapprochement, où le journal est la trace de qui a décidé qu'un paiement correspondait, la distinction compte pour votre régulateur.
L'ajout seul est le plancher, pas le plafond
Première exigence : les enregistrements d'audit peuvent être insérés, jamais modifiés ni supprimés. Le meilleur endroit pour l'imposer est la base de données elle-même — des triggers qui bloquent UPDATE et DELETE sur la table d'audit — pour qu'un bug applicatif ou une session SQL directe ne puisse pas réécrire l'historique en silence. Le « nous n'exposons pas de bouton modifier » côté application n'est pas la même chose.
Le chaînage de hachage rend la falsification détectable
L'ajout seul arrête la modification évidente. Le chaînage de hachage attrape la modification déterminée. Chaque enregistrement (ou lot) est scellé par un haché cryptographique — typiquement SHA-256 — qui incorpore le haché du précédent. Les enregistrements forment une chaîne : changez une entrée, et plus aucun haché suivant ne correspond.
- Un attaquant ne peut pas altérer un enregistrement sans recalculer toute la chaîne qui le suit.
- Vous pouvez ancrer la chaîne périodiquement, pour que même une réécriture complète de la table soit détectable.
- Cela vaut quels que soient les accès à la base — le contrôle, c'est le calcul, pas les permissions.
Hacher ne sert à rien si personne ne vérifie jamais. L'inviolabilité exige une étape de vérification — un endpoint ou un job qui reparcourt la chaîne et confirme son intégrité. Demandez à l'éditeur de la démontrer en train d'attraper une ligne modifiée par accès direct à la base.
Quoi demander à un éditeur
- La table d'audit est-elle protégée contre UPDATE/DELETE au niveau de la base, ou seulement dans l'application ?
- Les enregistrements sont-ils chaînés par hachage ? Avec quel algorithme, et à quelle granularité ?
- Existe-t-il un endpoint de vérification, et pouvez-vous le montrer en train de détecter une ligne falsifiée ?
- Chaque action sensible est-elle journalisée — connexions, dépôts, décisions de rapprochement, litiges, exports — avec horodatage UTC et acteur ?
Le journal d'audit de Kilter est en ajout seul au niveau de la base, chaîné par hachage sous des ancres SHA-256, et livré avec un endpoint de vérification qui détecte les modifications faites même par accès direct à la base. La posture complète est sur la page sécurité.