Un serveur de rebond peut-il remplacer un PAW ?

Non, pas à lui seul. Un serveur de rebond protège la cible, mais les frappes clavier et les identifiants de l'administrateur proviennent toujours du poste devant lequel il est assis. Si ce poste est une station de travail ordinaire avec messagerie et navigateur, un logiciel malveillant peut y capturer les identifiants saisis dans la session RDP ou détourner la session elle-même. Un serveur de rebond n'est acceptable que s'il est atteint depuis un PAW ; il devient alors une extension du Tier 0, pas un substitut.

Un seul PAW physique peut-il servir à l'administration Tier 0 et Tier 1 ?

Uniquement si le tier le plus élevé est l'hôte et que les tiers inférieurs s'exécutent en invités. Un PAW Tier 0 peut héberger une VM Tier 1 ou utilisateur, car l'hôte contrôle l'invité. L'inverse, une VM Tier 0 sur un portable Tier 1 ou utilisateur, donne à l'hôte moins fiable le contrôle total de la session Tier 0 et viole le principe de source propre.

Comment les PAW doivent-ils recevoir les mises à jour Windows sans accès Internet ?

Pointez-les vers une source de mises à jour contrôlée par le Tier 0, comme une instance WSUS dédiée ou une stratégie Windows Update for Business étroitement délimitée, avec une liste d'autorisation sortante limitée aux points de terminaison de mise à jour Microsoft. Ne laissez pas la hiérarchie SCCM de l'entreprise corriger les PAW, sauf si elle est elle-même gérée comme du Tier 0, car qui déploie des mises à jour peut déployer du code.

Construire des postes d'administration à privilèges (PAW)

Un identifiant Tier 0 n'est pas plus fiable que le clavier sur lequel il est saisi. Les droits de refus d'ouverture de session et les silos d'authentification déterminent où un Domain Admin peut s'authentifier, mais si cet endroit est un portable qui ouvre aussi des pièces jointes et navigue sur le Web, une seule charge de phishing capture tout. Le poste d'administration à privilèges (PAW) comble cette faille en appliquant le principe de source propre : un système utilisé pour contrôler un actif doit être au moins aussi fiable que l'actif lui-même.

Ce guide explique comment construire un PAW qui tienne la route : exigences matérielles, provenance de l'image, plan de gestion, liste d'autorisation des applications, restrictions réseau et articulation des PAW avec les serveurs de rebond. La raison d'être des PAW est présentée dans Tier 0 et accès à privilèges. Ici, on en construit un.

Les choix de conception avant la construction

PAW physique, hôte de VM ou Cloud PC

Trois modèles sont courants :

Modèle	Description	Compromis
Poste dédié	Portable distinct réservé au travail d'administration	Le plus robuste, mais les administrateurs transportent deux appareils
Hôte PAW avec VM utilisateur	Le PAW est l'OS physique ; le bureau du quotidien s'exécute en invité Hyper-V ou via VDI	Un seul appareil, principe de source propre préservé
PAW Cloud PC / VDI	Session Windows 365 ou VDI durcie	Pas plus propre que l'appareil qui s'y connecte, et les administrateurs du tenant entrent dans le Tier 0

La règle : le tier le plus fiable doit constituer la couche la plus externe. Exécuter une VM Tier 0 sur un portable standard inverse cette logique : le compte SYSTEM du portable, et tout logiciel malveillant qui s'y trouve, peuvent lire la mémoire et les frappes clavier de l'invité.

Qui gère le PAW

Le plan de gestion du PAW relève du Tier 0. Si votre SCCM d'entreprise, votre tenant Intune ou votre console EDR peut diffuser des scripts sur les PAW, quiconque contrôle cette console contrôle vos Domain Admins. Donnez aux PAW un circuit de gestion dédié (un petit WSUS Tier 0 et une configuration uniquement par GPO suffisent à beaucoup d'organisations) ou délimitez les outils d'entreprise pour que les opérateurs Tier 1 ne puissent pas cibler les regroupements de PAW. Consignez la décision dans votre inventaire Tier 0.

Socle matériel et micrologiciel

Achetez du matériel qui prend en charge les protections basées sur la virtualisation que vous allez imposer :

TPM 2.0, UEFI avec Secure Boot activé, et un mot de passe administrateur du micrologiciel (BIOS) défini et conservé dans un coffre.
Extensions de virtualisation du processeur et IOMMU (VT-d / AMD-Vi) pour VBS et la protection DMA du noyau.
Démarrage sur support externe désactivé dans le micrologiciel ; protection Thunderbolt/DMA activée.
Idéalement un modèle unique, acquis via une chaîne d'approvisionnement maîtrisée et stocké en lieu sûr avant l'installation de l'image.

Construire une image saine

Installez à partir d'un média Microsoft dont vous avez vérifié le hachage, et non depuis l'image de référence de l'entreprise, qui embarque des agents et des logiciels détenus par des tiers inférieurs. Joignez la machine directement dans une UO dédiée (par exemple OU=Devices,OU=Tier0) en ayant revu l'héritage des GPO afin que seules les GPO Tier 0 s'appliquent.

Activez ensuite les protections de la plateforme par une GPO liée à l'UO des PAW :

VBS et Credential Guard : Computer Configuration > Policies > Administrative Templates > System > Device Guard > Turn On Virtualization Based Security sur Enabled, avec Secure Boot et DMA Protection, Virtualization Based Protection of Code Integrity activé avec verrouillage UEFI, et Credential Guard Configuration sur Enabled with UEFI lock.
BitLocker avec TPM+PIN : Computer Configuration > Policies > Administrative Templates > Windows Components > BitLocker Drive Encryption > Operating System Drives > Require additional authentication at startup.
Protection des identifiants à distance : Computer Configuration > Policies > Administrative Templates > System > Credentials Delegation > Restrict delegation of credentials to remote servers, sur Require Remote Credential Guard ou Restrict Credential Delegation, afin que les sessions RDP ouvertes depuis le PAW ne laissent pas d'identifiants réutilisables sur la cible.
Stockage amovible : Computer Configuration > Policies > Administrative Templates > System > Removable Storage Access > All Removable Storage classes: Deny all access, avec un processus d'exception pour les supports chiffrés approuvés si vous avez besoin de transférer des fichiers.

Les administrateurs locaux du PAW doivent se limiter à un compte bris de glace géré par LAPS. L'administrateur qui utilise le PAW ouvre une session avec un compte standard propre à l'appareil et élève ses privilèges vers son compte Tier 0 pour les tâches d'administration, ou ouvre directement une session avec le compte Tier 0 si le PAW est dédié. Dans les deux cas, il n'est pas administrateur local.

Mettre les applications en liste d'autorisation

Un PAW exécute une liste courte et connue de logiciels : RSAT, PowerShell, les composants logiciels enfichables MMC que vous utilisez, le client PAM et éventuellement un navigateur durci limité aux portails d'administration internes. Imposez cette liste avec App Control for Business (WDAC) ou, au minimum, AppLocker.

AppLocker se trouve sous Computer Configuration > Policies > Windows Settings > Security Settings > Application Control Policies > AppLocker. Commencez par les règles par défaut en mode audit, collectez les événements 8003 et 8006 (exécution qui aurait été bloquée) dans Microsoft-Windows-AppLocker/EXE and DLL et MSI and Script, puis passez en mode application. Vérifiez que le service Application Identity démarre automatiquement, sans quoi AppLocker n'applique rien.

PowerShell

# Examiner ce qui serait bloqué pendant la phase d'audit
Get-WinEvent -LogName 'Microsoft-Windows-AppLocker/EXE and DLL' -MaxEvents 500 |
    Where-Object Id -eq 8003 |
    Group-Object Message | Sort-Object Count -Descending |
    Select-Object Count, Name

# Confirmer la stratégie effective sur un PAW
Get-AppLockerPolicy -Effective -Xml | Out-File "$env:TEMP\paw-applocker.xml"

App Control for Business est plus robuste, car il s'applique au mode noyau et se contourne plus difficilement depuis un contexte administrateur. L'App Control Wizard de Microsoft et le module PowerShell ConfigCI (New-CIPolicy, ConvertFrom-CIPolicy) génèrent des stratégies à partir d'un PAW de référence.

Couper Internet et la messagerie

Un PAW ne doit ni naviguer sur Internet ni lire de messages. Mettez-le en œuvre à deux niveaux :

Pare-feu de l'hôte : Computer Configuration > Policies > Windows Settings > Security Settings > Windows Defender Firewall with Advanced Security. Réglez le trafic sortant sur Block pour tous les profils et n'ajoutez des règles d'autorisation que vers les destinations Tier 0 (DC, serveurs Tier 0, plateforme PAM, source de mises à jour). Bloquez toutes les connexions entrantes.
Réseau : placez les PAW dans un VLAN dédié dont la sortie est limitée aux mêmes destinations Tier 0, afin qu'un administrateur local qui désactiverait le pare-feu ne rouvre pas l'accès à Internet.

N'installez ni Outlook, ni Teams, ni navigateur généraliste. Si les administrateurs ont besoin de documentation, ils la consultent sur leur poste standard à côté du PAW.

PAW et serveurs de rebond

Les serveurs de rebond (ou serveurs d'administration Tier 0 équipés de RSAT) sont utiles : ils centralisent l'outillage, maintiennent les sessions Tier 0 sur des serveurs que vous pouvez journaliser et capturer en instantané, et réduisent le nombre de machines qui conservent des identifiants Tier 0 en mémoire. Ils ne suppriment pas le besoin d'un PAW, car l'appareil qui lance la session RDP voit chaque frappe. La combinaison qui fonctionne est PAW → serveur de rebond Tier 0 → DC, avec un serveur de rebond durci au même niveau et joignable uniquement depuis le VLAN des PAW.

Imposez ce chemin dans AD : les comptes Tier 0 reçoivent Allow log on locally et Allow log on through Remote Desktop Services uniquement sur les PAW et les serveurs Tier 0, et sont refusés partout ailleurs par les GPO de refus d'ouverture de session par tier. Les stratégies et silos d'authentification ajoutent la même restriction au niveau du KDC.

Exploiter la flotte de PAW

Un programme PAW échoue plus souvent à l'exploitation qu'à la conception. Tranchez les points suivants avant la livraison du premier appareil.

Provisionnement et garde. Tenez un registre de chaque PAW : numéro de série, clé d'approbation (endorsement key) du TPM ou hachage matériel, administrateur attribué, UO et date de construction. Remettez les appareils en main propre et faites définir le PIN BitLocker par l'administrateur au premier démarrage. Un PAW laissé sans surveillance hors d'une zone contrôlée, envoyé en réparation ou déclaré perdu est réinstallé ou mis au rebut, jamais simplement remis en service.

Rythme de reconstruction. Même un PAW bien maîtrisé accumule de l'état. Le reconstruire à partir de l'image saine selon un calendrier fixe (tous les six à douze mois est courant) et après tout incident de sécurité limite la durée de vie d'un implant non détecté. Comme rien de personnel ne réside sur un PAW, une reconstruction doit prendre des heures, pas des jours.

Quels comptes ouvrent une session. Deux modèles fonctionnent. Dans le premier, l'administrateur se connecte au PAW directement avec son compte Tier 0 ; l'appareil est dédié et rien d'autre n'y tourne. Dans le second, l'administrateur se connecte avec un compte standard propre au PAW et utilise runas ou le client PAM pour lancer les outils sous le compte Tier 0. Évitez de vous connecter avec le compte utilisateur du quotidien qui lit les e-mails ailleurs : son mot de passe et ses jetons sont par construction exposés sur des machines hors Tier 0.

Supervision. Transférez les journaux de sécurité des PAW vers le même pipeline que ceux des DC. Les signaux utiles sont l'apparition de nouveaux administrateurs locaux, les blocages AppLocker ou App Control en mode application, les modifications de règles de pare-feu, la désactivation de Credential Guard ou de BitLocker, et les ouvertures de session de tout compte qui n'est pas un administrateur Tier 0 attribué.

Bris de glace. Si le PAW lui-même est en panne ou indisponible pendant un incident, les administrateurs trouveront un autre chemin. Donnez-leur-en un documenté : un PAW de rechange scellé, ou un accès console à un serveur de rebond Tier 0 dans le datacenter, l'utilisation de l'un ou l'autre étant journalisée et revue a posteriori.

Vérifier

Exécutez ces contrôles sur chaque PAW après sa construction, puis de manière planifiée :

PowerShell

# Credential Guard et HVCI en cours d'exécution (1 = Credential Guard, 2 = HVCI)
Get-CimInstance -Namespace root\Microsoft\Windows\DeviceGuard -ClassName Win32_DeviceGuard |
    Select-Object VirtualizationBasedSecurityStatus, SecurityServicesConfigured, SecurityServicesRunning

# Protection BitLocker sur le lecteur du système d'exploitation
Get-BitLockerVolume -MountPoint $env:SystemDrive | Select-Object VolumeStatus, ProtectionStatus, KeyProtector

# Le groupe Administrateurs local ne contient que le compte attendu géré par LAPS
Get-LocalGroupMember -SID 'S-1-5-32-544'

# L'action sortante par défaut est Block sur chaque profil
Get-NetFirewallProfile | Select-Object Name, Enabled, DefaultOutboundAction, DefaultInboundAction

# Internet doit être injoignable
Test-NetConnection -ComputerName www.microsoft.com -Port 443 | Select-Object TcpTestSucceeded

TcpTestSucceeded doit valoir False. Côté DC, examinez les événements d'ouverture de session 4624 des comptes Tier 0 et confirmez que le WorkstationName et les adresses IP sources ne correspondent qu'à des PAW et à des serveurs de rebond Tier 0.

Ce que cela casse

Le confort des administrateurs : ils perdent le copier-coller depuis la messagerie et la recherche Web sur le même écran. Attendez-vous à des résistances les premières semaines et prévoyez un second écran ou le modèle hôte/invité.
Remote Credential Guard et Restricted Admin ne fonctionnent pas avec toutes les cibles : Remote Credential Guard exige Windows 10 1607 / Server 2016 ou ultérieur sur la cible ainsi que l'authentification Kerberos. Restricted Admin ne permet aucun second saut en tant qu'administrateur, et Remote Credential Guard ne fait que rediriger les requêtes Kerberos de second saut vers le PAW tant que la session est connectée : les scripts planifiés ou sans surveillance sur le serveur de rebond qui dépendent des identifiants délégués de l'administrateur échoueront.
App Control et AppLocker bloquent les outils ponctuels, les binaires portables et de nombreux installateurs d'éditeurs. Chaque nouvel outil d'administration nécessite une mise à jour de la stratégie, ce qui est voulu mais exige un responsable.
Credential Guard casse NTLMv1, les VPN et le Wi-Fi basés sur MS-CHAPv2 avec identifiants enregistrés, ainsi que la délégation Kerberos non contrainte depuis l'appareil.
L'absence d'Internet casse les consoles cloud. L'administration Entra et Microsoft 365 nécessite soit une liste d'autorisation explicite des points de terminaison d'administration sur le PAW, soit un profil de PAW distinct pour l'administration cloud.

Pour aller plus loin : la vue d'ensemble du domaine Tier 0, le déploiement de Windows LAPS pour le compte administrateur local du PAW, et le modèle d'accès d'entreprise pour la place des PAW dans une stratégie moderne d'accès à privilèges.