La piste d'audit

01En une phrase #sec_311beda8

La piste d'audit enregistre ce qui s'est passé dans REVIEWIT — qui a fait quoi, quand, sur quoi, et avec quel résultat — sous une forme dont on peut démontrer qu'elle n'a pas été retouchée après coup.

02Une précision de vocabulaire #sec_fbdaf12f

Dans REVIEWIT, le mot audit désigne toujours la piste d'audit : la trace des actes accomplis dans le produit.

L'acquisition des données chez le client — l'inventaire des sites, des groupes, des accès — s'appelle la collecte . Les deux n'ont rien à voir, et les confondre conduit à chercher des preuves là où il n'y a que de l'inventaire.

03Le problème #sec_9df23eaa

Un outil de recertification produit des preuves sur le système d'information du client. Une question se pose alors immédiatement, et c'est la première que pose un auditeur sérieux :

Et l'outil lui-même, qu'est-ce qui prouve ce qu'il a fait ?

Sans réponse, tout le dispositif repose sur la confiance accordée à l'exploitant. Or les gestes qui comptent le plus sont précisément ceux qu'un exploitant mal intentionné aurait intérêt à effacer : avoir exclu une ressource du périmètre, avoir mis en place une délégation, avoir annulé une campagne, avoir modifié une règle juste avant une échéance.

Trois exigences en découlent, et elles sont plus dures qu'il n'y paraît :

Enregistrer les échecs autant que les succès. Une piste qui ne consigne que les actions abouties ne prouve que ce qui a fonctionné. Les tentatives refusées, les accès rejetés, les erreurs de sécurité sont souvent l'information la plus utile.

Résister à celui qui tient la base. Une trace protégée par un mécanisme que l'exploitant contrôle n'est pas une preuve contre l'exploitant.

Ne jamais surestimer sa propre garantie. Une piste qui annonce plus de protection qu'elle n'en apporte est pire qu'une piste modeste : elle produit une confiance injustifiée.

04Le parti pris #sec_19917edd

L'intégrité de la piste ne doit dépendre ni d'un moteur de base de données, ni d'un hébergeur.

C'est la décision structurante, et elle a été prise contre plusieurs solutions plus faciles.

Les fonctionnalités d'immuabilité offertes par les moteurs de base de données modernes, les tables temporelles et les services managés d'horodatage ont tous été écartés . Ils fonctionnent, mais ils déplacent la confiance vers un tiers — l'éditeur du moteur, le fournisseur de cloud — et ils enferment le produit : une piste d'audit qui ne survit pas à un changement d'hébergeur n'est pas un actif du client.

La garantie est donc entièrement applicative , portée par le produit lui-même, et vérifiable partout où il tourne. C'est cohérent avec le reste de la plateforme, qui se déploie dans la région choisie par le client.

Trois principes complètent ce choix :

1. Le socle ne se désactive pas. Il n'existe aucun réglage permettant de couper la piste d'audit — sinon on désactiverait l'audit depuis l'audit. Ce qui est configurable, c'est la finesse de certains événements de lecture, jamais l'enregistrement des actes.

2. Un acte inconnu s'écrit quand même. Le catalogue des actions vit en base et compte aujourd'hui près de deux cent quarante entrées. Mais si une version du produit émet un code que le catalogue ne connaît pas encore, l'événement est écrit malgré tout . Refuser d'enregistrer ce qu'on ne sait pas nommer serait la meilleure façon de créer un angle mort.

3. On annonce ce qui est réellement garanti. Le rapport de vérification indique le niveau de protection effectivement en place — jamais celui qui est prévu.

05Comment ça marche #sec_e77f0329

Deux chemins de capture

C'est le point d'architecture le plus important, et il découle directement de l'exigence « enregistrer les échecs ».

Le chemin transactionnel sert les actes aboutis. L'événement est déposé dans la même transaction que l'acte métier qu'il décrit. La conséquence est absolue : si l'acte échoue et que la transaction est annulée, aucune trace orpheline ne subsiste ; si l'acte réussit, sa trace existe nécessairement. Il ne peut pas y avoir de décalage entre ce que le produit a fait et ce que la piste raconte.

Le chemin autonome sert tout le reste : tentatives refusées, échecs d'authentification, accès rejetés, erreurs de sécurité. Ces événements n'ont, par nature, aucune transaction métier à laquelle s'accrocher — l'acte n'a pas eu lieu. Sans ce second chemin, la piste ne prouverait que les succès.

Le chaînage

Chaque événement reçoit un identifiant, une position de séquence attribuée à l'écriture, et une empreinte cryptographique qui inclut celle de l'événement précédent . La piste forme ainsi une chaîne : modifier un événement passé invalide tous les suivants.

Chaque chaîne s'ouvre par un événement de genèse placé en première position. Sans lui, on pourrait supprimer les premiers événements d'une chaîne et la présenter comme complète.

La forme exacte des données soumises à l'empreinte est normalisée et versionnée : deux systèmes qui vérifient la même piste obtiennent le même résultat, aujourd'hui comme dans cinq ans.

Le mécanisme a été éprouvé contre sept formes d'altération distinctes — modification de contenu, suppression, insertion, réordonnancement — toutes détectées.

Les trois niveaux de garantie

Le produit distingue explicitement ce qu'il garantit, et ne prétend jamais au niveau supérieur.

Le rapport de vérification est daté et annonce le niveau réel. Tant que le scellement n'est pas en place, il indique « chaînage seul » — et surtout pas N1. Cette discipline est délibérée : un rapport qui surestime sa garantie ne vaut rien devant un auditeur qui sait lire.

La clé de scellement est dédiée

La clé qui scelle la piste d'audit n'est jamais celle qui signe les documents produits par le client.

La raison est simple : celui qui peut signer un rapport ne doit pas pouvoir sceller la piste qui prouve comment ce rapport a été produit. Séparer les deux — et séparer la base d'audit du signataire — est la condition pour que le scellement veuille dire quelque chose.

06Ce qui est enregistré, et ce qui ne l'est pas #sec_548db5ca

Les actes. Tout ce qui modifie l'état du dispositif : campagnes créées, lancées, annulées ; décisions rendues ; exclusions posées et levées ; délégations mises en place et révoquées ; règles modifiées ; rôles attribués ; demandes de suppression émises et traitées ; configuration changée.

Les tentatives et les refus. Par le chemin autonome, comme expliqué plus haut.

Les lectures — de façon graduée. Tracer chaque affichage d'écran produirait un volume qui noierait l'information utile. Les consultations courantes sont donc échantillonnées , avec trois exceptions systématiquement enregistrées :

• les exports , car ils font sortir de la donnée du système ;
• les consultations de données personnelles nommées ;
• les consultations de preuve , car savoir qui a regardé le dossier avant une échéance a une valeur d'audit.

Les conversations avec RITA — par empreinte seulement. La piste enregistre qu'une question a été posée et ce qui en a résulté, jamais le texte de la question . Conserver le contenu des échanges reviendrait à constituer un historique de ce que les utilisateurs se demandent, ce qui n'est pas l'objet d'une piste d'audit.

Les données de démonstration — marquées comme telles. Les jeux de données synthétiques restent possibles, mais leur provenance est marquée, et ce marquage se propage à tout ce qui en dérive. Une démonstration ne doit jamais pouvoir être confondue avec de la production.

07Qui voit quoi #sec_1be12c7e

La visibilité est descendante : l'administrateur d'un workspace voit les événements de niveau souscription qui désignent son workspace — la création de son périmètre, l'attribution de ses fonctionnalités, la modification de son allocation.

C'est le complément nécessaire de la gouvernance déléguée : une entité à qui l'on confie l'autonomie doit pouvoir constater les décisions prises au-dessus d'elle qui la concernent. Elle ne voit en revanche rien des autres entités.

L' auditeur dispose d'un accès en lecture stricte à l'ensemble de la piste de son périmètre, et d'un moteur de recherche pour y naviguer.

08Un choix assumé : le démarrage à blanc #sec_c32441da

La nouvelle piste d'audit ne reprend pas l'historique de l'ancienne.

Ce n'est pas un renoncement technique. L'ancien journal n'offrait aucune garantie d'intégrité, sa couverture était partielle et son vocabulaire ambigu. Le reprendre reviendrait à faire entrer dans une chaîne scellée des données dont on ne peut rien affirmer — et donc à laisser croire qu'elles bénéficient d'une garantie qu'elles n'ont jamais eue.

Mieux vaut une piste courte et solide qu'une longue piste dont la première moitié ne prouve rien. Le même raisonnement s'applique au remplacement du dispositif d'authentification.

09Ce que l'auditeur peut en attendre #sec_7f268117

• Un rapport de vérification daté , qui affirme que la chaîne est intacte — ou désigne précisément où elle ne l'est pas.
• La certitude qu'aucune action aboutie n'est absente , par construction transactionnelle.
• La trace des refus , et pas seulement des succès.
• L'origine de chaque acte : l'auteur, la surface, le moment, l'objet, et l'état avant/après lorsque cela a du sens.
• Un export incrémental , pour verser la piste dans son propre outil d'analyse ou son SIEM.

10À retenir #sec_cc1ba3dd

Un produit de conformité qui ne peut pas rendre compte de ses propres actes demande qu'on le croie sur parole. La piste d'audit de REVIEWIT est construite pour qu'on n'ait pas à le faire.

Elle est indissociable du produit — non désactivable, alimentée dans la même transaction que les actes qu'elle décrit, y compris quand ces actes échouent. Elle est indépendante de l'infrastructure, donc portable et vérifiable partout. Et elle est honnête sur sa propre force : elle annonce le niveau de garantie qu'elle apporte réellement, jamais celui qu'elle vise.