Journaux d'audit d'agent : enregistrements de session et d'appel

Les journaux d'audit d'agent échouent lorsqu'ils tentent de répondre à deux questions différentes dans un seul enregistrement. Pendant un incident, vous devez établir à la fois qui détenait l'autorité d'agir et quelle action a réellement atteint le monde extérieur. L'enregistrement de l'exécution ne peut pas remplacer celui de l'appel, et une liste de requêtes ne peut pas expliquer pourquoi le processus avait l'autorisation nécessaire.

Les équipes ne conservent souvent qu'une seule de ces vues, parce qu'elle semble suffisante pendant une démonstration. Puis un agent ouvre un ticket, modifie un paramètre de production ou exécute une commande SSH, et l'enquête se réduit à deviner les heures. C'est évitable. Tenez un journal de session pour l'autorité et le cycle de vie. Tenez un journal d'activité pour chaque action externe tentée. Reliez-les avec un identifiant que ni les humains ni les agents ne peuvent choisir à leur guise.

Un enregistrement d'exécution indique qui détenait l'autorité

Un enregistrement de session doit indiquer si un processus d'agent précis avait l'autorisation d'agir, pendant quelle période et à la suite de quelle décision humaine. C'est l'enregistrement que vous consultez lorsqu'on demande : « Quelle instance d'agent a fait cela et pourquoi l'avons-nous laissée agir ? »

Un enregistrement de session utile commence lorsque le processus demande pour la première fois une autorité, pas lorsqu'un utilisateur ouvre un éditeur et pas lorsqu'un répertoire de projet apparaît. Les noms d'agents sont des éléments de preuve faibles. Deux processus peuvent se présenter sous le même nom, et un binaire malveillant peut emprunter un nom familier. Capturez l'identité du processus connue par l'hôte, son autorité de signature lorsque le système d'exploitation en fournit une, le processus parent lorsque c'est utile, un identifiant de session généré, les heures de début et de fin, ainsi que le résultat de l'autorisation.

L'enregistrement de session doit aussi contenir les événements du cycle de vie. L'approbation est un événement. La révocation est un événement. La fin du processus est un événement. Le verrouillage du coffre-fort d'identifiants, s'il bloque l'activité, est également un événement qu'il vaut la peine de corréler. Sans ces limites, l'enquêteur ne peut pas déterminer si un appel s'est produit pendant une période approuvée ou après un arrêt supposé.

Ne transformez pas l'enregistrement de session en journal intime de chaque réflexion du modèle, ligne de terminal et modification de fichier. Vous créeriez une masse de données sensibles tout en manquant la limite importante : un processus d'agent a reçu l'autorité de demander à une passerelle d'effectuer des actions externes. Capturez clairement les éléments de preuve qui établissent cette limite.

Voici un enregistrement de session simplifié :

{
  "type": "session.authorized",
  "session_id": "ses_7f4c2",
  "observed_at": "2025-04-18T14:03:11Z",
  "process": {
    "pid": 8124,
    "signing_authority": "Example Development Team",
    "parent_pid": 8090
  },
  "decision": "approved",
  "approved_by": "local_operator"
}

L'enregistrement n'a pas besoin du nom d'un employé pour être utile. Sur un poste partagé, local_operator peut être le niveau d'attribution honnête. Prétendre en savoir davantage produit une fiction présentée avec assurance. Si votre environnement peut associer l'approbation à une personne authentifiée, consignez cette association et la manière dont elle a été établie.

Un enregistrement de session ne doit jamais affirmer qu'une exécution entière était sûre. L'approbation accorde une autorité, mais elle ne préapprouve pas tous les effets qu'un processus peut produire. Cette distinction peut sembler pointilleuse jusqu'à ce qu'un agent de programmation garde une session ouverte pendant des heures et effectue des centaines d'appels sous une seule approbation.

Un enregistrement d'appel indique ce qui a atteint le monde extérieur

Un enregistrement d'appel doit décrire une opération tentée et son résultat. C'est l'élément de preuve nécessaire lorsqu'on demande : « L'agent a-t-il envoyé cette requête, vers quelle cible et avec quel résultat ? »

Consignez les tentatives, pas seulement les réussites. Une requête refusée peut montrer qu'un agent cherchait un identifiant. Une requête échouée peut révéler un hôte mal orthographié, un secret expiré ou une commande dangereuse rejetée par le système distant. Une requête annulée peut expliquer pourquoi une session semble s'être arrêtée au milieu d'un déploiement. Les journaux qui ne montrent que les réussites racontent une histoire rassurante, mais incomplète.

Pour une action HTTP, conservez l'identité de la destination, la méthode HTTP, le chemin ou une représentation contrôlée du chemin, la référence de l'identifiant plutôt que sa valeur, l'heure de la requête, l'heure de fin, le résultat, l'identifiant de session et un identifiant d'appel. Pour SSH, conservez l'identité de l'hôte visé, la commande ou une représentation sûre de celle-ci, le résultat de la connexion, le code de sortie distant lorsqu'il est disponible, l'identifiant de session et l'identifiant d'appel.

Vous devez décider avec soin quelles données de requête conserver. Enregistrer par habitude tous les en-têtes et corps complets est une source d'incident en attente. Les en-têtes d'autorisation, les cookies, les URL signées, les jetons d'accès, les données privées de clients et les mots de passe s'y cachent souvent. Un bon enregistrement préserve le sens de l'opération tout en supprimant les secrets. Par exemple, POST /v1/users/123/disable peut suffire à reconstituer une modification administrative. Copier tout le corps JSON pourrait exposer bien plus de données que l'enquête n'en nécessite.

Utilisez l'identité de la cible, pas seulement une chaîne d'URL brute. https://api.example.test et https://api.example.test:443 peuvent désigner la même destination, tandis qu'un hôte ressemblant peut différer d'un seul caractère. Pour SSH, consignez l'identité de l'hôte utilisée pour la vérification lorsque votre système peut l'obtenir. Un nom d'hôte seul ne suffit pas à confirmer que la connexion a atteint la machine attendue.

Cet ensemble montre la séparation :

{
  "type": "call.completed",
  "call_id": "call_b91d",
  "session_id": "ses_7f4c2",
  "observed_at": "2025-04-18T14:09:27Z",
  "channel": "http",
  "operation": "POST",
  "target": "api.example.test/v1/deployments/42/cancel",
  "credential_ref": "deployment-service",
  "authorization": "session_approved",
  "outcome": "completed",
  "response_status": 202
}

L'identifiant de session indique quelle autorité l'appel a utilisée. La cible et le résultat indiquent ce qui s'est produit. Si vous fusionnez ces éléments dans un événement vague comme agent performed task, vous n'aurez correctement enregistré aucune des deux réponses.

L'approbation et l'exécution sont deux faits distincts

Les équipes confondent souvent un événement d'approbation avec la preuve qu'une requête a été exécutée. Ce sont deux faits distincts, et une piste d'audit doit conserver les deux.

Un opérateur peut approuver un nouveau processus d'agent, puis s'absenter. Le processus peut ne faire aucun appel parce que la tâche s'achève localement. Il peut effectuer une requête API échouée ou cinquante requêtes réussies. L'enregistrement d'approbation reste identique dans tous les cas. Seuls les enregistrements d'appels montrent l'effet produit.

La confusion inverse existe aussi. Quelqu'un voit une requête sortante dans un journal réseau et suppose qu'un agent approuvé l'a envoyée. Un journal réseau peut établir l'existence d'une connexion ou d'un fragment de requête, selon l'endroit où il a été capturé. Il ne montre généralement pas la décision d'approbation, l'identité réelle du processus ni le fait qu'une passerelle ait injecté un identifiant pour le compte de l'agent. Ne lui demandez pas de répondre à des questions pour lesquelles il n'a jamais été conçu.

La publication spéciale NIST 800-92, Guide to Computer Security Log Management, distingue la source de l'événement, l'infrastructure de journalisation et le processus d'analyse. Sa leçon pratique pour les systèmes d'agents est simple : collectez l'événement à la couche qui connaît le fait. La couche d'autorisation sait si une session a reçu une autorité. La passerelle d'action sait quelle opération elle a tentée avec un identifiant protégé. Un pare-feu connaît le trafic qu'il a observé. Chaque enregistrement possède une portée probante différente.

Un état d'autorisation précis sur chaque appel est utile. session_approved signifie que la session disposait d'une approbation permanente. per_call_approved signifie qu'un opérateur a approuvé cette utilisation. denied_locked signifie que le coffre-fort d'identifiants a refusé la tentative parce qu'il était verrouillé. denied_user signifie qu'un opérateur l'a refusée. Ce ne sont pas des libellés décoratifs. Ils indiquent à l'enquêteur si l'opération a atteint l'exécuteur d'action et si une intervention humaine l'a arrêtée.

Ne qualifiez pas chaque appel réussi d'« approuvé ». Ce mot masque la différence entre une permission accordée au début de la session et une permission accordée au moment de l'utilisation. Lorsqu'un examinateur demande si quelqu'un a approuvé la suppression, l'enregistrement doit fournir la réponse en une seule lecture.

L'approbation par appel a sa place, mais utilisez-la comme un contrôle ciblé. Appliquez-la aux identifiants dont chaque utilisation a de lourdes conséquences ou lorsque la cible change d'état d'une manière qu'un opérateur doit voir. Si vous exigez un clic humain pour les lectures courantes et les appels de build sans danger, les utilisateurs finissent par approuver une succession de demandes sans les lire. L'approbation existe toujours sur le papier, mais elle ne signifie plus un consentement éclairé.

Une chronologie d'échec révèle les lacunes cachées par les résumés

Une seule chronologie d'incident suffit à montrer l'intérêt des deux vues. Supposons qu'un agent de programmation autonome reçoive la tâche de nettoyer les environnements de prévisualisation obsolètes. L'opérateur approuve son processus pour la session. L'agent découvre un ancien identifiant d'API de déploiement et demande à la passerelle d'effectuer des appels avec celui-ci.

À 14 h 03, le journal de session enregistre un processus approuvé et lui attribue ses_7f4c2. À 14 h 07, le journal d'activité enregistre une requête GET qui liste les déploiements. À 14 h 09, il enregistre l'appel d'annulation présenté plus haut. À 14 h 10, une deuxième tentative d'annulation reçoit une réponse 403. À 14 h 12, l'opérateur révoque la session après avoir constaté que l'agent avait sélectionné le mauvais groupe d'environnements.

Imaginez maintenant que vous n'ayez conservé que les enregistrements de session. Vous pourriez dire qu'un processus a été approuvé puis révoqué. Vous ne pourriez pas établir s'il a annulé un environnement, plusieurs, ou aucun. Vous ne pourriez pas distinguer une deuxième tentative bloquée d'une tentative réussie. Il faudrait interroger le service de déploiement, dont la durée de conservation ou le niveau de détail des requêtes ne répond peut-être pas à vos besoins.

Imaginez ensuite que vous n'ayez conservé que les enregistrements d'appels. Vous verriez deux requêtes d'annulation. Vous ne pourriez pas établir quel processus local les a lancées, si un opérateur avait approuvé ce processus, si l'approbation était encore valide au moment des appels, ni si l'examinateur avait agi rapidement après la révocation.

La chronologie doit préserver l'ordre sans prétendre que l'heure murale est parfaite. Les machines dérivent. Les services distants fournissent leurs propres horodatages. Écrivez un horodatage de passerelle lorsque vous observez la requête et, lorsque c'est pertinent, conservez séparément l'horodatage du résultat distant. Utilisez une séquence d'ordonnancement interne au journal d'audit si vous en avez une. Ne déduisez pas de causalité simplement parce que deux événements partagent la même seconde sur une horloge.

La question délicate est de savoir si une session révoquée peut encore avoir des appels qui se terminent ensuite. C'est possible, selon le moment où la révocation atteint l'exécuteur et selon qu'une requête a déjà quitté la machine. Vos enregistrements doivent le rendre visible. Consignez l'heure de révocation, puis chaque fin d'appel ultérieure, avec l'heure de début et l'heure de fin de l'appel. Un système qui supprime simplement une session rend cette analyse impossible.

Les identifiants de corrélation doivent être contrôlés strictement

Un identifiant de session ne fonctionne que si la passerelle l'attribue et le contrôle. Ne laissez pas l'agent fournir un identifiant de session et ne le considérez pas comme un élément de preuve de sécurité.

Les agents peuvent transporter du texte arbitraire entre les appels d'outils. Ils peuvent réutiliser un identifiant obsolète après un redémarrage, faire une faute de frappe ou revendiquer délibérément l'identifiant d'une autre session si l'interface le permet. La passerelle doit déduire l'association à partir de la connexion locale authentifiée ou de la relation entre les processus, puis ajouter elle-même l'identifiant de session à chaque appel.

Les identifiants d'appel doivent être traités de la même manière. Générez-les à la limite d'action, avant que la requête ne quitte la machine. Si une requête HTTP est réessayée, indiquez si la nouvelle tentative est un nouvel essai lié à l'appel d'origine ou une partie du même appel comportant plusieurs tentatives de transport. Les deux modèles peuvent fonctionner. Les mélanger détruit la précision des comptages pendant une panne.

Utilisez un modèle de corrélation simple et cohérent :

• Un identifiant de session regroupe les événements d'autorité et de cycle de vie d'un même processus d'agent.
• Un identifiant d'appel identifie une opération externe demandée.
• Un identifiant de tentative identifie une tentative de transport lorsque les nouvelles tentatives comptent.
• Une référence d'identifiant désigne le secret configuré sans en exposer la valeur.
• Une référence de cible désigne l'hôte, le service ou la destination de la commande.

Ne cherchez pas à rendre chaque identifiant compréhensible par un humain. Son rôle est de relier les enregistrements de manière fiable. Des libellés lisibles peuvent les accompagner, mais les libellés changent, entrent en collision et invitent aux modifications improvisées.

Pour les agents concurrents, la corrélation évite une erreur fréquente. Un ingénieur voit une requête destructive à 16 h 21, trouve la transcription d'un terminal d'agent à 16 h 21 et suppose qu'elles correspondent. Pendant ce temps, un autre processus d'agent s'exécutait sous le même compte. L'identifiant de session présent sur l'enregistrement d'action supprime cette incertitude. S'il n'existe pas de lien stable, indiquez cette limite dans le rapport d'incident au lieu de la combler avec une fausse certitude.

Le journal d'audit doit montrer les refus comme les utilisations

Les actions refusées comptent souvent davantage que les actions achevées, car elles révèlent ce que l'agent a tenté de faire avant qu'un contrôle ne l'arrête. Consignez-les avec suffisamment de contexte pour expliquer la décision, mais évitez que le journal des refus devienne une nouvelle source de secrets.

Un coffre-fort d'identifiants verrouillé doit refuser toute action qui en dépend. L'enregistrement d'appel qui en résulte doit indiquer que l'action a été refusée avant toute exécution externe, identifier la session et la cible demandée, et préciser la catégorie de motif. Il ne doit contenir ni faux jeton, ni fragment de clé privée, ni en-tête d'autorisation copié.

Le refus par appel mérite la même attention. Si un opérateur refuse une commande SSH, consignez la représentation de la commande, la cible, l'heure de la décision et son résultat. L'absence de code de sortie distant prend alors tout son sens : l'exécuteur n'a jamais lancé la commande. C'est différent d'une commande lancée puis terminée avec un code non nul.

Sallyport utilise trois contrôles fixes : une barrière absolue sur le coffre-fort, l'autorisation par session par défaut et l'approbation par appel facultative pour un identifiant donné. Ce modèle limité facilite l'interprétation de l'audit, car chaque enregistrement peut indiquer quelle décision a arrêté ou autorisé l'action.

Évitez la réponse à la mode qui consiste à créer un immense langage de politiques pour chaque action d'agent. Elle plaît parce qu'elle promet une automatisation complète. En pratique, un moteur de politiques ajoute un second programme que les équipes doivent examiner, tester, mettre à jour et expliquer pendant un incident. Si vous avez besoin de politiques pour la gouvernance du réseau ou des services, appliquez-les à la couche concernée. Ne prétendez pas qu'un ensemble de règles illisible dispense d'éléments de preuve clairs sur les sessions et les appels.

Un enregistrement doit distinguer les résultats suivants :

• L'agent n'a jamais disposé d'une session autorisée.
• La session avait une autorité, mais le coffre-fort était verrouillé.
• La passerelle a demandé une décision par appel et l'opérateur l'a refusée.
• La passerelle a exécuté l'action et la cible distante l'a refusée ou a échoué.
• La passerelle a exécuté l'action et reçu un résultat positif.

Ces situations exigent des suites différentes. Une demande de session refusée peut indiquer un processus non fiable. Une réponse distante 403 peut signaler un problème de portée d'identifiant. Un appel réussi mais indésirable peut nécessiter l'examen de l'instruction donnée à l'agent, de la décision d'approbation de la session et de l'utilisation autorisée de l'identifiant cible.

La preuve d'altération protège l'enregistrement après l'incident

Les journaux applicatifs ordinaires sont faciles à modifier, tronquer ou remplacer après la prise de contrôle d'un hôte. Cela ne les rend pas inutiles, mais limite ce qu'ils peuvent prouver. Un journal d'audit chaîné par hachage rend les modifications ultérieures visibles lorsqu'un vérificateur compare la chaîne aux enregistrements reçus.

La distinction compte. Une chaîne de hachage peut montrer qu'une entrée a changé ou disparu au milieu d'une chaîne conservée. Elle ne peut pas prouver que le système a enregistré chaque événement qui aurait dû exister. Elle ne peut pas protéger un hôte déjà compromis avant la création de l'événement. Elle ne peut pas dire si un opérateur a compris une demande d'approbation. Toute affirmation allant au-delà relève de la mise en scène sécuritaire.

La RFC 5848, Signed Syslog Messages, traite d'un problème proche : les messages de journal peuvent perdre leur intégrité et la garantie de leur origine lorsqu'ils traversent plusieurs systèmes. Sa leçon reste valable même si vous utilisez un journal local chiffré plutôt que syslog. Protégez les journaux près du lieu où l'événement se produit, conservez les éléments d'ordonnancement et vérifiez au lieu de vous fier uniquement à une interface élégante.

Sallyport produit son journal Sessions et son journal Activity à partir d'un même journal d'audit chiffré, chaîné par hachage et protégé contre les écritures. Sa commande sp audit verify vérifie la chaîne hors ligne sur le texte chiffré, sans nécessiter la clé du coffre-fort. C'est utile lorsque l'examinateur doit valider l'intégrité des enregistrements sans recevoir les secrets utilisés pour les actions.

Effectuez la vérification avant de filtrer, d'exporter ou d'annoter les enregistrements d'un incident. Préservez d'abord les éléments de preuve chiffrés originaux. Créez ensuite une copie de travail pour l'analyse. Si la vérification échoue, consignez l'échec et l'artefact exact examiné. Ne poursuivez pas discrètement avec un export nettoyé, car la question de l'intégrité fait alors partie de l'incident.

La preuve d'altération modifie aussi la discipline opérationnelle. Si votre équipe sait qu'une modification ultérieure sera visible, elle cesse de considérer le journal d'audit comme un endroit pratique où réécrire l'histoire après un mauvais déploiement. Cela n'empêche pas les erreurs. En revanche, cela préserve les éléments nécessaires pour en tirer des leçons.

La conservation nécessite des limites, pas une collecte indiscriminée

Conservez les enregistrements de session et d'appel assez longtemps pour enquêter sur une découverte tardive, une utilisation abusive d'identifiants et les revues d'accès, mais ne conservez pas chaque charge utile indéfiniment sous prétexte que le stockage est bon marché. Les journaux les plus dangereux sont souvent ceux que personne n'a classifiés.

Commencez par les questions auxquelles votre équipe doit répondre en cas d'incident. Combien de temps après une exécution d'agent le propriétaire d'un service peut-il remarquer une modification indésirable ? Pendant combien de temps devez-vous retracer l'utilisation d'un identifiant après le départ d'un membre du personnel ? Quelles réglementations ou quels contrats imposent une durée de conservation ? Ces réponses fixent la période. Elles ne justifient pas la collecte de prompts bruts, de réponses complètes ou de secrets inutiles.

Séparez la visibilité opérationnelle de la conservation forensique. Les opérateurs peuvent avoir besoin d'une vue concise des sessions actives et des appels récents. Les enquêteurs peuvent avoir besoin de la séquence immuable complète, avec les refus et les détails horaires. Donner à tous les développeurs un accès sans restriction à cette dernière transforme la piste d'audit en un autre jeu de données sensibles.

Définissez des limites de rôles pour la consultation, mais ne vous servez pas du contrôle d'accès pour cacher des éléments aux personnes responsables des incidents. Un propriétaire de service peut avoir besoin de savoir qu'un appel a modifié son service. Il n'a pas besoin d'un jeton porteur ni d'une charge utile client sans rapport pour le comprendre.

Lorsqu'un enregistrement renvoie à un contenu sensible conservé ailleurs, stockez une référence contrôlée et une procédure de récupération. Par exemple, conservez un identifiant de requête que le service cible pourra utiliser pour retrouver une charge utile protégée selon ses propres règles d'accès. Le journal d'actions reste ainsi utile sans dupliquer des données métier sensibles dans chaque système d'audit.

La suppression nécessite son propre enregistrement. Si la conservation arrive à échéance pour un lot d'entrées, consignez l'événement de conservation, sa portée et l'autorité ayant entraîné la suppression avant d'effacer les données. Sans cela, un vérificateur ultérieur ne peut pas distinguer une expiration autorisée d'une absence inexpliquée. La politique de conservation doit être assez claire pour qu'un examinateur puisse l'appliquer sans consulter la personne qui a écrit le système initial.

Construire la vue d'incident en partant de l'appel

Pendant une enquête active, commencez par l'appel suspect et remontez vers les autres éléments. C'est généralement la preuve la plus concrète : une cible, une opération, une heure et un résultat. Utilisez son identifiant de session pour récupérer l'enregistrement d'autorité, puis examinez les appels proches dans cette session ainsi que l'événement de révocation ou de fin de session.

Suivez cette séquence :

1. Préservez et vérifiez les enregistrements d'audit originaux avant de les modifier ou de les exporter.
2. Repérez l'enregistrement d'appel par destination, identifiant d'appel, opération ou fenêtre temporelle de l'incident.
3. Récupérez l'enregistrement de session associé et confirmez l'identité du processus, l'heure d'approbation et l'état du cycle de vie.
4. Examinez tous les appels de cette session autour de l'événement, y compris les refus et les nouvelles tentatives.
5. Comparez la chronologie des actions avec les propres enregistrements du service cible, puis documentez les lacunes au lieu de les combler par des suppositions.

Cette méthode révèle à la fois l'erreur évidente et l'erreur plus discrète. L'erreur évidente est un appel qui n'aurait jamais dû avoir lieu. L'erreur plus discrète est une session restée autorisée après la fin prévue de la tâche, ou une nouvelle tentative qui a répété une action après l'expiration d'un délai du service.

Ne faites pas tourner tous les identifiants en premier simplement parce que cette mesure semble décisive. Si le coffre-fort a gardé les identifiants hors de portée de l'agent et que l'enregistrement montre un appel émis par la passerelle vers une seule cible connue, une rotation générale peut provoquer une interruption inutile. Révoquez immédiatement les sessions actives lorsqu'une utilisation abusive en cours est plausible. Utilisez ensuite les enregistrements d'appels pour décider quel identifiant, quelle cible ou quelle portée d'accès doit être traité.

Deux vues produisent effectivement davantage d'enregistrements. Elles suppriment aussi la phrase la plus coûteuse d'un rapport d'incident : « Nous ne pouvons pas déterminer si l'agent approuvé a réellement effectué cette modification. » Rendez l'autorité visible à la limite de session et les effets visibles à la limite d'appel. Toute solution moindre laisse votre équipe reconstituer un événement de sécurité à partir de fragments.