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.
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.
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.
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.
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.
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 :
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.
| 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é |
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.
Une interprétation viable comporte trois couches.
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.
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.
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.
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.
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é.
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.