Sauvegarde et rançongiciel : le test de restauration que personne ne fait
Quand avez-vous restauré quelque chose pour de vrai, la dernière fois ? Pas un fichier effacé par erreur : un serveur entier, une base de données, une application avec ses dépendances. Si la réponse est « jamais » ou « je ne sais plus », vous n’avez pas une sauvegarde. Vous avez une hypothèse.
C’est le point que l’on rencontre le plus souvent chez les ETI : les sauvegardes tournent chaque nuit, le tableau de bord est vert, et personne ne sait combien de temps il faudrait pour redémarrer l’entreprise après une attaque. Voici comment on aborde le test de restauration de sauvegarde, et pourquoi il change tout face à un rançongiciel.
Une sauvegarde jamais restaurée, c’est une hypothèse
Un voyant vert dit que la copie s’est terminée. Il ne dit pas qu’elle est lisible, complète, ni qu’on sait la remettre en service. Les mauvaises surprises arrivent toujours au pire moment : un média corrompu, un compte de service oublié, une base qui ne démarre pas parce qu’il manque un autre serveur.
Et à la question « combien de temps pour tout remonter ? », on répond presque toujours à l’oreille. Or c’est ce chiffre qui décide si une attaque coûte une journée ou deux semaines.
Ce que visent les attaquants en premier
Un rançongiciel ne se contente pas de chiffrer vos serveurs. Les groupes organisés cherchent d’abord vos sauvegardes : ils les effacent, les chiffrent ou coupent le service qui les produit, avant de lancer l’attaque visible. Sans copie saine, la rançon devient la seule porte de sortie.
La question utile n’est donc pas « avons-nous des sauvegardes ? » mais « un attaquant qui a pris la main sur notre réseau peut-il les atteindre ? ». Si la réponse est oui, elles ne vous protègent pas de ce scénario. Pour le cadre général, l’ANSSI publie des ressources sur les rançongiciels sur cyber.gouv.fr.
La règle 3-2-1, mise à jour
La règle classique tient en trois chiffres : trois copies de vos données, sur deux supports différents, dont une hors site. Elle reste valable. Face aux rançongiciels, on y ajoute deux exigences, ce qui donne parfois un « 3-2-1-1-0 » :
- Une copie immuable ou hors ligne : impossible à modifier ou à effacer, même avec un compte administrateur volé.
- Zéro erreur après vérification : la copie est contrôlée et restaurée pour de bon, pas seulement archivée.
Le bénéfice se mesure le jour où le réseau est compromis : ce que l’attaquant ne peut pas toucher est ce qui vous remet debout.
L’immutabilité, concrètement
L’immutabilité consiste à verrouiller une copie pour une durée fixée à l’avance. Pendant cette période, personne ne peut la supprimer ni la modifier, pas même l’administrateur. Les stockages objet compatibles S3 proposent ce mécanisme, souvent appelé verrouillage d’objet. C’est une des raisons pour lesquelles on y envoie les sauvegardes Veeam ou Acronis : voir notre page Wasabi et la page Veeam.
Un point souvent oublié : la durée de verrouillage. Trop courte, une attaque discrète qui couve depuis des semaines est sauvegardée avec elle. Trop longue, le stockage coûte pour rien. Elle se fixe avec la durée de rétention dont vous avez réellement besoin.
Le test de restauration, en pratique
Un bon test se fait par niveaux, du plus simple au plus exigeant :
- Fichier : restaurer un document ou un dossier au hasard. Mensuel, c’est rapide.
- Machine virtuelle : remonter un serveur dans un réseau isolé et vérifier qu’il démarre. Trimestriel.
- Application : remonter l’ERP ou la messagerie avec ses bases et ses dépendances, et faire vérifier par un utilisateur que les données sont cohérentes. Deux fois par an.
- Site complet : simuler la perte totale et mesurer le temps réel de remise en service. Une fois par an.
Dans tous les cas, chronométrez. Le résultat qui compte est le temps de restauration mesuré, comparé à ce que l’entreprise peut réellement supporter. C’est souvent là qu’on découvre l’écart : l’activité tolère une demi-journée d’arrêt, la restauration en demande quatre. Mieux vaut le savoir un mardi tranquille qu’en pleine crise.
Notez aussi ce qui a coincé (mot de passe introuvable, ordre de démarrage, licence) et corrigez-le. Un test sans correction ne sert pas à grand-chose.
Ce que nous proposons chez AlphaNumerix
Nous concevons et exploitons des dispositifs de sauvegarde pour des ETI : copies immuables hors site, supervision quotidienne et tests de restauration planifiés, avec un compte rendu chiffré de ce qui a été restauré et en combien de temps. Selon votre contexte, cela s’intègre à notre service de sauvegarde ou à une infogérance plus large. Les briques techniques courantes sont Veeam pour la sauvegarde et Wasabi pour le stockage immuable.
Questions fréquentes
Quelle fréquence pour tester une restauration ?
Un test de fichier chaque mois, une machine virtuelle chaque trimestre, une application critique deux fois par an et un scénario complet une fois par an forment une base raisonnable. Augmentez le rythme après tout changement important d’infrastructure.
Une sauvegarde dans le cloud suffit-elle contre un rançongiciel ?
Non, pas par elle-même. Une copie cloud reste atteignable si les accès sont volés. Il faut qu’elle soit immuable, avec des identifiants séparés de votre annuaire principal.
Qu’est-ce que l’immutabilité d’une sauvegarde ?
Une copie verrouillée pour une durée définie : elle ne peut être ni modifiée ni supprimée pendant cette période, même par un administrateur.
Combien de temps faut-il pour tout restaurer ?
Il n’y a pas de réponse générale : cela dépend du volume, du débit et de l’ordre de redémarrage. C’est justement ce qu’un test chronométré permet de mesurer.
Et chez vous ?
Si vous n’avez pas de temps de restauration mesuré, c’est le bon moment pour en obtenir un. Parlez-en à un ingénieur d’AlphaNumerix : nous regardons votre dispositif actuel et nous vous disons honnêtement ce qui tiendrait le jour J.
À lire aussi : SOC en heures ouvrées ou 24/7, comment choisir.
Un doute sur le bon niveau pour votre entreprise ?
Décrivez votre contexte en quelques lignes : un ingénieur vous répond, sans engagement.
Parler à un ingénieur
