Lire la série complète :
|
Chapitre 1 – Protéger Active Directory Domain Services |
Chaque composant du datacenter moderne exige une authentification sous une forme ou sous une autre. Microsoft Active Directory Services contient des informations sur les objets individuels de la forêt et stocke les données nécessaires dans une base de données relationnelle (ntds.dit). Les contrôleurs de domaines constituent les têtes de l’infrastructure régissant l’accès aux ressources au moyen d’un processus d’authentification et de connexion. Également quand un utilisateur tente d’accéder à un fichier sur le serveur de fichier de domaine de l’entreprise. Kerberos et NTLM sont des protocoles d’authentification utilisés pour vérifier l’identité d’un ordinateur ou d’un utilisateur. Le moins qu’on puisse dire, c’est que l’authentification est essentielle à la continuité de l’activité.
Concevoir pour la haute disponibilité
Les informaticiens professionnels et les ingénieurs font très attention et planifient rigoureusement pour architecturer soigneusement une infrastructure Active Directory Domain Services hautement disponible afin d’éliminer les problèmes potentiels. Si un seul contrôleur de domaine est indisponible (à cause d’une panne de réseau ou un redémarrage pendant l’application d’un patch par exemple), nous ne voulons pas que toutes les communications soient interrompues et nous intégrons la résilience. Microsoft Active Directory Sites and Services (dssite.msc) gère le moteur de réplication ou l’intervalle pendant lequel la réplication entre contrôleurs de domaines se produit. Cela permet d’assurer que les plus récents changements sont automatiquement généralisés sur tous les sites. Une meilleure pratique consiste à créer un « lag site », un site de l’environnement considérablement mis à l’écart de la réplication normale. Ces valeurs sont gérées selon un modèle de coûts et d’intervalles. Les sites dont le coût et l’intervalle de réplication sont les plus importants ont la moindre priorité. En cas de suppression accidentelle d’une unité organisationnelle (OU), il serait tragique de voir cela immédiatement répliqué dans l’ensemble de l’environnement, d’où le lag site.
Exemple 1 : Active Directory Sites and Services – coût et intervalle de réplication
Heureusement pour ceux qui emploient Veeam Backup & Replication, nous pouvons restaurer des objets individuels ou des attributs d’objets rapidement, facilement et de manière fiable au cas où quelque chose serait modifié ou supprimé par erreur. Ceci est effectué en tirant parti de Veeam Explorer pour Microsoft Active Directory.
Détenir les clés du château
Active Directory (AD) comporte de nombreux groupes de sécurité globaux prédéfinis. Certains sont destinés aux objets ordinateurs et d’autres aux objets utilisateurs. Par exemple :
- administrateurs de domaine ;
- administrateurs de l’entreprise ;
- administrateurs de schémas ;
- utilisateurs de domaine ;
- contrôleurs de domaine ;
- ordinateurs de domaine.
Afin de mettre en œuvre avec succès la délégation, il est important de comprendre comment les modèles de sécurité fonctionnent dans AD. À mon avis, c’est en fait très simple, de manière très semblable à NTFS. Les permissions définies au niveau le plus élevé peuvent se propager à travers les unités organisationnelles et les objets imbriqués dans les limites de la hiérarchie du domaine.
Les accidents ne manquent pas de se produire ! Que se passe-t-il si Jean du service d’assistance supprime accidentellement l’unité organisationnelle de tous les comptes de service de l’infrastructure SQL ? Ce serait une bien mauvaise journée ! Pour assurer une protection contre les erreurs humaines ou pire, les malveillances, il convient de superviser étroitement les appartenances à ces groupes. Un audit périodique devrait avoir lieu pour valider les comptes utilisateurs qui ont accès aux groupes. Une meilleure pratique consiste à créer des comptes de service (svc-xxxx) pour tous les comptes utilisateurs basés sur les applications et des comptes administratifs (admin-xxxx) pour tous les comptes d’accès élevé au moyen desquels les utilisateurs individuels se connectent. Par exemple, mon compte de domaine habituel, cwyckoff ne serait JAMAIS autorisé dans le groupe Domain Admins. Pour cela, je devrais créer et utiliser admin-cwyckoff. De plus, pensez à utiliser des caractères aléatoires tels que les identifiants des collaborateurs en tant que comptes utilisateurs (par ex., v123456 ou admin-v123456). Cela compliquera les choses pour les pirates extérieurs qui tenteraient de deviner les noms de comptes pour mener des attaques en force brute en fonction de conventions de nommage connues.
Déléguer des rôles à d’autres membres du service informatique est une excellente manière d’inciter d’autres membres de l’équipe à mener des activités. En règle générale, dans les grandes entreprises IT, les équipes d’ingénierie et d’architecture gèrent le service d’authentification d’Active Directory et délèguent les contrôles et les accès à des équipes d’administrateurs et d’opérateurs. Pour cela, vous devez tirer parti de l’outil intégré d’Active Directory Users and Computers (dsa.msc). Il est facile et rapide de déléguer des accès à des utilisateurs individuels ou des groupes d’utilisateurs pour leur permettre d’effectuer des tâches courantes. Par exemple, « Joindre un ordinateur au domaine » ou « Réinitialiser des mot de passe utilisateur et forcer leur changement au prochain logon ». Vous pouvez également créer une tâche personnalisée si ce que vous souhaitez accomplir n’est pas défini parmi les tâches courantes prêtes à l’emploi de l’assistant. Recenser les tâches que chaque utilisateur ou groupe d’utilisateurs peuvent effectuer nous permet d’adopter une approche basée sur les rôles. C’est une bonne pratique et une excellente manière d’assurer que les équipes appropriées disposent exactement des permissions nécessaires pour effectuer leur travail — rien de plus et rien de moins.
Exemple 2 : Assistant intégré de délégation de contrôle
Conclusion
L’authentification de domaine est un composant stratégique de l’infrastructure trop fréquemment négligé. Souvent, les membres exécutant les services de domaine ne peuvent pas prendre le temps de définir le rôle spécifique de chaque membre du service informatique. La manière la plus facile de traiter la question est d’accorder des permissions excessives, ce qui présente rapidement de grands dangers. Mettre en place des stratégies de protection locales parallèlement à une architecture hautement résiliente permet à tous les composants de fonctionner d’une manière optimale. Dans le prochain article, nous aborderons les pannes de sites entiers et les composants de restauration ainsi que la manière dont vous pouvez tirer parti des Read-only Domain Controllers (RODC) pour sécuriser encore plus votre environnement AD.
Lire le chapitre suivant :
- Chapitre 2 – Read-Only Domain Controller (RODC)
