1. Origine et limites structurelles du modèle 3-2-1

La règle 3-2-1 est née dans le contexte d’un modèle de risque essentiellement accidentel:

• défaillance matérielle,
• les erreurs humaines,
• les événements locaux (incendie, inondation, panne d’électricité).

Le modèle suppose implicitement :

• des menaces non coordonnées,
• l’absence d’attaquants avec persistance,
• des systèmes de sauvegarde distincts mais fiables.

D’un point de vue technique, le 3-2-1 a assuré :

• la redondance des données,
• la diversification des médias,
• la protection contre les événements spécifiques au site.

Ce qu’ il ne couvrait pas (et ne pouvait pas couvrir) :

• avec des privilèges administratifs,
• la compromission des identités,
• les mouvements latéraux et les attaques de type « living off the land »,
• l’effacement ou le cryptage coordonné des sauvegardes.

2. Le nouveau modèle de menace : attaques destructrices et compromission systémique

Dans le paysage actuel des menaces, les sauvegardes sont devenues des cibles privilégiées.
Les attaquants ne cherchent plus seulement à crypter les données de production, mais aussi à en faire autant :

• supprimer les référentiels de sauvegarde,
• des catalogues corrompus,
• crypter les instantanés et les copies secondaires,
• modifier la conservation et la politique,
• saboter les mécanismes de restauration.

D’un point de vue technico-opérationnel, cela signifie que :

• la joignabilité du réseau devient une vulnérabilité,
• les informations d’identification partagées représentent un point de défaillance unique,
• la séparation logique ne suffit pas.

Une sauvegarde compromise équivaut en fait à une sauvegarde inexistante.

3. De la sauvegarde à l’assurance de la récupération

L’étape clé n’est pas technologique, mais conceptuelle :
de la sauvegarde en tant qu’atout à la sauvegarde en tant que capacité.

En termes de BCM :

• le nombre de copies existantes n’a pas d’importance,
• compte si et comment elles peuvent être restaurées dans le cadre du RTO/RPO défini,
• compte la probabilité de réussite de la restauration dans des conditions défavorables.

Cela introduit le concept d’assurance de la récupération, qui exige :

• l’isolement,
• la vérifiabilité,
• la testabilité,
• la gouvernance.

4. Analyse technique de la règle 3-2-2-1-0

La règle 3-2-2-1-0 n’est pas une formule mnémotechnique, mais un cadre de contrôle des risques.

3 copies des données

Redondance minimale à gérer :

• les erreurs d’écriture,
• la corruption silencieuse,
• une défaillance pendant la sauvegarde ou la restauration.

2 supports différents

Réduction du risque de :

• les insectes systémiques,
• défaillance du micrologiciel,
• les vulnérabilités communes des plates-formes.

Exemples :

• disque + stockage d’objets,
• NAS + bande,
• sur site + en nuage.

2 exemplaires vraiment distincts

Un élément souvent sous-estimé.

La séparation doit se faire :

• physique (différents sites),
• logique (compte, location, abonnement),
• administratif (identité et rôles distincts).

Une séparation uniquement logique au sein d’un même domaine de sécurité est insuffisante contre un attaquant persistant.

1 copie hors site

Protection contre :

• les événements destructeurs locaux,
• les accidents environnementaux,
• indisponibilité prolongée du site principal.

Du point de vue du BCM, cette copie est essentielle pour la reprise après sinistre.

1 copie isolée ou immuable

C’est le véritable changement de paradigme.

Solutions typiques :

• à air comprimé (physique ou logique),
• stockage immuable (WORM, verrouillage d’objet),
• sauvegarde avec rétention non modifiable,
• la séparation complète des pouvoirs.

Caractéristiques principales :

même avec des privilèges administratifs compromis, la copie ne peut être ni modifiée ni supprimée.

Cette copie représente la dernière ligne de défense contre les cyber-événements destructeurs.

0 erreur dans les tests de récupération

L’exigence la plus stricte.

Signification :

• restaurer les tests automatisés et périodiques,
• la vérification de l’intégrité des données,
• la mesure effective du RTO et du RPO,
• même dans des scénarios dégradés ou compromis.

Une sauvegarde qui n’a jamais été testée est une hypothèse, pas un contrôle.

5. Intégration avec BCM et BIA

Du point de vue de la gestion de la continuité des activités :

• la stratégie de sauvegarde doit être dérivée de l’analyse de l’impact sur l’entreprise,
• les données doivent être classées en fonction de la criticité des processus,
• Le RTO/RPO ne peut pas être défini par les services informatiques seuls.

La sauvegarde devient une mesure de continuité et non un service d’infrastructure générique.

Cela implique :

• cartographie des données ↔ processus critiques,
• différenciation des politiques de sauvegarde,
• l’alignement sur les plans de réponse aux crises et aux incidents.

6. Cohérence avec la résilience opérationnelle et les exigences réglementaires

Le cadre 3-2-2-1-0 est parfaitement compatible avec les principes requis par les exigences modernes de résilience opérationnelle :

• la capacité à résister à des événements extrêmes mais plausibles,
• une résilience démontrable,
• des preuves objectives,
• réduction du point de défaillance unique.

Il n’est pas nécessaire « d’avoir des sauvegardes », mais de le faire :

• restaurer les fonctions critiques,
• dans des délais définis,
• même en présence d’attaques destructrices.

7. Conclusion technique

Dans un contexte moderne :

• la sauvegarde n’est plus une fonction informatique,
• est une capacité de résilience opérationnelle.

Sans isolation, sans véritable séparation et sans tests rigoureux,
la présence de sauvegardes ne réduit pas le risque d’une panne majeure.

Questions opérationnelles à poser

• Quel est le niveau maximal de compromission auquel nos sauvegardes peuvent résister ?
• Existe-t-il au moins une copie inaltérable même si l’identité est compromise ?
• Les tests de restauration mesurent-ils réellement le RTO/RPO annoncé ?
• La stratégie de sauvegarde est-elle conçue en fonction des processus ou des infrastructures critiques ?

Car, en fin de compte, la résilience n’est pas une déclaration architecturale, mais une capacité testée sous contrainte

---