Journal d’audit
Vérifié avec Cortex le 2 octobre 2026
Le journal d’audit garde une trace de ce que Cortex fait : qui a agi, quelle action, vers quelle destination, avec quel profil DLP et quels types d’entités ont été caviardés. Il ne contient ni le contenu des conversations ni les valeurs caviardées : la console le rappelle sous le tableau, et la fenêtre de détail indique « Contenu de la requête : non consigné par conception ». Cette page explique comment le lire, l’exporter et vérifier son intégrité. L’accès est réservé aux rôles « Auditeur » et « Administrateur » (voir Utilisateurs et accès).
Ce qui est enregistré
Chaque entrée porte un numéro de séquence, un horodatage, l’utilisateur à l’origine, l’action, la destination, le profil DLP appliqué et, pour les requêtes, les types d’entités caviardées avec leur nombre (sous la forme « catégorie × nombre »). Les actions couvrent les conversations et l’analyse DLP, mais aussi les changements de configuration : destinations, règles DLP, utilisateurs et rôles, rétention, base de connaissances, recherche web, connexions.
L’écriture au journal fait partie de la même transaction que la requête : si l’entrée ne peut pas être écrite, la requête échoue. Une requête qui ne peut pas être auditée n’a pas lieu. Quelques entrées font exception, parce qu’elles décrivent un refus ou un échec qui annule la requête elle-même : requête bloquée (DLP, budget ou quota), DLP indisponible, erreur de clavardage, recherche web bloquée ou indisponible. Elles sont écrites dans leur propre transaction pour survivre à l’annulation. Si cette écriture échoue, l’erreur d’origine est quand même renvoyée et un avertissement sans contenu est journalisé. Le repli d’acheminement (bascule vers une autre destination) est un cas à part : il décrit une requête encore en cours, et son entrée est écrite de la même façon, dans sa propre transaction, sans interrompre la requête si l’écriture échoue.
La base de données interdit la modification et la suppression des entrées pour l’identité que la passerelle utilise. Aucune purge de rétention ne touche le journal (voir Rétention et effacement). Chaque locataire ne voit que son propre journal.
Lire le journal
Ouvrez « Journal d'audit » dans la console. Le sous-titre affiche « Lecture seule » : le rôle « Auditeur » peut consulter, filtrer, exporter et vérifier le journal, sans pouvoir le modifier. Quatre cartes résument l’état : « Événements (7 j) » (avec le nombre des dernières 24 h), « Intégrité de la chaîne », « Requêtes bloquées » (7 derniers jours) et « Conservation » (la durée de la politique de rétention des conversations, ou « aucune politique définie »).
Les entrées les plus récentes viennent en premier, 50 à la fois; « Charger plus » affiche les suivantes. Les colonnes sont « Nº », « Horodatage », « Utilisateur / action », « Destination » (avec le profil DLP) et « Entités ». Une requête refusée par le DLP porte le repère « bloquée ». Le chevron au bout d’une ligne ouvre « Détail de l'événement », qui répète ces champs; « Fermer » le ferme.
- Dans la barre de filtres, choisissez une « Action » (« Toutes les actions » par défaut), une « Destination », ou une période avec « Du » et « Au ». Le champ « Utilisateur » accepte un nom, un courriel ou un identifiant UUID.
- Cliquez sur « Filtrer ». Tant que vous ne l’avez pas fait, la liste et l’exportation gardent les filtres précédents.
Le lien « Historique » d’une ligne de la liste des utilisateurs ouvre ce journal avec le filtre « Utilisateur » prérempli. Ce lien se trouve dans le menu « … » de la ligne. Depuis l’onglet « Historique » de la page « Rétention », « Tout voir dans Audit » ouvre le journal complet, sans filtre.
Exporter
Le bouton « Exporter CSV » se trouve en haut de la page. Il est inactif tant que la liste est vide. L’exportation applique les filtres de la dernière fois que vous avez cliqué sur « Filtrer » et couvre tout le résultat filtré, pas seulement les lignes affichées. Le fichier audit-AAAA-MM-JJ.csv contient les colonnes id, seq, actor_user_id, action, destination_id, policy_applied, redacted_types et occurred_at. Les colonnes d’empreintes de la chaîne n’y figurent pas : l’exportation ne sert pas à vérifier l’intégrité.
Vérifier l’intégrité
Chaque entrée est liée à la précédente par une empreinte calculée avec une clé secrète propre au locataire (HMAC-SHA256, clé chiffrée par la KEK). Modifier, retirer ou réordonner une entrée casse la chaîne : l’altération est détectable.
Dans la console, cliquez sur « Vérifier la chaîne », sous les cartes. Le résultat « Chaîne intègre — N entrées vérifiées. » ou « Rupture de chaîne détectée à la séquence N. » s’affiche, et la carte « Intégrité de la chaîne » passe à « Intègre » ou « Rompue ». Elle affiche « non vérifiée » tant que vous n’avez pas lancé la vérification depuis le chargement de la page : l’état n’est pas conservé et revient à zéro à chaque ouverture ou changement de page.
Pour vérifier en dehors de la console, ou pour planifier la vérification (cron), lancez depuis la copie du dépôt, avec la KEK de la passerelle et l’identité propriétaire de la base (ces commandes ne lisent pas .env) :
MIGRATION_DATABASE_URL='postgres://cortex_owner:<mot de passe>@localhost:5432/cortex' \
KMS_LOCAL_KEK='<la KEK de la passerelle>' \
pnpm --filter gateway audit:verify -- --slug cortex
La commande affiche une ligne par locataire (ok, le nombre d’entrées et l’empreinte de la dernière) et se termine avec un code d’erreur s’il y a une rupture. Sans --slug, elle vérifie tous les locataires. Conserver ces empreintes dans vos rapports archivés fournit un point de comparaison manuel.