Journal d'audit

Un journal chaîné par hash

Le journal d'audit n'est pas une simple liste d'événements que l'on pourrait éditer ligne à ligne. Chaque entrée intègre le hash de l'entrée qui la précède : les enregistrements forment une chaîne, où le maillon N verrouille tout ce qui a été écrit jusqu'à N. Supprimer une entrée au milieu, en modifier le contenu ou en réordonner deux casse la continuité des hachages, et l'anomalie devient visible en recalculant la chaîne.

Cette propriété ne rend pas le journal « immuable » au sens magique du terme — un opérateur disposant d'un accès total au stockage pourrait toujours tenter d'agir dessus. Ce qu'elle garantit, c'est la détectabilité : une altération ne peut pas passer inaperçue, car elle rompt le chaînage. C'est la différence entre un registre que l'on peut trafiquer en silence et un registre où toute manipulation laisse une trace mathématique.

1. 1
   Une action se produitUn membre agit depuis la console : la nature de l'action, l'auteur et l'horodatage sont capturés.
2. 2
   L'entrée est chaînéeL'enregistrement incorpore le hash de l'entrée précédente, puis on calcule son propre hash. Le nouveau maillon dépend de tout l'historique antérieur.
3. 3
   La chaîne se vérifiePour contrôler l'intégrité, on rejoue les hachages de bout en bout : la moindre rupture signale une entrée manquante, modifiée ou déplacée.

Chaque organisation possède sa propre chaîne. Les journaux ne sont pas mélangés entre clients : l'audit hérite du cloisonnement multi-tenant décrit dans /docs/console-roles, et le chaînage d'une organisation ne dit rien de celui d'une autre.

Attribution : qui a fait quoi

Un journal qui enregistre « une règle a été supprimée » sans dire par qui n'a qu'une valeur limitée. Dans VIGIL-MESH, chaque action de console est attribuée : l'entrée porte l'identité du membre qui a agi, l'horodatage, et la nature de l'opération. On peut donc répondre aux questions qui comptent après un incident : qui a révoqué ce device, quand cette règle a-t-elle changé, qui a invité ce nouveau membre.

• L'auteur : le membre de l'organisation qui a déclenché l'action, désigné par son identité dans le workspace, pas par une adresse anonyme.
• L'action : la nature de l'opération (création, modification, révocation, publication, invitation, suppression…) et la ressource concernée.
• L'horodatage : le moment où l'action a été consignée, qui donne à la chaîne son ordre temporel.
• Le contexte : l'organisation à laquelle l'entrée appartient, puisque chaque tenant tient sa propre chaîne d'audit.

L'attribution repose sur les identités du workspace : c'est parce que chaque membre agit sous une identité distincte que le journal peut nommer l'auteur d'une action. Le découpage des rôles — exploitant d'infrastructure, administrateur réseau d'un client, auditeur en lecture seule — est traité dans /docs/console-roles, et l'auditeur en lecture seule est précisément le rôle qui consulte ce journal sans pouvoir agir sur le réseau.

Filtrer et exporter

Un journal utile est un journal que l'on peut interroger. La console permet de filtrer les entrées pour retrouver ce qui compte sans faire défiler des mois d'historique : par auteur, par type d'action, par ressource concernée, par intervalle de temps. On passe ainsi d'un registre brut à une réponse ciblée — « toutes les révocations de devices du mois dernier », « toutes les actions de tel membre sur telle politique ».

Les entrées filtrées peuvent être exportées pour un usage hors de la console : archivage indépendant, revue de conformité, transmission à un tiers, corrélation avec d'autres journaux du système d'information. L'export sort les enregistrements avec les éléments qui les identifient, de sorte que la chaîne exportée reste vérifiable en dehors de l'interface.

Conservation : au moins un an

Un incident ne se découvre pas toujours le jour où il survient. Une révocation contestée, un changement de politique mal compris, une intrusion repérée tardivement : il faut souvent remonter loin dans le temps pour reconstituer ce qui s'est passé. C'est pourquoi le journal d'audit est conservé au moins un an, de sorte que l'historique reste disponible bien au-delà de l'horizon immédiat.

Cette rétention se combine au chaînage : sur toute la fenêtre conservée, l'ordre et l'intégrité des entrées restent vérifiables. On ne garde pas seulement des lignes, on garde une chaîne dont la cohérence peut être recontrôlée. C'est ce qui permet d'utiliser le journal comme élément de preuve lors d'une revue de sécurité, dont le cadre d'ensemble est décrit dans /docs/securite.