Journal d'audit

Ce que contient une entrée

Une entrée nomme l'acteur par type et id (un membre de l'équipe, un service ou l'un de vos utilisateurs), l'action, la ressource touchée, l'heure de validation et l'id de la requête qui l'a provoquée. Elle enregistre qu'un changement a eu lieu. Elle ne contient pas les valeurs avant et après.

Écrite avec le changement

Chaque entrée est écrite dans la même transaction de base de données que le changement qu'elle décrit : aucun des deux ne peut donc exister sans l'autre. Un changement qui n'émet aucun événement propre obtient quand même une entrée, nommée d'après l'action appelée.

Le lire dans la console

L'écran Journal d'audit se trouve sous Accès, avec des filtres pour l'action, le type de ressource, l'id de ressource, l'acteur et une plage de dates. Il faut la permission audit:read pour le lire. Parmi les deux rôles prêts à l'emploi, Administrateur de l'espace de travail la détient et Administrateur du projet ne la détient pas.

Le journal couvre les événements d'un projet et ceux de l'espace de travail lui-même, comme les membres ajoutés et retirés. Pour quelqu'un situé dans une organisation, il montre cette organisation et celles qui sont en dessous.

Ce que vous y trouverez

Les clés API révoquées y sont enregistrées, de même qu'un enregistrement qui change de propriétaire, un export qui inclut des hachages de mots de passe et les changements faits par l'assistant IA, attribués à la personne pour qui il agit. Chaque accès de l'assistance y est aussi consigné : demande, approbation et refus.

Conservé 90 jours

Le journal d'événements derrière le journal d'audit sert une fenêtre de 90 jours sur tous les forfaits. Pour un historique plus long d'un projet, lisez le journal en avançant avec l'API Event Log, avec une clé secrète qui détient events:list.project, et conservez-le vous-même. Un curseur de plus de 90 jours est refusé avec une erreur qui indique où reprendre. Une clé publique ou le jeton d'un utilisateur connecté ne peut pas lire le journal.