Convenir de la fenêtre de transmission et des responsables
Confirmez qui est autorisé à approuver les transferts et à révoquer les accès. Nommez le propriétaire du compte client, le prestataire sortant, l'opérateur remplaçant et la personne qui peut aider si l'accès tombe en panne. Convenez d'une date limite, des modifications autorisées pendant le chevauchement et des preuves requises avant la clôture.
Disposez d'un inventaire de projet à jour, du périmètre de travail convenu et d'un accès au système sécurisé d'identifiants du client. Établissez le fonctionnement de la récupération de compte avant de supprimer l'opérateur sortant. Si la transmission fait suite à une compromission présumée, le responsable de la réponse aux incidents doit déterminer le calendrier de confinement ; la séquence de chevauchement normale peut être inappropriée.
Recenser la propriété indépendamment de l'accès de connexion
Listez pour chaque service le propriétaire du compte, les opérateurs actuels, les identités d'automatisation, le responsable de la récupération et l'action de transfert requise. Une connexion administrateur ne détermine pas qui contrôle la facturation ou la récupération. Consignez uniquement des références d'identifiants ou des empreintes de clés publiques ; ne mettez jamais de mots de passe, jetons, clés privées ou codes de récupération dans ce registre.
Faites défiler horizontalement pour toutes les colonnes du tableau.
| Actif du projet | Question de propriété | Preuve d'achèvement |
|---|---|---|
| Domaine et DNS | Qui contrôle le bureau d'enregistrement, le renouvellement et le contact de récupération ? | Le propriétaire confirme l'accès et les enregistrements actuels. |
| Hébergement et serveur | Qui contrôle le compte, la console et les utilisateurs privilégiés ? | Le remplaçant vérifie de façon indépendante l'accès nécessaire. |
| Dépôt et déploiement | Qui possède le dépôt, l'automatisation et les identifiants de déploiement ? | Version approuvée déployée vers une cible isolée. |
| Application et intégrations | Qui administre le CMS, le courrier, les API et les tâches planifiées ? | Vérifications des rôles et des intégrations consignées. |
| Sauvegardes et récupération | Qui contrôle le stockage des sauvegardes et tout élément de déchiffrement nécessaire ? | Le remplaçant réalise un exercice de récupération isolé. |
Transférer la propriété et les connaissances opérationnelles
Utilisez le mécanisme de transfert ou d'invitation pris en charge par le service, puis faites vérifier le contrôle par le propriétaire récepteur depuis son propre compte. Évitez d'adopter l'identité personnelle du prestataire comme connexion partagée. Réémettez les identifiants du projet via le système sécurisé approuvé lorsque un compte personnel les fournissait auparavant.
Pour les dépôts GitHub, un transfert conserve les secrets associés, les clés de déploiement et les webhooks, et les collaborateurs existants peuvent rester. Examinez-les explicitement après le transfert. Le reçu de transfert établit un changement de propriété, et non l'achèvement de la suppression des accès.
Fournissez la référence de version, les versions d'exécution, les emplacements de configuration, les tâches planifiées, les dépendances externes, le périmètre de sauvegarde et la procédure de récupération. Ajoutez les défaillances connues et la prochaine tâche de maintenance. Expliquez où les identifiants sont récupérés de manière sécurisée sans copier leurs valeurs dans la documentation.
Laisser le remplaçant effectuer le travail
Demandez au remplaçant de suivre la procédure écrite sans emprunter la session du prestataire. Il doit obtenir la source approuvée, déployer vers une cible de test isolée, localiser les journaux utiles et démontrer la tâche d'administration applicative autorisée. Consignez chaque étape manquante, puis mettez à jour les instructions et répétez la vérification concernée.
Demandez-lui de restaurer une sauvegarde convenue vers une destination de test distincte avec les intégrations sortantes désactivées ou redirigées. Vérifiez des enregistrements représentatifs, les téléversements et le comportement de l'application. Consignez l'identifiant de sauvegarde, la cible, le temps écoulé et les lacunes non résolues. N'écrasez pas la production pour démontrer la récupération, et n'interprétez pas une tâche de sauvegarde réussie comme un test de restauration achevé.
Supprimer les accès du partant sur tous les canaux
Une fois le remplacement d'accès et la récupération vérifiés, retirez le contractant des équipes, dépôts, comptes d'hébergement et rôles applicatifs pertinents. Examinez les sessions actives et révoquez les jetons de projet, intégrations et identifiants qu'il pourrait conserver. Lorsqu'un identifiant est partagé, émettez son remplaçant, mettez à jour les services dépendants et testez-les avant de désactiver l'ancienne valeur. Répétez la tâche du remplaçant après révocation pour détecter toute dépendance cachée à un ancien identifiant.
Les clés de déploiement GitHub restent actives lorsque leur créateur est retiré d'un dépôt. Inspectez-les séparément, y compris les permissions d'écriture et la machine utilisant chaque clé. Pour les applications OAuth autorisées, le propriétaire du compte doit examiner la liste des applications et révoquer les autorisations obsolètes à l'aide des contrôles GitHub.
Pour l'accès SSH, identifiez la configuration d'autorisation de clé publique réelle. OpenSSH documente que AuthorizedKeysFile sélectionne les fichiers utilisés pour l'authentification par clé publique ; ne supposez pas que chaque serveur utilise un seul fichier par défaut. Conservez un chemin de récupération vérifié et testez la nouvelle connexion du remplaçant ainsi que les privilèges requis avant de clore la session de maintenance.
Exemple : le dépôt a été déplacé, mais le déploiement non
Dans ce scénario fictif, Cedar Workshop change son contractant de site web. Le dépôt atteint l'organisation du client, mais la tâche de déploiement utilise encore un identifiant détenu par le contractant sortant. Le remplaçant peut modifier le code mais ne peut pas publier la version approuvée. La passation reste incomplète.
Le propriétaire organise un identifiant de déploiement contrôlé par le projet avec les permissions nécessaires à cette tâche. Le remplaçant vérifie le déploiement et la récupération sur la cible de test. L'équipe retire ensuite l'ancien identifiant, examine les clés de déploiement restantes et relance les vérifications autorisées. L'enregistrement de clôture renvoie à ces résultats sans contenir de valeurs d'identifiants.
Clôturer avec des preuves et une propriété planifiée
Consignez le propriétaire qui a accepté la passation, chaque référence d'accès révoqué, l'heure d'achèvement, les résultats des tests de remplacement et les exceptions en cours. Confirmez qui agira en cas de prochaine défaillance de tâche planifiée, de renouvellement de domaine et de tâche de maintenance. Convenez du traitement des données de test temporaires et des copies de projet détenues par le contractant dans le cadre de l'accord existant.
La suppression des accès ne peut pas prouver que des copies historiques n'ont jamais été conservées. Un exercice de récupération prouve le scénario testé, pas tous les modes de défaillance. Gardez ces limites visibles et intégrez le travail non résolu dans le registre des responsabilités opérationnelles avec un responsable nommé et une date d'échéance.
Sources et révision
Les références techniques ont été vérifiées en septembre 12, 2026. Les exemples sont des exercices de planification ; la documentation logicielle citée n'établit pas les capacités de service PrivateHostLab.