# Journaux d'audit chaînés par hachage : ce qu'ils prouvent et ce qu'ils ne prouvent pas

Une chaîne de hachage peut fournir une preuve solide qu'un ensemble d'enregistrements d'audit n'a pas été modifié, réordonné ou discrètement inséré au milieu après sa création. Elle ne prouve pas que l'application a journalisé chaque événement pertinent, qu'un horodatage correspond à l'heure réelle ou qu'une personne nommée a effectué une action. Traiter ces éléments comme des preuves de toutes ces affirmations conduit les équipes à constituer des dossiers impressionnants en apparence, mais qui s'effondrent dès la première question sérieuse.

J'ai vu des analyses d'incident s'enliser parce que les équipes demandaient à un journal de répondre à des questions pour lesquelles il n'avait jamais été conçu. La chaîne était correctement vérifiée, mais personne ne pouvait déterminer si le service avait journalisé la requête refusée, si l'identité de l'opérateur était réelle ou si l'horloge du système avait dérivé. La cryptographie fonctionnait. Le dossier de preuves était incomplet.

Pour les développeurs qui exécutent des agents ayant accès à des API et à SSH, cette distinction compte encore davantage. Un agent peut effectuer de nombreuses actions rapidement. Plus tard, la question utile est souvent très précise : quel processus a demandé cet appel, avec quelle autorité, quelle requête exacte l'exécuteur a-t-il envoyée, quelle réponse a été reçue et quelqu'un l'a-t-il approuvée ? Une chaîne de hachage protège une partie de cette histoire. Elle ne peut pas écrire le reste à votre place.

## Une chaîne valide prouve la continuité des enregistrements, pas la réalité

Une chaîne de hachage valide prouve que chaque enregistrement disponible s'engage sur l'enregistrement précédent et que la séquence est restée cohérente depuis le point de départ choisi. Si quelqu'un modifie un ancien événement, échange deux événements ou insère un enregistrement entre deux enregistrements existants, la vérification échoue, sauf si cette personne peut recalculer tous les liens suivants et remplacer tous les points de contrôle de confiance.

C'est une preuve utile. Elle permet à un enquêteur de dire : « Ces enregistrements forment la même séquence que celle qui a produit cette tête de chaîne connue. » La formulation compte. Cette affirmation dépend d'une tête de chaîne connue ou d'une autre référence fiable. Si l'unique copie de la chaîne et son condensat final se trouvent sur la même machine contrôlée par un attaquant, celui-ci peut réécrire les deux.

Une chaîne de hachage ne prouve pas les affirmations suivantes :

- L'application a observé chaque événement qui devait être enregistré.
- Le contenu de l'événement décrit fidèlement ce qui s'est passé en dehors du système de journalisation.
- L'heure de l'événement correspond à une horloge fiable.
- Une personne, plutôt qu'un processus compromis utilisant ses identifiants, a déclenché l'action.
- La chaîne a commencé avant qu'un attaquant ne prenne le contrôle du système.

Il s'agit de propositions différentes, qui nécessitent des preuves différentes. Ne qualifiez pas un journal d'« infalsifiable ». Un logiciel n'obtient pas ce statut parce qu'il utilise SHA-256. Une chaîne rend les modifications détectables selon certaines hypothèses. C'est la propriété utile et défendable.

La distinction entre **intégrité** et **exhaustivité** mérite une attention particulière. L'intégrité consiste à déterminer si les enregistrements dont vous disposez ont été modifiés. L'exhaustivité consiste à déterminer si des enregistrements manquent. Une chaîne répond bien à la première question. Elle ne répond à la seconde que lorsque des preuves externes fixent à la fois les points de contrôle attendus et le périmètre des événements que le système de journalisation devait produire.

## Le format de l'enregistrement détermine ce que le hachage couvre réellement

Une chaîne ne protège que les octets qui entrent dans le condensat. Avant de débattre des algorithmes, définissez un format d'événement canonique et incluez tous les champs dont un enquêteur aura besoin pour comprendre l'action.

Un enregistrement minimal peut ressembler à ceci :

```json
{
  "sequence": 1842,
  "event_id": "7b2ea6de-9c3f-4bb4-b1d7-8b13fbb1c5b9",
  "recorded_at": "2025-03-08T17:14:22.481Z",
  "actor": {"kind": "agent_process", "process_id": "p-91f"},
  "action": "http.request",
  "target": "api.example.internal/v1/releases",
  "request_digest": "sha256:...",
  "result": {"status": 201, "response_digest": "sha256:..."},
  "previous_hash": "sha256:..."
}
```

Le système écrit l'enregistrement sous une forme définie, hache ces octets et stocke le condensat obtenu comme référence du prédécesseur dans l'enregistrement suivant. En théorie :

```text
record_hash[n] = SHA-256(canonical_record[n])
canonical_record[n+1].previous_hash = record_hash[n]
```

Le champ `previous_hash` doit lui-même se trouver dans les octets couverts par `record_hash[n]`. L'omettre est une erreur d'implémentation embarrassante, mais bien réelle. Dans cette conception, les enregistrements portent des décorations ressemblant à des condensats sans lier la séquence.

La canonicalisation n'est pas un détail. Deux sérialiseurs JSON peuvent ordonner différemment les champs d'un objet, échapper différemment les caractères Unicode ou formater les nombres de façon différente. Un vérificateur qui reconstruit le JSON au lieu de vérifier les octets stockés exactement peut rejeter des enregistrements honnêtes ou, pire encore, créer un désaccord sur leur signification. Stockez la représentation originale en octets, précisez l'encodage et testez la vérification avec plusieurs implémentations indépendantes.

La chaîne doit couvrir le contexte, pas seulement le corps de la requête. Un enregistrement qui dit « déployé » apporte peu de preuves. Un enregistrement qui lie la version de l'exécuteur, le type d'action, l'identifiant de la cible, l'identité authentifiée du processus, la décision d'autorisation, le condensat de la requête, le condensat de la réponse, le numéro de séquence et l'heure d'enregistrement donne à l'examinateur des éléments à évaluer. Cela ne prouve toujours pas que chaque champ est vrai, mais empêche un éditeur ultérieur de modifier l'histoire champ par champ.

La publication spéciale 800-92 du NIST, *Guide to Computer Security Log Management*, souligne le même point pratique en termes opérationnels plus simples : les enregistrements doivent contenir suffisamment d'informations sur l'événement, la source, l'utilisateur, le statut et l'heure pour permettre une analyse, et les organisations doivent protéger les données de journalisation. Une chaîne parfaite autour d'enregistrements vagues préserve parfaitement des enregistrements vagues. Ce n'est pas une conception d'audit.

## Le premier enregistrement et la fin manquante restent exposés

Toute chaîne possède un premier enregistrement, souvent appelé enregistrement de genèse. Sa valeur de prédécesseur est fixée par convention, par exemple comme le condensat d'une chaîne d'octets vide, ou elle fait référence à un point de contrôle antérieur. La chaîne peut établir la continuité après ce point. Elle ne peut pas expliquer pourquoi ce point constitue le début de l'historique.

Prenons un service qui écrit les enregistrements 1 à 10 000 dans un stockage local. Un attaquant en prend le contrôle total, supprime les enregistrements 1 à 7 000, modifie le champ de séquence des enregistrements conservés et construit une nouvelle chaîne à partir de ce qui était l'enregistrement 7 001. La chaîne falsifiée est correctement vérifiée. Un examinateur qui ne dispose d'aucun point de contrôle antérieur ne voit aucun défaut cryptographique.

Le même problème existe à la fin de la chaîne. Une panne, une coupure de courant ou un attaquant peut empêcher les derniers événements d'atteindre un stockage durable. Le dernier enregistrement conservé peut être correctement vérifié alors qu'une action s'est produite quelques instants plus tard. Une chaîne prouve que la fin conservée n'a pas été modifiée après coup. Elle ne prouve pas qu'il s'agit du véritable dernier événement.

Vous pouvez réduire ces deux lacunes en émettant des points de contrôle hors du contrôle du système d'écriture. Un point de contrôle contient au minimum l'identifiant de la chaîne, le numéro de séquence, le condensat de l'enregistrement et l'heure du point de contrôle. Envoyez-le vers un compte distinct, un stockage à écriture unique, un service d'horodatage externe ou un collecteur administré indépendamment. Un point de contrôle signé vaut mieux qu'un point de contrôle non signé, car il lie la déclaration à une identité de signature.

La RFC 3161 décrit un protocole d'horodatage dans lequel une autorité d'horodatage signe la preuve qu'elle a observé l'empreinte d'un message à une heure donnée. Cela peut étayer une affirmation limitée et utile : l'autorité disposait de ce condensat à cette heure. Cela ne dit pas si le contenu de l'événement était honnête, si des événements antérieurs ont été omis avant le point de contrôle soumis ou si l'acteur était autorisé. Utilisez-le pour les preuves d'existence et de temps, pas pour remplacer les enregistrements opérationnels.

La fréquence des points de contrôle est une décision liée au risque. Des points de contrôle fréquents réduisent l'intervalle pendant lequel quelqu'un peut supprimer une fin non ancrée. Ils créent aussi davantage d'enregistrements externes à conserver et à rapprocher. Ne prétendez pas que des points de contrôle horaires protègent une reconstitution d'incident à la minute près. Indiquez l'intervalle maximal non ancré dans votre procédure d'exploitation.

## Un hachage ne transforme pas un horodatage en heure fiable

Un horodatage de journal enregistre ce qu'indiquait l'horloge du système de journalisation lorsqu'il a créé l'enregistrement. Cela peut suffire pour le débogage courant. C'est une preuve faible pour les questions liées aux échéances, aux fenêtres de négociation, aux accès après une révocation ou à l'ordre des événements entre plusieurs machines.

Un administrateur peut modifier une horloge locale. Une machine virtuelle peut reprendre son activité avec une heure obsolète. La synchronisation de l'heure réseau peut échouer. Même un hôte correctement synchronisé enregistre le moment où son application a écrit l'événement, ce qui peut différer du moment où un service distant a reçu la requête ou validé la modification.

Conservez ces heures séparément lorsque la distinction compte :

- `observed_at` : le moment où le composant d'origine a observé l'événement.
- `recorded_at` : le moment où le système d'audit a créé son enregistrement.
- `remote_at` : une heure renvoyée par le système distant, s'il en fournit une.
- `checkpoint_at` : le moment où un témoin indépendant a accepté une tête de chaîne.

Ne les fusionnez pas dans un unique champ `timestamp` rassurant. Chacune a une source et un mode de défaillance différents. L'enquêteur peut ainsi raisonner sur un intervalle plutôt que de s'appuyer sur une fausse précision.

Si vous avez besoin de preuves temporelles, enregistrez la manière dont l'hôte synchronise son heure, conservez les alertes de santé de la synchronisation et préservez les reçus de points de contrôle signés. Pour les opérations à fort enjeu, comparez l'enregistrement local avec le propre journal d'audit du service distant. Une requête journalisée à 10:02:01 et une modification distante journalisée à 10:02:05 peuvent décrire la même action. La chaîne protège votre enregistrement contre les modifications ; la corroboration le relie au système externe.

Une recommandation courante affirme : « Utilisez une base de données en ajout uniquement et des horodatages, et le problème de l'audit sera résolu. » Elle est populaire parce qu'elle semble simple à appliquer. Elle est fausse, car le comportement en ajout uniquement d'un seul service ne dit pas grand-chose sur la fiabilité de l'horloge, les événements manquants, l'identité ou les effets externes. Utilisez un stockage en ajout uniquement s'il vous convient, mais indiquez clairement les preuves qui vous manquent encore.

## L'attribution exige une piste d'identité distincte du condensat

Une chaîne de hachage peut préserver une affirmation d'attribution telle que `actor = alice@example.com`. Elle ne peut pas prouver qu'Alice a fourni l'identifiant, que le fournisseur d'identité l'a correctement authentifiée ou qu'un attaquant n'a pas utilisé sa session active. Le condensat protège la phrase, pas sa véracité.

Pour les actions d'un agent, l'identité du processus est souvent plus utile qu'un champ utilisateur vague. Enregistrez l'identifiant du processus de l'agent, le processus parent lorsqu'il est disponible, l'autorité de signature de l'exécutable, l'heure de lancement, l'identifiant de session ainsi que le compte humain ou de service qui a autorisé la session. Le seul nom du processus constitue une preuve faible. N'importe quel programme peut choisir un nom familier.

La signature de code permet une affirmation limitée : le système d'exploitation peut déterminer qu'un exécutable porte une signature associée à une autorité de signature et que cette signature est valide selon les règles de la plateforme. Elle ne prouve pas que l'opérateur de l'exécutable avait de bonnes intentions. Elle aide à distinguer une version connue d'un binaire arbitraire portant le même nom de fichier.

L'authentification et l'autorisation nécessitent elles aussi des enregistrements distincts. L'authentification indique quel identifiant ou principal le système a accepté. L'autorisation indique pourquoi le système a permis cette action à ce moment-là. Une boîte de dialogue d'approbation, une attribution de rôle, la portée d'un jeton ou un ticket de modification peuvent constituer la preuve d'autorisation. Placez une référence stable ou le condensat de cette décision dans l'enregistrement d'action, puis conservez l'enregistrement de décision sous contrôle d'accès.

Les signatures numériques renforcent cette couche lorsqu'elles sont utilisées correctement. Si un système d'audit signe les têtes de chaîne périodiques, un vérificateur peut confirmer que le détenteur d'une clé privée a produit ces signatures. Cela ajoute une preuve de source qui n'existe pas avec un hachage sans clé. Cela dépend néanmoins de la protection de la clé privée, de l'état du certificat, des enregistrements de rotation et de la correspondance entre le sujet du certificat et une identité opérationnelle réelle.

Ne cachez pas tout cela dans une seule chaîne `user`. Lors d'un incident, il faut distinguer la personne qui a approuvé une exécution, le processus qui a demandé l'action, le service qui l'a exécutée et l'autorité des identifiants qui l'a acceptée. Il peut s'agir de quatre acteurs différents.

## La preuve d'autorisation répond à une question différente de celle de l'activité

Un enregistrement d'activité répond à la question : « Qu'a fait l'exécuteur ? » Un enregistrement d'autorisation répond à la question : « Pourquoi avait-il le droit de le faire ? » Les équipes les fusionnent souvent parce qu'ils apparaissent tous deux pendant la même requête. Cette fusion complique les enquêtes.

Supposons qu'un agent demande une commande SSH. L'exécuteur enregistre l'hôte demandé, le condensat de la commande, le résultat, l'identité du processus et l'heure. De son côté, la couche d'autorisation enregistre qu'un nouveau processus a reçu une approbation, la personne qui l'a approuvé, ce que couvrait l'approbation et le moment où elle a expiré. Si la commande SSH est exécutée plus tard, l'événement d'activité doit faire référence à l'enregistrement d'autorisation applicable.

Cette conception permet à l'examinateur de poser les bonnes questions. La commande a-t-elle été envoyée ? Consultez l'enregistrement d'activité. La session avait-elle l'autorisation nécessaire ? Consultez l'enregistrement d'autorisation. L'écran d'approbation affichait-il une identité exacte ? Consultez les enregistrements de l'interface et de l'identité du processus. L'hôte distant a-t-il exécuté la commande ? Consultez ses journaux serveur ou l'état qui en résulte.

L'approbation d'une session et l'approbation de chaque utilisation sensible d'un identifiant fournissent des preuves différentes. L'approbation d'une session établit qu'une personne a autorisé un processus donné à fonctionner pendant toute sa durée de vie. L'approbation par action établit une décision plus restreinte, proche d'une opération précise. Aucune n'est automatiquement supérieure. Le choix dépend de la fréquence des actions, de leurs conséquences et de la capacité réelle d'une personne à évaluer des demandes répétées.

La lassitude face aux approbations est un défaut de conception, pas une raison d'arrêter d'enregistrer les approbations. Si une personne voit des centaines de demandes impossibles à distinguer, les clics qui en résultent apportent peu de preuves d'une autorisation réfléchie. Regroupez les tâches à faible risque sous une décision de session limitée, réservez les confirmations répétées aux identifiants ou aux actions pour lesquels la personne peut évaluer la cible et la conséquence, et décrivez clairement la portée.

Un événement d'approbation ne peut pas non plus prouver à lui seul un consentement éclairé. Il prouve que le mécanisme d'approbation a enregistré une décision. Les détails du processus affichés à l'utilisateur, le lien entre cet affichage et le processus exécutant ainsi que l'enregistrement d'audit déterminent si cette décision pourra être prise en compte plus tard.

## L'exhaustivité dépend des endroits où les actions peuvent contourner le système de journalisation

Vous ne pouvez pas obtenir un relevé complet des actions d'un agent en ajoutant une chaîne de hachage à un fichier journal après que l'agent a déjà obtenu les identifiants bruts. Dès qu'un agent reçoit un jeton API ou une clé privée SSH, il peut appeler un autre client, copier le secret ou effectuer une requête sans passer par le chemin audité. La chaîne peut préserver fidèlement les requêtes qu'elle a vues tout en ignorant celles qui comptent.

L'exhaustivité commence par le contrôle de la frontière d'action. Le composant qui détient l'identifiant doit exécuter lui-même la requête réseau ou l'opération SSH et journaliser la décision et le résultat avant de renvoyer une réponse. L'agent doit recevoir le résultat, pas le secret. L'affirmation passe ainsi de « nous avons demandé à l'agent de journaliser son travail » à « le détenteur de l'identifiant a observé chaque utilisation sur ce canal ».

Même dans ce cas, le périmètre doit être explicite. Si un développeur peut aussi utiliser le même identifiant dans un terminal, la piste d'audit couvre l'utilisation médiée par l'agent, mais pas toute l'utilisation de l'identifiant. Si un agent peut atteindre un second chemin réseau qui contourne l'exécuteur, la piste ne couvre pas ce chemin. Toute affirmation d'exhaustivité doit préciser le canal, le principal et la période couverte.

Sallyport applique cette frontière pour ses canaux HTTP et SSH pris en charge : le coffre-fort chiffré conserve les identifiants API et SSH hors de portée de l'agent, tandis que l'application exécute l'action et l'enregistre. Sa piste d'audit couvre ainsi un périmètre plus solide que celui d'un journal d'activité situé côté agent, mais elle ne dit rien des actions effectuées par un chemin d'identifiants sans rapport.

Un test de défaillance utile consiste à dessiner chaque itinéraire entre un agent et un effet externe. Incluez les clients HTTP directs, les outils shell, les fichiers locaux contenant des jetons, les sessions de navigateur, les services de métadonnées cloud, les variables CI et la configuration SSH. Chaque itinéraire qui ne passe pas par l'exécuteur journalisé constitue une exception à toute affirmation d'exhaustivité. Fermez-le, isolez-le ou signalez honnêtement l'exception.

## La confidentialité, les accès et la conservation nécessitent leurs propres contrôles

Les chaînes de hachage ne révèlent rien par elles-mêmes, mais les enregistrements d'audit contiennent souvent des informations que vous ne placeriez pas dans un journal d'application ordinaire. Les URL de requête peuvent révéler des identifiants client. Les lignes de commande peuvent contenir des secrets. Les réponses peuvent contenir des données personnelles. Une chaîne qui rend ces enregistrements difficiles à modifier peut aussi rendre une divulgation imprudente difficile à annuler.

Chiffrez le stockage d'audit et limitez les personnes qui peuvent le lire. Séparez autant que possible la capacité à vérifier l'intégrité de la capacité à déchiffrer le contenu. Un vérificateur peut recalculer les hachages sur les octets chiffrés et comparer les références aux prédécesseurs sans voir le contenu protégé. C'est utile lorsqu'un examinateur doit établir qu'une archive scellée est toujours intacte avant qu'un enquêteur autorisé ne l'ouvre.

L'expurgation doit avoir lieu avant l'entrée de l'enregistrement dans la chaîne. Remplacer un secret après l'écriture modifie les octets et rompt la chaîne. Enregistrez plutôt le condensat du corps de la requête sensible, une référence stable au jeton, sa longueur lorsque c'est pertinent ou une déclaration structurée indiquant qu'un champ a été masqué. Documentez la règle d'expurgation. Sinon, deux enregistrements qui semblent similaires peuvent avoir été expurgés selon des règles différentes.

La conservation influe aussi sur la valeur probante. Si une tâche de conservation supprime d'anciens enregistrements, elle doit produire son propre enregistrement indiquant la plage supprimée, la règle de conservation applicable, l'heure de suppression et le dernier point de contrôle avant la suppression. Conservez ce point de contrôle dans une archive distincte. Une chaîne ne peut pas faire réapparaître des éléments supprimés, mais les preuves conservées peuvent montrer que la suppression a eu lieu selon une procédure définie plutôt que silencieusement.

La journalisation des accès compte également. Enregistrez qui a exporté une archive d'audit, qui l'a déchiffrée et qui a modifié la configuration de conservation. Les journaux d'audit attirent l'attention pendant un incident. La chaîne protège les enregistrements passés contre les modifications discrètes, mais un groupe étendu de lecteurs peut toujours copier des contenus sensibles ou faire pression sur un opérateur pour supprimer la journalisation future.

## Vérifiez l'archive avant d'en avoir besoin

La vérification doit être une opération courante dont le résultat est conservé, et non une commande que quelqu'un essaie pour la première fois pendant une panne. Votre procédure doit identifier exactement la plage d'archives, la version du vérificateur, la source du point de contrôle attendu, l'heure de vérification, l'opérateur et le résultat.

Un vérificateur doit détecter au moins quatre défaillances : des enregistrements mal formés, une référence de prédécesseur incorrecte, un enregistrement dont le condensat ne correspond pas aux octets stockés et un écart entre la tête calculée et un point de contrôle attendu. Sa sortie doit être facile à conserver. Par exemple :

```text
$ audit verify --archive agent-actions-2025-03-08.log --checkpoint checkpoints/2025-03-08.json
chain_id: agent-actions-prod-a
records_checked: 1842
first_sequence: 1
last_sequence: 1842
computed_head: sha256:4e7c...a912
checkpoint_head: sha256:4e7c...a912
result: VALID
```

Le résultat `VALID` signifie que le vérificateur a comparé les octets fournis au point de contrôle fourni. Il ne signifie pas que « chaque action de production est présente » ni que « les événements sont vrais ». Inscrivez directement cette limite dans la procédure. Sous pression, les personnes qui voient un résultat positif lui attribuent sinon plus de portée qu'il n'en a.

Testez les cas destructifs sur une archive hors production. Modifiez un octet dans le corps d'un enregistrement. Déplacez deux enregistrements. Supprimez un enregistrement au milieu. Remplacez la tête du point de contrôle. Tronquez la fin. Le vérificateur doit rejeter chacun de ces cas, à l'exception d'une troncature ordinaire de la fin sans point de contrôle final attendu, pour laquelle il peut signaler un préfixe valide. Ce résultat est correct, et doit vous inquiéter pour la bonne raison.

Sallyport permet de vérifier hors ligne les chaînes avec `sp audit verify`, et son vérificateur peut contrôler la chaîne d'audit chiffrée sans clé de coffre-fort. Lancez ce contrôle après les exports et entraînez-vous à le rapprocher des vues distinctes des sessions et des activités avant qu'une enquête ne vous y oblige.

## Un dossier de preuves a besoin d'enregistrements qui se contredisent utilement

Une enquête défendable utilise plusieurs enregistrements présentant des modes de défaillance différents. L'accord entre des sources indépendantes a plus de poids qu'un seul journal qui répète ses propres hypothèses.

Pour une action sensible d'un agent, conservez l'enregistrement d'activité chaîné par hachage, l'enregistrement de session ou d'approbation, l'identité authentifiée du processus, la version de configuration pertinente, le reçu du point de contrôle externe ainsi que l'enregistrement du système cible ou le résultat observable. Vous n'avez pas besoin de chaque source pour chaque requête ordinaire. Il vous en faut suffisamment au regard des conséquences d'une erreur.

Attendez-vous à ce que les sources divergent parfois. L'enregistrement d'activité local peut précéder l'horodatage du service distant parce que la transmission réseau a pris du temps. Une requête peut recevoir une réponse positive alors que le système distant annule ensuite l'opération. Un enregistrement de session peut montrer une approbation tandis que l'enregistrement d'action ne montre aucune utilisation de l'autorité accordée. Ces différences sont des éléments à examiner, pas des défauts à lisser.

Écrivez les affirmations exactes que votre système peut étayer. Par exemple : « Cette archive contient une séquence non modifiée d'enregistrements de l'exécuteur jusqu'au point de contrôle X. » Écrivez ensuite les affirmations qu'elle ne peut pas étayer seule : « Cette archive ne prouve pas qu'aucune utilisation directe des identifiants n'a eu lieu. » Des limites claires rendent les affirmations solides crédibles.

La première action pratique consiste à choisir une opération d'agent à fort enjeu et à la reconstituer du début à la fin. Identifiez la frontière d'action, les champs écrits avant l'exécution, ceux écrits après, les preuves d'approbation, la destination du point de contrôle, la corroboration distante et chaque chemin de contournement. Si une partie dépend du souvenir de quelqu'un, vous ne disposez pas encore d'une piste d'audit. Vous avez une histoire qui risque de ne pas résister à un incident.