Dans un précédent article, je vous avais présenté une méthodologie en termes de sécurité qui doit vous permettre de limiter les accès admins au sein de votre infrastructure en tenant compte de paramètres tels que le niveau d’accès nécessaire et la durée de validité de cet accès : Just-in-Time & Just Needed Access.
Je vous propose d’aborder une autre méthodologie de sécurité que l’on appelle le Tiering Model. Cette méthodologie a pour but d’organiser l’ensemble de votre infrastructure informatique en différentes couches.
Modèle des couches
L’objectif étant de séparer les composants de votre infrastructure en fonction de leur niveau d’importance et de de rendre ces différentes couches hermétiques les unes des autres. De ce fait, si une couche venait à être compromise, on souhaite éviter qu’un attaquant potentiel puisse aller attaquer les autres couches de votre infrastructure.
Par défaut, on distingue 3 couches différentes qui sont organisées comme suit :
- Le niveau 0 ou Tier 0 regroupe l’ensemble des composants de votre infrastructure qui gèrent le contrôle des identités de l’entreprise. On y positionnera donc normalement les serveurs liés à l’Active Directory (contrôleurs de domaine) mais on y intégrera également d’autres composants tels votre PKI interne ou bien un AAD Connect si vous en avez un. C’est la couche la plus importante.
- Le niveau 1 concernera les serveurs et applications de l’entreprise. Il s’agira d’y regrouper toutes vos applications internes et les composants qui permettent la gestion de votre parc informatique (SCCM, WSUS, SCOM, etc.).
- Le niveau 2 regroupera l’ensemble des stations de travails (portables ou postes fixes) ainsi que tous les terminaux mobiles de vos utilisateurs. C’est la couche qui est évidemment la plus « à risque » puisque c’est là que vous retrouvez vos utilisateurs (qui peuvent faire des erreurs : phishing, exécuter un ransomware, etc.) avec tous leurs périphériques mobiles (smartphone, tablette, …).
Cela peut paraître simple en apparence mais pour arriver à une telle organisation pour votre infrastructure, il faut en général du temps, des ressources mais aussi de la formation pour vos administrateurs… car vous allez voir que vos administrateurs seront impactés par la mise en place de cette approche dans leur façon de travailler.
Administration des couches
Pour assurer la séparation entre ces différentes couches il convient de ne pas utiliser les mêmes comptes d’administration pour chacune d’elle. Cela signifie qu’un ingénieur de production ou un administrateur d’entreprise est susceptible d’avoir (au moins) 3 comptes admin différents en fonction des actions qu’il souhaite réaliser (en plus de son compte personnel sans privilège bien entendu). 🙂
Evidemment, la séparation et l’utilisation de ces comptes ne repose pas sur la confiance de vos ingénieurs. Il faudra en effet mettre en place les GPO et la configuration qui permettra de restreindre l’accès à des couches inférieures ou supérieures en fonction du type de compte Administrateur utilisé.
Ainsi :
- Un administrateur T0 peut gérer uniquement des composants de la couche T0. Il ne peut RDP que sur des serveurs intégrés à ce niveau (domain controller, PKI, ADFS, etc.). L’accès ne doit PAS être utilisé pour se connecter à des serveurs d’une couche inférieure.
- Un administrateur T1 opère les serveurs applicatifs de l’entreprise et tous les autres middlewares que vous pourriez avoir au sein de votre infrastructure. Il ne doit pas être utilisé pour se connecter à une couche supérieure ou inférieure.
- Enfin, un administrateur T2 gère les postes de travail des utilisateurs et autres périphériques. Ce compte ne doit pas être utilisé pour accéder aux autres couches supérieures.
Utiliser cette distinction de comptes dans les différentes couches de votre infrastructure permet de mieux sécuriser l’ensemble en empêchant les déplacements latéraux (lateral movements) d’un attaquant potentiel qui remonterait d’une couche inférieure.
Encore une fois, on ne parle pas de recommandations qui peuvent être suivies ou ignorées par vos admins mais de restrictions qui doivent être configurées via GPO.
Utilisation de PAW ou SAW
Vous l’aviez peut-être remarqué dans le précédent schéma mais il est également question de « Jump Server » (voir ci-dessous à gauche).
Eh bien oui, si tous les postes de travail sont du T2, alors nous ne pouvons pas utiliser un accès admin d’une couche particulière directement depuis notre poste de travail !
Il est alors nécessaire de déployer ce que l’on appelle de PAW – Privileged Access Workstation (ou SAW – Service Access Workstation selon les éditeurs). Ces machines correspondent à des postes de travail spécifiques et sécurisés (hardening) qui sont utilisés pour accéder aux serveurs d’une couche en particulière avec un compte de Tier particulier.
Une machine PAW de T0 et un compte Admin de T0 permettra donc d’administrer la PKI, AD, ADFS, etc. Et une machine PAW de niveau T1 permettra d’accéder aux serveurs de la couche T1 – associée à votre accès admin T1.
Si vous ne l’aviez pas encore compris… vous commencez à voir que ça peut devenir très compliqué et surtout toute cette mise en place nécessite du temps et des ressources ! 😉
Maintenant que vous avez compris le principe, je vous invite à consulter les 2 liens suivants pour commencer votre configuration GPO – il s’agit de 2 liens officiels fournis par Microsoft (en anglais) :
- Protecting Domain Administrative Credentials
- Initially Isolate Tier 0 Assets with Group Policy to Start Administrative Tiering
Evidemment la configuration ne sera pas la même d’une infrastructure à l’autre. Par exemple, dans certains cas, les PAW sont déployées comme des serveurs RDS ou Citrix plutôt que d’être simplement un Laptop ou Desktop… 🙂
Pour aller plus loin
Plus d’informations sur le site de Microsoft :
Bonjour, n’y a t-il pas une faute dans la phrase » Et une machine PAW de niveau T1 permettra d’accéder aux serveurs de la couche T2″ on parle ici des serveurs de la couche t2 non ?
Bonjour, en effet. Je viens de corriger et je vous remercie d’avoir pris le temps de me remonter cette coquille. 😮
Bonjour,
Il y a une chose que je ne comprends pas : Comment utiliser les machines de rebond de manière sûre ?
Je pense installer des machines de rebond virtuelles communes à l’équipe d’admin.
Si j’installe une machine de rebond pour administrer le T0, je me connecte dessus en RDP depuis mon PC en T2, puis soit j’utilise les outils d’administration AD installés sur la machine de rebond, soit je refais un RDP depuis la machine de rebond vers un DC.
Lorsque je me connecte à la machine de rebond T0 depuis mon PC en T2, j’utilise quel compte pour m’authentifier ? Je vois 2 possibilités :
– Je me connecte avec mon compte utilisateur T2 en RDP sur la machine de rebond puis je lance les apps de gestion ou le RDP vers les DC avec le compte admin T0
– Je me connecte directement en RDP sur la machine de rebond avec mon compte admin T0 puis je lance les apps de gestion ou le RDP vers les DC avec même compte T0.
Merci d’avance pour votre réponse !
Bonjour,
Votre question concerne une pratique importante en matière de sécurité informatique, surtout dans les environnements utilisant Active Directory : l’usage de machines de rebond pour administrer les différents niveaux de votre infrastructure, notamment le Tier 0 (T0), qui est le plus critique.
En résumé, pour une utilisation sûre, il est conseillé de se connecter à la machine de rebond avec un compte de bas niveau (T2) et d’effectuer une élévation de privilèges pour les tâches d’administration. Cette méthode limite l’exposition des comptes à privilèges élevés et renforce la sécurité globale.
Merci Zak pour votre réponse très pertinente.
Bonjour Chris et merci pour votre question. La démarche derrière la machine d’administration (comme le modèle en tiers) est un bonne pratique qu’il convient d’adapter à chaque entreprise en fonction de ces cas d’usages et de ses façons de travailler. Par exemple, selon la taille de l’entreprise la ou les machines d’administration du T0 ou T1 peuvent être carrément tout une infra Citrix ou RDS (car de nombreux Admins) et pour des entreprises de plus petite taille il peut s’agir de mettre simplement 1 ou 2 serveurs de rebonds. L’idée derrière cette machine de rebond c’est de procéder à la sécurisation des machines de manière plus forte qu’une workstation classique : impossibilité de surfer sur Internet pour le poste d’admin T0, déploiement d’une authentification par smartcard, déploiement des GPO de hardening du SCT (Microsoft Security Compliance Toolkit), renforcement avec les méthodologies de restricted admin ou encore credential guard.
Enfin, dans le scénario que vous décrivez vous devez utiliser votre compte de T0 pour vous connecter à une machine d’administration (PAW) de T0 pour ensuite avoir accès à vos outils de gestion AD/ADCS/PKI (tout ce qui est T0) ou bien rebondir encore sur votre DC avec votre compte de T0 – donc c’est plutôt le point numéro 2 dans votre liste à puce. Le plus important derrière ça étant d’avoir recours aux outils dont je vous ai parlé : restricted admin ou credential guard, déploiement de SCT, etc.
Merci beaucoup pour votre réponse,
Que pensez vous d’un serveur de rebond de type Linux/Guacamole avec SSO gmail (compte gmail pro authentifié par mot de passe + MFA) pour prendre la main ensuite en RDP sur les Machines de T0 / T1 ?
L’accès passerait par le serveur Guacamole mais tout se ferait dans l’interface Web d’un poste utilisateur T2 des admins. A mon sens c’est semblable à l’utilisation d’un serveur de rebond Citrix en HTML5 depuis le poste utilisateur.
Dans le cas de Guacamole, faut il 1 serveur guacamole pour le T0 et 1 serveur pour le T1 ou on peut tout grouper sur le même ? Les identifiants d’accès gmail seraient de toutes façons les mêmes sur les 2 Serveurs Guacamole…
Merci d’avance,
Je ne connais pas spécifiquement Guacamole mais de ce que je comprends c’est comme Azure Bastion (il ne faut pas m’en vouloir je connais plus les produits Microsoft). De mon point de vue, cela me semble plutôt une bonne approche car du coup vous rebondissez directement sur les serveurs à administrer via une interface web sans avoir besoin de RDP depuis votre poste avec le client RDP classique de Windows. Ce qui est intéressant dans cette approche c’est que vous ne laisserez pas de traces sur le système en rebondissant de cette façon.
Bonjour, tu aurais les paramètres à positionner en termes de GPO pour faire le segmentation ?
Merci par avance.
Bonjour Jean-François, tu ne trouveras pas de « script prêt à l’emploi » qui précise les GPO à mettre en place. Tu peux commencer par le chargement des GPO qui sont disponibles dans le Microsoft SCT (Security Compliance Toolkit) qui sont la base du Tiering. Même chose, en ce qui concerne la ségrégation du réseau ou des groupes / comptes admins, ce sont des choses qui doivent être analysées au moment du design puis déployés en fonction de l’infrastructure cible. Même sur les docs MS du Technet, vous trouverez des explications qui disent ce qu’il faut faire mais il faudra l’adapter à votre infrastructure. Aucun script tout fait. La raison est simple MS et les ESN de sécurité vendent du service sur ce type de déploiement et c’est pourquoi vous ne trouverez rien de tout fait. La logique c’est de comprendre la méthodologie pour la traduire et l’appliquer à la configuration de notre prod.
Bonjour, dans le modèle de tiering, pour moi il manque la couche des personnes qui « gèrent les utilisateurs standard » càd les personnes qui vont créer les comptes AD, mettre ces comptes dans des groupes pour leur donner accès à des ressources (applications, partages réseau,…). Selon moi cette couche n’a aucun accès aux resources T0, T1, T2 mais peuvent juste faire certaines manipulations dans certaines OU au niveau de l’AD.
Autre point : est-ce que quelqu’un d’une couche peut créer un compte et donner des droits pour une nouvelle personne dans cette même couche ? Pour moi ca doit forcément être créé par quelqu’un d’une couche supérieure (sauf le T0 bien entendu).
Bonjour David, merci pour votre commentaire. Dans cet article, mon but était de reprendre et d’expliquer la méthodologie qui est mise en avance par Microsoft en tant que Tiering Model ou le « modèle en couche » si l’on se réfère aux documents de l’ANSSII. Il ne s’agit pas d’une méthodologie ou norme que l’on peut « copier » sur tous les environnements de production du monde mais plutôt de recommandations et de lignes directrices vers lesquelles il faut tendre. De toutes les entreprises que j’ai pu voir : aucune ne dispose du même déploiement en matière de sécurité. Et je pense que justement c’est très important de ne pas se laisser avoir par un discours avant-vente mais d’adapter cette démarche à chaque prod en fonction de ses spécificités. Pour votre seconde question, de mon point de vue tout ce qui est créations de comptes devrait être géré dans la partie T0.
Super article !
Concernant le déploiement de machines de rebond RDS, et plus précisément le serveur de licence RDS. Je déploie :
La connexion ne fonctionne pas à cause des restrictions T0 et T1 par GPO, le RDS T1 n’arrive pas à récupérer les licences sur RDS T0, est ce qu’il y a une solution à part faire un autre serveur T1 RDS pour les licences ?
Merci !
Hello Mike, la connexion RDP est limitée à 2 sessions concurrentes sur une machine de rebond. Si vous prévoyez d’avoir davantage d’admins connectés de manière consécutive alors vous allez devoir avoir des licences RDS. L’approche d’un point de vue « bonne pratique » Microsoft serez de mettre en place 2 serveurs de licences différents afin d’assurer l’isolation entre chaque couche. Mais dans cette approche on ne tient pas compte des coûts éventuels de licences car on recommandera le « mieux » en termes de sécurité sans tenir compte de l’aspect financier. Si on souhaite un scénario « entre 2 » alors on peut envisager de créer un serveur de licences qui soit mutualisé entre les 2 couches. Dans ce cas, vous devrez en effet adapter les flux et permettre aux serveurs de rebonds de contacter le serveur de licences RDS. Dans cette approche, vous économiserez potentiellement 1 VM et 1 licence Windows Server mais d’un point vue « respect du Tiering » c’est n’est pas tout à fait conforme. Comme je l’ai déjà dit dans les autres commentaires : Le Tiering Model tel qu’il est proposé par Microsoft ne tient pas compte de contraintes financières / budgétaire mais s’intéresse uniquement à la sécurité. Il appartient à chaque entreprise d’adapter cette approche de sécurité en fonction de son budget et des éventuelles optimisations financières qu’elle souhaite faire.
Bonjour Thibault,
Excellent article. Quelques petites questions sur ce modèle…
Dans le cas ou un admin doit installer, sur un poste utilisateur, un soft qui nécessite une élévation de privilèges. Faut il utiliser un compte T2 ou utiliser l’admin local avec du LAPS en lieu et place. Ca limiterait la creation à deux niveaux et sécuriserait mieux les risques sur le T2.
Je sais que c’est qu’une histoire de convention mais si mon compte standard est CONTOSO\a.amalice, quel pourrait être votre recommandation pour nommer les comptes T0 à T2 ?
Dans mon cas, j’ai une forêt avec 6 domaines. Cela implique donc de créer 7 x 3 comptes… pas de solution plus simple ?
Merci pour votre retour… Aliza
Bonjour Aliza,
Pour déployer un outil sur un poste utilisateur – connecté à Internet et donc dans le T2, l’idée c’est d’utiliser le compte Admin qui est géré par LAPS. Le temps que vous fassiez vos actions et pour la prochaine intervention sur ce poste, le mot de passe aura changé. Honnêtement, pour le nom c’est vraiment comme ça vous arrange, je connais certaines entreprises qui d’un côté mettent simplement t0-identifiant ou t1-identifiant – tandis que d’autres ne souhaitent pas que l’on reconnaisse facilement les comptes à privilèges dans l’AD et donc ne les identifient pas particulièrement avec un préfixe (approche qui peut se défendre lorsque l’on y pense). J’entends bien que vous disposez d’une forêt de 6 domaines. Comme je l’ai déjà partagé dans les autres commentaires, il est important de comprendre que le Tiering Model est une base en termes de recos et de bonnes pratiques. Chaque entreprise peut tordre le modèle pour l’adapter à son périmètre. En ce qui me concerne, j’aurais tendance à ne pas non plus trop complexifier à outrance et donc faire 1 compte / domaine pour les admins avec un suffixe pour identifier le domaine par exemple afin de ne pas confondre les comptes (mais c’est très subjectif).
Merci Thibault pour la réponse. Donc quel est l’intérêt du compte T2 si le compte admin LAPS suffit ?
Quand vous indiquez 1 compte / domaine pour les admin, c’est sous entendu que c’est un compte « générique » admin ou un compte par administrateur (qui est mieux pour la traçabilité tout de même), j’ai du mal à comprendre votre dernière explication.
Pour la masterisation, la gestion des applis métiers des utilisateurs, et tout ce qui concerne l’environnement d’un utilisateur « classique » (comprendre pas admin).
Non je parlais d’un compte administrateur en effet afin de garantir la traçabilité des actions des admins bien entendu.