Durcir un Active Directory : les mesures défensives

Après trois leçons passées du côté de l'attaquant, voici le côté qui fait vraiment la différence : le durcissement. Un white hat n'est pas payé pour montrer qu'un annuaire est fragile, mais pour aider à le rendre solide. Cette leçon rassemble les mesures de défense essentielles et vous apprend à les présenter comme des recommandations priorisées, ce qui fera la qualité de vos futurs rapports.

Le principe directeur : réduire les chemins

Souvenez-vous du graphe de la leçon 2. Durcir un annuaire, c'est supprimer les arêtes dangereuses : retirer les droits qui ne servent pas, séparer les usages, rendre les comptes privilégiés difficiles à voler. Une mesure se juge à un critère simple : combien de chemins vers les comptes privilégiés supprime-t-elle ?

L'ANSSI (cyber.gouv.fr) publie des guides de référence sur la sécurisation et l'administration d'annuaires Active Directory. Consultez-les : ils sont rédigés par des experts et mis à jour. Les mesures ci-dessous en reprennent l'esprit, sans les remplacer.

1. Séparer les niveaux d'administration

L'idée du modèle en niveaux (tiering) est de ne jamais mélanger les mondes. On distingue en général :

• le niveau 0 : le cœur de l'identité (contrôleurs de domaine, comptes qui les administrent) ;
• le niveau 1 : les serveurs applicatifs ;
• le niveau 2 : les postes de travail et les utilisateurs.

La règle est qu'un compte d'un niveau supérieur ne se connecte jamais à une machine d'un niveau inférieur. Pourquoi ? Parce qu'une session ouverte laisse des traces d'authentification en mémoire sur la machine. Si un administrateur de domaine se connecte à un poste ordinaire, ce poste, plus exposé aux courriels piégés et aux navigateurs, devient un moyen de voler son identité. Comme dans un hôpital où la salle d'opération ne se partage pas avec la salle d'attente.

2. Un compte pour chaque usage

Un administrateur doit avoir deux comptes au minimum : un compte ordinaire pour lire ses courriels et naviguer, un compte d'administration réservé aux tâches d'administration, sur des postes dédiés. Ce simple principe coupe un grand nombre de chemins d'attaque. Le compte d'administration ne doit ni avoir de boîte aux lettres, ni servir à naviguer sur Internet.

3. Mots de passe de comptes à privilèges et comptes de service

Trois mesures ciblent les mots de passe :

• LAPS (Local Administrator Password Solution, ou solution équivalente) : chaque machine possède un mot de passe d'administrateur local unique et renouvelé automatiquement. Sans cela, le même mot de passe sur tous les postes permet à un attaquant de se déplacer de machine en machine.
• Les comptes de service gérés (gMSA) : le système génère et renouvelle le mot de passe, très long, sans intervention humaine, ce qui répond directement au problème vu avec le Kerberoasting.
• Une politique de mots de passe adaptée, privilégiant la longueur et la vérification contre des mots de passe déjà compromis, plutôt que des règles de complexité artificielles.

4. Protéger les comptes les plus sensibles

Certains mécanismes natifs durcissent la situation des comptes de niveau 0 : un groupe de sécurité dédié aux utilisateurs protégés désactive plusieurs mécanismes d'authentification faibles pour ses membres et limite la durée des tickets. Les comptes d'administration y trouvent leur place, après test, car certaines applications anciennes peuvent ne plus fonctionner.

Pensez aussi aux délégations : repérez celles qui sont non contraintes (leçon 1), remplacez-les par des formes plus limitées, ou supprimez-les. Marquez les comptes très sensibles comme « non délégables ».

5. Fermer les protocoles faibles

Certains protocoles anciens restent actifs par compatibilité et offrent des prises aux attaquants. Les mesures classiques sont :

• Réduire puis désactiver NTLM lorsque c'est possible, en commençant par auditer qui l'utilise encore.
• Exiger la signature pour le partage de fichiers (SMB) et pour les requêtes d'annuaire (LDAP), afin d'empêcher la modification des échanges en cours de route.
• Désactiver les composants inutiles sur les contrôleurs de domaine : plus un serveur fait de choses, plus il expose de surface.

La méthode est toujours la même : auditer d'abord (qui utilise quoi ?), corriger ensuite, surveiller enfin. Couper un protocole sans audit préalable casse parfois une application métier critique.

6. Journaliser et surveiller

Un annuaire durci mais muet reste un angle mort. Il faut activer les journaux d'audit pertinents et les envoyer vers un point central (nous verrons le SIEM au chapitre 4). Les événements à suivre en priorité : modifications de groupes privilégiés, création de comptes, demandes inhabituelles de tickets, connexions d'administration en dehors des horaires habituels, modifications de stratégies de groupe.

7. Auditer régulièrement

La sécurité d'un annuaire se dégrade avec le temps : on ajoute des comptes, on accorde un droit « temporaire » qui devient permanent, on oublie une approbation. Il faut donc des revues régulières : liste des comptes privilégiés, comptes inactifs, comptes de service, délégations, approbations. Des outils d'audit gratuits ou open source produisent des synthèses de risque. Les mêmes outils que ceux de l'attaquant, utilisés pour la défense, forment la boucle de progrès continue : auditer → corriger → vérifier à nouveau.

Comment présenter ces mesures dans un rapport

Un auditeur ne dit pas simplement « activez LAPS ». Il présente la mesure sous cette forme :

Ce format (constat, risque, recommandation, priorité) sera au cœur du chapitre 6.

À vous de jouer

Dernière pièce du chapitre pour votre portfolio : une fiche de durcissement d'une page pour l'annuaire fictif atelier.lab.

1. Listez cinq mesures extraites de cette leçon.
2. Pour chacune, notez le chemin d'attaque qu'elle coupe (reprenez les exemples des leçons 1 à 3).
3. Classez les mesures en trois vagues : « dès cette semaine », « ce trimestre », « à planifier ».
4. Indiquez pour chacune comment vous vérifierez qu'elle est efficace.