Active Directory : Huit bonnes pratiques de sécurité

Le facteur humain, les individus représentent le maillon faible des systèmes d'information. A plus forte raison, les individus auxquels ont été accordés des comptes à privilèges dans l'Active Directory de l'entreprise.

Ces derniers sont indispensables mais doivent faire l'objet de plus grandes précautions que l'utilisateur lambda .... Les comptes à privilèges constituent un risque réel et majeur. Pour autant, il n’est pas possible de s’en passer puisque leur usage est l’une des conditions incontournables du bon fonctionnement des systèmes en entreprise. Heureusement, il existe des étapes éprouvées à mettre en œuvre pour réduire le risque d’une utilisation frauduleuse des comptes à privilèges, délibérée ou accidentelle, et rétablir le bon fonctionnement aussi vite que possible si ces mesures préventives venaient à échouer.
Voici huit bonnes pratiques à observer.
1. Limiter le nombre de comptes à privilèges
Il est vital de contrôler de façon stricte les membres des groupes à privilèges. La liste en est assez longue et inclut notamment les administrateurs de domaine, les créateurs et propriétaires de stratégies de groupe, les administrateurs d’entreprise, les contrôleurs de domaines, les administrateurs de schémas, les opérateurs de configuration réseau, les opérateurs serveurs, les administrateurs du DHCP et pour finir les opérateurs de sauvegarde.
Il convient également de contrôler avec soin tous les objets de stratégie de groupe (GPO) qui s’appliquent sur les contrôleurs de domaine ainsi que tous les logiciels installés sur les DC. Par exemple, si un agent est installé, ceux qui ont accès à cet agent pourraient très bien être des administrateurs de domaine.
La meilleure façon de contrôler les accès effectués à partir de comptes à privilèges est d’utiliser une solution de gestion de comptes à privilèges ou PAM (privilege account management) et de gestion de sessions nécessitant une élévation de comptes à privilèges ou PSM (privilege session management), dont l’approbation est effectuée manuellement. Quant à la supervision des niveaux d’accès risquant d’avoir un impact sur tout un domaine, elle doit être effectuée en temps réel. Comme nul ne devrait administrer seul les contrôleurs de domaine au quotidien, il est raisonnable d’avoir deux personnes présentes : une personne qui se charge du travail et une autre qui supervise. Même si la supervision se fait à distance ou par un collègue, cela réduit le risque qu’un individu malveillant mette à mal votre activité. De plus, la responsabilisation et deux paires d’yeux réduisent le risque que des erreurs coûteuses soient commises.
2. Sécuriser les comptes à l’aide d’un modèle Red Forest
Il peut être très difficile de renforcer suffisamment les forêts de production pour protéger les comptes admin à privilèges les plus critiques sans entraver le bon fonctionnement au sein du domaine. C’est pourquoi Microsoft propose de maintenir ces comptes dans une forêt administration dédiée, dont le nom officiel est "Enhanced Security Admin Environment" (ESAE) mais que l’on appelle "Red Forest", la couleur rouge désignant la nature critique des identifiants.
L’une des caractéristiques de ce modèle Red Forest est que les comptes admin sont répartis entre trois niveaux de sécurité :
• Niveau 0 — Autorité admin de toute la forêt (administrateurs d’entreprise)
• Niveau 1 — Autorité administrative des serveurs, applications et cloud
• Niveau 2 — Contrôle administratif des postes de travail et des terminaux
En plaçant tous les comptes de Niveau 0 dans une forêt séparée, il devient possible de mieux les surveiller et y appliquer plus facilement des mesures de sécurité supplémentaires, comme les contraindre à se connecter à partir d’un poste de travail à la sécurité renforcée ou à appliquer l’authentification à deux facteurs.
Bien sûr, il n’est pas simple de déployer une forêt d’administration mais on peut se faire aider dans cette tâche.
3. Tester les changements avant le passage en production
Pour réduire le risque d’erreurs néfastes pour l’Active Directory, il est préférable d’installer un laboratoire de test pour y étudier l’impact des mises à niveau et autres changements avant leur passage en production. Plus le test lab ressemble à l’environnement de production, mieux c’est.
4. Auditer.
Il est important de réaliser des audits complets pour plusieurs raisons. C’est un moyen de responsabilisation qui permet de contrer les agissements de collaborateurs malveillants tout en incitant les détenteurs de comptes à privilèges bien intentionnés à agir soigneusement pour réduire le nombre et la gravité des erreurs. C’est aussi un bon moyen pour savoir rapidement ce qui s’est mal passé et prendre des mesures correctives, et empêcher que la situation ne se reproduise. Il est important d’inclure dans votre piste d’audit les événements natifs, les journaux de sécurité système des applications, les journaux des services d’annuaires et d’autres données critiques. Il faut également s’assurer de pouvoir examiner rapidement les données, y faire des recherches et les analyser. Le système d’audit doit impérativement demeurer accessible en cas de panne d’AD.
5. Surveiller les changements critiques et donner l’alerte.
Il faut s’assurer d’être averti immédiatement en cas de changement d’un objet critique, comme un groupe à privilèges ou une GPO pouvant affecter les contrôleurs de domaines. Comme ces changements sont normalement très rares, les alertes le seront logiquement aussi. Les alertes concernant des changements légitimes servent de confirmation que le système de surveillance fonctionne correctement. Et les alertes concernant des changements non autorisés permettent d’agir rapidement pour éviter de lourdes conséquences potentielles.
6. Documenter l’architecture Active Directory
Il est essentiel de prendre le temps de documenter la structure AD, de maintenir ce dossier à jour et de le conserver accessible même hors ligne (dans OneDrive, par exemple), de manière à y accéder même si AD est en panne. Il faut y inscrire les informations suivantes : forêts, domaines, trusts, DNS, sous-réseaux et liens de réplication entre eux.
Chaque contrôleur de domaine doit y figurer, y compris son adresse IP, sa position physique, quel domaine il contrôle, les rôles FSMO (Flexible Single Master Operations) le concernant, et s’il s’agit d’un catalogue global.
7. Sauvegarder Active Directory
Sauvegarder Active Directory avec une solution de sauvegarde d’entreprise est important. Se limiter à la seule option de récupération depuis la corbeille est très risqué.
La corbeille a un aspect pratique, mais elle présente de sérieuses limites. Il est en effet facile de bloquer l’AD rien qu’en supprimant l’ensemble des enregistrements DNS. Et plutôt que de supprimer les enregistrements, un utilisateur malveillant pourrait remplacer les paramètres par des adresses IP non valides. La corbeille n’aidera pas à restaurer ces attributs.
8. Tester les sauvegardes
Il est vital de considérer les sauvegardes comme étant défaillantes jusqu’à preuve du contraire. Pour vérifier la viabilité d’une sauvegarde il suffit de la monter et d’essayer de lire un objet qu’elle contient. Reconstituer de temps en temps la forêt Active Directory dans un environnement test est une bonne pratique. Cela permet de vérifier s’il est possible de restaurer le système après un problème grave et surtout ... le faire rapidement.
Le fait de suivre ces bonnes pratiques réduit les chances d’être exposé à ces scénarios catastrophes, mais il est impossible d’éliminer totalement le risque. Il faut donc prendre des mesures en vue d’une restauration rapide d’Active Directory, y compris par une piste d’audit complète et le recours à des sauvegardes fiables. Certaines solutions permettent de reconstruire toute une forêt Active Directory en un simple clic et il est important de s’en doter car restaurer l’Active Directory n’est pas aussi simple que de restaurer quelques fichiers supprimés récemment. Ce type de restauration n’est ni facile à tester ni à simuler, en partie parce que la procédure de restauration AD dépend du scénario spécifique du sinistre