Sécurité de la déconnexion macOS : mettre fin à l'autorité de l'agent local

La déconnexion d'un développeur doit mettre fin à l'autorité locale de l'agent, même si un processus d'agent, une requête réseau ou une application de la barre des menus ne l'a pas encore détectée. Considérer la déconnexion comme une simple demande polie de nettoyage crée une fenêtre pendant laquelle une machine laissée sans surveillance peut encore agir avec les identifiants d'une personne.

Le problème est particulièrement important pour les agents de programmation, car leur travail utile franchit une limite. Ils appellent des API, ouvrent des sessions SSH, créent des tickets, publient des paquets ou modifient l'infrastructure. Si leur autorité venait de la personne devant le clavier, elle expire lorsque cette personne quitte la session macOS. Le système doit conserver les preuves de ce qui s'est passé, mais il ne doit pas conserver la capacité d'en faire davantage.

L'erreur que je rencontre le plus souvent consiste à confondre trois choses : un secret stocké localement, une approbation accordée à un processus et une action déjà en cours. Ces éléments ne doivent pas être arrêtés de la même façon. Un simple gestionnaire quit arrive trop tard et reste trop vague.

La déconnexion est une limite d'autorité, pas un événement applicatif

La sécurité de la déconnexion macOS signifie que l'absence de session utilisateur interactive doit interdire toute nouvelle action utilisant des identifiants, même si toutes les applications ne se ferment pas proprement. Une application de bureau peut recevoir des notifications d'arrêt lors d'une déconnexion normale, mais la sécurité ne peut pas dépendre de leur réception, de leur exécution complète ou de leur ordre d'arrivée.

Un utilisateur peut fermer son ordinateur portable, changer d'utilisateur, forcer la fermeture d'une application, perdre l'alimentation ou lancer une déconnexion pendant qu'un agent attend une réponse lente. Le système d'exploitation peut aussi supprimer les processus dans un ordre que votre code n'avait pas prévu. Une conception qui dit « nous révoquerons l'accès dans applicationWillTerminate » accepte déjà trop d'incertitude.

La documentation de launchd d'Apple établit ici une distinction essentielle. Elle sépare les domaines système, utilisateur et de connexion graphique. Une tâche située dans un domaine utilisateur graphique appartient à une session connectée précise, tandis qu'une tâche système a une durée de vie et un modèle d'autorité différents. Ne prenez pas le fait qu'un processus soit encore actif comme preuve qu'il a toujours le droit d'agir au nom de l'utilisateur qui est parti.

Construisez la vérification d'autorisation autour d'un fait actuel sur la session, que la passerelle d'action peut vérifier au moment de l'appel. Chaque action doit poser les questions suivantes, dans cet ordre :

1. Le coffre-fort est-il actuellement ouvert pour cette session utilisateur connectée ?
2. Cette requête appartient-elle à un processus d'agent actif et autorisé dans cette même session ?
3. Cet identifiant nécessite-t-il une approbation pour cette utilisation précise ?
4. Un événement de déconnexion ou de révocation de session a-t-il déjà fait avancer la génération de session ?

La quatrième vérification évite une course subtile. Une requête peut réussir les trois premières vérifications, rester dans une file d'attente, puis atteindre l'exécuteur après le début de la déconnexion. Un numéro de génération, vérifié à nouveau juste avant l'injection de l'identifiant ou l'exécution SSH, fait échouer cette requête obsolète.

Ne faites pas dépendre la déconnexion de la bonne volonté d'un agent qui accepterait de s'arrêter. À la limite de sécurité, l'agent est un appelant non fiable. Il peut être désorienté, occupé, compromis ou simplement avoir disparu.

Un coffre-fort verrouillé doit refuser l'accès avant le nettoyage

La porte du coffre-fort doit se fermer en premier, de manière synchrone du point de vue de l'exécuteur. Une fois la porte fermée, aucune nouvelle injection d'identifiant HTTP ni aucune nouvelle authentification SSH ne doit pouvoir commencer. Le nettoyage peut suivre, mais il ne peut pas être le mécanisme qui rend le système sûr.

Cet ordre semble évident jusqu'à ce qu'une application conserve une file de requêtes. Un échec classique se déroule ainsi : un agent soumet cinq appels de déploiement, l'interface commence le nettoyage de la déconnexion, l'application efface la carte de session visible, puis un thread de travail retire le quatrième appel de la file avec une référence d'identifiant qu'il avait résolue plus tôt. L'application semble déconnectée alors que l'action atteint encore le service externe.

Conservez un objet d'autorité unique dans le processus qui contrôle l'utilisation des secrets. Il doit contenir un identifiant de session opaque, un compteur de génération et un état d'activation. Les workers ne doivent jamais recevoir les octets des secrets. Ils reçoivent une requête d'action et doivent obtenir un bail d'autorisation renouvelé juste avant que le coffre-fort exécute l'action.

Une structure simple suffit :

AuthorityState {
  sessionID: 6C17...
  generation: 41
  vaultOpen: true
  logoutStarted: false
}

execute(request):
  lease = authority.issueLease(request, generation: 41)
  vault.perform(request, lease)

beginLogout():
  authority.logoutStarted = true
  authority.vaultOpen = false
  authority.generation = 42
  cancelPendingRequests()

vault.perform doit refuser le bail si sa génération ne correspond plus. Cette seconde comparaison doit se trouver aussi près que possible du moment où le coffre-fort fournit un en-tête HTTP, démarre un assistant SSH ou signe une requête. Vérifier uniquement l'autorisation lorsque la requête entre dans la file laisse une fenêtre suffisamment grande pour être importante.

Pour une application macOS qui protège son coffre-fort avec Secure Enclave et Touch ID, l'accès contrôlé par le matériel est utile, car il donne à la porte un propriétaire local clairement défini. Il ne supprime pas le besoin d'un état de session. Une invite biométrique acceptée avant la déconnexion ne peut pas autoriser un appel après la déconnexion.

La porte du coffre-fort de Sallyport suit cette règle : lorsqu'il est verrouillé, chaque action est refusée. Cette limite fixe vaut mieux qu'une liste d'exceptions d'arrêt, car les listes d'exceptions s'allongent jusqu'à ce que plus personne ne sache quel appel leur échappe encore.

Une approbation active appartient à un processus et à une session

Une approbation utilisateur doit être liée à un processus d'agent précis, à son autorité de signature du code et à la session de connexion macOS actuelle. Elle ne doit jamais signifier « ce compte a approuvé cet outil il y a quelque temps ».

L'identité d'un processus ne se résume pas à son identifiant. Les PID sont réutilisés. Un appelant qui n'enregistre que le PID 4812 peut autoriser par erreur un processus sans rapport après suffisamment de créations et d'arrêts. Enregistrez l'heure de démarrage du processus et son identité de signature du code avec le PID. Si le processus est enfant d'un terminal ou d'une intégration d'éditeur, conservez assez d'informations sur le parent pour expliquer le chemin dans la trace d'approbation, mais ne faites pas de l'arborescence le seul signal de confiance. Les wrappers shell et les superviseurs de processus la modifient constamment.

La carte d'approbation doit commencer par l'autorité de signature, car cela permet au développeur de poser une question concrète : « Est-ce que je veux que ce processus d'agent signé agisse dans cette session ? » Un nom de paquet ou une chaîne arbitraire fournie par MCP ne répond pas à cette question.

Lorsque la déconnexion commence, supprimez toutes les approbations actives de cette session. Ne les suspendez pas. Ne les sérialisez pas pour la prochaine connexion. Ne les recréez pas parce que le même binaire revient après un redémarrage. Le développeur doit approuver la nouvelle exécution comme une nouvelle exécution.

Cela s'applique aussi aux boîtes de dialogue d'approbation déjà affichées. Elles doivent disparaître ou devenir inactives lorsque la session change. Un clic tardif sur une ancienne carte ne doit pas réactiver une autorisation désormais morte. Donnez à chaque invite d'approbation une expiration liée à la même génération de session que celle qui protège les requêtes.

Une distinction utile est souvent brouillée par les implémentations :

• Le déverrouillage du coffre-fort permet à la passerelle locale d'examiner les actions.
• L'autorisation de session permet à un processus d'agent identifié de soumettre des actions.
• L'approbation par utilisation permet une utilisation précise d'un identifiant.

Une déconnexion invalide les trois, mais ils ne reposent pas sur les mêmes preuves et ne suivent pas le même calendrier. Le coffre-fort se ferme immédiatement. Les approbations de session deviennent invalides en groupe. Les invites par utilisation échouent individuellement, car leur génération de session a changé. Réduire ces éléments à un seul booléen rend difficile l'audit de la raison pour laquelle un appel a réussi ou échoué.

Les outils en cours d'exécution ont besoin d'une annulation et d'une incertitude honnête

La déconnexion doit arrêter le travail qui n'a pas encore franchi la limite externe et tenter d'arrêter celui qui l'a franchie. Elle ne peut pas inverser une opération déjà acceptée par un service distant.

Séparez une action en états qui ont une signification opérationnelle :

queued -> authorized -> dispatched -> response received
                    \-> cancelled

Une action en file n'a pas quitté le Mac. Retirez-la de la file et signalez cancelled_before_dispatch. Une action autorisée peut ne détenir qu'un bail interne de courte durée. Invalidez le bail avant l'envoi et signalez revoked_before_dispatch si le worker l'atteint trop tard.

Une action envoyée est différente. Le système distant peut l'avoir reçue même si le processus local ne reçoit jamais de réponse. Ne la signalez pas comme annulée simplement parce que vous avez fermé une connexion ou tué un assistant. Enregistrez logout_during_dispatch, recueillez l'identifiant de requête si le protocole distant en fournit un et indiquez à l'utilisateur que le résultat reste inconnu jusqu'à vérification dans le système distant.

Les requêtes HTTP demandent une attention particulière. Fermer une connexion client peut interrompre un envoi avant que le serveur ne le lise, ou se produire après que le serveur a validé une modification. Les jetons d'idempotence réduisent les dommages lorsqu'un utilisateur réessaie plus tard, mais ils ne transforment pas une requête incertaine en requête annulée. Pour les opérations qui créent une ressource externe, envoyez un identifiant d'idempotence réellement pris en charge par l'API distante, puis journalisez cet identifiant sans enregistrer l'identifiant secret.

SSH est encore moins prévisible. Envoyer un signal à un assistant local peut tuer le processus local alors que la commande distante continue dans son propre groupe de processus. Lorsque vous contrôlez l'environnement distant, exécutez les travaux longs sous un superviseur distant avec un identifiant de tâche explicite et une procédure d'annulation. Lorsque vous ne le contrôlez pas, dites-le dans l'enregistrement d'activité. Prétendre avoir annulé une migration distante parce que le terminal local s'est fermé est une façon d'aggraver un incident déjà sérieux.

Ne faites pas attendre indéfiniment la déconnexion pour le nettoyage. Fermez d'abord l'autorité, demandez aux workers d'annuler, accordez à l'application un bref délai de nettoyage limité, puis laissez le système d'exploitation terminer la déconnexion. La propriété de sécurité est le refus de toute utilisation future. Une sortie élégante n'est qu'une facilité souhaitable.

La persistance en arrière-plan modifie le modèle de menace

Une application par utilisateur qui continue d'agir après la déconnexion est devenue un service sans surveillance, et non plus un assistant de bureau. Cela peut convenir à un compte de service conçu à cette fin. Ce n'est pas acceptable comme effet secondaire accidentel d'une application de barre des menus.

Évitez d'installer un assistant privilégié ou une tâche launchd dans le domaine système uniquement pour maintenir un agent actif après la déconnexion. Cette solution est populaire, car elle donne l'impression que les tâches longues sont fiables. Elle détache aussi le chemin d'action de la personne qui l'a approuvé et élargit souvent l'accès au-delà de la session utilisateur initiale.

Si une équipe a réellement besoin que le travail continue après le départ d'un développeur, donnez à ce travail un cadre distinct. Utilisez une identité de service explicite, des identifiants à portée distante limitée et à durée d'expiration, une responsabilité définie, une piste d'audit et une procédure d'annulation utilisable par un autre opérateur. Rendez le transfert visible. Un agent local ne doit pas endosser ce rôle en silence.

Le changement rapide d'utilisateur expose le même problème. L'utilisateur A peut laisser une session graphique ouverte pendant que l'utilisateur B se connecte. L'utilisateur B ne doit pas pouvoir approuver ni observer l'autorité de l'agent de l'utilisateur A. Liez chaque instance de passerelle, chaque approbation et chaque vérification d'accès au coffre-fort à l'utilisateur et à la session graphique appropriés. Un daemon à l'échelle de la machine qui multiplexe négligemment les deux utilisateurs exige une isolation très rigoureuse. La plupart des outils de bureau devraient éviter cette architecture.

La mise en veille n'est pas une déconnexion. Un Mac en veille peut reprendre la même session utilisateur. Les équipes ont donc besoin d'une décision distincte pour la veille et le verrouillage de l'écran. Pour les identifiants sensibles, fermer le coffre-fort au verrouillage de l'écran est souvent raisonnable. Pour un travail local moins sensible, la passerelle peut conserver l'état du coffre-fort, mais exiger une nouvelle approbation au réveil. Quelle que soit la politique choisie, ne la décrivez pas comme un comportement de déconnexion. Les utilisateurs et les personnes chargées d'examiner les incidents ont besoin de termes précis.

Les journaux doivent survivre à l'autorité sans devenir un second coffre-fort de secrets

Vous avez besoin d'un enregistrement durable de l'autorité qui a pris fin, surtout lorsqu'une action réseau chevauche la déconnexion. Vous n'avez pas besoin d'une seconde base de données remplie de jetons, de corps de requêtes ou de clés privées SSH.

Écrivez les événements du cycle de vie comme des faits : session ouverte, processus d'agent approuvé, requête soumise, utilisation de l'identifiant autorisée, envoi commencé, déconnexion observée, bail révoqué, arrêt de l'assistant demandé et résultat final. Ajoutez des identifiants stables qui permettent à un opérateur de relier les événements, mais réduisez le contenu utilisateur au minimum. Un enregistrement d'activité peut indiquer qu'un appel HTTP vers une adresse configurée a réussi sans conserver d'en-tête d'autorisation ni de corps de réponse sensible.

Un journal d'audit chaîné par hachage ajoute une propriété absente des journaux applicatifs ordinaires : un vérificateur hors ligne peut détecter les enregistrements supprimés ou modifiés. C'est utile après un déploiement contesté ou une compromission locale suspectée, mais cela ne rend pas un journal véridique par magie. Le journal prouve la continuité entre les enregistrements qu'il contient. Il ne peut pas prouver qu'un processus malveillant n'a jamais cessé de journaliser avant d'agir.

Pour cette raison, écrivez l'événement de révocation avant tout nettoyage de processus effectué au mieux. Si l'application se bloque en tuant un assistant, l'enregistrement doit tout de même montrer que l'autorité locale a pris fin et que le résultat de l'action peut être incertain. Une piste d'audit qui n'enregistre que les réussites propres donne une fausse idée de la situation aux opérateurs.

Sallyport projette ses journaux de sessions et d'activité depuis un seul journal d'audit chiffré, chaîné par hachage et inscriptible mais non lisible, et sp audit verify peut vérifier cette chaîne hors ligne sur le texte chiffré. Une équipe peut ainsi vérifier la continuité sans ouvrir le coffre-fort simplement pour déterminer si la déconnexion a révoqué une exécution.

La question d'audit utile est précise : « Quel processus détenait l'autorité, quel chemin d'identifiant a-t-il demandé et que savait la passerelle lorsque l'utilisateur est parti ? » Un énorme journal de débogage répond rarement à cette question.

Testez les courses critiques plutôt qu'une fermeture propre

Un test de déconnexion doit faire chevaucher une action et la limite d'autorité. Les tests qui appellent une méthode d'arrêt après la fin de tous les workers vérifient seulement que le nettoyage normal fonctionne.

Commencez par un point de terminaison que vous contrôlez. Il accepte une requête, enregistre sa réception, puis retarde sa réponse. Soumettez une action par la passerelle de l'agent et déclenchez la déconnexion après que la passerelle a marqué l'action comme envoyée, mais avant le retour de la réponse. À la prochaine connexion, comparez l'état de l'audit local avec l'enregistrement du point de terminaison. Le résultat attendu n'est pas toujours « annulé ». Il doit être un état exact comme logout_during_dispatch, accompagné d'un identifiant de requête à examiner.

Utilisez un test distinct pour le travail en file. Mettez un worker en pause après qu'il a pris un élément dans la file, mais avant qu'il ne demande un bail d'action au coffre-fort. Lancez la déconnexion, libérez le worker et vérifiez qu'il reçoit un résultat de révocation au lieu d'envoyer quoi que ce soit. Ce test détecte l'erreur courante qui consiste à vérifier l'autorisation uniquement à l'entrée des requêtes dans la file.

Exercez ensuite les cas difficiles :

• Passez à un autre utilisateur pendant que la session d'origine reste ouverte.
• Verrouillez l'écran, réveillez la machine et testez la politique choisie pour cette transition.
• Forcez la fermeture de l'agent pendant qu'une requête attend une approbation, puis démarrez un nouveau processus avec un PID réutilisé si votre banc de test peut le provoquer.
• Interrompez la passerelle pendant l'arrêt et vérifiez si l'enregistrement d'audit identifie toujours le travail non résolu.
• Envoyez une commande SSH qui démarre un travail distant, puis vérifiez le comportement côté distant au lieu de vous fier au statut de sortie de l'assistant local.

Sur macOS, inspectez les domaines launchd pendant la préparation du test afin de savoir ce que vous avez réellement démarré :

uid="$(id -u)"
launchctl print "gui/$uid" | grep -E "(agent-gateway|your-test-label)"

La sortie varie selon les tâches installées et la version de macOS, mais elle doit afficher la tâche correspondante dans le domaine gui/<uid> actuel. Si votre tâche de test apparaît plutôt dans un domaine système, le résultat de votre déconnexion ne dit pas grand-chose sur le comportement d'une application de bureau ordinaire liée à une session.

N'automatisez pas d'abord une véritable déconnexion sur le compte principal d'un développeur. Utilisez un compte local temporaire, un identifiant API temporaire et un point de terminaison où vous pouvez examiner chaque requête. Les tests de déconnexion peuvent détruire du travail non enregistré et laisser un état distant partiellement modifié. Ce n'est pas une raison de les éviter. C'est une raison de ne plus les traiter comme un simple test unitaire.

Les identifiants distants doivent limiter l'ampleur d'un appel tardif

Une révocation locale ne peut pas remonter le temps pour révoquer un jeton bearer déjà accepté par un service distant. La conception des identifiants distants limite les dommages si la passerelle découvre une requête trop tard, si une application se bloque ou si une machine est compromise avant la déconnexion.

Préférez des identifiants distants avec des permissions limitées et une durée de vie courte lorsque la cible les prend en charge. Utilisez des identifiants distincts pour les différents environnements. Un agent qui peut mettre à jour un déploiement de staging ne doit pas recevoir un identifiant capable de supprimer des données de production simplement parce que les deux points de terminaison utilisent le même fournisseur d'API.

Pour SSH, utilisez un compte distant dédié et limitez ce qu'il peut faire. Si une commande doit lancer une tâche longue, rendez sa responsabilité et son annulation visibles du côté distant. Une identité SSH personnelle avec un accès shell étendu est pratique jusqu'au jour où il faut expliquer pourquoi une tâche a continué après la disparition de son parent local.

Ne transmettez pas les identifiants à l'agent sous forme de variables d'environnement, de texte de configuration, de substitutions de paramètres ou d'arguments shell. Dès qu'un secret entre dans l'appelant, la déconnexion peut arrêter les actions locales futures, mais elle ne peut pas faire disparaître cette copie de la mémoire du processus, de l'historique shell, des rapports de plantage ou d'une transcription. Une passerelle doit injecter l'identifiant uniquement dans l'action qu'elle exécute, puis renvoyer le résultat à l'agent.

Cette conception donne à la déconnexion une mission claire : fermer le coffre-fort, invalider les autorisations actives, refuser les baux obsolètes, arrêter le travail en attente et signaler l'incertitude pour les actions déjà envoyées. Elle ne peut pas promettre de défaire ce qui s'est passé sur Internet. Elle peut empêcher l'appel suivant d'emprunter l'autorité d'une personne qui n'est plus là.

La condition de sortie doit être facile à expliquer

Écrivez la règle dans une phrase qu'un développeur fatigué peut utiliser pendant un incident : lorsque la session utilisateur macOS prend fin, aucun processus d'agent local ne peut lancer une nouvelle action utilisant les identifiants sous l'autorité de cet utilisateur.

Tout le reste découle de cette règle. La porte du coffre-fort se ferme avant le nettoyage. Les approbations meurent avec le processus et la session qui les ont obtenues. Une requête en file perd son bail. Une requête déjà envoyée reçoit un état honnêtement inconnu jusqu'à confirmation du système distant. Les journaux restent disponibles pour examen, mais les secrets et l'autorité exécutable ne restent pas accessibles.

Si un produit a besoin d'une autorité après la déconnexion, construisez un service autonome explicite avec sa propre identité. N'introduisez pas cette décision en douce dans le chemin d'arrêt d'une application de bureau.