Macs de développement partagés : contrôlez l'accès des agents aux outils

Un Mac de développement partagé peut servir à toute une équipe, mais il ne peut pas exécuter des agents autonomes en toute sécurité si chaque personne et chaque processus local héritent du même ensemble d'identifiants. Le problème commence souvent par une commodité : un jeton de projet dans un fichier du shell, une clé SSH chargée une fois, un éditeur lancé depuis un ancien terminal et un agent à qui l'on demande de « simplement effectuer la mise en production ». Peu après, plus personne ne sait quelle personne a autorisé l'action ni quel processus a encore accès.

Traitez l'identité, la garde des identifiants, l'autorisation et les preuves comme des fonctions distinctes. Une session macOS vous indique quel utilisateur possède un processus. Elle ne prouve pas qui possède un jeton cloud, si un agent doit l'utiliser ni si un processus resté actif depuis la pause déjeuner doit encore conserver son accès. Lorsque les équipes mélangent ces responsabilités, elles créent une forme très discrète d'extension progressive des privilèges.

Les machines partagées ont besoin d'identités distinctes

Un poste de travail partagé n'est viable que si chaque personne, chaque identifiant et chaque exécution d'agent ont une identité distincte que vous pouvez examiner et révoquer. La session de la machine est la première limite, pas toute l'architecture.

Ne créez pas un compte « dev » unique pour tout un groupe sous prétexte que sa maintenance semble plus simple. Ce compte rend collectifs la propriété des fichiers, l'historique du shell, les sessions de navigateur, les entrées du trousseau et les processus en cours. Quand un déploiement échoue, l'audit indique seulement que le compte partagé l'a effectué. Ce n'est pas de la responsabilité. C'est une impasse.

Donnez à chaque développeur un compte macOS distinct et utilisez une identité de service séparée pour les tâches sans surveillance qui en ont réellement besoin. Une identité de service doit avoir un propriétaire, une finalité déclarée, un ensemble restreint d'identifiants et un plan de retrait. Elle ne doit pas devenir un compte d'équipe déguisé que les utilisateurs prennent parce que leur propre configuration est moins pratique.

Cette distinction compte particulièrement pour un agent. Un agent de programmation peut lancer des sous-processus, lire son répertoire de travail, examiner l'environnement dont il a hérité et appeler les outils autorisés. Si deux personnes exécutent des agents avec le même compte local, l'ancien environnement ou le processus auxiliaire de l'une peut devenir l'autorité accidentelle de l'autre.

Apple Platform Security décrit les protections des comptes macOS concernant la séparation des données utilisateur et des services système. Ces protections sont importantes, mais elles ne déterminent pas si un jeton copié dans un dépôt, un répertoire partagé ou l'environnement d'un processus convient au processus qui le trouve. Les permissions de fichiers limitent une catégorie d'erreurs. Elles n'établissent pas l'intention.

Tenez une fiche de propriété simple pour chaque identifiant capable de modifier des systèmes de production, le contrôle de version, la publication de paquets ou les données clients :

• Nommez un propriétaire humain et un contact de secours.
• Précisez le service, les opérations autorisées et les environnements concernés.
• Notez où le secret est conservé et comment il est renouvelé.
• Fixez une date de révision et un déclencheur de retrait.

Évitez de mettre le secret lui-même dans cette fiche. Le but est de rendre la propriété visible, pas de créer une copie supplémentaire d'un identifiant.

Un propriétaire identifié ne signifie pas qu'il doit effectuer chaque action manuellement. Cela signifie que quelqu'un peut répondre à une question directe : pourquoi cet identifiant existe-t-il, qui peut l'autoriser et que se passera-t-il si nous le révoquons maintenant ? Si personne ne peut répondre, révoquez-le pendant une période sûre et recréez l'accès avec une finalité plus claire.

Un compte Unix ne contient pas un secret copié

Les limites d'un compte macOS protègent les données uniquement tant que l'identifiant reste dans cette limite et n'est pas proposé par un autre chemin. Les équipes sécurisent souvent le répertoire personnel, puis laissent le même jeton dans des fichiers de projet, l'historique du terminal, les réglages de l'éditeur, les exports CI ou un processus d'agent qui reste actif pendant longtemps.

Commencez par un inventaire des emplacements réellement utilisés par les développeurs. Faites-le avec autorisation et prudence : afficher un secret actif dans le défilement d'un terminal partagé crée précisément le problème que vous cherchez.

# Search filenames and likely configuration references, not secret values.
find "$HOME" -maxdepth 3 \( -name '.env' -o -name '.netrc' -o -name 'credentials*' \) -print

# Show environment variable names for the current shell only.
env | cut -d= -f1 | grep -E 'TOKEN|SECRET|KEY|PASSWORD' || true

# Show loaded SSH identities without printing private key material.
ssh-add -l

La dernière commande affiche normalement une ligne par identité, avec une empreinte, un algorithme et un commentaire. Si elle affiche The agent has no identities., c'est un résultat utile. Si elle affiche une empreinte que vous ne pouvez pas expliquer, cessez de considérer la machine comme saine et cherchez quel processus a chargé cette identité.

N'exécutez pas env dans la transcription d'un agent pour en copier la sortie dans un ticket. Les agents, les terminaux, les journaux d'éditeurs et les tickets d'assistance sont de mauvais coffres à secrets. Recherchez d'abord les noms de variables et les emplacements de fichiers. Renouvelez un identifiant si vous avez des raisons de penser que sa valeur est entrée dans une transcription ou l'historique d'un dépôt.

Une recommandation souvent présentée comme sûre dit : « Placez les secrets dans un fichier .env et excluez-le de Git. » Elle est populaire parce qu'elle fonctionne en cinq minutes. Elle transforme aussi chaque programme lancé depuis ce répertoire en lecteur potentiel d'identifiants. Une entrée .gitignore empêche un commit. Elle n'empêche pas un agent local de lire le fichier, un outil d'archivage de le collecter ou un développeur de le copier dans le projet suivant.

Utilisez les fichiers .env uniquement pour des réglages locaux peu sensibles ou un travail de migration temporaire avec une date de nettoyage définie. Pour les identifiants capables de modifier des systèmes partagés, gardez la valeur dans un stockage local protégé et exposez une opération à l'agent, pas la valeur brute.

L'héritage des processus mérite la même méfiance. Un terminal exporte DEPLOY_TOKEN ; un éditeur est lancé depuis ce terminal ; une extension démarre un serveur de langage ; un agent appelle un outil via l'éditeur. Le développeur d'origine a peut-être oublié le jeton depuis des heures, mais chaque processus enfant peut encore le lire. Les permissions macOS ont fait exactement ce qui leur était demandé. C'est l'équipe qui a donné le secret à trop de processus.

La garde des identifiants et l'autorité d'action sont deux choses différentes

Un identifiant répond à la question « qui peut s'authentifier ? » L'autorisation répond à la question « ce processus peut-il effectuer cette action maintenant ? » Les équipes confondent souvent la possession du premier avec la preuve du second, surtout avec les jetons API.

Ne transmettez pas un jeton bearer à un agent simplement parce que celui-ci doit effectuer un appel API. Un jeton bearer agit comme son détenteur pour la portée qu'il contient. Dès que le jeton apparaît dans le contexte d'un agent, un argument d'outil, l'environnement d'un processus enfant ou une sortie de débogage, vous devez supposer que tout système capable de lire ces éléments peut le réutiliser.

Définissez plutôt un contrat d'action. L'agent demande une opération nommée avec des entrées structurées. Un composant local de confiance conserve l'identifiant, vérifie la destination autorisée et la forme de la requête, effectue l'appel puis renvoie le résultat. L'agent ne reçoit jamais un emplacement vide qu'il pourrait remplir plus tard depuis une autre source. Il ne reçoit aucun identifiant.

Par exemple, un agent de mise en production peut devoir créer un enregistrement de déploiement. Sa requête peut se présenter ainsi :

{
  "action": "create_deployment",
  "environment": "staging",
  "revision": "7c31f4a",
  "summary": "Fix request timeout handling"
}

Le composant de confiance peut associer create_deployment à un seul endpoint autorisé et à un identifiant conservé. Il doit refuser une entrée qui tente de fournir un hôte, un chemin, un en-tête d'autorisation ou un corps de requête arbitraire. Si le contrat d'action autorise des URL et des en-têtes arbitraires, il a recréé un accès réseau général avec davantage de cérémonial.

Gardez la portée de l'identifiant suffisamment réduite pour qu'une erreur ait des conséquences limitées. Séparez les accès en lecture et en écriture. Séparez la préproduction de la production. Préférez les identifiants de courte durée lorsque le service en amont les prend en charge, mais ne considérez pas une durée courte comme un remède à une portée trop large. Un jeton qui ne vit que quelques instants peut tout de même effectuer un appel irréversible dès sa première seconde.

La même distinction s'applique à SSH. Une clé privée SSH prouve le contrôle d'un principal. Elle n'explique pas pourquoi un agent local devrait exécuter une commande sur un hôte à cet instant. Intégrez la sélection de la commande et de l'hôte à la décision d'autorisation. Ne donnez pas à un agent un accès shell général en espérant que les instructions du dépôt le retiendront.

Les processus locaux peuvent emprunter plus d'autorité que prévu

Un processus local peut hériter d'une autorité par des variables d'environnement, des descripteurs de fichiers ouverts, des sockets Unix, des sessions de navigateur et des services auxiliaires. Le processus risqué n'est souvent pas malveillant. Il est obsolète, mal configuré ou lancé par quelqu'un qui ne savait pas ce que son processus parent avait déjà accordé.

Inspectez un processus suspect avant de le tuer. Sur macOS, ces commandes fournissent des indices utiles sans exposer les valeurs des identifiants :

ps -axo pid,ppid,user,command | grep -i '[a]gent\|[c]laude\|[n]ode\|[p]ython'
lsof -nP -p <PID> | grep -E 'cwd|unix|TCP|IPv4|IPv6'

La première commande affiche l'identifiant du processus, celui de son parent, le compte et la commande de lancement. La seconde affiche généralement le répertoire de travail, les chemins des sockets Unix et les connexions réseau ouvertes. Un répertoire de travail situé dans un ancien projet et un terminal parent provenant d'une session passée expliquent davantage d'incidents que les logiciels malveillants exotiques.

Ne supposez pas qu'un processus s'est arrêté parce que sa fenêtre a disparu. Les éditeurs maintiennent des serveurs de langage actifs. Les multiplexeurs de terminaux conservent les shells. Les outils de build lancent des observateurs. Un client MCP local peut maintenir une connexion longtemps après que le développeur a cessé d'y prêter attention.

Faites de la fin des accès une action volontaire. Quittez le client de l'agent, arrêtez la session du terminal qui l'a lancé et supprimez toute autorisation temporaire accordée pour cette exécution. Si un assistant doit rester actif, notez sa finalité et rendez son identité de processus visible à la personne qui approuve l'accès.

Un test pratique de transmission permet de détecter rapidement les problèmes. Le développeur A exécute un agent ayant accès à une action de préproduction, puis ferme l'agent et se déconnecte. Le développeur B se connecte à son propre compte et lance une requête inoffensive. B ne doit pas pouvoir trouver le répertoire du projet de A, ses variables d'environnement, son socket SSH, sa session de navigateur ni son autorisation active. Si B peut atteindre l'un de ces éléments, l'équipe dispose d'un état partagé à supprimer.

Ne résolvez pas ce problème en faisant des développeurs des administrateurs. Les droits d'administration peuvent être nécessaires pour gérer le système, mais ils élargissent les conséquences d'un installateur imprudent ou d'un script local. Utilisez un compte standard pour le travail quotidien avec les agents, sauf si une tâche précise exige une élévation. Dans ce cas, élevez les droits pour cette tâche, puis revenez à un usage normal.

Les agents SSH doivent être surveillés autant que les clés privées

Un agent SSH conserve une autorité de signature derrière un socket local. Un processus capable d'atteindre ce socket peut donc demander des signatures sans lire le fichier de clé privée. C'est préférable à la dispersion de clés privées sur le disque, mais cela ne donne pas carte blanche à tous les processus du poste de travail.

OpenSSH définit SSH_AUTH_SOCK comme le chemin vers le socket de l'agent. Considérez cette variable d'environnement comme une information de routage sensible. Si un agent en hérite, il peut être capable de demander des signatures aux identités actuellement chargées dans l'agent SSH. La clé privée reste cachée, mais le risque opérationnel demeure.

Exécutez ceci avant d'utiliser une automatisation sur un système distant :

printf '%s\n' "${SSH_AUTH_SOCK:-SSH_AUTH_SOCK is unset}"
ssh-add -l
ssh -G [email protected] | grep -E '^(hostname|user|identityfile|forwardagent) '

ssh -G affiche la configuration effective du client OpenSSH. La sortie comprend des lignes telles que user deploy, identityfile ... et forwardagent no. Vérifiez attentivement la dernière ligne. Le transfert de l'agent permet à un hôte distant d'utiliser votre agent local via la connexion transférée. Il doit rester désactivé, sauf si vous pouvez expliquer exactement le saut distant concerné et la raison pour laquelle il en a besoin.

Le manuel ssh_config d'OpenSSH décrit ForwardAgent et avertit que le transfert peut exposer l'agent local aux utilisateurs disposant d'un accès suffisant sur l'hôte distant. Les équipes l'activent encore largement parce qu'il évite de copier les clés et rend pratique l'utilisation d'un hôte relais. Cette commodité est réelle. Le fait qu'un environnement distant compromis ou trop permissif puisse demander des signatures pendant toute la durée de la session transférée l'est aussi.

Utilisez des identités distinctes pour les catégories d'accès distinctes. Une identité de déploiement en production ne doit pas se trouver à côté d'une identité personnelle de contrôle du code dans un même agent simplement parce que toutes deux sont utiles au développement. Supprimez les identités après la tâche lorsque c'est possible :

ssh-add -d ~/.ssh/id_staging_deploy
# Or clear every identity after a short, dedicated session.
ssh-add -D

Supprimer toutes les identités peut interrompre d'autres travaux légitimes. Faites-le à la fin d'une session dédiée, et non dans un onglet shell partagé dont dépend une autre personne. La meilleure approche reste d'éviter complètement les shells partagés.

Évitez de placer les chemins des clés privées, les alias d'hôtes et les règles de transfert permissives dans une configuration de dépôt que chaque développeur adopterait aveuglément. Un dépôt peut documenter l'hôte et le compte attendus. Chaque développeur doit décider quelle identité locale peut y accéder.

L'approbation doit nommer le processus et l'action

Une demande d'approbation n'est utile que si un humain peut identifier l'appelant, comprendre l'opération demandée et révoquer l'autorisation une fois le travail terminé. Une demande qui dit simplement « autoriser l'accès » habitue les utilisateurs à approuver le bruit.

L'approbation par session convient au travail de développement courant. Le premier appel d'un agent nouvellement lancé affiche l'identité de l'appelant et l'utilisateur décide si cette exécution peut utiliser un canal d'action. L'autorisation doit prendre fin lorsque le processus se termine, et non rester comme une préférence invisible.

L'approbation à chaque appel convient aux actions aux conséquences disproportionnées : suppression en production, publication d'un paquet, modification d'un réglage de paiement ou exécution d'une commande sur un hôte sensible. Elle ajoute volontairement de la friction. Ne l'appliquez pas à une simple consultation d'état uniquement pour créer un rituel rassurant : les utilisateurs finiraient par l'approuver sans la lire.

La carte d'approbation doit répondre à ces questions en termes simples :

• Quel processus local a demandé l'accès, y compris son autorité de signature lorsqu'elle est disponible ?
• Quel identifiant conservé ou quelle catégorie d'action sera utilisé ?
• Quelle destination, quel hôte ou quel environnement recevra la requête ?
• Quelle opération sera effectuée et quelles entrées modifieront concrètement ses effets ?
• L'approbation vaut-elle pour cet appel ou seulement jusqu'à l'arrêt de ce processus ?

N'acceptez pas un système d'approbation qui identifie l'appelant uniquement comme « terminal » ou « agent ». Une machine locale peut exécuter plusieurs terminaux et plusieurs processus d'agents. La personne qui approuve doit disposer d'informations suffisantes pour distinguer une nouvelle exécution de travail d'un ancien processus encore actif.

Sallyport utilise une échelle de décision fixe : un coffre verrouillé refuse chaque action, un nouveau processus d'agent exige par défaut une autorisation de session et certains identifiants peuvent exiger une approbation à chaque utilisation. Ce modèle limité est préférable à un langage de politiques locales complexe sur un ordinateur portable de développeur, où les règles obscures vieillissent mal et où personne ne peut prévoir avec certitude laquelle l'emportera.

L'approbation ne remplace pas la limitation de portée. Un humain peut approuver la mauvaise chose. Limitez d'abord les destinations, les identifiants et la forme des actions, puis demandez une approbation lorsque le jugement humain apporte un contrôle utile.

Un journal doit répondre aux questions de propriété après coup

Un audit utile permet à un ingénieur de reconstituer qui a lancé quoi, quel processus local a reçu l'autorité, quelle action externe a eu lieu et quand l'accès a été retiré. Le défilement d'un terminal ne peut pas répondre à cette exigence : les utilisateurs peuvent le modifier, les shells le font tourner et les processus distincts disparaissent dans un seul fichier d'historique.

Conservez deux vues du même flux d'événements. La première suit les sessions : identité du processus d'agent, heures de début et de fin, approbations et révocations. La seconde suit les actions : horodatage, destination, méthode ou commande, référence de l'identifiant, résultat et erreur. Reliez-les avec un identifiant de session, tout en gardant les informations compréhensibles sans devoir fouiller une base de données.

La preuve d'absence de modification améliore la qualité des échanges après un incident. Une séquence en écriture unique avec des hachages chaînés rend les modifications silencieuses détectables. Elle ne prouve pas que chaque action enregistrée était judicieuse et ne fait pas réapparaître les événements que vous n'avez pas collectés. Elle rend toutefois plus facile la contestation de l'affirmation « quelqu'un a nettoyé le journal ».

Vérifiez la piste d'audit indépendamment. Sallyport produit ses journaux de session et d'activité à partir d'un journal d'audit chiffré et chaîné par hachage, et sp audit verify vérifie la chaîne hors ligne sans accès aux clés du coffre. Cette séparation compte, car la commande de vérification ne doit pas avoir besoin du même coffre secret dont vous examinez l'utilisation.

Les journaux doivent eux aussi protéger les secrets. Enregistrez une référence d'identifiant, le nom de l'action, la destination et le résultat. N'enregistrez pas les jetons bearer, les en-têtes d'autorisation des requêtes, les clés privées ni les arguments de commande qui contiennent des mots de passe. Un journal complet qui reproduit chaque secret devient un second coffre d'identifiants, avec un contrôle d'accès moins bon.

Examinez les actions échouées, pas seulement les réussites. Des refus répétés peuvent révéler qu'un agent tente d'utiliser un contrat d'action obsolète, qu'un développeur emploie le mauvais compte ou qu'un processus en arrière-plan a survécu à sa tâche. Une réussite inexpliquée mérite de l'attention, mais les échecs montrent les limites où vos contrôles ne correspondent pas au travail réel.

Un modèle opérationnel viable pour un Mac d'équipe

Les équipes peuvent utiliser des agents locaux pour des tâches sérieuses avec un niveau de sécurité suffisant si elles accordent plus d'importance à l'identité individuelle et à une autorité d'action explicite qu'au matériel partagé. Le modèle opérationnel doit reposer sur des habitudes quotidiennes, pas sur un document de sécurité qui ne réapparaît qu'à l'intégration.

Suivez cette séquence lorsque vous ajoutez un flux de travail avec agent à une machine partagée du bureau :

1. Attribuez à chaque identifiant un propriétaire humain, un service autorisé, un environnement et une condition de retrait.
2. Créez un contrat d'action dédié pour l'agent au lieu d'exposer un jeton général ou une session shell.
3. Lancez l'agent depuis le compte du développeur prévu, avec un environnement d'identifiants vide ou minimal.
4. N'autorisez le nouveau processus qu'après avoir vérifié son identité et sa destination demandée.
5. Terminez l'exécution, révoquez-la si nécessaire et vérifiez que ses processus auxiliaires et ses identités SSH ont disparu.

Cette séquence est volontairement moins pratique que le fait de placer un jeton de production dans un profil shell utilisé par tout le monde. Ce raccourci semble efficace jusqu'à ce qu'un prestataire utilise la machine, qu'un éditeur hérite de l'environnement ou qu'un ancien processus reste actif pendant la session suivante.

Définissez l'accès d'urgence avant qu'une panne ne survienne. Une équipe a besoin d'une personne désignée pour approuver une action de secours, d'un identifiant distinct à portée d'urgence limitée et d'un enregistrement expliquant pourquoi il a été utilisé. Ne laissez pas un jeton puissant dans un dossier partagé « pour les urgences ». Il deviendra un accès ordinaire simplement parce qu'il est disponible.

Pour les tâches qui exigent une passerelle d'actions locale, gardez cette passerelle sur le compte personnel du développeur et rendez la limite du processus visible. Un Mac partagé peut accueillir plusieurs utilisateurs au fil du temps ; il ne doit pas héberger un seul ensemble indifférencié d'autorités.

Testez la révocation pendant que l'agent est encore actif

La révocation n'est crédible que si elle bloque l'action suivante d'un processus qui disposait déjà d'une autorisation. La tester après avoir quitté tous les clients ne prouve presque rien.

Configurez une action de préproduction inoffensive qui renvoie une réponse connue. Lancez un processus d'agent, autorisez-le pour la session et effectuez l'action une fois. Révoquez ensuite la session ou verrouillez le coffre d'identifiants alors que le processus est encore actif. Demandez à nouveau la même action.

Le résultat attendu est un refus lié au processus actif ou à l'état verrouillé. L'agent ne doit pas se rabattre sur un jeton présent dans son environnement, un socket SSH existant ou une session de navigateur mise en cache. S'il réussit, examinez le chemin qu'il a utilisé avant d'ajouter d'autres demandes d'approbation ou règles.

Effectuez le même test après la déconnexion d'un développeur et la connexion d'un autre. Testez-le aussi après la mise en veille et le réveil de la machine, car les connexions des assistants locaux et les agents SSH révèlent parfois des hypothèses qui n'apparaissent qu'après une longue journée de travail. Conservez une courte trace des résultats, avec l'identité exacte du processus et l'action testée.

La première modification utile n'est pas un gestionnaire de secrets plus complexe ni une liste d'approbation plus longue. Retirez un identifiant trop large de la portée d'un agent, remplacez-le par un chemin d'action limité et prouvez que la révocation arrête un processus encore actif. Ce test vous indique si l'équipe contrôle réellement les accès ou si elle se contente de les documenter.