# Les sauvegardes de preuves d'audit doivent-elles contenir des identifiants ? Une archive d'incident doit vous aider à répondre aux questions suivantes : qui a fait quoi, quand, par quel chemin approuvé, et si quelqu'un a modifié l'enregistrement par la suite. Elle ne doit pas permettre à la personne qui l'ouvre d'utiliser un jeton API, une clé privée SSH ou de créer l'un ou l'autre. Les équipes se trompent régulièrement parce que les logiciels de sauvegarde donnent à tout le même aspect. Un export de base de données, un export de coffre et un journal d'audit peuvent tous être des fichiers chiffrés au repos. Pourtant, leur rôle de sécurité diffère. Une sauvegarde de coffre restaure l'autorité. Une sauvegarde de preuves préserve la traçabilité. Placez-les dans la même archive et celle-ci héritera de la propriété la plus dangereuse du coffre. Cette distinction compte encore davantage avec les agents de programmation autonomes. En peu de temps, un agent peut effectuer un grand nombre d'actions externes : modifier un dépôt, appeler un service de déploiement, mettre à jour des tickets, administrer le cloud et exécuter des commandes à distance. Après un incident, les équipes ont besoin d'un compte rendu durable de ces actions. Elles n'ont pas besoin d'un paquet transportable contenant les identifiants qui les ont rendues possibles. ## Une sauvegarde de preuves ne doit pas restaurer l'autorité Une archive sans identifiants est un paquet de preuves qui ne peut pas s'authentifier comme un utilisateur, un service ou une machine après sa restauration. Son contenu peut être confidentiel, mais aucun élément ne peut à lui seul provoquer une action externe. Le paquet peut donc contenir un enregistrement comme celui-ci : ```text 2026-07-22T02:14:09Z session=ses_8f0d... process_authority=Developer ID Application: Example Engineering LLC channel=http method=POST host=api.internal.example path=/deployments credential_ref=prod-deploy-token authorization=approved result=201 Created entry_hash=2ebc6f... previous_hash=78dd91... ``` Il ne doit pas contenir le jeton représenté par `credential_ref`. Il ne doit pas non plus contenir de clé privée SSH, de cookie de session, de jeton d'actualisation OAuth, de code de récupération, de base de données de coffre déchiffrée ou de mot de passe d'exportation stocké à côté de l'archive. Si l'un de ces éléments apparaît, vous n'avez plus une simple sauvegarde de preuves. Certains objectent qu'une copie du coffre est nécessaire pour reconstituer complètement les événements. Elle ne l'est que lorsque l'objectif est de restaurer l'autorité après un sinistre. C'est une autre opération, avec un autre modèle de menace. La traiter comme une preuve ordinaire d'incident crée une archive qui doit être protégée comme un accès de production, souvent plus longtemps que l'identifiant d'origine ne devrait rester valide. Utilisez deux classifications explicites dans votre inventaire de sauvegardes : - **Le matériel de récupération de l'autorité** peut restaurer la capacité d'agir. Il doit suivre des procédures de récupération du coffre strictement contrôlées. - **Le matériel de conservation des preuves** peut expliquer et vérifier les actions réalisées. Il doit suivre un processus d'archivage conçu pour la conservation et l'examen. N'adoucissez pas cette limite avec des appellations comme « export de coffre nettoyé ». Un export de coffre qui contient des blocs de secrets chiffrés, des clés de données enveloppées ou le moyen de les déballer reste du matériel de coffre. Un examinateur ne pourra peut-être pas l'utiliser aujourd'hui, mais vous aurez conservé une autre cible qui pourrait devenir exploitable après une compromission distincte. Le test pratique est simple : restaurez l'archive sur une machine propre qui n'a aucun accès à votre système d'identifiants. Si un utilisateur peut transformer un élément de cette archive en requête authentifiée active, corrigez la conception. ## Le chiffrement et l'intégrité des preuves répondent à des questions différentes Le chiffrement répond à la question « qui peut lire cette archive ? ». Les preuves d'intégrité répondent à la question « cet enregistrement a-t-il été modifié, réordonné ou tronqué ? ». Vous avez besoin des deux réponses, et aucune ne remplace l'autre. Un fichier ZIP protégé par mot de passe peut préserver la confidentialité d'une chronologie d'incident tout en offrant très peu de garanties sérieuses que son contenu est resté intact. Un attaquant capable de le déchiffrer, de le modifier puis de le rechiffrer peut vous laisser une archive bien présentée, sans moyen fiable de distinguer l'original de la réécriture. Une chaîne de hachage suit une autre approche. Chaque événement contient l'empreinte de l'événement précédent et l'empreinte de son propre contenu canonique. Si vous modifiez une entrée passée, les hachages suivants ne correspondent plus. Si vous supprimez une entrée intermédiaire, l'entrée suivante ne pointe plus vers le prédécesseur attendu. L'archive peut alors prouver que la séquence exportée est cohérente en interne, ou montrer exactement où cette cohérence se rompt. Cela ne rend pas une chaîne de hachage magique. Si un attaquant contrôle le système d'écriture avant qu'il n'émette un enregistrement, la chaîne ne peut pas prouver qu'un événement manquant a eu lieu. Si l'attaquant contrôle toutes les copies du journal et peut remplacer la chaîne entière, une chaîne seule ne peut pas identifier celle qui est authentique. Il vous faut toujours des points de contrôle protégés, un export contrôlé et un stockage indépendant. La RFC 5848, « Signed Syslog Messages », est utile parce qu'elle sépare les affirmations que l'on mélange facilement. Elle décrit l'authentification de l'origine, l'intégrité des messages, la résistance à la relecture, le séquençage et la détection des messages manquants. Elle précise aussi qu'un enregistrement de journal authentifié ne prouve pas que l'hôte d'origine était lui-même honnête. Cette limite est saine. Les journaux constituent des preuves de ce qu'un système d'enregistrement a observé et émis, pas une vision surnaturelle de la réalité. Pour une archive d'incident, écrivez clairement l'affirmation d'intégrité que vous pouvez réellement soutenir : - Les octets de l'archive correspondent au manifeste créé au moment de l'exportation. - La séquence du journal est complète jusqu'à un point de contrôle signé ou conservé à l'extérieur. - Toute modification d'une entrée après sa capture entraîne un échec de la vérification. - L'archive ne prouve pas qu'une action non journalisée n'a jamais eu lieu. Cette dernière phrase évite les mauvaises enquêtes. Un résultat d'audit propre soutient une affirmation au sujet du journal. Il n'innocente pas un administrateur qui a utilisé un autre chemin d'identification, en dehors de la passerelle enregistrée. ## Gardez les journaux et la récupération du coffre dans des domaines de protection distincts Des fichiers séparés sont un début. Des domaines de protection séparés sont la véritable exigence. Des groupes d'accès, des procédures de récupération, des calendriers de conservation et des règles de suppression différents empêchent une sauvegarde pratique de devenir un accès indirect à la production. Une organisation raisonnable comporte trois espaces de stockage : 1. Le coffre actif contient les identifiants et le matériel nécessaire pour les utiliser. Sa récupération est rare, strictement autorisée et journalisée. 2. Le journal actif contient les enregistrements d'activité récents et l'état d'intégrité. Les opérateurs en ont besoin pour les enquêtes et le suivi courant. 3. L'archive de preuves contient les segments de journal exportés, les manifestes, les instructions de vérification et les points de contrôle conservés. Les enquêteurs peuvent y accéder avec un autre circuit d'approbation, sans recevoir l'autorité d'utiliser des identifiants actifs. N'utilisez pas la même phrase secrète de chiffrement d'archive pour la copie de récupération du coffre et la copie de preuves. Ne placez pas les deux copies dans le même compartiment cloud sous prétexte que « le compartiment est déjà chiffré ». Ne confiez pas non plus leurs contacts de récupération au même petit groupe par défaut. Ces raccourcis font disparaître la séparation lorsqu'un seul compte administrateur, rôle de sauvegarde ou système de stockage est compromis. La durée de conservation doit également différer. Les identifiants doivent être renouvelés, expirer ou être révoqués lorsque leur objectif opérationnel prend fin. Les preuves peuvent devoir survivre beaucoup plus longtemps, parce que l'incident est découvert plus tard, qu'un client demande des explications ou qu'un examen interne dure plusieurs mois. Lorsqu'une ancienne archive de preuves contient un ancien secret, cette conservation prolongée augmente discrètement la durée d'utilisation possible du secret. Un autre problème apparaît lors du départ d'un collaborateur. Un ingénieur qui quitte l'entreprise perd l'accès au coffre actuel, mais conserve une ancienne sauvegarde chiffrée sur un disque personnel de récupération. Si cette sauvegarde contient des identifiants encore valides, le processus de départ comporte une faille. Si le disque ne contient qu'une archive de journal sans identifiants, il peut toujours contenir des preuves sensibles, mais il ne peut pas réanimer une identité de production. Cette séparation facilite aussi la destruction. Vous pouvez supprimer des preuves selon un calendrier de conservation sans vous demander si vous venez d'effacer l'unique copie de récupération utilisable. Vous pouvez renouveler ou retirer des identifiants sans lancer une purge massive des archives. Ces opérations ne doivent jamais être liées. ## Exportez un paquet de vérification, pas un joli rapport Une chronologie en PDF est utile pour une réunion. Elle constitue une mauvaise preuve principale. Elle perd la structure des enregistrements, masque généralement la représentation exacte des champs qui ont été hachés et empêche l'examinateur de vérifier si la séquence source était complète. Exportez un paquet dont le contenu est vérifiable par une machine, accompagné d'un index lisible par un humain. Une structure d'archive concrète pourrait ressembler à ceci : ```text agent-evidence-2026-07-22/ manifest.json entries.ndjson checkpoints.ndjson activity-summary.txt VERIFYING.md hashes.sha256 ``` `entries.ndjson` contient un objet d'événement canonique par ligne. Gardez les champs stables. Si vous devez censurer le corps d'une requête, indiquez-le dans l'entrée et conservez une empreinte du champ protégé original lorsque cela peut être fait sans risque. Ne remplacez pas silencieusement une valeur par `[REDACTED]` en laissant l'examinateur deviner si elle était absente, masquée ou modifiée après coup. `checkpoints.ndjson` contient les informations qui ancrent les segments du journal. Selon votre conception, il peut s'agir d'une empreinte signée, d'une valeur racine stockée à l'extérieur, d'un reçu de témoin ou de l'enregistrement d'un transfert d'archivage terminé. Une chaîne sans point de contrôle conservé prouve seulement que ses liens internes concordent. `manifest.json` doit décrire l'archive comme un objet, plutôt que de dépendre du nom d'un répertoire. Incluez l'identifiant de l'exportation, la période, les identifiants de séquence les plus ancien et le plus récent, le nombre d'enregistrements, la version du schéma, la version de canonisation, l'algorithme de hachage, l'identifiant de la politique de censure et la valeur finale attendue de la chaîne. Ajoutez la version de l'exportateur et l'identité de l'hôte lorsque ces informations sont utiles à votre enquête. Le résumé d'activité est volontairement secondaire. Il peut indiquer qu'une exécution a effectué sept appels HTTP et deux appels SSH, obtenu une approbation de session et comporté une commande échouée. Un humain peut le lire rapidement. Les entrées détaillées restent la référence faisant foi. La structure d'un manifeste peut être aussi réduite : ```json { "archive_id": "evd_2026_07_22_001", "window_start": "2026-07-22T00:00:00Z", "window_end": "2026-07-22T23:59:59Z", "entry_count": 184, "canonicalization": "journal-json-v1", "hash_algorithm": "SHA-256", "first_sequence": 9012, "last_sequence": 9195, "final_entry_hash": "2ebc6f...", "redaction_policy": "evidence-redaction-v3" } ``` Un rapport peut être régénéré à partir de ce paquet. L'inverse est rarement possible. Conservez les preuves structurées, puis produisez les rapports selon les besoins. ## Les sauvegardes échouent lorsque les exports attendent l'incident La séquence d'échec habituelle semble anodine jusqu'au moment où quelqu'un a besoin des enregistrements. Un agent effectue un déploiement inhabituel à 1 h 40 du matin. Un responsable remarque l'impact sur les clients plus tard dans la matinée. L'équipe examine l'hôte, redémarre l'application, renouvelle les identifiants et copie les journaux encore présents. À midi, le journal local a déjà été écrasé, l'état initial du processus a disparu et le fichier copié n'a ni manifeste ni point de contrôle. Personne n'a nécessairement agi avec malveillance. L'équipe ne peut pourtant pas établir un historique défendable. Elle dispose d'un extrait incomplet, pas d'une archive de preuves. La norme NIST SP 800-92 décrit la gestion des journaux comme allant au-delà de la collecte. Elle comprend la génération, la transmission, le stockage, l'accès et la suppression des données de journal. Cette vision plus large est la bonne. Si votre plan s'arrête à « l'application écrit des journaux », vous avez planifié la génération, pas la conservation. NIST avertit également qu'une journalisation indiscriminée peut créer des problèmes opérationnels et même provoquer une perte de données de journal. Enregistrez suffisamment d'informations pour reconstituer les actions de l'agent, mais ne répandez pas de secrets bruts, de corps de réponse complets et de contenus de fichiers arbitraires dans chaque événement. Intégrez les exports aux opérations courantes avant tout incident. Le calendrier dépend du volume d'actions et de la perte maximale que vous pouvez tolérer, mais il doit avoir un responsable et faire l'objet d'un test. Déclenchez un export après une exécution d'agent à conséquences importantes, avant une maintenance susceptible d'affecter l'état local du système et à intervalles réguliers pour l'activité ordinaire. Testez le scénario difficile. Commencez par une archive restaurée sur une machine distincte. Ne donnez pas au testeur l'accès au coffre. Demandez-lui de répondre aux questions suivantes en utilisant uniquement le paquet : - Quel processus d'agent a lancé l'action ? - Quelle décision d'autorisation l'a permise ou refusée ? - Quelle destination et quelle opération visait-elle ? - La séquence du journal a-t-elle été vérifiée jusqu'au point de contrôle archivé ? - Quelles entrées ont été censurées, et selon quelle règle déclarée ? Si le test exige de rouvrir l'application d'origine, de retrouver un collègue absent, de se souvenir d'une phrase secrète ou de copier un secret depuis le système actif, l'archive est incomplète pour une utilisation en cas d'incident. ## La censure doit préserver la forme de l'action Les équipes choisissent souvent entre deux mauvaises extrémités : déverser chaque requête et chaque réponse dans le journal, ou supprimer tant d'informations que l'enregistrement ne peut plus expliquer l'événement. La première approche transforme le journal en un autre coffre de secrets. La seconde en fait un simple accessoire de conformité. Conservez les faits nécessaires pour identifier et évaluer l'action. Pour un appel HTTP, il s'agit généralement de l'identité de session, de l'autorité de signature du code ou de l'identité équivalente du processus, de l'hôte de destination, de la méthode, du chemin, de la référence de l'identifiant, du résultat de l'approbation, de l'horodatage et d'une représentation appropriée de la requête et de la réponse. Pour SSH, enregistrez la destination, l'identité du compte ou la référence de l'identifiant, la commande ou une représentation conçue avec soin, le résultat de l'approbation, le code de sortie et la classification des sorties pertinentes. L'expression « représentation appropriée » demande du discernement. Une requête `POST /deployments` contenant un identifiant de version et un nom d'environnement peut être conservée en clair sans risque. En revanche, un corps de requête contenant un jeton d'accès, une fiche client ou une clé privée ne le peut pas. Vous pouvez stocker un marqueur de censure fixe ainsi qu'une empreinte du champ original si une comparaison ultérieure est importante. L'empreinte permet à un enquêteur de voir si deux valeurs protégées étaient identiques sans les révéler. Soyez prudent avec les identifiants. Un en-tête d'autorisation est évidemment secret. Un paramètre de requête dans une URL peut être tout aussi dangereux. Une ligne de commande peut contenir un mot de passe, un jeton d'accès cloud ou un chemin vers des données client. Les outils de journalisation ne connaissent pas assez bien la sémantique de votre activité pour prendre seuls toutes les décisions de censure. Écrivez la règle dans l'archive. Par exemple : ```text redaction_policy=evidence-redaction-v3 request_body=retained only for allowlisted JSON fields authorization_header=omitted query_parameters=names retained, values digested response_body=classified and omitted unless allowlisted ssh_command=stored after secret argument filtering ``` Cette déclaration permet à l'examinateur de comprendre pourquoi certaines informations manquent. Elle donne aussi à vos ingénieurs un élément concret à tester lorsqu'une API évolue. Ne censurez pas les résultats d'autorisation, les identités des destinations ou les détails des échecs simplement parce qu'ils sont gênants. Une requête refusée, une tentative d'authentification échouée et un hôte inattendu sont souvent les éléments qui expliquent l'incident. ## Une chaîne propre a tout de même besoin d'une conservation indépendante Le chaînage par hachage empêche les modifications discrètes au sein d'une séquence conservée. Il n'empêche pas une personne qui contrôle le système source de supprimer toute la séquence et d'en commencer une autre. Un plan d'archivage sérieux fournit à la chaîne un point de référence extérieur. La méthode la plus simple consiste à exporter régulièrement des points de contrôle. À intervalles définis, écrivez l'empreinte finale du journal, le numéro de séquence et l'horodatage dans une archive contrôlée séparément. Conservez plusieurs copies dotées d'autorités d'écriture distinctes. Un attaquant qui modifierait ensuite le journal local devrait aussi modifier chaque point de contrôle conservé, sans quoi une divergence apparaîtrait. Vous pouvez renforcer ce dispositif avec des points de contrôle signés, un processus d'horodatage fiable ou un stockage en ajout uniquement. Le bon choix dépend de votre environnement, mais ne passez pas directement à une infrastructure complexe si vous ne pouvez pas effectuer les tests de restauration et de vérification. Un point de contrôle modeste et répété, réellement contrôlé, vaut mieux qu'une conception impressionnante que personne n'a jamais testée. Faites en sorte que la vérification puisse fonctionner hors ligne. C'est là que la conception d'audit de Sallyport est utile : son journal chiffré, chaîné par hachage et insensible à l'écriture peut être vérifié sur le texte chiffré avec `sp audit verify`, sans clé de coffre. Un vérificateur sans identifiants évite la situation absurde où la personne qui cherche à savoir si un agent a utilisé abusivement un secret devrait d'abord obtenir l'accès à ce secret. Votre procédure de conservation des preuves doit préserver le vérificateur lui-même ou documenter le moyen d'obtenir la version exacte utilisée pour le format de l'archive. Enregistrez dans le manifeste une empreinte cryptographique du binaire du vérificateur ou de la révision du code source. Un futur examinateur n'a pas besoin d'un ordinateur ancien, mais il lui faut suffisamment d'informations pour éviter de vérifier silencieusement d'anciennes données avec des règles modifiées. Le résultat attendu de la vérification doit être sans ambiguïté : ```text $ sp audit verify evidence/journal.enc verified: 184 entries chain: intact range: sequence 9012 through 9195 checkpoint: matched ``` Lorsque la vérification échoue, conservez le résultat de l'échec et cessez de traiter l'archive comme une séquence intacte. Un échec ne prouve pas automatiquement une intention malveillante. Il peut révéler un dommage pendant le transfert, un exportateur défectueux, une incompatibilité de format ou une modification délibérée. L'essentiel est que l'archive rende le désaccord visible au lieu d'accepter silencieusement une histoire révisée. ## L'accès aux preuves doit permettre l'enquête tout en protégeant les personnes Les preuves sont plus sûres à partager que les identifiants, mais elles ne sont pas publiques par défaut. Les enregistrements d'audit peuvent révéler des noms de dépôts, la topologie de services internes, les actions d'employés, des identifiants clients et des erreurs opérationnelles. Retirez l'autorité de l'archive, puis contrôlez l'accès aux preuves selon la sensibilité de ce qui reste. Donnez aux enquêteurs un accès en lecture au paquet et au vérificateur, mais pas un accès en écriture à l'emplacement de l'archive de référence. Donnez aux opérateurs système un rôle d'export documenté, en rendant chaque export visible dans la même piste d'audit lorsque c'est possible. Fournissez aux conseillers externes, aux clients ou aux évaluateurs un paquet dérivé et censuré lorsqu'ils n'ont pas besoin des détails internes bruts. Évitez un groupe unique d'« archives de sécurité » capable de lire le matériel de récupération du coffre, de modifier les paramètres de conservation et de télécharger les preuves. Ce groupe accumulera les accès parce que cela facilite les urgences. Il permettra aussi à un seul compte compromis d'effacer à la fois votre capacité de récupération et votre capacité à expliquer ce qui s'est passé. Définissez un registre de garde de l'archive. Il n'a pas besoin de mise en scène judiciaire. Il doit contenir les faits essentiels : identifiant de l'archive, créateur, heure d'exportation, plage source, classe d'emplacement de stockage, autorisations d'accès, événements de transfert, résultats de vérification et approbation de la destruction. Si vous remettez un paquet à un enquêteur via un système de partage de fichiers, enregistrez l'empreinte du paquet avant et après le transfert. L'intérêt apparaît lorsque l'incident devient délicat. Un ingénieur peut vérifier si un agent a appelé un endpoint de production sans recevoir le jeton de production. Un responsable de la sécurité peut vérifier la chaîne sans accès Touch ID au coffre. Un responsable peut recevoir un compte rendu lisible des événements sans recevoir les corps de requête bruts. Chacun obtient la plus petite quantité d'informations et d'autorité nécessaire à son travail. ## Rendez l'archive banale avant d'en avoir besoin La meilleure sauvegarde de preuves est celle que votre équipe peut créer et vérifier alors que rien ne brûle. Elle possède une structure de paquet fixe, une règle de censure explicite, un point de contrôle indépendant et un test de restauration qui ne dépend pas du coffre actif. Effectuez un exercice avec une copie volontairement endommagée. Modifiez un octet dans une entrée, supprimez un enregistrement intermédiaire et changez le nombre indiqué dans le manifeste. Votre vérificateur doit échouer dans chaque cas d'une manière compréhensible par un intervenant fatigué. Faites ensuite passer la copie intacte par le même processus et confirmez que le paquet de preuves répond à ces questions : qui a autorisé l'action, que s'est-il passé et la séquence est-elle restée intacte ? Conservez la récupération des identifiants ailleurs. Lorsqu'un incident vous oblige à préserver l'historique, l'archive doit faciliter l'enquête sans créer discrètement un nouvel endroit permettant d'accéder à la production.