La règle 3-2-1 est connue de tous les administrateurs : trois copies des données, sur deux supports différents, dont une hors du site. Elle protège bien contre la panne d'un disque, l'incendie d'une salle ou l'erreur humaine. Face à un rançongiciel, elle ne suffit plus.
Les attaquants ciblent d'abord les sauvegardes
Un rançongiciel moderne ne se contente pas de chiffrer les fichiers. Les attaquants passent souvent plusieurs jours dans le réseau, récupèrent des identifiants d'administration, puis suppriment ou chiffrent les sauvegardes avant de déclencher l'attaque. Si votre serveur de sauvegarde est joint au même annuaire que vos serveurs, et que ses dépôts sont accessibles avec les mêmes comptes, vos trois copies peuvent disparaître en quelques minutes.
Passer au 3-2-1-1-0
La règle a donc évolué. Aux trois copies, deux supports et une copie hors site s'ajoutent :
- 1 copie immuable ou hors ligne : une copie que personne ne peut modifier ni supprimer pendant sa durée de rétention, pas même un administrateur. Par exemple un stockage objet avec verrouillage des objets (Object Lock), ou un support physiquement déconnecté (disque externe en rotation, bande).
- 0 erreur à la restauration : chaque sauvegarde est vérifiée, et des restaurations sont testées régulièrement.
Isoler la sauvegarde du reste du système d'information
L'immuabilité ne sert à rien si l'attaquant peut prendre le contrôle de la console de sauvegarde. Quelques mesures simples réduisent fortement le risque :
- Des comptes dédiés à la sauvegarde, qui ne servent à rien d'autre, avec une double authentification.
- Un serveur de sauvegarde hors de l'annuaire principal (Active Directory ou LDAP), dans un réseau séparé, joignable uniquement depuis les postes d'administration.
- Des droits limités pour les serveurs sauvegardés : ils peuvent écrire de nouvelles sauvegardes, pas supprimer les anciennes.
- Des alertes sur les suppressions massives et sur l'échec des tâches de sauvegarde.
Définir le RPO et le RTO, puis les vérifier
Deux chiffres doivent guider votre stratégie. Le RPO (perte de données maximale admissible) fixe la fréquence des sauvegardes : une base de données de facturation ne se sauvegarde pas comme un partage de fichiers. Le RTO (durée maximale d'interruption) fixe la façon de restaurer : restaurer dix téraoctets depuis un site distant peut prendre des jours si le lien est lent.
Ces objectifs n'ont de valeur que s'ils sont testés. Planifiez au moins un exercice de restauration complète par trimestre sur une application réelle, chronométrez-le, et comparez le résultat au RTO promis aux métiers.
Une liste de contrôle pour commencer
- Avez-vous au moins une copie qu'un administrateur ne peut pas supprimer ?
- Le serveur de sauvegarde utilise-t-il des comptes distincts de ceux du domaine ?
- Quand avez-vous restauré une application complète pour la dernière fois ?
- Le RPO et le RTO de vos applications critiques sont-ils écrits et validés par les métiers ?
- Qui est alerté si une sauvegarde échoue trois nuits de suite ?
Si une de ces questions reste sans réponse, c'est par elle qu'il faut commencer. La sauvegarde est la dernière ligne de défense : elle mérite la même attention que le pare-feu.