Décomposer la règle sans jargon

La règle 3-2-1-1-0 décrit une sauvegarde robuste en six exigences complémentaires :

• 3 copies des données : l’original + au moins deux sauvegardes.
• 2 supports différents : pour éviter une panne commune (ex. deux systèmes identiques au même endroit).
• 1 copie hors site : pour survivre à un incident local (sinistre, vol, coupure prolongée).
• 1 copie hors ligne ou immuable : pour résister à une compromission (ransomware, suppression malveillante).
• 0 erreur : objectif atteint via surveillance et tests de restauration.

Pourquoi c’est pertinent face aux ransomwares

Un ransomware cherche souvent à :

• chiffrer les données de production ;
• supprimer les sauvegardes accessibles ;
• attaquer le serveur de sauvegarde ou les consoles d’administration.

La règle impose donc une copie que l’attaquant ne peut pas modifier (immutabilité) ou pas atteindre (hors ligne), et une copie hors site pour éviter l’effet « tout est au même endroit ». Le point 0 est crucial : une sauvegarde peut être "réussie" tout en étant inutilisable (données corrompues, application impossible à démarrer, dépendances oubliées).

Transformer la règle en architecture cible

Pour une PME, l’objectif n’est pas de multiplier les outils, mais de combiner des briques simples :

1. Une sauvegarde rapide pour restaurer vite (souvent locale).
2. Une sauvegarde isolée/immuable pour résister au sabotage.
3. Un processus de tests documenté, planifié, et mesuré.

Cette approche aligne la sauvegarde sur la réalité opérationnelle : RPO (perte de données acceptable) et RTO (temps de reprise) doivent être définis par application, puis traduits en fréquence de sauvegarde et en choix de stockage.

Les principales cibles de sauvegarde

Une stratégie de sauvegarde moderne assemble souvent plusieurs destinations, chacune ayant un rôle :

• NAS (sur site) : pratique pour des restaurations rapides et des coûts maîtrisés. Limite : si le NAS est joint au domaine et administrable comme le reste, il peut être ciblé.
• Bande (tape) : pertinente pour l’archivage et l’isolement physique (hors ligne). Limite : nécessite une discipline d’exploitation (rotation, stockage, inventaire) et des délais de restauration plus longs.
• Cloud “fichier/bloc” : facile à consommer, mais il faut clarifier les garanties (versions, verrouillage, rétention) et les coûts de sortie.
• Stockage objet type S3 : adapté aux sauvegardes immuables via des mécanismes comme Object Lock S3, avec une bonne scalabilité et des politiques de rétention.

Critères de décision pour PME

Pour choisir, partez des exigences (RPO/RTO, criticité, volume, dépendances applicatives), puis évaluez :

• Restauration : vitesse, simplicité, possibilité de restaurer une VM, un fichier, une base, un service complet.
• Sécurité : isolation réseau, immutabilité possible, gestion des identités, journalisation.
• Opérations : supervision, alertes, capacité à tester régulièrement, documentation.
• Résilience : copie hors site réelle, risques de panne commune, risque de suppression.
• Coûts : pas seulement le stockage, mais aussi la bande passante, les frais de récupération, et le temps humain.

Modèles d’architecture fréquents

1. Local + objet immuable : sauvegarde sur NAS pour le quotidien, réplication vers un stockage objet verrouillé pour la protection ransomware.
2. Local + bande : restauration rapide depuis disque, archivage hors ligne en bande.
3. Tout cloud + copie isolée : utile si l’infrastructure est majoritairement cloud, à condition de séparer strictement les comptes et les accès.

L’important : chaque cible doit être associée à une intention claire (rapidité, isolement, hors site), pas seulement à une préférence technologique.

Ce que signifie “sauvegarde immuable”

Une sauvegarde immuable est une sauvegarde dont la suppression ou la modification est empêchée pendant une durée définie (rétention). On parle souvent de WORM (Write Once, Read Many). L’objectif est de conserver une copie utilisable même si un attaquant obtient des droits élevés.

Les approches courantes

• Object Lock S3 : mécanisme de verrouillage au niveau objet, avec rétention gouvernée par des politiques. Utile pour garantir qu’une sauvegarde déposée ne peut pas être supprimée avant échéance.
• Stockage WORM (appliance ou service) : verrouillage similaire, selon l’implémentation.
• Snapshots protégés : clichés de volumes/VM, parfois “verrouillables” ou protégés par des droits spécifiques.

Bonnes pratiques d’implémentation

1. Définir des durées de rétention par type de données (production critique, bureautique, archives), en cohérence avec les exigences métier et réglementaires.
2. Éviter les “rétentions infinies” par défaut : elles compliquent l’exploitation et augmentent les coûts ; privilégiez des politiques explicites.
3. Isoler l’écriture : l’outil de sauvegarde doit pouvoir écrire, mais pas forcément supprimer.
4. Journaliser et auditer : traces d’accès, création, suppression (si autorisée), échecs, changements de politiques.

Limites et pièges à connaître

• L’immutabilité protège une copie, mais ne remplace pas la séparation des accès : si l’attaquant contrôle la console qui pilote les rétentions, le risque augmente.
• Certains snapshots ne sont pas des sauvegardes complètes : ils peuvent dépendre d’un stockage sous-jacent, d’une chaîne de snapshots, ou ne pas couvrir l’application (cohérence).
• L’immutabilité n’élimine pas le besoin de tests : une sauvegarde peut être intacte mais inutilisable (mauvais point de restauration, dépendances manquantes, clé de chiffrement perdue).

L’objectif est simple : disposer d’au moins une copie inviolable sur une durée pertinente, et pouvoir prouver qu’elle est restaurable.

Le problème : “si je peux l’administrer, un attaquant aussi”

Les ransomwares réussissent souvent parce que l’administration est trop centrale : mêmes comptes, mêmes mots de passe, mêmes consoles accessibles depuis le poste du quotidien. La règle 3-2-1-1-0 exige une copie hors d’atteinte, mais cela passe aussi par une séparation des accès.

Modèle de séparation réaliste pour PME

• Comptes dédiés :

- un compte “opérateur” (tâches courantes) ; - un compte backup admin (changement de politiques, rétention, dépôts immuables) ; - un compte “lecture seule” (audit, supervision).

• MFA : obligatoire a minima sur la console de sauvegarde et sur le fournisseur cloud/objet.
• Bastion / poste d’administration : accès aux consoles uniquement via un environnement d’admin dédié (machine durcie, droits limités, navigation restreinte).
• Principe du moindre privilège : l’outil de sauvegarde doit écrire sur la cible, mais les suppressions et changements de rétention doivent être contrôlés.

Cloisonnement technique

• Segmentation réseau : serveur de sauvegarde et dépôts dans un VLAN/segment distinct, flux strictement nécessaires.
• Identités séparées : éviter que l’administration du stockage de sauvegarde dépende du même annuaire et des mêmes groupes que la production.
• Journalisation centralisée : conserver des logs d’authentification et d’administration, avec alertes sur événements sensibles (échec MFA, changement de politique, tentative de suppression).

Contrôles simples qui changent tout

1. Désactiver l’administration depuis les postes utilisateurs.
2. Protéger les comptes à privilèges avec MFA et mots de passe uniques.
3. Documenter “qui peut faire quoi” sur les sauvegardes.

Cette discipline réduit drastiquement le risque que l’attaquant transforme un incident en perte totale de capacité de restauration.

Le principe : “zéro erreur” se prouve, il ne se déclare pas

Le dernier “0” de la règle 3-2-1-1-0 correspond à une exigence de qualité : pas d’échec silencieux, pas d’angle mort. Le moyen le plus fiable d’y parvenir est un programme de test de restauration planifié et documenté.

Quoi tester (au-delà du simple fichier)

• Restauration fichier : rapide, utile pour valider les permissions et la recherche.
• Restauration système/VM : capacité à redémarrer une machine dans un environnement isolé.
• Restauration applicative : base de données + service + dépendances (certificats, DNS, secrets, licences). C’est souvent là que se trouvent les surprises.
• Scénarios dégradés : restauration depuis la copie immuable/hors site, pas seulement depuis la copie locale “confort”.

Fréquence : une approche pragmatique

Plutôt que d’imposer un rythme unique, fixez une fréquence selon la criticité :

1. Applications vitales : tests plus réguliers, incluant une restauration complète.
2. Applications importantes : tests réguliers sur échantillon (VM ou base), plus un exercice complet périodique.
3. Données moins critiques : tests ponctuels, mais avec vérification d’intégrité et traçabilité.

L’important est d’avoir un calendrier connu, des responsables identifiés, et des preuves de réalisation.

Comment documenter (simple et exploitable)

Créez une fiche de test qui contient :

• périmètre (application, serveur, données) ;
• point de restauration visé (date/jeu) ;
• étapes de restauration ;
• critères d’acceptation (service démarre, utilisateurs se connectent, données cohérentes) ;
• temps observés (restauration, redémarrage, validation) ;
• écarts et actions correctives.

La documentation transforme les tests en amélioration continue : vous réduisez les surprises et vous rendez la restauration reproductible, même en situation de crise.

Piloter la sauvegarde comme un service

Sans indicateurs, une sauvegarde devient une suite de tâches techniques difficile à prioriser. Un tableau de bord doit répondre à trois questions :

1. Est-ce que ça sauvegarde ?
2. Est-ce que ça restaure ?
3. Est-ce que c’est conforme à nos règles (rétention, isolement, immutabilité) ?

Indicateurs utiles (et actionnables)

• Taux de succès des jobs : avec une distinction entre avertissements et échecs bloquants.
• Couverture : liste des actifs protégés (serveurs, VM, bases, SaaS le cas échéant) et détection des “oubliés”.
• Âge du dernier point de restauration : par application, en lien avec l’objectif de perte de données acceptable.
• État de l’immutabilité : dépôts verrouillés, rétentions appliquées, et alertes en cas de modification de politique.
• Capacité et tendance : pour éviter les saturations qui provoquent des échecs en chaîne.
• Résultats de tests : nombre de tests réalisés, taux de réussite, écarts récurrents.

Mettre en forme : un tableau simple

Vous pouvez commencer avec un tableau mensuel partagé :

Boucle d’amélioration continue

Le tableau de bord doit déclencher des décisions : corriger un job instable, ajuster une rétention, améliorer un runbook de restauration, ou prioriser la protection d’un actif oublié. L’objectif final : que la sauvegarde soit auditable, compréhensible, et défendable lors d’un incident.

Checklist opérationnelle 3-2-1-1-0 (PME)

Utilisez cette checklist pour valider rapidement votre niveau de maturité, puis en faire un plan d’actions.

Copies et supports

• Vérifier que vous avez au moins 3 copies (production + deux sauvegardes).
• Vérifier 2 supports différents (ex. disque et objet, ou disque et bande).
• Vérifier 1 copie hors site (site distant ou cloud, réellement distinct).

Isolement et immutabilité

• Disposer d’1 copie immuable ou hors ligne.
• Vérifier la rétention : règles écrites, durées cohérentes, exceptions documentées.
• Vérifier l’impossibilité de suppression avant échéance (selon la solution : WORM, Object Lock, politique de verrouillage).

Séparation des accès

• Comptes dédiés : opérateur, backup admin, audit.
• MFA activé sur les consoles sensibles.
• Administration via bastion/poste dédié.
• Segmentation réseau minimale (flux strictement nécessaires).

Tests de restauration

• Définir des scénarios : fichier, VM, application.
• Planifier un calendrier de tests (par criticité).
• Documenter chaque test : périmètre, étapes, critères d’acceptation, écarts.

Supervision et preuve

• Tableau de bord : succès/échecs, couverture, âge des points, capacité.
• Alertes traitées avec une procédure (qui fait quoi, sous quel délai).
• Stocker les rapports de tests et de conformité dans un emplacement accessible en crise.

Si vous cochez partiellement, priorisez d’abord : immutabilité + séparation des accès + un test de restauration complet sur une application critique.