Définir ce que « le site » inclut
Commencez par un inventaire des services. Pour chaque site, portail, boutique ou campagne, enregistrez le propriétaire métier, le propriétaire technique, le compte d’hébergement, le contrôle du domaine et du DNS, le dépôt, les magasins de contenu et de médias, les intégrations et les identifiants essentiels. Indiquez ce qui peut être reconstruit depuis le contrôle de version et ce qui contient des enregistrements uniques.
Incluez la configuration intentionnellement : redirections, paramètres CDN ou pare-feu, tâches planifiées, modèles et fichiers d’infrastructure-as-code. Ne copiez pas les secrets en direct dans un manifeste général ; pointez plutôt vers le système de secrets approuvé et le processus d’accès d’urgence. La documentation WordPress montre l’écart courant : un site typique a besoin à la fois de ses fichiers et d’une base de données séparée.
Définissez la plus petite version sûre qui puisse fournir les informations ou transactions essentielles.
Donnez aux exports compatibles de base de données, fichiers, médias et configuration une étiquette de timestamp ou de version unique.
Fixer la fréquence et la rétention selon la tolérance métier
Choisissez la fréquence en fonction du rythme et de la valeur des changements. Rédigez le RPO en langage clair, puis vérifiez que chaque magasin unique est capturé assez souvent. Une copie de fichiers nocturne ne satisfera pas un RPO de quatre heures pour une base de données à forte cadence de changement.
Définissez l’RTO séparément. Incluez l’approbation, l’infrastructure propre, la restauration, la validation, les modifications de trafic et la communication interne. Mesurez-le lors d’un exercice plutôt qu’en vous fiant à une affirmation du fournisseur. Conservez des points plus anciens suffisamment longtemps pour revenir en arrière avant une erreur ou une découverte tardive, puis revoyez la rétention avec les spécialistes de la confidentialité, des archives ou du juridique lorsque des données l’exigent.
Comparez l’intervalle entre les points de reprise complets avec le RPO de chaque service.
Vérifiez qu’une personne autorisée peut retrouver un point de restauration approuvé ancien.
Séparer et protéger les copies de reprise
Utilisez plusieurs copies dans des emplacements ou services différents afin qu’un seul compte, événement local ou erreur humaine n’élimine toutes les options. La CISA recommande des sauvegardes automatisées régulières, une copie hors site, le chiffrement et des copies hors ligne. Le NCSC déconseille les dispositifs de sauvegarde en connexion permanente et recommande plus d’une solution ou d’un emplacement de sauvegarde.
Protégez l’administration des sauvegardes avec le principe du moindre privilège, l’authentification multi‑facteur quand elle est disponible, des comptes d’administration distincts et des revues d’accès. Utilisez la protection contre la suppression, l’historique de versions ou le stockage immuable uniquement après avoir compris leur coût et leur comportement de récupération. Chiffrez les données stockées et testez la garde des clés. Un chiffrement sans clés accessibles est inutilisable ; un accès trop largement partagé affaiblit chaque copie.
La copie doit avoir un mode de défaillance significativement différent de la production.
Listez qui peut lire, modifier, supprimer et restaurer les sauvegardes ; retirez les accès obsolètes.
Rédiger un runbook de reprise et attribuer l’autorité
Un runbook est la procédure de reprise testée. Conservez-en une copie accessible sans le site affecté, le fournisseur d’identité de production ou le système de chat habituel. Incluez les contacts et leurs remplaçants, l’autorité, la priorité des systèmes, les emplacements de sauvegarde, les prérequis, l’ordre de restauration, les contrôles de validation et les conditions d’arrêt.
Nommez un propriétaire de reprise responsable et un suppléant pour chaque service critique. Définissez qui autorise la restauration en production, les changements DNS et la validation des données métiers. Si des données de carte de paiement, des données personnelles sensibles ou des enregistrements réglementés sont concernés, obtenez l’avis qualifié de la sécurité, de la confidentialité, du juridique et, le cas échéant, de PCI avant de décider quoi préserver, notifier ou restaurer.
Enregistrez le point de restauration choisi, la personne ayant approuvé, les systèmes touchés, le résultat de la validation et les exceptions.
Documentez l’accès d’urgence contrôlé ; ne dépendez jamais de l’appareil ou de la mémoire d’un seul employé.
Restaurer en sécurité après une compromission suspectée
N’écrasez pas automatiquement la production avec la copie la plus récente lorsqu’un accès non autorisé, un logiciel malveillant ou une suppression suspecte est possible. Suivez le processus d’incident, évaluez quels comptes et sauvegardes peuvent être affectés, sélectionnez un point à partir des éléments de preuve et reconstruisez ou isolez l’environnement de reprise avant de le reconnecter.
La CISA oriente la reprise selon l’ordre de priorité des services critiques et met en garde contre la réinfection de systèmes propres. Le NCSC recommande de ne connecter les sauvegardes qu’à des appareils connus propres et de les scanner avant restauration. Ces étapes réduisent le risque, elles ne garantissent pas la propreté. Montez en charge vers une aide qualifiée en réponse aux incidents quand l’investigation, la conservation de preuves ou les obligations de notification peuvent s’appliquer.
Restaurez le service de plus haute priorité sur une infrastructure propre, validez-le, puis continuez selon l’ordre des dépendances.
Vérifiez les parcours utilisateurs, les données, les tâches, les intégrations, l’administration, la journalisation et la nouvelle couverture de sauvegarde.
Utiliser des exercices comme preuve et source d’amélioration
Exécutez des restaurations partielles, des reconstructions complètes isolées, des exercices de perte de dépendance ou des table‑tops selon le niveau de risque. Commencez par un test sûr et signifiant et augmentez le réalisme au fil du temps. La CISA recommande des tests de restauration complets et partiels ; le NCSC recommande des exercices pour clarifier les rôles, les responsabilités des tiers et les priorités.
Mesurez l’âge du point de restauration par rapport au RPO et le temps de reprise écoulé par rapport à l’RTO. Enregistrez l’identifiant du set, les participants, le résultat de validation, les étapes échouées et un propriétaire pour chaque correction. Retestez après la fermeture des lacunes et après tout changement matériel de plateforme, d’identité, de base de données ou de fournisseur. SIU peut organiser ce travail préventif de remédiation ; ce n’est pas un système de sauvegarde ni un service de surveillance en direct.
Conservez un compte rendu concis de ce qui a été restauré, où, ce qui a réussi, ce qui a échoué et qui l’a accepté.
Répétez les tests ciblés après un changement matériel de l’architecture ou des fournisseurs.
