27 septembre 2026Sécurité

Sauvegardes immuables : règle 3-2-1-1-0 appliquée à une PME romande

Un ransomware chiffre l'ensemble des partages réseau d'une fiduciaire vaudoise en moins de 40 minutes : sans copie immuable hors ligne, la règle 3-2-1 classique ne suffit pas. Voici comment implémenter la variante 3-2-1-1-0 dans un contexte PME suisse, conformité nLPD incluse.

Par ZRS-Holding Sàrl·11 min de lecture·7 lectures
Partager

Un vendredi soir qui change tout

Il est 18h47 quand le SOC d'un cabinet fiduciaire lausannois reçoit la première alerte : l'extension .locked se propage sur le serveur de fichiers. En 38 minutes, 4 To de dossiers clients sont chiffrés. Les deux copies de sauvegarde sur NAS local ? Chiffrées également, montées en lecteur réseau. La copie cloud ? Synchronisée à la baisse par le client de sauvegarde avant que quiconque ne coupe la connexion. Résultat : zéro donnée récupérable, notification obligatoire au Préposé fédéral à la protection des données et à la transparence (PFPDT) sous 72 heures dès que des données personnelles de clients sont concernées, et une facture de reconstruction dépassant CHF 180 000.

Ce scénario n'est pas hypothétique : il illustre l'échec systématique de la règle 3-2-1 classique face aux ransomwares modernes qui ciblent explicitement les sauvegardes accessibles. La variante 3-2-1-1-0 corrige ces angles morts. Sa mise en œuvre dans une PME romande de 20 à 150 employés est l'objet de cet article.

Anatomie de la règle 3-2-1-1-0

La règle originale 3-2-1, popularisée dans les années 2000, stipule : 3 copies des données, sur 2 supports différents, dont 1 hors site. Elle reste une base saine, mais elle ne prend pas en compte deux vecteurs d'attaque contemporains : le chiffrement latéral via comptes à privilèges et la compromission du fournisseur cloud de sauvegarde.

Les deux chiffres ajoutés

  • +1 : une copie immuable (air-gapped ou WORM) — un medium que ni l'attaquant, ni un administrateur compromis, ni même un script automatisé ne peut modifier ou supprimer pendant la période de rétention définie. Cela couvre les bandes LTO en bibliothèque physique, les objets S3 avec Object Lock (mode Compliance), ou un NAS avec protocole WORM activé et réseau isolé.
  • +0 : zéro erreur vérifiée au dernier test de restauration — une sauvegarde dont l'intégrité n'a jamais été testée n'existe pas opérationnellement. Ce dernier chiffre force une discipline de test automatisé et documenté.

Ce que signifie "immuable" techniquement

L'immuabilité n'est pas la même chose que le chiffrement de la sauvegarde (utile, mais insuffisant) ni qu'un simple contrôle d'accès (contournable par un compte root ou Domain Admin compromis). Une copie est véritablement immuable quand :

  • Le mécanisme de verrouillage est appliqué au niveau du stockage (firmware, Object Lock S3, WORM tape) et non au niveau applicatif.
  • Aucune API, aucun compte, y compris root ou S3 root account, ne peut supprimer les objets avant expiration de la rétention (mode Compliance chez les principaux fournisseurs, par opposition au mode Governance qui reste révocable par un super-admin).
  • La durée de verrouillage est au minimum égale à la fenêtre de détection attendue de votre organisation — pour une PME sans SOC dédié, 30 jours est un minimum raisonnable ; 90 jours est conseillé si vous traitez des données sensibles au sens de la nouvelle Loi fédérale sur la protection des données (nLPD).

Cadre légal suisse : nLPD et obligation de disponibilité

Depuis le 01.09.2023, la nLPD impose aux responsables du traitement de garantir la sécurité des données personnelles par des mesures techniques et organisationnelles appropriées (art. 8 nLPD). L'ordonnance sur la protection des données (OPDo) précise que ces mesures doivent assurer notamment la disponibilité et la restaurabilité des données. Concrètement :

  • Une PME qui perd des données personnelles suite à un ransomware et ne peut pas les restaurer subit une violation de données au sens de l'art. 24 nLPD.
  • La notification au PFPDT est obligatoire dès que possible (le délai de 72 heures est la référence pratique, alignée sur le RGPD pour les entités ayant des clients européens).
  • L'absence de sauvegarde testée et récupérable peut être retenue comme faute dans l'appréciation de la proportionnalité des mesures de sécurité.

Pour les secteurs régulés (banques, assurances), la FINMA impose des exigences supplémentaires via la circulaire FINMA 2023/1 sur les risques opérationnels : les établissements assujettis doivent démontrer un RTO (Recovery Time Objective) et un RPO (Recovery Point Objective) documentés, testés et auditables. Pour une petite banque privée genevoise de 80 collaborateurs, un RPO supérieur à 4 heures est généralement inacceptable au regard de cette circulaire.

Signalement au NCSC

Parallèlement à la notification au PFPDT pour les violations de données personnelles, le Centre national pour la cybersécurité (NCSC) encourage les entreprises à signaler les cyberattaques. Ce signalement est distinct de la notification légale PFPDT : il est volontaire (sauf secteurs critiques), mais il permet d'obtenir un appui opérationnel et contribue à la vision nationale des menaces. Depuis le 01.01.2025, certains opérateurs d'infrastructures critiques ont une obligation de déclaration au NCSC sous 24 heures.

Architecture technique pour une PME romande de 50 endpoints

Inventaire des données à protéger en priorité

Avant de dimensionner quoi que ce soit, classifiez. Pour un bureau d'études vaudois de 50 ingénieurs, les données critiques sont typiquement :

  • Plans CAD et livrables projets (volume souvent entre 2 et 8 To, croissance ~20 % par an).
  • Données RH et salariales (données sensibles au sens de l'art. 5 let. c nLPD).
  • Correspondance clients avec coordonnées, devis, contrats (données personnelles ordinaires).
  • Configurations ERP/CRM et bases de données associées.

Chaque catégorie mérite un RPO et un RTO distincts. Les plans CAD peuvent tolérer un RPO de 24 heures ; les données de paie en fin de mois, jamais.

Topologie 3-2-1-1-0 pour une PME de 50 postes

  1. Copie 1 — Snapshot local rapide : snapshots toutes les 4 heures sur le NAS de production (ZFS ou BTRFS). Accessible en lecture seule via le serveur de fichiers. RPO cible : 4 heures. Ce n'est pas une sauvegarde au sens strict, c'est un filet de sécurité pour les suppressions accidentelles.
  2. Copie 2 — Sauvegarde sur NAS secondaire isolé : backup quotidien (incrémental, rétention 14 jours) sur un NAS en DMZ interne, connecté uniquement via un port TCP dédié en push depuis le serveur de sauvegarde, sans accès SMB/CIFS exposé au LAN. Le compte de sauvegarde n'a pas de session RDP ou SSH permanente.
  3. Copie 3 — Réplication cloud chiffrée : réplication nightly vers un bucket S3 (ou équivalent) chez un fournisseur disposant d'un datacenter en Suisse ou en UE (contrainte nLPD pour les données personnelles si vous n'avez pas de BCR ou de clauses contractuelles types). Chiffrement côté client avec clé gérée par vous (AES-256, clé stockée séparément du bucket).
  4. +1 — Copie immuable : le même bucket S3 avec Object Lock en mode Compliance, rétention 90 jours. Alternativement, une bande LTO-8 mensuelle en coffre physique externe (prestataire de stockage documentaire ou coffre bancaire). Le coût d'une cartouche LTO-8 de 12 To (natif) est d'environ CHF 25-35 ; une bibliothèque d'entrée de gamme coûte entre CHF 3 000 et CHF 8 000.
  5. +0 — Test de restauration documenté : restauration complète testée trimestriellement, restauration partielle (10 fichiers aléatoires) testée mensuellement. Résultats consignés dans le registre des incidents et activités de traitement.

Isolation réseau : le point souvent négligé

Un NAS de sauvegarde accessible sur le même VLAN que les postes de travail sera chiffré par un ransomware qui a obtenu des droits Domain Admin. Les règles minimales :

  • VLAN dédié pour les serveurs de sauvegarde, filtrage L3 strict (autoriser uniquement les flux TCP nécessaires : port 9392 pour Veeam, 10082 pour Bacula, selon votre solution).
  • Authentification MFA sur le portail d'administration de la solution de sauvegarde.
  • Compte de service de sauvegarde sans droits d'ouverture de session interactif (Deny log on locally et Deny log on through Remote Desktop Services via GPO).
  • Alertes sur toute modification des tâches de sauvegarde ou des politiques de rétention (SIEM ou simple règle d'alerte email).

Cas pratique : Fiduciaire romande, 35 collaborateurs, Fribourg

Contexte

Cabinet fiduciaire bilingue à Fribourg, 35 collaborateurs, 1 200 dossiers clients actifs, environ 800 Go de données structurées (ERP Abacus + fichiers clients), 120 Go de données RH. Infrastructure : serveur Windows Server 2022, 28 postes Windows 11 23H2, 7 MacBook Pro sous macOS 14, NAS Synology DS1823xs+ en production. Aucun IT interne à plein temps : un responsable informatique à 30 % et un prestataire MSP pour les interventions.

État initial (avant projet)

  • Sauvegarde quotidienne sur NAS secondaire dans la même salle serveur : 3-1-0 de fait (pas de copie hors site, pas de test documenté).
  • Aucune copie immuable. Comptes de sauvegarde avec droits Admin de domaine par héritage historique.
  • Dernier test de restauration : impossible à dater (aucune trace écrite).

Procédure de mise en conformité 3-2-1-1-0 (conduite sur 6 semaines)

  1. Semaine 1 — Cartographie et classification (DSI 30 % + MSP) : inventaire des volumes de données, classification par sensibilité (données personnelles ordinaires, données sensibles RH, données publiques), définition des RPO/RTO par catégorie. Résultat : RPO ≤ 4h pour l'ERP, RPO ≤ 24h pour les fichiers clients, RPO ≤ 1h pour la base Abacus (critique en période de clôture).
  2. Semaine 2 — Isolation réseau (MSP + responsable IT) : création d'un VLAN backup (VLAN 40) sur le switch managé existant, règles pare-feu L3 pour n'autoriser que les flux de réplication entrants depuis le serveur de sauvegarde. Suppression des droits Admin de domaine du compte de service de sauvegarde ; création d'un compte dédié avec droits minimaux sur les partages cibles uniquement.
  3. Semaine 3 — Déploiement de la copie cloud + immuabilité (MSP) : ouverture d'un compte chez un fournisseur IaaS avec datacenter en Suisse, création d'un bucket S3-compatible avec Object Lock activé en mode Compliance, rétention 90 jours. Chiffrement client AES-256 avec clé stockée dans un gestionnaire de secrets offline (KeePass chiffré sur clé USB dans le coffre du cabinet). Coût estimé : CHF 40-60/mois pour 1 To compressé.
  4. Semaine 4 — Sauvegarde hors site physique (responsable IT) : achat de 4 cartouches LTO-8 (rotation mensuelle), négociation avec un prestataire de stockage documentaire fribourgeois pour le stockage externe (CHF 30/mois). Procédure d'échange de cartouche documentée, avec fiche de traçabilité signée.
  5. Semaine 5 — Premier test de restauration complet (DSI + MSP + expert comptable pilote) : restauration de la base Abacus complète sur un environnement de test isolé. Durée mesurée : 2h14. RPO effectif constaté : 3h52 (inférieur à l'objectif de 4h). Rapport de test archivé dans le registre des activités de traitement (obligation art. 12 nLPD).
  6. Semaine 6 — Procédure de réponse à incident et formation (DSI + juriste externe) : rédaction du playbook ransomware (isolation, identification, notification PFPDT, contact NCSC, restauration), formation de 2h pour les 3 personnes clés. Le playbook intègre les délais légaux : notification PFPDT dès que possible, NCSC en parallèle.

Coût total du projet

  • Matériel (cartouches LTO + câbles) : CHF 480
  • Stockage externe prestataire (annuel) : CHF 360
  • Cloud immuable (annuel, 1 To) : CHF 600
  • Heures MSP (60h à CHF 180/h) : CHF 10 800
  • Heures responsable IT interne (30h à 30 %) : coût marginal ~CHF 2 500
  • Total première année : ~CHF 14 740, récurrent ~CHF 4 000/an.

À comparer aux CHF 180 000 de reconstruction évoqués en introduction — sans compter les sanctions administratives potentielles du PFPDT ou la perte de clients.

Récapitulatif opérationnel

SynGuard accompagne des PME romandes dans la mise en place de politiques de sauvegarde conformes et testables, intégrées à la gestion des endpoints. Voici les actions concrètes à engager :

  1. Classifiez vos données avant de configurer quoi que ce soit : RPO et RTO différenciés par catégorie de données, documentés et signés par la direction.
  2. Isolez le réseau de sauvegarde : VLAN dédié, flux TCP whitlistés, comptes de service sans droits interactifs, MFA sur le portail d'administration.
  3. Activez l'immuabilité en mode Compliance (pas Governance) sur votre stockage cloud, avec une rétention minimum de 30 jours (90 jours recommandés pour les données sensibles nLPD).
  4. Ajoutez une copie physique hors site : bande LTO ou disque chiffré en rotation mensuelle chez un tiers physique. L'air-gap physique reste le seul moyen de résister à une compromission totale du fournisseur cloud.
  5. Chiffrez les sauvegardes côté client, clé stockée séparément des données et des accès cloud.
  6. Testez la restauration complète au moins une fois par trimestre, partielle (fichiers aléatoires) chaque mois. Documentez les résultats avec durée de restauration et RPO effectif constaté.
  7. Rédigez et testez un playbook ransomware : étapes d'isolation, décision de notification PFPDT, contact NCSC, procédure de restauration ordonnée. Testez-le au moins une fois par an (exercice tabletop).
  8. Vérifiez la localisation géographique de votre stockage cloud au regard des exigences nLPD sur les transferts transfrontaliers de données personnelles.
  9. Auditez les droits du compte de service de sauvegarde : il ne doit avoir accès qu'aux partages sources, aucun droit Admin de domaine, aucune session interactive.
  10. Intégrez la politique de sauvegarde dans votre registre des activités de traitement (art. 12 OPDo) avec date de dernière vérification et responsable nommé.

Sources

Noter cet article

Pas encore de note