Votre entreprise est actuellement en proie à une crise ransomware conséquente. Comme dans 100% des crises de cette nature, les cybercriminels ont compromis l’Active Directory, en raison de son rôle central dans la gestion des accès, de l’authentification et des ressources réseau au sein de toute organisation.

Si les attaquants ont déclenché la charge malveillante, vos systèmes sont maintenant chiffrés. Ils peuvent sinon être isolés et hors ligne. Dans les deux cas, votre entreprise ne dispose plus des ressources nécessaires pour fonctionner correctement, et votre activité est alors à l’arrêt ou très fortement ralentie !

Dans cette situation, la confiance en votre système d’information est rompue. Vos équipes commencent à subir une pression des métiers et une question revient sans cesse : quand pourront-nous rouvrir nos services ? Votre objectif devient donc clair, il faut impérativement remettre sur pied l’Active Directory avec un niveau de confiance suffisant pour rouvrir les services.

La reconstruction d’un Active Directory est une étape complexe de la gestion d’une crise. Si elle est mal exécutée, votre organisation s’expose à deux risques majeurs : l’amplification des impacts opérationnels pour les métiers, ou une nouvelle compromission de votre environnement.

L’ANSSI vient de publier 3 guides très complets à ce sujet [1], et nous vous en conseillons la lecture.

Dans cet article nous allons revenir sur quelques points qui nous ont marqué lors de la gestion de crise. Durant leurs interventions, nos équipes ont en effet pu se confronter à de nombreux obstacles. Quels sont les principaux problèmes rencontrés ? Comment y remédier ?

De la compromission à la remise en service : les conseils pour surmonter les obstacles

Démarrez efficacement la remédiation grâce à une organisation éprouvée

La perte de temps due à une mauvaise organisation au moment de la crise peut aggraver les conséquences de la compromission d’Active Directory. Les équipes sont souvent incertaines quant à la marche à suivre, les personnes à mobiliser et les objectifs à atteindre. Une réponse ralentie augmentera les coûts associés à la remédiation, les pertes de revenus ainsi que les impacts sur la réputation de l’entreprise.

En amont de la crise…

Il est nécessaire d’identifier l’ensemble des acteurs clés à impliquer dans la reconstruction de l’Active Directory :

• Le comité exécutif pour arbitrer les questions structurantes. Par exemple, priorise-t-on une réouverture rapide des services critiques pour des questions business, ou plus lente et plus sécurisée ? Plusieurs postures sont possibles et présentent chacune leurs avantages et inconvénients [1 – Volet stratégique]. L’ensemble du plan de remédiation étant construit à partir de cette décision, il est nécessaire que le comité exécutif puisse trancher pour commencer les travaux rapidement.
• Les équipes métier pour identifier et prioriser le rétablissement des services les plus critiques. La compromission de l’Active Directory impacte la majorité des services de l’entreprise et vos équipes ne pourront traiter toutes les demandes à la fois.
• Les équipes d’intervention (techniques et sécurité) pour définir et déployer le plan de remédiation. L’expertise et les efforts humains requis pour reconstruire un Active Directory nécessitent un renfort ponctuel de vos équipes pour traiter la remédiation : maîtrise des outils de revue de configuration (PingCastle, Purple Knight, etc.), priorisation des vulnérabilités détectées, déploiement et contrôle des mesures, etc.

Afin d’optimiser le temps de réaction de chacun des acteurs, il est primordial de définir des processus et fiches réflexes. Au-delà de leur écriture, des simulations et exercices réguliers doivent être organisés pour entraîner vos équipes à réagir efficacement.

Pendant la crise…

Déployez rapidement un dispositif de suivi de projet, incluant des rapports réguliers, un suivi des actions et une coordination entre les différentes équipes impliquées. Le manque de communication et la perte d’informations engendrent trop souvent un ralentissement de la remédiation. Par exemple, il n’est pas rare de voir des administrateurs prendre des initiatives sans prendre le temps de les communiquer : ouverture de plus de ports réseaux que nécessaire, parallélisation de deux tâches du plan de remédiation, etc… Ces initiatives partant d’une bonne intention peuvent avoir des impacts significatifs sur la remédiation, allant de la complexification des travaux à une vision altérée du niveau de sécurité réel à la suite des travaux de sécurisation et donc un risque de nouvelle compromission éclair.

Assurez la résilience de vos sauvegardes en définissant une stratégie robuste

L’indisponibilité des sauvegardes (altérées ou compromises) est un défi majeur lors de la gestion d’une compromission d’Active Directory. Les attaquants prennent souvent le temps de cibler et de rendre indisponibles les sauvegardes ou de perturber les serveurs de sauvegarde. Cela a pour conséquence de rendre la restauration de l’Active Directory et la reprise des opérations plus difficiles et plus longues.

En amont de la crise …

Élaborez une stratégie de sauvegarde résiliente en tenant compte des bonnes pratiques et des recommandations (sauvegarde sur média déconnecté, immuable ou dans le cloud) [2]. Force est de constater qu’il existe aujourd’hui un écart entre l’état de l’art et les stratégies de sauvegardes (authentification des infrastructures de sauvegardes portées par l’Active Directory, sauvegardes des contrôleurs de domaine non sécurisée, etc.).

Pendant la crise …

Envisagez l’option d’assainir l’environnement Active Directory à partir d’un contrôleur de domaine compromis. Cette méthode de « double bascule » peut permettre de récupérer et de sécuriser les données essentielles afin de restaurer le service Active Directory sans sauvegarde. Un tel dispositif est à privilégier lorsque les sauvegardes sont indisponibles et que l’on ne souhaite pas reconstruire l’Active Directory de zéro.

Anticipez les problèmes techniques tels que la configuration du DNS Active Directory en entretenant votre environnement

La vaste majorité des environnements Active Directory souffre d’une dette technique accumulée au fil des années (architecture réseau complexe, rôles tel que DHCP portés par des contrôleurs de domaine plutôt que des serveurs dédiés, etc.). De plus, les environnements Active Directory sont aujourd’hui synchronisés avec Azure Active Directory, définissant de nouvelles dépendances entre les technologies pouvant complexifier la remédiation en cas de compromission de l’Active Directory (synchronisation Active Directory/Azure Active Directory). Ces deux éléments peuvent, le jour de la crise, engendrer de nombreuses problématiques techniques qui ralentiront la remédiation (perte de synchronisation avec Azure Active Directory, indisponibilité du service DHCP porté par un contrôleur de domaine devant rester éteint, etc.)

En amont de la crise …

Maintenez à jour la documentation technique et les inventaires de l’Active Directory (infrastructure, synchronisation Azure Active Directory, etc.). Il est trop souvent complexe d’obtenir une vision claire de l’environnement et du périmètre à remédier. Des inventaires à jour amélioreront grandement les travaux de remédiation et assurera la définition d’un plan de remédiation cohérent. De plus, cela vous permettra d’identifier et de remédier les mauvaises pratiques pouvant se transformer en problèmes conséquents le jour de la crise (configuration du service DNS, DHCP, etc.)

Pendant la crise …

Les services portés par Azure Active Directory pouvant être rendus indisponibles après 30 jours de désynchronisation avec l’Active Directory, cela peut engendrer un effet de bombe à retardement. Assurez-vous d’évaluer les impacts liés à la perte des services Azure Active Directory et de ne pas vous reposer sur ces services pour traiter vos activités essentielles (communication via e-mail, etc.).

De nombreux défauts techniques seront mis en lumière par la crise (rapport de configuration Active Directory via les outils d’audit, problématiques réseau, etc.). Assurez-vous de traiter uniquement les problèmes liés aux objectifs fixés par le plan de remédiation (cf. Conseil n°5 – Définissez un cap et gardez le pendant la remédiation !).

Optimisez la réinitialisation des secrets à travers des processus adaptés à votre contexte

La compromission de l’Active Directory engendre la perte de confiance dans l’ensemble de ses secrets. Une réinitialisation de ces derniers est donc requise pour atteindre le niveau de sécurité nécessaire à la réouverture des services et éviter une nouvelle compromission éclair. Pour des environnements conséquents avec plusieurs milliers d’utilisateurs et plus d’une centaine d’applications, réinitialiser un grand nombre de mots de passe d’utilisateurs et de comptes de service peut avoir des impacts opérationnels significatifs. Les travaux concernant les comptes de service nécessitent de comprendre comment l’application utilise le compte pour être en mesure de lui fournir le nouveau mot de passe. Pour les utilisateurs, il vous faudra trouver un moyen de distribuer les nouveaux mots de passe à large échelle de manière sécurisée.

En amont de la crise …

Il est nécessaire d’avoir les idées claires sur le processus de distribution de nouveaux mots de passe aux utilisateurs. Plusieurs méthodes sont possibles et dépendent de l’environnement étudié : convocation des utilisateurs avec présentation de la carte d’identité, transmission du nouvel identifiant/mot de passe via courrier physique, courriel, SMS, etc. Indépendamment de la méthode sélectionnée, il est nécessaire d’exiger de l’utilisateur qu’il réinitialise son mot de passe à la prochaine connexion. Il est aussi possible que les utilisateurs puissent réinitialiser eux-mêmes leurs mots de passe grâce à des solutions s’appuyant, par exemple, sur l’authentification à deux facteurs.

Afin d’effectuer les travaux liés aux comptes de service, il est primordial d’en dresser un inventaire en identifiant les applications associées et les méthodes de réinitialisation des mots de passe pour chacune d’entre elles. L’obtention de cet inventaire par les équipes de remédiation est souvent complexe (indisponible, non maintenu, etc.) et nécessite donc d’investir un temps non-négligeable sur des tâches pouvant être réalisées hors crise. Au-delà des travaux de remédiation, cet exercice vous sera utile au quotidien dans la gestion de vos comptes de service. L’une des bonnes pratiques étant de changer fréquemment les mots de passe de ces comptes.

Pendant la crise …

Une fois les mots de passes réinitialisés, il convient de contrôler que la mesure a été déployée sur l’ensemble de l’environnement. Cela peut se faire simplement via un script PowerShell et assure que l’attaquant n’a plus de compte valide à exploiter.

Définissez un cap et gardez le pendant la remédiation !

Lors de la reconstruction d’un Active Directory, il est souvent complexe de trouver le juste milieu entre s’exposer à des risques en rouvrant trop rapidement et engendrer des pertes financières importantes en rouvrant trop lentement. Attention à ne pas tomber dans les pièges classiques de gestion d’une crise rançongiciel. [3]

En amont de la crise …

Il est nécessaire d’effectuer un travail de réflexion sur les différentes postures de remédiation : restaurer au plus vite des services vitaux, reprendre le contrôle du système d’information ou saisir l’opportunité pour préparer une maîtrise durable du système d’information. [1]

Au-delà de la posture à définir, assurez-vous de maîtriser votre cœur de confiance Active Directory composé des actifs les plus critiques (Tier 0). Les actions de remédiations se concentrent en premier lieu sur ces composantes (contrôleurs de domaine, etc.) afin de restaurer les services vitaux l’Active Directory et d’assurer un niveau de sécurité ne permettant pas à l’attaquant de compromettre à nouveau l’entièreté de l’environnement.

Pendant la crise …

Assurez-vous que vos équipes se concentrent sur le cap défini. De nouvelles problématiques apparaîtront au fur et à mesure de l’exécution du plan de remédiation (indisponibilité du contrôleur de domaine portant l’un des rôles FSMO nécessaire à la remédiation, problématiques réseaux, etc.). Il sera nécessaire de se poser la question de la pertinence de sa remédiation à court terme par rapport aux objectifs fixés (la réponse étant fonction de la posture choisie par le comité exécutif : réouverture rapide, ou plus lente et plus sécurisée).

De plus, sachez considérer les opportunités offertes par la crise. Par exemple, si le service DHCP était géré par un contrôleur de domaine, profitez de l’occasion pour mettre en place un serveur dédié au DHCP, dissociant ainsi le service du contrôleur de domaine.

Nos enseignements

L’amélioration du processus de reconstruction en amont de la compromission d’Active Directory repose finalement sur trois axes principaux :

1. La rédaction de processus fonctionnels et fiches réflexes pour être capable de :
   1. Mobiliser les bonnes personnes en temps opportun.
   2. Se concentrer sur les objectifs principaux.
   3. L’entretien de l’environnement Active Directory, qui requiert de :
2. Définir et maintenir une architecture conforme aux bonnes pratiques.
   1. Avoir des inventaires à jour.
   2. S’assurer de la résilience des sauvegardes.
3. La réalisation de tests pour :
   1. Valider l’applicabilité des processus théoriques en conditions réelles.
   2. Améliorer la réactivité et l’efficacité de vos équipes face à une situation de crise.

Un travail adéquat sur ces trois sujets en amont permettra de réduire la complexité et le coût liés à la reconstruction de l’Active Directory en cas de compromission. Cette approche proactive contribuera à renforcer la résilience et la sécurité de l’entreprise face aux cybermenaces.

[1] https://www.ssi.gouv.fr/actualite/lanssi-publie-pour-appel-a-commentaires-un-corpus-documentaire-sur-la-remediation/

[2] https://www.riskinsight-wavestone.com/2023/02/reconstruction-dactive-directory-comment-se-donner-les-moyens-dy-parvenir/

[3] https://www.riskinsight-wavestone.com/2023/01/top-10-des-pieges-a-eviter-pour-une-gestion-de-crise-rancongiciel-reussie/

Cet article Survivre à une compromission d’Active Directory : les principaux enseignements pour améliorer le processus de reconstruction est apparu en premier sur RiskInsight.

La réflexion sur la bonne manière de traiter ce sujet dans les organisations se trouve à la croisée des projets de renforcement de la sécurité de l’AD et des projets de cyber-résilience.

Infrastructure et agent de sauvegarde : un point faible voire un vecteur de compromission

Nos différents états des lieux réalisés ces derniers mois nous le montrent : les stratégies de sauvegarde n’ont pas toujours évolué vers l’état de l’art.

Premier problème : les infrastructures de sauvegarde ne sont pas résilientes au risque cyber par défaut. L’authentification sur ces infrastructures de sauvegardes est par exemple très souvent liée à l’Active Directory lui-même. Par rebond, le système de sauvegarde pourrait être compromis par l’attaquant, induisant une potentielle destruction des sauvegardes… y compris celles de l’Active Directory !

Et les sauvegardes sont une cible de choix pour les attaquants. Dans plus de 20% des incidents gérés par le CERT Wavestone en 2021, les sauvegardes étaient impactées. Il convient donc d’intégrer le scénario cyber – et tout particulièrement le scénario rançongiciel – lorsque l’on pense à la résilience des sauvegardes.

Deuxième problème : les sauvegardes des Domain Controllers (DC) sont hébergées dans l’outil de sauvegarde, qui a souvent un niveau de sécurité plus faible que celui d’Active Directory. En effet, une organisation ayant déjà mené des travaux de sécurisation d’AD aura potentiellement fortement renforcé son tier 0 (l’on revient toujours au tiering !) : mise en place de postes dédiés pour l’administration, authentification multi-facteurs, filtrage réseau, matériel dédié, limitation du nombre de comptes à privilèges, etc. Cela ne sera hélas pas forcément le cas pour l’infrastructure de sauvegarde. Ces sauvegardes n’étant pas nécessairement chiffrées, un attaquant pourrait la récupérer et l’exfiltrer d’un DC en passant par l’infrastructure de sauvegarde, plus facile à compromettre. Une fois la sauvegarde exfiltrée, l’attaquant sera en mesure d’étendre encore son périmètre de compromission via une attaque de type pass the hash, après récupération des condensats ou encore une attaque par force brute, après extraction des secrets de la base ntds.dit pour récupérer des mots de passe en clair à rejouer sur des services dont l’authentification ne se base pas sur Active Directory.

Troisième problème : les méthodes traditionnelles de sauvegarde reposent sur des agents installés sur les Domain Controllers, dont les hauts privilèges servent parfois de vecteurs de compromissions. Les agents de sauvegarde nécessitent pratiquement toujours des droits d’administration sur l’actif sauvegardé, ce qui expose mécaniquement le Domain Controllers et donc les domaines Active Directory. L’on arrive donc à la situation paradoxale où la mesure de réduction de risque d’indisponibilité (installation d’un agent de sauvegarde sur un DC) devient elle-même la vulnérabilité à l’origine d’un risque pouvant devenir critique (indisponibilité de l’ensemble du système d’informations).

Sauvegarde sur média déconnecté, immuable ou dans le cloud : de multiples stratégies pour de multiples cas de figure

Pour résoudre ces deux problèmes, de multiples solutions existent et leur combinaison permet de construire une stratégie robuste. Cette stratégie doit prendre en compte le contexte de l’organisation ainsi que sa maturité en matière de cybersécurité.

Pour pallier le premier problème induit par l’agent vulnérable deux approches existent, toutes les deux viables :

1. Diminuer la probabilité d’exploitation de la vulnérabilité induite par l’agent de sauvegarde. Cela passe, au-delà des classiques sujets de maintien en condition de sécurité (mise à jour régulière, correction rapide de vulnérabilités de l’agent, etc.), par l’intégration d’un outil de sauvegarde dédié dans le tier 0, dont le niveau de sécurité aura été renforcé.
2. Se débarrasser de l’agent de sauvegarde. Comment ? En utilisant la fonction de sauvegarde native de Windows (Windows Backup), qui permet de réaliser et d’exporter une sauvegarde, que l’on pourra chiffrer et sortir du tier 0, vers un actif du tier 1, qui lui-même pourra être sauvegardé par la solution standard de sauvegarde de l’entreprise.

Pour renforcer la résilience des sauvegardes de l’Active Directory, plusieurs mesures doivent autant que possible se combiner :

1. Externaliser la sauvegarde sur média (version hors ligne). La première déclinaison peut être mise en place rapidement et à faible coût : un disque dur externe à déconnecter une fois la sauvegarde faite. Il s’agit simplement de mettre en place le processus organisationnel associé pour que l’action humaine puisse être faite sans oubli. La seconde déclinaison, pour les rares organisations qui en sont encore dotées, est de s’appuyer sur le système de sauvegarde sur bandes. Dans ce cas aussi, un point d’attention est de rigueur : la sauvegarde et l’externalisation régulière du catalogue de sauvegarde, pour ne pas perdre de temps en cas de restauration, dans le cas où celui-ci a disparu lui aussi (histoire s’inspirant de faits réels rencontrés par nos équipes de réponse à incident). Point d’attention : la sauvegarde sur bandes doit être vue comme un dernier recours pour s’assurer de conserver une copie des données, en cas de scénario catastrophe. En effet, ce format de sauvegarde ne se prête pas à la reconstruction rapide, en raison de délais incompressibles conséquents, avant même de pouvoir commencer à restaurer sur le SI de production : délai de rapatriement des bandes et délai la lecture de leur contenu.
2. Externaliser la sauvegarde en dehors du système d’information (version en ligne). Que cela soit réalisé à l’aise de scripts maison ou de solutions du marché (voir notre radar), après chiffrement robuste, une sauvegarde peut être externalisée. L’avantage des solutions du marché est qu’elles intègrent directement la partie reconstruction rapide (cf. partie suivante) d’un DC.
3. S’appuyer sur une sauvegarde complémentaire mais indépendante. Pour augmenter la disponibilité de l’infrastructure de sauvegarde, il suffit de la redonder en s’assurant qu’il n’y ait pas de risque de compromission simultanée. Pour cela, profitant de leur transition vers le cloud, de nombreuses organisations ont choisi récemment d’ajouter un DC supplémentaire, mais hébergé dans le cloud (les autres étant traditionnellement encore on-premises), bénéficiant ainsi naturellement des mécanismes de sauvegarde qui lui est propre. Du fait des mécanismes de réplication internes à AD, le DC hébergé dans le cloud sera compromis (compromission de certains comptes ou de certaines configurations d’AD) dans la même échelle de temps que ceux on-premises, mais l’étanchéité entre actifs sauvegardés et système de sauvegarde étant supposé meilleur dans le cloud, l’on aura plus de chance d’avoir une sauvegarde d’un DC encore disponible.
4. Rendre son infrastructure de sauvegarde immuable, en s’appuyant au maximum sur les solutions proposées par les éditeurs des logiciels de sauvegarde. En effet, la plupart des éditeurs proposent désormais des mécanismes d’immuabilité, qui parfois ne nécessitent pas l’achat de baies de stockage supplémentaires. En rendant les sauvegardes immuables sur leur stockage primaire, on s’assure d’un temps de reconstruction optimal puisqu’il ne sera pas nécessaire de rapatrier les sauvegardes depuis un stockage hors ligne (axe 1) ou en ligne (axe 2) avant de pouvoir commencer à restaurer. N.B.: l’axe 2 peut et doit bénéficier de ce concept (Amazon S3, Azure blob, etc.).

Enfin, dernier point de détail, connaître quel(s) DC sauvegarder et utiliser pour la restauration en cas de besoin est indispensable (DC Global Catalog, version d’OS la plus récente, etc.), tout comme la fréquence (sûrement quotidienne) et la durée de rétention (sujet beaucoup plus subjectif).

Reconstruction rapide : des capacités souvent incomplètement testées

Les tests de reconstruction sont aussi vieux que le concept de PCA/PRA. Mais là encore, l’on ne peut pas juste reposer sur ces tests annuels pour se considérer prêt, à la lumière de l’état de la menace. En effet, ces tests reposent très souvent sur des hypothèses qui ne seront pas vérifiées en cas de cyberattaque majeure : sauvegardes disponibles, confiance dans l’état du système d’information, outils collaboratifs (poste de travail, messagerie, outil de ticketing, etc.) fonctionnels, infrastructure d’accueil cible prête et disponible, etc.

De ce que l’on observe dans les organisations, les temps affichés et communiqués sur les temps de reconstruction d’un domaine AD sont souvent sous-estimés a priori. Les temps de déclenchement et d’arrêt du chronomètre sont bien souvent discutables : déclenchement au moment où l’on appui sur le bouton de démarrage de la restauration de la sauvegarde, arrêt au moment où un DC est restauré et opérationnel (procédure AD forest recovery exécutée [2]). Pour autant, l’on fait souvent fi de certains points qui peuvent difficilement être écartés pour comparer cette durée à celle du RTO :

• dépendance non satisfaite à un autre domaine indispensable (domaine présentant une ou plusieurs relation(s) d’approbation avec d’autres domaines) ;
• capacité à tenir la charge d’authentification que représentera une réouverture de service ;
• temps d’exécution des opérations de « toilettage » (changement de mot de passe en masse, désactivation de certains services ou compte, remise au propre dans les objets et les groupes, etc.) ;
• etc.

Lorsque l’infrastructure AD est paralysée par une cyberattaque majeure, sa reconstruction deviendra rapidement la priorité de la cellule de crise, en raison de la dépendance des applications et utilisateurs à celle-ci. C’est d’ailleurs un service dont le RTO est le plus faible. Dans le cas où les sauvegardes sont disponibles, se posent rapidement certaines questions qui doivent nourrir la stratégie de cyberdéfense que l’on est en train de définir (voir notre Top 10 des pièges à éviter pour une gestion de crise rançongiciel réussie) :

• Faut-il avoir une zone permettant d’accueillir la future infrastructure saine ?
• La création des utilisateurs dans Azure AD durant la crise permet-elle de rouvrir le service plus rapidem ent ?
• Dans le cas où il existe de nombreux domaines AD (cas des très grandes organisations) dans quel ordre procéder ?

Sur le volet infrastructure, d’abord, dans la vaste majorité des cas, disposer d’une zone isolée et sécurisée de reconstruction permet de gagner du temps. Celle-ci doit être disponible, prête à accueillir le nombre de VM permettant d’atteindre le niveau service considéré comme acceptable dans une telle situation et à la main (comptes avec les droits suffisants, accessibilité, etc.) de l’équipe responsable du service Active Directory uniquement. Cela pour réduire le risque de compromission mais aussi pour ne pas créer de freins (demandes à effectuer à une autre équipe) le jour où le besoin survient.

Cette zone peut-être on-premises ou dans un service cloud, dépendamment des coûts et de la posture cybersécurité de l’organisation quant à l’hébergement de DC sur un cloud (dans le cas où celui-ci est public). Cette zone dormante peut d’ailleurs être mise à profit pour accueillir les tests de restauration réguliers de l’Active Directory, pour être au plus proche d’une situation réelle. Enfin, cette infrastructure doit évidemment être dans le tier 0, si l’organisation s’appuie sur ce framework.

Sur le volet des processus, ensuite, il convient de préparer en amont plusieurs informations indispensables le jour où le besoin de reconstruire le service surviendra :

• déterminer le nombre de DC minimal ainsi que leur localisation (zone de reconstruction dans le cloud / on-premises, mais également géographiquement en cas de présence sur de multiples plaques) ;
• déterminer la méthode de réplication (réplication standard ou recours à IFM [3]) des DC permettant de minimiser le temps entre la disponibilité du premier et du dernier DC nécessaire à la réouverture du service ;
• des règles de filtrage prêtes et désactivées, qu’il suffira d’activer avant l’ouverture du service ;
• du niveau de risque acceptable pour la reconstruction (reconstruction simple et « toilettage » des objets ou méthode du pivot) ;
• (dans les organisations avec de multiples domaines servant plusieurs métiers) une séquence de reconstruction, qu’il aura fallu déterminer au-préalable avec les responsables métier, pour rouvrir le service selon les bonnes priorités.

Ici aussi, les outils de sauvegarde / restauration spécialisés AD apportent de la valeur : ils permettent d’exécuter la procédure de restauration d’une forêt AD en quelques clics et de manière automatisée. La parallélisation de ces opérations est également rendue possible, faisant de ces outils un accélérateur indéniable à considérer pour les organisations possédant de nombreuses forêts !

Sur le volet des ressources, enfin, il convient de disposer d’une organisation permettant de répondre à cette surcharge de travail ponctuelle mais très importante. Pour cela, l’automatisation des activités de reconstruction qui peuvent l’être, mais également le fait d’avoir des ressources ayant déjà pratiqué l’exercice à de multiples reprises s’avère souvent décisif.

Certaines organisations profitent des tests de Disaster Recovery (DR) pour simuler la pire situation possible pour le service Active Directory, plutôt que de simplement simuler une reprise seulement partielle. C’est indubitablement une bonne pratique.

En définitive, se poser la question de la résilience de son infrastructure Active Directory tire le sujet plus global de la résilience du système d’information, mais également celui du tiering, celui des exercices grandeur nature, à mener régulièrement. L’on pourrait même faire un pont avec le DevOps : ne rêverait-on pas de parvenir au redéploiement d’une infrastructure AD quasiment automatiquement, à l’image de ce que parviennent à faire les DevOps grâce au concept d’Infrastructure as Code ? En attendant, l’entraînement régulier reste le seul moyen d’atteindre un degré de sérénité sur ses capacités à rouvrir rapidement un service AD minimal, s’il venait à être entièrement détruit.

[1] https://www.wavestone.com/en/insight/cert-w-2022-cybersecurite-trends-analysis/

[2] https://learn.microsoft.com/fr-fr/windows-server/identity/ad-ds/manage/ad-forest-recovery-guide

[3] Install From Media : https://social.technet.microsoft.com/wiki/contents/articles/8630.active-directory-step-by-step-guide-to-install-an-additional-domain-controller-using-ifm.aspx

Cet article RECONSTRUCTION D’ACTIVE DIRECTORY : COMMENT SE DONNER LES MOYENS D’Y PARVENIR ? est apparu en premier sur RiskInsight.

Le RaaS : fer de lance des « Cloud Recovery Services »

Comme pour beaucoup de ce qui tourne autour du cloud, il est parfois difficile de donner une définition précise de ce dont on parle, tant une même appellation peut cacher des offres différentes. Nous utiliserons la définition suivante : « Cloud Recovery Service => secours d’un système d’information sur une infrastructure virtualisée, hébergée par un tiers, disponible à la demande et facturée à l’utilisation. »

L’éventail des possibilités est très large :

•  d’une sauvegarde externalisée des données critiques en mode cloud (« Backup-as-a-Service ») …
•  …en passant par la construction par le client lui-même de son secours sur la base d’une prestation de type « IaaS » [2] …
•   …jusqu’à une offre complètement managée intégrant le suivi du SI nominal et des mécanismes de bascule planifiés. C’est ce type de prestations que l’on retrouve sous l’appellation « Recovery-as-a-Service ».

 Quel est l’intérêt de passer au RaaS ?

L’utilisation du RaaS résulte avant tout d’un choix économique. Sur le papier du moins, le secours paraît adapté au modèle de facturation du cloud (pas de sinistre > allocation limitée de ressources > coût d’utilisation réduit), alors qu’un secours traditionnel implique de stocker, héberger et faire évoluer des infrastructures, des serveurs et des applications sur un site de secours.

Mais à y regarder de plus près, les économies ne sont pas toujours au rendez-vous et varient grandement en fonction des applications. Si certaines d’entre elles, peu consommatrices de données, sont les candidates idéales pour le RaaS (des études indépendantes font état d’environ 80% d’économies [3] pour leur secours par rapport à l’approche traditionnelle), le ROI pour les applications plus lourdes et/ou pour lesquels les exigences de continuité sont plus fortes s’avère discutable. En effet, plus les RTO et RPO seront exigeants, plus le niveau de service devra être élevé (allocation renforcée de ressources, mécanismes de réplication des données site-à-site, liens sécurisés, supervision 24/7, etc.) entraînant une envolée des coûts à la clef.

Le RaaS s’assimile, à ce stade de sa maturité, au mieux à du « warm recovery ». En effet, il est aujourd’hui illusoire de penser que les solutions proposées permettront de la haute-disponibilité : délais d’activation, délais relatifs aux opérations de bascule notamment au niveau du réseau, délais de restauration en cas de corruption des données, etc.

En outre, le RaaS repose essentiellement sur des mécanismes de virtualisation de serveurs (le plus souvent restreints aux architectures Intel x86, à l’exception de quelques fournisseurs), que ne supportent pas tous les progiciels du marché, a fortiori les applications propriétaires des clients.

Ainsi, le fait de vouloir tirer pleinement parti de la compétitivité économique du RaaS tout en répondant aux besoins Métiers réduit son utilisation à une certaine catégorie d’applications. Ce faisant, il cantonne le RaaS en tant que solution complémentaire à un secours traditionnel, ce qui peut paradoxalement devenir une source de complexité, du fait de la cohabitation de deux SI de secours. Néanmoins, deux cas d’usage du RaaS émergent pour les organisations concernées :

•  La couverture des applications virtualisées ou éligibles à la virtualisation à coût optimisé
•  L’extension du secours à des périmètres qui n’auraient pas pu être intégrés au Plan de Continuité Informatique de l’organisation, pour une meilleure couverture au meilleur coût.

A qui s’adressent les offres RaaS ?

Étant donné son modèle économique et sa structure technique, le RaaS semble plus adapté aux moyennes structures (qui n’ont pas souvent la surface financière pour mettre en œuvre et gérer en propre un site de secours) et notamment à celles qui ont opéré la virtualisation de leur SI. Les études prospectives [4] le montrent : ce sont elles qui tireront la croissance de ce marché dans les prochaines années.

Les grandes organisations déjà dotées de Plans de Continuité Informatique seront probablement moins intéressées mais pourront néanmoins trouver dans le RaaS des réponses ciblées à certains de leurs besoins.

Le RaaS : une offre mature ?

Comme pour nombre de cloud services, le RaaS n’a pas encore atteint sa pleine maturité : en témoigne le foisonnement des offres et des prestataires notamment aux États-Unis et au Royaume-Uni. Au-delà des acteurs historiques de la continuité informatique se positionnent des pure-players des cloud recovery services et de plus en plus des hébergeurs informatiques, convertis au cloud.

Le marché se structure, les offres évoluent en recherchant notamment de la complémentarité avec les cloud services : des initiatives d’interopérabilité entre services IaaS et RaaS se font jour pour assurer du secours « cloud-to-cloud » par exemple.

A ce stade et en terme de couverture de risques, le RaaS doit faire ses preuves. Concrètement les infrastructures dévolues au RaaS reposent sur encore peu de datacenters. Le client qui souhaitera se prémunir de sinistres affectant des zones géographiques particulières (ou étendues) devra se rapprocher du fournisseur de service RaaS qui l’intéresse pour vérifier que son ou ses sites ne sont pas exposés aux mêmes risques.

En France, le marché reste jeune et sans retour d’expérience significatif de déploiement. Les grands offreurs français s’appuient, aujourd’hui, sur les infrastructures anglo-saxonnes ou nord-américaines de leur maison-mère (ce qui potentiellement impacte la qualité de service, le niveau de sécurité, les engagements contractuels, etc.). Reste donc aux acteurs, anciens comme nouveaux, à démontrer toute la pertinence de leurs offres, en particulier sur la gamme des services managés, probablement les plus recherchés par les DSI.

[1] On rencontre également l’acronyme DRaaS (Disaster Recovery-as-a-Service)

[2] IaaS : Infrastructure-as-a-Service

[3] « Disaster Recovery as a Cloud Service : Economic Benefits & Deployment Challenges »

[4] « Gartner Says 30 Percent of Midsize Companies Will Use Recovery-as-a-Service by 2014 »

Cet article Recovery-as-a-Service (RaaS) : une révolution pour le secours informatique ? est apparu en premier sur RiskInsight.