L'Active Directory est central dans la résilience des environnements IT
L'annuaire Active Directory est un des éléments critiques, sinon le plus critique des environnements IT. Cela fait de lui une cible de choix pour les cybercriminels à la fois dans une optique de sabotage, mais aussi comme source d'informations et d'autorisations d'accès aux serveurs et aux données.
Les hackers peuvent attaquer l’Active Directory pour diverses raisons et par divers moyens décrits, entre autres, selon le Rapport de Défense Digital 2020 de Microsoft [1]. Selon cette étude, vingt pour cent des comptes utilisateurs Active Directory subissent des tentatives d'attaques quotidiennement.
La collecte d’informations
L’AD contient de nombreuses informations sensibles, d’un point de vue sécurité, accessibles sans autorisations particulières. Il est ainsi possible de collecter, par exemple, la liste des serveurs ayant le protocole RDP activé en étant un simple utilisateur. Ce protocole étant particulièrement vulnérable s’il n’est pas régulièrement patché, l’intrus peut initier une démarche de mouvement latéral à partir de cette liste. La détection en temps réel de telles requêtes d’informations est un premier pas vers l’identification de cyberattaques en cours.
L’obtention d’autorisations
L’AD gère les autorisations d’accès aux serveurs, aux applications et aux données. Un cyberattaquant va donc à un moment où à un autre tenter de modifier l’AD pour s’octroyer des droits. Il existe de nombreuses méthodes pour cela. Le vol d’identifiants via les hashes de mots de passe (Mimikatz …), l’exploitation de vulnérabilités (Zerologon …), le password spraying etc.
Une fois un identifiant à privilèges obtenu, l’attaquant peut se donner des autorisations sur les données critiques de l’entreprise. Le vol de données est quasi systématique dans les attaques de ransomware. La menace de divulguer les données concernées vient appuyer la demande de rançon réclamée en échange de la promesse d’envoi d’une clé de déchiffrement.
L’accès aux autorisations requises peut parfois prendre plusieurs étapes. Les hackers obtiennent des autorisations de plus en plus importantes à chacune de ces étapes et accèdent à de plus en plus de systèmes au fur et à mesure de l’avancement de l’intrusion. Cela implique de nombreuses modifications de l’AD difficiles à identifier.
La détection en temps réel de commandes Mimikatz, entre autres, de tentatives de connexions échouées depuis un même point d’origine, ou encore de modifications de groupes sensibles semble indispensable pour identifier une possible attaque en cours.
Le sabotage
La dernière étape d’une cyberattaque va viser à effacer les traces d’intrusion. Une des méthodes les plus simples pour cela consiste à « détruire » l’Active Directory. Les contrôleurs de domaine vont donc être chiffrés par une charge virale les rendant ainsi inutilisables. Leurs journaux d’audit et de sécurité seront alors inaccessibles. L’Active Directory lui-même ne sera évidemment plus disponible. Il ne sera plus possible de se connecter à distance sur les éventuels serveurs qui auraient échappé au chiffrement faute d’authentification.
Le fait d’exporter en temps réels les journaux des contrôleurs de domaine sur des systèmes indépendants de l’AD permettra des investigations forensiques à posteriori avec l’objectif de « fermer les portes » à des attaques ultérieures utilisant les mêmes moyens. La solution choisie pour cela devra tenir compte du volume de logs considérable que cela peut représenter.
Cependant avant d’investiguer sur ce qu’il s’est passé, il va falloir restaurer l’environnement et notamment l’Active Directory.
Restaurer l’Active Directory
L’architecture distribuée de l’AD et son système de gestion de la réplication rend sa restauration bien plus complexe que la simple restauration des contrôleurs de domaine individuellement (où la restauration d’un « snapshot » de machine virtuelle).
La procédure de restauration préconisée par Microsoft est longue, très complexe. Il est donc indispensable de disposer d’une solution permettant d’automatiser cette procédure de manière sécurisée afin de gagner un temps précieux dans le processus de restauration global.
Le choix de cette solution doit tenir compte de nombreux aspects notamment les différents scénarios de restauration possible en fonction de la situation.
Sauvegarde "bare metal", "system state" ou les deux ?
La réponse est dans la question. Si l’on veut pouvoir restaurer l’Active Directory totalement ou de manière plus granulaire, si l‘on veut pouvoir restaurer les contrôleurs de domaine sur l’infrastructure existante ou sur des machines propres, si l’on veut économiser l’espace de stockage des sauvegardes AD : les deux sont nécessaires.
La sauvegarde "bare metal" est volumineuse, mais permet de restaurer les DC rapidement sans disposer d’une infrastructure de secours.
Néanmoins, la solution choisie doit être capable de vérifier si d’éventuelles charges virales ne pourraient pas avoir été embarquées dans les sauvegardes et invalider pour la restauration celles qui seraient infectées.
L’idéal est de choisir une solution permettant les deux types de sauvegarde et capables de les combiner dans une restauration conjointe. Ainsi il sera possible de programmer des sauvegardes bare metal moins fréquentes que les system state. Ces dernières sont beaucoup moins volumineuses puisqu’elles ne comprennent que la base AD, le contenu du partage Sysvol et quelques autres composants comme la base de registre par exemple.
Le fait de pouvoir restaurer l’infrastructure à partir d’une sauvegarde bare metal datant de quelques jours et de compléter par une restauration system state différentielles utilisant une sauvegarde system state récente réduira drastiquement l’espace de stockage nécessaire et la maintenance associée.
Restauration "bare metal" ou "clean OS" ?
La première permet une restauration complète des contrôleurs de domaine sur l’infrastructure physique ou virtuelle existante. L’idéal est que la solution de restauration soit aussi capable d’effectuer une restauration sur des serveurs physiques ou virtuels différents de ceux d’origine (en injectant des pilotes adaptés dans les sauvegardes par exemple).
La seconde consiste à préparer des serveurs Windows "stand alone" dans la même version que les contrôleurs de domaine. Ces serveurs serviront de support pour la restauration de l’Active Directory et deviendront les contrôleurs de domaine de l’AD restauré.
Chacune de ces méthodes a des avantages et des inconvénients. La première est rapide et permet de réutiliser les serveurs existants, la seconde garantit que les contrôleurs de domaine seront exempts de tout malware, mais nécessite la préparation et le maintenance (notamment dans le suivi des évolutions de versions) de serveurs qui serviront de base de restauration.
L’idéal est, bien entendu, de disposer d’une solution de restauration AD capable de gérer les deux méthodes afin de pouvoir gérer toutes les situations y compris les plus catastrophiques.
Restauration totale ou granulaire de l’Active Directory ?
Les besoins de restauration de l’Active Directory ne sont pas systématiquement liés à une reprise complète. Il est beaucoup plus fréquent de devoir restaurer des objets, des GPO ou des parties de l’arborescence AD qui auraient été modifiés ou supprimés par mégarde ou par malveillance. La corbeille Active Directory permet de restaurer des objets supprimés, mais uniquement provenant des partitions de domaine. De plus elle ne permet pas de restaurer simplement des ensembles d’objets ou des arborescences entières. Enfin elle n’est d’aucune utilité dans le cas d’objets non pas supprimés, mais modifiés.
La solution de restauration AD choisie doit impérativement gérer la restauration granulaire des objets d’annuaire, des objets de configuration, des partitions DNS ou encore des GPO. Elle doit effectuer une réelle restauration et pas une reconstruction des objets de façon à conserver les attributs principaux (SID, GUID, SIDHistory, password etc…) ainsi que les attributs éventuellement synchronisés par l’Azure AD Connect.
De plus les restaurations granulaires doivent souvent être réalisées en urgence durant des périodes d’astreintes. Il serait donc intéressant que la solution de restauration permette de déléguer les droits de restauration granulaire à des personnes n’ayant pas de droit d’administration complets de l’AD tout en fournissant les interfaces adaptées pour utiliser ces délégations.
Avec ou sans Agents ?
À première vue, le fait de ne pas déployer d’agents sur les contrôleurs de domaine est séduisant. Cependant, l’absence d’agent entraine de nombreuses contraintes et limitations dues aux sécurités et au mode de fonctionnement de l’Active Directory. En effet, certaines APIs de sauvegarde ne sont pas accessibles à distance. Si l’on souhaite minimiser l’empreinte sur les DC, certaines solutions de restauration de l’AD installent automatiquement un agent pour réaliser la sauvegarde et le désinstallent ensuite, toujours automatiquement.
Dans le cadre d’une corruption Active Directory, ce dernier peut être totalement inopérant. Il est alors impossible de s’authentifier pour communiquer à distance avec les contrôleurs de domaine.
Pour pallier ce problème et permettre un pilotage centralisé de la procédure de restauration complète de l’AD, certaines solutions déploient des agents non actifs sur les DC. Ces agents permettent une communication réseau entre un point central et les DC sécurisée par des certificats et n’utilisant pas l’authentification AD.
Réinitialisation des mots de passe
Dans le cas d’une restauration suite à une cyberattaque, il est prudent de supposer que les hackers ont accès aux mots de passe de certains comptes membres de groupes à privilèges. Les restaurer en l’état donnerait donc aux cybercriminels l’opportunité de reprendre la main sur l’AD. La meilleure solution consiste à réinitialiser les mots de passe de l’ensemble des comptes membres de groupes à hauts privilèges pendant le processus de restauration et non une fois ce dernier terminé. Certaines solutions de restauration AD proposent ce genre de possibilités.
Supervision des sauvegardes
Évidemment comme pour les solutions de sauvegarde des données, la solution choisie pour restaurer l’AD doit être capable d’alerter les personnes responsables en cas de dysfonctionnement d’un ou plusieurs des processus de sauvegarde ou en cas de problème avec un de ses agents préinstallés.
La maintenance et la mise à jour de ces agents doit être le plus simple possible pour des raisons évidentes de charge de travail et de simplification de la procédure de restauration.
Du fait de la potentielle distribution géographique des contrôleurs de domaine, les sauvegardes de chacun d’entre eux devront être stockées à proximité, mais indépendamment de l’AD pour éviter une perte d’accès si l’authentification AD venait à être corrompue. La solution choisie devra donc pouvoir être paramétrée pour stocker les sauvegardes non pas sur un point central, mais sur des emplacements de stockage ayant globalement la même répartition que les DC eux-mêmes.
Comme nous avons pu le voir, il existe de nombreuses situations entrainant la nécessité de restaurer l’Active Directory. La capacité à le restaurer le plus rapidement et simplement possible est cruciale pour la résilience de l’environnement IT dans son ensemble, Cloud inclus puisque l’AD reste la base de synchronisation d’Azure AD pour Office 365.
Le choix d’une solution technique de sauvegarde et restauration de l’Active Directory doit tenir comptes de nombreuses problématiques et caractéristiques spécifiques à la structure même de l’AD. Étant donné la recrudescence des cyberattaques depuis le début de l’année, l’implémentation d’une telle solution devrait être réalisée avant qu’il ne soit trop tard.