Avez-vous déjà téléchargé un script PowerShell, l’avez exécuté, et rencontré le message d’erreur infâme ci-dessous? Si c’est le cas, vous avez besoin de la cmdlet Set-ExecutionPolicy et de ce tutoriel !
Dans ce post, vous allez apprendre sur les politiques d’exécution PowerShell et comment les gérer avec la cmdlet Set-ExecutionPolicy. À la fin de ce post, vous saurez non seulement exécuter des scripts, mais aussi comment utiliser les politiques d’exécution !
Ce tutoriel a été écrit en gardant à l’esprit Windows PowerShell, et toutes les démonstrations ont été effectuées avec Windows PowerShell. Les politiques d’exécution ne sont pas propres à Windows PowerShell, et elles fonctionnent de manière très similaire dans PowerShell 6+. Mais, si vous travaillez avec PowerShell 6+, vous pouvez trouver de petites différences de comportement.
What est une Politique d’Exécution?
Si vous avez déjà rencontré l’erreur décrite ci-dessus, vous avez rencontré une politique d’exécution. Les politiques d’exécution PowerShell sont un mécanisme de sécurité pour protéger votre système contre l’exécution de scripts malveillants. Les politiques d’exécution ne vous empêchent pas d’exécuter du code PowerShell dans la console en tant que shell mais l’exécution de scripts.
Microsoft dit qu’une politique d’exécution n’est pas techniquement une mesure « sécuritaire » mais plutôt une porte que vous pouvez ouvrir et fermer. Après tout, vous pouvez contourner facilement une politique d’exécution définie, comme vous le verrez plus tard.
Les politiques d’exécution sont basées sur la confiance. Si vous faites confiance à un script, il y a de fortes chances qu’il ne soit pas malveillant. Les politiques d’exécution ne préviennent généralement pas l’exécution de tous les scripts. Leur objectif principal (surtout lorsqu’elles sont configurées de manière plus stricte) est de s’assurer que vous faites confiance au script que vous exécutez signé de manière cryptographique avec un certificat.
Étendues des politiques d’exécution
Comme vous l’avez appris, les politiques d’exécution restreignent l’exécution des scripts, mais PowerShell peut exécuter des scripts dans de nombreux contextes différents. PowerShell exécute des scripts dans le contexte de l’utilisateur connecté ou dans le contexte machine global, via des tâches planifiées s’exécutant en tant que SYSTEM ou dans le cadre d’une seule console PowerShell ouverte.
Pour accommoder tous ces contextes, PowerShell propose cinq contextes ou étendues différentes que vous pouvez définir pour une politique d’exécution.
- MachinePolicy – Cette étendue est limitée à un seul ordinateur. Elle affecte tous les utilisateurs qui se connectent à cet ordinateur, et un objet de stratégie de groupe Active Directory la définit. Lorsqu’elle est définie, elle a priorité sur toutes les autres étendues.
- LocalMachine. Ceci est la portée par défaut qui affecte tous les utilisateurs de l’ordinateur et qui est stockée dans la sous-clé de registre HKEY_LOCAL_MACHINE. Lorsque vous définissez une stratégie d’exécution à l’aide de
Set-ExecutionPolicy, cette portée est la valeur par défaut.
La stratégie d’exécution pour LocalMachine est stockée dans la clé de registre HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PowerShell\1\ShellIds\Microsoft.PowerShell.
- UserPolicy – La portée UserPolicy affecte uniquement un seul utilisateur sur un ordinateur, et un objet de stratégie de groupe Active Directory la définit. Vous ne pouvez pas modifier cette stratégie avec
Set-ExecutionPolicy. - CurrentUser. La portée CurrentUser définit la stratégie d’exécution uniquement pour l’utilisateur actuel et est stockée sous la ruche de registre HKEY_CURRENT_USER. Vous ne pouvez pas modifier cette stratégie avec
Set-ExecutionPolicy.
La stratégie d’exécution pour CurrentUser est stockée dans la clé de registre HKEY_CURRENT_USER\SOFTWARE\Microsoft\PowerShell\1\ShellIds\Microsoft.PowerShell.
- Process – Cette portée définit la stratégie d’exécution pour une seule session PowerShell pour un seul utilisateur. La portée de stratégie d’exécution Process est la plus granulaire que vous puissiez définir. Contrairement aux autres stratégies d’exécution, cette stratégie est enregistrée dans une variable d’environnement appelée
PSExecutionPolicyPreferenceplutôt que dans le registre.
Types de stratégies d’exécution
Les politiques d’exécution ont différents « niveaux de sécurité ». Ces niveaux dictent à quel point la politique d’exécution est stricte. Par exemple, vous pouvez avoir une politique d’exécution en place qui ne fait essentiellement rien ; elle est désactivée, mais, d’un autre côté, une politique d’exécution peut désactiver complètement l’exécution de script.
Couvrons chacune des façons dont vous pouvez configurer le niveau de sécurité d’une politique d’exécution, du moins restrictif au plus restrictif.
Non restreint
La politique la moins restrictive est celle qui n’a aucun effet ; c’est Non restreint. Les politiques d’exécution Non restreintes sont essentiellement désactivées. Les utilisateurs peuvent exécuter tous les scripts, quel que soit le niveau de confiance, lorsque la politique d’exécution est Non restreinte.
Contournement
Comme le type Non restreint, une politique d’exécution définie sur Contournement, ne bloque rien.
Bien que le Contournement et le Non restreint aient un effet similaire, le type de politique d’exécution Contournement n’est pas techniquement un type du tout. Il ignore complètement une politique d’exécution définie.
Indéfini
Bien que peu utilisé, vous pouvez essentiellement supprimer une politique d’exécution en la définissant sur Indéfini. Lorsque vous définissez une politique d’exécution sur Indéfini, PowerShell supprime complètement toutes les politiques d’exécution attribuées de la portée attribuée.
Sur les ordinateurs non-Windows, la politique d’exécution est toujours définie sur Non restreinte et ne peut pas être modifiée.
Lorsque toutes les portées sont définies sur Indéfini, PowerShell traite essentiellement toutes les portées comme Restreintes.
Signé à distance
Comme vous l’avez lu précédemment, les stratégies d’exécution concernent la confiance acquise grâce à une signature numérique des scripts. PowerShell prend également en compte la provenance de ce script. A-t-il été créé sur votre ordinateur local ou par une personne aléatoire sur Internet ?
Les scripts créés ailleurs que sur votre ordinateur local ne doivent pas être intrinsèquement fiables. C’est pourquoi PowerShell propose la stratégie d’exécution RemoteSigned. La stratégie d’exécution RemoteSigned impose que tous les scripts écrits ailleurs que sur votre ordinateur local soient signés de manière cryptographique.
Vous pouvez outrepasser cette stratégie d’exécution dans une certaine mesure pour les fichiers téléchargés depuis Internet à l’aide de la
cmdletUnblock-File. Vous trouverez plus d’informations sur ce comportement un peu plus loin dans la section Comment fonctionne la stratégie RemoteSigned.
Pour Windows Server, la stratégie par défaut est RemoteSigned.
AllSigned
Si vous souhaitez vous assurer que tous les scripts PowerShell sont signés de manière cryptographique, définissez la stratégie d’exécution sur AllSigned. Comme pour la stratégie RemoteSigned, cette stratégie d’exécution va plus loin en imposant que tous les scripts soient signés avant d’être exécutés.
Même si vous avez défini la stratégie d’exécution AllSigned, vous pouvez toujours contourner la stratégie d’exécution en la contournant, comme vous le découvrirez plus tard.
Restricted
La politique d’exécution la plus restrictive est Restreinte. Lorsqu’une politique d’exécution est Restreinte, aucun script ne peut être exécuté, qu’il soit de confiance ou non. Cette politique désactive essentiellement complètement l’exécution de scripts.
De plus, contrairement aux types moins restrictifs, le type Restreinte garantit que les fichiers de formatage PowerShell et de configuration (PS1XML), les fichiers de script de module (PSM1) et les profils PowerShell ne peuvent pas être exécutés.
Tous les clients Windows sont, par défaut, configurés avec une politique d’exécution Restreinte.
Techniquement, Microsoft définit une septième politique d’exécution appelée Par défaut, mais le type est essentiellement un autre label pour RemoteSigned (Serveur Windows) et Restreint (Clients Windows).
Fonctionnement de la politique RemoteSigned
Un scénario particulier à souligner est le fonctionnement de la politique d’exécution RemoteSigned. Cette politique d’exécution (comme vous l’avez appris) empêche l’exécution de scripts qui ont été créés ailleurs que sur votre ordinateur local.
Mais comment PowerShell sait-il que le script a été créé ailleurs ? Par le biais des flux de données.
Compréhension et interrogation des flux de données NTFS
Lorsque vous créez un fichier sur un système de fichiers NTFS, NTFS applique un attribut de flux de données alternatif (ADS) au fichier. Un ADS a deux attributs de fichier : $Data et zone.Identifier. PowerShell utilise l’attribut zone.Identifier pour identifier si un fichier de script PowerShell a été créé ailleurs.
Contrairement à d’autres attributs comme Compressé ou Lecture seule, les attributs ADS sont cachés dans l’Explorateur de fichiers. Cependant, en utilisant PowerShell, vous pouvez inspecter ces flux de données.
Exécutez la commande Get-Item en utilisant le chemin vers le script et le paramètre Stream comme indiqué ci-dessous. Dans cet exemple, Hello World.ps1 a été écrit sur l’ordinateur local. Remarquez que le seul attribut attribué à la propriété Stream est $DATA. Il n’y a aucun attribut ADS.
Maintenant, exécutez la même commande sur un script téléchargé depuis Internet. Remarquez maintenant que Get-Item renvoie un autre objet complètement avec un Stream de Zone.Identifier.
Une fois que vous savez qu’un fichier a un ADS, vous pouvez alors utiliser la commande Get-Content pour découvrir la zone. La zone définit d’où vient le fichier.
Get-Content renverra une valeur ZoneId qui représente la zone d’origine du fichier.
Les valeurs possibles de zone sont:
Précédence de la stratégie d’exécution
Comme mentionné précédemment, de nombreuses stratégies d’exécution différentes existent simultanément. Toutes ces stratégies d’exécution, lorsqu’elles sont combinées, dictent les paramètres de votre session actuelle. Lorsque vous avez plusieurs stratégies d’exécution en cours, vous devez avoir une préférence.
La préférence de la stratégie est l’ordre dans lequel PowerShell applique différentes stratégies définies à différentes étendues. Certaines stratégies d’exécution ont une priorité plus élevée que d’autres.
Lorsque vous exécutez Get-ExecutionPolicy -List, vous trouverez toutes les stratégies d’exécution actuellement en vigueur, classées par ordre de priorité croissante. Par exemple, puisque MachinePolicy a une priorité plus faible, les stratégies LocalMachine et CurrentUser auront la priorité sur celle-ci.
Travailler avec les stratégies d’exécution
Après avoir compris le contexte des stratégies d’exécution, voyons maintenant comment travailler avec elles ! Pour travailler avec les stratégies d’exécution de PowerShell, vous disposez de deux commandes à votre disposition : Get-ExecutionPolicy pour découvrir les stratégies actuellement définies et Set-ExecutionPolicy pour définir de nouvelles stratégies.
Obtention des stratégies actuellement assignées
Avant de pouvoir commencer à modifier les stratégies d’exécution, vous devez savoir avec quoi vous travaillez. Pour cela, vous disposez de la commande Get-ExecutionPolicy. Cette commande énumère toutes les stratégies actuellement assignées sur un ordinateur.
Lorsque vous exécutez directement la commande Get-ExecutionPolicy dans une console PowerShell sans paramètres, elle affiche la stratégie d’exécution définie pour votre session PowerShell actuelle.
Pour voir la stratégie d’exécution définie pour une étendue, spécifiez le paramètre Scope en utilisant le nom de l’étendue pour laquelle vous souhaitez voir les résultats.
Pour afficher toutes les étendues et leurs stratégies d’exécution, utilisez le paramètre List comme indiqué ci-dessous.
Modification des stratégies d’exécution
Une fois que vous savez quelles politiques d’exécution sont actuellement attribuées, vous pouvez également les modifier. Pour modifier la politique sur un seul ordinateur, vous avez la commande Set-ExecutionPolicy à votre disposition. Mais, si vous êtes dans une organisation, vous voudrez modifier les politiques en masse. Si tel est le cas, vous avez toujours la stratégie de groupe si vous êtes dans un domaine Active Directory.
Utilisation de Set-ExecutionPolicy
Commençons par expliquer comment modifier les politiques avec la commande Set-ExecutionPolicy. Pour ce faire, ouvrez PowerShell en tant qu’administrateur.
Exécutez ensuite la commande Set-ExecutionPolicy avec un seul paramètre (ExecutionPolicy) en fournissant le nom de la politique d’exécution.
PowerShell vous demandera alors si vous souhaitez modifier la politique d’exécution. Si c’est le cas, tapez Y ou A et appuyez sur Entrée.
Certaines commandes PowerShell doivent exécuter plusieurs autres tâches pour fonctionner. Si dans l’exemple ci-dessus vous entrez Y, PowerShell peut vous demander de continuer pour chaque étape. Si vous appuyez sur A, il continuera pour toutes les étapes suivantes.
Exécution de Set-ExecutionPolicy sans invites
Par défaut, lorsque vous exécutez Set-ExecutionPolicy, il vous demandera si vous souhaitez changer la stratégie d’exécution. Vous pouvez ignorer cette invite en ajoutant le paramètre Force à votre commande. L’utilisation du paramètre Force supprimera toutes les invites de confirmation.
Configuration de la stratégie d’exécution PowerShell via le Registre
Étant donné que la plupart des stratégies d’exécution sont stockées dans le registre (à l’exception de Process), vous pouvez également modifier les stratégies directement via le registre.
Pour modifier les stratégies d’exécution via le registre :
- Ouvrez l’Éditeur du Registre Windows (regedit) ou votre outil d’édition de registre préféré.
2. Accédez à la clé de registre de la portée de la stratégie d’exécution que vous souhaitez modifier.
MachineLocale – HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PowerShell\1\ShellIds\Microsoft.PowerShell
UtilisateurActuel – HKEY_CURRENT_USER\SOFTWARE\Microsoft\PowerShell\1\ShellIds\Microsoft.PowerShell
3. Cliquez avec le bouton droit sur la clé de registre et créez une nouvelle valeur de chaîne appelée ExecutionPolicy.
4. Double-cliquez sur la nouvelle valeur de chaîne ExecutionPolicy créée et saisissez le nom de la stratégie d’exécution souhaitée (Restreint, RemoteSigned, AllSigned, NonRestreint, ou Indéfini).
5. Créez une autre valeur de chaîne à la même clé appelée Path. La valeur de chaîne Path représente le chemin vers le moteur PowerShell. Assurez-vous que la valeur de Path est C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe, qui pointe vers le moteur PowerShell de Windows.
La stratégie d’exécution CurrentUser annule une stratégie LocalMachine. Si vous avez une stratégie CurrentUser définie dans le registre et que vous essayez de changer la stratégie d’exécution via Set-ExecutionPolicy, qui, par défaut, définit la stratégie au niveau de LocalMachine, PowerShell renverra une erreur indiquée ci-dessous.
Définir la stratégie d’exécution PowerShell via la stratégie de groupe
Si vous êtes dans une organisation avec Active Directory, vous ne voudrez pas aller sur toutes vos machines Windows et exécuter la cmdlet Set-ExecutionPolicy. Au lieu de cela, vous pouvez gérer les stratégies en masse avec la stratégie de groupe.
Pour gérer les stratégies d’exécution via la GPO:
Créez l’objet de stratégie de groupe
- Ouvrez l’application de gestion de la stratégie de groupe sur un contrôleur de domaine ou sur votre poste de travail rejoint au domaine.
2. Développez Domains —> <votre forêt Active Directory> —> Group Policy Objects.
3. Faites un clic droit sur Group Policy Objects et cliquez sur New.
4. Donnez un nom à votre GPO. Dans ce tutoriel, la GPO est appelée PowerShell Execution Policy.
5. Cliquez avec le bouton droit de la souris sur la GPO nouvellement créée et cliquez sur Edit.
6. Accédez à Configuration de l’ordinateur\Stratégies\Modèles d’administration\Composants Windows\Windows PowerShell.
7. Ouvrez le paramètre dans le volet droit de la fenêtre, ouvrez le paramètre Activer l’exécution de scripts.
8. Dans la zone Activer l’exécution de scripts, sélectionnez l’option Activé. Vous pouvez maintenant sélectionner l’une des options ci-dessous:
9. Modifiez maintenant la Politique d’exécution selon votre souhait.
- Autoriser uniquement les scripts signés – Autorise l’exécution de tous les scripts lorsqu’un éditeur de confiance les signe.
- Autoriser les scripts locaux et les scripts signés à distance – Autorise l’exécution de scripts locaux mais les scripts téléchargés depuis Internet doivent être signés par un éditeur de confiance.
- Autoriser tous les scripts – Autorise l’exécution de tous les scripts.
Attribuer l’objet de stratégie de groupe
Une fois la GPO créée, il est temps de l’attribuer à vos ordinateurs cibles. Pour cela, vous devez attribuer la GPO à une unité organisationnelle de l’annuaire Active Directory (OU).
Si, au lieu de créer une nouvelle GPO, vous avez modifié une GPO existante, cette GPO a probablement déjà été attribuée à une OU.
- Dans Gestion des stratégies de groupe, accédez à votre unité organisationnelle de choix en allant dans Domaines —> <votre forêt Active Directory> —> <Votre UO>.
2. Cliquez avec le bouton droit sur l’OU et sélectionnez Associer une GPO existante…
3. Sélectionnez la GPO nouvellement créée (PowerShell Execution Policy) et cliquez sur OK.
Vous devriez maintenant voir la GPO assignée à l’OU comme indiqué ci-dessous.
À ce stade, vous pouvez soit attendre l’intervalle de rafraîchissement de la stratégie de groupe défini, soit exécuter la commande gpupdate sur un ordinateur cible pour forcer un rafraîchissement.
Verrouillage des modifications de la politique locale
Une fois qu’une GPO est en vigueur et modifie la stratégie d’exécution, les utilisateurs locaux ne peuvent plus modifier la politique via la console PowerShell locale. S’ils essaient, ils recevront une erreur, comme indiqué ci-dessous.
Bypassing la politique d’exécution complètement
Comme mentionné précédemment, une politique d’exécution n’est pas nécessairement censée être une mesure de sécurité. Pourquoi ? Parce que vous pouvez la contourner complètement si vous le souhaitez de plusieurs façons différentes.
En utilisant le paramètre -ExecutionPolicy Bypass
Contrairement aux autres stratégies d’exécution, la stratégie Bypass est généralement définie non pas dans la console PowerShell mais transmise au moteur powershell.exe exécuté en tant qu’administrateur.
Par exemple, pour exécuter un script appelé Hello World.ps1 en sautant complètement toute stratégie d’exécution, invoquez powershell.exe, utilisez le paramètre Bypass et fournissez le chemin du fichier comme indiqué ci-dessous.
Lecture de scripts et exécution de code brut
Vous pouvez également contourner toute stratégie d’exécution en lisant d’abord le contenu d’un script, puis en passant ce contenu directement au moteur PowerShell. Ce faisant, chaque commande est exécutée individuellement et non pas comme un script entier en une seule fois.
Comme vous pouvez le voir ci-dessous, la stratégie d’exécution est définie sur Restreint, mais en lisant le script et en le passant à powershell.exe, il fonctionne toujours.
Cette approche est similaire à l’ouverture d’un script dans un éditeur PowerShell comme PowerShell ISE ou Visual Studio Code, en sélectionnant une ligne et en appuyant sur F8.
Conclusion
À présent, vous devriez savoir tout ce qu’il y a à savoir sur les stratégies d’exécution PowerShell. Bien qu’elles ne soient pas techniquement une mesure de sécurité, vous devriez toujours les gérer dans votre organisation conformément aux politiques organisationnelles.