Tier Model sans PAW : comment construire des chemins d’administration adaptés au risque ?

La question revient régulièrement dans les programmes PAM et dans les réflexions autour des systèmes d’information d’administration : faut-il réellement équiper tous les administrateurs d’un poste de travail d’administration dédié ?

Le coût matériel est la partie visible du problème. Une PAW, Privileged Access Workstation dans la terminologie Microsoft, implique aussi un deuxième environnement à maintenir, sécuriser, mettre à jour et supporter. Côté administrateur, elle ajoute un chemin supplémentaire entre le besoin métier et l’action technique.

Ce dernier point est essentiel. Un système d’information d’administration n’est pas uniquement conçu pour être sûr : il doit permettre aux administrateurs de comprendre facilement par où passer, avec quelle identité, depuis quel environnement et pour atteindre quelles ressources.

C’est une déclinaison très concrète de notre principe Security meets Business. Une sécurité tellement complexe qu’elle pousse les équipes à chercher des chemins parallèles finit par travailler contre elle-même.

La réponse en une phrase
Il n’existe pas de Tier Model strict offrant exactement le niveau d’assurance d’une PAW sans les contraintes d’une PAW. Il est en revanche possible de concevoir plusieurs chemins d’administration, chacun associé à un niveau de risque, de confiance du terminal et de contrôle adapté.

Sommaire

1. Commencer par les risques, pas par les PAW
2. Ce que le Tier Model cherche réellement à préserver
3. Pourquoi Zero Trust ne supprime pas la segmentation réseau
4. Construire la confiance dans le terminal : le cas Ariovis
5. Pourquoi un bastion ne suffit pas
6. Dessiner des chemins d’administration réellement utilisables
7. Conclusion : quand faut-il conserver une PAW ?

Posons immédiatement la limite du raisonnement

Si votre objectif est d’appliquer strictement le Tier Model Microsoft et d’obtenir le niveau de garantie qu’il associe aux PAW, il n’existe pas de raccourci magique permettant d’obtenir exactement la même propriété de sécurité sans accepter les contraintes correspondantes.

Microsoft est aujourd’hui extrêmement explicite : le Tier Model AD DS fonctionne lorsque l’administration démarre depuis une station administrative approuvée correspondant au niveau administré. Pour Microsoft, la confiance commence dès le poste physique depuis lequel sont saisies les informations d’identification privilégiées.

Source : Microsoft — Tier Model for Active Directory Domain Services

L’ANSSI considère elle aussi que le poste physiquement dédié offre la meilleure garantie de sécurité. Mais lire uniquement cette recommandation ferait perdre une partie importante de son guide.

L’Agence précise que ses recommandations doivent être adaptées au contexte, que leur application linéaire n’est pas adaptée à tous les SI et invite explicitement à conserver « un esprit critique vis-à-vis du contexte d’application ». Le guide propose d’ailleurs plusieurs recommandations alternatives présentant différents niveaux de sécurité lorsque plusieurs architectures sont envisageables.

Source : ANSSI — Recommandations relatives à l’administration sécurisée des SI

Le propos de cet article n’est donc pas : « comment éviter les PAW ? »

Il est plutôt : comment construire un SI d’administration dans lequel le niveau de protection est cohérent avec le risque, où les contrôles se complètent, et dans lequel les administrateurs savent simplement comment travailler ?

1. Commencer par les risques, pas par les PAW

Une organisation ne souffre pas du risque « absence de PAW ».

Elle peut en revanche souffrir :

• qu’un malware présent sur un poste bureautique capture une identité d’administration ;
• qu’un administrateur dispose en permanence de privilèges dont il n’a besoin qu’occasionnellement ;
• qu’un prestataire puisse joindre directement un système sensible depuis un équipement non maîtrisé ;
• qu’un compte permettant d’administrer vingt serveurs puisse en réalité atteindre deux cents machines ;
• qu’une compromission initialement limitée devienne un mouvement latéral jusqu’au plan de contrôle.

C’est précisément pour cette raison que le guide ANSSI commence son architecture du SI d’administration par l’analyse de risques et la définition de zones de confiance, avant de descendre dans les composants techniques. L’Agence demande ensuite que ces zones soient matérialisées par les mécanismes appropriés : filtrage, authentification, chiffrement, cloisonnement, etc.

Ce que nous observons dans les programmes PAM

Notre retour d’expérience sur les programmes PAM conduit au même constat.

Nous avons audité ou fait évoluer des dispositifs dans lesquels une plateforme PAM existait déjà alors que subsistaient encore des privilèges permanents trop larges, des délégations incohérentes, des comptes historiques, des postes insuffisamment protégés ou des chemins d’administration mal maîtrisés. Un outil PAM peut sécuriser une partie du parcours sans corriger à lui seul le système de délégation, les flux réseau ou l’environnement depuis lequel le privilège est exercé.

Dans d’autres projets, le problème principal n’était même plus technique : il fallait clarifier ce qui était réellement privilégié, trouver les propriétaires, traiter les exceptions, modifier les habitudes d’exploitation et construire un modèle que les administrateurs utiliseraient effectivement.

C’est à cet endroit que la question économique devient saine. On ne cherche pas d’abord le contrôle le moins cher. On cherche à comprendre quel risque doit être réduit et quel niveau d’assurance est réellement nécessaire, sans imposer partout le parcours le plus lourd lorsque ce niveau n’est pas justifié.

C’est aussi l’approche que nous utilisons pour construire les trajectoires Zero Trust : partir des identités, des ressources, des processus, des risques et des contraintes d’exploitation avant de choisir les briques techniques.

En savoir plus : Construire une stratégie IAM & Zero Trust

Vous devez prioriser vos prochaines étapes ?

Obtenez gratuitement une première évaluation de votre maturité et une feuille de route IAM Zero Trust adaptée à votre contexte.
Générer ma feuille de route IAM Zero Trust

2. Ce que le Tier Model cherche réellement à préserver

Le Tier Model reste particulièrement utile parce qu’il introduit une idée très simple : toutes les ressources d’administration n’ont pas le même impact en cas de compromission.

Un contrôleur de domaine, une PKI, un système capable de déployer des agents sur les contrôleurs de domaine ou une infrastructure contrôlant les identités de l’entreprise ne sont pas au même niveau qu’une console permettant d’administrer une application métier isolée.

Microsoft définit aujourd’hui le Tier Model AD DS comme une hiérarchisation logique fondée sur les privilèges et capacités de contrôle, et non simplement sur la localisation physique dans le réseau. Microsoft précise immédiatement que la segmentation réseau reste complémentaire au modèle.

Cette notion de capacité de contrôle est fondamentale.

Un outil de sauvegarde capable de restaurer ou modifier les contrôleurs de domaine, un EDR disposant d’un contrôle système sur ceux-ci, un hyperviseur qui les héberge ou un service d’identité pouvant modifier les autorisations du domaine peuvent devenir des éléments équivalents au Tier 0, même s’ils ne s’appellent pas « Active Directory ».

C’est également la raison pour laquelle Microsoft a étendu le modèle historique avec son Enterprise Access Model : Control Plane, Management Plane et Data/Workload Plane. L’objectif reste d’empêcher qu’un plan inférieur puisse prendre le contrôle d’un plan supérieur, mais le raisonnement devient applicable aux environnements hybrides et cloud.

Source : Microsoft — Enterprise Access Model

Schéma 1 — Classer les ressources selon leur capacité de contrôle

Le principe à préserver n’est donc pas « trois réseaux, trois comptes, trois ordinateurs » comme une recette immuable.

C’est plutôt :

Une source présentant un niveau de confiance insuffisant ne doit pas devenir le moyen de compromettre une ressource présentant un niveau supérieur.

À partir de là, il devient possible de réfléchir à l’ensemble du chemin d’administration.

3. Pourquoi Zero Trust ne supprime pas la segmentation réseau

Un raccourci fréquent consiste à opposer le Tier Model, supposément fondé sur le réseau, à une architecture Zero Trust supposément fondée uniquement sur l’identité.

Nous refusons cette opposition.

L’ANSSI présente le Zero Trust comme une démarche reposant notamment sur une évaluation dynamique du sujet, du contexte d’accès, de l’état de sécurité du poste utilisé et de la criticité de la ressource. Elle cite également explicitement la micro-segmentation parmi les principes utilisés par le modèle.

Source : ANSSI — Les essentiels du Zero Trust

Le changement n’est donc pas :

réseau → identité

Il est :

réseau seul → décision construite à partir de plusieurs signaux

Nous continuons à vouloir empêcher un administrateur base de données d’atteindre une console d’administration Active Directory s’il n’a aucune raison de le faire. Nous continuons à vouloir filtrer les ports, les destinations et les flux possibles. Nous continuons à vouloir isoler les zones d’administration.

En revanche, appartenir physiquement ou logiquement au « réseau admin » ne devrait plus automatiquement signifier que tout le réseau d’administration devient accessible.

Le réseau peut désormais participer à l’application d’une décision plus fine.

Schéma 2 — Une décision d’accès construite à partir de plusieurs signaux

Dans le cours IAM et Zero Trust que nous dispensons chez Ariovis, nous modélisons justement le ZTNA comme un Policy Enforcement Point supplémentaire : il applique la décision sur l’accès réseau tandis que le PAM contrôle certains accès privilégiés, l’Access Management les parcours d’authentification et les autres PEP les contrôles dont ils sont responsables.

Et nous insistons aussi sur une limite : le ZTNA ne remplace ni l’architecture du poste ni l’ensemble des mécanismes de segmentation.

L’objectif est que l’administrateur dispose du bon chemin, pas de tous les chemins.

4. Construire la confiance dans le terminal : le cas Ariovis

C’est ici que notre propre architecture permet de sortir de la théorie.

Chez Ariovis, nous n’utilisons pas une PAW dédiée pour chacune de nos opérations administratives.

Mais nous n’avons absolument pas retenu comme conséquence que tous les terminaux pouvaient être considérés de la même manière.

Les accès directs à notre SI sont réalisés depuis des équipements Ariovis enrôlés et administrés. Nos postes sont durcis, leurs possibilités d’exécution sont fortement contraintes — notamment avec AppLocker — et ils font l’objet d’une supervision de sécurité.

Notre Trust Center rend d’ailleurs publique une partie de ces mesures : comptes nominatifs, accès sensibles protégés, FIDO2, bastion journalisé et supervision de sécurité 24/7 opérée avec Dhala Cyberdéfense.

En savoir plus : Trust Center et pratiques de sécurité Ariovis

Les alertes et incidents de sécurité entrent ainsi dans une chaîne de supervision opérée 24/7 par notre SOC externalisé. Ce point est important dans une logique Zero Trust : nous ne considérons pas le niveau de confiance d’un terminal comme un état acquis définitivement parce qu’il a été fourni par Ariovis. La capacité à détecter une modification de ce contexte fait partie de la protection.

Mais la maîtrise du poste n’est qu’une partie du mécanisme.

Nos administrateurs sont placés dans des groupes dédiés. Ces groupes déterminent notamment leur possibilité d’utiliser Microsoft Global Secure Access pour joindre les zones réseau d’administration correspondant à leurs fonctions.

Un PC Ariovis ne dispose donc pas automatiquement d’un accès à toutes les zones internes parce qu’il est « corporate ».

De même, être administrateur ne revient pas à se retrouver dans un grand VLAN d’administration donnant accès à tout.

Nous cherchons plutôt à obtenir quelque chose de ce type :

Schéma 3 — Le chemin d’administration Ariovis

Microsoft Entra Private Access permet précisément de construire ce type de modèle. Les ressources privées peuvent être regroupées dans des applications, affectées à des utilisateurs ou groupes et associées à leurs propres stratégies Conditional Access.

Source : Microsoft — Entra Private Access

Microsoft pousse d’ailleurs explicitement l’évolution depuis les modèles d’accès larges vers une segmentation par application, en observant quels utilisateurs et quels terminaux accèdent à quels FQDN, IP, ports et protocoles, puis en créant des règles plus précises.

Source : Microsoft — Per-app access segmentation

Cette architecture n’est pas une PAW.

Et nous ne prétendrions certainement pas qu’elle apporte automatiquement le même niveau d’assurance qu’une PAW dédiée utilisée pour administrer un Control Plane critique.

Elle illustre autre chose : la confiance dans un terminal peut être construite par niveaux et associée à des chemins différents selon le besoin.

Plusieurs niveaux de terminal, plusieurs niveaux d’assurance

Dans une autre entreprise, un premier niveau pourrait accepter certains usages depuis du BYOD après évaluation de quelques signaux de posture. Chez Ariovis, nous avions également étudié cette possibilité, notamment pour nos externes, mais nous l’avons rejetée au profit d’une expérience utilisateur plus simple et plus maîtrisée : un accès Guacamole, une authentification forte, puis une VM distante Ariovis déjà préparée avec tous les outils nécessaires. En pratique, l’utilisateur externe ouvre un navigateur web, s’authentifie une seule fois et accède immédiatement à son environnement de travail.

Nous basculons progressivement vers le passwordless. Même si le poste initial était compromis, il n’y aurait donc pas nécessairement de mot de passe réutilisable à voler. Nous envisageons même de cumuler un contrôle minimal du terminal entrant avec l’accès Guacamole : terminal suffisamment conforme + authentification forte + accès Guacamole = accès à l’environnement Ariovis.

Niveau	Environnement de départ possible	Exemple de contrôles	Usage envisageable
1	BYOD	Signaux de posture, authentification forte, rebond vers une VM maîtrisée	Accès encadré d’un externe
2	Poste corporate	Conformité, durcissement, supervision, groupes dédiés	Administration courante selon le risque
3	Poste spécialisé	Environnement fortement restreint, usages dédiés	Opérations sensibles
4	PAW séparée	Isolation physique ou logique stricte, chaîne de confiance dédiée	Administration du plan de contrôle critique

Ces niveaux ne sont pas équivalents. Le niveau retenu doit découler de l’analyse de risque et de la criticité de l’opération.

L’ANSSI demande d’ailleurs l’utilisation d’équipements durcis et maîtrisés pour les accès aux données critiques et souligne les limites des informations remontées par un équipement personnel.

Le rebond ne transforme pas magiquement un équipement personnel en équipement Ariovis de confiance : il réduit ce que cet équipement peut atteindre et déplace une partie des contrôles dans une zone que nous maîtrisons.

Et si demain notre analyse de risque concluait qu’une opération extrêmement sensible ne doit jamais être réalisée depuis le même poste que les usages bureautiques habituels, la réponse serait probablement… une PAW.

Le raisonnement par le risque fonctionne dans les deux sens.

5. Pourquoi un bastion ne suffit pas

La même prudence doit s’appliquer à la stratégie PAM.

En savoir plus : Sécuriser les accès à privilèges avec une approche pragmatique

Dans plusieurs projets sur lesquels nous avons travaillé, une solution PAM était déjà présente mais le dispositif continuait de comporter des privilèges excessifs, des accès directs historiques ou des comptes dont le cycle de vie n’était pas réellement gouverné.

Autrement dit, faire passer une connexion RDP par un bastion ne suffit pas à rendre saine toute la chaîne qui précède et suit cette connexion.

Le bastion ne corrige pas automatiquement :

• un compte trop puissant
• un poste source compromis
• un droit d’utilisation du bastion mal gouverné
• une cible joignable par un autre chemin
• un réseau autorisant des mouvements latéraux non nécessaires
• une session enregistrée sans qu’aucune alerte exploitable soit produite.

La traçabilité doit devenir exploitable

Ce dernier cas est loin d’être théorique. Dans plusieurs environnements, nous avons constaté que la principale preuve PAM disponible était constituée d’enregistrements vidéo de sessions. Ils sont utiles en investigation mais extrêmement difficiles à exploiter de manière proactive à grande échelle.

C’est un retour d’expérience tellement fréquent que nous l’avons intégré à notre cours PAM : la traçabilité doit aller au-delà de l’enregistrement passif et alimenter des mécanismes de détection et de réaction.

L’embarquement PAM est un processus durable

L’autre retour d’expérience est celui de la durée. Dans des SI complexes, plusieurs années après le lancement d’un programme PAM, de nouveaux accès RDP ou SSH continuent encore à entrer dans le périmètre. L’embarquement n’est pas un événement unique : c’est un processus durable.

Cela change profondément le critère de réussite.

Le meilleur dispositif n’est pas celui qui produit le plus beau schéma d’architecture au lancement. C’est celui dans lequel un nouvel administrateur, un nouveau serveur, un nouveau prestataire ou une nouvelle application peuvent être ajoutés sans recréer une exception technique incompréhensible.

Nous avons même intégré dans notre enseignement un retour d’expérience particulièrement parlant : lors d’un exercice de Red Team, des actifs sensibles avaient été atteints non pas en cassant directement le bastion, mais en utilisant les droits gouvernés depuis l’IAG pour remonter vers celui-ci. Le PAM, l’IAG et l’Access Management formaient en pratique une même surface de contrôle, alors qu’ils avaient été pensés trop indépendamment.

C’est précisément pour cette raison que nous évaluons désormais les programmes PAM en regardant autant la gouvernance, l’identité, le terminal et les chemins réseau que le bastion lui-même.

Votre PAM protège-t-il réellement toute la chaîne d’administration ?

Évaluez gratuitement la maturité de votre dispositif, identifiez les écarts prioritaires et obtenez une première feuille de route adaptée à votre contexte.
Lancer mon diagnostic PAM

6. Dessiner des chemins d’administration réellement utilisables

À ce stade, la question n’est plus simplement : « PAW ou pas PAW ? »

Pour chaque famille d’opérations, nous devons pouvoir répondre à six questions concrètes.

Question d’architecture	Points à qualifier
Quelle est la ressource ?	Quelle serait la conséquence de sa compromission ? Peut-elle en contrôler d’autres ?
Quelle identité l’administre ?	Compte quotidien ou identité distincte ? Droit permanent ou activé temporairement ? Quel périmètre réel ?
Depuis quel niveau de terminal ?	BYOD, équipement corporate, poste spécialisé ou PAW ?
Quel chemin réseau est nécessaire ?	Quels FQDN, IP, ports ou protocoles ? Pourquoi en ouvrir davantage ?
Faut-il un intermédiaire ?	PAM, bastion, gateway ou environnement de rebond ?
Quel contexte peut remettre en cause l’accès ?	Conformité du poste, niveau de risque, signal SOC, horaire, localisation ou changement de rôle ?

Le Tier Model reste utile pour déterminer la criticité de la destination.

Le Zero Trust permet d’être beaucoup plus précis sur les conditions dans lesquelles un chemin vers cette destination peut exister.

Et le travail d’architecture consiste à rendre le résultat exploitable.

Un administrateur ne devrait pas devoir connaître quinze règles de firewall et quatre technologies de sécurité pour comprendre comment faire son travail. Idéalement, son expérience est beaucoup plus simple : son identité détermine ce qu’il peut demander, le niveau de confiance de son poste détermine les environnements depuis lesquels cette demande peut être exercée, les privilèges sont limités au besoin et le réseau ne rend joignables que les interfaces utiles.

La complexité reste présente.

Mais elle est portée par l’architecture, pas par l’utilisateur.

C’est ce qui nous semble être le meilleur indicateur d’un SI d’administration correctement conçu : un chemin sûr doit également être un chemin compréhensible.

Faire monter vos équipes en maturité IAM et PAM

Nos formations relient les concepts, les architectures et les retours d’expérience terrain afin d’aider vos équipes à construire un dispositif adapté à leurs enjeux opérationnels.
Découvrir nos formations IAM et PAM

7. Conclusion : quand faut-il conserver une PAW ?

Dans certains environnements, cette logique conduira à généraliser les PAW.

Dans d’autres, elle conduira à distinguer plusieurs populations et plusieurs niveaux de terminal.

Dans d’autres encore, elle fera surtout apparaître que le problème prioritaire n’est pas le poste mais les privilèges permanents, la mauvaise segmentation, les identités partagées ou les chemins d’accès directs laissés en parallèle du PAM.

Il n’existe donc pas de formule permettant d’implémenter « le Tier Model sans PAW ».

Il existe en revanche une manière beaucoup plus utile d’aborder le problème :

1. Comprendre ce que le Tier Model cherche à empêcher
2. Classer les ressources selon leur capacité de contrôle ;
3. Déterminer le niveau d’assurance nécessaire pour les atteindre
4. Construire le chemin d’administration le plus simple qui respecte ce niveau.

Une PAW est l’une de ces trajectoires.

Un poste corporate fortement maîtrisé associé à une identité dédiée, une segmentation réseau fine, du JIT et un contrôle continu peut en être un autre, pour les opérations dont le niveau de risque le permet.

Le point commun doit rester le même : un environnement moins fiable ne doit pas pouvoir devenir le chemin de compromission d’un environnement plus critique.

Et, surtout, l’administrateur doit toujours savoir par où passer.

Vous devez sécuriser ou faire évoluer vos chemins d’administration ?

Ariovis vous accompagne pour évaluer l’existant, qualifier les risques et construire une trajectoire PAM et Zero Trust cohérente avec vos contraintes d’exploitation.
Parler de mon projet avec un expert Ariovis

---