La stratégie d’exécution des scripts PowerShell

I. Présentation

À quoi sert la stratégie d'exécution des scripts PowerShell ? Quel mode choisir ? Nous allons évoquer ce sujet important et manipuler deux cmdlets : Get-ExecutionPolicy et Set-ExecutionPolicy. Le premier cmdlet sert à visualiser la stratégie d'exécution actuelle tandis que le second cmdlet permet de modifier la configuration.

II. À quoi sert la stratégie d'exécution des scripts PowerShell ?

La stratégie d'exécution PowerShell est une fonctionnalité qui vous permet d'éviter que du code PowerShell soit exécuté par accident sur votre ordinateur Windows. Cela signifie que la stratégie d'exécution ne vous protège pas contre les attaquants qui souhaitent volontairement exécuter du code sur votre machine. Autrement dit, elle va permettre d'éviter qu'un utilisateur puisse exécuter un script PowerShell par erreur, que ce dernier soit malveillant ou non.

En fonction de la politique choisie, cette stratégie d'exécution est plus ou moins stricte, ce qui signifie que certains scripts pourront être exécutés, tandis que d'autres ne pourront pas l'être. Par exemple, nous pouvons bloquer les scripts PowerShell téléchargés depuis Internet, mais autoriser les scripts locaux.

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.

III. Les différentes stratégies d'exécution

PowerShell prend en charge six modes différents pour la stratégie d'exécution de scripts.

• 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 à partir de la console. Néanmoins, cela signifie qu'il n'est pas possible d'exécuter directement un fichier PS1. Il s'agit de la valeur par défaut sur les systèmes d'exploitation Windows (Windows 10, Windows 11).

• AllSigned

Pour l'entreprise et la production, il s'agit de la politique d'exécution la plus sûre, car elle autorise uniquement l'exécution des scripts PowerShell signés par un certificat de signature de code. Ce certificat doit être connu de la machine locale, qu'il soit émis à partir de l'autorité de certification de votre entreprise (ADCS, par exemple) ou auto-signé.

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 par l'administrateur système. Si un script PowerShell a été signé par l'administrateur système, nous pouvons considérer que son code a été validé et vérifié.

Dans un prochain chapitre, nous verrons comment signer un script PowerShell à partir d'un certificat auto-signé. Vous pouvez également vous référer à l'article ci-dessous pour effectuer cette opération avec un certificat obtenu auprès d'une autorité de certification Active Directory.

- 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 PowerShell locaux, mais bloque ceux en provenance d'Internet. Comment est-ce possible de détecter si un script provient d'Internet ou non ? 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 (ceci fait référence à la Mark of the Web).

• Unrestricted

Cette politique autorise l'exécution de tous les scripts PöwerShell, 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. À éviter en production, car un utilisateur pourra exécuter n'importe quel script PowerShell en quelques clics.

• Undefined

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

IV. 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, c'est-à-dire la session en cours. 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 Windows (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. Sachez que si la politique du scope "CurrentUser" n'est pas définie, elle sera sur l'état "Undefined" donc l'utilisateur va hériter de la politique définie sur l'étendue "LocalMachine".

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

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

V. 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 nous souhaitons obtenir plus de détails et notamment la politique d'exécution appliquée sur chaque étendue, nous devons ajouter le paramètre "-List" à la commande, comme ceci :

Get-ExecutionPolicy -List

Ce qui donne un résultat explicite :

VI. Set-ExecutionPolicy

Nous venons de voir comment visualiser la stratégie d'exécution des scripts PowerShell appliquée sur une machine, notamment au niveau des différentes étendues. Désormais, nous allons apprendre à modifier cette politique à l'aide du cmdlet "Set-ExecutionPolicy".

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

Set-ExecutionPolicy -ExecutionPolicy AllSigned

Grâce à la commande indiquée ci-dessus, nous allons configurer la politique sur "AllSigned". Validez avec "T" lors de l'exécution de cette commande.

Si nous voulons modifier la politique d'exécution pour une étendue précise, par exemple, celui nommé "CurrentUser", nous devons ajouter le paramètre "-Scope" à la commande. Voici un exemple :

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser

Nous pouvons exécuter de nouveau le cmdlet Get-ExecutionPolicy pour vérifier que notre configuration a été prise en compte.

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.

VII. Contourner la stratégie d'exécution PowerShell

Comme je l'évoquais en introduction, la stratégie d'exécution permet de lutter contre l'exécution accidentelle de scripts PowerShell. Nous pouvons la contourner très facilement, notamment en jouant sur l'étendue "Process".

Nous allons prendre une machine sous Windows 11, avec la stratégie d'exécution par défaut : Restricted, et essayer d'exécuter le script "script.ps1" qui affiche simplement un message dans la console. Voici son code :

Write-Output "Script PowerShell - IT-Connect"

Si nous tentons d'exécuter le script PowerShell nommé "script.ps1", nous obtenons une erreur, car l'exécution de scripts n'est pas autorisée.

script.ps1

Voici le résultat obtenu :

Désormais, à partir de cette même console PowerShell, nous allons ouvrir une autre console PowerShell en spécifiant une stratégie d'exécution particulière. Ceci va altérer la politique appliquée sur l'étendue "Process", uniquement le temps de la session PowerShell, et nous permettre d'exécuter n'importe quel script.

La commande suivante permet de lancer une console PowerShell avec la stratégie d'exécution "Bypass" :

powershell.exe -ExecutionPolicy Bypass

Puis, nous allons exécuter notre script une nouvelle fois. Cette fois-ci, nous pouvons voir que le script a été exécuté puisqu'il a retourné un message dans la console. De plus, nous pouvons voir que la politique d'exécution sur l'étendue "Process" est définie sur "Bypass" !

Sans même avoir besoin d'ouvrir une console PowerShell interactive, nous pourrions exécuter notre script de cette façon :

powershell.exe -ExecutionPolicy Bypass -File .\script.ps1

Par ailleurs, nous pourrions ruser en récupérant le contenu du fichier de script avec le cmdlet "Get-Content" et l'exécuter avec le cmdlet "Invoke-Expression", grâce à l'utilisation du pipeline. Ceci revient en quelque sorte à faire un copier-coller du contenu du script dans la console PowerShell afin de l'exécuter : la stratégie d'exécution ne restreint pas l'exécution de code via la console, mais uniquement les fichiers de scripts.

Get-Content ".\script.ps1" | Invoke-Expression

Nous pouvons voir que cela fonctionne :

Bien que la stratégie d'exécution PowerShell soit une fonction de sécurité, ce test prouve qu'elle a bien pour objectif d'empêcher l'exécution accidentelle de script. Si quelqu'un souhaite réellement exécuter un script, il pourra le faire, à moins d'aller beaucoup plus loin dans la configuration de la machine (jusqu'à bloquer PowerShell, par exemple).

VIII. Débloquer un script PowerShell

Si nous récupérons un script PowerShell depuis Internet, il est possible de "l'approuver" afin de permettre son exécution. Pour cela, nous devons utiliser le cmdlet "Unblock-File" et indiquer le nom du fichier .ps1 à déverrouiller. Par exemple :

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

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

IX. Conclusion

La stratégie d'exécution PowerShell, bien que contournable, est importante et ne doit pas être configurée n'importe comment. En entreprise, priorisez l'utilisation de la politique d'exécution AllSigned ou à minima RemoteSigned, mais en aucun cas, vous ne devez utiliser la politique Bypass sur vos postes de travail et vos serveurs. Sur votre poste de travail personnel, conservez Restricted si vous n'utilisez pas PowerShell, sinon vous pouvez utiliser RemoteSigned.

Enfin, il est important de noter que Windows PowerShell et PowerShell ont chacun une stratégie d'exécution des scripts, mais qu'elle peut être différente, car ces deux versions sont indépendantes. Pour déployer une configuration homogène, je vous recommande d'utiliser une stratégie de groupe (GPO) :

• Configurer la stratégie d'exécution de PowerShell 7 par GPO

---