PowerShell : Get-ExecutionPolicy et Set-ExecutionPolicy

I. Présentation

Le titre de cet article est relativement explicite : dans ce tutoriel, nous parler des commandes Get-ExecutionPolicy et Set-ExecutionPolicy. Elles permettent de récupérer et de modifier la politique d'exécution des scripts sur une machine Windows.

J'ai déjà publié un article sur les politiques d'exécution en 2012, mais je souhaitais proposer un nouvel article, plus complet. Je vais vous expliquer les différentes politiques d'exécution et la notion de scope associée.

Cet article est disponible également au format vidéo :

II. Les politiques d'exécution

Grâce à la politique d'exécution PowerShell, nous allons pouvoir contrôler sur une machine Windows, quels sont les scripts qui peuvent être exécutés en fonction de quelques critères, notamment la signature du code.

Par défaut, sur une machine Windows il n'est pas possible d'exécuter des scripts PowerShell, ce qui est une bonne nouvelle d'un point de vue sécurité. Les pirates informatiques tirent profit de la puissance de PowerShell et certains scripts sont malveillants. À l'inverse, il y a une politique d'exécution qui n'effectue aucun contrôle et permet l'exécution de tous les scripts PowerShell.

Note : que ce soit un poste client sous Windows 10 (ou autre) ou un serveur sous Windows Server, il y a cette notion de politique d'exécution.

Nous pouvons recenser 6 politiques d'exécution différentes, que voici :

• Restricted

Politique qui bloque l'intégralité des scripts PowerShell sur une machine, mais qui autorise l'utilisation de la console PowerShell ou d'un outil comme Windows Terminal pour exécuter du code en mode interactif. Néanmoins, cela signifie qu'il n'est pas possible d'exécuter directement un fichier PS1.

• AllSigned

En entreprise, il s'agit de la politique d'exécution la plus sûre d'un point de vue sécurité puisqu'elle permet d'autoriser l'exécution des scripts PowerShell, à condition que le script soit signé par un certificat à partir de l'autorité de certification de votre entreprise (ADCS).

La contrainte, c'est qu'à chaque fois qu'un script est modifié, même d'un seul caractère, il doit être signé de nouveau. Un peu plus lourd en termes d'administration, mais idéal pour la sécurité de votre SI.

? Comment signer un script PowerShell ?

• RemoteSigned

Politique d'exécution par défaut sous Windows Server depuis Windows Server 2012 R2, elle autorise l'exécution des scripts locaux, mais bloque ceux en provenance d'Internet. Comment est-ce possible de détecter si un script provient d'Internet ou non allez-vous me dire ? Il y a des flux cachés et des métadonnées qui permettent de connaître la provenance du script, ce qui permettra de déterminer s'il peut être exécuté ou non.

• Unrestricted

Cette politique autorise l'exécution de tous les scripts, que ce soit des scripts locaux ou en provenance d'Internet. Cependant, si un script provient d'Internet, un message d'avertissement s'affiche et vous devez confirmer que vous souhaitez qu'il soit exécuté.

• Bypass

Il s'agit du mode "open bar" : il n'y a aucun contrôle, et tous les scripts, peu importe la provenance, seront exécutés sur la machine. A éviter en production.

• Undefined

Ce mode signifie "non défini" et donc c'est la politique par défaut qui va s'appliquer, ou celle du scope de niveau supérieur. Vous comprendrez mieux cette notion de scope et la politique Undefined en poursuivant la lecture de cet article.

III. Les étendues des stratégies d'exécution

Il y a plusieurs étendues PowerShell au niveau d'un hôte Windows, et chaque étendue dispose de sa propre politique d'exécution. Nous retrouvons trois étendues principales :

• Process

La stratégie d'exécution définie sur le scope "Process" s'appliquera uniquement au niveau de la console PowerShell courante. Par exemple, cela signifie qu'un script pourra être lancé à partir de cette console si elle utilise la stratégie "Unrestricted", mais si au niveau du système la politique est "Restricted", ce même script ne pourra pas être exécuté directement via l'hôte Windows.

La politique liée au processus PowerShell en cours d'exécution est stockée temporairement en mémoire.

• CurrentUser

La stratégie définie au niveau du scope "CurrentUser" s'applique uniquement au niveau de la session Windows ouverte sur le poste. Si un autre utilisateur ouvre une session, il aura potentiellement une politique différente qui s'applique sur son compte.

La valeur est permanente et elle est stockée dans le registre (HKEY_CURRENT_USER).

• LocalMachine

Cette politique définie pour la machine locale, elle affecte tous les utilisateurs de la machine. C'est la politique de plus haut niveau. En fait, si la politique du scope "CurrentUser" n'est pas définie elle sera sur Undefined donc l'utilisateur va hériter de la politique définie sur le scope "LocalMachine".

La valeur est permanente et stockée dans le registre également (HKEY_CURRENT_MACHINE).

En complément de ces trois scopes, nous retrouvons deux scopes supplémentaires qui correspondent aux stratégies de groupe. En effet, la politique d'exécution peut être forcée sur les postes, au niveau du scope LocalMachine (ordinateur) et CurrentUser (utilisateur) grâce à une GPO. Cela correspond aux scopes MachinePolicy et UserPolicy.

IV. Get-ExecutionPolicy

Passons maintenant à la pratique et l'utilisation du premier cmdlet : Get-ExecutionPolicy. Cette commande permet d'obtenir la politique d'exécution appliquée sur la machine :

Get-ExecutionPolicy

Si l'on veut obtenir plus de détails et notamment la politique d'exécution appliquée sur chaque scope, il faudra ajouter le paramètre -List à la commande, comme ceci :

Get-ExecutionPolicy -List

Ce qui donne un résultat explicite :

V. Set-ExecutionPolicy

Maintenant que l'on sait comment obtenir la politique d'exécution appliquée sur la machine et les différents scopes, voyons comment la modifier... Le cmdlet Set-ExecutionPolicy doit être utilisée pour ça.

Pour définir une politique d'exécution au niveau de la machine (LocalMachine), il faudra exécuter cette commande :

Set-ExecutionPolicy -ExecutionPolicy AllSigned

Dans la commande ci-dessus, on va basculer sur la politique AllSigned. Validez avec "T" lors de l'exécution de cette commande.

Si l'on veut modifier la politique d'exécution pour un scope précis, par exemple "CurrentUser", il faut le préciser comme ceci :

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser

Il est à noter que s'il y a une politique définie au niveau "CurrentUser" et une autre au niveau "LocalMachine", c'est celle sur le scope CurrentUser qui va s'appliquer.

Sachez également que si vous souhaitez ouvrir une console avec une politique d'exécution spécifique uniquement pour une fois, sans modifier les paramètres du système, c'est possible ! Il faut le spécifier à la suite de powershell.exe, comme ceci (exemple avec Bypass) :

powershell -ExecutionPolicy Bypass

Pour terminer cet article, sachez que si vous récupérez un script depuis Internet, il est possible de "l'approuver" afin de permettre son exécution. Pour cela, vous devez utiliser le cmdlet Unblock-File et indiquer le nom du fichier .ps1 à déverrouiller. Par exemple :

Unblock-File "C:\TEMP\mon-script.ps1"

Cela correspond à cette option dans les propriétés d'un fichier :

Le mot de la fin : en entreprise, je vous recommande fortement d'utiliser la politique d'exécution AllSigned ou à minima RemoteSigned, mais en aucun cas vous ne devez déployer la politique Unrestricted ou Bypass sur vos postes et vos serveurs.