Pistes d'audit : architecture de référence

Ce dernier article transforme les exigences précédentes en conception.

J’ai choisi de l’écrire sous forme d’architecture decision record, le format que j’utiliserais pour présenter ce sujet à un comité d’architecture. La raison est simple : le raisonnement compte autant que le schéma. Un ADR conserve les options écartées et les raisons de leur rejet, ce qui est précisément ce que le prochain architecte, ou le prochain auditeur, voudra comprendre.

Contexte

L’organisation doit pouvoir prouver, des années après les faits, qui a effectué une action métier ou accédé à des données sensibles, quand, et dans quel but, auprès d’auditeurs, de superviseurs, de tribunaux et de personnes concernées. Aujourd’hui, cette preuve est reconstituée à partir de logs applicatifs : auto-déclarés, tolérants à la perte, modifiables par les opérateurs et remplis de données personnelles.

Les contraintes découlent directement des deux premières parties :

• Conservation réglementaire. Plusieurs flux doivent être conservés pendant des années en vertu d’obligations légales.
• Valeur probante. Les enregistrements doivent tenir face à un tiers qui ne fait confiance ni aux systèmes ni aux horloges de l’organisation.
• Protection des données. La piste est elle-même un traitement de données personnelles, y compris au titre du droit d’accès aux données de consultation.
• Accès sensibles. Les enquêtes de fraude et de conformité nécessitent un accès exceptionnel aux données clients, qui doit être traçable et proportionné.
• Exploitabilité. L’émission d’audit ne doit jamais devenir le goulot d’étranglement, ni le point de défaillance unique, des transactions métier.

L’architecture en un coup d’œil

Critères de décision

1. D1, exhaustivité. Aucune modification métier ne peut exister sans son événement d’audit, et les trous doivent être détectables.
2. D2, intégrité vérifiable par un tiers. Une modification, une suppression ou un réordonnancement doit pouvoir être prouvé à quelqu’un d’extérieur à l’organisation.
3. D3, temps attesté. Le moment d’existence est attesté par une partie indépendante dont l’attestation a une valeur juridique.
4. D4, divulgation minimale. La piste prouve les événements sans stocker ni exposer plus de données personnelles que nécessaire, et permet l’effacement en fin de rétention.
5. D5, accès exceptionnel traçable. L’accès des enquêteurs est délimité, approuvé, limité dans le temps et lui-même audité.
6. D6, coût et exploitabilité. Faible latence sur le chemin métier, coût prévisible, et pas de dépendance forte à une fonctionnalité d’un seul éditeur.

Options envisagées

• O1, logs vers un SIEM avec rétention WORM. Les logs applicatifs sont envoyés à la plateforme de sécurité et archivés dans un stockage immuable.
• O2, tables d’audit en base de données. Des triggers copient chaque ligne modifiée dans des tables d’audit de la même base.
• O3, outbox transactionnelle, log de Merkle et ancrage par horodatage qualifié. Les événements d’audit sont validés avec la modification métier, chaînés dans un log de Merkle append-only sur un stockage WORM, et la racine du log est horodatée par un prestataire de services de confiance qualifié.
• O4, O3 ancré sur une blockchain publique. Le même pipeline, avec des racines publiées sur une chaîne publique plutôt qu’horodatées par un prestataire qualifié.
• O5, un service de registre électronique qualifié. Les événements, ou leurs hachages, sont enregistrés dans un registre électronique qualifié opéré par un prestataire de services de confiance.

D5 n’apparaît volontairement pas dans le tableau : il ne dépend pas de l’option de stockage. L’accès exceptionnel traçable est assuré par le plan d’accès, qui reste le même quelle que soit l’option choisie.

Décision

Nous adoptons O3. Les événements d’audit sont émis via une outbox transactionnelle, signés et chaînés par hachage à l’ingestion, ajoutés à un log de Merkle persisté sur un stockage WORM, et la racine du log est horodatée par un prestataire de services de confiance qualifié à une cadence fixe. Les données personnelles des événements sont pseudonymisées ou chiffrées avec des clés par personne. L’accès humain passe exclusivement par un broker d’accès d’urgence et une interface de requête masquée.

O5 reste candidat pour les flux les plus sensibles une fois que le marché des registres électroniques qualifiés aura mûri. L’outbox et le schéma d’événement sont conçus pour qu’un flux puisse être redirigé vers un tel registre sans modifier ses producteurs.

Trois chemins partagent un unique log. Sur le chemin d’écriture, les événements métier et les événements d’accès des enquêteurs atterrissent dans la même structure à altération détectable. Sur le chemin de scellement, seule la racine de Merkle quitte le périmètre de confiance, pour être horodatée par un prestataire qualifié. Sur le chemin de vérification, un auditeur vérifie les preuves d’inclusion au regard des racines horodatées, sans jamais avoir à faire confiance aux propres systèmes de l’organisation.

Composants

Le vérificateur mérite qu’on s’y arrête, parce que c’est le composant que les équipes oublient le plus souvent. Une preuve que seul votre propre outillage peut vérifier n’est pas encore tout à fait une preuve. Donner aux auditeurs un moyen indépendant de vérifier la piste, c’est ce qui transforme enfin « faites-nous confiance » en « vérifiez par vous-même ».

Conséquences

Ce qui s’améliore

• La preuve d’audit peut être vérifiée par un tiers : l’intégrité par des preuves de Merkle, le temps par une présomption légale, ni l’un ni l’autre par la confiance dans une configuration interne.
• L’exhaustivité est structurelle : une modification métier et son événement d’audit sont validés ensemble, ou pas du tout.
• La piste ne contient par défaut aucune donnée personnelle en clair, et la limitation de la conservation est appliquée en détruisant les clés sur toutes les copies, sauvegardes comprises.
• Les demandes d’accès portant sur les données de consultation peuvent recevoir une réponse à partir de la piste sans exposer par défaut l’identité du personnel.
• L’accès des enquêteurs devient la preuve d’un processus proportionné plutôt qu’un passif.

Ce que cela coûte

• Chaque service producteur doit adopter l’outbox et le schéma d’événement. L’adaptation des systèmes legacy est de loin le coût le plus important.
• Gérer des millions de clés par personne est une nouvelle discipline opérationnelle, et une perte de clé accidentelle est aussi irréversible qu’une destruction délibérée.
• L’horodatage qualifié ajoute un coût récurrent et une dépendance à des prestataires externes, atténuée en en utilisant deux.
• Les vues masquées par défaut ajoutent de la friction pour les enquêteurs, à traiter par un bon outillage et de la formation plutôt que par des exceptions.

Risques résiduels

• La véracité à la source. L’architecture prouve qu’un événement a été enregistré et n’a pas été modifié. Elle ne peut pas prouver qu’un producteur compromis a dit la vérité. L’identité des producteurs et l’intégrité du code restent des contrôles distincts.
• La fenêtre d’ancrage. Entre deux ancrages, l’historique détenu à l’intérieur du périmètre n’est pas encore scellé. La cadence borne cette fenêtre, et elle doit être documentée.
• Les initiés privilégiés. La séparation des tâches entre production, audit et administration des clés doit être appliquée sur le plan organisationnel, pas seulement technique.

Quand réexaminer

• Les services de registre électronique qualifié atteignent la maturité de production avec au moins deux prestataires : réévaluer O5 pour les flux les plus sensibles.
• Un superviseur ou un tribunal conteste la valeur probante des racines de Merkle horodatées.
• Le volume d’événements ou le coût d’ancrage modifie l’économie de la cadence choisie.
• Les obligations de conservation changent, par exemple avec de nouvelles règles anti-blanchiment.

Questions pour votre comité d’architecture

Quoi que vous finissiez par construire, voici les questions que j’aimerais qu’un comité d’architecture pose :

• Chaque événement d’audit est-il validé dans la même transaction que la modification qu’il décrit ?
• Pouvez-vous détecter un seul enregistrement supprimé, modifié ou réordonné, et le prouver à un tiers ?
• Le temps est-il attesté par un prestataire qualifié, avec un intervalle d’ancrage documenté ?
• Chaque acteur, humain ou service, est-il une identité fortement authentifiée ?
• Chaque lecture de données sensibles, et de la piste d’audit elle-même, produit-elle un événement d’audit avec sa finalité ?
• L’accès d’urgence est-il lié à un dossier, approuvé par quelqu’un d’autre, limité dans le temps et revu ?
• La piste contient-elle des références et des hachages à clé plutôt que des données personnelles en clair ?
• Les données personnelles peuvent-elles faire l’objet d’un crypto-shredding en fin de rétention sans casser la chaîne ?

Ce qui change

Nous sommes partis d’une seule ligne dans un log serveur affirmant que la Terre est plate, et d’une observation simple : écrire quelque chose ne prouve rien. Trois articles plus tard, nous avons une conception dans laquelle chaque enregistrement est complet, scellé, attesté par une partie indépendante, lisible uniquement pour une finalité déclarée, et effaçable quand la loi le prévoit.

Aucune des briques n’est nouvelle. Ce qui fait la différence, c’est de décider, dès le tout premier sprint, que la preuve est une exigence comme une autre. J’espère que cette série rend cette décision un peu plus facile à défendre. Si vous avez construit quelque chose de similaire, ou fait un autre choix, j’aimerais sincèrement savoir comment cela s’est passé.