Des références de tickets d'actions d'agents qui résistent à la revue

Un agent capable d'appeler une API de production ou d'ouvrir une session SSH a besoin de plus qu'une trace indiquant qu'il a agi. Les réviseurs doivent savoir pourquoi cette action était autorisée à ce moment-là. Une référence de ticket de changement leur permet de remonter d'une commande ou d'un appel API observé jusqu'à une intention approuvée.

Ce lien ne fonctionne que si la référence fait partie des preuves de l'action avant son exécution. Coller un numéro de ticket dans un commentaire après le début d'un incident, c'est de la paperasse, pas un contrôle. Les équipes qui confondent les deux finissent par découvrir que chaque action risquée possède un ticket, mais qu'aucun ticket ne l'explique.

Une référence de ticket relie l'intention à l'exécution

Un ticket de changement répond à une question différente de celle d'un événement d'audit. Le ticket indique ce que quelqu'un a demandé, pourquoi, quels systèmes peuvent être concernés et qui a accepté le risque. L'événement indique ce que l'agent a réellement tenté sur une cible donnée, avec une identité donnée, et ce qui s'est passé.

Conservez ces enregistrements séparément, puis reliez-les avec une référence stable. Ne placez pas le contenu complet du ticket dans chaque événement. Le texte du ticket change, contient souvent des informations confidentielles et rend les recherches dans les événements moins efficaces. Stockez l'identifiant canonique du ticket ainsi qu'un court instantané des faits d'autorisation importants au moment de l'envoi.

Pour une migration de base de données en production, cet instantané peut contenir la référence du ticket, sa révision ou son horodatage de mise à jour, la fenêtre de maintenance approuvée et le responsable du changement. Pour un appel API qui désactive un compte, il peut contenir la référence, l'identifiant du compte demandé et la personne qui a accepté la demande. L'enregistrement de l'action doit aussi conserver ses propres détails de requête et son résultat.

Cette distinction permet de détecter un échec courant. Une équipe ouvre CHG-418 pour une modification planifiée de la configuration du cache. Plus tard, un agent utilise CHG-418 pour supprimer un compartiment de stockage parce qu'un ingénieur lui a demandé de « nettoyer les ressources liées au changement ». Le ticket existe. L'action de l'agent possède une référence. Pourtant, cette référence ne justifie ni la cible ni l'opération. Un réviseur doit disposer d'assez de contexte structuré pour voir cette incohérence sans lire une transcription de conversation.

L'OWASP Logging Cheat Sheet recommande d'enregistrer le moment, le lieu, l'auteur et la nature des événements liés à la sécurité. Ces recommandations s'appliquent parfaitement ici, mais les actions d'agents ajoutent un cinquième élément : le contexte d'autorisation déclaré. Une simple référence de ticket est trop pauvre ; une copie complète du ticket est excessive. Enregistrez la référence et les faits précis utilisés pour déterminer que l'action lui correspondait.

Le travail sensible a besoin d'une limite écrite

Exigez une référence de ticket pour les actions dont les conséquences sont difficiles à annuler, à détecter ou à expliquer plus tard. Ne demandez pas aux agents d'obtenir un ticket avant chaque lecture sans danger. Les équipes contourneront une règle qui interrompt les investigations courantes, et les actions importantes finiront dans les exceptions.

Commencez par définir des classes d'actions plutôt que d'essayer de prévoir chaque commande dangereuse. La plupart des équipes devraient inclure les actions qui :

• modifient l'infrastructure de production, la configuration de l'application ou le code déployé
• créent, révoquent ou modifient des accès utilisateur ou de service
• exportent, suppriment ou déplacent des données réglementées ou client
• modifient les paiements, la facturation, les notifications ou le comportement visible publiquement
• utilisent une procédure d'urgence ou un identifiant doté de larges autorisations

Une connexion SSH peut être sensible dans un environnement et banale dans un autre. La classification doit dépendre de ce que la connexion permet de faire et de l'endroit où elle aboutit. Une session de diagnostic en lecture seule sur la production peut nécessiter un enregistrement de session, mais pas de ticket. Une commande SSH qui modifie les règles du pare-feu nécessite une référence, même si elle ne comporte qu'une seule ligne.

Ne vous contentez pas d'étiqueter une catégorie « à haut risque ». Définissez le test observable au point de contrôle. Par exemple, toute requête utilisant un identifiant de production et envoyant une méthode HTTP différente de GET nécessite une référence ; toute invocation SSH visant le groupe d'hôtes de production en nécessite une, sauf si la commande correspond à une liste d'autorisation de diagnostic documentée. Les règles exactes varient, mais le test doit pouvoir être appliqué de façon cohérente par un programme comme par un réviseur.

On recommande souvent d'exiger un ticket pour chaque action, parce que cela semble rigoureux. En pratique, cela produit généralement une pile de tickets génériques, de références copiées et d'approbations que personne ne lit. Utilisez cette exigence là où elle crée un véritable point de décision. Conservez des journaux complets pour tout le reste, car l'absence de ticket ne doit pas entraîner l'absence d'événement.

Capturez la référence avant l'envoi de la requête

Le point de contrôle doit refuser une requête sensible dépourvue de référence valide avant d'envoyer l'appel HTTP ou de démarrer la commande SSH. Une tâche ultérieure d'enrichissement des journaux ne peut pas réparer cette lacune. Une fois qu'un système externe a accepté la requête, votre enregistrement local peut être retardé, modifié ou absent au moment précis de l'incident que les enquêteurs doivent reconstituer.

Le flux de requête doit suivre un ordre clair :

1. L'agent propose une action avec une cible, une opération et une référence de ticket.
2. Le point de contrôle vérifie que la référence a le format requis et récupère les informations nécessaires du ticket.
3. Une approbation humaine, si elle est requise, porte à la fois sur l'action proposée et sur la référence.
4. Le point de contrôle écrit un événement d'intention, envoie l'action, puis écrit l'événement de résultat.

L'écriture d'un événement d'intention est importante. Imaginons qu'une expiration de délai réseau survienne après qu'un fournisseur d'API a reçu DELETE /v1/projects/acme-prod. Si vous n'enregistrez que les réponses réussies, le journal d'actions laisse croire à tort que rien ne s'est produit. Un enregistrement d'intention indique que le système a tenté la requête. Un résultat unknown n'est pas un défaut de la piste d'audit. C'est le résultat honnête tant que quelqu'un n'a pas vérifié le système de destination.

Le même principe s'applique à SSH. Enregistrez l'identité de l'hôte cible, la commande ou l'empreinte d'une commande approuvée, la référence du ticket et le début de l'exécution avant de lancer le processus. Enregistrez ensuite le statut de sortie, la politique de conservation de la sortie capturée et l'heure de fin. Si le processus perd sa connexion, conservez ce résultat au lieu de le transformer en échec propre.

Ne permettez pas à un client d'envoyer un champ texte modifiable appelé change_note et de considérer le travail comme terminé. Un champ structuré ticket_ref permet la validation, les rapports et la réconciliation. Le texte libre donne à un agent un endroit où dissimuler un numéro plausible dans un paragraphe.

Le numéro de ticket doit correspondre au périmètre demandé

Une référence qui semble valide ne prouve pas que l'action correspond au travail approuvé. Le point de contrôle doit comparer le périmètre connu du ticket avec la requête lorsque ces informations sont disponibles, et imposer une décision humaine dans le cas contraire.

Au minimum, vérifiez que le ticket existe, n'a pas été annulé et se trouve dans un état que votre organisation accepte pour l'exécution. De nombreuses équipes exigent aussi une fenêtre de changement actuelle et un responsable approuvé. Ces contrôles empêchent l'utilisation paresseuse d'un ancien ticket, mais ne détectent pas le déplacement de cible.

Un déplacement de cible se produit lorsque le ticket décrit un service, un compte, un environnement ou une région tandis que la requête en concerne un autre. La meilleure défense consiste à structurer le périmètre dans le système de tickets lui-même. Si un ticket possède des champs lisibles par machine pour l'environnement, le service, le dépôt, le compte ou la fenêtre de maintenance, comparez-les aux attributs de la requête. Évitez de déduire le périmètre à partir de la prose. Les descriptions en langage naturel sont utiles aux humains, mais un analyseur peut approuver une absurdité avec une assurance impressionnante.

Lorsque le ticket ne contient que de la prose, présentez l'action et la référence ensemble pour approbation. La personne doit voir la destination et le verbe en termes simples : « Appliquer la mise à jour de configuration au service de production billing-api sous CHG-418. » N'affichez pas seulement « Approuver l'action de l'agent sous CHG-418. » Cette formulation dissimule la décision exacte demandée.

Ne construisez pas un langage de règles tentaculaire pour gérer toutes les nuances des tickets. Commencez par quelques comparaisons que vous pouvez expliquer pendant un incident : environnement, identifiant de la cible, heure demandée et demandeur ou responsable. Soumettez les cas incertains à une approbation explicite. Un contrôle limité qui échoue par défaut vaut mieux qu'une couche d'interprétation ingénieuse que personne ne peut auditer.

Utilisez un contrat d'événement interrogeable par les réviseurs

Un événement d'action a besoin de champs stables, pas d'un récit assemblé à partir de la sortie du terminal. Voici un enregistrement JSON générique pour une tentative d'action. Il sépare volontairement la référence déclarée des faits observés pendant l'exécution.

{
  "event_id": "act_01J8M7FQ6F2Y3K9D",
  "event_type": "action.intent",
  "occurred_at": "2025-03-08T14:32:11Z",
  "agent_run_id": "run_7e9d2",
  "actor": {
    "agent_process": "release-agent",
    "human_requester": "ops-204"
  },
  "ticket": {
    "system": "changes",
    "reference": "CHG-418",
    "observed_state": "approved",
    "observed_at": "2025-03-08T14:31:58Z",
    "scope_digest": "sha256:4ea4..."
  },
  "action": {
    "channel": "http",
    "operation": "PATCH",
    "target": "prod/billing-api/config",
    "request_digest": "sha256:35b9...",
    "idempotency_id": "chg-418-billing-01"
  },
  "decision": {
    "reference_required": true,
    "authorized_by": "ops-204",
    "decision_at": "2025-03-08T14:32:07Z"
  }
}

L'événement de fin réutilise event_id comme référence parente ou utilise un attempt_id distinct. Il enregistre le statut HTTP, le code de sortie SSH, l'identifiant de requête du fournisseur lorsqu'il est disponible et un résultat tel que succeeded, failed ou unknown. Ne placez pas dans cet enregistrement les en-têtes d'autorisation bruts, les cookies de session, les corps de requête contenant des secrets ou du matériel privé SSH.

Une empreinte est utile lorsque vous pouvez conserver la preuve de la charge utile exacte sans rendre le contenu sensible consultable par tous les lecteurs des journaux. Canonicalisez les données avant le hachage. Définissez l'ordre des champs, l'encodage et les règles de masquage ; sinon, deux requêtes équivalentes produiront des empreintes différentes et la comparaison ne sera qu'une mise en scène.

Vous pouvez détecter les références manquantes dans du JSON délimité par des retours à la ligne avant que les événements n'atteignent le stockage à long terme. Cette vérification jq renvoie un statut de sortie différent de zéro lorsqu'une action sensible n'a pas de référence :

jq -e '
  select(.event_type == "action.intent")
  | select(.decision.reference_required == true)
  | select((.ticket.reference // "") | length == 0)
  | error("sensitive action has no ticket reference")
' actions.ndjson

Exécutez une requête complémentaire pour trouver les références qui n'ont aucun événement de fin. Un lien vers un ticket n'est utile que si le journal indique si l'exécution demandée a eu lieu.

Ne laissez pas l'agent fabriquer ses propres preuves

Un agent peut proposer une référence de ticket, mais il ne doit pas pouvoir déclarer lui-même que cette référence est approuvée et que son périmètre est respecté. Ce serait la même erreur que de demander à un processus d'attester que ses propres identifiants sont appropriés.

Donnez à l'agent l'un de deux chemins. Dans le premier, un humain fournit une référence lors de l'attribution du travail, et l'agent reçoit un contexte de travail de courte durée contenant cette référence et le périmètre des cibles autorisées. Dans le second, l'agent demande à un service de recherche de tickets de confiance de retrouver un ticket par référence, et le point de contrôle vérifie indépendamment la réponse avant l'envoi. L'agent ne voit que les faits dont il a besoin pour formuler la requête.

Un contexte de travail signé peut prendre conceptuellement cette forme :

{
  "ticket_ref": "CHG-418",
  "allowed_targets": ["prod/billing-api/config"],
  "allowed_operations": ["PATCH"],
  "expires_at": "2025-03-08T15:00:00Z",
  "issued_for_run": "run_7e9d2"
}

L'émetteur signe le contexte sérialisé. Le point de contrôle vérifie la signature, l'expiration, la cible, l'opération et l'identité de l'exécution. L'agent ne peut pas prolonger l'expiration ni ajouter une seconde cible sans invalider la signature. Si votre système de tickets ne peut pas émettre de contextes signés, conservez la même logique côté serveur et enregistrez dans l'événement les faits de la réponse de recherche.

Liez le contexte à une exécution précise de l'agent. Sans cette liaison, un processus compromis peut copier une référence approuvée d'une tâche vers une autre. Enregistrez aussi l'identité du code ou du processus qui a effectué l'appel lorsque votre environnement peut la fournir. Un nom humain dans un ticket et un processus local anonyme dans un journal ne forment pas une chaîne fiable.

Les nouvelles tentatives et les lots ont besoin de preuves individuelles

Un ticket peut autoriser un changement limité dans le temps, mais il ne doit jamais réduire de nombreuses actions à une seule entrée d'audit vague. Les réviseurs doivent pouvoir distinguer une séquence planifiée d'échecs répétés, d'une exécution partielle ou d'un agent qui sort de son périmètre.

Donnez à chaque tentative son propre identifiant d'action. Associez la même référence de ticket à chaque tentative et regroupez les tentatives liées avec un identifiant d'exécution ou d'exécution du changement. Enregistrez un identifiant d'idempotence lorsque la destination le prend en charge. Il aide à déterminer si une nouvelle tentative a créé un second changement, mais ne remplace pas l'enregistrement de la tentative.

Prenons un agent qui met à jour dix configurations de services. Les sept premiers appels réussissent, le huitième expire et l'agent le réessaie deux fois. Un journal utile dit exactement cela : dix cibles prévues, sept résultats confirmés, un résultat inconnu et deux nouvelles tentatives. Un seul commentaire dans le ticket disant « mise à jour de configuration terminée » dissimule le seul service qui pourrait nécessiter une inspection manuelle.

Pour les lots, exigez que le ticket désigne une population limitée ou un manifeste joint. Stockez une empreinte de ce manifeste avec l'exécution. Si l'agent découvre une onzième cible après le début du changement, arrêtez-le et demandez une nouvelle décision sur le périmètre. Traiter la découverte comme une permission est la façon dont une opération de maintenance devient une migration non révisée.

Les interventions d'urgence ont elles aussi besoin d'une référence, même si celle-ci est créée après la première action de protection. Enregistrez un marqueur d'urgence, la raison, la personne qui a approuvé l'action et l'heure d'ouverture du ticket normal. Ne réutilisez pas discrètement un ticket courant parce que l'ouverture d'un enregistrement d'incident semble lente. Les urgences ont besoin de plus de preuves, pas de moins.

Réconciliez les tickets et les actions dans les deux sens

Un rapport hebdomadaire qui répertorie les tickets mentionnés dans les journaux ne suffit pas. Vous avez besoin de deux tests distincts. Le premier doit trouver chaque action sensible dépourvue de référence de ticket valide. Le second doit trouver chaque ticket terminé ou approuvé qui prétend avoir été exécuté sans preuve d'action correspondante.

Le premier test détecte les contournements. Le second révèle les notes d'achèvement erronées, le travail manuel effectué en dehors du chemin de l'agent et les défaillances d'intégration. Aucun des deux rapports ne prouve une faute. Ils indiquent tous deux à l'opérateur où poser une question précise tant que le contexte est encore disponible.

Utilisez une règle de jointure stable. Si le système de changement possède plusieurs projets, stockez le nom du système et la référence. Si les références peuvent être réutilisées après archivage, ajoutez un identifiant immuable de l'enregistrement du ticket ou une révision de l'instantané. Si un ticket peut être modifié après l'exécution, conservez l'état et l'empreinte du périmètre observés lors de l'autorisation de l'action. Sinon, une modification ultérieure peut donner l'impression qu'une ancienne exécution était approuvée alors qu'elle ne l'était pas.

Traitez les exceptions comme des enregistrements à part entière. Une exception doit indiquer qui l'a acceptée, pourquoi le lien normal a échoué, quelle action a eu lieu et quand l'exception expire. Un tableur d'exceptions informelles devient en quelques mois un second système de changement, plus faible.

Le journal Activity documenté de Sallyport enregistre les appels individuels, mais les équipes doivent conserver le lien avec les tickets dans leurs propres enregistrements de changement ou dans un événement immuable complémentaire jusqu'à l'existence d'un champ de référence de ticket documenté. Ne prétendez pas qu'une note en texte libre a la même valeur probante qu'un champ capturé et validé avant l'envoi.

Préservez les preuves sans exposer le contenu des tickets

Les systèmes de tickets contiennent souvent des noms de clients, des détails d'incidents, des notes d'architecture et des informations d'accès. Les journaux d'actions ont souvent un lectorat plus large pendant les opérations et les revues. Stockez la référence et l'instantané d'autorisation, puis laissez les réviseurs autorisés ouvrir le système de tickets lorsqu'ils ont besoin du texte complet.

Masquez les données de requête avant de calculer une représentation consultable, et ne conservez l'original sous contrôle d'accès que si les besoins d'enquête le justifient. Une empreinte peut confirmer qu'une charge utile conservée n'a pas changé, mais elle n'aide pas un réviseur à comprendre une charge utile qu'il ne peut pas récupérer. Décidez précisément quel système conserve l'original protégé et qui peut le récupérer.

Conservez la référence du ticket même après la suppression ou l'archivage de l'enregistrement source par le système de tickets. La référence fournit un point de départ aux enquêteurs, tandis que l'état capturé, la cible, la décision et le résultat rendent l'enregistrement d'action compréhensible par lui-même. Si les règles de conservation imposent une suppression, enregistrez ce fait au lieu de laisser un lien cassé qui ressemble à une erreur.

Un premier contrôle simple suffit à révéler les lacunes : refusez les actions sensibles sans référence structurée, écrivez l'intention avant l'envoi et conservez le résultat après l'envoi. Une fois cela en place, ajoutez la comparaison du périmètre et la réconciliation. Le numéro de ticket doit permettre au réviseur d'aller plus vite et d'être plus certain, pas fournir à l'agent une chaîne décorative à associer à un travail risqué.