Sécurisation des contrôleurs de domaine contre les attaques
S'applique à : Windows Server 2019, Windows Server 2016, Windows Server 2012 R2, Windows Server 2012
Loi numéro 3 : Si une personne mal intentionnée dispose d’un accès physique illimité à votre ordinateur, ce n’est plus votre ordinateur. - Dix lois immuables de la sécurité (version 2.0).
Les contrôleurs de domaine fournissent le stockage physique pour la base de données Active Directory Domain Services (AD DS), en plus de fournir les services et les données qui permettent aux entreprises de gérer efficacement leurs serveurs, stations de travail, utilisateurs et applications. Si un utilisateur malveillant obtient un accès privilégié à un contrôleur de domaine, il peut modifier, endommager ou détruire la base de données AD DS et, par extension, tous les systèmes et comptes gérés par Active Directory.
Comme les contrôleurs de domaine peuvent lire et écrire dans n’importe quel élément de la base de données AD DS, la compromission d’un contrôleur de domaine signifie que votre forêt Active Directory ne peut plus être considérée comme digne de confiance, sauf si vous pouvez la récupérer à l’aide d’une sauvegarde correcte connue et corriger les failles ayant permis la compromission.
En fonction de la préparation, des outils et des compétences de l’attaquant, des dommages irréparables peuvent survenir en quelques minutes voire quelques heures, et non en jours ou en semaines. L'important n'est pas de savoir pendant combien de temps un attaquant dispose d'un accès privilégié à Active Directory, mais de savoir dans quelle mesure l'attaquant a préparé le moment où il obtiendra un accès privilégié. La compromission d'un contrôleur de domaine peut constituer le chemin le plus direct vers la destruction des serveurs membres, des stations de travail et d'Active Directory. En raison de cette menace, les contrôleurs de domaine doivent être sécurisés séparément et de manière plus stricte que l'infrastructure générale.
Sécurité physique des contrôleurs de domaine
Cette section fournit des informations sur la sécurisation physique des contrôleurs de domaine. Les contrôleurs de domaine peuvent être des machines physiques ou virtuelles, dans des centres de données, des succursales ou des sites distants.
Contrôleurs de domaine du centre de données
Contrôleurs de domaine physiques
Dans les centres de données, les contrôleurs de domaine physiques doivent être installés dans des racks ou cages sécurisés dédiés distincts de la population de serveur générale. Si possible, les contrôleurs de domaine doivent être configurés avec des puces de module de plateforme sécurisée (TPM) et tous les volumes des serveurs de contrôleur de domaine doivent être protégés via le chiffrement de lecteur BitLocker. BitLocker ajoute une petite surcharge de performances d’un chiffre en pourcentage, mais protège l’annuaire contre la compromission même si les disques sont supprimés du serveur. BitLocker peut également aider à protéger les systèmes contre les attaques de type rootkits, car la modification des fichiers de démarrage entraîne le démarrage du serveur en mode de récupération pour pouvoir charger les fichiers binaires d’origine. Si un contrôleur de domaine est configuré pour utiliser un RAID logiciel, une interface SCSI en série, un stockage SAN/NAS ou des volumes dynamiques, BitLocker ne peut pas être implémenté. Par conséquent, vous devez utiliser autant que possible un stockage attaché localement (avec ou sans RAID matériel) dans les contrôleurs de domaine.
Contrôleurs de domaine virtuels
Si vous implémentez des contrôleurs de domaine virtuels, vous devez vous assurer que les contrôleurs de domaine s’exécutent également sur des hôtes physiques distincts d’autres machines virtuelles dans l’environnement. Même si vous utilisez une plate-forme de virtualisation tierce, vous pouvez déployer des contrôleurs de domaine virtuels sur Hyper-V dans Windows Server, qui offre une surface d'attaque minimale et peut être géré avec les contrôleurs de domaine qu'il héberge plutôt que d'être géré avec le reste des hôtes de virtualisation. Si vous implémentez System Center Virtual Machine Manager (SCVMM) pour la gestion de votre infrastructure de virtualisation, vous pouvez déléguer l'administration des hôtes physiques sur lesquels résident les machines virtuelles des contrôleurs de domaine et les contrôleurs de domaine eux-mêmes aux administrateurs autorisés. Vous devriez également envisager de séparer le stockage des contrôleurs de domaine virtuels pour empêcher les administrateurs du stockage d'accéder aux fichiers des machines virtuelles.
Remarque
Si vous comptez co-localiser des contrôleurs de domaine virtualisés avec d'autres machines virtuelles moins sensibles sur les mêmes serveurs physiques de virtualisation (hôtes), vous pouvez implémenter une solution qui implante une séparation des tâches basée sur les rôles, par exemple des machines virtuelles dotées d’une protection maximale dans Hyper-V. Cette technologie offre une protection complète contre les administrateurs malveillants ou désorganisés (y compris les administrateurs de virtualisation, de réseau, de stockage et de sauvegarde). Elle s'appuie sur une racine de confiance physique avec une attestation à distance et un approvisionnement sécurisé des machines virtuelles, et assure un niveau de sécurité équivalent à celui d'un serveur physique dédié.
Succursales
Contrôleurs de domaine physiques dans les succursales
Dans les sites où résident plusieurs serveurs mais qui ne sont pas physiquement sécurisés au même degré que les serveurs du centre de données, les contrôleurs de domaine physique doivent être configurés avec des puces TPM et le chiffrement de lecteur BitLocker pour tous les volumes de serveur. Si un contrôleur de domaine ne peut pas être stocké dans une pièce verrouillée dans les succursales, vous devez déployer des contrôleurs de domaine en lecture seule (RODC) dans ces sites.
Contrôleurs de domaine virtuels dans les succursales
Dans la mesure du possible, vous devez exécuter les contrôleurs de domaine virtuels dans les succursales sur des hôtes physiques distincts des autres machines virtuelles du site. Dans les succursales où les contrôleurs de domaine virtuels ne peuvent pas fonctionner sur des hôtes physiques distincts du reste des serveurs virtuels, vous devez implémenter des puces TPM et le chiffrement de lecteur BitLocker sur les hôtes sur lesquels les contrôleurs de domaine virtuels fonctionnent au minimum, et sur tous les hôtes si possible. En fonction de la taille de la succursale et de la sécurité des hôtes physiques, vous devez déployer des RODC dans les succursales.
Sites distants avec espace et sécurité limités
Si votre infrastructure inclut des sites où seul un serveur physique unique peut être installé, un serveur capable d'exécuter des charges de travail de virtualisation doit être installé, et un chiffrement de lecteur BitLocker doit être configuré pour protéger tous les volumes du serveur. Une machine virtuelle sur le serveur doit fonctionner comme un RODC, les autres serveurs fonctionnant comme des machines virtuelles distinctes sur l'hôte. Des informations sur la planification du déploiement des contrôleurs de domaine sont fournies dans le Guide de planification et de déploiement des contrôleurs de domaine en lecture seule. Pour plus d’informations sur le déploiement et la sécurisation des contrôleurs de domaine virtualisés, consultez Exécution de contrôleurs de domaine dans Hyper-V. Pour des conseils plus détaillés sur le renforcement de la sécurité Hyper-V, la délégation de la gestion des machines virtuelles et la protection des machines virtuelles, consultez le guide de sécurité Hyper-V Solution Accelerator sur le site Web de Microsoft.
Systèmes d'exploitation de contrôleur de domaine
Vous devez exécuter tous les contrôleurs de domaine sur la version la plus récente de Windows Server prise en charge par votre organisation. Les organisations doivent donner la priorité à la mise hors service des systèmes d'exploitation hérités dans les contrôleurs de domaine. En maintenant les contrôleurs de domaine à jour et en éliminant les contrôleurs de domaine hérités, vous pouvez profiter des nouvelles fonctionnalités et de la sécurité. Cette fonctionnalité peut ne pas être disponible dans les domaines ou les forêts avec des contrôleurs de domaine exécutant un système d'exploitation hérité.
Remarque
Comme pour toute configuration sensible à la sécurité et à usage unique, nous vous recommandons de déployer le système d'exploitation dans l'option d'installation Server Core. Elle offre de multiples avantages, tels que la réduction de la surface d'attaque, l'amélioration des performances et la diminution de la probabilité d'une erreur humaine. Il est recommandé que toutes les opérations et la gestion soient effectuées à distance, à partir de points de terminaison dédiés et hautement sécurisés tels que des stations de travail à accès privilégié (PAW) ou des hôtes administratifs sécurisés.
Configuration sécurisée des contrôleurs de domaine
Des outils peuvent être utilisés afin de créer une base de configuration de sécurité initiale pour les contrôleurs de domaine, qui peut ensuite être appliquée par les GPO. Ces outils sont décrits dans la section Administrer les paramètres de stratégie de sécurité de la documentation sur les systèmes d’exploitation Microsoft ou dans la configuration d’état souhaité ( ou « DSC », pour Desired State Configuration) pour Windows.
Restrictions RDP
Les objets de stratégie de groupe liés à toutes les unités d’organisation des contrôleurs de domaine dans une forêt doivent être configurés pour autoriser les connexions RDP uniquement à partir d’utilisateurs et de systèmes autorisés, par exemple des serveurs de rebond. Un contrôle peut être obtenu avec une combinaison de paramètres de droits d’utilisateur et de configuration WFAS implémentée avec des GPO pour que la stratégie soit appliquée de manière cohérente. Si la stratégie est contournée, l’actualisation suivante de la stratégie de groupe rétablit le système avec la configuration appropriée.
Gestion des correctifs et de la configuration pour les contrôleurs de domaine
Même si ça semble contre-intuitif, vous devez appliquer les mises à jour corrective des contrôleurs de domaine et des autres composants d’infrastructure critiques séparément de votre infrastructure générale Windows. Si vous utilisez un logiciel de gestion de configuration d’entreprise pour tous les ordinateurs de l’infrastructure, une compromission du logiciel de gestion des systèmes risque de compromettre ou détruire tous les composants d’infrastructure gérés par ce logiciel. En séparant la gestion des patchs et des systèmes des contrôleurs de domaine de celle de la population générale, vous réduisez la quantité de logiciels installés sur les contrôleurs de domaine et contrôlez étroitement leur gestion.
Blocage de l’accès à Internet pour les contrôleurs de domaine
L'un des contrôles effectués dans le cadre d'une évaluation de la sécurité d'Active Directory porte sur l'utilisation et la configuration d'Internet Explorer sur les contrôleurs de domaine. Aucun navigateur web ne doit être utilisé sur les contrôleurs de domaine. Une analyse de milliers de contrôleurs de domaine a révélé de nombreux cas où des utilisateurs privilégiés ont utilisé Internet Explorer pour naviguer sur l'intranet de l'organisation ou sur Internet.
Comme décrit précédemment dans la section « Mauvaise configuration » du chapitre Voies de compromis, la navigation sur Internet ou sur un intranet infecté à partir de l’un des ordinateurs les plus puissants d’une infrastructure Windows à l’aide d’un compte hautement privilégié présente un risque très élevé pour la sécurité d’une organisation. Que ce soit par téléchargement sur un disque ou par téléchargement « d’utilitaires » infectés par des programmes malveillants, les attaquants peuvent avoir accès à tout ce dont ils ont besoin pour compromettre ou détruire complètement l'environnement Active Directory.
Bien que Windows Server et les versions actuelles d'Internet Explorer offrent de nombreuses protections contre les téléchargements malveillants, dans la plupart des cas où des contrôleurs de domaine et des comptes privilégiés ont été utilisés pour naviguer sur Internet, les contrôleurs de domaine fonctionnaient sous Windows Server 2003, ou les protections offertes par les systèmes d'exploitation et les navigateurs plus récents avaient été intentionnellement désactivées.
Le lancement de navigateurs Web sur des contrôleurs de domaine doit être limité par des stratégies et des contrôles techniques. En outre, l'accès général à Internet depuis et vers les contrôleurs de domaine doit également être strictement contrôlé.
Microsoft encourage toutes les organisations à adopter une approche de la gestion des identités et des accès informatique et à migrer d'Active Directory vers Microsoft Entra ID. Microsoft Entra ID est une solution complète de gestion des identités et des accès dans le cloud, qui permet de gérer les annuaires, d'autoriser l'accès aux applications locales et dans le cloud, et de protéger les identités contre les menaces de sécurité. Microsoft Entra ID offre également un ensemble robuste et granulaire de contrôles de sécurité pour aider à protéger les identités, notamment Multi-Factor Authentication, les stratégies d'accès conditionnel, la protection des identités, la gouvernance des identités et Privileged Identity Management.
La plupart des entreprises fonctionneront dans un modèle d'identité hybride pendant leur transition vers le cloud, où certains éléments de l'infrastructure Active Directory locale seront synchronisés à l'aide de Microsoft Entra Connect. Bien que ce modèle hybride existe dans n'importe quelle organisation, Microsoft recommande de protéger ces identités locales à l'aide de Microsoft Defender pour le cloud. La configuration du capteur Defender pour Identity sur les contrôleurs de domaine et les serveurs AD FS permet une connexion unidirectionnelle hautement sécurisée au service dans le cloud par le biais d'un proxy et sur des points de terminaison spécifiques. Une explication complète sur la façon de configurer cette connexion proxy est disponible dans la documentation technique de Defender pour Identity. Cette configuration étroitement contrôlée permet d'atténuer le risque lié à la connexion de ces serveurs au service dans le cloud, et les organisations bénéficient de l'augmentation des capacités de protection offertes par Defender pour Identity. Microsoft recommande de protéger ces serveurs par un système de détection des points de terminaison alimenté par le cloud, comme Microsoft Defender pour Serveurs.
Pour les organisations qui ont des exigences réglementaires ou d'autres stratégies pour maintenir une implémentation d'Active Directory uniquement locale, Microsoft recommande de restreindre complètement l'accès à Internet depuis et vers les contrôleurs de domaine.
Restrictions de pare-feu de périmètre
Les pare-feu de périmètre doivent être configurés pour bloquer les connexions sortantes des contrôleurs de domaine vers Internet. Bien que les contrôleurs de domaine ont parfois besoin de communiquer au-delà des limites du site, les pare-feu de périmètre peuvent être configurés pour permettre la communication intersite en suivant les directives fournies dans la section Comment configurer un pare-feu pour les domaines et les approbations Active Directory.
Empêcher la navigation Web à partir de contrôleurs de domaine
Vous pouvez utiliser une combinaison de configuration d'AppLocker, de configuration de proxy « trou noir » et de configuration WFAS pour empêcher les contrôleurs de domaine d'accéder à Internet et pour empêcher l'utilisation de navigateurs Web sur les contrôleurs de domaine.