Sauvegarde immuable en Belgique : passer de 3-2-1 à 3-2-1-1-0

Qu’est-ce qu’une sauvegarde immuable ?

Une sauvegarde immuable est une copie qui ne peut pas être modifiée ni supprimée pendant une période définie, y compris lorsque des comptes d’administration ordinaires sont compromis.

L’immutabilité est généralement mise en œuvre par un mécanisme WORM — Write Once, Read Many —, un verrouillage d’objets, un système de fichiers durci ou un support physiquement hors ligne. La protection doit porter sur les points de restauration et sur les métadonnées nécessaires pour les retrouver. Un fichier déclaré « lecture seule » dans Windows n’offre pas ce niveau : un administrateur peut souvent changer les droits ou supprimer le volume.

Le Centrum voor Cybersecurity België (CCB) a actualisé ses recommandations le 14 janvier 2026. Il insiste sur une immutabilité conçue dès le départ, une protection en couches, l’isolation des environnements, des rétentions suffisamment longues et des restaurations exercées. Ce sont des principes de résilience, pas la validation d’un produit précis.

Pourquoi un attaquant cherche d’abord les sauvegardes

Un rançongiciel mature réduit la capacité de négociation de la victime en supprimant ou désactivant les chemins de restauration avant de chiffrer les systèmes.

Le rapport technique du CCB sur Qilin, publié le 17 juillet 2026, décrit notamment la suppression de Volume Shadow Copies, la désactivation de points de restauration et la suppression de sauvegardes sur bande ou de tâches planifiées. L’exemple montre pourquoi un voyant vert dans la console n’est pas une preuve suffisante : la même console peut devenir une cible.

Les chemins d’attaque les plus simples sont souvent administratifs. Un compte de domaine utilisé sur le serveur de sauvegarde, un secret conservé dans le même coffre que la production, un NAS joint au domaine ou un bucket accessible par la même identité cloud créent une dépendance commune. L’attaquant n’a pas besoin de casser l’algorithme de sauvegarde ; il lui suffit d’obtenir l’autorisation de suppression.

Comment lire 3-2-1-1-0 sans en faire un slogan

La règle 3-2-1-1-0 est un aide-mémoire de conception : elle ne constitue ni une loi belge, ni une certification, ni une garantie de récupération.

Le premier « 3 » compte les données de production et au moins deux copies. Le « 2 » impose de la diversité : deux supports ou plateformes dont les modes de panne ne sont pas identiques. Le premier « 1 » place une copie hors du site principal. Le second « 1 » demande une copie hors ligne, réellement isolée ou immuable. Le « 0 » signifie que les contrôles d’intégrité et les essais de restauration ne révèlent aucune erreur non résolue.

Veeam a popularisé cette extension de la règle 3-2-1 et explique le rôle du second 1 et du 0 dans sa documentation sur le 3-2-1-1-0. Le principe reste applicable sans utiliser Veeam. Une organisation peut combiner un dépôt local, un stockage objet avec verrouillage et un support hors ligne, à condition de documenter les dépendances et les preuves.

Que faut-il protéger dans une organisation hybride ?

Le périmètre doit suivre les services métiers et leurs dépendances, pas seulement la liste des serveurs visibles dans l’outil de sauvegarde.

Commencez par les dossiers et applications indispensables : ERP, logiciel métier, fichiers partagés, bases de données, machines virtuelles, configurations réseau, postes spécialisés et données SaaS. Pour Microsoft 365, distinguez Exchange, OneDrive, SharePoint, Teams et les identités nécessaires pour administrer la restauration. Pour un NAS, identifiez les partages, snapshots, applications internes et clés de chiffrement.

Chaque charge de travail reçoit un propriétaire, une criticité, un RPO — quantité maximale de données que l’activité accepte de perdre — et un RTO — délai cible de remise en service. Une boîte partagée peut tolérer plusieurs heures de perte ; une base de production peut demander un objectif plus serré. Ces valeurs doivent venir de l’activité et non d’un réglage par défaut du logiciel.

La page GVISION consacrée aux sauvegardes cloud et locales présente les briques de protection disponibles. Le présent guide ajoute l’angle d’architecture immuable : il aide à décider comment séparer les copies et comment prouver qu’elles restent récupérables.

Dépôt durci, stockage objet ou support hors ligne : que choisir ?

Aucune méthode n’est supérieure dans tous les cas : le bon choix équilibre résistance à la suppression, vitesse de restauration, exploitation et risque de mauvaise configuration.

Une architecture réaliste pour serveur, NAS, postes et Microsoft 365

Une architecture praticable combine une restauration locale rapide avec une copie secondaire isolée et une procédure de récupération indépendante.

Pour des serveurs ou machines virtuelles, le dépôt local réduit le temps de transfert lors d’une restauration courante. Une tâche de copie envoie ensuite les points de restauration vers un dépôt durci ou un stockage objet immuable hors site. Le serveur de production ne devrait pas disposer des droits permettant d’effacer cette seconde copie. Les comptes de sauvegarde ne servent pas aux opérations quotidiennes.

Pour un NAS, les snapshots locaux peuvent accélérer le retour après une suppression, mais ils restent attachés au même équipement. Ajoutez une copie vers une plateforme distincte, avec identités et rétention séparées. Pour les postes nomades, priorisez les données réellement locales et vérifiez que la machine peut terminer la sauvegarde malgré les périodes hors réseau.

Rétention, privilèges et clés : les décisions irréversibles

La durée d’immutabilité doit être suffisamment longue pour dépasser le délai plausible de détection, sans verrouiller inutilement des données au-delà du besoin.

Une attaque peut rester silencieuse avant le chiffrement. Si la rétention immuable est plus courte que ce délai, les derniers points sains peuvent expirer. À l’inverse, une conservation excessive augmente la capacité consommée, le coût de transfert futur et l’exposition de données personnelles devenues inutiles. Alignez fenêtres opérationnelles, obligations de conservation et politique d’effacement.

Dans Amazon S3, Object Lock distingue les modes Governance et Compliance. Le mode Governance peut être contourné par des identités dotées d’une permission spéciale ; en mode Compliance, une version protégée ne peut pas être écrasée ou supprimée, même par l’utilisateur racine, avant l’échéance. Ce niveau exige un cadrage et un test prudents.

Azure Blob propose des politiques WORM basées sur le temps et des legal holds. La documentation Microsoft distingue aussi les politiques verrouillées et non verrouillées et recommande de tester avant le verrouillage. Conservez les clés, comptes d’urgence et procédures dans un emplacement séparé, avec accès contrôlé et vérifié.

Comment prouver qu’une restauration fonctionnera

Le zéro de 3-2-1-1-0 n’est pas l’absence d’alerte dans la nuit : c’est une récupération vérifiée, documentée et compatible avec l’objectif métier.

Un contrôle d’intégrité vérifie qu’un fichier de sauvegarde n’est pas corrompu. Un démarrage automatisé vérifie qu’une machine boote. Un test fonctionnel confirme que l’application, la base, les droits et les dépendances permettent réellement de travailler. Ces niveaux sont différents. Pour une application critique, l’exercice doit aller jusqu’à une transaction ou un scénario utilisateur représentatif.

Restaurez dans un environnement isolé pour éviter de réintroduire un logiciel malveillant ou de créer un conflit avec la production. Mesurez le temps depuis la décision de restaurer jusqu’à la disponibilité du service. Notez les étapes manuelles, les identifiants manquants, la bande passante, les erreurs et le temps de validation métier. Comparez le résultat au RTO et le point restauré au RPO.

Le plan de reprise d’activité informatique relie ces tests à l’ordre de redémarrage, aux rôles, aux communications et aux dépendances. Une restauration de données réussie ne suffit pas si le DNS, l’identité, le réseau, une licence ou un fournisseur critique reste indisponible.

Quatre scénarios belges, quatre priorités différentes

La taille de l’organisation compte moins que l’impact d’une interruption, la sensibilité des données et la complexité des dépendances.

Une ASBL ou une école peut dépendre de Microsoft 365, d’un logiciel d’inscription et de quelques postes administratifs. Le plan doit couvrir les comptes, les documents partagés et la reprise pendant une période d’inscription ou d’examens. Une copie immuable gérée peut être plus réaliste qu’une infrastructure complexe sans responsable dédié.

Un cabinet ou un établissement de santé doit distinguer disponibilité clinique, confidentialité et conservation. L’immutabilité réduit le risque de suppression, mais ne justifie pas de garder chaque donnée indéfiniment. Les droits d’accès, le chiffrement, la traçabilité et la procédure de restauration doivent être proportionnés à la sensibilité.

NIS2, RGPD et preuves : ce que l’immutabilité ne prouve pas

Une sauvegarde immuable soutient la résilience et la sécurité du traitement, mais elle ne démontre à elle seule ni la conformité NIS2, ni la conformité RGPD.

Le règlement d’exécution européen 2024/2690, applicable à certaines catégories d’entités numériques visées par NIS2, demande des plans de continuité et de reprise testés, revus et mis à jour à intervalles planifiés. Le texte EUR-Lex doit être lu selon le champ d’application de l’organisation. D’autres entités belges peuvent relever de la loi NIS2 et de mesures proportionnées différentes.

Pour le RGPD, la disponibilité et la capacité de rétablir l’accès font partie de la sécurité, mais la minimisation et les durées de conservation restent importantes. Une politique immuable mal définie peut empêcher l’effacement technique pendant sa fenêtre. Documentez cette limite, la base de conservation et la suppression à l’expiration, au lieu de présenter WORM comme une conformité automatique.

Plan de mise en œuvre en neuf étapes

Le chemin le plus sûr commence par les services critiques, puis ajoute l’immutabilité à une architecture déjà compréhensible et testable.

Commencez par une charge de travail représentative mais réversible. Un pilote révèle les limites de bande passante, les fenêtres de copie, les effets de versioning et les droits nécessaires. Ne verrouillez pas immédiatement une longue conservation sur tout le stockage : une politique WORM peut volontairement rendre la suppression impossible.

1. Cartographier les services, données, identités, clés et fournisseurs nécessaires à la reprise.
2. Attribuer un propriétaire métier, un RPO et un RTO réalistes à chaque service critique.
3. Dessiner les copies existantes et marquer leurs comptes, réseaux, sites et plateformes.
4. Identifier les points de défaillance communs : domaine, console, coffre, fournisseur ou administrateur.
5. Choisir la copie hors ligne ou immuable selon le risque, les volumes, le délai de restauration et les compétences.
6. Définir la rétention, les exceptions, l’expiration et la capacité avant de verrouiller une politique.
7. Séparer les privilèges, activer MFA lorsque disponible et protéger les comptes d’urgence.
8. Tester d’abord un périmètre pilote, puis restaurer un service complet dans un environnement isolé.
9. Planifier les tests récurrents, traiter chaque écart et mettre à jour le PRA après les changements.

Les erreurs fréquentes à éviter

Les erreurs les plus dangereuses donnent une impression de sécurité tout en conservant un point de défaillance commun.

Une autre erreur consiste à acheter d’abord la technologie puis à chercher ce qu’elle doit protéger. La décision doit partir d’un scénario de perte et d’un délai acceptable. Le meilleur dépôt immuable ne compense pas une base de données absente du périmètre ou une procédure connue d’une seule personne.

1. Confondre snapshot, réplication, synchronisation ou corbeille avec une sauvegarde indépendante.
2. Joindre le dépôt de sauvegarde au même domaine et réutiliser des comptes d’administration quotidiens.
3. Appeler « hors site » un stockage que le même compte cloud peut supprimer.
4. Activer une politique WORM sans test, estimation de capacité ni procédure d’expiration.
5. Conserver les données trop peu de temps pour survivre à une compromission silencieuse.
6. Conserver toutes les données indéfiniment au nom du RGPD ou de NIS2.
7. Tester seulement un fichier alors que la reprise dépend d’une application complète.
8. Mesurer le temps de copie mais pas le délai réel de récupération et de validation.
9. Oublier les clés, licences, configurations réseau, comptes SaaS et contacts fournisseurs.