Just Enough Administration (JEA) pas à pas

Le guide pilier sur la sécurité de PowerShell présentait un exemple JEA de cinq lignes. C'est suffisant pour saisir l'idée, pas pour l'exploiter en production. Ce guide va plus loin : comment concevoir des rôles dont on ne peut pas s'échapper, comment choisir l'identité d'exécution, comment déployer des points de terminaison sur de nombreux serveurs et comment prouver qu'ils font ce que vous croyez.

Just Enough Administration est un point de terminaison de communication à distance PowerShell doté de trois propriétés. L'utilisateur qui se connecte ne peut exécuter qu'un ensemble de commandes autorisées, les commandes s'exécutent sous une identité privilégiée temporaire plutôt que sous le compte de l'utilisateur, et tout est transcrit. Bien fait, il permet au support de redémarrer un service ou de vider une file d'impression sans que personne ne détienne de droits d'administrateur local sur le serveur. Voir l'entrée du glossaire JEA pour la définition courte.

Comment les pièces s'assemblent

Les capacités de rôle sont chargées au démarrage d'une session : modifier un .psrc affecte immédiatement les nouvelles sessions. Les modifications d'un .pssc ne s'appliquent qu'après un nouvel enregistrement.

Ce qui casse

Les sessions JEA sont volontairement inconfortables. Anticipez :

• Ni variables ni blocs de script. Les sessions RestrictedRemoteServer sont par défaut en mode NoLanguage. Les utilisateurs exécutent des commandes ; ils ne peuvent pas écrire $x = Get-Service ni ForEach-Object { }. Placez la logique dans des fonctions de votre module.
• Pas de double saut. Un compte virtuel est local au serveur. Tout ce qui doit atteindre un partage de fichiers, SQL ou AD depuis la session nécessite plutôt un gMSA.
• Pas de copie de fichiers par défaut. Copy-Item -ToSession ne fonctionne qu'avec un lecteur utilisateur (MountUserDrive), et uniquement vers ce lecteur.
• Les outils graphiques ne l'utilisent pas. Server Manager, les composants logiciels enfichables MMC et RDP ignorent les points de terminaison JEA. Les opérateurs ont besoin de scripts ou de la communication à distance implicite.

Étape 1 : inventorier les tâches

Partez des tickets, pas des cmdlets. Pour chaque tâche récurrente, notez la commande exacte et les valeurs de paramètres dont elle a besoin :

• Redémarrer le spouleur d'impression sur les serveurs d'impression.
• Supprimer les travaux bloqués d'une file nommée.
• Lire les 50 derniers événements Système.

Si une tâche exige une saisie arbitraire (n'importe quel service, n'importe quel chemin), c'est un signal d'alerte. Chaque paramètre libre est une voie d'évasion potentielle.

Étape 2 : construire le module de capacité de rôle

Créez un petit module pour héberger le rôle. Le module a besoin d'un manifeste, même si le .psm1 est vide :

$mod = "C:\Program Files\WindowsPowerShell\Modules\CorpJEA"
New-Item -ItemType Directory -Path "$mod\RoleCapabilities" -Force | Out-Null
New-Item -ItemType File -Path "$mod\CorpJEA.psm1" -Force | Out-Null
New-ModuleManifest -Path "$mod\CorpJEA.psd1" -RootModule 'CorpJEA.psm1'

Passons au rôle. Contraignez les paramètres avec ValidateSet ou ValidatePattern partout où c'est possible :

New-PSRoleCapabilityFile -Path "$mod\RoleCapabilities\PrintOperator.psrc" `
  -VisibleCmdlets @(
    @{ Name = 'Restart-Service'; Parameters = @{ Name = 'Name'; ValidateSet = 'Spooler' } },
    @{ Name = 'Get-Service';     Parameters = @{ Name = 'Name'; ValidateSet = 'Spooler' } },
    @{ Name = 'Get-PrintJob';    Parameters = @{ Name = 'PrinterName'; ValidatePattern = '^PRN-[A-Z0-9-]+$' } },
    @{ Name = 'Remove-PrintJob'; Parameters = @(
         @{ Name = 'PrinterName'; ValidatePattern = '^PRN-[A-Z0-9-]+$' },
         @{ Name = 'ID' }) }
  ) `
  -VisibleFunctions 'Get-CorpSystemEvents'

Get-CorpSystemEvents est une fonction que vous écrivez dans CorpJEA.psm1, par exemple une enveloppe autour de Get-WinEvent -LogName System -MaxEvents 50. Les fonctions de votre module sont le bon endroit pour tout ce qui nécessite des variables ou des boucles : les utilisateurs peuvent les appeler, mais pas voir ni modifier leur corps.

Excluez ceci de tous les rôles, à moins de comprendre exactement pourquoi c'est là, car chacun de ces éléments refait du point de terminaison un accès administrateur complet :

• Invoke-Expression, Invoke-Command, Start-Process, New-Service, Register-ScheduledTask, Add-Type.
• Tout ce qui modifie l'appartenance aux groupes (Add-LocalGroupMember, Add-ADGroupMember).
• Les fournisseurs de fichiers et de registre via VisibleProviders, ainsi que Set-Content, Copy-Item ou New-Item sans contrainte de chemin.
• Des VisibleExternalCommands pointant vers cmd.exe, powershell.exe ou n'importe quel interpréteur.

Une cmdlet dotée d'un paramètre -ScriptBlock, -FilePath ou -ComputerName non contraint mérite la même méfiance.

Étape 3 : écrire la configuration de session

New-PSSessionConfigurationFile -Path .\PrintOps.pssc `
  -SessionType RestrictedRemoteServer `
  -RunAsVirtualAccount `
  -RunAsVirtualAccountGroups 'JEA-PrintSvc' `
  -TranscriptDirectory 'C:\ProgramData\JEA\Transcripts' `
  -RoleDefinitions @{ 'CORP\JEA-PrintOps' = @{ RoleCapabilities = 'PrintOperator' } } `
  -RequiredGroups @{ And = 'CORP\JEA-PrintOps', 'CORP\SmartCardUsers' }

Test-PSSessionConfigurationFile -Path .\PrintOps.pssc

JEA-PrintSvc est un groupe local du serveur auquel vous n'accordez que les droits nécessaires au rôle, par exemple les droits de démarrage et d'arrêt sur le service Spooler (via le descripteur de sécurité du service) et Manage documents sur les files d'impression. Construire ce groupe demande plus d'effort que d'accepter l'administrateur local, et c'est précisément cet effort qui rend le point de terminaison sûr.

L'identité d'exécution est ici la décision la plus importante :

Le comportement par défaut Domain Admins sur les contrôleurs de domaine piège bien des équipes. Un point de terminaison JEA sur un DC avec un compte virtuel non restreint et une seule commande permettant de s'échapper, c'est un shell Domain Admin pour quiconque peut s'y connecter. Restreignez-le toujours, ou utilisez un gMSA doté de droits délégués précis.

RequiredGroups ajoute une condition qui doit être vraie quel que soit le rôle, par exemple que l'utilisateur se soit aussi connecté avec une carte à puce (via un groupe d'authentication mechanism assurance). Elle est évaluée au moment de la connexion.

Étape 4 : enregistrer le point de terminaison

Register-PSSessionConfiguration -Name PrintOps -Path .\PrintOps.pssc -Force

L'enregistrement redémarre le service WinRM, ce qui coupe les sessions distantes existantes. Faites-le pendant une fenêtre de maintenance sur les serveurs chargés.

Vérifiez ensuite les points de terminaison par défaut. Get-PSSessionConfiguration liste chaque point de terminaison et qui peut l'utiliser :

Get-PSSessionConfiguration | Select-Object Name, Permission

Les points de terminaison intégrés microsoft.powershell autorisent Administrators et Remote Management Users. Les utilisateurs JEA ne doivent appartenir à aucun de ces groupes, sinon ils peuvent ignorer purement et simplement votre point de terminaison. Nettoyez l'appartenance aux groupes dans le cadre de la suppression des droits d'administrateur local.

Étape 5 : déployer à grande échelle

L'enregistrement manuel des points de terminaison ne tient pas au-delà de quelques serveurs. Deux schémas courants :

• Distribution logicielle plus un script. Empaquetez le dossier du module et le .pssc, copiez le module dans C:\Program Files\WindowsPowerShell\Modules, puis exécutez Register-PSSessionConfiguration. Utilisez la version du module dans le manifeste comme règle de détection.
• Desired State Configuration. Le module de ressources communautaire JeaDsc déclare points de terminaison et capacités de rôle sous forme de configuration, ce qui corrige aussi la dérive. Vérifiez l'état de maintenance actuel du module avant de vous y fier.

Conservez les fichiers .psrc et .pssc dans un gestionnaire de versions avec revue de code. Ce sont des configurations privilégiées, au même titre qu'une GPO qui accorde des droits d'administrateur.

Vérifier

D'abord, demandez au serveur ce qu'obtiendrait un utilisateur donné, sans vous connecter :

Get-PSSessionCapability -ConfigurationName PrintOps -Username 'CORP\alice'

La sortie liste les commandes exactes accessibles à cet utilisateur. Tout élément inattendu est une erreur de conception.

Connectez-vous ensuite en tant qu'opérateur de test :

Enter-PSSession -ComputerName prn01.corp.example -ConfigurationName PrintOps
Get-Command                      # seulement les commandes autorisées, plus celles par défaut
Restart-Service -Name Spooler    # fonctionne
Restart-Service -Name WinRM      # échoue à la validation des paramètres
$env:USERNAME                    # échoue : pas de langage

Consultez la transcription dans C:\ProgramData\JEA\Transcripts. L'en-tête indique à la fois l'utilisateur connecté et le compte d'exécution, ce qui rend JEA auditable. Transférez ces transcriptions, ainsi que les événements PowerShell 4104 générés dans la session, comme décrit dans détecter le PowerShell malveillant.

Enfin, essayez délibérément de vous échapper. Exécutez chaque commande visible avec des arguments inhabituels, redirigez les sorties vers d'autres commandes visibles, et cherchez tout ce qui écrit des fichiers, lance des processus ou modifie des groupes. Une courte revue interne par quelqu'un qui n'a pas écrit le rôle trouve la plupart des évasions.

Exploiter JEA

• Protégez le transport du point de terminaison. JEA s'exécute sur WinRM et hérite donc de sa configuration. Appliquez le durcissement de WinRM : Kerberos, pas de Basic, pas de CredSSP, et restriction par pare-feu aux hôtes de gestion.
• Associez les rôles aux tiers. Un point de terminaison JEA sur un serveur Tier 0 est un actif Tier 0, et le groupe qui accorde le rôle est un groupe Tier 0. Suivez votre modèle de tiering de l'administration.
• Revue trimestrielle. Comparez les capacités de rôle avec l'usage réel dans les transcriptions. Retirez les commandes que personne n'exécute.
• Alertez sur les modifications de points de terminaison. Une configuration de session nouvelle ou modifiée apparaît comme un changement sous WSMan:\localhost\Plugin ; surveillez-le, ainsi que le dossier du module, avec vos outils d'intégrité des fichiers ou de gestion de configuration.

Davantage de contexte sur JEA et les autres contrôles PowerShell sur la page thématique Sécurité de PowerShell.

Liste de contrôle

• Tâches opérationnelles récurrentes listées avec commandes et valeurs de paramètres exactes
• Module de capacité de rôle avec paramètres contraints ; aucun interpréteur, lancement de processus, modification de groupe ni accès fichier non contraint
• La configuration de session utilise RestrictedRemoteServer et un compte virtuel restreint ou un gMSA
• Aucun compte virtuel non restreint sur un contrôleur de domaine
• RequiredGroups utilisé pour les rôles sensibles (par exemple assurance carte à puce ou MFA)
• Utilisateurs JEA retirés d'Administrators et de Remote Management Users
• Sortie de Get-PSSessionCapability revue pour chaque rôle
• Transcriptions et événements 4104 transférés et conservés
• Fichiers de rôle et de session dans un gestionnaire de versions et déployés automatiquement