T0, T1 et T2 : Sécuriser les poste admin sans multiplier les PC

Réputé pour sa logique incontestable, sa simplicité redoutable et son implémentation implacable, le modèle de tiering des comptes à privilèges est aujourd'hui un standard de fait pour toute organisation qui administre un système d'information Active Directory (AD, pour les intimes). Le tiering c’est un peu la mise en application d’une expression bien connue de nos grands-parents : chacun chez soi et les vaches seront bien gardées.  

Un compte T0 compromis ne doit jamais pouvoir être atteint depuis un poste T2. Et comme dans la sécurité informatique le cloisonnement physique règne en maître depuis des décennies, du tiering a découlé le concept de Privileged Access Workstation (PAW). L’idée est simple : un poste dédié, isolé, par niveau de privilège.

Le fonctionnement technique du tiering (GPO, unités d'organisation, séparation des comptes) est déjà largement documenté par des ressources spécialisées sur Active Directory. Ce qui l'est moins, c'est ce qui se passe quand cette règle est appliquée dans un parc IT, avec un budget réel et une équipe bien humaine. Dans la vraie vie, quoi.  

C’est à cette friction opérationnelle que nous nous intéresserons dans cet article.  Un p’tit biscuit et c’est parti !  

Le défi oublié du tiering

Le tiering classe les actifs et les comptes selon leur niveau de sensibilité, et interdit qu'un compte d'un niveau donné s'authentifie sur un actif d'un niveau inférieur en confiance.  

‍

‍

Le PAW en est le prolongement au niveau du poste de travail. Autrement dit, un poste garde en mémoire des identifiants et des traces de session. Ce poste doit lui-même appartenir à un seul tier pour ne pas devenir le maillon faible qui permet de remonter d'un niveau à l'autre. Sur le papier, la règle tient en une phrase. Sur le terrain, elle devient un casse-tête logistique.

Le PAW par tier : une règle difficile à implémenter

Chez Dodulard, poids lourd de la charcuterie, un administrateur intervient quotidiennement sur des contrôleurs de domaine, des serveurs applicatifs et le support utilisateur. Trois tiers donc de trois postes entre lesquels il doit jongler toute la journée. Une situation aussi inconfortable pour lui comme pour le DSI qui applique cette règle à toute l’équipe. Et puisqu’ils sont huit, il faut compter pas moins de vingt-quatre postes à acheter, configurer, patcher et remplacer. Au-delà du poids sur le budget IT, c’est aussi une charge importante en termes de maintenance. De quoi ravir le CFO et le RSSI, vous imaginez bien.  

C’est comme si, pour cloisonner ses différents services, une entreprise faisait construire des bâtiments différents, chacun avec ses propres accès. Peu d’organisations font ça. Il est plus pratique d’attribuer un étage à chaque service et sécuriser l'accès aux étages d'un même bâtiment, avec des badges différents et des portes qui ne s'ouvrent pas aux mauvais niveaux. Le PAW, tel qu'il est généralement mis en œuvre, revient à construire un bâtiment par service.

La règle de sécurité est juste ; l'implémentation qu'on lui donne par défaut ne l'est pas forcément.  

Le coût d’un poste dédié par niveau de privilège

La règle a beau être juste sur le papier, deux limites apparaissent une fois qu'elle est mise en œuvre : son coût, et le fait qu'elle repose sur une classification qui ne bouge plus une fois fixée.  

Le coût ne se limite pas au prix d'achat du matériel. Chaque poste supplémentaire répète à l'identique, tier après tier, la même charge : licence de système d'exploitation, agent de sécurité endpoint, place dans le cycle de patch management, station d'accueil, espace de rangement sécurisé, et une entrée de plus dans les procédures d'arrivée et de départ.

Le support technique subit la même multiplication : un ticket de panne ou une mise à jour de firmware deviennent des opérations à répéter sur deux ou trois machines pour la même personne. Sur un parc de quelques dizaines d'administrateurs, cette charge de gestion pèse souvent plus lourd, dans la durée, que l'achat initial du matériel ; un facteur que beaucoup de RSSI découvrent seulement au moment de budgéter le projet, une fois le tiering validé sur le papier.

Le tiering face à l’évolution du risque

Le tiering attribue un niveau de risque à un instant donné : T2 pour un poste utilisateur, T1 pour un serveur, par exemple. Or le risque réel, lui, évolue en permanence. Le poste développeur illustre parfaitement cette limite. Généralement classé T2, il héberge pourtant souvent des jetons d'accès cloud, des secrets, des clés d'API ou encore des accès aux pipelines CI/CD. La compromission de ces actifs peut avoir des conséquences comparables à celles d'un poste T0 ou T1, malgré une classification T2.  

L'arrivée des agents IA dans les environnements de développement accentue encore ce décalage. Ces outils ne se limitent plus à suggérer du code : ils lisent des fichiers, exécutent des commandes et interagissent avec des API en héritant des privilèges de la session du développeur. Dès lors, un même tier peut masquer des niveaux d'exposition radicalement différents selon les données, les identités et les outils réellement présents sur le poste.

La séparation logique du matérielle : la fin du dilemme ?

Longtemps, la virtualisation a été associée aux hyperviseurs de type 2 (VMWare, Citrix, etc.). Aujourd’hui, l’hyperviseur de type 1 suscite un regain d’intérêt.  

S’exécutant directement sur le matériel, sans dépendre d’un OS intermédiaire, il permet de faire fonctionner plusieurs environnements, en parallèle sur un seul poste physique. Chaque environnement est isolé des autres au niveau du matériel plutôt que d'être empilés les uns au-dessus des autres. C’est ce qu’a mis en œuvre la filiale d’un grand groupe de construction. Leur équipe de développeurs s’était vu attribuer des postes Windows avec des droits administrateurs pour simplifier leur travail. 

Cette situation entrait en conflit avec la politique de sécurité du Groupe et augmentait considérablement les risques.  

L’attribution de postes multi-environnements, alignés avec les exigences de l’ANSSI, a permis à chaque développeur de faire coexister deux environnements distincts, parfaitement sécurisés, sur un seul PC : un environnement Group Master et un environnement Linux dédié aux développeurs.

Le même principe, appliqué au poste administrateur évoqué plus haut, assure le cloisonnement entre T0, T1 et T2 sur un seul PC. Pour reprendre l'analogie de l'immeuble : au lieu de construire un bâtiment par service, on sécurise les étages d'un même bâtiment, avec des accès qui ne communiquent pas entre eux.  

À préciser : cette approche isole et sépare des environnements sur un même poste. Elle ne fait pas office de supervision centralisée des usages ou des événements de sécurité entre ces environnements. Cette fonction reste celle des outils de détection et de journalisation déjà en place dans l'organisation.

Qu'est-ce que ça change, concrètement, pour un administrateur système ?

Pour un administrateur, le poste multi-environnements permet de conserve un seul poste physique et bascule vers l'environnement correspondant au tier sur lequel il doit intervenir. Chaque environnement dispose de ses propres identifiants, ressources et politiques de sécurité, sans partage avec les autres. Cette approche peut constituer une réponse rationnelle aux exigences de NIS2 ou SecNumCloud, sans multiplier les PC.  

Sur le plan opérationnel, le service IT ne gère plus qu’un seul PAW par utilisateur :  un seul numéro de série, un seul firmware, un seul cycle de renouvellement, tout en maintenant autant d'environnements isolés que le tiering l'exige. Il devient ainsi possible de maintenir autant d'environnements isolés que le tiering l'exige, tout en conservant une gestion matérielle proportionnelle au nombre d'utilisateurs plutôt qu'au nombre de tiers couverts.

Si la séparation logique ne remplace pas les bonnes pratiques de tiering, elle résout la contrainte matérielle. La séparation des unités d'organisation, les GPO, les comptes dédiés par tier ou encore les solutions de gestion des accès à privilèges (PAM) restent indispensables. La séparation logique intervient simplement à un autre niveau : celui du poste physique sur lequel ces droits s'exercent. Les deux approches sont complémentaires ; aucune ne se substitue à l'autre.

Conclusion

La question posée par le tiering n'a jamais vraiment été de savoir si le modèle est pertinent. Spoiler alert : elle l'est. Elle a plutôt été de savoir où se loge son coût réel, une fois sorti du schéma théorique : dans le nombre de postes à gérer, ou dans le temps passé à bien définir ce que chaque environnement doit isoler. Dans la plupart des déploiements actuels, ce coût est reporté sur le matériel. Pourtant, cette approche n'est pas une exigence du modèle de tiering lui-même. C’est seulement une conséquence de la façon dont on a choisi de l'appliquer.  

Chez Kerys Software, nous sommes convaincus que la réponse passe par une approche différente du poste de travail : disposer, sur un même équipement, de plusieurs environnements totalement cloisonnés dédiés à des usages distincts. Nous aidons les organisations à conserver les bénéfices du tiering tout en réduisant significativement sa complexité opérationnelle et matérielle. Pas envie de multiplier les PC ? Contactez-nous.