Pistes d'audit : les logs ne suffisent pas

Écrire « la Terre est plate » dans un log serveur ne prouve rien.

Cela prouve seulement qu’un processus, à un moment donné, a écrit cette chaîne dans un fichier. Il en va de même pour chaque ligne qu’émettent nos systèmes. Un log est une déclaration qu’un système fait sur lui-même, stockée là où ses propres opérateurs peuvent la modifier, horodatée par une horloge qu’ils contrôlent.

Pour le débogage, c’est parfaitement acceptable. C’est exactement à cela que servent les logs. Mais placez la même ligne devant un auditeur, un superviseur, un juge ou un enquêteur fraude, et elle ne vaut presque rien. Ils ne demandent pas ce que le système a dit. Ils demandent si vous pouvez prouver ce qui s’est passé, quand et par qui, et que personne n’a touché à l’enregistrement depuis.

Les logs répondent à la première question. Les pistes d’audit existent pour répondre à la seconde. Confondre les deux est l’une des erreurs les plus courantes, et les plus coûteuses, que je rencontre dans l’ingénierie en environnement régulé. Dans ce premier article, j’aimerais détailler ce qu’il faut réellement pour transformer un enregistrement en preuve.

Deux artefacts, deux questions

Logs et pistes d’audit se ressemblent. Ce sont tous deux des lignes horodatées de données structurées, il est donc tentant de croire qu’un seul pipeline peut servir les deux. C’est impossible, parce qu’ils sont construits pour des lecteurs différents, avec des hypothèses différentes sur les défaillances.

La ligne que je vous demanderais de regarder deux fois est la tolérance à la perte. Un pipeline de logs qui perd des événements quand son collecteur est saturé se comporte conformément à sa conception. Un événement d’audit qui peut être perdu pour la même raison n’est tout simplement pas un événement d’audit.

Cela mène au premier principe de conception de la série : les enregistrements d’audit sont émis explicitement, dans le cadre de la transaction métier, jamais extraits des logs après coup. Soit la modification et son enregistrement d’audit existent tous les deux, soit aucun des deux. La partie 3 montre comment l’implémenter sans ralentir le chemin métier.

Ce qui transforme un enregistrement en preuve

Un enregistrement devient une preuve quand un tiers sceptique peut vérifier quatre propriétés sans avoir à faire confiance à l’organisation qui l’a produit.

1. Intégrité. L’enregistrement n’a pas été modifié depuis son écriture, et toute modification serait détectable.
2. Temps. Le moment où l’enregistrement a existé est établi par quelqu’un d’autre que la partie auditée.
3. Attribution. L’acteur est une identité fortement authentifiée, pas un champ user en texte libre. Idéalement, le service émetteur signe l’événement avec sa propre identité de workload.
4. Exhaustivité. Aucun enregistrement ne manque. Vous pouvez démontrer l’absence de trous, pas seulement la présence d’entrées.

Notre ligne sur la Terre plate échoue sur les quatre. N’importe qui ayant un accès shell aurait pu l’écrire, la modifier ou supprimer discrètement ses voisines. Son horodatage vient d’une horloge que l’opérateur contrôle. Son auteur est ce que le processus a bien voulu prétendre être.

La suite de cet article traite ces lacunes une par une.

Le WORM est nécessaire, mais pas suffisant

La réponse réflexe à l’intégrité est le stockage WORM : write once, read many. Object Lock en mode compliance, conteneurs blob immuables, supports optiques. Une fois écrit, un enregistrement ne peut être ni modifié ni supprimé avant l’expiration de sa période de rétention, pas même par l’utilisateur root du compte.

Le WORM a de la valeur, et je ne construirais pas de piste d’audit sans lui. Il élimine l’attaque la moins chère de toutes, un administrateur qui modifie discrètement un fichier. Mais il faut être clair sur ce qu’il ne garantit pas :

• La vérité au moment de l’écriture. Le WORM préserve un mensonge aussi fidèlement qu’il préserve un fait. Verrouillez la ligne sur la Terre plate et vous possédez désormais une ligne immuable sur la Terre plate.
• L’exhaustivité. Un initié n’a pas besoin de supprimer un enregistrement s’il peut empêcher son écriture, ou le modifier dans la fenêtre qui précède son verrouillage.
• L’ordre. Les objets immuables ne portent aucune preuve intrinsèque de séquence.
• La vérifiabilité par un tiers. Pour accepter la garantie, un auditeur doit faire confiance à la configuration de votre bucket, à votre compte cloud et à votre fournisseur. La preuve vit à l’intérieur de votre propre périmètre de confiance.

Les régulateurs sont arrivés à la même conclusion. En 2022, la SEC américaine a amendé la Rule 17a-4 pour offrir aux broker-dealers une alternative au WORM fondée sur une piste d’audit : un système capable de recréer n’importe quel enregistrement original après modification ou suppression, avec un historique complet et horodaté de qui a changé quoi. L’accent est passé du support de stockage à l’historique vérifiable.

Mieux vaut détecter l’altération que prétendre l’empêcher

Aucune conception n’empêchera un initié suffisamment privilégié d’essayer. Ce que nous pouvons obtenir, c’est que personne ne modifie l’historique sans que cela soit détecté. C’est une propriété cryptographique, pas une propriété de stockage.

La première brique est une chaîne de hachage, dans laquelle chaque enregistrement s’engage sur son prédécesseur :

h(n) = SHA-256( h(n-1) || canonical(event(n)) )

Ici, canonical est une sérialisation déterministe comme le JSON Canonicalization Scheme (RFC 8785). Modifiez, supprimez ou réordonnez un seul événement, et tous les hachages suivants cassent. Un numéro de séquence monotone par flux rend également les trous visibles.

Une chaîne de hachage seule a une faiblesse : quiconque détient la chaîne entière peut la recalculer de bout en bout. Deux étapes supplémentaires ferment cette porte.

1. Un arbre de Merkle, comme dans Certificate Transparency (RFC 9162). Les événements deviennent les feuilles d’un log de Merkle append-only. Le log peut alors produire une preuve d’inclusion (cet événement est dans le log) et une preuve de cohérence (le log d’aujourd’hui prolonge celui d’hier sans le réécrire), chacune de taille logarithmique.
2. L’ancrage externe. La racine signée du log est régulièrement remise à une partie extérieure à votre périmètre de confiance. Une fois qu’une racine est sortie de vos mains, réécrire l’historique implique de produire une racine différente de celle qu’un tiers détient déjà.

Le WORM trouve alors sa juste place : la couche de stockage durable sous une structure à altération détectable, plutôt que la structure elle-même.

Un temps que l’on peut prouver : les horodatages qualifiés

Même le log de Merkle le mieux conçu a un point faible : ses horodatages viennent de vos propres horloges. NTP peut être usurpé, les horloges peuvent être reculées, et un log peut être reconstruit hors ligne et présenté plus tard. Il nous faut un témoin du temps que nous ne contrôlons pas.

En Europe, ce témoin a un statut juridique. Selon le règlement eIDAS, tel que modifié par eIDAS 2 (règlement (UE) 2024/1183), un horodatage électronique qualifié émis par un prestataire de services de confiance qualifié bénéficie d’une présomption légale d’exactitude et d’intégrité. La charge de la preuve passe à celui qui le conteste, et l’effet est reconnu dans toute l’UE.

La mécanique est d’une simplicité rafraîchissante. Vous envoyez un hachage à l’endpoint RFC 3161 du prestataire et recevez en retour un jeton d’horodatage signé. Le prestataire ne voit jamais vos données, seulement leur empreinte.

Horodater la racine, pas chaque événement

Horodater chaque événement d’audit individuellement est coûteux, ajoute de la latence au chemin métier et n’apporte rien de plus. La conception efficace ancre plutôt la racine de Merkle à une cadence fixe.

• L’existence de chaque événement est alors prouvée par deux artefacts combinés : sa preuve d’inclusion, et l’horodatage qualifié de la racine qui le couvre.
• L’intervalle d’ancrage devient un paramètre explicite et auditable : la fenêtre maximale pendant laquelle l’historique pourrait être réécrit avant d’être scellé.
• Le coût est d’un appel RFC 3161 par intervalle, quel que soit le volume d’événements.

Être précis sur ce que cela prouve

Un horodatage montre que des données existaient au plus tard au moment T, exactement sous cette forme. Il ne prouve pas que l’événement métier a eu lieu à T, ni que l’événement était véridique. Combiné à l’émission transactionnelle et à une chaîne de hachage, il ferme cependant la fenêtre dans laquelle un historique fabriqué ou modifié pourrait être glissé.

Ce qui change

Un log enregistre ce qu’un système prétend. Une piste d’audit prouve ce qui s’est passé, à quelqu’un qui n’a aucune raison de vous croire sur parole.

C’est un ensemble de propriétés que l’on conçoit délibérément : exhaustivité transactionnelle, altération détectable, temps attesté de façon indépendante, acteurs fortement identifiés et accès audités. Rien de tout cela n’est nouveau ni exotique. Chaînes de hachage, logs de Merkle, RFC 3161 et accès juste-à-temps sont des briques matures et bien comprises. Ce qui manque souvent, c’est la décision de traiter la preuve comme une exigence d’ingénierie dès le premier jour, plutôt que comme quelque chose à reconstituer à partir des logs le jour où quelqu’un la demande.

Il y a toutefois un piège, et je ne voulais pas le cacher. Tout dans cet article pousse dans une seule direction : enregistrer davantage, conserver plus longtemps, rendre impossible l’effacement. Suivi naïvement, ce conseil produit le plus gros et le moins supprimable des stocks de données personnelles de l’entreprise. La partie 2, « Audit trails: Not a data lake », explique comment tout prouver sans exposer plus que ce que la preuve exige.