Vitesse de reprise après ransomware : en combien de temps pouvez-vous vraiment restaurer ?

4

La plupart des plans de reprise après ransomware sont rédigés comme des plans de protection. Ils précisent où arrivent les sauvegardes, combien de temps elles sont conservées et quel verrou de rétention est appliqué. Ils sont relus, approuvés et archivés. Puis un incident survient, et la question que personne n’avait écrite se révèle la seule qui compte : combien d’heures avant que l’activité reprenne ?

Protection et reprise ne sont pas la même discipline. La protection est une propriété du chemin d’écriture : elle se configure une fois et se vérifie par inspection. La reprise est une propriété du chemin de lecture sous charge, et elle ne se vérifie qu’en la pratiquant. Une architecture peut être irréprochable sur le premier point et non éprouvée sur le second, et c’est la situation que découvrent de nombreuses organisations le pire jour possible.

Ce guide porte sur ce second volet. Il explique comment exprimer la vitesse de reprise sous forme d’un chiffre défendable, pourquoi le stockage objet change le calcul, et quelles sont les quatre propriétés d’architecture (immuabilité, isolation, parallélisme et validation) qui déterminent si ce chiffre est réel.

Qu’est-ce que la reprise après ransomware ?

La reprise après ransomware désigne l’ensemble des processus et technologies utilisés pour restaurer les données et reprendre l’activité après un incident de ransomware, sans dépendre de l’attaquant. Elle se distingue d’une restauration de sauvegarde ordinaire sur un point : l’infrastructure de reprise elle-même est considérée comme une cible.

Cette hypothèse change les exigences. Un plan opérationnel doit garantir :

• Une restauration à un instant donné : des points de restauration cohérents, pas seulement des fichiers récupérables
• Une protection immuable : des copies de sauvegarde qui ne peuvent être ni modifiées ni supprimées, y compris par un administrateur
• L’isolation : un chemin de restauration qui ne dépend pas du plan de contrôle compromis
• Un débit de restauration à grande échelle : mesuré en charges de travail restaurées, et non en gigaoctets par seconde
• La validation : la preuve, produite de manière planifiée, que les points de restauration se restaurent réellement

Payer une rançon ne remplace aucun de ces éléments. Les outils de déchiffrement fournis par les attaquants sont souvent lents, partiels ou défectueux, et ils ne font rien pour les systèmes qui ont été supprimés plutôt que chiffrés. Restaurer à partir de copies fiables est la seule voie qui mène à une issue.

Mesurer la reprise en charges de travail par heure, et non en gigaoctets par seconde

Les chiffres de débit sont la monnaie courante des achats de stockage, et ils sont presque inutiles pour planifier une reprise. Un référentiel qui soutient 10 Go/s dans un test séquentiel ne dit rien du temps nécessaire pour remettre en ligne 400 machines virtuelles, car cette opération est limitée par la concurrence, les opérations sur les métadonnées et la planification propre de l’application de sauvegarde bien avant d’être limitée par la bande passante brute.

L’indicateur qui parle à l’activité est le nombre de charges de travail restaurées par heure, généralement exprimé en VM par heure. C’est le seul chiffre qui se convertit directement en objectif de temps de reprise, et c’est celui sur lequel un dirigeant peut agir.

Un modèle à appliquer à votre propre environnement

Le calcul est assez simple pour être fait au tableau blanc, et le faire est plus instructif que la plupart des benchmarks des fournisseurs. Prenons un environnement de 400 VM d’une taille moyenne de 200 Go chacune, soit 80 To à restaurer.

Flux de restauration simultanés	Débit agrégé effectif	VM par heure	Temps de restauration de 400 VM
4	0,8 Go/s	~14	~28 heures
16	3,2 Go/s	~58	~7 heures
64	12,8 Go/s	~230	~1,7 heure

Trois enseignements en découlent. Premièrement, la différence entre une reprise en deux heures et une reprise en deux jours tient à la concurrence, et non à la bande passante : le débit par flux est identique dans les trois lignes. Deuxièmement, aucun environnement réel ne monte en charge de manière linéaire jusqu’à 64 flux ; quelque chose sature d’abord, et identifier ce qui sature constitue le véritable exercice de planification. Troisièmement, si vous ne pouvez pas exprimer votre propre chiffre sous cette forme, vous n’avez pas d’objectif de temps de reprise. Vous avez une aspiration.

C’est aussi là que la distinction entre RTO et RPO cesse d’être théorique. L’objectif de point de reprise dépend de la fréquence des sauvegardes et il est généralement bien maîtrisé. L’objectif de temps de reprise dépend de la concurrence des restaurations et il n’est généralement pas mesuré du tout. Pour les définitions, voir RTO ou RPO : les différences clés expliquées.

Pourquoi le stockage objet change le calcul de la restauration

Le stockage objet s’est imposé dans les architectures de sauvegarde parce qu’il fait évoluer la capacité à moindre coût. Sa pertinence pour la reprise après ransomware est différente et plus précise : c’est un espace de noms plat, parallèle par défaut, avec une rétention applicable, ce qui correspond presque exactement aux besoins d’une restauration massive.

Le parallélisme est une propriété d’architecture, pas un paramètre de réglage

Un système de fichiers hiérarchique se sérialise sur les métadonnées des répertoires. Chaque flux de restauration entre en concurrence pour les mêmes structures d’espace de noms, et la contention s’aggrave à mesure que la concurrence augmente, ce qui est exactement l’inverse de ce qu’exige une reprise massive. Un espace de noms plat de type S3 n’a pas d’arborescence de répertoires à verrouiller. Les flux de restauration sont indépendants par construction : ajouter des flux ajoute du débit, jusqu’à ce que le réseau ou l’application de sauvegarde devienne la contrainte.

C’est le mécanisme qui sous-tend le tableau ci-dessus. Passer de la première à la troisième ligne n’est pas une question d’achat de disques plus rapides. C’est une question de capacité du référentiel à absorber 64 lecteurs simultanés sans que l’espace de noms devienne le goulot d’étranglement. Pour en savoir plus sur ce comportement, voir le débit du stockage objet et les opérations de résilience en entreprise.

Une immuabilité qui résiste à un administrateur compromis

La plupart des échecs de reprise ne sont pas des reprises lentes. Ce sont des reprises impossibles : des sauvegardes supprimées, chiffrées sur place ou dont la rétention a été discrètement raccourcie des semaines avant le chiffrement.

Le stockage objet y répond par une rétention appliquée au niveau du stockage plutôt qu’au niveau applicatif. S3 Object Lock met en œuvre une sémantique write-once-read-many : pendant la période de rétention, un objet ne peut être ni modifié ni supprimé par aucun identifiant, y compris root. La distinction qui compte sur le plan opérationnel se situe entre le mode gouvernance, qu’une identité suffisamment privilégiée peut contourner, et le mode conformité, que personne ne peut contourner.

Le mode de défaillance à anticiper n’est pas « nous avons oublié d’activer l’immuabilité ». C’est « l’immuabilité était activée dans un mode que les identifiants volés de l’attaquant pouvaient désactiver ». Nous avons détaillé ces mécanismes dans la véritable immuabilité avec le stockage objet S3.

La rétention doit dépasser votre délai de détection

La durée de rétention est généralement fixée d’après une exigence de conformité. Pour les ransomwares, elle doit être fixée d’après le temps de présence de l’attaquant (dwell time), l’intervalle entre la compromission initiale et sa détection, qui atteint couramment plusieurs semaines. Si la rétention est de 14 jours et que l’attaquant était présent depuis 30 jours, chaque copie immuable dont vous disposez est peut-être déjà contaminée. L’immuabilité a parfaitement préservé le mauvais état.

Fixez la rétention en fonction du délai de détection que vous observez réellement, et non de celui que vous préféreriez. Le même raisonnement s’applique plus généralement aux compromissions lentes : voir la reprise après une attaque zero-day.

L’isolation des copies saines : séparer le chemin de reprise du chemin d’attaque

L’immuabilité protège les octets. Elle ne fait rien pour le chemin qui permet d’y accéder.

L’isolation des copies saines consiste à garder au moins une copie de reprise accessible par un chemin qui ne partage ni identité, ni réseau, ni plan de contrôle avec la production. Le test est simple : si le domaine est compromis et que chaque identifiant de production est considéré comme hostile, pouvez-vous encore monter et lire une sauvegarde ? Dans un grand nombre d’architectures, la réponse honnête est non, car le catalogue de sauvegarde, les identifiants du référentiel et la console de restauration s’authentifient tous auprès du même annuaire, désormais contrôlé par l’attaquant.

L’isolation se construit en couches, et ces couches sont indépendantes :

• Isolation des identités : des identifiants de reprise émis par un fournisseur d’identité distinct, et non par l’annuaire de production
• Isolation réseau : un air gap logique entre la production et le référentiel, ce dernier restant inaccessible depuis un segment de production compromis
• Isolation du plan de contrôle : une politique de rétention administrée depuis un endroit inaccessible au serveur de sauvegarde
• Confinement du rayon d’impact : aucune identité compromise ne peut affecter à elle seule toutes les copies, ce qui revient à appliquer la notion de domaine de défaillance aux privilèges d’administration plutôt qu’au matériel

Une règle de conception utile : partez du principe que tous les identifiants sont compromis, puis demandez-vous quelles copies survivent et quels chemins de restauration fonctionnent encore. Tout ce qui échoue à ce test relève du théâtre de la protection.

La restauration en salle blanche : où vont les données restaurées

Restaurer une VM compromise dans un réseau compromis la réinfecte. Ce n’est pas une hypothèse : c’est l’une des façons les plus courantes dont une tentative de reprise échoue au premier essai et coûte une journée.

Une salle blanche (clean room) est un environnement isolé (segment réseau distinct, identité distincte, aucun chemin de retour vers la production) dans lequel les charges de travail restaurées sont démarrées, analysées et validées avant d’être remises en service. Elle offre un lieu pour répondre à la question qui détermine toute la chronologie de la reprise : quel est le dernier point de restauration sain connu ?

Sans salle blanche, trouver ce point de restauration implique de restaurer des candidats en production et d’observer ce qui se passe. C’est à la fois lent et dangereux. Avec une salle blanche, la recherche devient une activité parallèle en arrière-plan, menée pendant que le reste de la reprise se poursuit. Notez que cela change l’exigence de débit : une salle blanche implique de restaurer les mêmes données plusieurs fois, et le référentiel doit l’absorber sans ralentir la reprise principale.

Les tests de restauration : la seule preuve que tout cela fonctionne

La réussite d’une tâche de sauvegarde est un signal du chemin d’écriture. Elle confirme que des octets ont été transférés. Elle ne dit rien de la capacité de ces octets à constituer un système démarrable et cohérent au niveau applicatif, et un tableau de bord vert rempli de tâches réussies est parfaitement compatible avec un référentiel incapable de restaurer quoi que ce soit.

Les tests de restauration comblent cet écart, et ils doivent être gradués, car les tests les moins coûteux ne prouvent pas grand-chose :

• Vérification au niveau des objets : sommes de contrôle et état de rétention. En continu, à faible coût, cela prouve que les données sont intactes.
• Restauration d’une charge de travail : une VM restaurée et démarrée. Chaque semaine. Cela prouve que la chaîne fonctionne de bout en bout.
• Restauration cohérente au niveau applicatif : une base de données restaurée et interrogée. Chaque mois. Cela prouve la cohérence à un instant donné, et pas seulement la récupération de fichiers.
• Restauration parallèle massive : des dizaines de charges de travail à la fois, chronométrées. Chaque trimestre. C’est le seul test qui produit un chiffre de VM par heure défendable.
• Reprise isolée complète : un environnement reconstruit en salle blanche à partir des seules copies isolées et d’identifiants hors bande. Chaque année. Cela prouve que l’isolation est réelle.

La plupart des organisations réalisent les deux premiers tests et se considèrent comme testées. C’est sur les deux derniers que les architectures échouent, et c’est précisément pour cela qu’on les saute : ils sont perturbateurs et produisent des chiffres dérangeants. Ces chiffres sont le livrable.

Les niveaux de sauvegarde et là où se joue réellement la vitesse de reprise

Les architectures de sauvegarde sont couramment hiérarchisées : un niveau de performance pour les points de restauration récents, un niveau de capacité pour une évolutivité économique et un niveau long terme pour la rétention et la conformité.

Longtemps, on a considéré que le stockage objet n’avait sa place qu’aux deuxième et troisième niveaux. Cette hypothèse est dépassée : les éditeurs de sauvegarde valident désormais le stockage objet au niveau de performance, y compris pour la restauration instantanée, où une charge de travail est montée et exécutée directement depuis la sauvegarde pendant que la restauration complète se poursuit en arrière-plan.

La conséquence, pour les ransomwares en particulier, est que les deux exigences cessent d’être concurrentes. Il faut un accès rapide aux points de restauration récents pour tenir un RTO ambitieux, et une longue rétention immuable pour résister à un long délai de détection. Lorsque le stockage objet couvre les trois niveaux, les deux découlent d’une seule architecture plutôt que de deux. L’architecture de cible de sauvegarde évolutive explique comment elle s’organise généralement, et la définition de la cible de sauvegarde précise la terminologie.

Liste de contrôle de préparation à la reprise après ransomware

Immuabilité

• Rétention appliquée au niveau du stockage, et non par l’application de sauvegarde
• Mode conformité lorsque la copie doit résister à un administrateur compromis
• Durée de rétention fixée en fonction du délai de détection observé, et non du minimum de conformité
• Modifications de rétention journalisées et signalées par des alertes, et pas seulement réservées aux rôles à privilèges

Isolation

• Au moins une copie accessible sans identité de production
• Référentiel inaccessible depuis un segment de production compromis
• Politique de rétention administrée hors de portée du serveur de sauvegarde
• Aucune identité unique ayant autorité sur toutes les copies

Vitesse de reprise

• Un chiffre de VM par heure issu d’un test chronométré, et non d’une fiche technique de fournisseur
• Un plafond de concurrence connu, et sa cause identifiée
• Un ordre de restauration défini selon les dépendances métier, et non par ordre alphabétique
• La restauration instantanée validée si le RTO en dépend

Validation

• Des tests de restauration gradués sur les cinq niveaux, de manière planifiée
• Un environnement de salle blanche qui existe avant d’en avoir besoin
• Une méthode documentée pour identifier le dernier point de restauration sain connu
• Des procédures rédigées pour être exécutées par quelqu’un qui n’a pas conçu le système

Questions fréquentes

Quelle doit être la vitesse d’une reprise après ransomware ?

Il n’existe pas d’objectif universel : la question utile est de savoir si votre temps de reprise mesuré est plus court que l’interruption que votre activité peut absorber. Exprimez-le en charges de travail restaurées par heure, déduisez-en le total à partir de votre nombre réel de charges de travail, et comparez-le à la tolérance déclarée par l’activité. Si ces deux chiffres n’ont jamais été mis côte à côte, c’est la première tâche.

Le stockage immuable garantit-il la reprise après ransomware ?

Non. L’immuabilité garantit qu’une copie existe dans l’état où elle a été écrite. Elle ne garantit pas que cet état était sain, que vous pouvez accéder à la copie sans identifiants de production, ni que vous pouvez restaurer assez vite pour que cela serve. C’est une condition nécessaire, pas suffisante.

Pourquoi le stockage objet est-il plus rapide pour les restaurations à grande échelle ?

Parce qu’un espace de noms plat n’a pas de métadonnées de répertoires sur lesquelles se sérialiser. Les flux de restauration fonctionnent indépendamment, de sorte que le débit augmente avec la concurrence au lieu de se dégrader. Lors d’une reprise massive, portant sur des centaines ou des milliers de charges de travail à la fois, la concurrence est le facteur dominant de l’équation du temps de reprise.

Qu’est-ce que l’isolation des copies saines ?

C’est le fait de garder au moins une copie de reprise accessible par un chemin qui ne partage ni identité, ni réseau, ni plan de contrôle avec la production. Le test consiste à savoir si vous pourriez encore monter et lire une sauvegarde en partant du principe que tous les identifiants de production sont entre des mains hostiles.

À quelle fréquence faut-il tester les restaurations ?

De manière graduée, selon le coût et la perturbation : vérification des objets en continu, restaurations d’une charge de travail chaque semaine, restaurations cohérentes au niveau applicatif chaque mois, restaurations parallèles massives chronométrées chaque trimestre et reprise isolée complète chaque année. Le test trimestriel est celui qui produit un chiffre de VM par heure défendable.

La reprise est une opération, pas une configuration

Les architectures qui se rétablissent bien ne se distinguent pas par le nombre de fonctions de protection activées. Elles se distinguent parce qu’elles ont mesuré quelque chose. Elles connaissent leur chiffre de VM par heure parce qu’elles l’ont chronométré. Elles savent que leur isolation tient parce qu’elles l’ont testée en supposant les identifiants de production perdus. Elles savent quel point de restauration est sain parce qu’elles ont construit un lieu pour le découvrir.

Immuabilité, isolation, parallélisme et validation sont quatre propriétés indépendantes, et une lacune dans l’une d’elles rend les trois autres quasiment décoratives. Le stockage objet est un bon socle parce qu’il offre une rétention applicable et une restauration parallèle dans le même système, mais le socle n’est pas le résultat. Le résultat est un chiffre que vous pouvez annoncer à voix haute.

Si vous ne pouvez pas annoncer le vôtre aujourd’hui, c’est cela, le constat. Tout le reste découle de sa correction.

---

Scality conçoit un stockage objet S3 cyber-résilient pensé pour la reprise à grande échelle. Découvrez l’architecture ou parcourez le glossaire pour les termes utilisés dans ce guide.