Les coffres d'agents de Migration Assistant nécessitent un redémarrage à froid

Un transfert de Mac n'est pas un simple déplacement sans conséquence lorsque des agents autonomes peuvent accéder à des API et à des hôtes SSH. Il crée une nouvelle machine, une nouvelle frontière de sécurité matérielle, de nouveaux processus en cours d'exécution et un nouveau moment où quelqu'un doit décider quelles autorisations restent justifiées. Si les agents retrouvent l'accès externe parce que le bureau semble familier, la migration a oublié la seule étape qui compte.

Migration Assistant peut transférer des documents, des applications, des comptes utilisateur et des réglages depuis un autre Mac, un PC ou une sauvegarde. C'est utile pour redevenir rapidement opérationnel. Cela ne signifie pas que toutes les propriétés de sécurité de la machine source doivent être conservées. Apple précise que les clés Secure Enclave et les éléments du trousseau marqués ThisDeviceOnly ne migrent pas vers un autre appareil.

La règle d'utilisation sûre est simple : transférez ce qui vous aide à examiner la situation et à reconstruire l'environnement, puis exigez une nouvelle preuve avant qu'un agent puisse utiliser un identifiant ou ouvrir une session distante. Un coffre qui refuse de s'ouvrir après un transfert fait peut-être exactement ce pour quoi vous l'avez choisi.

Un Mac transféré est un nouveau point d'accès

Un nouveau Mac peut avoir le même nom d'utilisateur, le même chemin de répertoire personnel, les mêmes applications et la même copie du projet. Aucun de ces éléments n'en fait le même point d'accès du point de vue de la sécurité. Le processeur, la Secure Enclave, l'inscription biométrique, le contexte de chiffrement du disque, l'état du système installé, la connexion réseau et l'historique des processus locaux ont tous changé.

Les équipes font souvent la mauvaise comparaison. Elles demandent si la machine de destination contient les mêmes fichiers. Elles devraient demander si la destination peut prouver qu'elle possède la même autorité sans copier une autorité qui devait rester locale. Ces deux objectifs s'opposent lorsque le coffre utilise une protection liée à l'appareil.

La documentation de sécurité d'Apple établit clairement cette limite. Une clé privée Secure Enclave est créée dans l'enclave, ne peut pas importer une clé privée existante et ne peut être utilisée que par l'enclave qui l'a créée. Apple précise également qu'un élément du trousseau utilisant kSecAttrAccessibleWhenUnlockedThisDeviceOnly ne migre pas vers un nouvel appareil.

Ce comportement peut sembler gênant lors du remplacement urgent d'un ordinateur portable. Il empêche un conteneur d'application copié, une sauvegarde ou un transfert de migration de devenir un jeton porteur transportable donnant accès à des services externes. Ne contournez pas l'échec en exportant les secrets dans un fichier de notes, une variable d'environnement, l'historique du shell ou une entrée générique de gestionnaire de mots de passe. Vous remplaceriez une frontière matérielle voulue par un fichier capable de se diffuser beaucoup plus loin que l'ancien ordinateur.

Définissez les règles de bascule avant de lancer Migration Assistant :

• L'ancien Mac reste la source faisant autorité pour les accès existants jusqu'à ce que la destination ait passé les tests.
• Sur le nouveau Mac, l'exécution des agents est bloquée ou déconnectée des identifiants de production.
• Un fichier transféré est un élément à examiner, pas une permission d'agir.
• Chaque approbation et chaque association d'identifiant doivent avoir un résultat attendu explicite.

Il s'agit d'une nouvelle inscription contrôlée, même si la plupart des données de l'application sont copiées correctement. L'appeler un transfert ne change rien au travail de sécurité à accomplir.

Quatre types d'état échouent de manière différente

Les données de l'application, les approbations, les enregistrements d'audit et les associations d'identifiants sont souvent stockés à proximité les uns des autres. Il ne faut pas les traiter comme un seul élément. Chacun répond à une question différente et une migration peut produire un résultat différent pour chacun.

Les données de l'application sont l'état local courant : préférences, définitions de points de terminaison, libellés, métadonnées non secrètes et éventuellement blobs de coffre chiffrés. Elles peuvent être transférées intactes. Leur présence vous indique seulement que l'opération de copie les a trouvées.

Les approbations sont des décisions limitées dans le temps concernant un processus d'agent précis. Elles répondent à la question : « Ce processus peut-il agir pendant cette exécution ? » Une approbation qui reste visible dans une base locale après le transfert ne doit pas autoriser un processus sur un nouveau Mac. Le processus possède une nouvelle chaîne de parents, un nouvel emplacement d'exécutable, un nouvel environnement et potentiellement un état de signature différent.

Les enregistrements d'audit sont les preuves de ce qui s'est passé. Ils peuvent et doivent survivre si le transfert conserve les fichiers chiffrés concernés. Ils doivent préserver leur ordre et leurs propriétés d'intégrité, pas seulement rester lisibles dans une vue de journal.

Les associations d'identifiants indiquent si le matériel de destination peut utiliser la protection cryptographique qui entoure un secret. Le blob chiffré peut être copié alors que la capacité locale à le déchiffrer ne l'est pas. C'est la distinction qui piège même les ingénieurs prudents : la disponibilité du texte chiffré ne signifie pas que l'identifiant est disponible.

Inscrivez ces quatre états dans une feuille de migration avant le transfert. N'écrivez pas un résultat vague comme « coffre migré ». Notez un résultat pour chaque état :

Le cas le plus déroutant est celui d'une réussite partielle. L'application se lance, les réglages apparaissent, l'ancien historique d'audit est présent et le coffre ne peut pas être déverrouillé. Ce n'est pas une migration ratée. C'est une migration qui a conservé les preuves et la configuration tout en refusant de transférer une autorité liée à l'appareil. Acceptez ce résultat et réinscrivez les identifiants.

Bloquez l'accès des agents avant toute copie

Ne commencez pas par Migration Assistant. Commencez par vérifier qu'aucun agent ne peut envoyer une requête tant que vous ne savez pas quel Mac détient l'autorité.

Commencez par arrêter les exécutions d'agents actives sur le Mac source. Si l'agent est géré par un multiplexeur de terminal, une extension d'éditeur, une tâche en arrière-plan ou un lanceur local similaire à une CI, arrêtez chaque point d'entrée. Fermez les sessions de terminal qui les ont lancées. Fermer une fenêtre ne prouve pas qu'un processus enfant s'est terminé.

Ensuite, consignez l'état de la source en dehors de l'application. Notez la date et l'heure, le numéro de série ou l'identifiant interne de l'actif du Mac source, le compte utilisateur, les processus d'agent actifs et les noms des systèmes distants auxquels les agents pouvaient accéder. Ne mettez pas de secrets dans ce relevé. Vous avez besoin d'une chronologie expliquant les preuves ultérieures, pas d'un double du coffre.

Déconnectez ensuite la destination des réseaux importants jusqu'à son premier test contrôlé. Cela peut signifier retirer un profil VPN de production de la séquence de configuration initiale, refuser une règle de pare-feu ou simplement laisser le nouveau Mac hors réseau jusqu'à la fin des contrôles locaux. Un ordinateur portable qui ne peut pas atteindre une API externe ne peut pas démontrer accidentellement qu'une ancienne autorisation a été acceptée.

Enfin, décidez qui est habilité à accepter les nouvelles approbations. Ce point compte plus que les équipes ne le reconnaissent. Une migration se déroule souvent pendant qu'une autre personne configure la nouvelle machine, restaure des sauvegardes ou répare un ordinateur endommagé. La personne qui clique sur une demande d'approbation doit savoir quel binaire d'agent elle approuve et pourquoi il a besoin de cette capacité.

Utilisez un court relevé de passation comme celui-ci :

Migration ID: MA-2026-07-22-A
Source endpoint: old Mac asset ID
Destination endpoint: new Mac asset ID
External access state: disabled
Source agent runs: stopped
Source sessions revoked: pending destination verification
First permitted test: disposable read-only API action
Decision owner: named operator

La date affichée est un exemple de format, pas un identifiant magique. L'essentiel est de pouvoir relier ultérieurement la fin du journal d'audit source, la première approbation sur la destination et la première action réussie à un seul relevé de bascule.

Les fichiers de l'application peuvent bouger sans que la confiance bouge

Examinez l'état de l'application en deux temps : d'abord son exhaustivité, puis les autorisations. Ne mélangez pas les deux. L'exhaustivité indique ce qu'il faut restaurer. Les autorisations indiquent ce qui doit être refusé ou reconstruit.

Après le transfert, lancez l'application alors que la destination ne peut toujours pas atteindre les services de production. Vérifiez que sa configuration visible est cohérente : noms des points de terminaison, libellés, détails de routage non secrets et éventuelle vue du journal local. Comparez ces éléments avec le Mac source tant qu'il existe encore. Si un point de terminaison manque, reconstruisez-le volontairement. Si un point de terminaison inconnu apparaît, supprimez-le et cherchez son origine.

Recherchez ensuite tout état susceptible de provoquer une action automatique. Cela comprend les intégrations d'agents lancées automatiquement, les entrées de profil shell qui lancent un connecteur, les tâches de l'éditeur, les agents de lancement, les modèles de commandes enregistrés et les préférences qui rouvrent d'anciennes sessions. Une migration peut conserver des réglages pratiques inoffensifs pour un éditeur de texte, mais dangereux pour un agent capable d'appeler des API de production.

Apple indique que Migration Assistant transfère les applications, les comptes, les documents et les réglages. C'est précisément pourquoi cette vérification est nécessaire, plutôt que de supposer que seuls les fichiers personnels ont été déplacés.

Ne considérez pas la présence d'un répertoire comme une condition de réussite. Une conception de sécurité peut transférer volontairement un fichier de coffre chiffré tout en laissant son matériel de déchiffrement derrière elle. Un coffre qui semble vide peut aussi être correct si l'application choisit de ne pas copier l'état de sécurité local. La seule question utile est de savoir si le résultat correspond à la conception attendue.

Pour Sallyport, le coffre est chiffré dans l'application et sa barrière est absolue. Sur les Mac équipés du matériel pris en charge, cette barrière utilise Secure Enclave et Touch ID, et un coffre verrouillé refuse toute action. Une charge utile de coffre copiée ne prouve donc pas que la destination peut utiliser l'autorité du Mac source.

Documentez chaque résultat observé avec des termes précis. Écrivez « état chiffré présent ; la barrière de destination reste verrouillée » plutôt que « migration échouée ». Écrivez « lanceur d'agent désactivé avant la première exécution » plutôt que « probablement arrêté ». Ces détails empêchent un opérateur ultérieur de prendre un test incomplet pour une bascule réussie.

Les anciennes approbations ne doivent pas autoriser un nouveau processus

L'approbation de session et l'accès aux identifiants sont deux contrôles distincts. Un nouveau Mac doit réussir les deux, dans le bon ordre. La barrière du coffre détermine si une action est possible. L'autorisation de session détermine si cette exécution précise de l'agent peut effectuer des appels. Une exigence par appel détermine si un identifiant donné nécessite une nouvelle décision humaine à chaque utilisation.

Cette séparation est facile à brouiller, car l'utilisateur voit une seule action réussir ou échouer. N'acceptez pas cette ambiguïté pendant la migration. Testez-la volontairement.

Lancez un nouveau processus d'agent seulement après avoir placé le coffre de destination dans l'état verrouillé ou déverrouillé prévu. Demandez-lui une action sans danger au moyen d'un identifiant qui ne peut pas modifier les systèmes de production. Le résultat attendu pour la session est une nouvelle demande d'approbation. Examinez l'identité du processus et l'autorité de signature affichées par l'interface d'approbation, puis n'approuvez que l'exécution que vous avez réellement lancée.

Si un processus d'agent effectue une action sur la destination sans nouvel événement d'autorisation, arrêtez-vous. Ne vous félicitez pas d'avoir gagné du temps grâce au transfert. Cherchez le chemin qui a accordé l'autorité. Il peut s'agir d'un processus encore actif, d'une base de sessions restaurée, d'une intégration lancée en dehors du relais prévu ou d'un modèle d'approbation qui ne lie pas assez étroitement l'autorisation à la durée de vie du processus.

L'autorisation de session de Sallyport est activée par défaut et affiche le premier appel d'un nouveau processus d'agent sous la forme d'une carte d'approbation présentant d'abord l'autorité de signature du processus. Une approbation ne dure que pour cette exécution, jusqu'à sa fin. Un processus de destination lancé à nouveau doit donc provoquer une nouvelle décision.

Testez séparément les identifiants soumis à une approbation par appel. Configurez un identifiant de test sans danger pour exiger une approbation à chaque utilisation. Effectuez deux appels depuis la même exécution d'agent approuvée. Vous devriez voir une décision pour chaque utilisation de cet identifiant, tandis que la décision de session ne devrait pas se répéter simplement parce que le même processus continue de fonctionner. Vous saurez ainsi si vous avez testé la couche de session ou celle des appels individuels, au lieu de deviner à partir d'une seule fenêtre.

Un tableau de test simple suffit :

Ne faites pas ce test avec un déploiement en production, car vous ne testez pas seulement une fenêtre. Vous vérifiez que le nouveau point d'accès reconnaît correctement la durée de vie du processus et la politique des identifiants.

L'historique d'audit doit être vérifié, pas seulement consulté

Une vue du journal contenant les entrées d'hier est utile, mais elle ne prouve pas que l'enregistrement transféré est complet. Une migration peut omettre un fichier, copier un instantané ancien, interrompre une mise à jour ou vous montrer un index mis en cache. Les preuves d'audit ont besoin d'un test d'intégrité.

Conservez le Mac source avant d'exécuter la première action sur la destination. Notez le dernier horodatage source et le nombre de sessions et d'appels attendus autour de la bascule. Comparez ensuite la vue historique de la destination. Vous cherchez une continuité, pas une disposition identique à l'écran ni un ordre d'affichage identique.

Sallyport projette ses journaux Sessions et Activity à partir d'un journal d'audit chiffré, chaîné par hachage et inscriptible uniquement à l'aveugle. Son vérificateur peut contrôler la chaîne hors ligne sur le texte chiffré, sans clé de coffre. Cette conception fournit un critère concret de réussite ou d'échec pour les tests de migration, au lieu de demander à un opérateur d'examiner une liste d'anciennes actions.

Exécutez le vérificateur sur la source avant le déplacement si possible, puis de nouveau sur la destination avant d'autoriser toute action d'agent. Capturez la sortie standard et le code de retour sans supposer un format de message particulier :

sp audit verify > audit-verify.txt 2>&1
status=$?
printf 'sp audit verify exit=%s\n' "$status"

Conservez audit-verify.txt avec le relevé de migration, pas dans une discussion qui disparaîtra. Un code de sortie nul n'est utile que si vous indiquez aussi quel point d'accès l'a produit et quand. Si le vérificateur signale une erreur ou renvoie un état différent de zéro, arrêtez la procédure de migration. Gardez la source intacte, copiez la sortie de diagnostic et examinez le transfert au lieu de commencer un nouveau journal qui masquerait la rupture.

Une autre distinction mérite d'être conservée : l'historique d'audit transféré prouve ce que l'ancien point d'accès a enregistré ; l'activité de la destination prouve ce que le nouveau point d'accès fait après la bascule. Ne les confondez pas. Le premier appel de la destination doit être facile à repérer, associé à la nouvelle autorisation de session et clairement postérieur au dernier appel source.

Réinscrivez les identifiants au lieu de les extraire

Le raccourci classique consiste à exporter un jeton API ou une clé privée SSH depuis l'ancien Mac, à le coller dans le nouveau et à promettre de le supprimer plus tard. Il est populaire parce qu'il fonctionne vite. Il est incorrect lorsque la conception d'origine gardait volontairement l'identifiant hors de portée de l'agent et liait son utilisation locale à un coffre protégé.

La réinscription déplace la question de « Comment copier ce secret ? » vers « Qui doit accorder une nouvelle autorité à ce point d'accès ? » C'est une question plus saine. Elle peut nécessiter la création d'un nouveau jeton API, l'enregistrement d'une nouvelle clé publique SSH ou l'obtention d'un nouvel identifiant auprès du propriétaire du système. Elle crée aussi un point de révocation propre pour l'ancien Mac.

Pour un accès HTTP, créez un identifiant de test temporaire et en lecture seule lorsque le service distant le permet. Donnez-lui accès à une seule ressource sans danger. Demandez à l'agent nouvellement approuvé d'accéder à cette ressource. Vérifiez le résultat renvoyé et l'entrée d'audit locale. Révoquez ensuite l'identifiant de test ou laissez-le expirer selon la procédure habituelle du service.

Pour SSH, utilisez un compte de test dédié ou un hôte de test restreint. La première commande doit être d'observation, par exemple l'affichage de l'identité du compte distant et du répertoire de travail courant. Ne faites pas d'un envoi vers un dépôt, d'une publication de paquet, d'une commande de base de données ou d'un déclenchement de déploiement la première preuve de réussite. Ces actions compliquent fortement le diagnostic, car elles modifient précisément le système que vous cherchez à protéger.

Un identifiant qui exige une approbation à chaque appel est particulièrement utile à cette étape. Il oblige une personne à observer exactement le moment où l'utilisation externe commence. Une fois que la destination a réussi les tests d'autorisation, d'audit et d'action sans danger, réinscrivez les identifiants de production selon leur procédure normale de propriété. Révoquez l'ancien identifiant ou supprimez l'autorisation de l'ancien point d'accès dès que le système distant permet cette distinction.

Ne confondez pas un fichier de clé SSH avec une identité SSH qui doit appartenir au nouveau Mac. Une clé privée copiée peut s'authentifier, mais cela prouve seulement qu'un serveur a accepté le même matériel cryptographique. Cela ne dit rien sur la préservation de votre modèle de sécurité local. Nouveau point d'accès, nouvelle inscription d'identité, nouvelle piste d'audit.

La première action réelle doit être volontairement banale

Votre première action proche de la production doit vous indiquer si toute la chaîne fonctionne sans créer de travail de nettoyage. Choisissez une opération en lecture seule, limitée à un objet de test inerte et facile à retrouver dans les journaux distants comme dans le journal d'activité local.

Les bons candidats sont la lecture des métadonnées d'un objet API de test, l'affichage du contenu d'un répertoire SSH dédié et vide ou l'interrogation de l'identité actuellement authentifiée auprès d'un service. Les mauvais candidats sont la création de ressources cloud, la rotation d'identifiants partagés, la publication d'artefacts, la modification des réglages d'un dépôt et l'exécution de commandes utilisant l'expansion du shell sur de vrais chemins.

Exécutez l'action une fois. Confirmez les éléments suivants dans l'ordre où ils se sont produits :

1. Le coffre de destination était dans l'état prévu avant la requête.
2. Le nouveau processus d'agent a reçu une nouvelle autorisation de session.
3. Un identifiant soumis à une approbation par appel a demandé une approbation si son réglage l'exigeait.
4. Le système distant a enregistré l'action sans danger attendue.
5. L'enregistrement d'activité de la destination correspond à l'action autorisée.

Si une observation manque, ne répétez pas l'action avant d'avoir compris pourquoi. Répéter un test opaque produit généralement une pile d'enregistrements presque identiques, sans explication. Une réussite nette en dit plus que cinq nouvelles tentatives précipitées.

Une fois cette action validée, activez l'accès externe identifiant par identifiant. N'activez pas tous les points de terminaison enregistrés le même après-midi simplement parce que la machine est enfin utilisable. Un jeton de production, une identité SSH d'infrastructure et un jeton de service personnel ne présentent pas le même risque et ne nécessitent pas le même approbateur. Activez-les dans l'ordre qui accorde le moins d'autorité en premier.

Gardez l'ancien Mac jusqu'à la clôture des preuves

N'effacez pas le Mac source et ne le remettez pas lorsque la destination se lance correctement. Gardez-le disponible, avec les agents désactivés, jusqu'à la fin du relevé de transfert et jusqu'à ce que vous puissiez expliquer les preuves présentes des deux côtés.

Le relevé de clôture doit comprendre le dernier état d'audit vérifié de la source, le premier état d'audit vérifié de la destination, le résultat des tests de nouvelles approbations, les identifiants réinscrits, ceux qui ont été révoqués et la personne ayant autorisé l'accès à la production. Ce n'est pas de la paperasse pour la forme. C'est ce qui permet de répondre plus tard à la question de savoir si une action venait de l'ancienne machine, de la nouvelle ou d'un chevauchement imprévu.

Révoquez ensuite les sessions actives de la source. Retirez la source des listes d'autorisation d'accès distant lorsqu'elles existent. Révoquez les jetons propres à la source et les inscriptions SSH une fois que le remplacement fonctionne. Vérifiez enfin que l'ancien point d'accès ne peut pas retrouver l'accès simplement parce qu'il revient en ligne.

Le test le plus important n'est pas de savoir si Migration Assistant a transféré suffisamment de données. C'est de savoir si la destination a dû regagner son autorité externe. Si oui, le nouveau Mac démarre avec une limite défendable. Si non, laissez les agents déconnectés jusqu'à ce que vous puissiez expliquer exactement ce qui a traversé le transfert et pourquoi.