Comment le verrouillage du coffre et de l'écran modifie un test d'agent

Un écran verrouillé et un coffre verrouillé sont deux contrôles différents. Les traiter comme s'il s'agissait du même contrôle produit un test qui n'apprend presque rien. Le verrouillage de l'écran macOS limite l'accès interactif à une session utilisateur. Le verrouillage du coffre doit bloquer les actions protégées au moment où les identifiants seraient utilisés, y compris les actions demandées par un processus autorisé avant que vous ne vous éloigniez.

Cette distinction compte surtout avec les agents de programmation autonomes. Un agent peut maintenir un processus en vie, conserver son contexte, planifier du travail et réessayer une requête qui a échoué. Un test qui confirme seulement qu'une personne ne peut pas saisir de texte sur le bureau ne montre pas si ce processus peut encore appeler une API ou ouvrir une connexion SSH. Testez les deux états séparément, puis testez leur combinaison.

J'ai vu des équipes appeler cela un test « ordinateur verrouillé », prendre une seule capture d'écran de l'écran de verrouillage et déclarer le travail terminé. Cela prouve qu'un écran de verrouillage est affiché. Cela ne prouve pas qu'une frontière de refus absolu entoure les identifiants.

Un écran verrouillé ne détermine pas si un processus peut agir

Le verrouillage de l'écran macOS protège la session de la console contre une personne qui aurait physiquement accès au clavier et à l'écran. À lui seul, il ne décrit pas tous les processus déjà exécutés dans cette session, toutes les connexions réseau qu'ils possèdent ni tous les coffres d'identifiants qu'une application peut utiliser.

La documentation Platform Security d'Apple sépare l'authentification de l'utilisateur et la protection de la session de la protection des secrets, comme les éléments du trousseau. Cette distinction est utile ici, même si votre déploiement comporte moins d'éléments que ceux couverts par la documentation d'Apple. Demander « l'écran était-il verrouillé ? » et demander « l'agent pouvait-il utiliser un identifiant ? » sont deux questions différentes, qui nécessitent des preuves différentes.

Un agent peut être inoffensif lorsque l'écran est déverrouillé et devenir dangereux après avoir reçu un jeton porteur dans son propre environnement. À l'inverse, un agent peut fonctionner pendant une session verrouillée tout en restant incapable d'effectuer une requête protégée, parce que l'identifiant n'est jamais entré dans sa mémoire et que la passerelle d'action le refuse. L'état de l'écran ne permet pas de savoir quelle architecture vous utilisez.

Utilisez cette définition pratique pendant la revue :

• Le verrouillage de l'écran contrôle l'utilisation interactive du Mac.
• Le verrouillage du coffre contrôle l'exécution de l'action protégée.
• L'autorisation de session contrôle la capacité de ce processus d'agent précis à demander des actions protégées pendant sa durée de vie.
• Une clé par appel détermine si une personne doit autoriser cette utilisation précise d'un identifiant.

Ces contrôles peuvent bien s'aligner dans une démonstration réussie. En production, ils ne doivent pas dépendre de cet alignement.

La passerelle du coffre a besoin d'un test de refus absolu

Une passerelle de coffre à refus absolu signifie qu'un coffre verrouillé refuse toute action qui utiliserait un identifiant enregistré. Le refus doit intervenir avant l'injection des identifiants HTTP et avant que l'assistant SSH ne s'authentifie. Il doit s'appliquer à un processus qui a déjà réussi auparavant, pas seulement à un nouveau processus qui n'a jamais été approuvé.

Sallyport rend cette frontière explicite : lorsque son coffre est verrouillé, toute action est refusée. Sur le matériel macOS compatible, la passerelle du coffre est contrôlée matériellement par Secure Enclave et Touch ID. C'est plus solide et plus clair qu'une convention comme « l'agent ne devrait pas appeler cet outil pendant mon absence ».

Le test le plus révélateur commence par une réussite. Configurez un point de terminaison à faible impact que vous contrôlez, par exemple un point de terminaison HTTP qui enregistre uniquement la méthode de la requête et un identifiant de requête opaque, ou un hôte SSH avec une commande qui affiche un mot fixe. Ne commencez pas par un point de terminaison de déploiement en production. Vous avez besoin d'une cible dont vous pouvez consulter les journaux sans exposer un secret actif ni modifier quoi que ce soit d'important.

Laissez ensuite le processus d'agent en vie, verrouillez le coffre depuis l'application et demandez à nouveau la même action. Un résultat correct comporte trois éléments :

1. L'appelant reçoit un refus clair, plutôt qu'une expiration de délai ou une erreur réseau générique.
2. Le journal Activity enregistre la tentative comme refusée, avec suffisamment de contexte pour identifier la session et le chemin de l'identifiant sans révéler celui-ci.
3. Votre point de terminaison contrôlé ou votre hôte SSH ne reçoit aucune nouvelle requête ni commande.

Le troisième élément révèle le problème que les interfaces soignées dissimulent. Une passerelle peut afficher un refus après avoir déjà envoyé une requête authentifiée parce qu'elle a placé le contrôle au mauvais niveau. Le journal distant est le témoin qui compte.

Pour SSH, évitez un test comme ssh host true si votre hôte de test accepte d'autres identités provenant de votre environnement habituel. Utilisez le canal que l'agent utiliserait, ciblez un compte isolé et donnez-lui une commande dont l'apparition dans les journaux du serveur est évidente. Si vous ne pouvez pas prouver quelle identité a établi la connexion, vous testez la configuration de votre shell, pas la frontière du coffre.

Une autorisation préalable ne doit pas survivre à la barrière

L'autorisation par session répond à une question plus précise que la passerelle du coffre : ce processus d'agent peut-il utiliser des actions protégées pendant cette exécution ? Ce n'est pas un droit permanent et cette autorisation ne peut pas contourner un coffre verrouillé.

C'est ici que les équipes confondent souvent commodité et autorité. Elles autorisent un agent, voient plusieurs appels réussir, verrouillent le coffre, puis le déverrouillent plus tard. Si le processus reprend son travail, elles supposent que l'autorisation précédente devrait être conservée ou disparaître selon ce qui leur semble le plus pratique. Déterminez ce comportement à partir du modèle de contrôle réel, puis testez-le. L'échelle de décision documentée de l'application place la passerelle du coffre en premier. Une barrière fermée l'emporte.

Exécutez cette séquence sans redémarrer l'agent :

1. Démarrez un nouveau processus d'agent et effectuez un appel protégé. Autorisez sa session lorsqu'une demande apparaît.
2. Effectuez un deuxième appel protégé avec le même identifiant ordinaire. Vérifiez qu'il réussit sans nouvelle fiche de session.
3. Verrouillez le coffre pendant que le processus reste actif. Répétez l'appel et vérifiez le refus avant que la cible distante ne le reçoive.
4. Déverrouillez le coffre avec l'interaction locale requise. Répétez l'appel et notez si la session établie reprend conformément aux règles documentées.
5. Quittez le processus d'agent, démarrez un nouveau processus et effectuez le même appel. Vérifiez que cette nouvelle exécution reçoit sa propre fiche d'autorisation.

L'étape quatre n'est pas un détail cosmétique. Elle révèle si le produit a accidentellement assimilé « le coffre a été ouvert » à « tout le code en cours d'exécution est de nouveau approuvé ». L'étape cinq révèle si un identifiant de processus, un parent de terminal ou une étiquette de client trop vague est devenu un droit persistant non prévu.

La fiche d'autorisation doit mettre en avant l'autorité de signature du code du processus. Un nom de processus est facile à copier. Un chemin peut être trompeur. L'autorité de signature du code fournit à l'opérateur un élément plus stable à évaluer lorsque le processus d'agent demande à utiliser un secret. Notez ce que la fiche affichait pendant votre test, notamment ce que vous auriez vu si une copie non approuvée du client avait formulé la même demande.

Le test de l'écran de verrouillage a un objectif distinct

Testez le verrouillage de l'écran macOS après avoir établi le comportement du coffre, car son objectif est de répondre à une autre question opérationnelle : que peut continuer à faire le système lorsque personne n'est devant la console, et comment en reprendre le contrôle ?

Laissez d'abord le coffre dans l'état disponible prévu et démarrez une session déjà autorisée. Déclenchez une action protégée inoffensive, verrouillez l'écran macOS, attendez assez longtemps pour couvrir votre préoccupation habituelle concernant le travail sans surveillance, puis vérifiez si l'action a pu continuer. Ne supposez pas la réponse. Les réglages d'alimentation de votre Mac, l'état du réseau, le cycle de vie du processus et la propre passerelle de l'application jouent tous un rôle.

Réalisez ensuite la même expérience en verrouillant explicitement le coffre avant de verrouiller l'écran. Le résultat devrait être plus simple : les tentatives d'actions protégées sont refusées. Si un agent peut continuer à générer du texte ou à modifier des fichiers locaux, cela sort du cadre de cette assertion précise. Celle-ci affirme uniquement qu'il ne peut pas transformer une clé API ou SSH enregistrée en action externe.

Cette paire de tests sépare un choix de politique inconfortable mais légitime d'un problème de sécurité. Certains développeurs autorisent intentionnellement un agent déjà approuvé à poursuivre des tâches à faible risque lorsque l'écran est verrouillé. D'autres exigent que toute absence verrouille le coffre. Ce sont des choix d'exploitation. Permettre à un agent d'utiliser des identifiants après le verrouillage du coffre constitue une défaillance de frontière.

Ne testez pas ce scénario en observant un écran de verrouillage depuis l'autre bout de la pièce. Capturez les horodatages de la requête de l'agent, du point de terminaison contrôlé et du journal Activity. Une requête commencée avant le verrouillage de l'écran peut se terminer après celui-ci. Cela ne prouve pas qu'elle a commencé après le verrouillage. L'ordre des événements compte.

L'autorisation par appel concerne les actions que vous regretteriez d'approuver en bloc

Une clé par appel exige une autorisation humaine à chaque utilisation de cet identifiant. Elle doit se placer au-dessus d'une session approuvée, sans remplacer le contrôle de session ni affaiblir la passerelle du coffre.

Incluez un tel identifiant dans le plan de test, même si la plupart des clés utilisent une autorisation ordinaire par session. Choisissez une action cible dont l'effet est visible et réversible, comme un point de terminaison de test qui incrémente un compteur jetable ou une commande SSH qui crée un fichier dans un répertoire temporaire. Le but est de prouver que l'application demande une nouvelle autorisation lors de la deuxième utilisation et que le refus de la demande empêche l'action externe.

Exécutez le test suivant avec l'écran déverrouillé afin de séparer le comportement de la demande de l'état de la session :

• Démarrez un nouveau processus d'agent et autorisez sa session.
• Utilisez l'identifiant par appel et autorisez cet appel. Vérifiez la présence d'un événement distant.
• Utilisez à nouveau le même identifiant et refusez l'autorisation. Vérifiez qu'aucun deuxième événement distant n'a lieu.
• Verrouillez le coffre et utilisez-le une nouvelle fois. Le refus du coffre doit intervenir sans présenter un véritable choix d'autoriser une action que la barrière ne peut pas permettre.

La recommandation courante de configurer chaque identifiant par appel semble prudente, car elle transforme chaque action en décision visible. En pratique, elle habitue les utilisateurs à approuver des fiches répétitives sans les lire. Réservez cette option aux identifiants dont chaque utilisation modifie de l'argent, un accès, un état de publication ou une autre conséquence que vous devez observer. Pour les appels courants, une autorisation de session pertinente et un coffre verrouillable offrent à l'opérateur moins de décisions, mais plus claires.

Un journal distant révèle le refus qu'un test local ne détecte pas

Un message d'erreur local prouve seulement que l'appelant a vu une erreur. Il ne prouve pas qu'une requête authentifiée n'a pas quitté la machine et ne dit rien des nouvelles tentatives arrivées plus tard.

Construisez une cible de test qui renvoie un identifiant de requête court de votre choix. L'action de l'agent peut envoyer un en-tête inoffensif ou un champ du corps de la requête comme test_run=screen-vault-01, à condition que le chemin d'identifiant configuré par votre passerelle autorise cette forme de requête. Sur le récepteur, enregistrez l'heure d'arrivée, la méthode, les informations de source dont vous disposez habituellement et cet identifiant. Isolez la cible des données de production.

Votre relevé de test doit contenir un petit tableau comme celui-ci :

Le mot « dépend » dans la ligne C est volontaire. Ne dissimulez pas une décision de politique dans une colonne réussite ou échec. Indiquez si un processus approuvé peut continuer à travailler lorsque l'écran est verrouillé dans votre environnement, et faites correspondre le résultat attendu à cette décision.

Pour HTTP, consultez les journaux de l'application, pas uniquement les journaux d'accès, si un proxy inverse peut refuser ou réessayer les requêtes avant que l'application ne les voie. Pour SSH, consultez les enregistrements d'authentification et de commandes du serveur pour le compte isolé. Donnez un nouvel identifiant à chaque tentative. Réutiliser une même étiquette crée un débat sur la livraison différée alors que vous avez besoin d'un résultat net.

Le relevé d'audit doit expliquer la transition d'état

Une bonne piste d'audit permet à un réviseur de reconstituer qui a exécuté l'agent, quelles actions il a tentées et si la passerelle les a refusées ou exécutées. Le réviseur ne devrait pas avoir à deviner si l'absence d'événement distant vient d'un coffre verrouillé, d'une perte de réseau ou d'un agent qui n'a jamais envoyé la requête.

L'application tient un journal Sessions pour les exécutions des agents et un journal Activity pour les appels individuels. Tous deux proviennent d'un même journal d'audit chiffré, inscriptible uniquement par le système et chaîné par hachage. Ils offrent donc deux vues du même enregistrement sous-jacent, plutôt que deux journaux concurrents racontant des histoires différentes. Lorsqu'un test révèle un décalage entre les journaux, considérez-le comme un échec jusqu'à ce que vous puissiez l'expliquer.

Après chaque série de tests, conservez les observations suivantes dans vos notes :

• L'identité de session affichée lors de l'autorisation, ainsi que l'heure à laquelle vous l'avez acceptée ou refusée.
• L'heure précise à laquelle vous avez modifié l'état du coffre et celui de l'écran.
• Le résultat de réussite ou de refus communiqué par l'appelant pour chaque action tentée.
• Les entrées correspondantes des journaux Activity et Sessions.
• Les éléments fournis par la cible contrôlée montrant qu'elle a reçu ou non l'action.

Vérifiez ensuite la chaîne hors ligne avec :

sp audit verify

Une exécution réussie doit indiquer que la vérification a réussi, même si la formulation exacte peut varier selon la version. La propriété utile est que la vérification fonctionne sur du texte chiffré et ne nécessite pas d'ouvrir le coffre. Vous pouvez ainsi remettre un artefact d'audit protégé à un réviseur qui doit vérifier l'absence de falsification, sans lui donner les identifiants ni la possibilité d'effectuer des actions.

Ne présentez pas cette commande comme une preuve absolue. Une chaîne de hachage valide vous indique que la séquence enregistrée est intègre selon le modèle du vérificateur. Elle ne peut pas prouver que vous avez choisi le bon journal distant, que votre horloge est exacte ou qu'une autre voie d'accès à la cible de test n'existait pas. Associez-la aux éléments distants.

La durée de vie du processus est la frontière que l'on oublie

Une autorisation de session doit prendre fin lorsque le processus d'agent se termine. Testez-le explicitement, car « j'ai ouvert un nouveau terminal » ne signifie pas « le processus précédent s'est terminé », et un superviseur en arrière-plan peut garder un processus enfant en vie après la disparition de son interface utilisateur.

Commencez par une base propre. Quittez le processus d'agent, confirmez avec votre méthode habituelle d'inspection des processus qu'il a disparu, puis démarrez un autre processus par le même chemin client. Son premier appel protégé doit créer une nouvelle session et demander une autorisation. S'il hérite silencieusement de l'autorisation, déterminez quelle identité a transmis ce droit. Il peut s'agir d'une fonctionnalité volontaire, mais l'autorité est alors bien plus large que ne le laisse entendre une autorisation par session.

Testez aussi un lancement échoué et une copie du client. Si un processus client démarre, demande une autorisation, se termine avant d'appeler une action, puis qu'un processus de remplacement peut utiliser cette autorisation, vous avez découvert un problème de durée de vie. Si un processus portant une signature différente présente le même nom convivial, l'interface d'autorisation doit fournir à l'opérateur assez d'informations sur l'autorité pour le distinguer.

Ce n'est pas une question théorique de tenue de registres. Les outils d'agent évoluent rapidement, et les enveloppes lancent des assistants, reconnectent les transports et récupèrent après des plantages. Le processus qui effectue l'appel protégé est l'objet que vous devez autoriser. Un nom de projet ou une transcription de conversation n'est pas une identité d'exécution.

Traitez la veille, le redémarrage et la perte de réseau comme des expériences distinctes

Le verrouillage de l'écran est souvent testé sur un ordinateur portable actif, puis on suppose que le résultat couvre aussi la veille, le redémarrage et une coupure réseau. Ce n'est pas le cas. Chaque événement modifie une partie différente du système.

Pour la veille, notez si le processus d'agent reste en vie, si le Mac autorise le chemin réseau que vous utilisez et si l'état du coffre change. Pour le redémarrage, considérez chaque exécution de l'agent comme nouvelle et exigez un nouveau déverrouillage local avant toute utilisation protégée. En cas de perte réseau, vérifiez qu'un appel échoué ne provoque pas une nouvelle tentative dangereuse après le verrouillage du coffre ou après la fin du processus initial.

Gardez ces expériences limitées. Un test de nouvelle tentative utile utilise un identifiant de requête et un récepteur capable d'indiquer s'il a reçu zéro, une ou plusieurs requêtes. Démarrez la requête, interrompez le chemin réseau à un moment contrôlé, verrouillez le coffre, rétablissez le chemin réseau et observez l'arrivée éventuelle d'une requête différée. Si la requête produit des effets, utilisez un récepteur jetable. Réessayer une simple lecture est différent de réessayer une opération qui modifie un état.

Ne transformez pas ce document de test en moteur général de politiques. La question est plus précise : l'échelle de décision fixe produit-elle toujours l'état de refus attendu lorsque des événements ordinaires de l'ordinateur interrompent un agent ? Des preuves claires valent mieux qu'une immense matrice de règles imaginaires.

Le plan de test final doit laisser une affirmation sans ambiguïté

Votre plan terminé doit vous permettre d'affirmer, preuves à l'appui, que l'écran macOS verrouillé et le coffre verrouillé ont été testés séparément. Il doit aussi montrer si un processus approuvé pouvait agir sans surveillance, si l'autorisation par appel bloquait une deuxième utilisation et si un appel refusé restait absent du système distant.

Rédigez l'affirmation finale en termes simples : « Lorsque le coffre était verrouillé, l'agent ne pouvait pas utiliser l'identifiant HTTP ou SSH configuré, que l'écran macOS soit verrouillé ou déverrouillé. » Joignez le relevé de la cible distante et le résultat de la vérification de l'audit. Ajoutez ensuite votre décision d'exploitation distincte concernant ce qu'un agent approuvé peut faire lorsque seul l'écran est verrouillé.

Cette dernière phrase évite la confusion habituelle lors d'une revue d'incident. Quelqu'un peut contester votre politique de travail sans surveillance. Il ne doit pas pouvoir la confondre avec la preuve que la passerelle du coffre a fonctionné.