Sécurisation des contrôleurs de domaine contre les attaques
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 accès privilégié à un contrôleur de domaine est obtenu, un utilisateur malveillant peut modifier, corrompre 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. Ce qui compte, ce n’est pas la durée pendant laquelle un attaquant a un accès privilégié à Active Directory, mais ce que l’attaquant a planifié pendant l'intervalle de temps où l’accès privilégié est obtenu. 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, 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 plateforme de virtualisation autre que Microsoft, envisagez de déployer des contrôleurs de domaine virtuels sur Hyper-V dans Windows Server. Cette configuration fournit une surface d’attaque minimale et peut être gérée 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. Vous devez donner la priorité à la mise à jour des contrôleurs de domaine et à l’élimination des contrôleurs de domaine hérités, ce qui vous permet de tirer parti des nouvelles fonctionnalités et de la sécurité. Cette fonctionnalité peut ne pas être disponible dans les domaines ou les forêts ayant des contrôleurs de domaine qui exécutent 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
Les outils peuvent être utilisés pour créer une base de référence de configuration de la sécurité initiale pour les contrôleurs de domaine à appliquer avec les objets de stratégie de groupe. 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. Le contrôle peut être obtenu à l’aide d’une combinaison de paramètres de droits utilisateur et d'une configuration WFAS (pare-feu Windows avec Advanced Security). Ces contrôles peuvent être implémentés avec des objets de stratégie de groupe afin 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’une des vérifications effectuées dans le cadre d’une évaluation de la sécurité Active Directory est l’utilisation et la configuration des navigateurs Web 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 utilisaient Internet Explorer pour naviguer sur l’intranet de l’organisation ou sur Internet.
Naviguer sur Internet ou sur un intranet infecté à partir de l’un des ordinateurs les plus puissants d’une infrastructure Windows présente un énorme risque 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.
Le lancement de navigateurs Web sur des contrôleurs de domaine doit être limité à l’aide de contrôles techniques et d'une stratégie. L’accès général à Internet vers et depuis 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 un ensemble robuste et granulaire de contrôles de sécurité pour aider à protéger les identités, tels que l’authentification multifacteur, les stratégies d’accès conditionnel, la protection des ID, la gouvernance des identités et Privileged Identity Management.
La plupart des organisations fonctionnent dans un modèle d’identité hybride pendant leur transition vers le cloud, où certains éléments de leur Active Directory local sont synchronisés à l’aide de Microsoft Entra Connect. Bien que ce modèle hybride existe dans n’importe quelle organisation, Microsoft recommande une protection gérée par le cloud de ces identités locales à l’aide de Microsoft Defender pour Identity. La configuration du capteur Defender pour Identity sur les contrôleurs de domaine et les serveurs AD FS permet une connexion unidirectionnelle sécurisée au cloud via un proxy et 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 ayant des exigences réglementaires ou d’autres exigences liées à des stratégies pour maintenir une implémentation locale d’Active Directory uniquement, Microsoft recommande de restreindre entièrement l’accès Internet vers et depuis 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 puissent avoir besoin de communiquer au-delà des limites du site, les pare-feu de périmètre peuvent être configurés pour autoriser les communications intersites en suivant les instructions fournies dans 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.