Accès par bastion pour les agents IA de programmation, correctement conçu

Un bastion peut offrir aux agents IA de programmation un accès plus sûr à l'infrastructure privée, mais seulement si vous le considérez comme un élément de la frontière d'accès. Une machine relais qui apparaît simplement dans un fichier de configuration SSH n'est pas un contrôle. L'agent peut la contourner, emprunter un identifiant, ouvrir un tunnel ou vous laisser un enregistrement d'audit prouvant seulement qu'une connexion a atteint le relais.

Pour un fonctionnement autonome, la conception utile est plus stricte : l'agent atteint un point d'entrée contrôlé, ce point d'entrée n'atteint que des destinations connues, les identifiants restent en dehors du contexte de l'agent et vos journaux distinguent l'hôte demandé par l'agent de celui qui a réellement accepté la connexion. Cette distinction peut sembler tatillonne jusqu'au premier examen d'incident. Elle fait alors la différence entre une preuve et une histoire rassurante.

Un bastion modifie la route, pas les autorisations de l'agent

Une conception d'accès par bastion limite la portée réseau, mais ne réduit pas ce qu'un agent peut faire après avoir atteint un compte privilégié. Les équipes confondent souvent ces deux fonctions parce qu'elles passent toutes deux par SSH. Ce sont des contrôles distincts et ils doivent échouer séparément.

Un hôte relais est utile lorsque les cibles privées n'acceptent le trafic d'administration que depuis cet hôte ou ce sous-réseau. Il offre un endroit unique pour appliquer des limites de sortie, recueillir les preuves de connexion et couper l'accès pendant une enquête. Il évite aussi que chaque poste, exécuteur de build et bac à sable d'agent ait besoin de routes directes vers les réseaux sensibles.

Il ne répond pas aux quatre questions qui comptent davantage avec un client autonome :

• L'agent peut-il atteindre directement la cible par une autre route ?
• Le compte cible dispose-t-il d'autorisations plus larges que nécessaire pour la tâche demandée ?
• L'agent peut-il créer un tunnel qui lui donne un chemin non contrôlé ?
• Pourrez-vous identifier après coup la machine finale et la commande distante ?

Si la réponse à la première question est oui, ProxyJump est un réglage pratique, pas une règle imposée. Si la réponse à la deuxième est oui, le bastion n'a fait que déplacer l'endroit où un identifiant trop puissant entre dans le réseau.

J'ai vu des équipes construire une machine relais soigneusement entretenue, puis autoriser une sortie SSH étendue depuis un sous-réseau CI « pour le dépannage ». Un agent exécuté dans ce sous-réseau n'a besoin ni d'un exploit ni d'une astuce. Il peut appeler directement l'adresse finale. L'architecture a échoué parce que le réseau autorisait le contournement, pas parce que SSH se comportait mal.

Gardez les rôles simples. L'environnement de l'agent ne devrait se connecter qu'à l'hôte d'entrée. L'hôte d'entrée ne devrait se connecter qu'aux réseaux et ports cibles prévus. L'hôte final devrait autoriser un compte à usage limité. Chaque couche devrait produire des enregistrements répondant à une question différente.

ProxyJump n'expose pas la commande finale

Un hôte relais SSH ne peut généralement pas inspecter la commande exécutée par l'agent sur l'hôte final. C'est le point que les équipes oublient lorsqu'elles promettent des « journaux complets des commandes depuis le bastion ».

OpenSSH décrit ProxyJump dans ssh_config(5) comme une connexion d'abord établie vers l'hôte relais, suivie de la mise en place d'une redirection vers la destination finale. Dans l'utilisation courante d'OpenSSH, le client demande en pratique à l'hôte relais d'établir une connexion TCP vers la cible, puis exécute sa session SSH de bout en bout dans ce flux d'octets. Le transport SSH final reste chiffré entre le client et la cible.

Le bastion peut souvent savoir qu'il s'est connecté à 10.42.8.19:22. Il peut journaliser le compte utilisé sur le bastion, la source, les horaires et la destination d'une demande de redirection. Il ne sait pas automatiquement si la session chiffrée a ensuite exécuté systemctl restart api, cat /etc/shadow ou ouvert un shell interactif.

Cela laisse trois observations différentes que l'on confond souvent :

1. La destination demandée est celle fournie par l'agent, par exemple prod-api-01.
2. La destination de connexion est l'adresse et le port réellement ouverts par le proxy.
3. La destination d'exécution est l'identité du serveur et le compte ayant accepté l'authentification SSH finale.

Elles peuvent différer. Un alias peut se résoudre différemment après une modification DNS. Une entrée known-host compromise ou obsolète peut rendre la connexion suspecte. Une règle de proxy peut envoyer un alias convivial vers une adresse inattendue. Journaliser uniquement prod-api-01 ne prouve pas quel serveur a exécuté une commande.

La même séparation s'applique aux commandes. Une passerelle côté client peut enregistrer la commande demandée avant le transport. Un wrapper sur l'hôte final peut enregistrer la commande qu'OpenSSH transmet pour une requête exec. Le bastion peut enregistrer la cible TCP. Corrélez ces observations avec un identifiant de session et une fenêtre temporelle. Ne prétendez pas qu'une seule couche les voit toutes.

Si vous avez besoin d'un point unique capable d'inspecter et d'autoriser chaque commande distante, le SSH ordinaire de bout en bout à travers une machine relais est le mauvais outil. Utilisez un service d'exécution distante conçu à cet effet, un endpoint de commandes restreint ou un wrapper côté cible qui n'accepte que l'opération prévue. Ce choix réduit la flexibilité. Il vous évite aussi de revendiquer une visibilité que vous n'avez pas.

Les règles réseau doivent rendre le chemin approuvé incontournable

Un point d'entrée contrôlé ne fonctionne que si le réseau environnant rend les autres chemins indisponibles. Commencez par la connectivité avant de débattre des dialogues d'approbation ou du format des journaux.

L'environnement d'exécution de l'agent ne doit disposer d'une sortie SSH que vers l'adresse et le port du bastion. Il ne devrait pas avoir de route étendue vers les sous-réseaux de production, les interfaces d'administration publiques ou un second hôte relais que personne n'avait inclus dans la conception. Le DNS compte également. Si l'agent peut résoudre et contacter directement les adresses des cibles, une convention de noms conviviale ne vous protège pas.

Le bastion a besoin d'une courte liste d'autorisation pour ses sorties. S'il administre des hôtes sur le port TCP 22 dans deux plages privées, autorisez ces plages et ce port. Ne lui donnez pas une sortie arbitraire en appelant la machine un bastion. Un hôte d'entrée capable d'atteindre tous les services, bases de données et endpoints publics devient un relais général si le compte de l'agent est détourné.

Les cibles finales ne devraient accepter l'administration SSH que depuis le chemin du bastion. Les groupes de sécurité cloud, les pare-feu des hôtes et les ACL réseau peuvent tous contribuer à cette protection. Utilisez plusieurs couches seulement si leurs responsabilités restent claires. Une règle que personne ne maintient n'est pas une défense.

Testez la route avec des cas de refus, pas seulement avec la commande réussie. Lancez ces vérifications depuis le même utilisateur, conteneur ou VM que celui qui exécute l'agent :

nc -vz bastion.internal.example 22
nc -vz 10.42.8.19 22
ssh -o ConnectTimeout=5 prod-api-01 true

La première connexion devrait fonctionner. La connexion directe vers l'hôte final devrait échouer. La commande SSH ne devrait fonctionner que parce que sa route configurée passe par le bastion. Si nc n'est pas disponible, utilisez la commande habituelle de test TCP de votre environnement. Le but est de tester le chemin réseau sans laisser la configuration SSH masquer une route directe.

Répétez le test après les changements de pare-feu, l'ajout de sous-réseaux et les modifications de l'exécuteur de l'agent. C'est un petit test au rendement exceptionnel. Il détecte le cas fréquent où la configuration SSH semble correcte alors que le réseau permet toujours une connexion directe.

L'agent a besoin d'une identité révocable

Ne donnez pas à un agent une clé d'administrateur partagée en espérant que le bastion rende cette pratique acceptable. Une clé privée copiée est une décision d'autorisation dont les conséquences peuvent durer très longtemps.

Donnez à chaque processus ou exécution d'agent une identité que vous pouvez attribuer et révoquer. Il peut s'agir d'un certificat SSH de courte durée, d'une clé éphémère enregistrée pour une tâche limitée ou d'un identifiant conservé par une passerelle d'action qui exécute SSH au nom de l'agent. Le bon choix dépend de votre environnement, mais l'agent ne doit pas imprimer de secret réutilisable dans son transcript, son espace de travail, l'historique du shell ou la sortie de ses outils.

Les certificats SSH sont utiles si vous exploitez déjà une autorité de certification SSH. Un certificat peut contenir une courte période de validité, un principal pour le compte cible et des options critiques comme des restrictions d'adresse source. La cible peut faire confiance à l'autorité de certification au lieu de gérer une liste croissante de clés publiques individuelles. L'émission et l'expiration deviennent ainsi plus faciles à contrôler.

Les certificats ne rendent pas un compte étendu plus limité. Un certificat pour root reste un identifiant root jusqu'à son expiration. Ils ne prouvent pas non plus l'intention d'une commande. Considérez-les comme un mécanisme d'émission et de durée de vie.

Une passerelle modifie davantage le profil d'exposition. Sallyport peut exécuter SSH via son utilitaire sp-ssh tandis que la clé SSH reste dans son coffre-fort chiffré au lieu d'atteindre le processus de l'agent. Cela protège la clé privée contre le transcript de l'agent, mais les équipes doivent tout de même vérifier comment sont enregistrés la route de saut prévue, l'identité cible et les preuves de commande.

Associez l'approbation à un processus identifiable, pas à la phrase écrite par l'agent dans une fenêtre de discussion. Un processus peut être signé, démarré à une heure donnée, associé à un utilisateur local et révoqué comme session active. Une explication en langage naturel fournit un contexte utile, mais ce n'est pas une frontière de contrôle d'accès.

Évitez qu'un même identifiant soit partagé par tous les traitements automatisés. Lorsque le journal de la cible indique deploy, il vous faut un second enregistrement identifiant l'exécution de l'agent à l'origine de l'action. Si toutes les exécutions utilisent la même clé et le même compte, l'analyse d'un incident devient une véritable fouille archéologique.

Enregistrez une intention d'exécution, un fait de routage et un résultat

Un enregistrement d'audit SSH d'agent doit préciser exactement la signification de chaque champ. Cela empêche le système d'audit de formuler des affirmations qu'il ne peut pas étayer.

Au moment de la demande d'action, enregistrez l'identité de l'exécution de l'agent, l'alias d'hôte demandé, le compte distant demandé, le texte de la commande ou l'opération structurée, ainsi que l'indication d'une demande de TTY ou de transfert. C'est l'intention d'exécution. Elle indique ce que l'appelant a tenté de faire.

À la frontière de routage, enregistrez l'identité de l'hôte d'entrée, l'adresse de destination résolue, le port de destination et le résultat de la connexion. C'est le fait de routage. Si le proxy ouvre une connexion, il peut indiquer où il l'a ouverte. Il ne peut pas déduire honnêtement la commande finale à partir d'octets chiffrés.

Sur l'hôte final, enregistrez son identité stable, le compte authentifié, l'empreinte d'authentification ou le numéro de série du certificat, la commande si le serveur a reçu une requête exec, le code de sortie et les journaux locaux pertinents. C'est la preuve d'exécution. L'hôte final est le seul endpoint SSH ordinaire qui puisse voir la commande distante sans rompre la conception SSH de bout en bout.

Utilisez une structure d'événement qui rend les preuves manquantes visibles :

{
  "run_id": "run_7c31",
  "requested": {
    "host": "prod-api-01",
    "user": "deploy",
    "command": "sudo systemctl restart api",
    "tty": false
  },
  "route": {
    "bastion": "bastion.internal.example",
    "destination_ip": "10.42.8.19",
    "destination_port": 22
  },
  "final_host": {
    "host_fingerprint": "SHA256:example",
    "authenticated_user": "deploy",
    "command_observed": true,
    "exit_status": 0
  }
}

L'exemple sépare volontairement requested.command d'une observation effectuée sur l'hôte final. Si la session était interactive, définissez command_observed sur false et expliquez pourquoi. Un champ vide sans explication invite quelqu'un à supposer que l'outil a capturé la commande.

Pour l'exécution ordinaire de commandes, sshd_config(5) documente ForceCommand, qui impose une commande pour un compte ou un bloc match donné. Un wrapper côté cible peut lire SSH_ORIGINAL_COMMAND pour une requête exec, valider une opération autorisée et écrire un enregistrement d'audit avant d'appeler le programme approuvé. Il doit gérer soigneusement le shell. Ne transmettez pas une chaîne non fiable à eval et ne supposez pas que SSH_ORIGINAL_COMMAND existe pour un shell interactif.

Le chaînage de hachages et le stockage en ajout uniquement aident à détecter une modification ultérieure des événements d'audit. Ils ne corrigent pas un contenu d'événement insuffisant. Un enregistrement parfaitement conservé qui indique seulement « Connexion SSH établie » reste une preuve faible.

Rendez la configuration SSH vérifiable

Conservez les alias d'hôtes pour les utilisateurs, mais inspectez ce qu'OpenSSH fera réellement avant de transmettre une configuration à un agent. ssh -G affiche la configuration effective du client après traitement par OpenSSH des entrées Host correspondantes.

Cet exemple fait passer une cible nommée par un bastion nommé et désactive les options qui surprennent souvent les équipes :

Host agent-bastion
    HostName bastion.internal.example
    User agent-gateway
    IdentityFile ~/.ssh/agent_gateway
    IdentitiesOnly yes

Host prod-api-01
    HostName 10.42.8.19
    User deploy
    ProxyJump agent-bastion
    StrictHostKeyChecking yes
    UserKnownHostsFile ~/.ssh/agent_known_hosts
    ForwardAgent no
    RequestTTY no

Vérifiez ensuite les paramètres générés :

ssh -G prod-api-01 | grep -E '^(hostname|user|proxyjump|forwardagent|requesttty) '

La sortie devrait avoir la même forme que celle-ci :

user deploy
hostname 10.42.8.19
requesttty no
forwardagent no
proxyjump agent-bastion

Cela prouve comment le client prévoit de se comporter. Cela ne prouve pas que le réseau bloque SSH direct, que la cible présente la clé d'hôte attendue ou que le bastion limite ses sorties. Testez ces points séparément.

Ne laissez pas l'agent fournir librement des options ssh. Il peut remplacer la configuration avec des options de ligne de commande, spécifier une adresse IP brute, remplacer ProxyJump ou ajouter des options de transfert si la couche d'exécution transmet simplement une chaîne de shell. Structurez autant que possible la destination, le compte et les options SSH autorisées dans les entrées d'action. Si vous acceptez une commande brute, considérez-la comme du code et méfiez-vous-en autant que d'un script shell provenant d'une source non fiable.

La vérification des clés d'hôte mérite une attention particulière, car les agents réessaient automatiquement et considèrent souvent une erreur comme un obstacle à la tâche. Préchargez les empreintes d'hôtes approuvées au moyen d'un processus contrôlé. Gardez la vérification stricte activée. N'apprenez pas à l'agent à supprimer les entrées known-hosts ou à accepter des clés modifiées pour débloquer un déploiement. Une modification de clé d'hôte exige qu'un opérateur vérifie sa cause.

Les transferts et les shells créent des chemins qui contournent votre contrôle

Désactivez les transferts et les shells interactifs pour les agents autonomes, sauf si une tâche précise les exige. Ces deux fonctions transforment une commande distante limitée en canal d'accès plus large.

Le transfert local permet au client d'ouvrir un port local qui atteint un service interne par SSH. Le transfert distant permet à un endpoint distant d'exposer un chemin vers le côté client. Le transfert dynamique crée un proxy SOCKS. Le transfert d'agent rend des identifiants accessibles à un autre hôte. Chacune de ces fonctions peut être légitime pour un administrateur humain. Chacune affaiblit aussi l'affirmation selon laquelle le bastion est le seul chemin contrôlé.

OpenSSH fournit des restrictions côté serveur à placer sur la cible finale ou le compte du bastion, pas seulement dans la configuration client de l'agent. sshd_config(5) documente DisableForwarding, et authorized_keys prend en charge des options comme no-port-forwarding, no-agent-forwarding, no-X11-forwarding et no-pty. Utilisez les contrôles pris en charge par votre version d'OpenSSH, puis vérifiez-les avec une véritable tentative de connexion.

Une entrée de clé autorisée pour un compte restreint pourrait avoir cette forme :

no-port-forwarding,no-agent-forwarding,no-X11-forwarding,no-pty ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAI... agent-run

Cette ligne limite les fonctions pour cette clé publique. Elle ne limite pas les commandes que le compte peut exécuter. Associez-la à un compte contraint, à un wrapper ForceCommand ou à une interface spécifique au service si la portée des commandes est importante.

Pour les shells interactifs, adoptez une règle claire : n'en donnez pas un par défaut à un agent autonome. Un shell accepte des suites de commandes, des pipelines, des redirections, des processus en arrière-plan et des identifiants copiés. Le champ de commande de la demande d'action initiale ne décrira pas toute la session. Un wrapper forcé peut bloquer un shell, mais testez-le, car le comportement dépend de la configuration du compte et des demandes de sous-système SSH.

Certains travaux de maintenance exigent réellement un tunnel ou un shell. Traitez-les comme des chemins d'exception explicites, avec approbation d'un opérateur identifié et une durée courte. Cacher une exception dans un identifiant général d'agent est le moyen de transformer un accès temporaire en accès permanent.

Les restrictions de la cible valent mieux que les filtres de chaînes de commandes

Une simple liste d'autorisation fondée sur les préfixes de commandes shell est facile à contourner et difficile à maintenir. Elle plaît parce qu'elle semble précise : autoriser systemctl restart api, refuser tout le reste. La grammaire du shell rend cette confiance fragile.

Prenez un filtre qui accepte un texte commençant par systemctl restart api. Un appelant peut ajouter un opérateur shell, utiliser un autre chemin d'exécutable, provoquer un comportement via une variable d'environnement ou exploiter un wrapper qui analyse la chaîne différemment. Même un analyseur soigneux ne peut pas connaître tous les effets d'une commande qui appelle un autre programme.

Utilisez des opérations structurées lorsque le travail a une forme stable. Un exécuteur de déploiement peut accepter un nom d'application et un identifiant de version. Un endpoint de maintenance peut accepter le nom d'un service choisi dans une liste fixe. Un wrapper restreint peut associer un petit nom d'opération à un tableau argv fixe. Dans tous les cas, évitez complètement le shell.

Lorsque vous devez accepter des commandes libres, reconnaissez ce que vous autorisez : une autorité de shell distant pour ce compte. Journalisez-la, limitez la durée de l'identifiant, restreignez l'environnement cible et exigez un niveau d'approbation distinct. Ne présentez pas un filtre de chaîne comme une autorisation de commande.

Le compte cible doit aussi disposer d'une frontière de permissions au niveau du système d'exploitation. Un compte deploy qui peut exécuter sudo sans restriction est en pratique un compte administrateur avec davantage de saisie. Accordez-lui uniquement les actions sur les services, fichiers et répertoires nécessaires à son automatisation. Examinez ses règles sudo comme du code, y compris chaque chemin de commande et chaque modèle d'arguments.

Le test pratique consiste à vérifier si un agent chargé de redémarrer un service peut lire des secrets de production, créer un tunnel inverse, modifier les autorisations SSH ou altérer le collecteur d'audit. Si c'est possible, la portée du compte est incorrecte, même si chaque connexion a utilisé le bon bastion.

La réponse aux incidents commence par l'arrêt de la route active

Lorsqu'un agent se comporte de manière suspecte, révoquez son accès actif avant de reconstituer ses intentions. Désactivez sa session active à la frontière d'action si vous en avez une, bloquez sa source sur le bastion et empêchez l'identifiant associé de s'authentifier à nouveau. Conservez les journaux avant que quelqu'un ne fasse tourner les fichiers ou ne redémarre l'hôte qui contient les preuves.

Construisez ensuite une chronologie à partir des différents enregistrements. Commencez par l'action demandée par l'agent. Faites-la correspondre à la destination et à l'heure de la connexion sur le bastion. Faites ensuite le lien avec l'authentification de l'hôte final et les preuves de commande. Vérifiez si un TTY, une demande de transfert ou une autre destination est apparu. Une divergence n'est pas automatiquement malveillante, mais elle indique quel contrôle doit être examiné.

Ne réagissez pas en accordant définitivement davantage d'accès « pour que l'agent puisse réparer le problème ». C'est une réaction de panique fréquente. Si l'agent s'est déjà comporté de manière inattendue, élargir son compte ou ouvrir une route directe supprime les preuves dont vous avez besoin et crée un nouvel incident.

Faites un exercice simple avant d'en avoir besoin en production. Révoquez un agent de test pendant une commande SSH sans danger, vérifiez que les nouvelles demandes échouent et confirmez que vos enregistrements indiquent l'hôte demandé, la route réelle, l'identité de la cible et le résultat. Si cet exercice exige une discussion de groupe pour comprendre ce qui s'est passé, votre conception d'accès reste trop vague.

Un bastion justifie sa place lorsqu'il impose une route, permet une révocation rapide et apporte un fait précis à la piste d'audit. Configurez d'abord la route, gardez les identifiants hors de l'agent et recueillez les preuves sur l'hôte final, là où les commandes finales sont visibles. En dessous de ce niveau, vous n'avez qu'une commodité SSH affublée d'un nom à connotation sécuritaire.