Avant de choisir un outil de sauvegarde ou une option d’immutabilité, il faut traduire le risque en contraintes métier. Deux notions structurent tout le reste :

• RPO (Recovery Point Objective) : la perte de données maximale acceptable. Il répond à la question « jusqu’à quand peut-on perdre ? ».
• RTO (Recovery Time Objective) : le temps maximal acceptable d’interruption. Il répond à « en combien de temps doit-on redémarrer ? ».

Partir des processus, pas des serveurs

Listez les processus critiques (facturation, production, logistique, relation client, paie) et associez-y les applications et dépendances : annuaire, DNS, messagerie, ERP, fichiers, hyperviseur, VPN, accès internet. Une application peut sembler secondaire, mais être indispensable à l’authentification ou aux flux.

Classer les données et définir des priorités de restauration

Définissez des tiers (critique, important, support) avec pour chacun :

• le RPO visé (ex. sauvegardes plus fréquentes, journaux, snapshots)
• le RTO visé (ex. restauration plus rapide, architecture de reprise)
• le propriétaire métier (qui valide que « ça marche »)

Vérifier la faisabilité opérationnelle

Un RTO agressif implique des choix : stockage performant pour les dépôts, réseau dimensionné, procédures industrialisées, automatisation, et surtout tests. Sans tests, un RTO reste un souhait. Enfin, notez les contraintes de conformité (conservation, confidentialité) et les risques connexes (effacement volontaire, erreur humaine), car la stratégie anti-ransomware couvre aussi ces scénarios.

La règle 3-2-1 (trois copies, sur deux supports différents, dont une hors site) reste une base utile, mais elle ne suffit plus face à des attaquants capables d’obtenir des droits administrateur et de supprimer ou chiffrer les sauvegardes. 3-2-1-1-0 renforce cette approche.

Décomposer la règle 3-2-1-1-0

• 3 copies : production + au moins deux copies de sauvegarde.
• 2 supports différents : par exemple stockage disque + objet cloud, ou deux technologies distinctes pour réduire le risque de défaillance commune.
• 1 copie hors site : pour résister à un sinistre local et limiter l’impact d’un sabotage sur site.
• 1 copie hors ligne ou immuable : pour empêcher la modification/suppression par un compte compromis.
• 0 erreur : objectif d’intégrité via vérifications, monitoring et tests de restauration (et pas seulement « le job est vert »).

Ce que 3-2-1 ne couvre pas bien

3-2-1 peut échouer si :

• les sauvegardes sont accessibles avec les mêmes identifiants que la production
• la console de sauvegarde est dans le même domaine et subit le même ransomware
• la rétention est faible et l’on restaure des données déjà chiffrées
• les sauvegardes ne sont jamais restaurées en conditions réelles

Cartographier vos copies

Pour chaque périmètre (VM, fichiers, bases, M365), décrivez explicitement :

• où est la copie (site, cloud, coffre)
• qui peut la supprimer
• combien de temps elle est conservée
• comment on prouve son intégrité

Cette cartographie met souvent en évidence une illusion de sécurité : beaucoup de « copies », mais aucune survivante face à un attaquant avec des droits élevés.

Les termes se ressemblent, mais les mécanismes et les risques ne sont pas les mêmes. L’objectif commun : empêcher qu’un attaquant (ou une erreur) puisse altérer vos sauvegardes.

Immutabilité

Une sauvegarde immuable ne peut pas être modifiée ou supprimée pendant une période définie. Elle est souvent implémentée via :

• du stockage objet avec verrouillage (politiques de rétention)
• des dépôts avec mode immuable côté solution de sauvegarde

Avantages : protection forte contre la suppression, intégration fluide, bonne compatibilité avec des environnements hybrides.

Limites : si l’attaquant contrôle la couche qui définit la politique (mauvaise gouvernance des comptes, clés d’accès), il peut tenter de contourner la protection. L’immutabilité n’exonère pas de la segmentation et du durcissement.

Air-gap (isolement)

Un air-gap vise une séparation logique ou physique entre production et sauvegardes.

• logique : réseau séparé, règles strictes, accès administratifs dédiés
• physique : infrastructure distincte, voire site séparé

Avantages : réduit fortement les attaques « à portée de réseau ».

Limites : plus complexe à opérer, nécessite des procédures et une discipline d’accès.

Offline (hors ligne)

Une copie hors ligne n’est pas accessible en permanence (média déconnecté, export contrôlé, coffre).

Avantages : résistance très élevée au chiffrement à distance.

Limites : délais de récupération, logistique, risques opérationnels (rotation, stockage sécurisé).

Recommandation pratique

Combinez :

• une copie immuable pour une restauration rapide
• une copie hors ligne ou fortement isolée pour le pire scénario

Et documentez le cas d’usage : restauration « erreur humaine », restauration « ransomware confirmé », restauration « sinistre site ». La bonne réponse dépend de votre RTO/RPO et de votre capacité d’exploitation.

Une architecture anti-ransomware efficace couvre l’ensemble du SI, pas seulement les serveurs. L’enjeu est de limiter la portée d’un compte compromis et de rendre la restauration priorisée et répétable.

Serveurs et virtualisation

• Protégez les VM et les données applicatives (fichiers, bases, partages) avec une politique alignée sur les tiers RPO/RTO.
• Séparez réseau de production et réseau de sauvegarde quand c’est possible.
• Utilisez des comptes dédiés (sans droits interactifs) pour les agents et les accès aux hyperviseurs.

Microsoft 365

M365 n’est pas une sauvegarde en soi. Prévoyez une stratégie dédiée :

• Exchange, OneDrive, SharePoint, Teams
• rétention et restauration granulaire
• dépôt immuable ou isolé, différent des identités de production

Postes nomades

• Sauvegarde des profils et données critiques (documents métier) via synchronisation contrôlée ou sauvegarde endpoint.
• Chiffrement des postes et durcissement des accès (réduction des droits locaux) pour limiter l’exfiltration.

Sites distants

• Stratégie « local + central » : cache local pour restaurer vite sur site, copie centralisée immuable pour la résilience.
• Bande passante : prioriser les données critiques, planifier les fenêtres, gérer la déduplication.

Exemple de répartition (à adapter)

Cette architecture n’a de valeur que si les chemins d’administration (console, comptes, API) sont durcis et segmentés.

La règle « 0 erreur » de 3-2-1-1-0 se gagne par l’exploitation : ce que vous mesurez, ce que vous testez, et ce que vous savez refaire sous stress.

Supervision orientée risque

Ne vous limitez pas au statut « succès/échec ». Surveillez :

• absence de sauvegarde récente sur un actif critique
• variations anormales de volumétrie (signe de chiffrement ou d’exfiltration)
• échecs récurrents sur un même périmètre (agents, snapshots, API M365)
• changements de configuration (rétention, immutabilité, comptes, clés)

Tests de restauration réguliers

Planifiez des restaurations :

• fichiers (restauration simple)
• application (cohérence fonctionnelle)
• système (VM complète, annuaire, services d’infra)

L’objectif n’est pas seulement de « restaurer », mais de valider : droits, performance, dépendances, et acceptation métier.

Exercices de crise

Simulez un scénario ransomware : console indisponible, identifiants suspects, réseau segmenté, pression temporelle. Exercez :

• qui décide de restaurer et sur quel périmètre
• comment isoler avant de réinjecter des systèmes restaurés
• comment traiter les secrets (mots de passe, clés, MFA)

Documentation utile le jour J

Documentez au format simple :

• ordre de restauration (infra, identité, applicatifs)
• accès hors bande aux dépôts (procédure coffre)
• contacts et responsabilités
• preuves : journaux, rapports de tests, emplacements des sauvegardes

Une bonne documentation réduit les improvisations. En crise, le problème n’est pas « connaître l’outil », mais enchaîner des décisions sûres avec des preuves de restauration.

Beaucoup d’échecs de reprise ne viennent pas d’un manque d’outils, mais de choix d’architecture et d’exploitation qui donnent à l’attaquant un chemin direct vers les sauvegardes.

Erreur 1 : sauvegardes administrées depuis le même domaine

Si la console de sauvegarde, les dépôts et les comptes sont dans le même périmètre d’identité que la production, un attaquant qui compromet l’annuaire peut viser la suppression des points de restauration ou le chiffrement du dépôt.

Mesure : comptes d’administration dédiés, séparation des rôles, durcissement MFA, et idéalement un plan d’administration isolé.

Erreur 2 : permissions trop larges sur les dépôts

Des droits d’écriture ou de suppression trop permissifs (SMB/NFS, objets, API) rendent les dépôts vulnérables au sabotage.

Mesure : moindre privilège, séparation lecture/écriture, immutabilité avec rétention, et journalisation des opérations sensibles.

Erreur 3 : pas de segmentation réseau

Sans segmentation, un poste compromis peut pivoter vers l’infrastructure de sauvegarde.

Mesure : VLAN dédiés, filtrage, limitation des flux d’administration, bastion, et supervision des accès.

Erreur 4 : rétention incohérente avec le scénario ransomware

Si la fenêtre de conservation est trop courte, vous risquez de ne garder que des sauvegardes déjà chiffrées.

Mesure : politique de rétention alignée sur le risque, avec au moins une copie immuable/hors ligne, et des points de restauration « repères ».

Erreur 5 : restauration non testée

Un job « OK » ne garantit ni la cohérence applicative ni la vitesse de reprise.

Mesure : tests planifiés, validation métier, et correction des écarts. Une stratégie anti-ransomware se juge sur la restauration, pas sur la sauvegarde.

Cette checklist vous aide à déployer dans le bon ordre une stratégie de sauvegarde anti-ransomware, sans vous perdre dans les options.

1. Cadrer (métier et périmètre)

• Identifier les processus critiques et leurs dépendances
• Fixer RPO/RTO par tier de criticité
• Définir le périmètre exact : on-prem, cloud, M365, endpoints, sites distants

2. Concevoir 3-2-1-1-0 (copies survivantes)

• Cartographier les copies existantes (où, qui supprime, combien de temps, comment vérifier)
• Ajouter une copie hors site et une copie immuable ou hors ligne
• Choisir les supports (différents) et documenter les chemins de restauration

3. Sécuriser l’administration

• Comptes dédiés (moindre privilège) pour sauvegarde et stockage
• MFA et séparation des rôles d’administration
• Segmentation réseau entre production, dépôt, administration

4. Mettre sous supervision

• Alertes sur absence de sauvegarde récente
• Détection d’anomalies de volumétrie et d’échecs répétés
• Journalisation des actions sensibles (suppression, changement de rétention, clés)

5. Prouver la restauration

• Restaurations régulières (fichier, VM, application)
• Exercice de crise documenté (isolement, décision, ordre de reprise)
• Compte-rendu : temps, écarts, actions correctives

Si vous ne deviez retenir qu’une règle : toute décision (outil, cloud, on-prem) doit être validée par un test de restauration reproductible et tracé.