Mettre à niveau le format d'audit sans perdre les anciennes preuves

Une mise à niveau du format d'audit n'est sûre que si un enquêteur peut vérifier les preuves exportées hier avec les règles qui s'appliquaient hier. Un nouvel analyseur qui affiche un écran plausible, une migration de base de données réussie et un déploiement au vert ne le prouvent pas. Ils dissimulent souvent la rupture qui compte vraiment : les octets d'un enregistrement restent intacts, mais sa signification, les données hachées ou le comportement du vérificateur ont changé.

Considérez le format d'audit comme un protocole dont la durée de vie est longue. Votre application peut changer chaque semaine. Les preuves, elles, ne le peuvent pas. Dès qu'une personne s'appuie sur un enregistrement pour expliquer qui a approuvé une action, quel identifiant a été utilisé ou ce qu'un agent a envoyé à un service externe, cet enregistrement doit garder une interprétation stable longtemps après la disparition du code qui l'a écrit.

Préserver les octets avant de préserver la commodité

L'artefact faisant autorité est la séquence d'octets originale de l'enregistrement, accompagnée du contexte nécessaire à sa vérification. Une ligne analysée dans une base de données actuelle est une copie de travail. Un objet JSON affiché dans un tableau de bord est une vue. Aucun des deux ne remplace les octets de preuve qui ont participé à une signature, à une chaîne de hachage ou à une enveloppe authentifiée.

Cette distinction peut sembler tatillonne jusqu'au jour où une mise à niveau réécrit un champ. Supposons que la version 1 stocke une cible SSH sous la forme d'une chaîne fournie par l'utilisateur :

{"schema_version":1,"event":"ssh.execute","target":"[email protected]:22","command":"uptime"}

La version 2 veut séparer les champs pour pouvoir filtrer par hôte et par port :

{"schema_version":2,"event":"ssh.execute","user":"build","host":"prod.example","port":22,"command":"uptime"}

Ces deux enregistrements peuvent décrire la même action, mais ils ne constituent pas des preuves interchangeables. Un encodeur v2 peut normaliser un nom d'hôte, ajouter un port par défaut ou rejeter une cible acceptée par v1. Si vous remplacez le premier enregistrement par le second, vous formulez une nouvelle affirmation sur l'ancien événement. Cette affirmation peut être correcte, mais les données réécrites ne suffisent pas à le prouver.

Séparez trois éléments :

• Preuves originales : octets immuables, exactement tels qu'ils ont été acceptés dans la séquence d'audit.
• Représentation dérivée : forme indexée, décodée ou migrée utilisée pour la recherche et l'affichage.
• Notes d'interprétation : règles documentées qui expliquent les champs, les valeurs par défaut et le comportement propre à chaque version.

Une représentation dérivée peut être reconstruite. Les preuves originales, non. Stockez les originaux dans un paquet de preuves en ajout uniquement ou dans un stockage d'objets, adressez-les par leur condensat et faites pointer chaque élément dérivé vers ce condensat. Si les règles de conservation imposent une suppression, enregistrez cette suppression comme un événement distinct. Ne compactez pas discrètement l'historique en appelant cela une mise à niveau.

Cela vaut également lorsque le journal utilise des enregistrements chiffrés. Le chiffrement protège le contenu contre les lecteurs non autorisés, mais il ne rend pas inoffensive une migration avec perte. Le vérificateur doit toujours pouvoir identifier le texte chiffré, l'en-tête et la règle de chaîne qui ont produit le résultat.

Donner une version explicite à chaque enregistrement

Placez un schema_version explicite dans chaque enregistrement avant de le hacher ou de le signer. Ne déduisez pas la version d'une extension de fichier, d'un numéro de migration de base de données, d'une version de l'application ou de la présence d'un champ ajouté récemment.

La déduction fonctionne jusqu'à la première exportation à des fins d'enquête. Un enquêteur reçoit un dossier d'enregistrements copié depuis une sauvegarde, un ticket d'assistance ou une machine qui n'exécute plus l'application actuelle. Le contexte environnant est incomplet, tandis que l'enregistrement est toujours là. Un enregistrement qui porte sa propre version indique au vérificateur le décodeur et les règles à utiliser.

Utilisez un petit entier pour un format dont vous contrôlez les règles. Réservez la version 0 comme valeur invalide afin qu'un champ manquant ne devienne pas silencieusement un ancien format. La version doit avoir une fonction précise : sélectionner la grammaire de l'enregistrement et la méthode de vérification. N'en faites pas un identifiant général de version produit.

Une enveloppe durable peut ressembler à ceci :

{
  "schema_version": 3,
  "record_id": "01J8X7K5W3H0Q9M6P2R4A1C8ZD",
  "recorded_at": "2026-07-22T14:08:31.482Z",
  "kind": "http.request.completed",
  "previous_digest": "sha256:4a4d...",
  "payload": {
    "method": "POST",
    "authority": "api.example.test",
    "status": 201
  }
}

La version fait partie de l'entrée authentifiée. Si un enregistrement indique la version 3 alors que le condensat a été calculé sans ce champ, un attaquant capable de modifier les octets stockés pourrait orienter le vérificateur vers une autre interprétation. Incluez dans les octets protégés chaque champ qui détermine un analyseur, un algorithme de hachage, une règle de canonicalisation ou un algorithme de signature.

Séparez également la version du schéma de l'enregistrement de la version sémantique de l'événement. La première répond à la question : « Comment analyser et vérifier ces octets ? » La seconde répond à la question : « Que signifiait cet événement au moment de son émission ? »

Par exemple, remplacer actor, nom d'affichage libre, par une identité stable de processus peut conserver la même structure JSON tout en modifiant l'affirmation. Il ne s'agit pas simplement de la version 4 du schéma. C'est un changement sémantique, et la spécification des preuves doit indiquer à partir de quel moment le nouveau sens s'applique. Le même avertissement vaut lorsqu'un champ change d'unité, qu'un horodatage passe de l'heure locale à UTC ou qu'un statut passe d'une réponse observée à une décision de politique.

Figer la méthode de vérification, pas seulement les champs

Un schéma versionné est incomplet si le vérificateur ne peut pas reconstituer exactement les octets utilisés pour authentifier un enregistrement. La disposition des champs n'est qu'une partie de cette méthode.

Pour chaque version, documentez :

• la grammaire acceptée et les champs obligatoires ;
• l'encodage texte ou binaire et les règles de canonicalisation ;
• les algorithmes de condensat et de signature ;
• le séparateur de domaine, si vous en utilisez un ;
• la règle de liaison de la chaîne et la règle de genèse ;
• le comportement en cas d'entrée mal formée ou inconnue.

RFC 8785 explique pourquoi le JSON a besoin d'une représentation déterministe avant les opérations cryptographiques : le JSON ordinaire autorise plusieurs sérialisations d'une même valeur logique, alors que le hachage et la signature exigent des octets invariants. Son JSON Canonicalization Scheme contraint l'entrée et trie les propriétés des objets de manière déterministe. Il rappelle aussi, au moyen des restrictions de son format, que les noms de propriétés en double et les nombres en dehors de la représentation prise en charge ne sont pas des détails sans importance.

Cette norme n'est utile que si vous nommez précisément le profil utilisé. Dire « nous hachons du JSON » n'est pas une méthode. Dire « nous appelons le sérialiseur de l'environnement d'exécution actuel » est encore pire, car une mise à niveau de cet environnement peut modifier l'échappement, le format numérique ou l'ordre sans changement d'audit décidé consciemment.

Le même problème existe avec les formats binaires. RFC 8949 définit les exigences d'encodage déterministe du CBOR et précise qu'une convention de tri antérieure doit être désignée explicitement comme mode de compatibilité. Un vérificateur ne peut pas supposer que tous les producteurs historiques donnaient le même sens au mot « canonique ».

Ne construisez pas un nouveau vérificateur qui analyse n'importe quel JSON, le sérialise avec la bibliothèque du jour, puis hache le résultat. Ce modèle casse les anciennes preuves de deux façons. Il peut rejeter des enregistrements valides selon l'ancienne méthode, et accepter un enregistrement selon une nouvelle méthode qui n'a jamais produit le condensat original.

Au contraire, gardez la sélection de version près de la limite des octets :

read envelope bytes
  -\u003e identify protected schema_version
  -\u003e select verifier V1, V2, or V3
  -\u003e validate that version's grammar
  -\u003e reproduce that version's authenticated bytes
  -\u003e verify digest, signature, and chain link
  -\u003e decode a display model only after verification

Le modèle d'affichage vient volontairement en dernier. Un rendu peut être agréable. Un vérificateur n'a pas le droit d'imaginer.

Les versions inconnues doivent échouer par défaut

Face à une version qu'il ne prend pas en charge, un vérificateur doit renvoyer explicitement le résultat unsupported_version. Il ne doit pas traiter les champs inconnus comme négligeables, supposer la disposition la plus récente ou lancer un décodeur générique de secours.

Les ingénieurs s'y opposent souvent parce qu'ils recherchent la compatibilité ascendante. Celle-ci convient à une application qui lit des champs de présentation facultatifs. Elle est dangereuse pour la vérification de preuves, car un champ apparemment facultatif pourrait contrôler plus tard l'interprétation authentifiée.

Utilisez une structure de résultat qui distingue l'échec des preuves des limites de l'outil :

{
  "record_id": "01J8X7K5W3H0Q9M6P2R4A1C8ZD",
  "schema_version": 4,
  "status": "unsupported_version",
  "verified": false,
  "supported_versions": [1, 2, 3],
  "reason": "Verifier 2.7.0 has no verification recipe for schema version 4"
}

Ce résultat dit quelque chose de précis : l'outil n'a pas établi l'authenticité. Il n'accuse pas l'enregistrement d'avoir été falsifié et ne prétend pas non plus qu'il est valide. Gardez invalid, incomplete, unsupported_version et verified distincts, dans la sortie de commande comme dans les API.

Une chaîne de hachage ajoute une autre exigence de compatibilité. L'historique de la chaîne ne peut pas être déduit d'un seul condensat final. Le vérificateur a besoin des règles propres à la version pour le premier enregistrement, l'ordre des enregistrements, l'encodage du condensat parent et le format des points de contrôle. Certificate Transparency fournit ici un bon modèle mental : RFC 9162 définit des preuves de cohérence montrant qu'un arbre antérieur est le même préfixe qu'un arbre ultérieur, au lieu de demander aux auditeurs de faire confiance à une nouvelle valeur racine.

Votre séquence d'audit n'utilise peut-être pas d'arbre de Merkle, mais la leçon reste valable. Lorsque les règles de chaîne changent, prouvez la continuité à la frontière. Créez un point de contrôle v1 terminal contenant son dernier condensat vérifié, le nombre d'enregistrements et la version. Faites authentifier ce point de contrôle par le premier enregistrement v2 dans un champ défini. Le vérificateur v2 doit vérifier les deux côtés avec leurs propres règles avant de déclarer l'historique continu.

Ne réunissez jamais deux historiques en stockant un ancien condensat dans un commentaire ou un champ d'affichage. La jonction doit faire partie de l'entrée protégée.

Les migrations doivent produire des dérivés, jamais des remplacements

Une bonne migration crée un dérivé nouveau et reproductible à côté des preuves sources. Elle conserve suffisamment de provenance pour qu'une autre personne puisse recréer le même résultat et le comparer à la source.

Pour chaque enregistrement ou lot migré, capturez :

{
  "source_digest": "sha256:4a4d...",
  "source_schema_version": 1,
  "migration_id": "audit-v1-to-v2",
  "migration_build": "2.7.0+e31c9f4",
  "output_digest": "sha256:77c8...",
  "migrated_at": "2026-07-22T14:12:09Z"
}

L'heure migrated_at décrit le dérivé, et non l'événement original. Ne remplacez pas recorded_at et ne présentez pas un enregistrement v2 généré comme s'il avait été émis par l'ancien système. Cette erreur a semé plus de confusion dans les enquêtes internes qu'un plantage évident de l'analyseur.

Certaines migrations ne peuvent pas être sans perte. Un enregistrement v1 peut avoir une seule chaîne target, tandis que v2 exige un URI structuré. Si l'analyse échoue ou reste ambiguë, conservez la chaîne source et indiquez explicitement l'état de la migration. N'inventez pas une valeur structurée simplement parce que votre nouvel index en souhaite une.

Par exemple :

{
  "source_digest": "sha256:4a4d...",
  "migration_status": "partial",
  "derived": {
    "target_raw": "[email protected]:22",
    "host": "prod.example",
    "port": 22
  },
  "unresolved": ["user"]
}

Le résultat peut sembler moins ordonné qu'une ligne entièrement remplie. Il est plus honnête. Un futur enquêteur peut voir à la fois ce que disait l'ancien enregistrement et ce que la migration a déduit.

Évitez la recommandation courante qui consiste à faire passer chaque ancienne entrée dans l'écrivain actuel pour appeler cela une mise à niveau. Elle est populaire parce qu'elle simplifie un chemin de code et uniformise les rapports. Elle est incorrecte pour les preuves, car les écrivains appliquent généralement les valeurs par défaut actuelles, omettent les champs obsolètes et normalisent les valeurs. Le résultat peut être utile pour la recherche, mais c'est une traduction, pas un témoignage original.

Un corpus permanent de fixtures détecte les ruptures silencieuses

La compatibilité est un élément de test, pas une promesse dans une note de version. Constituez un corpus de preuves pour chaque version de schéma publiée et exécutez-le avec chaque version du vérificateur qui prétend prendre cette version en charge.

Le corpus doit contenir plus que quelques enregistrements de réussite. Conservez des fixtures exactes au niveau des octets pour les cas suivants :

• un enregistrement valide normal et une chaîne valide de plusieurs enregistrements ;
• des horodatages limites, du texte Unicode, des valeurs facultatives vides et les limites numériques acceptées par cette version ;
• un enregistrement dont un octet de la charge utile a changé ;
• un enregistrement dont le condensat parent a changé ou dont la séquence a été réordonnée ;
• des entrées mal formées, en double, tronquées et de version inconnue.

Stockez les résultats attendus, pas seulement les objets décodés attendus. Le test doit vérifier le résultat de la preuve et la catégorie du diagnostic. Un vérificateur qui marque correctement un enregistrement valide comme invalide a tout de même échoué. Un vérificateur qui transforme un enregistrement mal formé en exception générique d'analyseur a échoué de façon moins spectaculaire, mais il a compliqué l'enquête.

Utilisez un manifeste qui fixe les condensats des fixtures et le comportement attendu du vérificateur :

fixture: v1/0007-http-request.json
sha256: 4a4d5f0c...
expect:
  status: verified
  schema_version: 1
  chain_position: 7

fixture: v1/0007-http-request-tampered.json
sha256: 91af2a7d...
expect:
  status: invalid
  error_code: payload_digest_mismatch

Testez ensuite plusieurs directions.

1. Le plus ancien vérificateur conservé doit encore vérifier son corpus original.
2. Le vérificateur actuel doit vérifier chaque corpus historique conservé.
3. Un écrivain candidat doit créer des enregistrements que le vérificateur actuel accepte sous la nouvelle version.
4. Une migration candidate doit conserver le condensat source déclaré et produire le dérivé attendu.
5. Chaque vérificateur doit rejeter les fixtures conçues pour des versions futures non prises en charge.

Ne réécrivez pas les fixtures attendues chaque fois qu'un test échoue. Examinez d'abord les octets, la version du vérificateur sélectionnée et le code d'échec. Les mises à jour de fixtures doivent rester rares, être examinées comme une modification de protocole et être accompagnées d'une raison distinguant une nouvelle fixture intentionnelle de preuves modifiées.

Ajoutez des tests de propriétés autour des analyseurs, mais ne les confondez pas avec le corpus permanent. Les entrées aléatoires trouvent des plantages et des cas limites étranges. Les fixtures nommées préservent les cas que vous avez déjà appris à vos dépens, notamment les enregistrements de versions réelles après suppression des informations sensibles.

Tester la frontière de mise à niveau comme le ferait une enquête

Le risque le plus élevé se situe généralement à la frontière entre les versions, et non dans l'une ou l'autre version prise isolément. Écrivez un scénario qui commence avant la mise à niveau et se termine après, puis demandez-vous si une personne indépendante peut expliquer toute la séquence.

Considérez une chaîne dans laquelle v1 enregistre l'approbation d'une session d'agent, plusieurs appels HTTP et la révocation d'une session. La version 2 ajoute un champ de résultat de requête plus détaillé ainsi qu'un nouvel encodage du contrôle de somme. Le test doit commencer par un enregistrement de genèse v1, ajouter des entrées v1 valides, créer le point de contrôle documenté à la frontière, ajouter des entrées v2 et exporter l'ensemble du paquet.

Le rapport de vérification attendu doit afficher clairement la transition :

$ audit verify evidence-bundle
verified v1 records: 18
verified v1 terminal digest: sha256:6c12...e98a
verified v1-to-v2 continuity checkpoint
verified v2 records: 6
chain status: verified

Lancez maintenant les défaillances que provoquent les mises à niveau en production :

• supprimer le dernier enregistrement v1 tout en conservant les enregistrements v2 ;
• modifier le condensat v1 du point de contrôle ;
• utiliser un enregistrement v2 avec une étiquette de version v1 ;
• n'exporter que le segment v2 et demander un verdict sur tout l'historique ;
• exécuter un vérificateur antérieur à v2 sur le paquet mixte.

Un système correct donne des réponses différentes. Les trois premiers cas sont invalides. Le quatrième peut être vérifié comme segment partiel si le paquet indique son point de contrôle de départ, mais il ne peut pas prétendre avoir vérifié tout l'historique. Le cinquième renvoie unsupported_version après avoir signalé les preuves v1 qu'il a pu vérifier, si la conception de la commande autorise les rapports partiels. Il ne doit pas déclarer tout le paquet vérifié.

C'est à ce moment que les équipes découvrent que leurs journaux et leurs tableaux de bord masquent les frontières entre les sources. Une interface qui fusionne les enregistrements en une seule chronologie peut convenir, à condition d'étiqueter la transition de schéma et de permettre au réviseur d'inspecter l'enveloppe originale. Ne forcez pas un enquêteur à déduire un changement de format à l'apparition soudaine d'un champ.

Garder le vérificateur assez petit pour survivre à l'application

Le vérificateur d'audit doit avoir moins de dépendances et moins de privilèges que l'application qui produit les enregistrements. Si la lecture d'anciennes preuves exige de démarrer une application graphique, de se connecter à un compte, d'ouvrir un coffre de secrets ou de télécharger un paquet de compatibilité, votre dispositif de preuves dépend de conditions qui disparaîtront au pire moment.

Séparez les responsabilités :

• L'application écrit les enregistrements et présente l'activité en direct.
• Un vérificateur compact lit un paquet exporté, sélectionne les méthodes versionnées et produit un rapport lisible par une machine.
• Un moteur de rendu peut transformer les enregistrements vérifiés en tableaux et chronologies sans participer à la décision d'authenticité.

Rendez le vérificateur déterministe. Avec le même paquet et les mêmes options de commande, il doit renvoyer les mêmes codes d'état et la même structure de rapport. Incluez l'identifiant de version du vérificateur dans son rapport, mais ne permettez pas à cet identifiant de modifier le résultat concernant les preuves.

Pour Sallyport, sp audit verify est le contrôle à conserver dans une procédure de mise à niveau, car il vérifie hors ligne la chaîne de hachage chiffrée sur le texte chiffré et n'a pas besoin de la clé du coffre-fort. Enregistrez le rapport de la commande à côté d'une exportation intacte avant de modifier l'application, puis vérifiez à nouveau cette même exportation après la modification.

Le mot « hors ligne » doit être utilisé avec précision. Il signifie que le vérificateur peut établir le résultat de la chaîne à partir des preuves disponibles et de ses méthodes de vérification intégrées. Il ne signifie pas qu'il peut reconstituer les enregistrements manquants, déterminer qui utilisait une machine ou prouver qu'un utilisateur a compris une carte d'approbation. Un rapport bien conçu indique exactement quelle affirmation il a contrôlée.

Publiez la spécification du format des preuves avec le code source du vérificateur et les fixtures. Une version source sans corpus de fixtures laisse les futurs responsables deviner la compatibilité. Un corpus sans méthode écrite les laisse deviner si un test réussi reflète une règle intentionnelle ou un accident d'implémentation.

Définir une politique de retrait avant la première urgence

Vous ne pouvez cesser de prendre en charge un format historique qu'après avoir décidé ce qui arrivera aux preuves qui l'utilisent. Cette décision relève de la sécurité, du juridique, des opérations et des personnes qui enquêtent sur les incidents. Elle ne doit pas être une conséquence fortuite de la suppression d'un ancien paquet.

Rédigez un tableau de prise en charge indiquant les versions conservées, les versions du vérificateur capables de les lire, la durée prévue de conservation des preuves et la procédure applicable à une archive exceptionnelle. Si vous prévoyez de retirer un lecteur, fournissez un vérificateur d'archive autonome et figez d'abord son corpus de fixtures. Conservez ses instructions de compilation et ses sommes de contrôle attendues avec la documentation des preuves.

Ne promettez pas une prise en charge perpétuelle à la légère. Les algorithmes vieillissent, les systèmes d'exploitation changent et les anciens analyseurs peuvent contenir des failles. Préservez toutefois un moyen de vérifier les preuves conservées. Il peut s'agir d'un outil d'archive isolé qui n'accepte que des fichiers locaux, ou de la conservation d'une image de conteneur ou de machine virtuelle accompagnée de condensats enregistrés. Le choix dépend de votre environnement. L'obligation reste la même : ne pas demander à un futur enquêteur de reconstituer de mémoire une chaîne d'outils disparue.

La première action est concrète : exportez un petit paquet de preuves réelles, exécutez le vérificateur, puis notez chaque règle versionnée dont la commande dépendait. Si vous ne pouvez pas décrire cette méthode et reproduire le résultat après une mise à niveau de test, vous n'avez pas encore de plan de mise à niveau. Vous espérez simplement que les anciennes preuves resteront lisibles.