Outils de sécurité pour agents à processus unique ou fondés sur un daemon

Un schéma de processus peut donner à un produit de sécurité une apparence rassurante de simplicité ou, au contraire, de grande sophistication. Aucune de ces impressions ne permet de savoir si un agent de programmation autonome peut détourner un identifiant, communiquer avec un service local imprévu ou laisser une action sans trace après un crash.

La comparaison utile est concrète : comptez les limites de confiance, examinez les interfaces qui les traversent et suivez un secret depuis son stockage jusqu'à la requête sortante. Une application à processus unique peut réduire le nombre d'éléments locaux. Un daemon peut isoler un privilège ou maintenir un service actif pour plusieurs clients. Les deux architectures échouent lorsque leurs concepteurs confondent séparation des processus et autorisation.

Le nombre de processus ne définit pas la limite de sécurité

Une architecture à processus unique place l'interface utilisateur, le coffre d'identifiants, l'état des approbations, la validation des requêtes, l'action réseau et la journalisation dans un même espace mémoire. Elle n'a pas de socket client local entre ses propres composants, ni d'enregistrement de service indépendant à maintenir, ni de protocole par lequel un processus local commande un autre processus. Cela peut réduire sensiblement la surface d'attaque.

Elle crée aussi un grand domaine de confiance. Si un attaquant obtient l'exécution de code dans ce processus, il peut atteindre tous les composants auxquels le processus a accès. Une corruption mémoire, le chargement d'un plugin malveillant, un mécanisme de mise à jour dangereux ou une interface de script trop large deviennent particulièrement graves, car le coffre et l'exécuteur se trouvent à côté du code applicatif ordinaire.

Une architecture fondée sur un daemon répartit ces tâches. Une application de bureau ou un client en ligne de commande envoie une requête à un service d'arrière-plan. Le service peut conserver les secrets et effectuer l'appel réseau, tandis que le client affiche les approbations et reçoit les résultats. Cela peut limiter ce qu'un client compromis est capable de faire, mais uniquement si le daemon refuse les requêtes que le client n'est pas autorisé à envoyer.

Cette condition est souvent oubliée dans les discussions d'architecture. Un socket Unix limité à un seul compte utilisateur fournit un accès au transport, pas la preuve que l'appelant est l'agent ou l'application approuvée. Tous les processus exécutés par cet utilisateur peuvent peut-être l'ouvrir. Si le daemon accepte d'un pair local quelconque une requête telle que « utiliser l'identifiant X avec l'URL Y », une extension d'éditeur malveillante, un script shell ou un agent compromis peut demander la même action.

Il faut distinguer trois notions :

• Une limite de processus sépare les espaces mémoire.
• Une limite de privilège restreint ce que le code peut faire après une compromission.
• Une limite d'autorisation détermine quel appelant peut demander quelle action.

Les équipes prennent régulièrement la première pour une preuve des deux autres. C'est une erreur. Deux processus exécutés par le même utilisateur avec un canal IPC non authentifié ont des tas mémoire distincts, mais peuvent toujours appartenir à un seul domaine d'autorisation.

Un processus unique évite le problème d'autorisation IPC, car ses appels internes ne franchissent pas une limite de service locale. Cela ne dispense pas d'identifier une session d'agent externe avant d'approuver une action. Un daemon ajoute ce problème d'identification deux fois : à son endpoint client et souvent à chaque endpoint administratif qu'il expose.

Un socket local est une API que du code hostile peut appeler

Les défenseurs des daemons affirment souvent, à juste titre, que le service n'écoute que sur localhost ou sur un socket Unix. Ce qu'ils omettent, c'est que le code local est l'environnement où s'exécutent la plupart des intégrations d'agents. L'agent de programmation, le terminal, l'éditeur, les scripts de build, les hooks de paquets et les assistants de navigateur partagent tous la même machine.

Traitez un endpoint IPC local comme une petite API réseau. Définissez précisément les formats de message. Refusez les champs inconnus lorsque le protocole le permet. Associez chaque requête à l'identité de l'appelant et à une session de courte durée. Limitez la taille des requêtes, la concurrence et les destinations possibles. Journalisez les requêtes refusées comme les requêtes réussies, car des refus répétés peuvent révéler qu'une intégration tente de contourner le parcours prévu.

Sur macOS, inspectez un outil avant de croire son affirmation selon laquelle il est uniquement local :

ps -axo pid,ppid,user,command | grep -i '[a]gent\\|[d]aemon'
lsof -nP -iTCP -sTCP:LISTEN
launchctl print gui/$(id -u) 2>/dev/null | grep -i -C 2 'agent\\|vault\\|security'

La deuxième commande affiche généralement des colonnes de cette forme lorsqu'un processus écoute sur TCP :

COMMAND   PID USER   FD   TYPE             DEVICE SIZE/OFF NODE NAME
service  4128 sam     9u  IPv4 0x...            0t0  TCP 127.0.0.1:48120 (LISTEN)

L'absence de sortie de lsof ne prouve pas que l'outil n'utilise aucune IPC. Les sockets Unix n'apparaissent pas dans cette requête TCP. Vérifiez les répertoires de support des applications, les répertoires temporaires et la documentation du service pour trouver les chemins des sockets. Vérifiez ensuite les permissions avec ls -l et demandez-vous si un autre processus appartenant à votre compte peut se connecter.

Le manuel Apple consacré à launchd.plist décrit KeepAlive comme un ensemble de conditions dans lesquelles launchd redémarre un job. C'est utile sur le plan opérationnel, mais cela crée une obligation de sécurité. Un service qui redémarre doit restaurer correctement son état verrouillé, son état de session et son état d'audit. « Il revient automatiquement » ne répond pas à la question de ce qu'il accepte pendant la première seconde qui suit son redémarrage.

Un bon daemon fait de l'identité de l'appelant une partie du protocole, plutôt qu'une hypothèse fournie par le client. Le mécanisme exact dépend du système d'exploitation. Sur les plateformes capables d'exposer les identifiants du pair d'un socket local, utilisez-les. Lorsque les informations de signature de code sont disponibles, vérifiez-les avant d'accorder une session. N'acceptez pas comme identité un nom de processus, un PID fourni en JSON ou un chemin saisi par l'appelant. Ces trois éléments sont faciles à falsifier ou peuvent être périmés lorsque vous les vérifiez.

Le comportement au démarrage détermine si la protection existe au moment nécessaire

Une application à processus unique démarre généralement lorsque l'utilisateur ouvre l'application. Son état sensible suit un cycle de vie simple : l'application démarre, l'utilisateur la déverrouille, les sessions approuvées s'exécutent, puis la fermeture ou le crash de l'application met fin à l'accès. C'est facile à expliquer et à tester.

Le coût est la disponibilité. Un agent en ligne de commande ne peut pas utiliser la passerelle lorsque l'application est fermée, encore en cours de lancement, verrouillée ou bloquée par une demande d'autorisation système. C'est peut-être exactement le comportement souhaité pour une passerelle d'identifiants contrôlée par un humain. C'est en revanche peu adapté si la tâche doit s'exécuter sans surveillance après un redémarrage et si le produit ne permet pas de récupérer son autorité de manière sûre.

Un daemon démarre généralement à la connexion, à la demande ou au démarrage du système. Chaque choix modifie le modèle de menace. Un service lancé à la connexion peut attendre le trousseau de l'utilisateur et sa session de bureau. Un service lancé au démarrage peut fonctionner avant que l'utilisateur ne puisse approuver quoi que ce soit. Un service lancé à la demande peut réduire l'exposition au repos, mais sa première requête ne doit pas entrer en concurrence avec son initialisation.

J'ai vu la version la plus problématique de cet échec : l'interface se lance lentement, le service d'arrière-plan accepte déjà des requêtes et traite « aucun état d'approbation chargé » comme « aucune approbation requise ». Les développeurs écrivent cette branche pour éviter une erreur au démarrage. Les attaquants et les automatisations instables ne se soucient pas de sa raison d'être.

Écrivez explicitement la machine à états. Elle doit répondre sans approximation aux questions suivantes :

1. L'exécuteur peut-il accepter une requête avant que le coffre signale qu'il est verrouillé ou déverrouillé ?
2. Que devient une approbation liée à un processus client lorsque ce processus se termine ?
3. Que fait le service après un redémarrage alors qu'une requête est en cours ?
4. Une demande utilisateur en attente peut-elle survivre à un redémarrage et être associée à un autre appelant ?
5. La déconnexion révoque-t-elle l'état utilisable des identifiants du service ?

Pour les actions à haut risque, refusez par défaut pendant toute transition ambiguë. Une requête reçue pendant l'initialisation du service doit recevoir un refus explicite ou une réponse temporaire indiquant que le service est indisponible. Elle ne doit pas hériter d'une ancienne approbation, d'un identifiant déchiffré en cache ou d'une décision d'autorisation par défaut.

Le démarrage influence aussi le comportement des utilisateurs. Si un parcours avec un agent échoue parce qu'il faut relancer manuellement un service caché, les utilisateurs désactiveront la barrière ou stockeront un jeton dans une variable d'environnement. Les contrôles de sécurité qui ne résistent pas au sommeil, à la déconnexion et au redémarrage ordinaires apprennent aux utilisateurs à les contourner.

Les identifiants doivent parvenir à l'exécuteur sans passer par l'agent

La question centrale n'est pas de savoir si un outil chiffre un coffre. Il faut savoir si l'agent reçoit un jour le secret sous une forme qu'il peut copier, afficher, placer dans un fichier ou transmettre à un autre endpoint.

La disposition la plus sûre garde l'identifiant dans un coffre contrôlé par la passerelle. L'agent envoie une demande d'action. La passerelle vérifie son état d'autorisation, injecte l'identifiant dans la requête HTTP sortante ou dans l'opération SSH, exécute l'action et renvoie le résultat. L'agent reçoit les données produites par le système distant, pas le jeton bearer ni la clé privée.

Cette distinction est importante, car les agents travaillent avec du texte. Si un jeton apparaît dans la sortie d'un outil, un modèle peut le recopier dans une commande shell, un fichier source, la description d'un ticket, un journal de build ou une transcription de conversation. Masquer ensuite un champ dans l'interface ne répare pas l'exposition. Le secret a déjà franchi la limite.

Le guide OWASP Secrets Management Cheat Sheet conseille d'éviter les secrets codés en dur et de les renouveler lorsqu'une exposition est suspectée. Ce conseil est juste, mais incomplet pour les parcours avec des agents. Un secret peut éviter le contrôle de version et tout de même fuiter par la réponse d'un outil. La passerelle doit empêcher la divulgation au moment où elle exécute l'action.

Un daemon peut bien protéger cette limite lorsqu'il contrôle le déchiffrement et les communications sortantes. Le client envoie une description d'opération, jamais une demande de secret en clair. Le daemon doit également éviter de renvoyer des diagnostics trop détaillés. Une réponse d'authentification échouée peut indiquer à l'appelant qu'une requête a échoué. Elle n'a pas besoin de renvoyer l'en-tête d'autorisation injecté, une configuration SSH sérialisée ou un dump mémoire du fournisseur d'identifiants.

Un processus unique peut appliquer la même règle. Son exécuteur interne lit le coffre et effectue l'appel, tandis que l'agent communique via un point d'intégration limité. L'avantage est qu'aucun second processus n'a besoin d'accéder aux données déchiffrées. Le risque est que les fonctions ordinaires de l'application se trouvent dans le même domaine mémoire que le secret.

Évitez ces architectures tentantes :

• Placer les jetons d'API dans les variables d'environnement du processus agent.
• Écrire un fichier d'identifiant temporaire lu par un sous-processus.
• Renvoyer un espace réservé qu'un client échange ensuite contre le véritable jeton.
• Exposer une méthode « get secret » par un daemon local pour des raisons pratiques.
• Transmettre les octets d'une clé privée SSH via l'entrée standard.

Le modèle de l'espace réservé mérite une suspicion particulière. Il n'est sûr que s'il ne donne jamais accès aux identifiants en dehors de la passerelle et s'il ne peut pas être rejoué par un autre processus. En pratique, les équipes en font souvent un jeton bearer non documenté. Elles ont alors créé un deuxième identifiant dont les contrôles de cycle de vie sont plus faibles.

Pour SSH, la même discipline s'impose. Un assistant peut devoir utiliser une clé pour établir une connexion, mais l'agent doit lui demander d'exécuter une commande distante précise ou une opération de connexion strictement limitée. Donner une clé privée à un agent parce qu'il « n'en a besoin que brièvement », c'est tout de même lui donner une clé privée.

Plus de processus signifie plus de maintenance, pas plus de maturité

Un daemon implique un travail opérationnel qu'une application de bureau à processus unique évite. Quelqu'un doit l'installer, le démarrer dans le bon contexte utilisateur ou système, le mettre à jour, vérifier son binaire, gérer les crashes, supprimer les anciens enregistrements et s'assurer que le socket et les fichiers journaux ont les bonnes propriétés après les mises à niveau.

Ce n'est pas un argument contre les daemons. C'est un argument contre l'idée que ces tâches disparaissent dans le système d'exploitation. launchd peut redémarrer un job. Il ne peut pas déterminer si un nouveau binaire conserve les vérifications attendues de l'appelant, si un ancien socket a survécu à une mise à niveau ou si un service démarre désormais avec un autre ensemble d'autorisations.

Un daemon complique aussi la correspondance des versions. Une passerelle en ligne de commande peut parler le protocole A alors que le service installé attend le protocole B. Si les auteurs gèrent mal ce décalage, le client revient à un parcours de compatibilité non authentifié ou désactive les contrôles pour préserver une expérience fluide. Le code de compatibilité a causé plus de problèmes que prévu, car il s'exécute précisément lorsque le système est le moins bien compris.

Refusez explicitement les versions incompatibles. Le message doit demander à l'utilisateur de mettre à jour l'un des deux composants, et non négocier silencieusement un mode plus faible. Gardez le protocole assez petit pour tester les anciens clients, les redémarrages du service, les messages malformés et les requêtes concurrentes sans construire tout un laboratoire autour de lui.

Les applications à processus unique ont tout de même besoin d'une discipline de mise à jour. Une application signée peut modifier sa propre implémentation et son schéma de coffre. La différence est plus limitée : il n'y a qu'un cycle de vie exécutable à inspecter, et le processus qui présente l'approbation est le même que celui qui effectue l'action protégée. Une mise à jour peut toujours introduire une faille, mais elle n'introduit pas automatiquement un protocole RPC local et l'état d'un gestionnaire de services.

Le compromis devient plus net pour les équipes. Un daemon central peut fournir un endpoint local stable à plusieurs outils, ce qui peut réduire le nombre d'intégrations en double. Il peut aussi devenir un point de défaillance partagé. Un seul service bloqué peut interrompre tous les parcours de développement sur la machine. Un service disposant de permissions trop larges peut donner à chaque client local accès à tous les identifiants configurés.

Ne prenez pas une icône d'arrière-plan dans la barre des menus pour une preuve de bon fonctionnement du daemon. Testez les cas difficiles : forcez la fermeture de l'interface, arrêtez le service, redémarrez pendant une session active, mettez d'abord le client à jour, mettez d'abord le service à jour et supprimez un identifiant pendant qu'une requête attend une approbation. Si la réponse à l'un de ces cas est « il devrait probablement récupérer », vous ne connaissez pas encore le comportement opérationnel.

L'approbation doit appartenir à une exécution identifiée, pas à une machine mémorisée

Les systèmes d'approbation échouent lorsqu'ils autorisent une notion vague comme « cet ordinateur » ou « l'utilisateur actuel ». Les agents autonomes lancent souvent des processus enfants, redémarrent après des modifications et appellent des outils par l'intermédiaire de shells. Une permission qui suit toute cette activité est trop large pour avoir une réelle signification.

Associez l'approbation à une exécution précise du processus ou à une autre identité qu'un code local sans rapport ne peut pas copier. L'écran d'approbation doit afficher suffisamment de provenance pour qu'un humain remarque une anomalie : l'autorité de signature de l'exécutable, le chemin de commande et la catégorie de requête sont de meilleurs indices qu'un simple nom convivial de client. N'importe qui peut choisir un nom de processus.

Rendez ensuite la durée explicite. Une approbation pour une courte session d'agent peut convenir à des appels répétés peu risqués. Les identifiants sensibles peuvent exiger un consentement à chaque utilisation. La révocation doit arrêter immédiatement l'exécution identifiée, et pas seulement la masquer dans un tableau de bord pendant que sa connexion locale reste ouverte.

Un daemon a ici une obligation supplémentaire. Il doit associer une connexion IPC à l'identité approuvée par une personne et supprimer cette association lorsque le client se termine ou se reconnecte. Ne laissez jamais un client reprendre une ancienne session en présentant simplement un identifiant mis en cache. Si l'identifiant peut circuler dans un fichier ou un argument de commande, c'est un identifiant bearer sous un nom sophistiqué.

Une architecture à processus unique peut conserver l'état d'approbation à côté de l'intégration active, ce qui réduit le travail d'association. Elle doit tout de même distinguer un lancement d'agent d'un autre. Si l'application ne peut pas savoir si une requête vient de l'exécution approuvée ou d'un processus de remplacement lancé plus tard, elle doit demander une nouvelle approbation.

La règle utile est généralement plus simple que ce que les équipes imaginent : refuser lorsque le coffre est verrouillé, demander une fois l'approbation pour une nouvelle exécution identifiée et exiger une confirmation individuelle pour les identifiants qui justifient cette contrainte. Les langages de règles locales complexes produisent souvent des règles que personne ne peut auditer sous pression. Un chemin de décision court, prévisible pour les utilisateurs, est plus facile à tester et plus difficile à contourner accidentellement.

Un échec au redémarrage révèle la faiblesse de l'architecture

Imaginez un développeur qui a autorisé un agent de programmation à effectuer des appels HTTP ordinaires pendant une session de terminal active. La passerelle conserve l'approbation en mémoire. L'agent envoie une requête et la passerelle commence à préparer l'appel sortant. À ce moment-là, l'interface plante ou l'exécuteur d'arrière-plan redémarre après une mise à jour.

Une implémentation négligente d'un daemon peut aggraver la situation de plusieurs façons. L'exécuteur renvoie une réponse avant d'avoir chargé l'état de verrouillage du coffre. Son socket client réapparaît au même chemin. L'agent se reconnecte. Le daemon voit un identifiant de session en cache dans la requête et suppose que l'ancienne approbation reste valide. Pendant ce temps, son écrivain d'audit n'a pas rouvert le journal, si bien que la nouvelle réussite n'a pas de trace durable.

Chaque décision prise séparément semble pratique : conserver une session, réduire les demandes d'approbation, redémarrer rapidement, mettre les journaux en mémoire tampon. Ensemble, elles créent une action non approuvée au moment où le système dispose de l'état le moins fiable.

Le comportement sûr est plus simple. Au redémarrage, supprimez les approbations volatiles. Gardez le coffre indisponible jusqu'à ce que son état de protection soit connu. Refusez les nouvelles actions jusqu'à ce que l'écrivain d'audit puisse enregistrer une trace. L'agent doit recevoir un refus ou une réponse temporaire d'indisponibilité, puis demander une nouvelle approbation si la session n'existe plus.

Vous pouvez tester cela sans matériel particulier :

1. Ouvrez une nouvelle session d'agent et approuvez une requête autorisée à faible impact.
2. Lancez une autre requête qui attend au niveau d'une approbation ou d'un endpoint de test.
3. Arrêtez le processus ou le service de sécurité pendant l'attente.
4. Redémarrez-le et relancez la requête depuis le processus agent d'origine.
5. Vérifiez qu'une nouvelle autorisation est nécessaire et que le résultat final apparaît une seule fois dans l'enregistrement d'audit.

Répétez le test avec une reconnexion du client, le verrouillage de l'appareil, la suppression d'un identifiant et une mise à niveau. Cherchez une autorité obsolète, une exécution en double ou des enregistrements manquants. Un outil incapable de rendre ces résultats visibles est difficile à considérer comme fiable lors d'un incident.

Les enregistrements d'audit ont besoin d'un écrivain impossible à contourner

Les journaux de sécurité enregistrent souvent ce que l'interface utilisateur a vu, et non ce que l'exécuteur d'identifiants a fait. Cette différence devient grave lorsqu'un daemon accepte directement des requêtes locales. Un client compromis peut ignorer l'interface, ou l'interface peut planter après l'action de l'exécuteur.

Placez l'écriture d'audit sur le parcours de l'action. Le composant qui envoie la requête HTTP ou invoque l'assistant SSH doit enregistrer l'identité de l'appelant, la référence de l'identifiant, la destination, la catégorie de requête, la décision et le résultat. Ne journalisez pas les secrets bruts ni les corps de requête par défaut. Des journaux contenant des jetons bearer deviennent un autre coffre, avec des contrôles d'accès plus faibles.

Un processus unique peut rendre cet ordre direct : valider, enregistrer la décision, exécuter et enregistrer le résultat. Un daemon doit s'assurer que son propre exécuteur ne peut pas effectuer une requête par un canal parallèle qui contourne le composant de journalisation. Ne séparez la journalisation de l'exécution par IPC que si vous pouvez accepter le mode d'échec et prouver l'ordre des opérations.

La preuve d'altération compte après une compromission, et pas seulement lors du dépannage courant. Si un attaquant peut modifier un fichier SQLite local ou supprimer certaines lignes d'un journal texte, l'enregistrement peut aider au débogage, mais il n'établit pas un historique fiable. Un enregistrement orienté ajout avec chaînage cryptographique donne aux enquêteurs un moyen de détecter les modifications, à condition de conserver les fichiers nécessaires et de les vérifier.

Sallyport projette les vues des sessions et des appels à partir d'un seul journal d'audit chiffré et chaîné par hachage, et sa commande sp audit verify vérifie la chaîne hors ligne sans nécessiter de clé de coffre. Cette conception répond à un problème que créent souvent des journaux séparés pour l'interface et le daemon : deux enregistrements qui ne concordent pas sur le fait qu'une action a eu lieu.

Ne surestimez pas ce que l'audit peut faire. Une chaîne ne peut pas restaurer un événement qu'un attaquant a empêché le programme d'écrire. Elle peut détecter les modifications dans l'ensemble d'enregistrements qu'elle reçoit. C'est déjà utile, notamment lorsqu'un crash, une mise à niveau ou un client local inattendu vous oblige à reconstituer une séquence après coup.

Choisissez l'architecture minimale adaptée au cycle de vie nécessaire

Choisissez un processus unique lorsque le travail protégé se déroule en présence d'un humain, que l'application peut rester ouverte pendant l'exécution des agents et que la réduction des endpoints locaux est plus utile que la survie indépendante de l'interface. Cette architecture convient à une passerelle d'identifiants dont la promesse principale est qu'une personne voit et contrôle chaque exécution d'agent.

Choisissez un daemon lorsque la tâche a réellement besoin de la continuité d'un service, d'une séparation avec un client moins fiable ou d'un privilège distinct du système d'exploitation. Exigez une réponse pour chaque interface ajoutée : qui se connecte, comment le service l'identifie, quelle requête cette personne ou ce processus peut effectuer, quand l'état expire et ce qui arrive lorsque l'un ou l'autre redémarre.

Un outil de bureau comme Sallyport adopte la voie de l'application à processus unique tout en utilisant un shim MCP standard pour les requêtes des agents. Son coffre effectue lui-même l'action HTTP ou SSH, de sorte que l'agent ne reçoit jamais l'identifiant API ou SSH configuré.

Avant d'adopter l'un ou l'autre modèle, effectuez une vérification sans complaisance. Arrêtez le composant qui détient l'autorité pendant qu'un agent travaille, redémarrez-le et vérifiez si la requête suivante est refusée, soumise à une nouvelle approbation et journalisée. Ce test révèle davantage sur l'architecture qu'un schéma bien présenté ne le fera jamais.