Oui, les chiffres publiés par Veeam décrivent des dépôts de sauvegarde visés de façon systématique dans les attaques par rançongiciel. Une sauvegarde était traditionnellement conçue contre l’accident, le disque qui lâche, le local inondé, le fichier supprimé par erreur. Elle affronte désormais quelqu’un qui la cherche.
Ce que disent les chiffres
89 % des organisations touchées par un rançongiciel ont vu leurs dépôts de sauvegarde visés, et en moyenne 34 % des dépôts ont été modifiés ou supprimés par les attaquants, selon Veeam.
Ces chiffres décrivent une méthode installée, qui fait désormais partie du mode opératoire ordinaire.
Pourquoi la sauvegarde passe en premier
La logique de l’attaquant est simple. Une entreprise capable de restaurer ne paie pas. S’il détruit la capacité de reprise avant de chiffrer quoi que ce soit, un incident gênant devient une négociation.
Il doit pour cela rester présent sur le réseau plusieurs jours ou plusieurs semaines, le temps de localiser les dépôts, d’obtenir les droits nécessaires et d’agir. Pendant ce délai, une détection reste possible.
Le périmètre à protéger a donc changé. Une sauvegarde accessible depuis le même annuaire que la production, avec un compte d’administration ordinaire, devient une cible de plus, et elle contient l’intégralité des données.
Ce que la règle historique ne couvre pas
La règle des trois copies, sur deux supports, dont une hors site, est ancienne et reste valable. Elle a été pensée contre le hasard, et elle continue de bien fonctionner contre lui.
Face à quelqu’un qui cherche, elle ne dit rien. Une copie hors site reste effaçable si elle est joignable avec les mêmes identifiants. Deux supports différents n’apportent rien de plus si les deux répondent au même compte.
Deux exigences se sont donc ajoutées ces dernières années. La première est une copie impossible à supprimer avant une date donnée, même par quelqu’un disposant de tous les droits. La seconde est une vérification systématique dont le résultat attendu est zéro erreur.
Elles se mettent en place progressivement, et la méthode complète est décrite dans l’article sur la fiabilité réelle des sauvegardes.
L’immuabilité, ce qu’elle couvre et ce qu’elle ne couvre pas
Elle empêche la suppression et la modification pendant une durée fixée à l’avance. C’est la seule protection qui résiste à un compte d’administration compromis, et la plupart des offres sérieuses la proposent aujourd’hui sans surcoût majeur.
Elle ne vous dispense de rien d’autre. Tant que personne n’a vérifié la restauration d’une copie immuable, vous ne savez pas si elle fonctionne. La durée de rétention choisie compte aussi, car une rétention de sept jours reste sans effet contre une présence installée depuis trois semaines.
Le test de restauration, l’exigence que l’on repousse
Des deux exigences ajoutées, la seconde demande du temps, alors que l’autre se règle par un paramétrage. C’est ce qui explique qu’on la remette à plus tard.
Un rapport de sauvegarde qui affiche un succès prouve que des données ont été copiées. Il ne dit pas si elles sont lisibles et complètes, ni si un système peut redémarrer à partir d’elles. Seule une restauration menée pour de bon le démontre, et elle doit être tracée pour valoir preuve devant un assureur ou un donneur d’ordre.
Une fois par an suffit, sur un périmètre représentatif, à condition de le faire. Quatre tests inscrits au plan et jamais réalisés ne vous apprennent rien.
Ce que la mise à niveau demande
Vous n’aurez besoin ni d’une refonte ni d’un budget considérable. Il faut un état des lieux de ce qui est sauvegardé, quelques arbitrages sur les durées de rétention et les périmètres, l’activation de l’immuabilité là où l’offre le permet, et un test de restauration conduit jusqu’au bout, terrain compris.
Ce travail se fait en quelques jours, une fois. Dans une PME, aucun rôle n’en est chargé, et les rapports de sauvegarde continuent alors d’arriver par messagerie, dans un dossier que plus personne n’ouvre.
Questions fréquentes
Une sauvegarde dans le cloud est-elle immuable par défaut ?
Non, c’est une option à activer et à configurer. L’hébergement distant protège de l’incendie et du dégât des eaux, sans rien pouvoir contre un compte compromis qui dispose des droits de suppression. Demandez à votre prestataire quelle durée d’immuabilité s’applique à vos données, et ce qui l’empêche d’être réduite.
Quelle durée de rétention immuable choisir ?
Elle doit dépasser le temps qu’un attaquant peut passer sur un réseau sans être détecté, qui se compte en semaines. Une rétention de trente jours constitue un point de départ raisonnable en PME, à ajuster selon le volume et le coût du stockage.
Faut-il tester la restauration de tout ?
Non. À vouloir tout tester, on finit par repousser le test. Un périmètre représentatif suffit, choisi parmi ce qui arrêterait l’activité, et il gagne à changer d’une année sur l’autre, pour éviter de toujours revenir au même serveur commode.
Et les automates et postes de terrain ?
Ils restent facilement hors du périmètre, parce qu’ils ne ressemblent pas à des serveurs et que personne ne se sent responsable de leur configuration. Une machine dont le programme n’existe qu’en local s’arrête définitivement le jour où sa carte lâche, sujet développé dans l’article sur la reconstruction après sinistre.