Planification des compromis
S’applique à : Windows Server 2022, Windows Server 2019, Windows Server 2016, Windows Server 2012 R2, Windows Server 2012
Loi numéro 1 : Personne ne croit que quelque chose de mal peut leur arriver, jusqu’à ce que cela se produise. - 10 lois immuables de l’administration de la sécurité
Dans de nombreuses organisations, les plans de récupération d’urgence se concentrent sur la récupération après des sinistres ou des défaillances régionales qui entraînent la perte de services informatiques. Toutefois, lorsque vous travaillez avec des clients compromis, nous constatons souvent que la récupération à la suite d’une compromission intentionnelle est absente dans leurs plans de récupération d’urgence. Cela est particulièrement vrai lorsque la compromission entraîne le vol de propriété intellectuelle ou la destruction intentionnelle qui tire profit des limites logiques (comme la destruction de tous les domaines Active Directory ou de tous les serveurs) plutôt que des limites physiques (par exemple, la destruction d’un centre de données). Bien qu’une organisation puisse avoir des plans de réponse aux incidents qui définissent les activités initiales à entreprendre lorsqu’une compromission est découverte, ces plans omettent souvent les étapes de récupération à la suite d’une compromission qui affecte l’ensemble de l’infrastructure informatique.
Étant donné qu’Active Directory fournit des fonctionnalités enrichies de gestion des identités et des accès pour les utilisateurs, les serveurs, les stations de travail et les applications, il est toujours ciblé par des personnes malveillantes. Si une personne malveillante obtient un accès à haut niveau de privilège à un domaine ou à un contrôleur de domaine Active Directory, cet accès peut être exploité pour accéder, contrôler ou même détruire l’ensemble de la forêt Active Directory.
Ce document présente certaines des attaques les plus courantes contre Windows et Active Directory et les contre-mesures que vous pouvez implémenter pour réduire votre surface d’attaque. Cependant, la seule façon sûre de récupérer en cas de compromission complète d’Active Directory consiste à se préparer à la compromission avant qu’elle ne se produise. Cette section se concentre moins sur les détails de l’implémentation technique que les sections précédentes de ce document, mais plus sur des recommandations générales que vous pouvez utiliser pour créer une approche holistique et complète afin de sécuriser et de gérer les ressources métier et informatiques critiques de votre organisation.
Que votre infrastructure n’ait jamais été attaquée, qu’elle ait résisté à des tentatives de violation ou qu’elle ait succombé à des attaques et ait été entièrement compromise, vous devez prévoir l’inévitable réalité selon laquelle vous serez attaqué encore et encore. Il n’est pas possible d’empêcher les attaques, mais il peut être possible en effet d’empêcher des violations importantes ou des compromissions de grande ampleur. Chaque organisation doit évaluer étroitement ses programmes de gestion des risques existants et apporter les ajustements nécessaires pour réduire son niveau de vulnérabilité général en effectuant des investissements équilibrés dans la prévention, la détection, la maîtrise et la récupération.
Pour créer des défenses efficaces tout en fournissant des services aux utilisateurs et aux entreprises qui dépendent de votre infrastructure et de vos applications, vous devrez peut-être réfléchir à nouvelles façons d’empêcher, de détecter et de contenir les compromissions dans votre environnement, puis de récupérer après la compromission. Les approches et recommandations de ce document peuvent ne pas vous aider à réparer une installation Active Directory compromise, mais peuvent vous aider à sécuriser la prochaine.
Les recommandations relatives à la récupération d’une forêt Active Directory sont présentées dans Récupération de la forêt Active Directory : étapes de restauration de la forêt. Vous pourrez peut-être empêcher votre nouvel environnement d’être complètement compromis, mais même si vous ne le pouvez pas, vous disposerez d’outils pour récupérer et reprendre le contrôle de votre environnement.
Repenser l’approche
Loi numéro 8 : La difficulté pour défendre un réseau est directement proportionnelle à sa complexité. - 10 lois immuables de l’administration de la sécurité
Il est bien admis que si une personne malveillante a obtenu un accès système, administrateur, racine ou un accès équivalent à un ordinateur, quel que soit le système d’exploitation, cet ordinateur ne peut plus être considéré comme digne de confiance, peu importe les efforts déployés pour « nettoyer » le système. Active Directory n’est pas différent. Si une personne malveillante a obtenu un accès privilégié à un contrôleur de domaine ou à un compte à privilèges élevés dans Active Directory, sauf si vous disposez d’un enregistrement de chaque modification apportée par la personne malveillante ou d’une sauvegarde fiable connue, vous ne pouvez jamais restaurer le répertoire à un état entièrement fiable.
Lorsqu’un serveur membre ou une station de travail est compromis et modifié par une personne malveillante, l’ordinateur n’est plus fiable, mais les serveurs et les stations de travail non compromis voisins peuvent toujours être approuvés. La compromission d’un ordinateur n’implique pas la compromission de tous les ordinateurs.
Toutefois, dans un domaine Active Directory, tous les contrôleurs de domaine hébergent des réplicas de la même base de données AD DS. Si un seul contrôleur de domaine est compromis et qu’une personne malveillante modifie la base de données AD DS, ces modifications sont répliquées sur tous les autres contrôleurs de domaine dans le domaine et, en fonction de la partition dans laquelle les modifications sont apportées, dans la forêt. Même si vous réinstallez chaque contrôleur de domaine dans la forêt, vous réinstallez simplement les hôtes sur lesquels réside la base de données AD DS. Les modifications malveillantes apportées à Active Directory sont répliquées sur les contrôleurs de domaine nouvellement installés aussi facilement que sur des contrôleurs de domaine en cours d’exécution depuis des années.
Lors de l’évaluation des environnements compromis, nous constatons généralement que ce qui était considéré comme le premier « événement » de violation a été déclenché après des semaines, des mois, voire des années après que les personnes malveillantes ont initialement compromis l’environnement. Les personnes malveillantes obtenaient généralement les informations d’identification des comptes à privilèges élevés bien avant la détection d’une violation et elles tiraient profit de ces comptes pour compromettre le répertoire, les contrôleurs de domaine, les serveurs membres, les stations de travail et même les systèmes connectés non Windows.
Ces résultats sont cohérents avec plusieurs résultats du rapport d’enquêtes Verizon sur les violations de données de 2012, qui indique que :
98 % des violations de données proviennent d’agents externes
85 % des violations de données ont mis des semaines ou plus à être découvertes
92 % des incidents ont été découverts par un tiers et
97 % des violations étaient évitables par des contrôles simples ou intermédiaires.
Une compromission au degré décrit précédemment est en fait irréparable et le conseil standard « aplatir et reconstruire » chaque système compromis n’est tout simplement pas réalisable ou même possible si Active Directory a été compromis ou détruit. Même la restauration à un état correct connu n’élimine pas les failles qui ont permis à l’environnement d’être compromis en premier lieu.
Bien que vous deviez défendre chaque facette de votre infrastructure, une personne malveillante n’a besoin que de trouver suffisamment de failles dans vos défenses pour atteindre l’objectif souhaité. Si votre environnement est relativement simple et vierge et historiquement bien géré, l’implémentation des recommandations fournies précédemment dans ce document peut être une proposition simple.
Cependant, nous avons constaté que plus l’environnement est ancien, grand et complexe, plus il est probable que les recommandations contenues dans ce document seront irréalisables, voire impossibles à mettre en œuvre. Il est beaucoup plus difficile de sécuriser une infrastructure après coup que de partir de zéro et de construire un environnement résistant aux attaques et aux compromissions. Cependant, comme indiqué précédemment, il n’est pas une mince tâche de reconstruire une forêt Active Directory entière. Pour ces raisons, nous vous recommandons d’adopter une approche plus concentrée et ciblée pour sécuriser vos forêts Active Directory.
Plutôt que de vous concentrer sur toutes les choses qui sont « endommagées » et d’essayer de les corriger, envisagez une approche dans laquelle vous hiérarchiser en fonction de ce qui est le plus important pour votre entreprise et dans votre infrastructure. Au lieu d’essayer de corriger un environnement rempli de systèmes et d’applications obsolètes et mal configurés, envisagez de créer un nouvel environnement petit et sécurisé dans lequel vous pouvez transférer en toute sécurité les utilisateurs, les systèmes et les informations les plus essentiels à votre entreprise.
Dans cette section, nous décrivons une approche par laquelle vous pouvez créer une forêt AD DS vierge qui sert de « canot de sauvetage » ou de « cellule sécurisée » pour votre infrastructure métier principale. Une forêt vierge est simplement une forêt Active Directory nouvellement installée qui est généralement limitée en taille et en étendue et qui est créée à l’aide de systèmes d’exploitation actuels, d’applications et avec les principes décrits dans Réduire la surface d’attaque Active Directory.
En implémentant les paramètres de configuration recommandés dans une forêt nouvellement créée, vous pouvez créer une installation AD DS à partir de zéro avec des paramètres et des pratiques sécurisés et vous pouvez réduire les défis qui accompagnent la prise en charge des systèmes et des applications hérités. Bien que des instructions détaillées pour la conception et l’implémentation d’une installation d’AD DS vierge soient en dehors de l’étendue de ce document, vous devez suivre certains principes généraux et des instructions pour créer une « cellule sécurisée » dans laquelle vous pouvez héberger vos ressources les plus critiques. Ces instructions sont les suivantes :
Identifiez les principes de séparation et de sécurisation des ressources critiques.
Définissez un plan de migration limité et basé sur les risques.
Tirez profit des migrations « non migratrices» si nécessaire.
Implémentez la « destruction créative ».
Isolez les applications et les systèmes hérités.
Simplifiez la sécurité pour les utilisateurs finaux.
Identifier les principes de séparation et de sécurisation des ressources critiques
Les caractéristiques de l’environnement vierge que vous créez pour héberger des ressources critiques peuvent varier considérablement. Par exemple, vous pouvez choisir de créer une forêt vierge vers laquelle vous migrez uniquement les utilisateurs VIP et les données sensibles que seuls ces utilisateurs peuvent accéder. Vous pouvez créer une forêt vierge dans laquelle vous migrez, entres autres, les utilisateurs VIP, mais que vous implémentez en tant que forêt administrative, en implémentant les principes décrits dans Réduire la surface d’attaque Active Directory pour créer des comptes d’administration et des hôtes sécurisés qui peuvent être utilisés pour gérer vos forêts héritées à partir de la forêt vierge. Vous pouvez implémenter une forêt « spécialement conçue » qui héberge les comptes VIP, les comptes privilégiés et les systèmes nécessitant une sécurité supplémentaire, tels que les serveurs exécutant les services de certificats Active Directory (AD CS) dans le seul but de les séparer des forêts moins sécurisées. Enfin, vous pouvez implémenter une forêt vierge qui devient de facto l’emplacement de tous les nouveaux utilisateurs, systèmes, applications et données, ce qui vous permet, au final, de mettre hors service votre forêt héritée via l’attrition.
Que votre forêt vierge contienne une poignée d’utilisateurs et de systèmes ou qu’elle constitue la base d’une migration plus agressive, vous devez suivre ces principes dans votre planification :
Supposons que vos forêts héritées aient été compromises.
Ne configurez pas un environnement vierge pour approuver une forêt héritée, même si vous pouvez configurer un environnement hérité pour approuver une forêt vierge.
Ne migrez pas de comptes d’utilisateurs ou des groupes d’une forêt héritée vers un environnement vierge s’il est possible que les appartenances aux groupes, l’historique SID ou d’autres attributs des comptes aient été modifiées de manière malveillante. Au lieu de cela, utilisez des approches « non migratrices » pour remplir une forêt vierge. (Les approches non migratrices sont décrites plus loin dans cet section)
Ne migrez pas d’ordinateurs de forêts héritées vers des forêts vierges. Implémentez des serveurs tout juste installés dans la forêt vierge, installez des applications sur les serveurs nouvellement installés et migrez les données d’application vers les systèmes nouvellement installés. Pour les serveurs de fichiers, copiez les données sur des serveurs nouvellement installés, définissez des listes de contrôle d’accès à l’aide d’utilisateurs et de groupes dans la nouvelle forêt, puis créez des serveurs d’impression de la même manière.
N’autorisez pas l’installation d’applications ou de systèmes d’exploitation hérités dans la forêt vierge. Si une application ne peut pas être mise à jour et être nouvellement installée, laissez-la dans la forêt héritée et envisagez la destruction créative pour remplacer les fonctionnalités de l’application.
Définir un plan de migration limité et basé sur les risques
La création d’un plan de migration limité basé sur les risques signifie simplement que lorsque vous décidez quels utilisateurs, applications et données migrer vers votre forêt vierge, vous devez identifier les cibles de migration en fonction du degré de risque auquel votre organisation est exposée si l’un des utilisateurs ou des systèmes est compromis. Les utilisateurs VIP dont les comptes sont les plus susceptibles d’être ciblés par des personnes malveillantes doivent être hébergés dans la forêt vierge. Les applications qui fournissent des fonctions métier vitales doivent être installées sur des serveurs fraîchement construits dans la forêt vierge et les données hautement sensibles doivent être déplacées vers des serveurs sécurisés dans la forêt vierge.
Si vous ne disposez pas déjà d’une image claire des utilisateurs, systèmes, applications et données les plus critiques de l’entreprise dans votre environnement Active Directory, collaborez avec les unités commerciales pour les identifier. Toutes les applications nécessaires au fonctionnement de l’entreprise doivent être identifiées, tout comme les serveurs sur lesquels les applications critiques s’exécutent ou sur lesquels les données critiques sont stockées. En identifiant les utilisateurs et les ressources nécessaires pour que votre organisation continue de fonctionner, vous créez une collection de ressources naturellement prioritaire sur laquelle concentrer vos efforts.
Tirer profit des migrations « non migratrices »
Que vous sachiez si votre environnement a été compromis, suspectiez sa compromission ou préfériez simplement ne pas migrer les données et les objets hérités d’une installation Active Directory héritée vers une nouvelle installation, envisagez des approches de migration qui ne « migrent » techniquement pas les objets.
Comptes d'utilisateurs
Dans une migration Active Directory classique d’une forêt à une autre, l’attribut SIDHistory (historique des SID) sur les objets utilisateur est utilisé pour stocker le SID des utilisateurs et les SID des groupes dont les utilisateurs étaient membres dans la forêt héritée. Si les comptes d’utilisateurs sont migrés vers une nouvelle forêt et qu’ils accèdent aux ressources de la forêt héritée, les SID dans l’historique SID sont utilisés pour créer un jeton d’accès qui permet aux utilisateurs d’accéder aux ressources auxquelles ils avaient accès avant la migration des comptes.
Toutefois, la gestion de l’historique SID s’est avérée problématique dans certains environnements, car le remplissage des jetons d’accès des utilisateurs avec des SID actuels et historiques peut entraîner un ballonnement de jeton. Le ballonnement de jeton est un problème dans lequel le nombre de SID qui doit être stocké dans le jeton d’accès d’un utilisateur utilise ou dépasse la quantité d’espace disponible dans le jeton.
Bien que la taille des jetons puisse être augmentée dans une mesure limitée, la solution ultime au ballonnement de jetons consiste à réduire le nombre de SID associés aux comptes d’utilisateur, que ce soit en rationalisant les appartenances aux groupes, en éliminant l’historique SID ou en combinant les deux. Pour plus d’informations sur le ballonnement de jeton, consultez MaxTokenSize et Kerberos Token Bloat.
Au lieu de migrer des utilisateurs à partir d’un environnement hérité (en particulier dans lequel les appartenances aux groupes et les historiques SID peuvent être compromis) à l’aide de l’historique SID, envisagez de tirer profit des applications de méta-annuaire pour « migrer » les utilisateurs, sans apporter d’historiques SID dans la nouvelle forêt. Lorsque des comptes d’utilisateur sont créés dans la nouvelle forêt, vous pouvez utiliser une application méta-annuaire pour mapper les comptes à leurs comptes correspondants dans la forêt héritée.
Pour fournir aux nouveaux comptes d’utilisateur l’accès aux ressources de la forêt héritée, vous pouvez utiliser les outils de méta-annuaire pour identifier les groupes de ressources auxquels les comptes hérités des utilisateurs ont obtenu l’accès, puis ajouter les nouveaux comptes des utilisateurs à ces groupes. Selon votre stratégie de groupe dans la forêt héritée, vous devrez peut-être créer des groupes locaux de domaine pour l’accès aux ressources ou convertir des groupes existants en groupes locaux de domaine pour permettre l’ajout des nouveaux comptes aux groupes de ressources. En vous concentrant d’abord sur les applications et les données les plus critiques et en les migrant vers le nouvel environnement (avec ou sans historique SID), vous pouvez limiter la quantité d’efforts déployés dans l’environnement hérité.
Serveurs et stations de travail
Dans une migration classique d’une forêt Active Directory vers une autre, la migration d’ordinateurs est souvent relativement simple par rapport à la migration d’utilisateurs, de groupes et d’applications. Selon le rôle de l’ordinateur, la migration vers une nouvelle forêt peut être aussi simple que de disjoindre un ancien domaine et d’en joindre un nouveau. Cependant, la migration de comptes d’ordinateur intacts dans une forêt vierge ne sert pas à créer un environnement nouveau. Plutôt que de migrer des comptes d’ordinateur (potentiellement compromis, mal configurés ou obsolètes) vers une nouvelle forêt, vous devez installer des serveurs et des stations de travail dans le nouvel environnement. Vous pouvez migrer les données des systèmes de la forêt héritée vers des systèmes de la forêt vierge, mais pas les systèmes qui hébergent les données.
Applications
Les applications peuvent présenter le défi le plus important de toute migration d’une forêt vers une autre, mais dans le cas d’une migration « non migratrice», l’un des principes de base que vous devez appliquer est que les applications dans la forêt vierge doivent être actuelles, prises en charge et nouvellement installées. Lorsque cela est possible, les données peuvent être migrées à partir d’instances d’application dans l’ancienne forêt. Dans des situations où une application ne peut pas être « recréée » dans la forêt vierge, vous devez envisager des approches telles que la destruction créative ou l’isolation des applications héritées, comme décrit dans la section suivante.
Implémenter la destruction créative
La destruction créative est un terme économique qui décrit le développement économique créé par la destruction d’un ordre antérieur. Ces dernières années, ce terme a été appliqué aux technologies de l’information. Il fait généralement référence aux mécanismes par lesquels une ancienne infrastructure est supprimée, non pas en la mettant à niveau, mais en la remplaçant par quelque chose de tout à fait nouveau. La conférence Gartner Symposium ITXPO de 2011 pour les DSI et les responsables informatique a présenté la destruction créative comme l’un de ses thèmes clés pour la réduction des coûts et l’augmentation de l’efficacité. Les améliorations de la sécurité sont possibles comme extension naturelle du processus.
Par exemple, une organisation peut être composée de plusieurs unités commerciales utilisant une application différente qui effectue des fonctionnalités similaires, avec différents degrés de modernité et de prise en charge des fournisseurs. Historiquement, le service informatique pouvait être responsable de la maintenance de l’application de chaque unité commerciale séparément et les efforts de consolidation consistaient à essayer de déterminer quelle application offrait les meilleures fonctionnalités, puis à migrer les données vers cette application à partir des autres.
Dans la destruction créative, au lieu de conserver des applications obsolètes ou redondantes, vous implémentez des applications entièrement nouvelles pour remplacer les anciennes, migrer les données vers les nouvelles applications et désactiver les anciennes et les systèmes sur lesquels elles s’exécutent. Dans certains cas, vous pouvez implémenter la destruction créative d’applications héritées en déployant une nouvelle application dans votre propre infrastructure, mais dans la mesure du possible, vous devez envisager de porter l’application vers une solution cloud à la place.
En déployant des applications cloud pour remplacer les applications internes héritées, vous réduisez non seulement les efforts et les coûts de maintenance, mais vous réduisez également la surface d’attaque de votre organisation en éliminant les systèmes et les applications hérités qui présentent des vulnérabilités pour les personnes malveillantes. Cette approche offre à une organisation un moyen plus rapide d’obtenir les fonctionnalités souhaitées tout en éliminant les cibles héritées dans l’infrastructure. Bien que le principe de la destruction créative ne s’applique pas à toutes les ressources informatiques, il offre une option souvent viable pour éliminer les systèmes et les applications hérités tout en déployant simultanément des applications cloud robustes et sécurisées.
Isoler les applications et les systèmes hérités
Une conséquence naturelle de la migration de vos utilisateurs et de vos systèmes critiques vers un environnement vierge et sécurisé est que votre forêt héritée contiendra des informations et des systèmes moins précieux. Bien que les systèmes et les applications hérités qui restent dans l’environnement moins sécurisé puissent présenter un risque élevé de compromission, ils représentent également une gravité de compromission réduite. En relogeant et en modernisant vos ressources d’entreprise critiques, vous pouvez vous concentrer sur le déploiement d’une gestion et d’une surveillance efficaces sans avoir à prendre en charge les paramètres et les protocoles hérités.
En supprimant ces systèmes des domaines dans lesquels l’implémentation des paramètres hérités est forcée, vous pouvez ensuite augmenter la sécurité des domaines en les configurant pour prendre en charge uniquement les systèmes d’exploitation et les applications actuels. Même s’il est préférable de désactiver les systèmes et les applications hérités chaque fois que possible. Si la désactivation n’est tout simplement pas possible pour un petit segment de votre population héritée, la ségrégation dans un domaine (ou une forêt) distinct vous permet d’effectuer des améliorations incrémentielles dans le reste de l’installation héritée.
Simplifiez la sécurité pour les utilisateurs finaux
Dans la plupart des organisations, les utilisateurs qui ont accès aux informations les plus sensibles en raison de la nature de leurs rôles au sein de l’organisation ont souvent le moins de temps à consacrer à l’apprentissage des restrictions et des contrôles d’accès complexes. Même si vous devez avoir un programme complet d’éducation à la sécurité destiné à tous les utilisateurs de votre organisation, vous devez également vous concentrer sur la simplification de l’utilisation de la sécurité en implémentant des contrôles transparents et des principes de simplification auxquels les utilisateurs adhèrent.
Par exemple, vous pouvez définir une stratégie dans laquelle les cadres et autres VIP doivent utiliser des stations de travail sécurisées pour accéder aux données et aux systèmes sensibles, ce qui leur permet d’utiliser leurs autres appareils pour accéder à des données moins sensibles. Il s’agit d’un principe simple que les utilisateurs doivent retenir, mais vous pouvez implémenter un certain nombre de contrôles back-end pour aider à faire appliquer l’approche.
Vous pouvez utiliser l’assurance du mécanisme d’authentification pour permettre aux utilisateurs d’accéder aux données sensibles uniquement s’ils se sont connectés à leurs systèmes sécurisés à l’aide de leurs cartes à puce et utiliser les restrictions IPsec et les droits de l’utilisateur pour contrôler les systèmes à partir desquels ils peuvent se connecter à des répertoires de données sensibles. Vous pouvez implémenter le contrôle d’accès dynamique pour restreindre l’accès aux données en fonction des caractéristiques d’une tentative d’accès, en traduisant les règles métier en contrôles techniques.
Du point de vue de l’utilisateur, l’accès aux données sensibles à partir d’un système sécurisé « fonctionne simplement » et tenter de le faire à partir d’un système non sécurisé « ne fonctionne tout simplement pas ». Toutefois, du point de vue de la surveillance et de la gestion de votre environnement, vous aidez à créer des modèles identifiables de la façon dont les utilisateurs accèdent aux données et aux systèmes sensibles, ce qui vous permet de détecter plus facilement les tentatives d’accès anormales.
Dans les environnements dans lesquels la résistance des utilisateurs aux mots de passe longs et complexes a entraîné des stratégies de mot de passe insuffisantes, en particulier pour les utilisateurs d’adresses IP virtuelles, envisagez d’autres approches d’authentification. Les autres approches incluent les cartes à puces (qui viennent dans un nombre de facteurs de forme et avec des fonctionnalités supplémentaires pour renforcer l’authentification), des contrôles biométriques, tels que les lecteurs d’empreintes de doigts, ou même les données d’authentification sécurisées par les puces du module de plateforme sécurisée (TPM) présentes dans les ordinateurs des utilisateurs. L’authentification multifacteur n’empêche pas les attaques par vol d’informations d’identification si un ordinateur est déjà compromis. Cependant, en offrant à vos utilisateurs des contrôles d’authentification faciles à utiliser, vous pouvez affecter des mots de passe plus robustes aux comptes d’utilisateurs pour lesquels les contrôles de nom d’utilisateur et de mot de passe traditionnels sont difficiles à gérer.