Audit des inventaires d'assets

L'écran /inventaires — Débug → Inventaires — liste chaque exécution d'un connecteur d'assets, toutes communautés confondues, et ouvre chacune sur ce qu'elle a construit et posté : tous ses items, dans l'ordre d'envoi, ceux-là mêmes que le point d'entrée Sekoia a reçus. Il est aux assets OCSF ce que les envois sont aux journaux.

L'onglet Assets d'une communauté montre ses 20 dernières exécutions. Chaque ligne porte un lien Auditer, et Toutes les exécutions de cette communauté, dans Débug → Inventaires ouvre cet écran filtré sur elle.

Conservé, pas reconstruit

L'audit montre ce qui est parti, pas ce qui partirait. Chaque exécution garde les items qu'elle a construits et postés — des items OCSF pour un connecteur, des requêtes {agentId, body} pour la conformité et l'inventaire logiciel de l'agent Sekoia — au moment où elle se termine. Les reconstruire après coup décrirait le passé avec les réglages du présent : un rafraîchissement NVD, une population ou un archétype modifiés depuis changeraient le résultat, et l'audit contredirait ce que Sekoia a reçu.

Aucun secret n'est gardé. La clé d'API de la communauté voyage dans l'en-tête Authorization, la clé d'intake de l'agent Sekoia dans l'en-tête de ses requêtes ; aucune ne fait partie d'un item.

Tous les items, sans plafond. Un audit qui s'arrêterait aux cent premiers items ferait passer un device absent pour un device jamais parti. Un inventaire logiciel pèse quelques mégaoctets par communauté et par jour ; c'est la profondeur de conservation qui le borne.

Conservé 24 heures

Les items d'une exécution sont conservés 24 heures après sa fin — le contrat des messages de /envois, appliqué de la même façon :

• le seuil s'applique à la lecture : un item passé ses 24 heures n'est jamais montré, même si le balayage n'a pas tourné ;
• le balayage ne fait que récupérer de l'espace — il vide les items et garde l'exécution : son statut, ses compteurs et son motif restent au relevé.

Avec l'inventaire quotidien, l'exécution du jour reste auditable jusqu'à la suivante, tant que la communauté tourne. La profondeur part de la fin de l'exécution, pas de son début : une exécution est relevée dès sa mise en file, et celle qui y aurait attendu verrait sinon ses items naître périmés.

Le rapport de construction d'une exécution — ce que la construction a laissé de côté — reste avec elle, sans profondeur : il explique les compteurs.

La liste

Colonne	Ce qu'elle dit
Communauté	La communauté de l'exécution — un lien vers son onglet Assets
Format	Le connecteur, sa catégorie, et si l'exécution était quotidienne ou manuelle
Jour	Le jour local de la communauté
Statut	En file, Envoi en cours, Envoyé, Échec ou Écarté — et pourquoi, s'il échoue
Items envoyés	Acceptés sur construits
Requêtes	Des hôtes regroupés pour le logiciel (dix pour un connecteur neuf), des lots de 1 000 pour les autres, une par device pour l'agent Sekoia
Terminée	Quand elle s'est terminée, avec le statut HTTP et la durée — pendant l'envoi, quand elle a démarré

Les filtres — Communauté, Format, Statut — et la page vivent dans l'URL : l'écran se partage, le retour arrière fonctionne, et tout marche sans JavaScript. La page se met à jour seule à chaque exécution de chaque communauté — et, pendant qu'une exécution part, à mesure qu'elle avance.

Une exécution

Auditer ouvre trois cartes — quatre quand Sekoia a refusé des lots :

• Relevé : son statut et son motif, les items acceptés sur construits, les requêtes, l'Espacement joué entre deux d'entre elles — le délai de l'agent de la communauté pour l'agent Sekoia, un tiret pour une exécution qui n'a rien envoyé —, pour un inventaire logiciel les Hôtes par requête regroupés, sa fin. Les items sont rangés dans leurs lots par ce regroupement, celui que l'exécution a joué, jamais par le réglage d'aujourd'hui ;
• Lots refusés : chaque lot que Sekoia n'a pas accepté, dans l'ordre d'envoi — son rang, les hôtes qu'il portait pour un inventaire logiciel, son nombre d'items. Chaque hôte mène à ses items, par la recherche sur son identifiant d'agent, qui n'apparaît que dans les items de cet hôte ; un lot de 1 000 mène à la page où il commence ;
• Ce que la construction a laissé de côté : les mêmes listes nommées que l'aperçu — entités sans identité exploitable, systèmes sans produit connu, entités sans archétype, binaires non classés, postes non Windows. Absente quand l'exécution s'est abstenue avant de rien construire ;
• Items : les items conservés, cinquante par page.

Chaque item se déplie sur son JSON tel qu'il est parti. Sa ligne de résumé donne :

• sa position dans l'envoi ;
• le lot qui l'a porté — une requête pour l'agent Sekoia ;
• ce qu'il nomme : le hostname d'un device, l'adresse d'un utilisateur, la CVE et le hostname d'une vulnérabilité, l'application et le hostname d'un logiciel, le poste et l'agent d'une requête de l'agent Sekoia ;
• son issue, déduite du relevé :

Issue	Ce qu'elle veut dire
Accepté	L'exécution est partie, ou Sekoia a accepté le lot de l'item
Lot non accepté	Sekoia a refusé le lot de l'item — ou ce lot a arrêté l'exécution, panne réseau comprise
Non envoyé	Après un arrêt : il n'est jamais parti
Issue inconnue	Une exécution en échec relevée avant que les lots refusés ne soient gardés : rien n'est deviné

Un lot refusé pour son propre contenu n'arrête pas l'exécution. Des items que Sekoia rejette, ou un lot trop lourd, ne disent rien du lot suivant : les lots d'après partent quand même, et l'exécution garde le rang de chaque lot refusé. Ce qui vaut pour tous les lots l'arrête — une clé refusée, un connecteur introuvable, un point d'entrée faux, une API qui reste indisponible —, et les lots d'après l'arrêt ne sont jamais partis. Les envois de l'agent Sekoia ne s'arrêtent que sur une clé refusée.

Rechercher dans les items cherche dans l'item entier, sans casse : un hostname, un UUID, une CVE, un chemin. Un chemin Windows se tape avec des antislashs simples, tel qu'on le lit — pas tel que JSON l'échappe. Une recherche ne renumérote rien : un item garde sa position, donc son lot.

Télécharger le JSON rend tous les items conservés de l'exécution, dans l'ordre d'envoi — à confronter au modèle avec lequel Sekoia valide, ou à l'inventaire de la veille. Une exécution expirée, ou qui n'a rien gardé, répond par un message plutôt que par un fichier vide, qui passerait pour un inventaire vide.

Au-dessus des items, une phrase dit ce qui reste :

Phrase	Quand
Items conservés : n, dans l'ordre d'envoi.	L'exécution s'est terminée il y a moins de 24 heures
Ces items ne sont plus conservés : …	Elle s'est terminée il y a plus de 24 heures
Cette exécution n'a rien gardé : …	Elle s'est abstenue, a échoué avant de construire, tourne encore, ou précède l'audit

Ce que l'écran ne fait pas

• Une exécution antérieure à cet écran, ou expirée, n'a rien à montrer : rien n'est reconstruit.
• Les items partent avec leur communauté : supprimer une communauté supprime ses exécutions, comme avant.
• L'aperçu ne change pas : il montre toujours ce que la prochaine exécution enverrait, trois items au plus.