Sauvegardes immuables : pourquoi elles changent tout

01Pourquoi vos sauvegardes actuelles ne suffisent plus

Pendant longtemps, une sauvegarde quotidienne sur un NAS ou un serveur dédié suffisait à se sentir protégé. Ce n'est plus le cas. Les ransomwares modernes suivent un mode opératoire bien rodé : une fois entrés dans le réseau, les attaquants passent plusieurs jours à cartographier le système d'information, à élever leurs privilèges… et à localiser les sauvegardes. Elles sont supprimées ou chiffrées en premier, avant le déclenchement de l'attaque visible.

La raison est simple : une entreprise qui peut restaurer ses données ne paie pas de rançon. Vos sauvegardes sont donc la cible prioritaire. Si elles sont accessibles en écriture depuis le réseau — même avec un mot de passe — elles sont vulnérables.

02Ce qu'est une sauvegarde immuable

Une sauvegarde immuable est une copie de données qui, une fois écrite, ne peut plus être modifiée ni supprimée pendant une durée définie — y compris par un administrateur, y compris par l'éditeur de la solution. C'est le principe du WORM (Write Once, Read Many) : on écrit une fois, on lit autant qu'on veut, on ne réécrit jamais.

Concrètement, cela repose sur des mécanismes comme le verrouillage d'objets sur un stockage compatible S3, des dépôts durcis ou des copies hors ligne. Même si un attaquant obtient les identifiants les plus élevés de votre SI, il ne peut pas détruire ces copies : la protection n'est pas un droit d'accès, c'est une propriété du stockage lui-même.

03La règle 3-2-1-1-0

La bonne pratique de référence étend la règle classique du 3-2-1 :

• 3 copies de vos données au minimum ;
• 2 supports de stockage différents ;
• 1 copie externalisée, hors de votre site ;
• 1 copie immuable ou hors ligne, hors d'atteinte d'un attaquant ;
• 0 erreur lors des tests de restauration.

Le dernier point est le plus souvent négligé. Une sauvegarde qui n'a jamais été restaurée est une hypothèse, pas une protection.

04Tester la restauration, pas la sauvegarde

Le rapport quotidien « sauvegarde réussie » ne dit rien de votre capacité réelle à redémarrer. Les bonnes questions sont ailleurs : combien de temps faut-il pour restaurer un serveur complet ? Dans quel ordre redémarrer les applications ? Qui sait le faire si le prestataire habituel n'est pas disponible ?

Nous recommandons un test de restauration complet au moins deux fois par an, chronométré et documenté. C'est ce délai mesuré — pas le délai espéré — qui doit nourrir votre plan de reprise d'activité.

05Par où commencer

1. Inventorier ce qui est réellement sauvegardé aujourd'hui — et ce qui ne l'est pas (postes, cloud, applications métier).
2. Externaliser une copie chez un hébergeur distinct de votre infrastructure principale.
3. Activer l'immuabilité sur cette copie, avec une durée de rétention adaptée à votre activité.
4. Planifier des tests de restauration réguliers et consigner les résultats.

Pour une PME équipée, ce chantier se mène en quelques semaines. C'est, de loin, l'investissement au meilleur rapport coût-résilience face au ransomware.