La perte irréversible de données reste l’un des scénarios les plus redoutés par les équipes IT, et pourtant les architectures de sauvegarde continuent d’être sous-dimensionnées ou mal testées dans de nombreuses organisations. La règle 3-2-1, formalisée par le photographe Peter Krogh dans son ouvrage The DAM Book (2005) et depuis adoptée comme référence par des organismes comme la CISA et le NIST, offre un cadre structurant : trois copies des données, sur deux supports différents, dont une copie hors site. Ce principe, simple en apparence, demande une lecture actualisée à l’heure où les ransomwares ciblent délibérément les sauvegardes immuables et où les environnements cloud introduisent de nouveaux modèles de responsabilité partagée.
Ce que dit réellement la règle 3-2-1
La règle 3-2-1 repose sur trois contraintes distinctes qui se renforcent mutuellement.
Trois copies signifie une copie de production et deux sauvegardes. L’objectif est statistique : réduire la probabilité que toutes les copies soient perdues simultanément. Une seule sauvegarde ne protège pas contre une défaillance concurrente de la production et du backup.
Deux supports différents vise à éliminer les modes de défaillance communs. Deux copies sur le même NAS partagent la même baie, le même contrôleur, le même incident physique potentiel. La combinaison classique associe disque local et stockage objet cloud, ou bande et cloud.
Une copie hors site protège contre les sinistres physiques localisés (incendie, inondation, destruction du datacenter) et contre les ransomwares qui se propagent latéralement sur le réseau de production. La copie hors site doit être inaccessible depuis le système compromis.
| Contrainte | Objectif | Risque adressé |
|---|---|---|
| 3 copies | Redondance statistique | Défaillance simultanée de plusieurs supports |
| 2 supports | Élimination des modes communs | Incident matériel unique |
| 1 copie hors site | Isolation géographique et réseau | Sinistre physique, propagation ransomware |
Pourquoi la règle 3-2-1 seule ne suffit plus
Les ransomwares de troisième génération, documentés par l’ENISA dans son rapport Threat Landscape 2024, intègrent des modules de reconnaissance qui cartographient les partages réseau, les agents de sauvegarde et les accès cloud configurés sur les machines compromises. Avant le déclenchement du chiffrement, l’attaquant supprime ou chiffre les sauvegardes accessibles. Les groupes comme LockBit 3.0 ou BlackCat/ALPHV utilisent cette tactique de manière systématique, référencée dans le catalogue MITRE ATT&CK sous la technique T1490 (Inhibit System Recovery).
Une sauvegarde cloud connectée via des credentials stockés en clair sur le serveur de production est accessible à un attaquant ayant compromis ce serveur. La règle 3-2-1 ne traite pas l’authentification, l’immuabilité ou le cloisonnement réseau des sauvegardes.
La variante 3-2-1-1-0 apporte deux exigences supplémentaires :
- 1 copie air-gapped ou hors ligne : physiquement déconnectée ou dans un stockage cloud avec accès restreint par politique IAM stricte, sans credentials permanents depuis la production.
- 0 erreur vérifiée : la dernière copie doit avoir été restaurée avec succès, validée par un processus automatisé.
La CISA documente cette évolution dans son guide StopRansomware et recommande explicitement l’isolation des sauvegardes comme mesure prioritaire.
Un point souvent sous-estimé dans les environnements cloud : l’accessibilité réseau des buckets de sauvegarde. Un bucket exposé sur l’internet public, même protégé par IAM, présente une surface d’attaque plus large qu’un bucket accessible uniquement via un VPC endpoint privé. La configuration d’un endpoint privé pour restreindre les chemins d’accès aux sauvegardes est une mesure complémentaire directe à l’immuabilité, disponible chez les trois principaux hyperscalers.
L’immuabilité : le contrôle technique central
L’immuabilité des sauvegardes (mode WORM, Write Once Read Many) interdit toute modification ou suppression d’un objet pendant une période définie, y compris par un compte administrateur authentifié. C’est aujourd’hui le contrôle technique le plus robuste contre la destruction ou le chiffrement des backups par un attaquant ayant obtenu des privilèges élevés.
Les trois principaux hyperscalers proposent des fonctionnalités natives :
| Fournisseur | Service | Mode le plus strict | Caractéristique |
|---|---|---|---|
| AWS | S3 Object Lock | Compliance | Irréversible, même compte root |
| Azure | Immutable Blob Storage | Time-based retention verrouillée | Politique verrouillée non modifiable |
| GCP | Retention policy + Bucket Lock | Bucket Lock | Verrou définitif de la politique de rétention |
Le mode Compliance d’AWS S3 Object Lock est le plus strict : une fois activé, même le compte root de l’organisation ne peut pas supprimer les objets avant l’expiration de la période de rétention. Il convient aux sauvegardes critiques soumises à des obligations réglementaires. Le mode Governance permet à des comptes disposant de permissions spécifiques de contourner la rétention, ce qui reste insuffisant en cas de compromission des accès privilégiés.
La durée de rétention doit couvrir au minimum le délai médian de détection d’une compromission. L’ENISA Threat Landscape 2024 souligne que les attaquants maintiennent une présence silencieuse de plusieurs semaines avant le déclenchement du chiffrement dans les incidents ransomware analysés en Europe. Une rétention de 30 à 90 jours est la pratique courante pour les sauvegardes critiques. L’ANSSI, dans ses recommandations sur les architectures SI sensibles, insiste sur la nécessité de garantir que les sauvegardes ne peuvent pas être modifiées ou supprimées par un compte compromis sur le système de production.
RPO, RTO et stratégie de restauration
La sauvegarde n’a de valeur que si la restauration est testée et documentée. Deux indicateurs structurent la stratégie :
- RPO (Recovery Point Objective) : la perte de données maximale acceptable, exprimée en durée. Un RPO de 4 heures impose des sauvegardes toutes les 4 heures au maximum, complétées par des journaux de transactions pour les bases de données.
- RTO (Recovery Time Objective) : le délai maximal de remise en service opérationnelle. Il doit être mesuré lors de tests réels, pas estimé théoriquement.
La cohérence entre RPO, RTO et architecture de sauvegarde doit être documentée dans le Plan de Continuité d’Activité (PCA) et le Plan de Reprise d’Activité (PRA). Le NIST SP 800-209 (Security Guidelines for Storage Infrastructure) fournit un cadre de référence pour la classification des données et la définition de ces objectifs par niveau de criticité.
Un point souvent négligé : le RTO partiel. Restaurer 80 % d’un système critique en 2 heures peut être acceptable si les 20 % restants sont secondaires. Cette granularité doit être explicitement définie et testée.
| Fréquence | Périmètre | Objectif |
|---|---|---|
| Mensuelle | Fichier ou base unitaire | Valider l’intégrité des sauvegardes récentes |
| Trimestrielle | Système complet non critique | Mesurer le RTO réel |
| Annuelle | Simulation d’incident majeur | Valider le PRA bout en bout |
Pour les workloads Kubernetes, la stratégie de restauration doit intégrer les volumes persistants (PVC) et les objets de configuration (ConfigMaps, Secrets, manifestes de déploiement). Des outils comme Velero permettent de sauvegarder l’état complet d’un cluster et de tester la restauration dans un environnement de staging. Le RTO d’un cluster Kubernetes est généralement plus long que pour un serveur traditionnel si les images de conteneurs ne sont pas mises en cache localement : ce paramètre doit figurer explicitement dans le PRA.
Obligations réglementaires : NIS2, DORA et RGPD
Le délai de transposition de NIS2 était fixé au 17 octobre 2024. La France n’a pas respecté ce délai : l’ordonnance n°2025-276 transposant la directive en droit français a été publiée au Journal Officiel le 7 avril 2025. Les entités essentielles et importantes ont l’obligation formelle de disposer de politiques de sauvegarde et de restauration testées, intégrées dans une gestion documentée de la continuité d’activité. Un incident majeur doit être notifié à l’ANSSI dans les 24 heures suivant la détection.
DORA, applicable aux entités financières depuis le 17 janvier 2025, va plus loin : il exige des RTO et RPO documentés par système critique, des tests de résilience opérationnelle annuels incluant des scénarios de défaillance de prestataires cloud, et une traçabilité complète des sauvegardes et restaurations. Les orientations techniques de l’Autorité Bancaire Européenne (ABE) précisent les attentes pour les établissements financiers.
Le RGPD (article 32) impose des mesures techniques garantissant la disponibilité et la résilience des traitements de données personnelles. Une perte définitive de données personnelles sans backup constitue une violation à notifier à la CNIL dans les 72 heures.
Ces trois cadres convergent : la sauvegarde n’est plus un choix technique laissé à l’appréciation des équipes IT, mais une obligation documentée, testée et auditable.
Points de vigilance pour les équipes IT
Plusieurs erreurs récurrentes fragilisent les architectures de sauvegarde pourtant conformes sur le papier à la règle 3-2-1 :
Credentials cloud stockés sur le serveur de production : un attaquant qui compromet le serveur récupère les accès cloud et peut supprimer les sauvegardes. La solution est d’utiliser des rôles IAM à durée de vie courte (assume-role, Workload Identity Federation) sans credentials statiques persistants.
Absence de supervision des jobs de sauvegarde : un job en échec silencieux peut passer inaperçu plusieurs semaines. Il faut superviser activement les résultats et alerter sur tout échec ou anomalie de taille de backup. Un backup dont la taille diminue de 30 % sans explication est un signal d’alerte aussi important qu’un échec total.
Chiffrement sans gestion sécurisée des clés : chiffrer les backups est une bonne pratique, mais si les clés sont stockées au même endroit que les sauvegardes, elles seront perdues ou compromises simultanément. Les solutions de gestion de clés dédiées (AWS KMS, Azure Key Vault, GCP Cloud KMS) avec séparation des droits et rotation automatique sont recommandées.
Dépendance exclusive à un seul hyperscaler : deux buckets chez le même fournisseur partagent le plan de contrôle, les incidents de facturation et les risques d’indisponibilité régionale. Une copie chez un fournisseur secondaire ou sur un support différent renforce réellement la résilience et satisfait l’exigence de diversité de supports.
Restauration jamais testée en conditions réelles : la conformité à la règle 3-2-1 est vérifiable sur papier ; la capacité réelle à restaurer dans le RTO cible ne l’est que par un exercice réel. Les organisations qui n’ont pas réalisé de test de restauration grandeur nature dans les 12 derniers mois ne connaissent pas leur RTO réel.
La stratégie de sauvegarde cloud doit être traitée comme un composant de sécurité à part entière, intégré dans la posture globale de défense. Face aux vecteurs d’attaque ransomware actuels, les sauvegardes immuables et régulièrement testées constituent souvent la dernière ligne de défense effective entre un incident contenu et une compromission totale.