La règle 3-2-1 à l'épreuve du rançongiciel

Éditorial

La règle 3-2-1 a été pensée contre la panne et le sinistre, pas contre un adversaire qui détient les identifiants de la production. Une sauvegarde joignable avec ces identifiants n'est pas une sauvegarde : c'est une copie de plus à chiffrer.

Mis à jour le 25 septembre 2026~24 min de lecture13 sections

papy cyber

→ Lire l’explication complète de la marmotte

Une règle écrite pour un autre ennemi

La règle 3-2-1 est l’un des rares dogmes de l’informatique que tout le monde récite et que personne ne conteste, ce qui devrait suffire à la rendre suspecte. Trois copies des données, sur deux supports différents, dont une hors site. On en attribue généralement la formulation à un photographe soucieux de ses archives numériques, ce qui me la rend plutôt sympathique : c’est une règle de gens qui avaient quelque chose à perdre et qui ne voulaient pas le perdre.

Elle est excellente. Elle est aussi datée, non parce qu’elle serait fausse, mais parce qu’elle répond à une liste de menaces qui n’est plus la bonne. Regardons contre quoi elle protège. Trois copies : contre la corruption d’une copie. Deux supports : contre la défaillance d’une technologie, le lot de disques défectueux, le format de bande devenu illisible. Une copie hors site : contre l’incendie, l’inondation, le cambriolage, le voisin qui perce un mur porteur.

Tous ces ennemis ont un point commun admirable : ils sont stupides. L’incendie ne cherche pas la bande de sauvegarde. L’inondation ne lit pas la documentation. Le disque qui meurt ne s’est pas renseigné sur la politique de rétention. La règle 3-2-1 est une règle probabiliste contre des événements indépendants, et elle marche précisément parce que ces événements n’ont aucune intention.

Le rançongiciel moderne, lui, en a une. Il est opéré par des gens patients, compétents, rémunérés au résultat, qui ont compris depuis longtemps que la sauvegarde est le seul obstacle entre eux et le paiement. Ils ne tombent pas sur vos sauvegardes par hasard ; ils les cherchent, avant de chiffrer quoi que ce soit, parce qu’une victime qui peut restaurer ne paie pas. La destruction méthodique des copies de secours fait partie du mode opératoire documenté de nombreux groupes, au même titre que la suppression des clichés instantanés du système.

Face à un adversaire intelligent, l’indépendance des copies disparaît. Trois copies joignables avec les mêmes identifiants ne font pas trois chances de survie : elles en font une seule, répétée trois fois. Une sauvegarde joignable avec les identifiants de la production n’est pas une sauvegarde. C’est une copie de plus à chiffrer, et, pour l’attaquant, une commodité : elle lui indique où se trouvent les données qui comptent.

Cet éditorial examine ce qu’il faut ajouter à la règle pour qu’elle survive à ce changement d’ennemi. La réponse tient en trois mots (immutabilité, isolation, vérification), et chacun d’eux est plus difficile qu’il n’en a l’air.

Comment meurt une sauvegarde

Il faut d’abord regarder le mécanisme de près, parce que l’intuition est trompeuse. On imagine volontiers le rançongiciel comme un programme qui se propage et chiffre tout sur son passage, y compris, par malchance, le partage réseau où traînaient les sauvegardes. Ce scénario existe, mais c’est le moins inquiétant. Le plus inquiétant est celui où un humain, installé dans le réseau depuis un certain temps, fait l’inventaire avant d’agir.

Supposons une PME de vingt postes, avec un serveur de fichiers, un annuaire, un logiciel de gestion et une sauvegarde qui, chaque nuit, copie tout cela vers un NAS dans le local technique, lequel réplique vers un stockage en ligne. C’est du 3-2-1 honorable : trois copies, deux supports, une hors site. Suivons l’attaquant.

Il obtient un premier accès, par hameçonnage, par un service exposé mal tenu, par des identifiants réutilisés. Peu importe ici.

Il élève ses privilèges jusqu’à un compte d’administration du domaine. Dans un petit réseau, la distance entre un poste compromis et l’administrateur du domaine est souvent courte, parce que les mêmes personnes administrent tout avec les mêmes comptes, par commodité, depuis toujours.

Il cherche les sauvegardes. Il trouve la console du logiciel, installée sur un serveur membre du domaine, accessible avec les identifiants d’administration. Il trouve le NAS, dont le partage est monté sur le serveur de sauvegarde et dont l’interface accepte le compte administrateur du domaine, parce qu’on l’a joint au domaine pour « simplifier la gestion des droits ». Il trouve, dans la configuration du logiciel, les identifiants du stockage en ligne, puisque le logiciel en a besoin pour y écrire.

Il détruit, dans l’ordre inverse de la difficulté. Il réduit la rétention à un jour dans la console, ou supprime les jeux de sauvegarde. Il formate le volume du NAS, ou le chiffre en premier. Il utilise les identifiants trouvés pour vider le compartiment en ligne, ou pour modifier sa politique de cycle de vie.

Puis, seulement puis, il chiffre la production.

Rien, dans ce scénario, n’a violé la règle 3-2-1. Il y avait bien trois copies, deux supports, une hors site. Toutes les trois étaient atteignables à partir d’un même point de compromission, parce que la règle compte les copies mais ne dit rien des chemins qui y mènent. Le coffre-fort était solide ; la combinaison était sur un post-it collé à la porte de la maison.

Le vrai critère : le domaine de compromission

La leçon du scénario tient en une notion, que je trouve plus utile que la règle elle-même : le domaine de compromission. Deux copies appartiennent au même domaine si un attaquant qui prend le contrôle de l’une dispose, par ce seul fait, de ce qu’il faut pour détruire l’autre. Le nombre de copies qui compte n’est pas le nombre total ; c’est le nombre de domaines de compromission distincts entre lesquels elles sont réparties.

Sous cet angle, beaucoup de dispositifs qui se croient redondants s’avèrent singuliers. Le cliché instantané sur la baie de stockage de la production : même administrateur, même domaine. La réplication synchrone vers un second site : elle réplique fidèlement le chiffrement, avec une latence remarquable. Le RAID, dont il faut redire à chaque génération qu’il n’est pas une sauvegarde, et qui chiffre ses deux disques en parfaite synchronie. Le dossier synchronisé vers un service de partage en ligne, qui propage le chiffrement avec un zèle que l’on aimerait voir à d’autres processus.

Qu’est-ce qui sépare deux domaines ? Presque toujours la même chose : les identités. Un réseau segmenté dont tous les équipements acceptent le même compte d’administration n’est segmenté que pour les paquets, pas pour l’attaquant. La segmentation réseau est nécessaire, mais c’est la séparation des identités qui fait la frontière. Concrètement :

l’infrastructure de sauvegarde ne doit pas dépendre de l’annuaire de la production pour son authentification ;
ses comptes d’administration doivent être distincts, protégés par une authentification forte, et ne jamais être utilisés depuis un poste de la production ;
les identifiants que la production détient pour parler à la sauvegarde, s’il en faut, ne doivent permettre que d’écrire de nouvelles données, jamais de supprimer ni de modifier la rétention ;
dans un environnement en nuage, le compte qui héberge les sauvegardes doit être distinct de celui de la production, avec ses propres administrateurs. La persistance d’un attaquant dans la gestion des identités d’un fournisseur de nuage montre ce que devient un compte unique quand on y a laissé entrer quelqu’un.

Cela coûte de la commodité, et c’est le point. La sécurité d’une sauvegarde se mesure exactement à l’inconfort qu’elle impose à son propre administrateur. Une sauvegarde qu’on administre sans friction depuis son poste habituel est une sauvegarde qu’un attaquant administrera sans friction depuis le même poste.

Pousser ou tirer

Il existe une décision d’architecture qui détermine à elle seule une bonne partie de la réponse, et qu’on prend généralement sans la voir : qui initie la sauvegarde ?

En mode « push », c’est la machine sauvegardée qui envoie ses données vers la destination. Elle doit donc détenir un moyen de s’authentifier auprès de la destination. Si ce moyen permet aussi de supprimer, l’attaquant qui compromet la machine peut détruire ses sauvegardes. C’est le mode par défaut de beaucoup d’outils, parce qu’il est simple : chaque machine sait ce qu’elle doit sauvegarder et quand.

En mode « pull », c’est le serveur de sauvegarde qui vient chercher les données. La machine sauvegardée ne détient aucun identifiant vers la sauvegarde ; elle ignore même, idéalement, où elle se trouve. Compromettre la production ne donne rien sur la sauvegarde. C’est la raison pour laquelle le mode pull est souvent recommandé contre le rançongiciel.

Il faut en voir le revers, car il n’y a pas de repas gratuit, seulement des additions différées. En mode pull, le serveur de sauvegarde détient des accès en lecture à toutes les machines qu’il sauvegarde, souvent avec des privilèges élevés pour pouvoir tout lire. Il devient la cible la plus précieuse du réseau : le compromettre, c’est obtenir à la fois la capacité de détruire les sauvegardes et un accès à l’ensemble de la production. On a déplacé le risque, et on l’a concentré. C’est un bon marché à une seule condition : que ce serveur soit réellement mieux protégé que le reste, isolé, sans exposition, administré depuis ailleurs, avec des accès de lecture aussi restreints que possible.

Il existe une troisième voie, souvent la meilleure pour une petite structure : le push vers une destination qui n’accepte que l’ajout. La machine envoie ses données, mais les identifiants qu’elle détient ne permettent ni de supprimer ni de réécrire. Plusieurs outils de sauvegarde courants proposent un mode d’ajout seul côté serveur (c’est le cas de borg et du serveur REST de restic, par exemple), et les stockages objets permettent d’écrire des politiques d’accès sans droit de suppression. On garde la simplicité du push et on retire à l’attaquant l’outil dont il avait besoin.

L’immutabilité, et ses petits caractères

La deuxième réponse consiste à rendre les copies impossibles à modifier, même par quelqu’un qui dispose d’identifiants valides. Si la donnée ne peut physiquement ni être effacée ni réécrite avant une date donnée, peu importe qui détient quoi.

Il existe plusieurs façons d’y parvenir, qui n’offrent pas la même garantie.

Le verrouillage d’objets dans un stockage objet. Sur un stockage compatible S3, le verrouillage d’objets (Object Lock) empêche la suppression ou l’écrasement d’une version d’objet avant une date de rétention. Il existe deux modes, et la différence est capitale. En mode gouvernance, un utilisateur disposant d’une permission particulière peut lever la protection : c’est une ceinture, pas une cage, et un attaquant qui obtient cette permission la lève aussi. En mode conformité, personne ne peut raccourcir la rétention ni supprimer l’objet avant l’échéance, pas même le compte racine. C’est la vraie immutabilité, et elle a la contrepartie qu’on devine : une erreur de configuration (une rétention de dix ans au lieu de dix jours) se paie pendant dix ans, sur la facture.

La vérification de la configuration, en lecture seule :

# Lecture seule : configuration de verrouillage par défaut d'un compartiment
aws s3api get-object-lock-configuration --bucket mes-sauvegardes

# Lecture seule : rétention effective d'une version précise d'un objet
aws s3api get-object-retention --bucket mes-sauvegardes \
  --key chemin/vers/objet --version-id <identifiant-de-version>

On cherche le mode (COMPLIANCE ou GOVERNANCE) et la durée. L’absence de configuration, ou un mode gouvernance avec une permission de contournement accordée largement, signifie que l’immutabilité est déclarative.

Les clichés de systèmes de fichiers. ZFS et Btrfs permettent des clichés en lecture seule, peu coûteux et rapides. Ils sont excellents contre la suppression accidentelle et contre un chiffrement qui passerait par le système de fichiers d’un client. Ils ne résistent pas à un administrateur de l’hôte qui les détruit. Un cliché sur une machine dont l’attaquant a obtenu la racine est un cliché que l’attaquant supprimera. Ils sont immuables pour les utilisateurs, pas pour les administrateurs : c’est une excellente propriété, à condition de ne pas la confondre avec une autre.

Les supports déconnectés. La bande sortie de la bibliothèque, le disque externe débranché et rangé dans un tiroir fermé à clé. C’est la forme la plus ancienne de l’immutabilité, et la seule qui ne dépende d’aucun logiciel : un support qui n’est connecté à rien ne peut être atteint par rien. Elle a mauvaise réputation parce qu’elle demande un geste humain régulier, et que le geste humain régulier est la chose la moins fiable de l’informatique. Mais un disque débranché le vendredi soir, dans un tiroir, a résisté à plus d’attaques que bien des architectures qui le méprisent.

L’immutabilité vendue. Beaucoup de produits de sauvegarde annoncent désormais des « copies immuables ». Le mot est devenu un argument commercial, ce qui l’a exposé à l’usure habituelle des mots devenus arguments commerciaux. Il faut toujours poser la même question, d’une grossièreté salutaire : qui peut lever cette immutabilité, et avec quels identifiants ? Si la réponse est « l’administrateur de la console », et que la console accepte le compte d’administration du domaine, l’immutabilité est un paramètre, pas une propriété.

La sauvegarde qui contient déjà l’attaquant

Il y a un piège que la règle 3-2-1 n’a jamais eu à considérer, parce que l’incendie ne s’installe pas chez vous trois semaines avant de se déclarer.

Un attaquant humain est souvent présent dans le réseau un certain temps avant de chiffrer. Pendant ce temps, les sauvegardes continuent de tourner, consciencieusement, et sauvegardent l’attaquant avec le reste : ses comptes créés, ses tâches planifiées, ses portes dérobées, ses outils déposés. Restaurer la sauvegarde de la veille, c’est restaurer une production chiffrée moins le chiffrement, c’est-à-dire exactement le réseau que l’attaquant a quitté quelques heures plus tôt, avec la porte qu’il avait laissée ouverte pour revenir.

Deux conséquences.

La rétention doit remonter plus loin que la date d’intrusion probable. Une rétention de sept jours protège contre la suppression accidentelle ; elle ne permet pas de revenir à un état antérieur à une compromission qui a commencé le mois précédent. Combien de temps faut-il ? Je n’ai pas de chiffre honnête à donner : cela dépend de la capacité à détecter, qui est précisément ce qui fait défaut. Ce qui est sûr, c’est que la rétention la plus longue doit être pensée en fonction de cette question, et non du seul coût du stockage.

La restauration doit distinguer les données des systèmes. Les données métier (fichiers, bases) peuvent souvent être restaurées depuis une sauvegarde récente, après vérification. Les systèmes (annuaire, serveurs, postes) sont plus sûrement reconstruits à partir de sources de confiance (images de référence, configuration déclarative) qu’extraits d’une sauvegarde potentiellement contaminée. Une infrastructure dont la configuration existe sous forme de code se reconstruit ; une infrastructure configurée à la main pendant dix ans se restaure, avec tout ce qu’elle contenait.

Il existe enfin une variante plus sournoise : l’attaquant qui, au lieu de détruire les sauvegardes, les corrompt silencieusement pendant des semaines, en altérant les données à la source ou en modifiant la clé de chiffrement de la sauvegarde. Le jour venu, les sauvegardes existent, sont immuables, et contiennent des données inutilisables. Seule une vérification régulière de contenu, et pas seulement de présence, peut détecter ce scénario. On y arrive.

3-2-1-1-0 : les deux chiffres qu’on avait oubliés

Pour intégrer ces leçons, une extension de la règle circule, popularisée notamment par des éditeurs de sauvegarde : 3-2-1-1-0. Aux trois chiffres historiques, elle en ajoute deux.

Le second « 1 » : une copie hors ligne, isolée ou immuable. Au moins une copie doit se trouver hors de tout domaine de compromission joignable depuis la production : déconnectée physiquement, ou protégée par une immutabilité qu’aucun identifiant de la production ne peut lever. C’est la traduction directe de tout ce qui précède, et c’est le chiffre qui compte le plus.

Le « 0 » : zéro erreur à la vérification. Les sauvegardes doivent être vérifiées, et la vérification ne doit produire aucune erreur non résolue. C’est le chiffre le plus négligé, parce qu’il ne coûte pas d’argent mais du temps, et que le temps est la seule ressource dont personne ne dispose jamais.

Je trouve cette extension utile et je m’en méfie un peu. Utile, parce qu’elle force à nommer les deux propriétés que la règle originale supposait implicitement. Méfiance, parce qu’une règle à cinq chiffres ressemble déjà à un code de carte bancaire, et qu’on connaît le sort des codes de carte bancaire : on les note quelque part. Le risque est qu’on coche « 3-2-1-1-0 » comme on cochait « 3-2-1 », sans se demander si la copie « isolée » l’est vraiment et si le « 0 » vient d’une restauration ou d’un voyant vert.

Car c’est là tout le problème du zéro.

Une sauvegarde non restaurée est une hypothèse

Le voyant vert du logiciel de sauvegarde dit une chose précise : que le travail s’est terminé sans erreur signalée. Il ne dit pas que les données sont restaurables, ni qu’elles sont les bonnes, ni qu’elles sont complètes, ni qu’on sait les remettre en service dans un délai acceptable. Il dit que le programme n’a pas eu à se plaindre. C’est le degré de certitude d’un employé qui déclare n’avoir rien remarqué.

Une sauvegarde qui n’a jamais été restaurée n’est pas une sauvegarde : c’est une hypothèse. Et comme toutes les hypothèses, elle se révèle généralement fausse au moment exact où on en a besoin, pour des raisons d’une banalité désarmante : un répertoire exclu par erreur, une base sauvegardée à chaud dans un état incohérent, une clé de chiffrement de la sauvegarde que personne n’a conservée ailleurs que sur le serveur chiffré, une procédure qui suppose un logiciel dont la licence a expiré.

Il y a plusieurs niveaux de vérification, par ordre croissant de valeur.

Vérifier l’intégrité du dépôt. Les outils sérieux savent contrôler que les données stockées correspondent à leurs empreintes. C’est la base, et cela détecte la corruption du support. Avec restic, par exemple :

# Lecture seule : liste des instantanés présents dans le dépôt
restic -r /chemin/vers/depot snapshots

# Lecture seule : vérifie la structure du dépôt et relit
# un dixième des données pour contrôler leurs empreintes
restic -r /chemin/vers/depot check --read-data-subset=1/10

Relire un sous-ensemble différent à chaque passage finit par couvrir l’ensemble. Le principe s’appuie sur les condensats cryptographiques : l’outil sait que les données n’ont pas changé depuis l’écriture. Il ne sait pas si elles étaient bonnes au moment de l’écriture.

Restaurer des fichiers. Extraire une sélection de fichiers dans un emplacement neutre et vérifier qu’ils s’ouvrent. Cette opération écrit sur disque : elle doit viser un répertoire vide dédié, jamais l’emplacement d’origine.

# ÉCRIT sur disque : restauration du dernier instantané dans un
# répertoire de test vide, jamais par-dessus les données de production.
restic -r /chemin/vers/depot restore latest \
  --target /srv/test-restauration --include /donnees/compta

Restaurer un service. Remonter une base dans un environnement isolé, démarrer l’application qui l’utilise, vérifier qu’un utilisateur peut travailler. Pour une base, la restauration à un instant donné se teste de la même manière : si on ne l’a jamais rejouée, on ne sait pas si on sait le faire.

Restaurer tout, en chronométrant. L’exercice complet, sur un environnement séparé, avec la montre. C’est le seul qui réponde à la question qui intéresse la direction : combien de temps l’activité sera-t-elle arrêtée ? La page sur la continuité et les plans de reprise détaille les notions de durée maximale d’interruption et de perte de données admissible ; ce qu’il faut retenir ici, c’est qu’un objectif de reprise qui n’a jamais été mesuré est un vœu.

Le niveau de test qu’on pratique réellement dit à peu près tout de la maturité d’une organisation en matière de sauvegarde. Beaucoup s’arrêtent au voyant vert. Les meilleures restaurent tout, régulièrement, et en sortent rarement sans une surprise, ce qui est la preuve que le test sert.

Le meilleur argument contre

Il faut maintenant laisser la parole à la défense, qui a de bons arguments.

Tout cela est disproportionné pour une petite structure. Une entreprise de dix personnes n’a ni le temps, ni la compétence, ni le budget pour maintenir un domaine d’identité séparé, un serveur de sauvegarde en mode pull durci, un stockage objet en mode conformité et des exercices de restauration trimestriels. Lui présenter cette liste, c’est la décourager, et une organisation découragée ne fait rien. Mieux vaut une règle 3-2-1 imparfaite et appliquée qu’une architecture exemplaire restée sur le papier. Par ailleurs, les attaquants les plus méthodiques ciblent des organisations capables de payer ; la petite structure a davantage à craindre d’une attaque opportuniste et automatisée, que des mesures plus simples suffisent à contrer.

Et un second argument, plus dérangeant : la sauvegarde ne protège plus de l’essentiel. De nombreux groupes pratiquent désormais la double extorsion : ils exfiltrent les données avant de les chiffrer, et menacent de les publier. Contre cette menace, la meilleure sauvegarde du monde ne sert à rien. Elle permet de reprendre l’activité, pas d’empêcher la divulgation. Investir massivement dans l’immutabilité, c’est bien armer la porte de derrière pendant que les voleurs sortent par celle de devant avec les meubles.

Je prends ces deux arguments au sérieux.

Sur la proportionnalité, je suis d’accord avec le principe et en désaccord avec la conclusion. Il n’est pas nécessaire de tout faire. Il est nécessaire de faire une chose : avoir au moins une copie que les identifiants de la production ne peuvent pas atteindre. Pour une petite structure, cela peut être aussi simple qu’un disque externe débranché chaque semaine et emporté hors des locaux, ou un stockage en ligne distinct avec des identifiants en ajout seul et un verrouillage en mode conformité sur une durée raisonnable. Ce n’est ni coûteux ni compliqué. C’est inconfortable, ce qui est différent, et c’est précisément pourquoi personne ne le fait. Quant à l’idée que les attaques automatisées sont plus simples, elle est exacte, mais elles aussi savent trouver un partage réseau monté et supprimer des clichés instantanés.

Sur la double extorsion, l’argument est juste et il faut le dire franchement : la sauvegarde protège la disponibilité, pas la confidentialité. Mais de là à la déclasser, il y a un pas que je ne franchis pas. Une organisation qui ne peut pas restaurer subit les deux menaces ; celle qui peut restaurer n’en subit plus qu’une, et négocie dans une position très différente. La sauvegarde n’est pas la réponse à tout. Elle reste la condition pour que les autres réponses aient le temps d’exister.

Ce que je ne sais pas

Je ne sais pas quelle rétention est raisonnable contre une intrusion longue. Elle dépend du délai entre intrusion et détection, que je ne peux pas estimer pour une organisation donnée, et je me méfie des chiffres moyens qui circulent sans méthode publiée. Je sais seulement que « sept jours » ne répond pas à la question.

Je ne sais pas ce que valent réellement les « copies immuables » de chaque produit. L’immutabilité se vérifie dans la documentation, dans la configuration et, idéalement, par un test où l’on tente de supprimer avec les droits les plus élevés disponibles. Je n’ai pas fait ce test pour les produits du marché et je ne prétends pas les classer. Faites-le pour le vôtre, sur un jeu de test, et regardez ce qui se passe.

Je ne sais pas si le mode pull est meilleur que le push avec ajout seul pour une petite structure. Le premier concentre le risque sur un serveur qu’il faut savoir durcir ; le second le disperse sur des clients qu’il faut savoir configurer. Mon intuition penche pour le second quand l’équipe est réduite, mais c’est une intuition, pas un résultat.

Je ne sais pas comment évoluera l’économie de l’attaque. Si l’exfiltration devient le levier principal, l’attention des attaquants aux sauvegardes pourrait diminuer, ou au contraire se renforcer pour maximiser la pression. Les tendances en la matière changent vite, et un texte qui prétendrait les prévoir mériterait qu’on s’en méfie.

Ce qui reste

La règle 3-2-1 n’est pas fausse. Elle est incomplète d’une manière précise : elle compte des copies, alors que l’attaquant, lui, compte des chemins. Contre un ennemi qui ne cherche pas, le nombre suffit. Contre un ennemi qui cherche, seule compte la copie qu’il ne peut pas atteindre, et qu’on a vu revenir à la vie au moins une fois.

Trois choses me paraissent acquises. Que le critère qui compte est le domaine de compromission, et qu’il se trace presque toujours le long des identités, bien plus que le long des câbles. Que l’immutabilité n’existe que si l’on peut nommer qui a le droit de la lever, et que cette personne n’est pas l’attaquant ; tout le reste est un paramètre avec un joli nom. Et qu’une sauvegarde non restaurée est une hypothèse, que les rançongiciels se chargent de tester à votre place, à la date de leur choix.

Il y a quelque chose de vexant, à mon âge, à constater que la meilleure réponse à une menace aussi sophistiquée ressemble à s’y méprendre à un disque débranché dans un tiroir. Mais le tiroir a un avantage que n’aura jamais la plus belle des consoles : personne ne peut s’y connecter.

L’éditorial sur l’effacement arrivait par l’autre bout à la même contradiction : les propriétés qui rendent une sauvegarde indestructible sont celles qui la rendent impossible à expurger. Il faudra choisir, pour chaque donnée, lequel des deux échecs on préfère. C’est la seule question de sauvegarde qu’aucun logiciel ne pose à votre place.

🐝 Ce qui arrive si on s’en passe

Une organisation qui s’en tient au décompte des copies découvre leur fragilité le jour où elle en a besoin, c’est-à-dire trop tard pour la corriger. Les sauvegardes joignables depuis la production disparaissent avant le chiffrement, et la négociation commence sans alternative. Celles qui survivent peuvent contenir l’attaquant lui-même, si bien qu’une restauration précipitée remet en service ses comptes et ses tâches planifiées ; l’incident se rejoue alors quelques jours plus tard, sans surprise pour personne, sauf pour la victime. Et faute d’exercice de restauration chronométré, la durée d’arrêt annoncée à la direction reste une estimation optimiste, que les événements se chargent de réviser.

🦫 Explication de la marmotte 🍫

Une sauvegarde est une copie des données, faite régulièrement pour pouvoir les récupérer en cas de problème. La règle classique demande trois copies, sur deux types de supports différents, dont une conservée dans un autre lieu. Elle protège bien contre les pannes, les incendies ou les inondations, qui frappent au hasard. Un rançongiciel est un logiciel malveillant qui chiffre les fichiers d’une organisation pour exiger une rançon contre leur déblocage. Les personnes qui le déploient entrent d’abord dans le réseau, obtiennent des droits d’administrateur, cherchent les sauvegardes et les détruisent, puis seulement chiffrent le reste. Si toutes les copies sont accessibles avec les mêmes identifiants que les serveurs habituels, elles tombent toutes ensemble. Trois protections s’ajoutent alors. L’isolation : les sauvegardes utilisent des comptes séparés, et les serveurs ne peuvent qu’y ajouter des données, jamais en supprimer. L’immutabilité : certaines copies ne peuvent être ni effacées ni modifiées avant une date fixée, ou restent sur un disque débranché. La vérification : il faut régulièrement restaurer des fichiers, puis des services entiers, en mesurant le temps nécessaire, car une sauvegarde jamais restaurée peut se révéler inutilisable. Il faut aussi garder des copies assez anciennes, car l’attaquant est souvent présent plusieurs semaines avant d’agir et se retrouve dans les sauvegardes récentes. Enfin, une sauvegarde permet de reprendre le travail, mais n’empêche pas la publication de données volées.

Pages voisines

La citent

La règle 3-2-1 à l'épreuve du rançongiciel

Elle cite

: les deux pages se citent l’une l’autre.

La règle 3-2-1 à l'épreuve du rançongiciel

Une règle écrite pour un autre ennemi

Comment meurt une sauvegarde

Le vrai critère : le domaine de compromission

Pousser ou tirer

L’immutabilité, et ses petits caractères

La sauvegarde qui contient déjà l’attaquant

3-2-1-1-0 : les deux chiffres qu’on avait oubliés

Une sauvegarde non restaurée est une hypothèse

Le meilleur argument contre

Ce que je ne sais pas

Ce qui reste

🐝 Ce qui arrive si on s’en passe

🦫 Explication de la marmotte 🍫

À lire aussi

Pages voisines