Ces dernières années, de grands projets de sécurisation de l’Active Directory (AD) ont vu le jour dans les organisations. Ceux-ci ont notamment été lancés pour palier la menace de sa compromission massive dans l’optique de déployer un rançongiciel, dont malheureusement l’actualité fournit de trop nombreux exemples. La mesure phare de cette sécurisation de l’AD est la mise en place du tiering (modèle en tiers), modèle de sécurité en strates préconisé par Microsoft et l’ANSSI, afin d’éviter la compromission des comptes à hauts privilèges de l’AD. Ce genre de projets se confrontent souvent avec un projet probablement encore en cours ou récemment terminé dans l’organisation : le projet lié au PAM. La plupart des organisations se lançant dans ce vaste chantier ont déjà mis en place des mesures de protection autour de ces comptes, qui n’avaient pas pris en compte la vision en trois tiers qu’amène le modèle. PAM, pour Privileged Access Management, et son implémentation, principalement existante au travers de bastions, n’est souvent pas parfaitement aligné avec les préceptes du tiering. En effet, le projet PAM a probablement structuré son approche autour des sensibilités métier ou des périmètres de responsabilités pour l’exploitation, là où le modèle en tiers propose plutôt une approche par types de composants. Alors essayons d’y voir plus clair…

 

Rappels sur le tiering

 

Le tiering est un modèle de sécurité applicable à l’Active Directory. L’idée principale est de séparer les comptes à privilèges dans différentes couches (les tiers) et périmètres fonctionnels, afin de restreindre leur utilisation possible dans leur tier d’origine uniquement, de sorte que si un tier est compromis, cela n’entraine pas la compromission des autres tiers. Cela permet par exemple de contenir une attaque par rançongiciel dans le tier d’origine de l’attaque uniquement, ou bien de se prémunir du scénario classique vu et revu de découverte et rejeu d’un identifiant administrateur de domaine sur un poste de travail. Typiquement le modèle se décompose comme il suit :

 

• Le tier 0 est le plus critique. Il est constitué de l’AD lui-même, donc les contrôleurs de domaine qui le portent, ainsi que des composants qui interagissent directement avec lui, où qui peuvent le compromettre par rebond. Ceux-ci sont typiquement les ADLDS, ADCS, PKI, mais aussi les composants IT nécessaires à son fonctionnement : hyperviseurs, SCCM, SCOM, sauvegarde, et postes d’administration dédiés (PAW, pour Privileged Access Workstation). Les comptes d’administration de ces composants sont ceux à plus hauts privilèges, car il s’agit forcément des comptes administrateurs de domaine (les comptes ayant des droits sur tout le parc Windows de l’organisation), mais aussi des comptes des autres composants pouvant s’attribuer indirectement les droits administrateurs de domaine, vu leur interaction avec les contrôleurs de domaines.
• Le tier 1 se compose classiquement des applications de l’entreprise et des serveurs qui les hébergent. Les comptes à privilèges sont donc ceux des administrateurs fonctionnels des applications ainsi que ceux des administrateurs techniques des serveurs.
• Le tier 2, pour finir, regroupe tout ce qui gravite autour de l’environnement utilisateur. En plus des comptes et postes bureautique, on peut y trouver les imprimantes, la téléphonie, ainsi que tous les comptes des différents niveaux de support utilisateur.

 

Pour rendre l’étanchéité possible entre les tiers, et donc limiter le périmètre de compromission, des « deny logon GPOs » (plus simple à mettre en place) ou des Authentication Policy Silos (plus sécurisées) sont mis en place, pour interdire à un compte d’un tier supérieur de se connecter à un composant appartenant à un tier inférieur. Aussi, un autre objectif du projet de mise en œuvre du tiering, pouvant avoir un impact sur le PAM, est de restreindre le nombre d’administrateurs du tier 0 au minimum, toujours dans l’optique de réduire la surface d’attaque et l’étendue d’une potentielle compromission. Une fois ce nouveau concept établi, examinons l’existant.

 

Bastion ? Vous avez dit bastion ?

 

Le bastion de sécurité est un outil très répandu dans les organisations pour implémenter le PAM. Le principe est d’héberger les comptes à privilèges dans des coffres sécurisés, et d’imposer les connexions des administrateurs (avec un compte sans privilège) vers une machine de rebond centrale, qui jouera ces comptes à privilèges pour l’administrateur, sans révéler son mot de passe. Autre avantage du bastion pour les organisations : la facilité de mise en place de l’authentification multi-facteurs, l’enregistrement et la traçabilité des actions d’administration, la gestion automatisée de la rotation de mot de passe, etc.

Jusqu’ici, rien d’incompatible avec le modèle en tiers. Et pourtant des adhérences existent. La structure de comptes à privilèges qui a été créée dans le bastion (par périmètre et/ou par équipe fonctionnelle et/ou type de composants, etc.), l’a été sans prendre en compte le concept amené par le projet de sécurisation AD : la notion de tiers.

Afin d’identifier les potentiels impacts, plaçons-nous dans l’optique du tiering et posons les questions simplement par rapport au bastion.

 

Comment adapter le bastion au modèle en tiers ?

 

Si l’on synthétise le problème à résoudre, cela donnerait le schéma ci-dessus qui est une pure vue de l’esprit. Pour réussir à l’adapter, il faut faire des choix.

 

Faut-il mettre le bastion dans un tier spécifique ? Faut-il le dupliquer dans chaque tier ?

Comme décrit dans le schéma d’un point de vue purement théorique du tiering, il faudrait une instance de bastion dans chaque tier, et même d’éditeurs différents afin de se prémunir d’une faille 0-day sur la technologie utilisée. Mais la mesure se heurte à une réalité financière, la possession de plusieurs bastions ayant un certain coût, doublé d’une réalité opérationnelle supportant mal la multiplication d’outils pour un même besoin. Heureusement des adaptations sont possibles. Dans la réalité, aucune entreprise ne met de bastion sur le tier 2. Ce tier étant relativement homogène et monolithique en matière de responsabilité, on autorise de s’y connecter directement, avec un compte à privilège du tier 2 évidemment, ou avec le compte administrateur local (protégé par LAPS) qui a l’avantage d’être robuste à une compromission totale du tier 2 en cas de compromission d’un seul compte à privilège du tier 2.

Pour les tiers 0 et 1, leur sort est lié et dépend à la fois du contexte de l’organisation et de l’existant. Première option, comme mentionné, le plus simple mais le plus couteux, est de déployer un bastion dédié dans chaque tier. En étant un peu plus réaliste maintenant, si une seule instance de bastion est possible, alors celle-ci devrait nécessairement être positionnée dans le tier 1. La raison de ce choix est très simple : le bastion répond à un besoin fonctionnel d’administration, or le périmètre de machines et de comptes le plus important est au sein du tier 1, à l’inverse du tier 0 dont on souhaite restreindre l’exposition (i.e. le nombre d’administrateurs y ayant accès).

Le tier 0 lui peut être plus simplement géré par des PAW, postes d’administration dédiés et durcis dans le but spécifique d’accéder à des comptes et ressources privilégiées. L’accès à la zone réseau hébergeant le tier 0 est soumise à une connexion VPN, autorisée seulement à partir de ces PAW. Il existe des organisations ayant fait une combinaison des deux : bastion et PAW. Cette implémentation reste tout à fait valable d’un point de vue sécurité, mais sa faisabilité dépend de la capacité de l’entreprise à déployer des PAW pour l’ensemble de ses administrateurs du tier 1, ce qui représente une population cible et un coût nettement supérieur. Dernier point pour conclure ce sujet : l’utilisation de bastion et PAW ne sont pas incompatibles entre eux, bien au contraire, les bénéfices sécurité sont complémentaires pour la protection des comptes à privilèges.

 

Dans le cas d’un bastion unique, peut-on administrer les autres tiers via celui-ci ?

Cette hypothèse simplifierait les choses, mais malheureusement elle n’est pas souhaitable. Administrer le tier 0 depuis le tier 1 briserait toute la segmentation que l’on cherche à mettre en place, notamment parce que des comptes privilégiés du tier 0 seraient hébergés dans le tier 1 et accessibles par les administrateurs du tier 1 du bastion. Cela dit, une infime possibilité existe, mais elle est très techno-dépendante car peu de bastions offrent les fonctionnalités adéquates. Sur le principe en positionnant le bastion dans le tier 0, administré par le tier 0, il serait possible de créer des groupes de machines de rebond, ainsi que des coffres (logiques), actifs ou passifs, dédiés dans chaque tier. Néanmoins notons que les rares organisations ayant tenté l’expérience font aujourd’hui machine arrière, face aux problèmes de gestion technique des coffres et à la lourdeur administrative induite.

 

Faut-il revoir l’attribution et la répartition des comptes dans le bastion ?

Pas nécessairement, mais encore une fois, cela dépend du contexte et de l’existant. En premier lieu, les comptes issus de chaque tier doivent être hébergés dans des coffres différents, afin de respecter la segmentation et l’étanchéité de chaque tier. Rien n’empêche si nécessaire de fragmenter, au sein de chaque tier, les coffres en sous périmètres pour répondre à l’organisation technique ou fonctionnelle existante (e.g. équipes ayant la charge du MCO/MCS des composants hébergeant des bases de données sont différentes des celles ayant la charge du MCO/MCS d’applications métier). Enfin, il est recommandé d’utiliser au maximum des comptes nominatifs et non des comptes génériques ou partagés. Si en effet rien n’empêche de mettre en coffre un compte unique administrateur de tous les serveurs du tier 1 utilisé par tous les administrateurs du périmètre, et que cette façon d’opérer ne va pas non plus contre les principes du tiering, il est quand même préférable de pouvoir immédiatement identifier le propriétaire du compte qui a fait l’action, afin de mieux maitriser les accès et habilitations de chacun, même si le bastion permettrait quand même de retrouver l’identité de manière indirecte via un recoupement dans les logs.

 

Bien encadrer la mise en place du tiering

 

Le tiering est aujourd’hui le chantier qui réduit le plus les risques de compromission des comptes à hauts privilèges et de l’AD de manière générale. C’est cependant également un sujet complexe, qui a beaucoup d’impacts sur l’ensemble des infrastructures et qui nécessite un très grand nombre d’adaptations de l’existant, pour que sa mise en place soit considérée comme réussie. Le PAM étant une brique essentielle à la gestion de ces comptes et accès d’administration, il est nécessaire de s’assurer que son implémentation n’interfère pas avec les principes du tiering voire ne vienne pas rompre la segmentation et l’isolement en couches. S’il n’y avait qu’une chose à retenir pour bien réussir cette transformation, ce serait que la mise en place du tiering, contrairement à ce que l’on croit, est loin de n’être qu’un simple sujet AD, mais qu’il doit conduire à repenser toutes les pratiques d’administration dans leur globalité.