Une PME de 45 personnes dans la distribution subit un ransomware un vendredi soir. Le lundi matin, les sauvegardes réseau sont aussi chiffrées — l’attaquant les avait atteintes deux semaines plus tôt. La seule copie exploitable est une sauvegarde cloud immutable configurée trois mois auparavant. La restauration prend 14 heures. L’activité reprend le mardi matin. Sans cette copie immutable, le délai estimé de reconstruction depuis zéro était de six semaines.

Ce scénario illustre une réalité que les statistiques ANSSI confirment : le ransomware cible systématiquement les sauvegardes avant de déclencher le chiffrement visible. La question n’est plus seulement « avez-vous des sauvegardes ? » mais « vos sauvegardes survivront-elles à un attaquant qui a eu trois semaines pour les compromettre ? »

Ce guide couvre la construction d’une stratégie de sauvegarde conçue pour résister à cette réalité : règle 3-2-1-1-0, sauvegardes immutables, protection des données cloud, tests de restauration et protocole de décision en cas d’attaque active.

Pourquoi vos sauvegardes sont votre dernière ligne de défense

Les chiffres qui définissent le risque réel

Selon les données publiées par l’ANSSI sur cyber.gouv.fr, les PME et ETI représentent la majorité des victimes de ransomware en France. Le délai moyen de retour à une activité normale après un ransomware sans plan de reprise documenté est de 21 jours. Avec des sauvegardes immutables testées et un plan documenté, ce délai descend à 3 à 5 jours.

Vingt et un jours d’interruption représentent pour la plupart des PME une menace existentielle : perte de clients, rupture de contrats, trésorerie épuisée. Les entreprises qui survivent à un ransomware ne sont pas celles qui ont les meilleures protections préventives — ce sont celles dont les sauvegardes ont survécu à l’attaque.

Les attaquants ciblent les sauvegardes en premier

Les groupes ransomware modernes ont parfaitement intégré ce point. Leur méthode standard : compromission initiale via phishing ou exploitation de vulnérabilité, présence discrète sur le réseau pendant deux à six semaines, cartographie des systèmes de backup, compromission ou destruction des sauvegardes accessibles depuis le réseau, puis déclenchement du chiffrement visible.

Dans un ransomware sur deux, les sauvegardes réseau sont compromises avant le chiffrement principal. Une sauvegarde stockée sur un NAS accessible via les mêmes identifiants Active Directory que les serveurs de production sera chiffrée avec le reste. Ce n’est pas un cas exceptionnel — c’est la norme opératoire des groupes ransomware actifs en France.

La double extorsion : chiffrement et exfiltration

La grande majorité des ransomwares actuels combinent deux mécanismes de pression. Avant de chiffrer, l’attaquant exfiltre des données sensibles : bases clients, données comptables, contrats, données personnelles. Il menace de les publier ou de les revendre si la rançon n’est pas payée. Payer ou non la rançon ne supprime pas cette menace — la couverture préventive reste indispensable.

La règle 3-2-1-1-0 : le standard anti-ransomware

La règle 3-2-1 originale et ses limites

La règle 3-2-1 est le standard historique de l’industrie : 3 copies des données (la production plus deux sauvegardes), sur 2 supports différents (par exemple NAS local et stockage cloud), dont 1 copie hors site.

Cette règle a été conçue pour les scénarios de sinistre physique : incendie, vol, panne matérielle. Elle suppose que l’attaquant n’a pas accès aux systèmes de sauvegarde. Face aux ransomwares modernes qui restent plusieurs semaines sur le réseau avant d’agir, la copie hors site connectée via VPN avec les mêmes credentials Active Directory n’offre qu’une protection partielle.

L’extension 3-2-1-1-0

La version étendue ajoute deux exigences non négociables pour les entreprises exposées au ransomware :

Le quatrième « 1 » : une copie immutable ou air-gapped. Cette copie ne peut pas être modifiée ou supprimée pendant la période de rétention, même par un compte administrateur compromis. L’immutabilité est garantie au niveau du stockage, pas au niveau applicatif. Une copie air-gapped (physiquement déconnectée du réseau) offre une protection équivalente.

Le « 0 » : zéro erreur vérifiée. Toutes les copies ont été restaurées avec succès au moins une fois. Un backup dont la restauration n’a jamais été testée n’est pas un backup — c’est une hypothèse non validée. Le « 0 erreur » signifie que votre dernière restauration de test n’a produit aucune erreur non résolue.

Mise en œuvre pratique pour une PME

Architecture minimale recommandée pour la règle 3-2-1-1-0 :

Copie 1 : sauvegarde locale sur NAS ou serveur de backup dédié (restauration rapide en cas d’incident limité)
Copie 2 : réplication sur stockage objet cloud avec immutabilité activée (Wasabi, Backblaze B2, AWS S3 Object Lock) — c’est la copie immutable du quatrième « 1 »
Copie 3 : disque externe rotatif déposé hors site et échangé selon un planning hebdomadaire ou mensuel, ou second bucket cloud dans une région distincte avec des identifiants séparés

La copie cloud immutable est la protection la plus rentable contre le ransomware : elle est accessible rapidement pour la restauration, inatteignable pour un attaquant qui a compromis votre réseau, et son coût mensuel est marginal comparé au coût d’une interruption d’activité de 21 jours.

Les sauvegardes immutables : fonctionnement et solutions

Ce qu’est l’immutabilité au niveau stockage

L’immutabilité (ou WORM — Write Once, Read Many) est une propriété du stockage : une fois écrites, les données ne peuvent pas être modifiées ou supprimées avant l’expiration de la période de rétention configurée. Cette propriété est appliquée par le système de stockage lui-même, indépendamment des identifiants utilisés pour y accéder.

Le point critique : même un compte avec les droits administrateurs les plus élevés ne peut pas contourner l’immutabilité pendant la période active. L’attaquant qui a compromis votre compte admin ne peut pas effacer vos sauvegardes immutables — c’est là toute la différence avec un backup classique.

Solutions disponibles

Stockage objet cloud :

AWS S3 Object Lock — mode Compliance (irréversible, même par AWS) ou Governance (override possible par admin AWS). Disponible sur tous les buckets S3.
Wasabi Immutable Buckets — prix fixes sans frais de sortie de données, modèle économique prévisible particulièrement adapté aux PME.
Backblaze B2 Object Lock — tarification attractive, compatible avec l’API S3 standard.
Azure Blob Storage — politiques d’immuabilité configurables par conteneur, intégré dans l’écosystème Microsoft.

Infrastructure on-premise :

Veeam Hardened Repository — serveur Linux avec système de fichiers XFS, accès SSH désactivé après configuration, immutabilité native gérée par Veeam. Un serveur standard suffit.
Appliances WORM dédiées — solutions matérielles proposées par Dell EMC, ExaGrid ou Quantum, adaptées aux environnements avec de grands volumes de données.

Paramètres de configuration essentiels

Deux paramètres définissent la robustesse de votre protection :

La durée de rétention doit couvrir le délai de détection d’un ransomware. Un attaquant qui reste quatre semaines sur votre réseau avant d’agir contourne une rétention de 14 jours. Trente jours est un minimum ; 90 jours offre une couverture confortable pour la plupart des scénarios.

L’isolation des identifiants est aussi importante que l’immutabilité elle-même. Les credentials d’accès au bucket ou au repository immutable ne doivent jamais être présents sur les serveurs de production, dans l’Active Directory, ni dans un gestionnaire de secrets accessible depuis le réseau de production. Stockez-les dans un coffre-fort de mots de passe hors ligne ou dans un gestionnaire de secrets isolé.

Microsoft 365 et Google Workspace : la sauvegarde que vous n’avez pas

La confusion entre rétention et backup

Des milliers de PME croient que Microsoft 365 ou Google Workspace sauvegardent leurs données. Cette confusion est alimentée par la terminologie : « politiques de rétention », « corbeille », « versions précédentes ». Ces fonctionnalités existent pour des usages spécifiques — conformité légale, récupération accidentelle d’un fichier — mais elles ne constituent pas une sauvegarde au sens opérationnel du terme.

Microsoft l’écrit explicitement dans ses conditions de service : la responsabilité de la sauvegarde des données appartient au client. Google adopte la même position.

Ce que la rétention native ne couvre pas

Scénario ransomware via synchronisation client : un ransomware chiffre les fichiers locaux sur un poste Windows. Le client OneDrive ou Google Drive synchronise les fichiers chiffrés vers le cloud. Les versions antérieures existent, mais la fenêtre de restauration est limitée (30 à 180 jours selon les plans) et la restauration de milliers de fichiers est une opération manuelle longue et risquée à grande échelle.

Suppression par compte admin compromis : un attaquant ayant accès à un compte administrateur global peut supprimer des mailboxes, des sites SharePoint, des drives entiers. Certaines suppressions admin contournent les politiques de rétention standard ou nécessitent une intervention Microsoft dont le délai n’est pas garanti.

Expiration des politiques : les politiques de rétention ne sont pas permanentes par défaut. Un utilisateur parti il y a deux ans dont les emails n’étaient pas sous politique de rétention active n’a pas de backup exploitable.

Solutions tierces recommandées

Une solution de backup dédiée pour les environnements cloud collaboratifs est indispensable. Elle doit être configurée comme une source de données externe à l’environnement M365 ou Google Workspace, avec ses propres identifiants et sa propre politique d’immutabilité.

Pour Microsoft 365 : Veeam Backup for Microsoft 365 (couvre Exchange, SharePoint, OneDrive, Teams avec une restauration granulaire), Druva inSync, AvePoint Cloud Backup, Backupify by Kaseya.

Pour Google Workspace : Backupify, Spanning Backup (by Kaseya), Acronis Cyber Protect Cloud.

Ces solutions sauvegardent les données dans votre propre stockage ou dans leur infrastructure dédiée, indépendamment du tenant Microsoft ou Google. La restauration est granulaire (un email, une boîte entière, un site SharePoint) et peut se faire vers un état antérieur précis. Plusieurs solutions couvrent M365 et Google Workspace depuis une interface unique.

Tester vos restaurations : la différence entre un backup et une promesse

Pourquoi la plupart des tests de backup sont insuffisants

La vérification standard consiste à contrôler que les jobs de sauvegarde s’exécutent sans erreur dans la console du logiciel. Ce n’est pas un test de restauration. Un job qui se termine sans erreur peut produire une sauvegarde corrompue, incomplète, ou dont la restauration prend trois fois plus longtemps que prévu.

Un test de restauration réel est la seule façon de savoir si votre backup fonctionne. Et ce test doit se faire dans un environnement isolé, sans impacter la production.

Le protocole de test trimestriel

Préparation : sélectionnez le système à restaurer (faites tourner entre vos systèmes critiques au fil des trimestres), identifiez la sauvegarde de référence à utiliser, préparez l’environnement de test isolé.

Restauration : exécutez la restauration depuis la sauvegarde en chronométrant chaque étape. N’aidez pas le processus avec des raccourcis ou des manipulations manuelles — vous devez mesurer le temps réel en conditions comparables à celles d’un incident réel.

Validation : vérifiez que les données restaurées sont exploitables (l’application démarre, les données sont cohérentes, les transactions récentes sont présentes), comparez le temps de restauration mesuré au RTO théorique, identifiez les obstacles rencontrés.

Documentation : archivez la date, le système testé, la sauvegarde utilisée, le temps réel et les actions correctives. Cette documentation sert de preuve de conformité pour les assureurs cyber et les audits NIS2.

Les indicateurs à mesurer

RTO réel vs théorique : si votre RTO pour l’ERP est de 4 heures et que la restauration en prend 9, vous avez un écart critique à corriger avant le prochain incident réel. Le test trimestriel est précisément là pour révéler cet écart.

RPO réel vs théorique : vérifiez la date des dernières données présentes dans la restauration. Si votre RPO est de 4 heures et que la sauvegarde la plus récente date de 18 heures, la fréquence ou la fenêtre de backup pose problème.

Intégrité des données : certaines corruptions silencieuses n’apparaissent pas dans les logs mais dans les données restaurées. La vérification applicative est la seule validation fiable.

Votre PRA/PCA formalise les RTO et RPO de chaque système critique dans un document partagé avec la direction.

Quand le ransomware frappe : décisions et priorités

Faut-il payer la rançon ?

La position de l’ANSSI, publiée sur cyber.gouv.fr, est claire : le paiement est déconseillé. Les raisons sont factuelles :

Seulement 65 % des entreprises ayant payé récupèrent l’intégralité de leurs données
Le paiement finance les groupes criminels et leur capacité à mener de nouvelles attaques
Les entreprises qui paient sont inscrites sur des listes revendues : elles sont recontactées ou ciblées à nouveau dans les 12 mois suivants dans un cas sur trois
En France, signaler l’incident auprès des autorités compétentes dans les 72 heures est une condition pour certaines procédures d’indemnisation assureur

Des outils de déchiffrement gratuits existent pour certains variants sur nomoreransom.org — vérifiez systématiquement avant de prendre toute décision de paiement.

La décision de payer — si elle devait être envisagée — appartient à la direction générale, pas au responsable IT. Elle doit être documentée dans le plan de réponse avant tout incident : qui a l’autorité, quels critères la déclenchent, quelles alternatives ont été épuisées.

L’ordre de priorité dans la restauration

Un incident ransomware ne permet pas de tout restaurer simultanément. L’ordre de priorité doit être établi avant l’incident, basé sur les RTO et RPO de chaque système.

Phase 1 — Isolation et sécurisation : déconnecter les systèmes compromis du réseau, isoler les systèmes non touchés, sécuriser les sauvegardes encore intactes. Ne pas éteindre les systèmes compromis avant d’avoir réalisé une image forensique si possible.

Phase 2 — Infrastructure critique : restaurer les services sans lesquels rien d’autre ne fonctionne (Active Directory, DNS, services d’authentification).

Phase 3 — Systèmes critiques métier : ERP, système de gestion des commandes, outils de production — par ordre de RTO croissant.

Phase 4 — Systèmes importants : messagerie, outils collaboratifs, CRM.

Phase 5 — Systèmes non critiques : sites web, outils secondaires, archives.

Notre fiche réflexe cyberattaque et notre plan de réponse à incident détaillent les actions heure par heure pendant les premières 72 heures d’un incident actif.

Communication pendant la crise

La gestion de la communication est aussi critique que la restauration technique. Quatre audiences nécessitent un traitement distinct :

Interne : les collaborateurs ont besoin de consignes claires (quels systèmes ne pas utiliser, comment travailler en mode dégradé, quand auront-ils des nouvelles). L’absence de communication interne génère des comportements contre-productifs.

Clients et partenaires : selon l’impact sur vos services, une communication proactive est préférable à un silence suivi de questions inquiètes.

Autorités : notification CNIL sous 72 heures si des données personnelles sont exposées, notification ANSSI sous 24 heures pour les entités NIS2. Ces délais courent dès la prise de connaissance de l’incident, pas depuis sa résolution.

Assureur : la plupart des contrats cyber imposent un délai de déclaration court — souvent 72 heures. Consultez votre police avant tout incident. Notre page cyber-assurance détaille les exigences typiques des assureurs et les clauses à vérifier avant souscription.

Prévention : le phishing comme porte d’entrée principale

La statistique que tout plan de backup doit intégrer

Le vecteur d’entrée initial le plus fréquent des ransomwares reste le phishing : un email malveillant qui conduit un collaborateur à exécuter un fichier ou à saisir ses identifiants sur une page de login frauduleuse. L’attaquant obtient un premier accès, pivote vers les systèmes internes, et commence le travail de reconnaissance et de compromission des sauvegardes décrit plus haut.

Construire une stratégie de sauvegarde solide sans adresser le vecteur d’entrée, c’est renforcer les portes de secours sans verrouiller la porte principale. Les deux couches de protection sont nécessaires et complémentaires.

Réduire la probabilité que la crise se déclenche

Les simulations de phishing régulières testent en conditions réelles la capacité des collaborateurs à détecter un email malveillant avant d’interagir avec lui. Elles mesurent où en est l’organisation, identifient les profils les plus exposés, et permettent de cibler la sensibilisation là où elle produit le plus d’effet.

Le résultat sur le risque ransomware est direct : un collaborateur qui signale un email suspect plutôt que de cliquer sur la pièce jointe bloque l’attaque au stade initial, avant que l’attaquant n’ait eu le temps d’atteindre les sauvegardes.

Notre outil de test de sécurité email permet de vérifier en quelques minutes la robustesse de votre configuration SPF, DKIM et DMARC — une configuration solide réduit la surface d’attaque par usurpation de domaine. Les simulations de phishing de nophi.sh permettent de tester et former vos équipes de façon continue, avec des scénarios adaptés à votre secteur et à votre niveau de maturité actuel.

Sauvegarde solide + formation continue : la couche technique limite les dégâts si l’attaque réussit, la couche humaine réduit la probabilité qu’elle réussisse. Les deux sont indispensables — et les deux se renforcent mutuellement.

Questions fréquentes

Thomas Ferreira, CISSP, GCFA — Consultant en cybersécurité et continuité d’activité. Thomas accompagne des PME et ETI françaises dans la construction de stratégies de sauvegarde, l’architecture de plans de reprise et les exercices de simulation de crise. Ce guide s’appuie sur les recommandations ANSSI publiées sur cyber.gouv.fr, les bonnes pratiques Veeam et NIST SP 800-34, et les retours d’expérience d’interventions post-incident en entreprises françaises.

Pour compléter cette stratégie, consultez notre guide PRA/PCA pour PME pour la formalisation du plan de reprise, notre plan de réponse à incident pour la gestion de la crise active, et notre page glossaire ransomware pour les définitions techniques.