Remplacer un Mac de développeur implique de renouveler les identifiants de l'agent

Remplacer un Mac de développeur est un changement d'accès, pas un simple transfert de fichiers. Les réglages de votre éditeur, vos dépôts, votre historique shell et votre cache de compilation local peuvent être déplacés avec les outils de migration habituels. Les identifiants qui permettent à un agent IA d'appeler des API de production ou d'ouvrir des sessions SSH méritent une procédure distincte.

L'erreur que je rencontre le plus souvent consiste à traiter l'ancien Mac comme une valise. Le développeur met la nouvelle machine en service, lance Migration Assistant, retrouve son bureau habituel et suppose que le transfert est terminé. En réalité, des années d'autorisations, des tokens mis en cache, des identités SSH oubliées et des outils d'agent ont peut-être franchi une frontière de confiance sans que personne ne vérifie ce qui a été conservé.

Séparer les données des droits

Les fichiers sont des copies. Les droits correspondent à la possibilité persistante d'effectuer une action à l'extérieur du Mac. Un token API peut encore lancer un déploiement après que l'ancien ordinateur portable a quitté votre domicile. Une clé publique SSH peut rester acceptée par un serveur longtemps après la copie, la sauvegarde ou la suppression de sa partie privée. Une session cloud peut se renouveler jusqu'à ce que son émetteur la révoque.

Cette distinction change le plan de remplacement. Vous pouvez copier rapidement le code source, les notes et la configuration non secrète, car vous pourrez les comparer ensuite. En revanche, vous devez attendre avant de transférer les droits, le temps de décider si le nouveau Mac a besoin du même identifiant, d'un identifiant de remplacement ou d'aucun identifiant.

Les outils d'agent rendent cette distinction encore plus importante. Un développeur classique peut saisir une commande lorsqu'un token expiré lui demande d'intervenir. Un agent de programmation autonome peut effectuer rapidement des appels, les répéter et continuer à fonctionner pendant que vous regardez ailleurs. L'agent n'a pas besoin d'un secret en clair pour créer un risque. Il lui suffit d'avoir accès à une action qui accepte encore les droits de l'ancien appareil.

Une migration raisonnable comporte deux registres :

• Le registre des données liste les dépôts, documents, fichiers de configuration, bases locales, emplacements de sauvegarde et éléments de licence.
• Le registre des droits liste tous les systèmes distants qui accepteront une action grâce à un élément stocké sur l'ancien Mac, émis pour lui ou approuvé depuis celui-ci.

Ne fusionnez pas ces listes. Un dépôt peut être restauré deux fois sans problème. Un bearer token copié deux fois crée deux endroits à protéger. C'est pourquoi le conseil habituel, migrer d'abord et faire le ménage ensuite, est mauvais pour les identifiants.

Apple décrit Migration Assistant comme un outil de transfert de documents, d'applications, de comptes utilisateurs et de réglages. Il ne supprime pas les informations de l'ancien Mac. Apple décrit correctement une migration normale, mais c'est précisément la raison pour laquelle cette opération ne constitue pas une procédure de retrait d'identifiants. L'ancienne machine reste une copie active jusqu'à ce que vous lui retiriez volontairement ses droits.

Le nouvel enregistrement doit être le choix par défaut

Un nouvel enregistrement est généralement plus sûr, car il vous oblige à décider ce que le Mac de remplacement peut faire. Vous vous reconnectez, créez un nouveau token ou une nouvelle identité SSH lorsque le service le permet, donnez au nouvel appareil le rôle minimal nécessaire et supprimez l'accès de l'ancien après le bon fonctionnement de la bascule.

Cette approche semble plus lente parce qu'elle révèle les dettes que la migration de compte dissimule. Vous découvrirez peut-être un ancien token de déploiement appartenant à une personne qui a quitté l'équipe, un token d'accès personnel beaucoup plus large que nécessaire ou une clé SSH copiée sur plusieurs machines parce que personne ne voulait interrompre une mise en production. Ces découvertes sont utiles. Le remplacement est l'un des rares moments où vous pouvez corriger ces problèmes sans perturber une installation fonctionnelle.

Choisissez un nouvel enregistrement dans les cas suivants :

• L'ancien Mac a servi à plusieurs rôles, par exemple le travail personnel, l'administration et le support de production.
• Vous ne pouvez pas nommer tous les identifiants ou comptes distants que l'ancien Mac peut utiliser.
• L'ancienne machine a été réparée, partagée, perdue pendant un certain temps ou se trouvait d'une autre manière hors de votre contrôle.
• Un émetteur d'identifiants peut créer un token, un certificat, un mot de passe d'application ou une clé SSH propre à l'appareil.
• Vous changez d'employeur, d'équipe, de profil d'appareil géré ou de compte Apple.

Le nouvel enregistrement facilite aussi le retour en arrière. Si le nouveau Mac tombe en panne pendant la première journée, l'ancien peut rester temporairement en ligne pendant que vous corrigez les accès. Ce chevauchement a un coût : fixez donc une échéance courte et notez-la. Il doit servir à prouver que la nouvelle machine fonctionne, pas à éviter de décider quoi révoquer.

Le mauvais contre-argument consiste à dire que faire pivoter tous les identifiants crée davantage d'identifiants à gérer. Une courte période avec deux identifiants nommés et inventoriés reste gérable. Une période indéfinie durant laquelle personne ne sait si un élément du gestionnaire de mots de passe, du trousseau local, d'une sauvegarde ou du coffre d'agent contient encore les anciens droits ne l'est pas.

La migration chiffrée a un rôle limité

Une migration chiffrée peut se justifier lorsque le nouvel enregistrement créerait un risque opérationnel inacceptable, lorsque l'émetteur d'identifiants ne permet pas un remplacement propre ou lorsqu'un produit de coffre dispose d'une procédure d'exportation et d'importation documentée pour ce transfert précis. Elle ne se justifie pas simplement parce que ressaisir les identifiants est pénible.

Ne confondez pas un disque chiffré par le système d'exploitation avec un paquet d'identifiants chiffré et portable. Le chiffrement intégral du disque protège un appareil tant que son stockage reste soumis à son modèle de protection habituel. Un export de migration devient un nouvel objet. Vous devez savoir s'il possède son propre chiffrement, où se trouve le matériel de déchiffrement, combien de temps le fichier existe et si une restauration peut être effectuée sur une deuxième machine sans que personne ne le remarque.

Utilisez ce test avant d'autoriser l'export chiffré d'un coffre :

1. Nommez le format d'export et la version de l'application capable de le lire.
2. Identifiez la frontière de chiffrement de l'export lui-même, et pas seulement celle du disque qui le contient.
3. Décidez où l'export sera conservé pendant la bascule et fixez une date limite de suppression.
4. Vérifiez comment le nouveau coffre prouve que l'importation a réussi sans exposer les valeurs secrètes.
5. Décidez quels enregistrements d'identifiants seront retirés ou renouvelés après l'importation.

Si une réponse reste vague, choisissez le nouvel enregistrement. Les migrations de sécurité échouent dans les zones floues, pas dans l'assistant qui suit le scénario idéal.

Il faut aussi reconnaître un point gênant : un export chiffré peut être une sauvegarde déguisée. Une équipe peut l'importer sur le nouveau Mac, déclarer l'opération terminée, puis laisser l'archive dans Time Machine, un service de fichiers partagé ou un disque externe. Cet export reste un conteneur d'identifiants. Il doit faire l'objet de la même décision de conservation que l'ancien Mac.

Migration chiffrée et nouvel enregistrement ne s'excluent pas. En pratique, vous pouvez combiner les deux. Si nécessaire, déplacez les identifiants de services peu sensibles par une procédure chiffrée documentée. Réémettez les tokens de production, les clés SSH privilégiées, les éléments de signature et tout ce qui peut atteindre les données clients. Classez les éléments selon leurs conséquences, pas selon la facilité avec laquelle un secret peut être copié.

Créer le registre des droits avant de toucher au nouveau Mac

Faites l'inventaire sur l'ancien Mac tant qu'il fonctionne encore. Ne comptez pas sur votre mémoire après le transfert : les réglages migrés peuvent donner l'impression que la nouvelle machine est complète alors que des accès importants manquent. Le registre doit contenir des références aux secrets, pas leurs valeurs.

Un simple fichier suffit. Conservez-le dans un emplacement de travail privé qui ne deviendra pas un dépôt public.

Service: production deployment API
Purpose: release automation
Credential form: bearer token
Old-device location: agent vault record deploy-prod
Issuer: deployment service administrator
Replacement method: create new device token
Cutover test: read release status only
Old-access action: revoke old token
Owner: platform team
Status: pending

Service: build host
Purpose: remote build troubleshooting
Credential form: SSH identity
Old-device location: agent vault record build-ssh
Issuer: build host authorized_keys
Replacement method: create a new SSH key pair
Cutover test: ssh hostname
Old-access action: remove old public key
Owner: build infrastructure
Status: pending

Le champ que l'on oublie est l'action à effectuer sur l'ancien accès. Sans lui, l'inventaire devient une liste de courses pour le nouveau Mac. Il doit aussi constituer un plan de retrait pour l'ancien.

Inventoriez les identifiants dans les emplacements que les développeurs oublient régulièrement :

• Les coffres d'agents et les fichiers de configuration des agents.
• La configuration SSH, l'état de l'agent SSH, les identités protégées par du matériel et les listes de clés autorisées à distance.
• Les sessions de navigateur pour les consoles cloud et les fournisseurs d'identité.
• Les registres de paquets, les outils d'hébergement de code, les systèmes de déploiement et les comptes d'administration CI.
• Les fichiers d'environnement locaux, les fichiers de démarrage du shell, les gestionnaires de mots de passe, les archives de sauvegarde et les disques amovibles chiffrés.

Ne placez pas de bearer tokens, de clés privées, de codes de récupération ou de mots de passe réels dans le registre. Celui-ci est utile parce qu'il fournit assez d'informations pour remplacer et révoquer les accès sans devenir à son tour un coffre de secrets très sensible.

Pour chaque élément, notez le test le moins destructeur. Un identifiant de déploiement doit commencer par une lecture de l'état, pas par la création d'une mise en production. Une identité SSH doit d'abord utiliser une commande limitée ou un hôte sans autorité de production. Si le seul test disponible peut modifier la production, le service présente un problème de conception des accès qu'il vaut mieux corriger avant le prochain remplacement de matériel.

Un nouveau coffre doit prouver davantage qu'une connexion réussie

Un nouveau coffre est prêt lorsque vous pouvez comptabiliser les enregistrements attendus, le déverrouiller avec les contrôles du nouvel appareil, effectuer une action limitée par son intermédiaire et examiner une trace indépendante de cette action. Voir un libellé familier dans une application ne suffit pas. Un libellé copié peut pointer vers un enregistrement expiré, un mauvais compte ou un identifiant qui n'a jamais été présent.

Pour un coffre qui contient les identifiants d'agents, suivez une séquence de test dans cet ordre précis :

1. Verrouillez le coffre et tentez l'action inoffensive. La requête doit être refusée lorsque le coffre est verrouillé.
2. Déverrouillez-le avec le contrôle local habituel et répétez la même action inoffensive.
3. Démarrez un processus d'agent vierge et vérifiez que le comportement d'autorisation correspond au réglage de session prévu.
4. Examinez l'enregistrement d'activité de l'appel et celui de la session d'exécution de l'agent.
5. Vérifiez la piste d'audit avant de retirer tout élément source de l'ancien Mac.

Sallyport conserve ses secrets dans un coffre local chiffré et effectue les actions HTTP et SSH sans remettre d'identifiants en clair à l'agent. Sa passerelle de coffre refuse les actions lorsqu'il est verrouillé, ce qui rend le premier test significatif plutôt que symbolique.

Utilisez la commande d'audit dans le compte rendu de validation :

sp audit verify

Exécutez-la sur le nouveau Mac après l'appel de test et notez la date, l'opérateur, la cible du test et le résultat dans le ticket de migration ou le journal des changements. Le but n'est pas d'ajouter de la paperasse. Il s'agit de conserver la preuve que la nouvelle machine a produit une trace valide avant la destruction de l'appareil source. Un enregistrement d'audit chaîné par hachage peut détecter une modification du journal, mais il ne peut pas vous dire que vous avez oublié d'enregistrer un identifiant. Le registre des droits couvre ce problème distinct.

Gardez le test limité. Si un identifiant ne peut pas effectuer en toute sécurité une requête en lecture seule, créez un point de terminaison de test dédié ou un compte limité pour la migration. On utilise souvent une véritable modification de production comme preuve parce qu'elle est décisive. Elle l'est de la pire manière possible : le test de migration devient un incident s'il vise le mauvais compte.

Migration Assistant est utile, mais ce n'est pas un protocole de coffre

Migration Assistant peut faire gagner des heures lorsque vous avez besoin des applications, des comptes utilisateurs, des fichiers et des réglages de l'ancien Mac. Il peut aussi transférer tout un environnement utilisateur depuis une sauvegarde Time Machine. Apple documente ces deux usages. Cette ampleur est utile pour restaurer un poste de travail, mais elle ne vous indique pas précisément quels fichiers contenant des identifiants, sessions, caches et enregistrements d'applications ont été transférés.

Utilisez-le pour le registre des données. Considérez chaque élément de droits comme absent jusqu'à ce que vous l'ayez vérifié avec les contrôles prévus sur la nouvelle machine. Cette méthode évite deux mauvais résultats : faire confiance au transfert accidentel d'un état sensible et perdre du temps à chercher un identifiant qui avait été conçu pour ne pas être transféré.

Un échec courant se déroule ainsi. Un développeur migre son compte, ouvre un projet d'agent et voit l'agent réussir un appel HTTP. Il suppose que le nouveau coffre fonctionne. En réalité, l'appel a utilisé une session cloud issue du navigateur ou un token encore présent dans un fichier de configuration copié. Une semaine plus tard, la session expire. Le développeur ajoute rapidement un identifiant de remplacement, laisse l'ancien identifiant copié en place et se retrouve avec l'ancien Mac, une sauvegarde et le nouveau coffre qui permettent tous d'accéder au même service.

La solution n'est pas d'interdire Migration Assistant. Il faut isoler la preuve. Avant de tester l'agent, fermez les sessions de navigateur sans rapport, évitez les fichiers d'environnement copiés et utilisez un enregistrement du coffre que vous avez volontairement enregistré ou importé. Examinez ensuite l'enregistrement d'activité obtenu. Vous devez savoir quel chemin a effectué l'action.

Apple indique également que Migration Assistant ne supprime pas les informations de l'ancien Mac. Organisez la bascule autour de ce fait. L'écran de fin de migration signifie que la copie est terminée. Il ne signifie pas que l'ancien appareil peut être remis sans risque à quelqu'un d'autre.

Révoquer l'ancien Mac avant de l'effacer

La révocation comporte plusieurs niveaux, et les confondre crée une fausse impression de sécurité. Mettre fin à une session d'agent arrête un processus. Retirer un appareil d'un fournisseur d'identité peut fermer certaines sessions. Révoquer un bearer token empêche les futurs appels API. Supprimer une clé publique SSH bloque la connexion distante avec cette identité. Modifier un mot de passe peut invalider certaines sessions mais en laisser d'autres actives, selon le service.

Écrivez l'action de révocation pour chaque entrée du registre avant de commencer. Ne vous contentez pas d'une note indiquant « désactiver l'ancien appareil ». Les systèmes distants ne partagent pas tous la même définition de l'accès à un appareil.

Un ordre pratique est le suivant :

1. Révoquez les sessions actives des agents et arrêtez les processus d'agent locaux sur l'ancien Mac.
2. Faites pivoter ou révoquez les tokens API, mots de passe d'application, sessions cloud et identifiants de comptes de service qui restent valides depuis l'ancien appareil.
3. Supprimez les anciennes clés publiques SSH de chaque serveur, bastion et compte d'hébergement de code qui les accepte.
4. Retirez la confiance accordée à l'appareil ou les sessions de navigateur des systèmes d'identité lorsque le service propose ce contrôle.
5. Reprenez le registre et marquez chaque élément avec la preuve de sa révocation.

Le journal Sessions de Sallyport peut révoquer immédiatement une session d'agent, tandis que son journal Activity permet d'examiner les appels individuels. Utilisez-le pour la couche du processus actif, puis terminez le travail sur les identifiants externes. Révoquer une session locale ne révoque pas un token qu'un service externe accepterait encore.

N'effacez pas l'ancien Mac en premier : il peut contenir la seule trace d'un compte de service obscur, d'une association avec un token matériel ou d'un alias d'hôte que vous devez supprimer. Laissez-le éteint et sous contrôle physique pendant la vérification du nouveau Mac. Si vous devez le laisser en ligne durant les tests, n'y exécutez pas d'agent, n'y ajoutez aucun identifiant et fixez une échéance explicite pour la bascule.

Dès que vous confirmez la révocation, l'ancien Mac change de rôle. Ce n'est plus un poste de secours. Il devient une preuve conservée brièvement au cas où un service signalerait un accès inattendu, puis un appareil prêt à être effacé.

La mise au rebut est un contrôle de sécurité distinct

Effacer le Mac ne remplace pas la révocation, et la révocation ne remplace pas l'effacement. Il faut les deux. La révocation à distance limite ce qu'un identifiant copié peut faire. L'effacement supprime les données locales, l'état des applications, les sources téléchargées, l'historique du navigateur et les éléments du coffre qui pourraient rester sur l'appareil.

Pour un Mac équipé d'Apple silicon, ou un Mac Intel doté de la puce de sécurité T2 et exécutant une version compatible de macOS, ouvrez Réglages Système, Général, Transférer ou réinitialiser, puis Effacer contenu et réglages. Apple indique que l'Assistant d'effacement supprime les comptes utilisateurs, les données, les applications installées, les connexions aux services Apple, Localiser et le verrouillage d'activation. Il efface également les volumes, et pas seulement le compte utilisateur actuel.

Si l'option n'est pas disponible, n'improvisez pas en supprimant des fichiers ou en formatant rapidement le disque. Apple recommande aux appareils plus anciens et non compatibles la procédure d'effacement appropriée dans Recovery et Utilitaire de disque. La méthode diffère parce que le matériel pris en charge et son modèle de sécurité diffèrent.

Une fois l'effacement terminé, arrêtez-vous à l'écran de configuration initiale si vous comptez vendre, échanger, donner ou recycler le Mac. Apple recommande précisément de ne pas poursuivre la configuration dans ce cas. La terminer ne ferait que créer un autre compte local sur un ordinateur qui doit sortir de votre contrôle.

Si l'ancien Mac a disparu ou si vous pensez qu'il a été modifié, ne restaurez pas son compte utilisateur sur la nouvelle machine. Apple déconseille de restaurer une sauvegarde lors d'une réinitialisation motivée par une suspicion de compromission, car la sauvegarde pourrait également restaurer le logiciel indésirable. Dans ce cas, donnez la priorité à la révocation à distance des identifiants et à une configuration propre du Mac de remplacement.

Garder une procédure de remplacement assez banale pour être répétée

La meilleure procédure de remplacement de matériel ne dépend pas d'une mémoire exceptionnelle pour retrouver l'emplacement des secrets. Elle produit les mêmes éléments à chaque fois : un registre des données, un registre des droits, des tests limités sur le nouveau Mac, les preuves de révocation de l'ancien et une confirmation d'effacement.

N'exigez pas de chaque développeur qu'il devienne spécialiste de l'analyse forensique des identifiants. Demandez aux services d'émettre des identifiants propres à chaque appareil lorsque c'est possible. Exigez des noms et des responsables pour les accès privilégiés. Donnez aux ingénieurs un parcours de test en lecture seule. Rendez la révocation évidente dans chaque service. Ces habitudes réduisent le travail lié au remplacement d'un Mac et facilitent le confinement de tous les autres incidents.

Un Mac de remplacement ne devrait recevoir, dès son premier jour, que les droits que sa mission justifie. Si cela vous semble contraignant, laissez l'ancien appareil éteint le temps d'effectuer une vérification supplémentaire. Ce délai coûte moins cher que de découvrir des mois plus tard qu'un ordinateur portable mis au rebut permet encore d'accéder à la production.