Rançongiciel : 5 raisons pour lesquelles vos sauvegardes ne vous sauveront pas

Vous avez des sauvegardes. Très bien. Mais dans 94 % des attaques par rançongiciel, les criminels tentent d’abord de compromettre ces sauvegardes, et ils y parviennent dans 57 % des cas (rapport Sophos, State of Ransomware). Une sauvegarde que l’attaquant peut atteindre n’est pas un filet de sécurité : c’est une cible.

Et quand la sauvegarde tombe, tout empire. Toujours selon Sophos, lorsque les sauvegardes sont compromises :

le coût de récupération est huit fois plus élevé ;
la rançon exigée double ;
les victimes sont presque deux fois plus susceptibles de payer (67 % contre 36 %).

Voici les cinq raisons pour lesquelles une sauvegarde ne tient pas face à un rançongiciel, et ce qui les corrige.

1. Elle est joignable depuis le réseau de production

Si votre serveur de sauvegarde répond sur le même réseau que vos serveurs, un attaquant qui prend le contrôle du domaine le voit aussi. Il chiffre vos données et vos copies dans le même mouvement. Une sauvegarde protège seulement si elle vit sur un plan isolé, que le réseau de production ne peut pas atteindre en fonctionnement normal.

2. Elle n’est pas immuable

C’est la faille la plus courante et la plus grave. Si un administrateur peut supprimer une sauvegarde, alors un administrateur compromis le peut aussi. Or c’est précisément ce que visent les attaquants : voler des identifiants privilégiés, puis effacer les copies avant de chiffrer.

Une sauvegarde immuable change la donne : pendant une fenêtre définie, elle ne peut être ni modifiée ni supprimée, par personne, même avec les identifiants du compte racine ou la clé d’API. On y revient plus bas, parce que c’est le cœur de la défense.

3. La rétention est trop courte

Un rançongiciel moderne ne frappe pas le jour de l’intrusion. Il dort souvent des semaines dans le réseau, le temps de se propager et de repérer les sauvegardes. Si votre fenêtre d’immuabilité ou votre rétention est plus courte que ce temps de dormance, vos seules copies saines ont déjà été écrasées quand l’attaque se déclenche. La rétention doit couvrir plus large que le temps de dormance observé.

4. Vous ne l’avez jamais restaurée

Certaines sauvegardes contiennent déjà les données chiffrées ou le maliciel dormant, sans que personne ne le sache. La seule façon de le découvrir avant l’incident, c’est de restaurer et démarrer une machine pour de vrai. C’est tout le sujet de notre article Sauvegarde vérifiée : pourquoi tester ses restaurations est devenu incontournable. Une copie jamais testée est une hypothèse, pas une garantie.

5. Les identifiants de la sauvegarde sont ceux du domaine

Si l’on se connecte à la console de sauvegarde avec le même compte Active Directory que le reste du parc, alors compromettre le domaine, c’est compromettre la sauvegarde. La sauvegarde doit avoir sa propre identité : comptes distincts, authentification multifacteur, séparation nette d’avec l’annuaire de production.

L’immuabilité : la seule faille que le rançongiciel ne peut pas exploiter

Retenez un mot : immuable. Techniquement, il s’agit du principe WORM (write once, read many, écrire une fois, lire plusieurs fois) : une fois écrite, la donnée est verrouillée pour une durée choisie. C’est ce que fait l’Object Lock sur le stockage objet.

La différence avec un simple « lecture seule » est capitale. Un droit en lecture seule se retire d’un clic par quiconque a les bons privilèges. L’Object Lock, lui, est appliqué au niveau du stockage : pendant la fenêtre de rétention, aucune commande ne peut supprimer ni réécrire l’objet, même émise par le compte racine ou avec la clé d’API. Le rançongiciel a beau détenir vos identifiants d’administrateur, il se heurte à un mur.

L’immuabilité ne remplace pas les autres protections, elle les couronne. La combinaison gagnante : une copie isolée (raison 1), immuable (raison 2), avec une rétention plus longue que le temps de dormance (raison 3), et testée (raison 4). C’est ce qui transforme une sauvegarde en point de retour garanti.

Ce que ça donne concrètement

C’est exactement l’architecture de notre sauvegarde gérée Proxmox. Vos données partent vers un Proxmox Backup Server infogéré, chiffré et immuable par Object Lock, hébergé au Canada, hors de portée du Cloud Act. La copie est isolée de votre production, la rétention est calée pour résister à un maliciel dormant, et chaque sauvegarde est surveillée, vérifiée et testée par restauration réelle. Le rançongiciel peut chiffrer vos serveurs : il ne peut pas toucher au point sain d’où vous repartez.

Pour aller plus loin quand l’arrêt coûte cher, l’immuabilité se combine à un plan de reprise après sinistre.

Questions fréquentes

Un rançongiciel peut-il vraiment supprimer mes sauvegardes ? Oui, et c’est la norme. Dans 94 % des attaques, les criminels tentent de compromettre les sauvegardes, et ils réussissent une fois sur deux. C’est pour cela que l’immuabilité n’est plus optionnelle.

Immuable, ça veut dire que je ne peux plus jamais rien supprimer ? Non. La donnée est verrouillée seulement pendant la fenêtre de rétention que vous choisissez. Passé ce délai, le cycle normal reprend. Vous gardez le contrôle, l’attaquant non.

Object Lock ou simple lecture seule, quelle différence ? Un droit en lecture seule se retire avec les bons privilèges. L’Object Lock est imposé par le stockage lui-même : pendant la rétention, personne ne peut supprimer l’objet, pas même le compte racine ni la clé d’API.

L’immuabilité suffit-elle à elle seule ? Non. Elle doit s’accompagner de l’isolement réseau, d’une rétention plus longue que le temps de dormance, d’identifiants séparés et de tests de restauration. C’est l’ensemble qui protège.

Vos sauvegardes résisteraient-elles à un rançongiciel ? Découvrez la sauvegarde gérée Proxmox, immuable, isolée et testée, ou créez votre compte pour en discuter et obtenir un prix.