Séparez la propriété de l'accès quotidien
Décidez qui détient chaque compte d'hébergement, de domaine, DNS et tiers, qui paie ses factures et qui contrôle la récupération. Ces rôles peuvent appartenir à des personnes différentes. Le mainteneur qui téléverse une version ne doit pas devenir la seule personne capable de récupérer le projet client.
Listez l'identifiant du compte, le propriétaire métier, le propriétaire du contact de récupération et les administrateurs autorisés. Consignez où sont conservés les éléments de récupération sans mettre ces éléments eux-mêmes dans cette fiche. Confirmez que la continuité d'activité ne dépend pas de l'e-mail personnel ou de l'appareil d'un prestataire partant.
Complétez une matrice de responsabilités ensemble
L'exemple ci-dessous est une proposition à discuter, et non un énoncé des obligations contractuelles de PrivateHostLab. Le client détient les décisions métier, l'agence assume le travail technique qu'elle accepte, et les obligations du fournisseur découlent de l'accord de service réel. Remplacez les rôles par des personnes nommées ou un contact fournisseur documenté.
Pour chaque ligne, ajoutez une limite d'approbation et le moyen de contact convenu. Un remplaçant doit accepter le rôle et disposer de l'accès nécessaire. Un remplaçant non renseigné ou une voie d'escalade fournisseur inconnue est une action ouverte, et non une couverture présumée.
Faites défiler horizontalement pour toutes les colonnes du tableau.
| Responsabilité | Principal proposé | Remplaçant à nommer | Escalader lorsque |
|---|---|---|---|
| Budget d'hébergement et renouvellement | Propriétaire du budget client | Adjoint autorisé par le client | Une décision de paiement ou un renouvellement n'est pas attribué |
| Contrôle du domaine et du DNS | Propriétaire client ; l'agence ne modifie que par accord | Opérateur de domaine autorisé | L'accès échoue ou les enregistrements acheminent mal les utilisateurs |
| Maintenance de l'OS et des applications | Mainteneur de l'agence dans le périmètre convenu | Remplaçant qualifié de l'agence | Une mise à jour échoue ou un composant non pris en charge nécessite une décision |
| Vérifications de sauvegarde et de récupération | Opérateur de données de l'agence ou du client nommé | Opérateur de récupération formé | Une copie manque ou une vérification de restauration échoue |
| Problèmes d'infrastructure | Fournisseur dans sa frontière de service vérifiée | Voie indiquée dans l'accord réel | Les preuves sortent du contrôle applicatif |
| Mises à jour des incidents client | Contact projet convenu | Remplaçant approuvé par le client | Un flux de travail critique est interrompu ou la prochaine mise à jour est due |
Donnez aux opérateurs l'accès nécessaire à leur tâche
Utilisez des identités individuelles là où le système concerné le permet. Gardez les permissions de publication, de déploiement, de facturation et de récupération de compte distinctes dans la mesure du possible. OWASP recommande d'accorder le minimum de privilèges nécessaires et de revoir les permissions pour l'accès accumulé. Traduisez ce principe en une tâche nommée et une date de révision pour chaque compte de projet. Aide-mémoire sur l'autorisation d'OWASP.
Convenez de qui peut ajouter ou supprimer des clés SSH et qui vérifie le résultat. Avant de modifier la configuration SSH, préservez une session de travail connue et une voie de récupération confirmée ; validez la configuration avant de l'appliquer, puis prouvez une nouvelle connexion autorisée avant de fermer l'ancienne session. Ubuntu conseille explicitement de vérifier la configuration avant de redémarrer OpenSSH afin d'éviter de perdre l'accès. Documentation du serveur Ubuntu OpenSSH.
Le document de transfert doit contenir des empreintes de clés ou des références de dossiers d'accès, jamais de clés privées, mots de passe ou phrases de récupération de portefeuille.
Définissez l'escalade selon l'impact métier
Distinguez une demande de contenu routinière, un changement de maintenance planifié et un incident affectant un flux de travail client critique. Écrivez les heures de couverture, le fuseau horaire, le premier contact, le remplaçant et le prochain point de communication. Ne transformez pas un canal de messagerie pratique en garantie implicite de temps de réponse.
Les alertes doivent conduire à une action que quelqu'un peut entreprendre. Les conseils de surveillance de Google distinguent les symptômes visibles des causes possibles et demandent si une alerte est urgente et actionnable. Pour ce projet, « les demandes ne peuvent pas être envoyées » est une description d'incident plus claire que « le serveur semble anormal ». Conseils de surveillance Google SRE.
Une note d'escalade utile consigne le flux de travail affecté, l'heure de première observation, le dernier succès connu, le changement récent et les actions déjà entreprises. Retirez les données personnelles et les secrets des journaux de support.
Attribuez la décision de récupération ainsi que la tâche de sauvegarde
Convenez du moment auquel les données doivent être récupérées et de la durée de récupération acceptable avant que l'activité ne soit matériellement affectée. Ce sont des questions de planification différentes reflétées par les objectifs de point de reprise et temps de rétablissement du NIST.
Nommez la personne qui conserve les copies, celle qui les teste et l'approbateur d'une restauration en production. Répétez sur une destination distincte. Consignez le point de données restauré, les contrôles fonctionnels, le temps écoulé et les écarts ; une répétition réussie constitue une preuve pour cet exercice, pas une garantie pour tout incident futur.
Transmettez un dossier de projet utilisable
Imaginez un client changeant son mainteneur au quotidien après une campagne. L'agence sortante fournit la version actuelle, l'inventaire des dépendances, les étapes de déploiement, la procédure de récupération de la base de données et des téléversements, les détails du planificateur, la carte DNS et le registre des comptes tiers. Le client confirme quels comptes et travaux en cours sont transférés au remplaçant.
L'opérateur recevant doit réaliser un exercice contrôlé avec les documents : localiser la version approuvée, restaurer des données échantillons en isolation, trouver la prochaine tâche planifiée et identifier le responsable des renouvellements. Consignez ce qui n'a pas pu être réalisé et résolvez-le avant de compter sur cet opérateur pour un incident.
- Confirmez l'accès autorisé du remplaçant avant de supprimer l'accès de la personne sortante.
- Renouvelez les identifiants partagés ou révoquez les identités individuelles lorsque c'est le contrôle approprié.
- Supprimez les clés obsolètes, les jetons de déploiement et les autorisations d'accès dans l'inventaire du projet.
- Confirmez le sort des copies restantes et des travaux en cours selon les termes de transfert convenus.
Acceptez la fiche, puis maintenez-la
Marquez chaque contrôle de transfert comme accepté, bloqué ou nécessitant un suivi, avec le réviseur et l'emplacement des preuves. Un contact de récupération non résolu doit rester visible plutôt que de disparaître dans un message général « transfert terminé ».
Révisez la feuille chaque fois que le client, l'agence, le périmètre du fournisseur ou l'application change. Liez-la au budget d'hébergement approuvé et registre de migration. Cette feuille de travail prépare un accord d'exploitation ; elle ne remplace pas les conditions réelles du vendeur et ne crée pas d'engagements de support du fournisseur. Comparez-la avec le périmètre de service publié et résolvez explicitement les détails manquants.
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.