Les attaques de ransomware et de wiper incitent les entreprises à réévaluer leurs capacités de sauvegarde et de restauration. Une préoccupation évidente est de savoir si les sauvegardes sont sûres - par exemple, si elles sont hors ligne et ne peuvent pas être chiffrées ou effacées.
Bien qu'il s'agisse d'une bonne première étape, ce n'est que cela. Nous devons également évaluer si les technologies de sauvegarde et de récupération que nous utilisons prennent en charge la récupération en cas de cyberattaque. C'est particulièrement important si la récupération sur métal nu (BMR) fait partie de votre plan de reprise d'activité.
Un nouveau sentiment d'urgence
En tant que responsable des produits chez Semperis, je discute avec de nombreux DSI et RSSI de la reprise après sinistre (DR) pour Microsoft Active Directory (AD). L'attention portée à la reprise d'AD est bien méritée étant donné le rôle critique d'AD (si AD n'est pas disponible, rien ne l'est) et le processus de reprise spécialisé (combien de vos collègues ont réellement effectué une reprise complète d'une forêt ?)
Au cours de l'année écoulée, j'ai constaté un nouveau sentiment d'urgence concernant la restauration d'AD. Il ne s'agit plus d'annuler une mise à niveau au niveau de la forêt ou un changement de schéma. Il s'agit maintenant de récupérer AD lorsqu'une cyberattaque destructrice et rapide (comme NotPetya ou LockerGoga) détruit tous vos contrôleurs de domaine (DC).
C'était avant, c'est maintenant
Le BMR a toujours été un moyen pratique de récupérer un serveur entier. Par exemple, l'équipe DR pouvait effectuer la restauration seule, sans dépendre de l'équipe de provisionnement des serveurs. Mais dans le nouveau paysage des menaces, la plus grande force de la BMR (récupération de tout le système d'exploitation) est devenue sa plus grande faiblesse (réintroduction potentielle de logiciels malveillants).
Le BMR montre également qu'il a pris de l'âge. Il a été conçu pour des ordinateurs physiques, à l'époque où de nombreux services informatiques avaient besoin de plusieurs jours, voire plusieurs semaines, pour approvisionner un serveur. Mais la virtualisation a changé la donne.
De plus, le BMR a été construit avant l'avènement de l'informatique en nuage et de l'infrastructure en tant que service (IaaS), qui constituent une alternative peu coûteuse et facilement accessible au matériel de secours.
Si votre plan de reprise AD actuel repose sur BMR - ou si vous envisagez de nouvelles capacités de reprise automatisée qui reposent sur BMR (pour récupérer les DC lorsque le matériel ou le système d'exploitation est affecté) - voici quelques éléments à prendre en compte.
Réinfection
BMR sauvegarde et restaure tout ce qui se trouve sur le DC, y compris le système d'exploitation (OS), le registre, les fichiers système, etc. Ce n'est pas une mauvaise chose si un incendie ou une inondation détruit vos DC et que vous devez restaurer AD sur du nouveau matériel. Mais c'est une très mauvaise chose si vos DC sont touchés par une cyberattaque.
Lorsqu'un intrus installe des rootkits, des ransomwares ou d'autres logiciels malveillants sur vos DC, tous ces exécutables et DLL sont inclus dans les sauvegardes BMR. Lorsque vous effectuez une restauration BMR, les logiciels malveillants dont vous ne voulez pas sont restaurés avec le système d'exploitation, le registre, la base de données AD et toutes les autres choses dont vous avez besoin. (Notez que les logiciels malveillants peuvent également être réintroduits lors de la restauration à partir de sauvegardes de l'état du système).
Voici une démonstration qui illustre le risque de réinfection par le BMR :
Dans certains cas, il est possible d'identifier et de supprimer les logiciels malveillants après la restauration. Personnellement, cette approche ne me convient pas et je ne l'envisagerais qu'en dernier recours (lorsqu'aucune autre option de restauration n'est disponible). Je ne recommande certainement pas de concevoir votre plan de restauration AD en fonction de cette approche.
Perte de données
Si des DC sont infectés au moment où les sauvegardes BMR sont effectuées - ou si vous soupçonnez qu'ils l'ont été - l'approche traditionnelle consiste à revenir à une sauvegarde antérieure. Mais jusqu'où remonter ? Les logiciels malveillants peuvent rester latents et ne pas être détectés pendant des semaines, voire des mois.
Bien entendu, plus vous remontez dans le temps, plus vous perdez de données. Vous pouvez effectuer des sauvegardes quotidiennes pour un RPO (objectif de point de récupération) de 24 heures, mais si vous devez remonter deux mois en arrière pour obtenir une bonne sauvegarde, vous ne respecterez pas cet accord de niveau de service. Et compte tenu du nombre de modifications de répertoire effectuées chaque jour, la perte de données s'accumule.
Interruptions prolongées
Chaque minute de temps d'arrêt coûte de l'argent à votre organisation. Cependant, la BMR prolonge le temps de récupération de plusieurs façons :
Installation matérielle: Le BMR est conçu pour être restauré sur du matériel correspondant. A moins que vous ne puissiez vous permettre de dupliquer le matériel de secours, vous aurez besoin d'au moins un jour ou deux pour vous procurer du nouveau matériel. Ce délai est en dehors du RTO (Recovery Time Objective) typique pour les infrastructures critiques (comme AD) et les applications de niveau 1. Et si une cyberattaque frappe de nombreuses organisations et entraîne une pénurie de matériel, l'approvisionnement peut prendre beaucoup plus de temps. Il est possible de trouver des solutions de rechange pour restaurer le matériel (comme l'injection de pilotes), mais elles prennent du temps et présentent des risques supplémentaires.
Récupération des sauvegardes: Parce qu'elles contiennent l'ensemble du système, les sauvegardes BMR sont volumineuses. Je le savais par expérience, mais je voulais le quantifier, alors j'ai effectué un test simple dans mon laboratoire en utilisant un DC Windows Server 2016 "vanille" avec essentiellement un AD vide (pour déterminer la surcharge associée à différentes méthodes de sauvegarde). J'ai utilisé Windows Server Backup pour effectuer une sauvegarde BMR (ainsi qu'une sauvegarde de l'état du système), et j'ai utilisé Semperis AD Forest Recovery pour effectuer une sauvegarde Semperis (qui extrait AD du système d'exploitation Windows sous-jacent). Voici les résultats (non compressés) :
Les sauvegardes plus importantes consomment plus de stockage et de bande passante et ont tendance à être moins fréquentes (par exemple, une fois par semaine ou après le mardi des correctifs). En outre, lors de la restauration, il faut plus de temps pour les récupérer (surtout lorsqu'elles sont stockées dans le nuage).
Sélection des sauvegardes : La recherche d'une sauvegarde BMR propre est un processus itératif (récupérer, monter, extraire, tester, répéter) qui prend du temps alors que chaque minute est chère.
Remaniement: La restauration d'AD à partir d'une ancienne sauvegarde BMR (que l'on espère propre) nécessite de recréer les changements de répertoires, de reconfigurer les applications, de réintégrer les postes de travail, etc. - et tout ce travail prend beaucoup de temps et d'efforts.
Faux rétablissement: Le BMR comporte un degré élevé d'incertitude - les DC ont-ils été infectés, quand l'ont-ils été, jusqu'où dois-je remonter ? Il se peut que vous ne découvriez pas que vous n'êtes pas remonté assez loin dans le temps avant d'avoir terminé ou d'avoir bien avancé dans le processus de restauration AD. La restauration d'AD n'est pas une tâche simple, et il est particulièrement pénible de recommencer à zéro.
Conclusion
Les temps changent et nos plans de secours doivent aussi changer. Les cyberattaques constituent un danger clair et présent qui ne peut être ignoré. Si le BMR peut répondre à certains scénarios de reprise, la reprise AD après une cyberattaque n'en fait pas partie.
