La règle de sauvegarde 3-2-1 (trois copies, deux types de supports, une copie hors site) protège contre les défaillances pour lesquelles elle a été écrite : une baie de disques hors service, un volume corrompu, une salle serveurs inondée. Elle n’a jamais été conçue pour un adversaire qui localise le catalogue de sauvegarde, supprime les dépôts, puis seulement ensuite chiffre la production. La règle étendue 3-2-1-1-0 vise à combler cette lacune.
L’extension ajoute une copie hors ligne, isolée par air gap ou immuable, et une exigence de zéro erreur après vérification de la restauration. Ces ajouts imposent deux questions que la règle d’origine ne posait jamais : un attaquant détenant des identifiants d’administrateur peut-il détruire toutes les copies, et quelqu’un sait-il réellement que les sauvegardes se restaurent ? Cet article explique chaque chiffre, la manière dont le stockage objet immuable répond à la copie supplémentaire, ce que « zéro erreur » signifie en pratique, et se termine par une architecture illustrative et une checklist.
Qu’est-ce que la règle 3-2-1-1-0 ?
La règle 3-2-1-1-0 fixe cinq conditions minimales pour une stratégie de sauvegarde : trois copies des données, sur deux technologies de stockage, une copie hors site, une copie hors ligne, isolée par air gap ou immuable, et zéro erreur à la vérification. Les trois premiers chiffres constituent la règle classique ; les deux derniers ont été ajoutés lorsque le ransomware est devenu le scénario de reprise dominant.
La lecture simpliste est qu’elle signifie simplement davantage de copies. Si chaque copie peut être supprimée avec les mêmes identifiants, une quatrième copie n’apporte pas grand-chose. Le « 1 » supplémentaire mérite sa place par son indépendance vis-à-vis du plan de contrôle utilisé partout ailleurs ; le « 0 » remplace l’hypothèse que les sauvegardes fonctionnent par la preuve qu’elles fonctionnent.
Contre quoi chaque chiffre protège-t-il ?
3 : trois copies
La production plus au moins deux sauvegardes, afin qu’un événement unique tel qu’une défaillance de contrôleur ne puisse pas détruire ensemble les données et leur unique sauvegarde. Aujourd’hui, il s’agit généralement d’un dépôt principal sur site pour des restaurations rapides plus une seconde copie sur un autre dépôt ou un stockage objet.
2 : deux technologies de stockage
Les copies de sauvegarde ne doivent pas partager un mode de défaillance : le même bug de firmware, la même corruption de système de fichiers ou le même compte administrateur capable de supprimer les deux. Historiquement, cela signifiait disque et bande ; aujourd’hui, il s’agit plus souvent d’un dépôt bloc ou fichier plus un stockage objet S3.
1 : une copie hors site
Protection contre l’incendie, l’inondation, la coupure électrique ou la panne régionale, généralement assurée par une réplication vers un centre de données secondaire ou un travail de copie vers un site de colocation ou un cloud public. Hors site ne signifie pas protégé contre le ransomware : une réplique qui hérite des suppressions de la source reste exposée.
1 : une copie hors ligne, isolée par air gap ou immuable
C’est le chiffre du ransomware. Il protège contre un attaquant qui a compromis le serveur de sauvegarde, l’hyperviseur ou le domaine et détient des identifiants légitimes. La copie doit être une copie que ces identifiants ne peuvent ni modifier ni supprimer :
- Hors ligne : support physiquement déconnecté après l’écriture, le plus souvent une bande éjectée et conservée dans un coffre.
- Isolée par air gap : une cible sur un réseau séparé, accessible uniquement pendant une fenêtre contrôlée.
- Immuable : un stockage qui applique une rétention en écriture unique au niveau du stockage, de sorte que même le compte propriétaire ne peut ni supprimer ni écraser un objet avant l’expiration de sa rétention. En stockage objet, il s’agit de S3 Object Lock en mode compliance.
0 : zéro erreur après vérification
La défaillance ici est silencieuse : un travail peut signaler un succès tout en écrivant une image impossible à monter ou une machine virtuelle qui ne démarre pas. L’exigence est que la vérification, et non l’état du travail, rapporte zéro erreur.
Comment les chiffres correspondent-ils aux menaces et aux erreurs courantes ?
| Chiffre | Menace traitée | Mises en œuvre courantes | Erreur typique |
|---|---|---|---|
| 3 copies | Une défaillance détruisant les données et leur unique sauvegarde | Production plus dépôt principal plus copie secondaire | Compter les snapshots de la baie de production comme une copie |
| 2 technologies | Mode de défaillance partagé entre les copies | Dépôt bloc ou fichier plus stockage objet S3 ; disque plus bande | Deux dépôts sur la même plateforme et le même compte administrateur |
| 1 hors site | Perte de site, panne régionale | Centre de données secondaire, colocation, stockage objet cloud | Réplication qui propage fidèlement les suppressions |
| 1 hors ligne / immuable | Attaquant disposant d’identifiants d’administrateur de sauvegarde ou de domaine | Bande éjectée, cible sur réseau isolé, S3 Object Lock en mode compliance | Mode governance, ou rétention plus courte que le temps de présence de l’attaquant |
| 0 erreur | Corruption silencieuse, sauvegardes non restaurables | Analyses d’intégrité, vérification de démarrage, restaurations de test planifiées | Considérer « travail terminé » comme une preuve de restaurabilité |
Comment le stockage objet immuable répond-il au « 1 » supplémentaire ?
La bande reste une copie hors ligne légitime, mais elle implique une logistique que de nombreuses équipes ne sont plus dimensionnées pour assurer : maintenance de la librairie, rotation des supports, transport vers le coffre, et restaurations qui attendent la bonne cartouche. Un air gap évite la manipulation des supports mais dépend toujours d’une discipline de planification. Le stockage objet immuable atteint le même résultat en rendant la copie logiquement indélébile pendant une période définie plutôt qu’en la séparant physiquement.
Lorsque l’application de sauvegarde écrit un objet avec une période de rétention en mode compliance, le stockage refuse toute suppression ou tout écrasement jusqu’à l’expiration de cette période, quel que soit le demandeur. Un serveur de sauvegarde compromis peut toujours émettre des commandes de suppression ; il reçoit simplement des erreurs. La rétention étant appliquée au niveau du stockage, reconfigurer ou désinstaller l’application de sauvegarde ne la supprime pas.
Plusieurs conséquences de conception en découlent. Le compte utilisé par l’application de sauvegarde ne doit détenir que des permissions d’écriture, afin que sa compromission ne puisse pas modifier les politiques de bucket. L’administration du stockage doit utiliser une identité distincte avec authentification multifacteur, détenue par des personnes différentes de celles chargées de l’administration des sauvegardes. La rétention doit dépasser le temps de présence probable de l’attaquant, car un intrus présent pendant des semaines attendra simplement la fin d’une période courte. Les principales applications de sauvegarde, dont Veeam, Commvault, Rubrik, Cohesity et HYCU, écrivent directement vers des buckets avec object lock activé ; en termes Veeam, il s’agit d’un niveau de capacité immuable d’un scale-out backup repository ou d’un dépôt de stockage objet direct. Déployée sur un second site, la même cible couvre également la seconde technologie et la copie hors site.
Que signifie « zéro erreur » en pratique ?
Une interprétation viable comporte trois couches.
Contrôles d’intégrité du dépôt
L’application de sauvegarde ou le système de stockage relit les données stockées et les compare aux sommes de contrôle enregistrées lors de l’écriture, détectant la dégradation des bits et les écritures incomplètes avant qu’une restauration n’en dépende. Les stockages objet le font généralement en continu.
Vérification automatisée des restaurations
La plupart des applications de sauvegarde d’entreprise peuvent monter un point de restauration dans un environnement isolé, le démarrer et exécuter des contrôles applicatifs selon un calendrier. Un échec dans ce rapport signifie que la sauvegarde n’est pas comptée comme bonne, quel que soit l’état du travail.
Restaurations de test planifiées
Les contrôles automatisés prouvent que les données sont lisibles ; une restauration de test prouve que les personnes, les procédures et l’infrastructure peuvent remettre un service en service dans le délai cible. Elle doit être effectuée spécifiquement depuis la copie immuable, car une restauration depuis le dépôt principal ne dit rien de la copie qui comptera pendant une attaque. Zéro erreur ne signifie pas qu’aucun problème n’est jamais trouvé ; cela signifie que chaque problème trouvé est corrigé et que les sauvegardes concernées sont revérifiées.
À quoi ressemble une architecture conforme pour un environnement de taille intermédiaire ?
Supposons qu’une organisation exploite environ 400 machines virtuelles réparties sur deux sites, détienne environ 150 To de données primaires et vise la restauration des services essentiels dans les 24 heures suivant un événement ransomware. Les chiffres sont illustratifs ; c’est la forme de l’architecture qui compte.
- Copie 1 : données de production sur la baie principale du site A.
- Copie 2 : le dépôt de sauvegarde principal du site A, un dépôt Linux durci ou une appliance de déduplication conservant 14 jours de points de restauration.
- Copie 3 : un dépôt de stockage objet S3 sur le site B, écrit avec object lock en mode compliance et une rétention de 30 jours, avec des points de restauration mensuels conservés plus longtemps pour la conformité.
Cela donne trois copies, deux technologies, une copie hors site et une copie immuable. Le « 0 » est satisfait par une vérification de démarrage automatisée hebdomadaire des 40 machines virtuelles les plus critiques, un contrôle d’intégrité continu sur les deux dépôts, et une restauration complète trimestrielle d’une application métier depuis la copie du site B, le dépôt principal étant exclu. Deux détails sont souvent oubliés : les identifiants d’administration du stockage objet sont détenus par l’équipe infrastructure plutôt que par l’équipe sauvegarde, et la rétention de 30 jours reflète un plan d’incident qui suppose qu’un attaquant peut être présent pendant plusieurs semaines avant d’être détecté.
Checklist : passer en revue une stratégie existante au regard du 3-2-1-1-0
- Existe-t-il deux copies de sauvegarde indépendantes de la baie de production, les snapshots de baie étant exclus du décompte ?
- Un seul compte administrateur peut-il supprimer les deux copies de sauvegarde ?
- La copie hors site survit-elle à une suppression ou à un chiffrement à la source ?
- Une copie est-elle protégée par un mécanisme que les propres identifiants du serveur de sauvegarde ne peuvent pas contourner ?
- La rétention d’immutabilité est-elle plus longue que le temps de présence de l’attaquant supposé ?
- Les administrateurs du stockage, de la sauvegarde et du domaine sont-ils des identités distinctes avec authentification multifacteur ?
- La vérification automatisée des restaurations s’exécute-t-elle, et quelqu’un examine-t-il les résultats ?
- Une restauration complète depuis la copie immuable a-t-elle été réalisée au cours de l’année écoulée, et le temps a-t-il été comparé à l’objectif de reprise ?
Comment Scality ARTESCA sert de copie immuable
Scality ARTESCA est un stockage objet S3 conçu pour la sauvegarde, disponible sous forme de logiciel ou d’appliance matérielle, de quelques dizaines de téraoctets à plusieurs pétaoctets. Il prend en charge S3 Object Lock, de sorte que les points de restauration ne peuvent être ni supprimés ni écrasés avant l’expiration de leur rétention, ce qu’exige le quatrième chiffre de la règle.
ARTESCA est validé avec les principales applications de sauvegarde, dont Veeam, Commvault, Cohesity, Rubrik, HYCU, Veritas, Zerto, Acronis et IBM, de sorte que la copie immuable peut être ajoutée comme dépôt dans les outils qu’une équipe exploite déjà. Ses fonctions de sécurité et cyber-résilience traitent les détails de configuration, tels que la séparation des identités d’administration et l’authentification multifacteur, qui déterminent si l’immutabilité tient en pratique.
À retenir concrètement : satisfaire le « 1 » immuable en ajoutant un dépôt avec object lock activé à l’application de sauvegarde déjà en place, puis prouver le « 0 » en restaurant depuis ce dépôt selon un calendrier.