Considérations relatives à la sécurité JEA

JEA vous aide à améliorer votre posture de sécurité en réduisant le nombre d’administrateurs permanents sur vos machines. JEA utilise une configuration de session PowerShell pour créer un point d’entrée pour permettre aux utilisateurs de gérer le système. Les utilisateurs qui ont besoin d’un accès élevé, mais pas illimité, à la machine pour effectuer des tâches d’administration peuvent être autorisés à accéder au point de terminaison JEA. Étant donné que JEA permet à ces utilisateurs d’exécuter des commandes d’administration sans avoir un accès administrateur complet, vous pouvez ensuite supprimer ces utilisateurs des groupes de sécurité hautement privilégiés.

compte Run-As

Chaque point de terminaison JEA a un compte d’exécution en tant que désigné sous lequel les actions de l’utilisateur de connexion sont exécutées. Ce compte est configurable dans le fichier de configuration de session, et le compte que vous choisissez a un impact significatif sur la sécurité de votre point de terminaison.

Les comptes virtuels sont la méthode recommandée pour configurer le compte d’exécution. Les comptes virtuels sont des comptes locaux temporaires à usage unique créés pour permettre à l’utilisateur de connexion d’utiliser pendant la durée de sa session JEA. Dès que leur session est terminée, le compte virtuel est détruit et ne peut plus être utilisé. L’utilisateur connecté ne connaît pas les informations d’identification du compte virtuel. Le compte virtuel ne peut pas être utilisé pour accéder au système via d’autres moyens, tels que le Bureau à distance ou un point de terminaison PowerShell non contraint.

Par défaut, les comptes virtuels sont membres du groupe Administrateurs local sur l’ordinateur. Cette appartenance leur donne des droits complets pour gérer n’importe quoi sur le système, mais aucun droit de gestion des ressources sur le réseau. Lorsque l’utilisateur se connecte à d’autres ordinateurs à partir de la session JEA, le contexte utilisateur est celui du compte d’ordinateur local, et non du compte virtuel.

Les contrôleurs de domaine sont un cas spécial, car il n’existe pas de groupe Administrateurs local. Au lieu de cela, les comptes virtuels appartiennent aux administrateurs de domaine et peuvent gérer les services d’annuaire sur le contrôleur de domaine. L’identité de domaine est toujours restreinte pour une utilisation sur le contrôleur de domaine où la session JEA a été instanciée. Tout accès réseau semble plutôt provenir de l'objet ordinateur du contrôleur de domaine.

Dans les deux cas, vous pouvez affecter le compte virtuel à des groupes de sécurité spécifiques, en particulier lorsque la tâche peut être effectuée sans privilèges d’administrateur local ou de domaine. Si vous disposez déjà d’un groupe de sécurité défini pour vos administrateurs, accordez l’appartenance au compte virtuel à ce groupe. L’appartenance aux groupes pour les comptes virtuels est limitée aux groupes de sécurité locaux sur les stations de travail et serveurs membres. Sur les contrôleurs de domaine, les comptes virtuels doivent être membres de groupes de sécurité de domaine. Une fois le compte virtuel ajouté à un ou plusieurs groupes de sécurité, il n’appartient plus aux groupes par défaut (administrateurs locaux ou de domaine).

Le tableau suivant récapitule les options de configuration possibles et les autorisations résultantes pour les comptes virtuels :

Type d’ordinateur	Configuration du groupe de comptes virtuels	Contexte utilisateur local	Contexte utilisateur réseau
Contrôleur de domaine	Par défaut	Utilisateur de domaine, membre de <DOMAIN>\Domain Admins	Compte d'ordinateur
Contrôleur de domaine	Groupes de domaines A et B	Utilisateur de domaine, membre de <DOMAIN>\A, <DOMAIN>\B	Compte d'ordinateur
Serveur membre ou station de travail	Par défaut	Utilisateur local, membre de BUILTIN\Administrators	Compte d'ordinateur
Serveur membre ou station de travail	Groupes locaux C et D	Utilisateur local, membre de <COMPUTER>\C et de <COMPUTER>\D	Compte d'ordinateur

Lorsque vous examinez les journaux d’événements d’audit de sécurité et d’application, vous voyez que chaque session utilisateur JEA a un compte virtuel unique. Ce compte unique vous aide à suivre les actions des utilisateurs dans un point de terminaison JEA jusqu'à l’utilisateur d’origine qui a exécuté la commande. Les noms de comptes virtuels suivent le format WinRM Virtual Users\WinRM_VA_<ACCOUNTNUMBER>_<DOMAIN>_<sAMAccountName> Par exemple, si l’utilisateur Alice dans le domaine Contoso redémarre un service dans un point de terminaison JEA, le nom d’utilisateur associé à tous les événements du gestionnaire de contrôle de service serait WinRM Virtual Users\WinRM_VA_1_contoso_alice.

Les comptes de service gérés par groupe (gMSA) sont utiles lorsqu’un serveur membre doit avoir accès aux ressources réseau dans la session JEA. Par exemple, lorsqu’un point de terminaison JEA est utilisé pour contrôler l’accès à un service d’API REST hébergé sur un autre ordinateur. Il est facile d’écrire des fonctions pour appeler les API REST, mais vous avez besoin d’une identité réseau pour vous authentifier auprès de l’API. L’utilisation d’un compte de service géré par un groupe permet le deuxième tronçon tout en conservant le contrôle sur les ordinateurs pouvant utiliser le compte. Les appartenances au groupe de sécurité (local ou domaine) du compte gMSA ont défini les autorisations effectives pour le compte gMSA.

Lorsqu’un point de terminaison JEA est configuré pour utiliser un gMSA, les actions de tous les utilisateurs JEA semblent provenir du même GMSA. La seule façon de tracer des actions vers un utilisateur spécifique consiste à identifier l’ensemble de commandes exécutées dans une transcription de session PowerShell.

Les informations d'identification de type pass-through sont utilisées lorsque vous ne spécifiez pas de compte run-as. PowerShell utilise les informations d’identification de l’utilisateur de connexion pour exécuter des commandes sur le serveur distant. Pour utiliser des informations d’identification directes, vous devez accorder à l’utilisateur connecté un accès direct aux groupes d’administration privilégiés. Cette configuration n’est pas recommandée pour JEA. Si l’utilisateur connecté dispose déjà de privilèges d’administrateur, il peut contourner JEA et gérer le système à l’aide d’autres méthodes d’accès.

Les comptes d’identification standard vous permettent de spécifier n’importe quel compte d’utilisateur sous lequel s’exécute la session PowerShell entière. Les configurations de session utilisant des comptes 'exécuter en tant que' fixes (avec le -RunAsCredential paramètre) ne sont pas compatibles avec JEA. Les définitions de rôle ne fonctionnent plus comme prévu. Chaque utilisateur autorisé à accéder au point de terminaison est affecté au même rôle.

Vous ne devez pas utiliser un RunAsCredential sur un point de terminaison JEA, car il est difficile de retracer les actions jusqu'à des utilisateurs spécifiques et cela ne prend pas en charge le mappage des utilisateurs aux rôles.

ACL du point de terminaison WinRM

Comme pour les points de terminaison PowerShell pour la communication à distance standard, chaque point de terminaison JEA dispose d'une liste de contrôle d'accès distincte (ACL) qui détermine qui peut s'authentifier. Si la configuration est incorrecte, les utilisateurs approuvés peuvent ne pas être en mesure d’accéder au point de terminaison JEA et les utilisateurs non approuvés peuvent avoir accès. La liste de contrôle d’accès WinRM n’influence pas l’attribution des utilisateurs aux rôles JEA. Le mappage est contrôlé par le champ RoleDefinitions dans le fichier de configuration de session utilisé pour inscrire le point de terminaison.

Par défaut, lorsqu’un point de terminaison JEA a plusieurs fonctionnalités de rôle, la liste de contrôle d’accès WinRM est configurée pour autoriser l’accès à tous les utilisateurs mappés. Par exemple, une session JEA configurée à l’aide des commandes suivantes accorde un accès complet à CONTOSO\JEA_Lev1 et CONTOSO\JEA_Lev2.

$roles = @{ 'CONTOSO\JEA_Lev1' = 'Lev1Role'; 'CONTOSO\JEA_Lev2' = 'Lev2Role' }
New-PSSessionConfigurationFile -Path '.\jea.pssc' -SessionType RestrictedRemoteServer -RoleDefinitions $roles -RunAsVirtualAccount
Register-PSSessionConfiguration -Path '.\jea.pssc' -Name 'MyJEAEndpoint'

Vous pouvez auditer les autorisations utilisateur avec l’applet de commande Get-PSSessionConfiguration .

Get-PSSessionConfiguration -Name 'MyJEAEndpoint' | Select-Object Permission

Permission
----------
CONTOSO\JEA_Lev1 AccessAllowed
CONTOSO\JEA_Lev2 AccessAllowed

Pour modifier les utilisateurs qui ont accès, exécutez Set-PSSessionConfiguration -Name 'MyJEAEndpoint' -ShowSecurityDescriptorUI une invite interactive ou Set-PSSessionConfiguration -Name 'MyJEAEndpoint' -SecurityDescriptorSddl <SDDL string> mettez à jour les autorisations. Les utilisateurs ont besoin d'au moins des droits d'invocation pour accéder au point de terminaison JEA.

Il est possible de créer un point de terminaison JEA qui ne mappe pas un rôle défini à chaque utilisateur ayant accès. Ces utilisateurs peuvent démarrer une session JEA, mais n’ont accès qu’aux applets de commande par défaut. Vous pouvez auditer les autorisations utilisateur dans un point de terminaison JEA en exécutant Get-PSSessionCapability. Pour plus d’informations, consultez Audit et création de rapports sur JEA.

Rôles de privilège minimum

Lors de la conception de rôles JEA, il est important de se rappeler que les comptes de service gérés par des groupes et virtuels exécutés en arrière-plan peuvent avoir un accès illimité à l’ordinateur local. Les fonctionnalités de rôle JEA permettent de limiter les commandes et les applications qui peuvent être exécutées dans ce contexte privilégié. Les rôles mal conçus peuvent autoriser des commandes dangereuses qui peuvent permettre à un utilisateur de sortir des limites jeA ou d’obtenir l’accès aux informations sensibles.

Par exemple, considérez l’entrée de fonctionnalité de rôle suivante :

@{
    VisibleCmdlets = 'Microsoft.PowerShell.Management\*-Process'
}

Cette fonctionnalité de rôle permet aux utilisateurs d’exécuter n’importe quelle applet de commande PowerShell avec le nom Process à partir du module Microsoft.PowerShell.Management . Les utilisateurs peuvent avoir besoin d’accéder aux applets de commande comme Get-Process pour voir quelles applications s’exécutent sur le système et Stop-Process pour tuer les applications qui ne répondent pas. Toutefois, cette entrée autorise également Start-Process, qui peut être utilisé pour lancer un programme quelconque avec les privilèges d'administrateur. Le programme n’a pas besoin d’être installé localement sur le système. Un utilisateur connecté peut démarrer un programme à partir d’un partage de fichiers qui donne aux utilisateurs des privilèges d’administrateur local, exécute des programmes malveillants, etc.

Une version plus sécurisée de cette même fonctionnalité de rôle se présente comme suit :

@{
    VisibleCmdlets = 'Microsoft.PowerShell.Management\Get-Process',
                     'Microsoft.PowerShell.Management\Stop-Process'
}

Évitez d’utiliser des caractères génériques dans les fonctionnalités de rôle. Veillez à auditer régulièrement les autorisations utilisateur effectives pour voir quelles commandes sont accessibles à un utilisateur. Pour plus d’informations, consultez la section Vérifier les droits effectifs de l’article Audit et Création de rapports sur JEA .

Recommandations de bonnes pratiques

Voici les recommandations de bonnes pratiques pour garantir la sécurité de vos points de terminaison JEA :

Limiter l’utilisation et les fonctionnalités des fournisseurs PowerShell

Passez en revue la façon dont les fournisseurs autorisés sont utilisés pour vous assurer que vous ne créez pas de vulnérabilités dans votre session configurée.

Avertissement

N’autorisez pas le fournisseur FileSystem . Si les utilisateurs peuvent écrire dans une partie du système de fichiers, il est possible de contourner complètement la sécurité.

N’autorisez pas le fournisseur de certificats . Une fois le fournisseur activé, un utilisateur peut accéder aux clés privées stockées.

N’autorisez pas les commandes qui peuvent créer de nouveaux espaces d’exécution.

Avertissement

Les *-Job applets de commande peuvent créer de nouveaux espaces d’exécution sans les restrictions.

N’autorisez pas l’applet Trace-Command de commande.

Avertissement

L'utilisation de Trace-Command regroupe toutes les commandes tracées dans la session.

Ne créez pas vos propres implémentations de proxy pour les commandes restreintes.

PowerShell a un ensemble de commandes proxy pour les scénarios de commande restreint. Ces commandes proxy garantissent que les paramètres d’entrée ne peuvent pas compromettre la sécurité de la session. Les commandes suivantes ont des proxys restreints :

• Exit-PSSession
• Get-Command
• Get-FormatData
• Get-Help
• Measure-Object
• Out-Default
• Select-Object

Si vous créez votre propre implémentation de ces commandes, vous pouvez autoriser par inadvertance les utilisateurs à exécuter du code interdit par les commandes proxy JEA.

JEA ne protège pas contre les administrateurs

L’un des principes fondamentaux de JEA est qu’il permet aux nonadministrateurs d’effectuer certaines tâches administratives. JEA ne protège pas contre les utilisateurs qui disposent déjà de privilèges d’administrateur. Les utilisateurs qui appartiennent aux administrateurs de domaine, aux administrateurs locaux ou à d’autres groupes hautement privilégiés peuvent contourner les protections de JEA d’une autre manière. Par exemple, ils peuvent se connecter avec RDP, utiliser des consoles MMC distantes ou se connecter à des points de terminaison PowerShell non entraînés. En outre, l’administrateur local sur un système peut modifier les configurations JEA pour ajouter d’autres utilisateurs ou modifier une fonctionnalité de rôle pour étendre l’étendue de ce qu’un utilisateur peut faire dans sa session JEA. Il est important d’évaluer les autorisations étendues de vos utilisateurs JEA pour voir s’il existe d’autres façons d’obtenir un accès privilégié au système.

Outre l’utilisation de JEA pour une maintenance quotidienne régulière, il est courant d'utiliser un système de gestion des accès privilégiés juste à temps. Ces systèmes permettent aux utilisateurs désignés de devenir temporairement un administrateur local uniquement une fois qu’ils ont terminé un workflow qui documente leur utilisation de ces autorisations.