Le journal d'audit

Cet écran rassemble en une seule liste ce qui s'est passé sur votre compte : les actions faites depuis la console, les scans de tags et les appels de l'API partenaire. Il répond à la question « qui a fait quoi, quand, et depuis où ». On l'ouvre pour reconstituer une suite d'événements, ou pour vérifier ce qu'un compte a fait sur une période.

#Ce que l'écran affiche

L'en-tête « Journal d'audit sécurité », sous-titré « Historique complet des actions de sécurité et événements système ».

Une carte de filtres à quatre champs : type d'événement, date de début, date de fin, acteur.

Le nombre total de résultats au-dessus du tableau, suivi de « événement(s) ».

Un tableau à six colonnes : Date, Type, Acteur, Action, Détails, IP. Chaque type porte sa pastille de couleur : Authentification en turquoise, Mint en vert, Burn en rouge, Transfert en ambre, Scan NFC en gris, Appel API en contour.

Une barre de pagination, « Page {page} sur {totalPages} », avec les boutons « Précédent » et « Suivant ».

#Ce que vous pouvez y faire

Filtrer par type, parmi sept choix : Tous les types, Authentification, Mint, Burn, Transfert, Scan NFC, Appel API. « Tous les types » n'applique aucun filtre.

Restreindre à une plage de dates avec les deux sélecteurs.

Chercher un acteur par son adresse de courriel, l'invite du champ étant « Rechercher par email... ». Les espaces autour de votre saisie sont retirés.

Naviguer de page en page. Les boutons se désactivent à la première et à la dernière page. Changer un filtre vous ramène à la page 1.

#Les connexions

Chaque connexion à un compte laisse une ligne, qu'elle soit acceptée ou refusée, quelle que soit la méthode : mot de passe, Google, Apple, code de l'application d'authentification ou code de secours. L'action vaut login_success pour une connexion acceptée et login_failure pour une connexion refusée. Les deux sont classées sous le type Authentification. La colonne Acteur porte l'adresse du compte visé, la colonne Détails son numéro, précédé de user.

Ni le mot de passe ni le code tapés ne sont gardés, et l'adresse tapée n'est jamais recopiée telle quelle. Une tentative qui ne désigne aucun compte, une adresse inconnue par exemple, est notée unknown et n'est rattachée à aucun compte : un administrateur de marque ne la voit donc pas.

Trois cas ne laissent aucune ligne. L'étape où la connexion attend encore votre code : elle n'est notée qu'une fois le code accepté. Le renouvellement automatique d'une session déjà ouverte. Une tentative refusée parce qu'il y en a eu trop en peu de temps.

#Ce qui conditionne l'accès

Il faut être connecté et administrateur. Sinon la console remplace la page par « Non autorisé. Merci de vous connecter sur www.sealtrust.io (nouvel onglet). » et un bouton de connexion. Aucune fonction de forfait n'est exigée.

Cet écran n'est pas dans le menu latéral : on y arrive par la carte-raccourci « Rapports d'audit » du tableau de bord sécurité.

Un administrateur de marque ne voit que trois choses : les actions des utilisateurs qui partagent une de ses marques, les scans de ses produits et les appels de ses clefs d'API.

Un export fait exception : il s'affiche chez les administrateurs des marques dont les données sont sorties, quel que soit le compte qui l'a lancé. Un compte rattaché aux marques A et B qui exporte les données de B n'apparaît donc que chez B.

Quand un superadmin exporte sans choisir de marque, tout dépend de l'export. Le catalogue des produits, le classeur des modèles, le dossier de preuves de toutes les marques et les fichiers du registre européen nomment la marque de chaque pièce ou de chaque modèle qu'ils contiennent : l'export apparaît chez chacune de ces marques. Un rapport, l'export de la distribution, le journal NFC, le journal d'audit et la liste des signataires ne nomment aucune marque : ils n'apparaissent chez aucune marque.

#Ce que l'écran refuse

La liste se pagine par 25 événements. Cette valeur est fixée par l'écran, vous ne pouvez pas la changer. Les événements sont triés par date décroissante avant d'être découpés en pages.

Les adresses IP ne sont jamais affichées en entier. Une adresse en notation pointée garde ses deux premiers nombres, suivis de trois astérisques. Toute autre valeur, une adresse IPv6 comprise, est remplacée entièrement par trois astérisques, et une adresse absente affiche un tiret.

Le type d'un événement d'administration est déduit du texte de l'action : un libellé contenant login devient Authentification, mint devient Mint, burn devient Burn, transfer devient Transfert, et tout le reste tombe sur Authentification.

Un export fait depuis la console (un rapport, le catalogue, une archive de QR, une archive de réversibilité, un dossier de preuves…) y apparaît sous une action qui commence par export_, par exemple export_report. Il s'affiche donc avec le type Authentification, comme toute action qui ne contient ni login, ni mint, ni burn, ni transfer. Le filtre Authentification, lui, ne garde que les actions qui contiennent login : pour voir les exports, laissez le filtre de type sur tous les types.

Pour un scan NFC, l'acteur affiché est l'auteur du scan, à défaut l'adresse de portefeuille, à défaut la mention anonymous. Pour un appel d'API, c'est le nom de la clef utilisée, ou la mention key# suivie de l'identifiant de la clef quand celle-ci n'a pas de nom, les détails reprenant le code de statut de la réponse.

En cas d'échec, la page affiche « Failed to load audit events » dans un bandeau rouge. Sans événement correspondant, elle affiche « Aucun événement » et « Aucun événement d'audit ne correspond aux filtres sélectionnés ».