Accès à distance sécurisé PowerShell avec Just-Enough-Administration (JEA)

L'utilisation de la communication à distance PowerShell est devenue quasiment indispensable dans tous les environnements. Windows Moderne, certes, mais accorder un accès à distance sans contrôle revient à laisser les clés du centre de données sur la table. C'est là que le jeu entre en jeu. Administration juste suffisante (JEA), une couche de sécurité qui vous permet de déléguer des tâches sans distribuer des droits d'administrateur à tout-va.

Avec JEA, vous pouvez configurer des points d'accès distants très limités où seuls certains utilisateurs exécutent le commandes que vous avez autorisés, sous des comptes disposant de privilèges plus étendus, mais sans connaître les véritables qualifications ni pouvoir s'écarter du scénarioEt tout cela a été consigné dans des transcriptions et journaux des informations détaillées qui vous permettent ensuite de vérifier qui a fait quoi, quand et d'où.

Qu’est-ce que l’administration juste suffisante (JEA) et pourquoi est-ce important ?

Just-Enough-Administration est une technologie de sécurité basée sur PowerShell JEA met en œuvre un modèle d'administration déléguée avec le minimum de privilèges requis. Concrètement, il permet d'exposer des points de terminaison distants où seul un ensemble restreint d'applets de commande, de fonctions, de scripts et de commandes externes, définis par vos soins, est accessible.

Grâce à cette approche, vous pouvez réduire drastiquement le nombre de comptes disposant de privilèges élevés Sur vos serveurs, vous pouvez utiliser des comptes virtuels ou des comptes de service gérés par groupe (gMSA) qui exécutent des actions privilégiées pour le compte d'utilisateurs standard. L'utilisateur se connecte avec ses identifiants habituels et, via la session JEA, lance des commandes qui sont exécutées en arrière-plan avec des privilèges élevés.

Un autre pilier essentiel de JEA est sa capacité à définir précisément ce que chaque rôle peut faireLes fichiers de capacités de rôle définissent les cmdlets, fonctions personnalisées, commandes externes ou fournisseurs PowerShell visibles. Le reste est inaccessible à l'utilisateur : il ne peut ni créer de scripts, ni naviguer librement dans le système de fichiers, ni accéder aux services ou processus non spécifiés.

De plus, toutes les sessions JEA peuvent être configurées pour générer transcriptions complètes et événements d'auditLa capture des commandes, des paramètres, des résultats, des erreurs, de l'identité de l'utilisateur et des temps d'exécution permet non seulement de répondre aux exigences réglementaires, mais s'avère également précieuse lors d'une enquête sur un incident de sécurité ou une défaillance opérationnelle.

Risques liés aux comptes privilégiés et comment JEA les atténue

Les comptes d'administrateur local, de domaine ou d'application disposant de permissions élevées impliquent l'un des vecteurs de risque les plus sérieux dans toute organisationSi un attaquant obtient l'un de ces identifiants, il peut se déplacer latéralement dans le réseau, élever ses privilèges et accéder à des données critiques, à des services clés, voire même paralyser des systèmes entiers.

Supprimer des privilèges n'est pas toujours chose aisée. Un exemple classique en est celui de un serveur hébergeant à la fois un serveur DNS et un contrôleur de domaine Active DirectoryL'équipe DNS a besoin de privilèges d'administrateur local pour résoudre les problèmes de service DNS, mais son ajout au groupe Administrateurs du domaine lui confère de fait le contrôle de toute la forêt et l'accès à toutes les ressources de la machine. C'est un exemple typique de compromis entre sécurité et facilité d'utilisation.

JEA résout ce dilemme en appliquant strictement la principe du moindre privilègeAu lieu de faire des administrateurs DNS des administrateurs de domaine, vous pouvez créer un point de terminaison JEA DNS dédié qui expose uniquement les cmdlets nécessaires pour vider le cache, redémarrer le service, consulter les journaux ou effectuer des tâches similaires. L'opérateur peut ainsi travailler sans avoir à examiner Active Directory, parcourir le système de fichiers, exécuter des scripts aléatoires ou des utilitaires potentiellement dangereux.

Lorsque vous configurez les sessions JEA pour utiliser comptes virtuels avec des autorisations temporairesCette initiative est encore plus intéressante : l’utilisateur se connecte avec des identifiants non privilégiés et peut, depuis cette session, exécuter des tâches qui requièrent normalement des droits d’administrateur. Cela permet de retirer de nombreux utilisateurs des groupes d’administrateurs locaux ou de domaine, assurant ainsi la continuité des opérations tout en renforçant considérablement la sécurité du système.

Concepts de sécurité qui sous-tendent JEA

JEA n'est pas apparue de nulle part : Elle repose sur plusieurs principes et modèles de sécurité bien établis. qui lui confèrent cohérence et robustesse. Le premier est le principe du moindre privilège, mentionné précédemment, qui stipule que les utilisateurs et les processus ne doivent disposer que des permissions essentielles à leurs fonctions.

Le deuxième pilier majeur est le modèle de Contrôle d'accès basé sur les rôles (RBAC)JEA implémente le contrôle d'accès basé sur les rôles (RBAC) via des fichiers de capacités de rôle, où vous définissez les actions autorisées pour un rôle spécifique au sein d'une session distante. Par exemple, un rôle d'assistance technique peut lister les services, consulter les événements et redémarrer un service spécifique, tandis qu'un rôle d'administrateur SQL Server ne peut exécuter que les cmdlets liées à… bases de données et un peu plus.

La La base technique de JEA repose sur PowerShell et son infrastructure de communication à distance.PowerShell fournit le langage, les cmdlets et la couche de communication à distance (WinRM/WS-Management), et JEA ajoute par-dessus un système de points de terminaison restreints, de comptes virtuels et un contrôle précis des commandes disponibles.

Un autre concept important est le administration restreinte, semblable à un Accès attribué en mode kiosque Windows 11Au lieu de fournir un accès complet à un opérateur, JEA crée une session où le langage de script est restreint (par défaut, NoLanguage), la création de nouvelles fonctions ou variables est bloquée, les boucles et les instructions conditionnelles sont interdites, et seules les cmdlets approuvées peuvent être exécutées. Cela limite considérablement les capacités d'un attaquant qui parviendrait à accéder à cette session.

Composants clés : fichiers .psrc et .pssc

Au cœur de tout déploiement JEA se trouvent deux types de fichiers : fichiers de capacités de rôle (.psrc) et fichiers de configuration de session (.pssc)Ensemble, ils transforment une interface générique en un terminal parfaitement adapté à des utilisateurs spécifiques.

Dans un fichier de capacités de rôle, vous définissez Quelles commandes sont exactement disponibles pour ce rôle ?Parmi les éléments les plus importants figurent :

• Cmdlets visibles: liste des cmdlets autorisées, avec possibilité de restreindre les paramètres.
• Fonctions visibles: fonctions personnalisées chargées dans la session.
• Commandes externes visibles: fichiers exécutables externes spécifiques auxquels on accède.
• Fournisseurs visibles: Les fournisseurs PowerShell (par exemple, FileSystem ou Registry) visibles dans la session.

Les fichiers de configuration de session .pssc, en revanche, Ils décrivent le point de terminaison JEA comme tel et le relient aux rôles.Des éléments tels que les suivants sont déclarés ici :

• Définitions des rôles: associer les utilisateurs ou les groupes de sécurité aux capacités des rôles.
• Type de session: où 'RestrictedRemoteServer' est généralement configuré pour renforcer la sécurité de la session.
• Répertoire des transcriptions: dossier où sont stockées les transcriptions de chaque session.
• Exécuter en tant que compte virtuel et les options connexes, comme par exemple l'ajout du compte virtuel à des groupes spécifiques.

JEA se matérialise sous la forme de Points de terminaison de communication à distance PowerShell enregistrés dans le systèmeCes points de terminaison sont créés et activés à l'aide d'applets de commande telles que : Nouveau fichier de configuration de session PS, Enregistrement – ​​Configuration de session PS ou des outils graphiques comme JEA Helper Tool, qui facilite la génération de fichiers .pssc et .psrc sans avoir à se débattre avec la syntaxe.

cycle de vie d'une session JEA

Lors de la mise en place d'un environnement JEA complet, le processus suit généralement une série d'étapes logiques qui Ils transforment un système de contrôle à distance ouvert en un système strictement réglementé.La séquence typique est la suivante :

Tout d'abord, vous créez un groupe de sécurité ou plusieurs groupes Ces groupes représentent les rôles que vous souhaitez déléguer (par exemple, HelpdeskDNS, Opérateurs Web, Opérateurs SQL). Leur utilisation n'est pas obligatoire, mais elle simplifie considérablement l'administration à mesure que l'environnement s'agrandit.

Ensuite, un ou plusieurs sont préparés fichiers de capacités de rôle .psrc Cette liste répertorie les actions autorisées : cmdlets, fonctions, scripts, commandes externes, alias, fournisseurs et restrictions supplémentaires (paramètres spécifiques, chemins autorisés, etc.). Par exemple, vous pouvez autoriser toutes les cmdlets commençant par Get-, limiter Restart-Service au service Spooler et autoriser uniquement le fournisseur FileSystem.

Le résultat suivant est généré fichier de configuration de session .pssc à l'aide de New-PSSessionConfigurationFile. Il définit des options telles que SessionType = RestrictedRemoteServer, le chemin TranscriptDirectory, l'utilisation ou non de comptes virtuels et le bloc RoleDefinitions qui associe les groupes aux capacités de rôle, par exemple, 'DOMAIN\HelpdeskDNS' = @{ RoleCapabilities = 'HelpdeskDNSRole' }.

Le fichier .pssc étant déjà préparé, le point de terminaison est enregistré à l'aide de Enregistrer – PSSessionConfiguration -Nom Nom de la session JEASession -Chemin Chemin\Fichier.psscÀ partir de ce moment, si les configurations disponibles sont listées avec Get-PSSessionConfiguration, le nouveau point de connexion apparaîtra prêt à recevoir des connexions.

Les utilisateurs se connectent à ce point de terminaison depuis leurs ordinateurs avec Saisissez -PSSession -NomOrdinateur Serveur -NomConfiguration NomDeLaSessionJEASession ou avec New-PSSession puis Invoke-Command. Dès l'ouverture de la session, les restrictions définies dans la capacité de rôle associée à l'utilisateur sont automatiquement appliquées.

Pendant la séance, La communication à distance PowerShell utilise WinRM avec des canaux chiffrés.L'authentification intégrée (généralement Kerberos au sein du domaine) et les règles de pare-feu définies pour le service sont utilisées. Concrètement, si l'option « Exécuter en tant que compte virtuel » est activée, un compte virtuel temporaire est créé, ajouté aux groupes nécessaires, puis supprimé à la fin de la session.

Enfin, à l'issue de la clôture de la session JEA, Les transcriptions et les événements d'audit sont enregistrés. Ces journaux conservent une trace claire des commandes exécutées, des résultats obtenus et du contexte utilisateur. Ils peuvent ensuite être envoyés à un système SIEM ou y être corrélés pour générer des alertes et permettre une analyse plus approfondie.

Contrôle d'accès à distance, renforcement de la sécurité et gestion de la sécurité PowerShell

Communication à distance PowerShell, prise en charge par le service Gestion à distance Windows (WinRM) Le protocole WS-Management permet l'exécution centralisée de commandes et de scripts sur des ordinateurs distants. C'est un outil puissant pour l'automatisation, la gestion de serveurs à grande échelle, le débogage et l'assistance à distance.

Par défaut, administrateurs locaux et membres du groupe d'utilisateurs de la gestion à distance Ils peuvent utiliser les points de terminaison PowerShell standard. Dans de nombreux environnements, cette fonctionnalité a permis à des utilisateurs non administrateurs d'exécuter des tâches à distance, ce qui n'est pas dangereux en soi, mais qui, sans contrôle adéquat, ouvre la voie à des abus importants.

Pour renforcer la sécurité, une stratégie commune implique Limiter l'accès PowerShell distant aux seuls comptes administrateurs. Mieux encore, on peut combiner cette limitation avec des points de terminaison JEA qui n'accordent à certains utilisateurs que l'accès strictement nécessaire. Ceci peut être réalisé grâce à :

• Les GPO qui définissent quels groupes peuvent utiliser WinRM et les points de terminaison par défaut.
• Règles de pare-feu autorisant WinRM uniquement depuis les sous-réseaux ou les ordinateurs d'administration.
• Suppression du groupe Utilisateurs de gestion à distance des listes de contrôle d'accès (ACL) des points de terminaison standard.

De plus, vous pouvez choisir de Bloquer complètement PowerShell pour les utilisateurs non administrateurs En utilisant des solutions comme AppLocker, vous empêchez un utilisateur standard d'exécuter des scripts malveillants en local, tout en autorisant les comptes privilégiés à utiliser PowerShell pour les tâches de gestion et d'automatisation.

JEA par rapport à d'autres méthodes de restriction PowerShell

Il existe plusieurs façons de limiter ce que les utilisateurs peuvent faire avec la communication à distance PowerShell, et JEA se présente comme une option plus fine et plus flexible dans un éventail qui comprend des approches plus larges telles que :

D’une part, l’utilisation de Stratégie de groupe (GPO) pour contrôler qui accède aux points de terminaison PowerShell par défautL'accès à Microsoft PowerShell peut être limité aux administrateurs, voire désactivé pour tous, imposant ainsi l'utilisation de points de terminaison spécifiques. Cette méthode est utile pour restreindre l'accès de manière exhaustive, mais elle ne résout pas le problème de la granularité : quiconque obtient l'accès peut faire quasiment tout.

D'autre part, il existe des outils de contrôle d'applications tels que Politiques de restriction d'AppLocker ou de logicielsCes méthodes permettent d'interdire l'exécution de PowerShell.exe ou pwsh.exe aux utilisateurs standard, soit par chemin d'accès, soit par éditeur, soit par hachage. Cette approche est utile pour sécuriser les postes de travail et empêcher tout utilisateur de lancer PowerShell, mais elle présente des limitations lorsqu'il s'agit d'autoriser un utilisateur à effectuer des tâches d'administration limitées depuis son compte.

Une autre option est la Points d'extrémité contraints sans atteindre l'intégralité de JEAVous pouvez créer des configurations de session personnalisées qui restreignent les cmdlets, les fonctions et les modules, sans pour autant dépendre autant du modèle de rôles, des comptes virtuels ou du contrôle d'accès basé sur les rôles (RBAC) structuré proposé par JEA. Il s'agit d'une solution intermédiaire adaptée aux scénarios simples, mais moins évolutive dans les environnements de grande envergure.

JEA combine le meilleur de plusieurs mondes : Limitation stricte des commandes, RBAC, exécution contrôlée de privilèges élevés et journalisation complèteCela en fait la solution recommandée lorsque vous devez activer l'accès à distance PowerShell pour les non-administrateurs, sans pour autant leur fournir un environnement de gestion complet.

Fonctionnalités avancées : exécuter en tant qu’autre compte et se connecter

L'une des capacités les plus puissantes de JEA est la Exécuter des commandes en tant qu'autre compte, plus privilégié, sans exposer vos identifiants.Cela résout le problème classique du « Je vais te donner le mot de passe de ce service pour que tu puisses faire X », mot de passe qui n'est ensuite jamais changé et qui finit par représenter un risque énorme.

Les scénarios de domaine sont couramment utilisés Comptes de services gérés par groupe (gMSA) Cela permet aux terminaux JEA d'exécuter des actions sous une identité de service gérée de manière centralisée, avec rotation automatique des mots de passe et sans qu'aucun opérateur ne connaisse jamais le secret. Dans d'autres cas, des comptes virtuels temporaires locaux à la machine sont utilisés, créés ad hoc lors de la connexion d'un utilisateur et supprimés à la fin de la session.

Du point de vue de l'audit, chaque session JEA peut être configurée pour générer à la fois des transcriptions PowerShell et des entrées de journal d'événements enrichiesLes informations généralement collectées comprennent :

• Historique complet des commandes et paramètres saisis.
• Sortie générée et messages d'erreur.
• Horodatage du début et de la fin de la session, ainsi que sa durée.
• Identité de l'utilisateur connecté et rôle/fonction attribué.

Si vous combinez ces traces avec les fonctionnalités de Journalisation et module PowerShell scénario Bloquer la journalisation via GPOEn envoyant les journaux à un SIEM, vous obtenez une visibilité complète sur l'activité de vos terminaux de gestion. Ceci est essentiel pour la conformité (audits SOX, ISO 27001, etc.) ainsi que pour la détection et la réponse aux incidents.

Cas d'utilisation typiques de JEA dans des environnements réels

JEA brille particulièrement lorsque vous en avez besoin. Déléguer des tâches très spécifiques à des équipes qui ne devraient pas être administrateurs.Voici quelques exemples très courants en pratique :

Dans le domaine du support technique, vous pouvez faire appel à des techniciens de haut niveau. Accès JEA pour redémarrer les services, consulter les journaux d'événements et vérifier l'état des processus sur les serveurs, mais sans possibilité d'installer de logiciels, de modifier les configurations critiques ni d'accéder à Active Directory. Un rôle typique d'assistance technique peut inclure des cmdlets telles que Get-Service, Restart-Service pour des services spécifiques, Get-EventLog en mode lecture seule et certaines cmdlets de diagnostic réseau.

Au sein des équipes d'exploitation ou de développement, vous pouvez configurer des rôles axés sur des tâches spécifiques telles que l'administration IIS ou la maintenance de sites webPar exemple, autoriser l'accès aux cmdlets de gestion du pool d'applications, aux redémarrages de sites web, à l'interrogation des journaux d'un répertoire limité et à la gestion des certificats pour des services spécifiques, tout en excluant toute possibilité de redémarrer l'ensemble du serveur ou de modifier les politiques de sécurité.

Dans les environnements hybrides et cloud, JEA est fréquemment utilisé pour limiter ce que chaque équipe peut faire concernant Machines virtuelles, stockage ou réseauxVous pouvez exposer des points de terminaison qui vous permettent de gérer uniquement les machines virtuelles d'un département, de modifier les règles de pare-feu d'un segment spécifique ou de gérer un ensemble spécifique de comptes de service, en maintenant l'accès séparé du reste de l'infrastructure.

Parallèlement, JEA s'intègre parfaitement avec Stratégies de gestion des accès privilégiés (PAM)où les sessions privilégiées sont accordées temporairement, enregistrées et attribuées à des identités personnelles, évitant ainsi les comptes partagés et minimisant le risque associé à chaque action privilégiée.

Article connexe:

Comment limiter l'accès aux dossiers partagés sous Windows étape par étape

Isaac

Écrivain passionné par le monde des octets et de la technologie en général. J'aime partager mes connaissances à travers l'écriture, et c'est ce que je vais faire dans ce blog, vous montrer toutes les choses les plus intéressantes sur les gadgets, les logiciels, le matériel, les tendances technologiques et plus encore. Mon objectif est de vous aider à naviguer dans le monde numérique de manière simple et divertissante.