Français
Sauvegarde & continuité · Belgique 2026
Une sauvegarde hors site n’est pas automatiquement à l’abri d’un rançongiciel. Si le même compte, la même console ou le même réseau permet de supprimer la production et ses copies, l’attaquant peut neutraliser la reprise. La règle 3-2-1-1-0 ajoute une copie hors ligne ou immuable et exige que la restauration soit vérifiée. Elle transforme un inventaire de copies en stratégie de récupération.
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 Centre pour la Cybersécurité Belgique 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.
| Critère | Stockage objet WORM | Dépôt durci local ou distant | Support hors ligne |
|---|---|---|---|
| Principe | Versions d’objets verrouillées pendant une durée. | Système de fichiers et privilèges conçus pour empêcher la modification des chaînes. | Média déconnecté ou physiquement isolé après écriture. |
| Avantages | Hors site, scalable, politiques de rétention et journaux. | Restauration rapide, contrôle de l’infrastructure, intégration aux jobs. | Très forte séparation réseau lorsqu’il est réellement retiré. |
| Limites | Droits cloud, mode de verrouillage, frais de sortie et capacité à maîtriser. | Durcissement, correctifs, accès physique et console restent à gouverner. | Manipulations, rotation, stockage physique et délai de récupération. |
| Cas d’usage | Copie secondaire hors site pour serveurs, SaaS ou données non structurées. | Restauration opérationnelle rapide de VM et serveurs. | Dernière copie de secours ou conservation de certains jeux critiques. |
| Coût | Dépend du volume, de la rétention, des requêtes et de la récupération. | Dépend du matériel, de l’exploitation, du site et de la capacité. | Dépend des médias, du transport, du coffre et des opérations. |
| Meilleur choix selon le besoin | Organisation voulant une copie hors site automatisée et verrouillée. | Organisation ayant besoin d’un RTO court et de compétences d’exploitation. | Organisation recherchant une séparation forte et acceptant plus de manipulation. |
La règle est une chaîne : une seule dépendance administrative commune peut affaiblir plusieurs chiffres. Illustration GVISION.
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.
- Cartographier les services, données, identités, clés et fournisseurs nécessaires à la reprise.
- Attribuer un propriétaire métier, un RPO et un RTO réalistes à chaque service critique.
- Dessiner les copies existantes et marquer leurs comptes, réseaux, sites et plateformes.
- Identifier les points de défaillance communs : domaine, console, coffre, fournisseur ou administrateur.
- Choisir la copie hors ligne ou immuable selon le risque, les volumes, le délai de restauration et les compétences.
- Définir la rétention, les exceptions, l’expiration et la capacité avant de verrouiller une politique.
- Séparer les privilèges, activer MFA lorsque disponible et protéger les comptes d’urgence.
- Tester d’abord un périmètre pilote, puis restaurer un service complet dans un environnement isolé.
- 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.
- Confondre snapshot, réplication, synchronisation ou corbeille avec une sauvegarde indépendante.
- Joindre le dépôt de sauvegarde au même domaine et réutiliser des comptes d’administration quotidiens.
- Appeler « hors site » un stockage que le même compte cloud peut supprimer.
- Activer une politique WORM sans test, estimation de capacité ni procédure d’expiration.
- Conserver les données trop peu de temps pour survivre à une compromission silencieuse.
- Conserver toutes les données indéfiniment au nom du RGPD ou de NIS2.
- Tester seulement un fichier alors que la reprise dépend d’une application complète.
- Mesurer le temps de copie mais pas le délai réel de récupération et de validation.
- Oublier les clés, licences, configurations réseau, comptes SaaS et contacts fournisseurs.
Questions fréquentes
Une sauvegarde immuable peut-elle être chiffrée par un ransomware ?
Une version correctement verrouillée ne devrait pas pouvoir être modifiée ou supprimée pendant sa rétention par les identités couvertes par le contrôle. Mais l’attaquant peut chiffrer la production avant la sauvegarde, voler des données ou viser les clés et catalogues. L’isolation, la détection et les tests restent nécessaires.
Un NAS avec snapshots suffit-il ?
Les snapshots accélèrent souvent la récupération locale, mais ils partagent l’équipement, l’administration et parfois les identités du NAS. Ils constituent une couche utile, pas forcément la copie hors site et immuable exigée par un scénario de ransomware ou de sinistre physique.
Object Lock et air gap sont-ils identiques ?
Non. Object Lock empêche certaines modifications et suppressions selon le mode et la durée. Un air gap vise l’inaccessibilité depuis l’environnement courant, physiquement ou logiquement. Une copie peut être immuable sans être hors ligne, et hors ligne sans bénéficier d’un verrouillage WORM.
Quelle durée d’immutabilité choisir ?
Il n’existe pas de valeur universelle. Prenez en compte le délai de détection d’une compromission, les points de restauration requis, le RPO, les obligations de conservation, le volume et la capacité. Testez la politique avant de la verrouiller et prévoyez son expiration.
Le 3-2-1-1-0 est-il obligatoire sous NIS2 ?
La formule elle-même n’est pas une obligation légale générale. NIS2 et les règles applicables demandent des mesures proportionnées, notamment en continuité et reprise. Le 3-2-1-1-0 est un moyen pratique de structurer la résilience, à adapter au champ d’application réel.
À quelle fréquence tester une restauration ?
Définissez une fréquence selon la criticité et ajoutez des tests après une migration, un changement de plateforme, une modification de rétention ou un incident. Les contrôles automatisés peuvent être fréquents ; un exercice fonctionnel complet peut suivre une cadence distincte et documentée.
Faut-il rendre toutes les sauvegardes immuables ?
Priorisez les services critiques et les points nécessaires à la reprise. Une politique uniforme peut gaspiller de la capacité ou bloquer l’effacement de données inutiles. Le périmètre et la rétention doivent être décidés par risque, puis élargis après validation.
Passez d’une copie disponible à une reprise démontrable
GVISION peut cartographier vos charges de travail, séparer les domaines d’administration, mettre en place une copie locale et une copie immuable hors site, puis organiser des restaurations mesurées. Pour confronter votre architecture actuelle à un scénario réaliste sans promesse absolue, discutez de votre continuité informatique avec GVISION.