Modèle en niveaux Active Directory et conception de l'accès privilégié

Active Directory reste la colonne vertébrale d'identité de la plupart des entreprises et, précisément parce qu'il est partout, c'est le terrain où un seul identifiant volé peut devenir un contrôle sur tout le domaine. La raison est structurelle : les administrateurs ouvrent une session sur des postes de travail ordinaires, ces postes sont compromis, et l'attaquant récolte les identifiants privilégiés laissés en mémoire. Le modèle en niveaux et la conception de l'accès privilégié existent pour briser cette chaîne. Cet article explique le modèle du point de vue du défenseur, dans le cadre comprendre pour défendre : pourquoi la confiance plate par défaut est dangereuse, comment le modèle en niveaux contient le déplacement latéral, quelle télémétrie révèle l'abus et quels contrôles durcissent tout le parc.

Pourquoi l'identité est le vrai périmètre

Les périmètres réseau se sont dissous dans les services cloud, le travail à distance et les appareils mobiles, et ce qui demeure constant est l'identité. Dans un parc Windows, cette identité vit dans Active Directory, et ses groupes les plus privilégiés — Admins du domaine, Admins de l'entreprise et les comptes qui contrôlent les contrôleurs de domaine — sont en pratique les clés de tout. Un attaquant qui atteint ce niveau peut lire chaque boîte aux lettres, déployer du logiciel sur chaque point de terminaison et forger des identifiants à volonté. Défendre le parc signifie donc défendre ces identités comme si elles étaient les joyaux de la couronne, car elles le sont.

La vérité inconfortable d'un Active Directory par défaut est qu'il fait confiance de façon trop plate. Si un Admin du domaine ouvre un jour une session sur un poste de support, ce poste détient désormais du matériel qu'un attaquant peut voler pour devenir Admin du domaine. Multipliez cela sur des années d'ouvertures de session commodes et vous obtenez un parc où compromettre presque n'importe quelle machine est un chemin plausible vers le contrôle total. Le modèle en niveaux est la discipline qui coupe ces chemins à dessein.

Le modèle en niveaux expliqué

Le modèle administratif en niveaux divise les actifs et les identités qui les gèrent en niveaux selon la valeur qu'ils contrôlent. Le Niveau 0 détient l'infrastructure d'identité elle-même : contrôleurs de domaine, base de données AD, autorités de certification, serveurs de fédération et tout compte ou groupe pouvant en prendre le contrôle. Le Niveau 1 couvre serveurs et applications — les données et services métier de l'entreprise. Le Niveau 2 est la couche des postes de travail et appareils où opèrent les utilisateurs ordinaires et le personnel qui les soutient. Le but de la division est une règle stricte sur quels identifiants peuvent apparaître sur quels systèmes.

Le principe directeur est qu'un identifiant de niveau supérieur ne doit jamais être exposé sur un système de niveau inférieur. Un compte de Niveau 0 n'ouvre de session que sur des systèmes de Niveau 0 ; il ne touche jamais un serveur de Niveau 1 ni un poste de Niveau 2, car ceux-ci sont plus nombreux, plus exposés et plus susceptibles d'être compromis. Cela prévient l'escalade classique où un attaquant qui possède un poste attend qu'un administrateur ouvre une session puis vole le jeton ou l'identifiant de cet administrateur. Quand les niveaux sont imposés, le puissant identifiant de cet administrateur n'atterrit tout simplement jamais là où l'attaquant peut l'atteindre.

Sources propres et postes d'administration

Le modèle en niveaux dépend du principe de source propre : un système ne peut être contrôlé que par des systèmes au moins aussi dignes de confiance que lui. Si un contrôleur de domaine de Niveau 0 peut être géré depuis un portable de Niveau 2, alors le portable est de fait Niveau 0, et la frontière est une fiction. Pour honorer cela, les administrateurs utilisent des postes de travail à accès privilégié dédiés — des machines durcies à usage unique employées uniquement pour le travail administratif, sans courriel, sans navigation web et sans logiciel de productivité général susceptible d'introduire une compromission.

Un poste de travail à accès privilégié est verrouillé par une liste d'autorisation d'applications, des règles réseau strictes qui ne lui permettent d'atteindre que des points de terminaison de gestion et une authentification multifacteur forte. Le portable quotidien où un administrateur lit son courriel et navigue sur le web est traité comme non fiable à des fins administratives. Séparer la machine avec laquelle vous exploitez le domaine de celle avec laquelle vous consultez votre agenda est l'un des contrôles de plus grande valeur de tout le modèle, car il retire directement le point d'appui de récolte de mémoire sur lequel s'appuient les attaquants.

Comptes séparés et accès juste-à-temps

Chaque administrateur devrait détenir des identités distinctes pour des niveaux distincts : un compte utilisateur normal pour le travail quotidien et des comptes privilégiés séparés limités au niveau qu'il administre, jamais réutilisés entre niveaux. L'appartenance permanente à des groupes puissants comme les Admins du domaine devrait être réduite à presque rien. La pratique moderne remplace l'appartenance permanente par l'élévation juste-à-temps, où un administrateur demande l'accès pour une tâche précise et une fenêtre limitée, la demande est approuvée et journalisée, et le privilège s'évapore à la fermeture de la fenêtre. Les outils de gestion des accès privilégiés rendent ce flux praticable à grande échelle.

Cela rétrécit la fenêtre durant laquelle un identifiant privilégié existe seulement pour être volé. Cela produit aussi une piste d'audit propre : chaque usage de privilège élevé est un événement délibéré, enregistré et limité dans le temps plutôt qu'une condition permanente. Combiné à une authentification forte et, lorsque possible, à des identifiants sans mot de passe ou adossés à une carte à puce pour les administrateurs, l'accès juste-à-temps transforme le privilège d'un passif constant en une ressource contrôlée et observable.

Détection : signaux qui révèlent l'abus

Même un parc bien découpé en niveaux doit supposer que des attaquants déterminés sonderont les frontières, aussi la détection est-elle essentielle. Surveillez directement les violations de niveau : un compte de Niveau 0 s'authentifiant depuis un poste de Niveau 2 est une alarme de haute fidélité car cela ne devrait jamais arriver. Surveillez les journaux de sécurité Windows pour des schémas d'ouverture de session suspects — les Event ID 4624 et 4625 montrant des comptes privilégiés apparaissant sur des hôtes inattendus, le 4672 marquant l'attribution de privilèges sensibles, et les 4768 et 4769 enregistrant des demandes de tickets Kerberos pouvant indiquer des techniques d'abus d'identifiants contre des comptes de service.

Les changements aux groupes de Niveau 0 méritent un examen immédiat : les Event ID 4728, 4732 et 4756 enregistrent les ajouts à des groupes privilégiés, et un ajout inattendu aux Admins du domaine est l'un des signaux les plus forts d'une compromission en cours. Les demandes de réplication d'annuaire depuis un hôte qui n'est pas un contrôleur de domaine peuvent indiquer une tentative d'extraire toute la base de données d'identifiants et devraient alerter quelqu'un aussitôt. Alimentez ces signaux dans un SIEM avec alertes, conservez les journaux hors des contrôleurs de domaine afin qu'un attaquant ne puisse les effacer, et répétez la réponse pour qu'une alerte mène à l'action plutôt qu'à un tableau de bord que personne ne regarde.

Pièges courants

L'échec le plus courant est de concevoir un beau modèle en niveaux sur le papier puis de le briser par commodité — un compte de Niveau 0 utilisé une fois pour réparer un serveur de Niveau 1, un compte de service avec des droits d'Admin du domaine tournant sur des dizaines de serveurs d'application, ou des appartenances de groupe imbriquées qui accordent en silence un pouvoir de Niveau 0 à un groupe d'apparence inoffensive. Les comptes de service sont un point faible récurrent : surprivilégiés, rarement renouvelés et souvent configurés de façons qui les exposent à des techniques de vol d'identifiants, ils sont fréquemment le pont qu'un attaquant emprunte pour traverser les niveaux. Un autre piège est d'oublier que les autorités de certification et les serveurs de fédération d'identité sont de Niveau 0 ; des modèles de certificat mal configurés sont devenus un chemin d'escalade prisé précisément parce qu'ils sont souvent négligés.

Enfin, les équipes traitent parfois le modèle en niveaux comme un projet ponctuel. En réalité, le parc dérive sans cesse à mesure qu'apparaissent de nouveaux serveurs, délégations et administrateurs, de sorte que sans un audit continu de l'appartenance aux groupes, de la délégation et des droits d'ouverture de session, les frontières s'érodent jusqu'à ce que le modèle n'existe plus que dans un document.

Une liste de contrôle pratique

Structure : actifs classés en Niveau 0, 1 et 2 ; contrôleurs de domaine, autorités de certification et serveurs de fédération reconnus comme Niveau 0. Identifiants : comptes séparés par niveau, aucune réutilisation entre niveaux, identifiants de niveau supérieur jamais exposés sur des systèmes de niveau inférieur. Accès : postes de travail à accès privilégié pour toute administration de Niveau 0 et Niveau 1, liste d'autorisation d'applications, authentification multifacteur forte. Privilège : appartenance permanente quasi nulle aux Admins du domaine, élévation juste-à-temps avec approbation et journalisation, comptes de service durcis et surveillés. Détection : alertes sur les violations de niveau, les changements de groupes privilégiés et la réplication anormale, journaux conservés hors des contrôleurs de domaine. Gouvernance : audit continu de l'appartenance, de la délégation et des droits d'ouverture de session.

FAQ : Le modèle en niveaux est-il encore pertinent avec le cloud et Zero Trust ?

Oui, et davantage encore. Zero Trust et le modèle en niveaux partagent la même idée centrale : ne jamais supposer la confiance selon l'emplacement réseau, et toujours minimiser et vérifier le privilège. En environnements hybrides, le modèle s'étend à l'identité cloud, où vous protégez les comptes qui contrôlent votre synchronisation d'annuaire et vos rôles administratifs cloud avec la même rigueur que le Niveau 0 sur site. Le vocabulaire évolue, mais le principe selon lequel les identités les plus puissantes doivent être isolées des systèmes les plus exposés est intemporel.

FAQ : Nous sommes une petite organisation. Avons-nous besoin d'un découpage complet ?

Vous avez besoin des principes même si vous ne pouvez financer tout l'appareil. Au minimum, donnez aux administrateurs des comptes séparés pour l'administration et l'usage quotidien, n'ouvrez jamais de session sur des postes ordinaires avec un compte d'Admin du domaine, activez une authentification multifacteur forte sur les comptes privilégiés et gardez l'appartenance privilégiée permanente au strict minimum. Ces quelques disciplines livrent l'essentiel de la valeur protectrice du modèle en niveaux et exigent du processus plutôt que des outils coûteux. Vous pourrez adopter des postes de travail à accès privilégié et l'accès juste-à-temps à mesure que vous grandissez.

Conclusion

Le modèle en niveaux d'Active Directory et la conception de l'accès privilégié existent pour répondre à une question : quand un attaquant compromet inévitablement une machine, cela lui ouvre-t-il un chemin vers les clés du royaume ? Un parc à confiance plate répond oui ; un parc bien découpé répond non. Classez vos actifs, séparez les identifiants par niveau, administrez depuis des postes propres et durcis, remplacez le privilège permanent par l'accès juste-à-temps, et instrumentez tout pour qu'une violation de niveau devienne une alarme sonore plutôt qu'une escalade silencieuse. Le travail est autant discipline que technologie, mais il fait la différence entre un seul portable compromis et une entreprise compromise.