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).
Et 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 :
- Mise en place d’accès privilégié (Just-In-Time & Just Needed)
- Mise en place de machine PAW
- Tiering Model
N’hésitez pas à utiliser la zone commentaires pour toute question ! 🙂
