Journal d'audit

Le journal d'audit répond à la question « qui a fait quoi » sur votre instance. Il est écrit par votre instance et consulté dans les réglages. Cette page décrit ce qui y entre, ce qui n'y entre pas, et sa durée de conservation.

Ce qui est journalisé

L'instance enregistre chaque requête de modification (POST, PUT, PATCH, DELETE) qui aboutit, ainsi que chaque requête refusée pour défaut d'authentification ou de droits (HTTP 401 et 403). Une requête refusée pour son contenu (autre erreur 4xx) n'est pas une action et n'est pas enregistrée ; une requête qui a échoué côté serveur (5xx) l'est, car elle peut avoir été appliquée en partie.

Chaque entrée contient :

Champ	Contenu
Heure	Horodatage de la requête
Utilisateur	L'identifiant de l'utilisateur authentifié ; vide pour un appel non authentifié
Méthode et chemin	Par exemple POST /scan/trigger ; le chemin est tronqué à 300 caractères
Statut	Le code HTTP de la réponse
IP	L'adresse du client, telle que vue par le point d'entrée de l'instance ; un en-tête d'adresse forgé par le client n'est pas cru
Agent utilisateur	Tronqué à 200 caractères

Le corps des requêtes n'est jamais conservé : il peut contenir des identifiants. Les requêtes internes de l'instance elle-même et les sondes de supervision sont exclues.

Une entrée survit à la suppression de son auteur. L'adresse électronique affichée est alors vide et la colonne indique « système / non authentifié ».

Où le consulter

Ouvrez « Paramètres », onglet « Utilisateurs & Accès », sous-onglet « Audit ». La carte « Journal d'audit » porte la description : « Qui a fait quoi : chaque requête de modification avec son auteur, le chemin, le résultat et l'IP. Conservé un an. »

• La lecture demande la permission read:users.
• Le tableau présente les colonnes « Heure », « Utilisateur », « Action », « Statut » et « IP », 50 entrées par page, de la plus récente à la plus ancienne.
• Le champ « Filtrer par email, chemin ou méthode… » cherche une sous-chaîne dans l'adresse de l'auteur, le chemin ou la méthode.
• Si le journal ne peut pas être lu, la page affiche une erreur plutôt qu'un tableau vide : « Le journal d'audit n'a pas pu être lu (HTTP …). Rien n'est affiché plutôt qu'un journal vide. »

Il n'existe pas d'export ; le journal se lit dans l'application.

Conservation

Les entrées sont conservées 365 jours. La purge a lieu une fois par jour, indépendamment de la rétention des constats : changer la « Période de rétention » des constats ne change pas la durée du journal, et aucun réglage de l'interface ne la modifie.

Limites

• Une partie des actions de l'interface n'y figure pas : la création, la modification et la suppression des rôles et de leurs périmètres, les canaux et règles de notification, les règles personnalisées, le changement d'état d'un constat, les commentaires, les dossiers, les interrupteurs des référentiels. La description de la carte, « chaque requête de modification », est donc à lire avec cette réserve.
• Pour un compte cloud créé ou modifié dans l'interface, le journal enregistre les tests ou synchronisations, pas l'enregistrement du compte en tant que tel.
• L'entrée dit quelle route a été appelée, pas ce qui a changé : ni l'objet visé ni les valeurs avant et après ne sont conservés.
• Les lectures ne sont pas journalisées : consulter un constat, un secret masqué ou l'inventaire ne laisse aucune trace.
• Les événements d'authentification unique (SAML, OIDC) sont enregistrés à part, sans écran de consultation.
• Si l'écriture dans le journal échoue, la requête est tout de même servie ; l'échec n'est visible que dans les journaux techniques de l'instance, auxquels vous n'avez pas accès.
• Les entrées sont conservées dans la base de votre instance et comprises dans ses sauvegardes ; elles ne sont pas envoyées vers un système externe.