Lire les actes d'une session dans l'onglet Audit

Ce que le journal des sessions contient, comment l'onglet Audit de la console présente les actes d'une session, comment révoquer une session, et ce que le journal permet d'établir.

Un agent a travaillé dans une session et vous voulez relire ce qu’il a fait : les fichiers lus, les fichiers modifiés, les commandes lancées, les décisions du développeur. Cette page décrit ce que le journal contient, comment l’onglet Audit de la console présente les actes d’une session, comment révoquer une session, et ce que le journal permet d’établir.

Ce que le journal contient

Les journaux sont tenus par les services de la passerelle, et non par le poste. Ils ont cinq propriétés (livre blanc sécurité V3, section 7.1) :

ils sont en ajout seul, et une suppression est elle-même journalisée ;
chaque entrée contient le condensat de la précédente : une modification rompt la chaîne et se détecte, y compris si elle vient d’un administrateur ;
chaque événement est horodaté et porte l’identité issue de votre annuaire, le projet, le dépôt, le modèle et le résultat ;
ils s’exportent vers votre SIEM dans un format structuré, selon un schéma d’événements documenté ;
le contenu en est absent par défaut : ni les requêtes ni le code n’y figurent, et vous pouvez activer leur conservation, avec un chiffrement et une durée de rétention distincts.

Sept catégories d’événements sont toujours journalisées (livre blanc sécurité V3, section 7.2) :

Catégorie	Ce qui est journalisé
Authentification et sessions	ouverture, fermeture, échec, révocation
Consigne du développeur	événement, utilisateur, projet ; le texte sur option
Fichiers lus et modifiés	liste des fichiers concernés ; le contenu sur option
Actions proposées par l’agent	type d’action, outil, commande, modèle utilisé
Décisions humaines	validation, refus, arrêt, avec horodatage et identité
Exécutions dans le bac à sable	commande, code de retour, durée ; la sortie sur option
Changements de politique	ancienne et nouvelle valeur, auteur

Un secret détecté n’est pas journalisé en clair.

L’onglet Audit présente les actes des sessions : les actions de l’agent, la décision prise pour chacune et son résultat. Pour chaque acte, il montre l’outil, la cible (un chemin ou une commande, coupée à 160 caractères), la décision, qui l’a prise, le résultat, le motif (300 caractères au plus) et l’instant. Il ne montre ni le contenu d’un fichier, ni la conversation.

Ouvrir l’onglet

Ouvrez l’onglet Audit de la console. La lecture des actes exige le rôle d’auditeur, qui lit les journaux et les politiques en lecture seule (livre blanc sécurité V3, section 6.1). L’administrateur y voit la liste des sessions et peut en révoquer une, sans le détail de leurs actes (voir Révoquer une session) ; un autre rôle voit l’onglet et le message d’erreur décrit plus bas. Voir Ouvrir la console d’administration.

L’écran a deux panneaux : Sessions à gauche, la chronologie de la session choisie à droite. Il se recharge toutes les 10 secondes ; la ligne « Updated HH:MM:SS · refreshes every 10 s » donne l’heure de la dernière lecture, et le bouton Refresh now relit sans attendre. La session la plus récente s’ouvre d’elle-même ; une session que vous avez choisie reste choisie d’un rechargement à l’autre.

Sans aucun acte reçu, le panneau des sessions affiche « No act has been remitted to this gateway yet. ». Si la console ne peut pas lire les actes, la cause est écrite au-dessus des panneaux, après « Could not read the acts: ».

Choisir une session

Le panneau Sessions liste 100 sessions au plus, de la dernière activité à la plus ancienne. Il n’a pas de filtre : vous lisez une session à la fois, en cliquant sur sa carte.

Chaque carte porte :

le jour (Today, Yesterday, ou la date en abrégé) et les heures du premier et du dernier acte, puis l’ancienneté du dernier (« just now », « 12 min ago », « 3 h ago », « 2 d ago ») ;
la personne à qui les actes sont attribués : l’identité issue de votre annuaire (livre blanc sécurité V3, section 7.1) ;
la surface (« terminal » ou « editor ») et la durée de la session ;
le nombre d’actes reçus pour la session, cadre de session compris, et, s’il y en a, le nombre d’actes refusés et le nombre d’échecs ;
les identifiants de la session et du poste, abrégés à huit caractères. L’identifiant complet s’affiche au survol.

Lire la chronologie

Le panneau de droite est titré par la personne, le jour et les heures de la session. Son sous-titre nomme la surface et répète les deux identifiants.

En tête, quatre chiffres : actions (les appels d’outils, sans le cadre de session), approved by the developer, refused, failed.

Sous les chiffres, la carte repliable How this session was set up décrit le cadre de la session : Mode, le mode de la session ; Permission rules, le nombre de règles de la politique en vigueur ; Tools available, le nombre d’outils que la politique laissait à l’agent, avec leur liste.

La liste des actes se lit du plus récent au plus ancien : l’acte que l’agent vient de prendre est en haut, le premier de la session en bas. Chaque ligne porte l’heure à la seconde, l’action en toutes lettres, la décision, le résultat, puis la cible. Le nom réel de l’outil s’affiche au survol de l’action. Quand un motif existe, il est écrit sous la ligne, après « Why: ».

Action affichée	Outils
Read a file	`Read`
Wrote a file	`Write`
Edited a file	`Edit`, `MultiEdit`
Ran a command	`Bash`
Switched branch	`SwitchBranch`
Listed a directory	`List`, `LS`
Searched the code	`Search`, `Grep`, `Glob`
Delegated to a sub-agent	`Task`
le nom de l’outil	tout autre outil

La décision et le résultat sont des étiquettes. Une bordure de couleur distingue les lignes refusées et les lignes en échec des lignes accordées et réussies.

Étiquette	Ce qu’elle dit
auto-approved	la politique a laissé passer sans demander : action libre
approved by the developer	le développeur a été consulté et a dit oui
refused by the developer	le développeur a été consulté et a dit non ; rien n’a tourné
refused by the rules	la politique a refusé sans demander
done	l’outil a tourné et a réussi
failed	l’outil a tourné et n’a pas réussi ; le motif est sous la ligne
not run	l’outil n’a pas tourné
stopped by the revocation	la commande tournait quand la session a été révoquée, et a été arrêtée

Le bouton i en tête de la chronologie, décrit comme « What the labels mean », ouvre une légende de ces étiquettes.

Révoquer une session

Révoquer une session arrête l’agent dans cette session, et dans celle-là seulement. La personne garde ses autres sessions et peut en ouvrir une nouvelle. Une révocation est définitive : une session révoquée ne peut être ni reprise, ni dupliquée, ni rétablie.

Depuis l’onglet

Le bouton Revoke this session est en tête de la chronologie de la session choisie, à côté d’un champ de motif. Le motif est facultatif ; il est conservé pour l’audit et n’est pas montré au développeur. Sans motif, la révocation porte « revoked from the console ». Le bouton ouvre une confirmation qui décrit l’effet ; Cancel n’écrit rien.

Le bouton n’est affiché que si la personne connectée peut révoquer, et seulement sur une session encore en vigueur. La révocation exige la permission sessions:revoquer, que porte l’administrateur ; l’auditeur, qui lit les actes, voit l’état des sessions et n’a pas le bouton (livre blanc sécurité V3, sections 4.5 et 6.1).

L’administrateur ouvre le même onglet. Il y voit le panneau Sessions : la personne, le poste, les heures, et l’étiquette revoked le cas échéant, sans le nombre d’actes. Le panneau de droite porte le bouton de révocation et la phrase « As an administrator you see which sessions exist, and you can revoke one. What the agent did in a session is read by the auditor. ». La chronologie des actes ne lui est pas servie : la console lit pour lui GET /api/agent-sessions, qui rend les sessions et aucun acte.

Une fois la session révoquée :

sa carte porte l’étiquette revoked dans le panneau Sessions ;
sa chronologie porte une ligne « Session revoked by … », à sa place dans le temps, avec l’heure, l’auteur et le motif après « Why: » ;
les sous-agents de la session sont révoqués avec elle ; leur chronologie le dit et nomme la session révoquée ;
l’acte figure au journal des actes d’administration, avec son auteur et la session visée.

Révoquer une session déjà révoquée ne change rien : l’acte d’origine est conservé.

Par la commande d’exploitation

La passerelle porte une commande qui révoque une session par son identifiant complet, celui que l’onglet affiche au survol. L’auteur est obligatoire ; le motif est facultatif. Elle révoque aussi une session dont aucun acte n’a encore été remis, que l’onglet ne liste pas.

node dist/identity/revokeAgentSession.js <session> <auteur> "motif"

Ce que voit le développeur

Le terminal demande à la passerelle l’état de sa session toutes les 5 secondes. Quand la session est révoquée :

le tour en cours est interrompu, et une commande déjà lancée est arrêtée avec les processus qu’elle a lancés : un signal d’arrêt, puis un arrêt forcé après 3 secondes. Elle est journalisée en échec, avec pour motif son arrêt par la révocation, et l’onglet l’affiche stopped by the revocation ;
le bac à sable de la session est détruit, et les écritures non validées sont rejetées (livre blanc sécurité V3, section 4.5) ;
aucune action demandée ensuite par l’agent n’est exécutée, et le développeur n’est pas sollicité pour l’autoriser ;
le terminal affiche une fois : « This session was revoked by your organization’s administration at HH:MM. The agent will not act in it any more. Your other sessions are not affected: start a new one with lemni. », suivi de l’identifiant de la session et de l’invitation à s’adresser à l’administrateur ;
si le développeur écrit de nouveau dans cette session, son message n’est pas envoyé à l’agent et le terminal le rappelle en une ligne : « This session is revoked since HH:MM: your message was not sent to the agent. Start a new session with lemni. » ;
en mode non interactif, ce texte part sur la sortie d’erreur et le programme sort avec le code 1 ;
reprendre ou dupliquer cette session est refusé avec le même texte. Dupliquer une session est aussi refusé quand le poste ne peut pas demander son état à la passerelle ;
la révocation est inscrite au journal.

La passerelle refuse aussi les appels au modèle faits au nom d’une session révoquée, par une réponse 403 qui porte le code agent-session-revoked.

Quand le poste ne joint pas la passerelle

Un poste qui n’obtient plus de réponse de la passerelle continue pendant 5 minutes à compter de la dernière réponse reçue. Au-delà, l’agent cesse d’agir et le terminal l’écrit : « The agent stopped acting: this workstation could not verify … This is not a revocation, and nothing is lost: the agent acts again as soon as the gateway answers. » Dès que la passerelle répond, l’agent agit de nouveau. Ce n’est pas une révocation : rien ne s’inscrit dans l’onglet.

La passerelle se met à jour avant les postes. Un terminal qui interroge une passerelle plus ancienne, sans la route d’état des sessions, n’obtient pas de réponse et cesse d’agir au bout des mêmes 5 minutes.

Ce que la révocation ne couvre pas

Révoquer une session ne coupe ni la personne ni ses autres sessions. La révocation d’un utilisateur est un acte distinct, fait lui aussi depuis la console (livre blanc sécurité V3, section 4.5).

Ce que le journal permet d’établir

Le journal permet de reconstituer une session : qui s’est authentifié, quelle consigne a été donnée, quels fichiers ont été lus, ce que l’agent a proposé, ce que le développeur a décidé, ce qui s’est exécuté et quelle politique était en vigueur. Il établit quelle proposition a été acceptée, et par qui (livre blanc sécurité V3, section 7.2).

L’onglet Audit montre les actes de l’agent et les décisions prises. Trois choses se lisent ailleurs :

l’intégrité du journal. Elle repose sur l’enchaînement des condensats : chaque entrée scelle la précédente (livre blanc sécurité V3, section 7.1) ;
les événements d’authentification et les changements de politique. Ils sont journalisés avec leur auteur et se lisent dans les journaux exportés (livre blanc sécurité V3, section 7.2) ;
l’exploitation dans la durée. Les événements exportés alimentent les règles de votre centre opérationnel de sécurité, dans votre SIEM (livre blanc sécurité V3, section 7.3).

La console lit les actes par GET /api/audit/agent-acts, qui rend les sessions, et GET /api/audit/agent-acts?session=<id>, qui rend les actes d’une session dans l’ordre croissant des rangs. L’inversion du plus récent au plus ancien est faite par l’écran ; le rang reste l’ordre de référence. Les droits de ces routes sont dans Référence : la console d’administration.