Sauvegarde 3-2-1 : stratégie, restauration et limites

Niveau : débutant à intermédiaire.

Prérequis : connaître les notions de fichier, serveur, compte, chiffrement, stockage et dépendance applicative. Pouvoir créer et supprimer des fichiers dans un dossier local suffit pour l’exercice.

L’exercice utilise uniquement une arborescence fictive sur ta machine. Il ne chiffre aucun fichier, ne simule aucun rançongiciel, ne contacte aucun stockage distant et n’accède à aucune donnée réelle sensible.

La règle 3-2-1 est une heuristique de diversification : trois copies au total, deux supports ou systèmes distincts, une copie hors site. Le fichier de production compte comme une copie. Les autres doivent éviter une cause de défaillance commune. Deux dossiers sur le même disque ne constituent pas deux supports indépendants. Deux espaces gérés par le même compte cloud peuvent disparaître ensemble.

Le chiffre ne constitue pas une certification. Adapte la stratégie aux risques, aux obligations et aux dépendances. Documente pour chaque jeu de données sa source, sa destination, sa fréquence, sa rétention, son propriétaire et sa méthode de restauration.

Le NIST SP 800-34 Rev. 1 replace les sauvegardes dans la planification de continuité : analyse d’impact, stratégie de reprise, procédures, tests et maintenance. La copie est un moyen. L’objectif est le retour à une fonction métier définie, avec des données cohérentes.

La diversité utile porte sur les causes de perte, pas seulement sur les marques. Un disque externe branché en permanence partage le risque électrique, le compte administrateur et l’exposition au logiciel malveillant du poste. Une réplication immédiate vers un second serveur reproduit rapidement une suppression ou une corruption. Elle améliore parfois la disponibilité, mais ne remplace pas un historique de sauvegarde.

Évalue les défaillances communes : même bâtiment, alimentation, hyperviseur, fournisseur, compte, console, clé de chiffrement ou politique de rétention. La copie hors site traite notamment le sinistre local, mais elle peut rester accessible en ligne. La copie locale accélère parfois la restauration, mais elle doit être protégée contre la suppression.

Choisis les supports selon le volume et le délai : stockage objet avec verrouillage, appliance dédiée, bande, disque déconnecté ou service de sauvegarde. Chaque option a des limites de coût, de vitesse, de durée de conservation et d’exploitation. Les clés de chiffrement et les catalogues de sauvegarde sont eux-mêmes critiques. Sans eux, les blocs copiés peuvent être inutilisables. Prévois leur protection, leur secours et un accès d’urgence contrôlé.

Une copie hors ligne n’est pas accessible par les systèmes de production pendant sa conservation. Une bande retirée ou un disque physiquement déconnecté en sont des exemples. Une copie immutable ne peut pas être modifiée ou supprimée avant l’échéance prévue, même par les chemins ordinaires d’administration. Un instantané modifiable avec un compte privilégié n’est pas réellement immutable face à la compromission de ce compte.

Le NCSC britannique détaille les principes de sauvegardes résistantes aux ransomwares : résistance à la destruction, alertes sur les changements, rétention prédéfinie et restauration possible. Combine ces propriétés avec des identités d’administration dédiées, une authentification forte, des rôles minimaux et un réseau de gestion séparé lorsque le risque le justifie.

Teste aussi le mode d’urgence. Une immutabilité mal configurée peut empêcher une suppression légitime ou faire exploser les coûts. Une copie hors ligne peut être trop ancienne si la rotation échoue. Surveille les travaux, les volumes inattendus, les modifications de politique et les suppressions. L’absence d’erreur affichée ne prouve ni l’exhaustivité de la copie ni son intégrité.

Le Recovery Point Objective, ou RPO, décrit le point de reprise visé et donc la perte de données maximale tolérée exprimée en temps. Avec un RPO de quatre heures, la stratégie doit permettre de revenir à un état datant au plus de quatre heures dans les conditions prévues. Une sauvegarde quotidienne ne satisfait généralement pas ce besoin.

Le Recovery Time Objective, ou RTO, décrit le délai visé pour rétablir une fonction après l’interruption. Il inclut la décision, l’accès aux personnes, la récupération des supports, la reconstruction, la restauration, les contrôles et la remise en service. Un transfert de données rapide ne suffit pas si les clés, le DNS, l’annuaire ou les procédures sont absents.

Fixe ces objectifs par service après une analyse d’impact. Les réduire augmente souvent le coût et la complexité. Mesure le RPO réellement obtenu grâce aux horodatages des dernières sauvegardes valides. Mesure le RTO lors d’exercices complets, pas à partir du débit théorique. Distingue enfin objectif et résultat : écrire « RTO 8 h » ne démontre pas que la reprise tient dans ce délai. Les écarts doivent conduire à un arbitrage ou à une amélioration.

La fréquence dépend du rythme de changement et du RPO. La rétention dépend du délai de découverte d’une corruption, des obligations et du coût. Plusieurs points dans le temps sont nécessaires, car la dernière copie peut déjà contenir des données altérées. Une politique typique combine versions fréquentes récentes et archives moins fréquentes plus anciennes, mais son calendrier doit découler du besoin.

Pour une application, sauvegarder seulement les fichiers visibles peut être insuffisant. Il faut parfois coordonner base de données, fichiers joints, configuration, secrets, certificats, code déployé et métadonnées d’infrastructure. Une copie crash-consistent ou application-consistent ne fournit pas le même niveau de cohérence. Documente la méthode de remise en relation des composants.

Protège les sauvegardes en transit et au repos lorsque la sensibilité l’exige. Le chiffrement limite l’exposition du support, mais crée une dépendance aux clés. Observe les échecs, durées, volumes, écarts de fréquence et expirations de rétention. Vérifie qu’un nouveau serveur ou volume entre bien dans la politique. Un rapport vert portant sur 90 % du périmètre ne couvre pas les 10 % oubliés.

Un test utile part d’un scénario et d’un objectif. Choisis une date de reprise, restaure dans une zone isolée, mesure les temps, vérifie l’intégrité et exécute des contrôles fonctionnels. Pour une application fictive, cela peut signifier ouvrir des enregistrements, vérifier leurs relations, lancer un calcul connu et confirmer les droits. La simple extraction d’une archive ne prouve pas la reprise du service.

Teste plusieurs niveaux : un fichier supprimé, un volume, une base, puis un service complet avec dépendances. Fais parfois le test sans l’administrateur habituel pour vérifier la documentation et les accès d’urgence. Consigne l’identifiant de la sauvegarde, les étapes, les erreurs, le temps de récupération, le temps de validation et la décision finale.

La norme ISO 22301:2019 encadre un système de management de la continuité et insiste sur la préparation, l’exercice, l’évaluation et l’amélioration. Elle ne dicte pas une architecture 3-2-1 universelle. Utilise-la pour replacer les tests techniques dans la capacité globale de continuité. Après chaque test, corrige la procédure et planifie une nouvelle vérification de l’écart.

Une sauvegarde peut réduire l’impact d’un chiffrement destructeur, mais elle ne bloque pas l’intrusion. Un acteur peut voler les données avant de les chiffrer, supprimer les copies accessibles, compromettre la console, attendre l’expiration des versions saines ou contaminer les sauvegardes. La restauration ne résout ni l’exfiltration, ni l’obligation de notification, ni la persistance sur un autre système.

Le guide StopRansomware de la CISA recommande des sauvegardes hors ligne ou cloud à cloud, protégées, régulièrement testées et non connectées en permanence aux systèmes sauvegardés. Ces mesures complètent la MFA, le moindre privilège, les correctifs, la segmentation, la journalisation et la réponse à incident.

Une copie immutable conserve aussi les données indésirables jusqu’à l’expiration. Elle n’indique pas quel point est sain. Préserve donc une profondeur d’historique et les traces permettant de dater l’incident. Pendant la reprise, reconstruis les identités et systèmes de confiance avant de reconnecter les données. Sinon, la restauration peut réintroduire le même chemin de compromission. Les sauvegardes sont une couche de résilience, pas un antivirus ni une garantie de non-paiement.

Crée un dossier atelier-backup avec production, copie-locale et copie-isolee. Dans production, crée clients-fictifs.txt contenant trois lignes inventées et config-fictive.txt. Copie les deux fichiers vers les deux destinations, puis calcule localement leur empreinte SHA-256 avec l’outil disponible sur ta machine. Note date, taille et empreinte dans registre.txt.

Supprime uniquement clients-fictifs.txt de production. Restaure-le d’abord vers un dossier séparé validation, compare son empreinte au registre et vérifie ses trois lignes avant de le remettre en production. Considère copie-isolee comme une représentation pédagogique : un dossier du même disque n’est ni hors site, ni hors ligne, ni immutable.

Critère observable

Le test est réussi si le fichier restauré possède exactement la même empreinte et les trois mêmes lignes, si registre.txt contient l’heure de début, l’heure de fin et la copie choisie, et si tu calcules le RPO observé à partir de l’âge de cette copie. Note aussi le RTO mesuré entre la décision de restaurer et la validation. Aucun fichier extérieur à atelier-backup ne doit être lu, modifié ou supprimé.

• Compter une synchronisation comme une sauvegarde. Elle peut répliquer immédiatement suppression et corruption.
• Placer toutes les copies sous le même compte. Une compromission privilégiée peut toutes les atteindre.
• Confondre hors site et hors ligne. Une copie distante peut rester accessible en permanence.
• Présumer l’immutabilité. Vérifie les droits, la durée verrouillée et les chemins d’administration.
• Sauvegarder les données sans les dépendances. Clés, configuration et annuaire peuvent bloquer la reprise.
• Tester seulement l’ouverture d’une archive. Valide la fonction métier et la cohérence.
• Définir RPO et RTO sans mesure. Compare les objectifs aux exercices réels.
• Conserver une seule version récente. Une corruption ancienne peut déjà s’y trouver.
• Croire que la sauvegarde annule un ransomware. Elle ne traite ni le vol de données ni la persistance.

La règle 3-2-1 ne convient pas seule à tous les systèmes. Les volumes, exigences de confidentialité, environnements industriels, services SaaS et contraintes réglementaires demandent des adaptations. Documente les hypothèses, les responsabilités et le risque résiduel.