Sécurisation des contrôleurs de domaine contre les attaques

Loi n° 3 : Si un mauvais acteur a 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.

Étant donné que les contrôleurs de domaine peuvent lire et écrire dans n’importe quoi dans la base de données AD DS, la compromission d’un contrôleur de domaine signifie que votre forêt Active Directory ne peut jamais être considérée comme fiable, sauf si vous pouvez la récupérer à l’aide d’une sauvegarde correcte connue et fermer les lacunes qui ont permis la compromission.

En fonction de la préparation, de l’outil et de la compétence d’un attaquant, les dommages irréparables peuvent être effectués en minutes ou en heures, et non en jours ou semaines. Ce qui importe n’est pas la durée pendant laquelle un attaquant a un accès privilégié à Active Directory, mais la préparation de l’attaquant au moment de l’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 pour les 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 de 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 quantité de surcharge de performances, mais protège le répertoire contre la compromission même si les disques sont supprimés du serveur. BitLocker peut également protéger les systèmes contre les attaques telles que les rootkits, car la modification des fichiers de démarrage entraîne le démarrage du serveur en mode de récupération afin que les fichiers binaires d’origine puissent être chargés. 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 virtuel

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 de 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 du contrôleur 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.

Note

Si vous envisagez de colocaliser des contrôleurs de domaine virtualisés avec d’autres machines virtuelles moins sensibles sur les mêmes serveurs de virtualisation physique (hôtes), envisagez d’implémenter une solution qui applique la séparation basée sur les rôles des tâches, comme les machines virtuelles protégées dans Hyper-V. Cette technologie offre une protection complète contre les administrateurs de structure malveillants ou non formés (notamment la virtualisation, le réseau, le stockage et les administrateurs de sauvegarde). Il utilise la racine physique de confiance avec l’attestation distante et le provisionnement de machines virtuelles sécurisées, et garantit efficacement un niveau de sécurité égal à celui d’un serveur physique dédié.

Emplacements de branche

Contrôleurs de domaine physiques dans les branches

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 salle verrouillée dans des emplacements de branche, vous devez envisager de déployer Read-Only contrôleurs de domaine (RODC) dans ces emplacements.

Contrôleurs de domaine virtuel dans les branches

Dans la mesure du possible, vous devez exécuter des contrôleurs de domaine virtuels dans des filiales sur des hôtes physiques distincts des autres machines virtuelles du site. Dans les succursales où les contrôleurs de domaine virtuel ne peuvent pas s’exécuter sur des hôtes physiques distincts du reste de la population du serveur virtuel, 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 s’exécutent, 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.

Emplacements distants avec un espace et une sécurité limités

Si votre infrastructure inclut des emplacements où un seul serveur physique peut être installé, un serveur capable d’exécuter des charges de travail de virtualisation doit être installé et le chiffrement de lecteur BitLocker doit être configuré pour protéger tous les volumes sur le serveur. Une machine virtuelle sur le serveur doit s’exécuter en tant que rodc et d’autres serveurs doivent s’exécuter en tant que 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 obtenir des conseils plus détaillés sur le renforcement de la sécurité d’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.

Systèmes d’exploitation du contrôleur de domaine

Vous devez exécuter tous les contrôleurs de domaine sur la dernière version 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. La hiérarchisation de la conservation des contrôleurs de domaine actuels et l’élimination des contrôleurs de domaine hérités 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 forêts avec des contrôleurs de domaine exécutant des systèmes d’exploitation hérités.

Note

Comme pour toute configuration à usage unique et sensible à la sécurité, nous vous recommandons de déployer le système d’exploitation à l’aide de l’option d’installation Server Core . Il offre plusieurs avantages, tels que la réduction de la surface d’attaque, l’amélioration des performances et la réduction de la probabilité d’une erreur humaine. Nous vous recommandons d’effectuer toutes les opérations et la gestion à distance, à partir de points de terminaison dédiés et hautement sécurisés, tels que les stations de travail à accès privilégié (PAW) ou les hôtes administratifs sécurisés.

Configuration sécurisée des contrôleurs de domaine

Vous pouvez utiliser des outils pour créer une base de référence de configuration de sécurité initiale pour que les contrôleurs de domaine soient appliqués avec des objets de stratégie de groupe. Ces outils sont décrits dans Administrer les paramètres de stratégie de sécurité et la vue d’ensemble de La configuration de l’état souhaité.

Restrictions RDP

Les objets de stratégie de groupe qui relient toutes les unités d’organisation du contrôleur 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, tels que des serveurs de rebond. Le contrôle peut être obtenu à l’aide d’une combinaison de paramètres de droits utilisateur et du Pare-feu Windows avec la configuration 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 correctifs et des systèmes pour les contrôleurs de domaine de la population générale, vous pouvez réduire la quantité de logiciels installés sur les contrôleurs de domaine en plus de contrôler é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 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ù les utilisateurs privilégiés utilisaient Internet Explorer pour parcourir l’intranet de l’organisation ou 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 via un lecteur en téléchargeant ou en téléchargeant des « utilitaires » infectés par des programmes malveillants, les attaquants peuvent accéder à tout ce dont ils ont besoin pour compromettre complètement ou détruire l’environnement Active Directory.

Vous devez restreindre le lancement de navigateurs web sur des contrôleurs de domaine à l’aide de contrôles techniques et de stratégie. L’accès à Internet général aux contrôleurs de domaine doit également être strictement contrôlé.

Nous encourageons toutes les organisations à passer à une approche basée sur le cloud pour la gestion des identités et des accès et la migration d’Active Directory vers l’ID Microsoft Entra. 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 protéger les identités, telles 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 opèrent 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 via Microsoft Entra Connect. Bien que ce modèle hybride existe dans n’importe quelle organisation, nous vous recommandons de protéger les identités locales via 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 unidirectionnel sécurisée au cloud via un proxy et des points de terminaison spécifiques. Pour obtenir une explication complète de la configuration de cette connexion proxy, consultez 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. Nous vous recommandons également de protéger ces serveurs avec la détection de point de terminaison cloud, comme Microsoft Defender pour serveurs.

Pour les organisations qui ont des exigences réglementaires ou d’autres exigences basées sur des stratégies pour maintenir une implémentation locale uniquement d’Active Directory, nous vous recommandons de restreindre entièrement l’accès à Internet à des contrôleurs de domaine et à partir de ces derniers.

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 entre les limites de site, vous pouvez configurer des pare-feu de périmètre pour autoriser la communication intersite en suivant les instructions fournies dans Comment configurer un pare-feu pour les domaines et approbations Active Directory.

Empêcher la navigation web des contrôleurs de domaine

Vous pouvez utiliser une combinaison de configuration AppLocker, de configuration de proxy « trou noir » et du Pare-feu Windows avec une configuration de sécurité avancée pour empêcher les contrôleurs de domaine d’accéder à Internet et d’empêcher l’utilisation de navigateurs web sur les contrôleurs de domaine.