about_Execution_Policies

Description courte

Décrit les stratégies d’exécution PowerShell et explique comment les gérer.

Description longue

La stratégie d’exécution de PowerShell est une fonctionnalité de sécurité qui contrôle les conditions dans lesquelles PowerShell charge les fichiers de configuration et exécute des scripts. Cette fonctionnalité permet d’éviter l’exécution de scripts malveillants.

Sur un ordinateur Windows, vous pouvez définir une stratégie d’exécution pour l’ordinateur local, pour l’utilisateur actuel ou pour une session particulière. Vous pouvez également utiliser un paramètre de stratégie de groupe pour définir des stratégies d’exécution pour les ordinateurs et les utilisateurs.

Les stratégies d’exécution pour l’ordinateur local et l’utilisateur actuel sont stockées dans le Registre. Vous n’avez pas besoin de définir des stratégies d’exécution dans votre profil PowerShell. La stratégie d’exécution d’une session particulière est stockée uniquement en mémoire et est perdue lorsque la session est fermée.

La stratégie d’exécution n’est pas un système de sécurité qui limite les actions utilisateur. Par exemple, les utilisateurs peuvent facilement contourner une stratégie en tapant le contenu du script sur la ligne de commande lorsqu’ils ne peuvent pas exécuter de script. Au lieu de cela, la stratégie d’exécution aide les utilisateurs à définir des règles de base et les empêche de les violer involontairement.

Sur les ordinateurs non Windows, la stratégie d’exécution par défaut est Unrestricted et ne peut pas être modifiée. L’applet Set-ExecutionPolicy de commande est disponible, mais PowerShell affiche un message console qui n’est pas pris en charge. Bien que Get-ExecutionPolicy les retours Unrestricted sur les plateformes non Windows correspondent vraiment Bypass parce que ces plateformes n’implémentent pas les zones Sécurité Windows.

Stratégies d’exécution PowerShell

L’application de ces stratégies se produit uniquement sur les plateformes Windows. Les stratégies d’exécution PowerShell sont les suivantes :

AllSigned

  • Les scripts peuvent s’exécuter.
  • nécessite que tous les scripts et fichiers de configuration soient signés par un éditeur approuvé, y compris les scripts que vous écrivez sur l'ordinateur local.
  • Vous invite avant d’exécuter des scripts à partir d’éditeurs que vous n’avez pas encore classés comme approuvés ou non approuvés.
  • Risque d’exécution de scripts signés, mais malveillants.

Bypass

  • rien n'est bloqué, et aucun avertissement, ni aucune invite ne s'affiche.
  • Cette stratégie d’exécution est conçue pour les configurations dans lesquelles un script PowerShell est intégré à une application plus grande ou pour les configurations dans lesquelles PowerShell est la base d’un programme qui a son propre modèle de sécurité.

Default

  • Définit la stratégie d’exécution par défaut.
  • Restricted pour les clients Windows.
  • RemoteSigned pour les serveurs Windows.

RemoteSigned

  • Stratégie d’exécution par défaut pour les ordinateurs Windows Server.
  • Les scripts peuvent s’exécuter.
  • Nécessite une signature numérique à partir d’un éditeur approuvé sur des scripts et des fichiers de configuration téléchargés à partir d’Internet, qui inclut des programmes de messagerie et de messagerie instantanée.
  • Ne nécessite pas de signatures numériques sur les scripts écrits sur l’ordinateur local et non téléchargés à partir d’Internet.
  • Exécute des scripts téléchargés à partir d’Internet et non signés, si les scripts sont débloqués, par exemple à l’aide de l’applet Unblock-File de commande.
  • Risque d’exécuter des scripts non signés à partir de sources autres que les scripts Internet et signés qui pourraient être malveillants.

Restricted

  • Stratégie d’exécution par défaut pour les ordinateurs clients Windows.
  • Autorise les commandes individuelles, mais n’autorise pas les scripts.
  • Empêche l’exécution de tous les fichiers de script, notamment la mise en forme et les fichiers de configuration (.ps1xml), les fichiers de script de module (.psm1) et les profils PowerShell (.ps1).

Undefined

  • Aucune stratégie d’exécution n’est définie dans l’étendue actuelle.
  • Si la stratégie d’exécution dans toutes les étendues est Undefined, la stratégie d’exécution effective est Restricted pour les clients Windows et RemoteSigned pour Windows Server.

Unrestricted

  • La stratégie d’exécution par défaut pour les ordinateurs non Windows et ne peut pas être modifiée.
  • Les scripts non signés peuvent s’exécuter. Il existe un risque d’exécution de scripts malveillants.
  • Avertit l’utilisateur avant d’exécuter des scripts et des fichiers de configuration qui ne proviennent pas de la zone intranet locale.

Notes

Sur les systèmes qui ne distinguent pas les chemins UNC (Universal Naming Convention) des chemins Internet, les scripts identifiés par un chemin d’accès UNC peuvent ne pas être autorisés à s’exécuter avec la stratégie d’exécution RemoteSigned .

Étendue de la stratégie d’exécution

Vous pouvez définir une stratégie d’exécution efficace uniquement dans une étendue particulière.

Les valeurs valides MachinePolicysont Scope , UserPolicy, ProcessCurrentUser et LocalMachine. LocalMachine est la valeur par défaut lors de la définition d’une stratégie d’exécution.

Les Scope valeurs sont répertoriées dans l’ordre de priorité. La stratégie qui est prioritaire est effective dans la session actuelle, même si une stratégie plus restrictive a été définie au niveau inférieur de la priorité.

Pour plus d’informations, consultez Set-ExecutionPolicy.

MachinePolicy

Défini par un stratégie de groupe pour tous les utilisateurs de l’ordinateur.

UserPolicy

Défini par un stratégie de groupe pour l’utilisateur actuel de l’ordinateur.

Process

L’étendue Process affecte uniquement la session PowerShell actuelle. La stratégie d’exécution est enregistrée dans la variable $env:PSExecutionPolicyPreferenced’environnement, plutôt que dans le Registre. Lorsque la session PowerShell est fermée, la variable et la valeur sont supprimées.

Utilisateur en cours

la stratégie d'exécution affecte uniquement l'utilisateur actuel. Il est stocké dans la sous-clé de Registre HKEY_CURRENT_USER .

LocalMachine

La stratégie d’exécution affecte tous les utilisateurs sur l’ordinateur actuel. Il est stocké dans la sous-clé de Registre HKEY_LOCAL_MACHINE .

Gestion de la stratégie d’exécution avec PowerShell

Pour obtenir la stratégie d’exécution effective pour la session PowerShell actuelle, utilisez l’applet de Get-ExecutionPolicy commande.

La commande suivante obtient la stratégie d’exécution effective :

Get-ExecutionPolicy

Pour obtenir toutes les stratégies d’exécution qui affectent la session active et les afficher dans l’ordre de priorité :

Get-ExecutionPolicy -List

Le résultat ressemble à l’exemple de sortie suivant :

        Scope ExecutionPolicy
        ----- ---------------
MachinePolicy       Undefined
   UserPolicy       Undefined
      Process       Undefined
  CurrentUser    RemoteSigned
 LocalMachine       AllSigned

Dans ce cas, la stratégie d’exécution effective est RemoteSigned , car la stratégie d’exécution de l’utilisateur actuel est prioritaire sur le jeu de stratégies d’exécution pour l’ordinateur local.

Pour obtenir le jeu de stratégies d’exécution pour une étendue particulière, utilisez le Scope paramètre .Get-ExecutionPolicy

Par exemple, la commande suivante obtient la stratégie d’exécution de l’étendue CurrentUser :

Get-ExecutionPolicy -Scope CurrentUser

Modifier la stratégie d’exécution

Pour modifier la stratégie d’exécution PowerShell sur votre ordinateur Windows, utilisez l’applet de Set-ExecutionPolicy commande. La modification est effective immédiatement. Vous n’avez pas besoin de redémarrer PowerShell.

Si vous définissez la stratégie d’exécution pour les étendues LocalMachine ou CurrentUser, la modification est enregistrée dans le Registre et reste effective jusqu’à ce que vous la modifiez à nouveau.

Si vous définissez la stratégie d’exécution pour l’étendue Process , elle n’est pas enregistrée dans le Registre. La stratégie d’exécution est conservée jusqu’à ce que le processus actuel et tous les processus enfants soient fermés.

Notes

Dans Windows Vista et versions ultérieures de Windows, pour exécuter des commandes qui modifient la stratégie d’exécution pour l’ordinateur local, l’étendue LocalMachine , démarrez PowerShell avec l’option Exécuter en tant qu’administrateur .

Pour modifier votre stratégie d’exécution :

Set-ExecutionPolicy -ExecutionPolicy <PolicyName>

Par exemple :

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned

Pour définir la stratégie d’exécution dans une étendue particulière :

Set-ExecutionPolicy -ExecutionPolicy <PolicyName> -Scope <scope>

Par exemple :

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser

Une commande permettant de modifier une stratégie d’exécution peut réussir, mais ne change toujours pas la stratégie d’exécution effective.

Par exemple, une commande qui définit la stratégie d’exécution pour l’ordinateur local peut réussir, mais être remplacée par la stratégie d’exécution de l’utilisateur actuel.

Supprimer la stratégie d’exécution

Pour supprimer la stratégie d’exécution d’une étendue particulière, définissez la stratégie d’exécution sur Undefined.

Par exemple, pour supprimer la stratégie d’exécution pour tous les utilisateurs de l’ordinateur local :

Set-ExecutionPolicy -ExecutionPolicy Undefined -Scope LocalMachine

Pour supprimer la stratégie d’exécution pour un Scope:

Set-ExecutionPolicy -ExecutionPolicy Undefined -Scope CurrentUser

Si aucune stratégie d’exécution n’est définie dans une étendue, la stratégie d’exécution effective est Restricted, qui est la valeur par défaut pour les clients Windows.

Définir une stratégie différente pour une session

Vous pouvez utiliser le paramètre ExecutionPolicy pour pwsh.exe définir une stratégie d’exécution pour une nouvelle session PowerShell. La stratégie affecte uniquement les sessions actuelles et les sessions enfants.

Pour définir la stratégie d’exécution d’une nouvelle session, démarrez PowerShell sur la ligne de commande, par cmd.exe exemple à partir de PowerShell, puis utilisez le paramètre ExecutionPolicy pour pwsh.exe définir la stratégie d’exécution.

Par exemple :

pwsh.exe -ExecutionPolicy AllSigned

La stratégie d’exécution que vous définissez n’est pas stockée dans le Registre. Au lieu de cela, il est stocké dans la variable d’environnement $env:PSExecutionPolicyPreference . La variable est supprimée lorsque vous fermez la session dans laquelle la stratégie est définie. Vous ne pouvez pas modifier la stratégie en modifiant la valeur de la variable.

Pendant la session, la stratégie d’exécution définie pour la session est prioritaire sur une stratégie d’exécution définie dans le Registre pour l’ordinateur local ou l’utilisateur actuel. Toutefois, elle n’est pas prioritaire sur la stratégie d’exécution définie à l’aide d’un stratégie de groupe.

Utiliser stratégie de groupe pour gérer la stratégie d’exécution

Vous pouvez utiliser le paramètre Activer l’exécution du script stratégie de groupe pour gérer la stratégie d’exécution des ordinateurs de votre entreprise. Le paramètre stratégie de groupe remplace les stratégies d’exécution définies dans PowerShell dans toutes les étendues.

Les paramètres de stratégie Activer l’exécution de script sont les suivants :

  • Si vous désactivez l’exécution du script, les scripts ne s’exécutent pas. Cela équivaut à la stratégie d’exécution Restricted .

  • Si vous activez l’activation de l’exécution du script, vous pouvez sélectionner une stratégie d’exécution. Les paramètres stratégie de groupe sont équivalents aux paramètres de stratégie d’exécution suivants :

    Stratégie de groupe Stratégie d’exécution
    Autoriser tous les scripts Unrestricted
    Autoriser les scripts locaux et les scripts signés distants RemoteSigned
    Autoriser uniquement les scripts signés AllSigned
  • Si l’exécution du script n’est pas configurée, elle n’a aucun effet. La stratégie d’exécution définie dans PowerShell est efficace.

Les fichiers PowerShellExecutionPolicy.adm et PowerShellExecutionPolicy.admx ajoutent la stratégie Activer l’exécution de script aux nœuds Configuration ordinateur et Configuration utilisateur dans stratégie de groupe Éditeur dans les chemins d’accès suivants.

Pour Windows XP et Windows Server 2003 :

Administrative Templates\Windows Components\Windows PowerShell

Pour Windows Vista et versions ultérieures de Windows :

Administrative Templates\Classic Administrative Templates\Windows Components\Windows PowerShell

Les stratégies définies dans le nœud Configuration ordinateur sont prioritaires sur les stratégies définies dans le nœud Configuration utilisateur.

Pour plus d’informations, consultez about_Group_Policy_Settings.

Priorité de la stratégie d’exécution

Lorsque vous déterminez la stratégie d’exécution effective pour une session, PowerShell évalue les stratégies d’exécution dans l’ordre de priorité suivant :

Group Policy: MachinePolicy
Group Policy: UserPolicy
Execution Policy: Process (or pwsh.exe -ExecutionPolicy)
Execution Policy: CurrentUser
Execution Policy: LocalMachine

Gérer les scripts signés et non signés

Dans Windows, les programmes tels qu’Internet Explorer et Microsoft Edge ajoutent un autre flux de données aux fichiers téléchargés. Cela marque le fichier comme « provenant d’Internet ». Si votre stratégie d’exécution PowerShell est RemoteSigned, PowerShell n’exécute pas de scripts non signés téléchargés à partir d’Internet qui incluent des programmes de messagerie électronique et de messagerie instantanée.

Vous pouvez signer le script ou choisir d’exécuter un script non signé sans modifier la stratégie d’exécution.

À compter de PowerShell 3.0, vous pouvez utiliser le paramètre Stream de l’applet Get-Item de commande pour détecter les fichiers bloqués, car ils ont été téléchargés à partir d’Internet. Utilisez l’applet Unblock-File de commande pour débloquer les scripts afin de pouvoir les exécuter dans PowerShell.

Pour plus d’informations, consultez about_Signing, Get-Item et Unblock-File.

Notes

D’autres méthodes de téléchargement de fichiers peuvent ne pas marquer les fichiers comme provenant de la zone Internet. Voici quelques exemples :

  • curl.exe
  • Invoke-RestMethod
  • Invoke-WebRequest

Stratégie d’exécution sur Windows Server Core et Windows Nano Server

Lorsque PowerShell 6 est exécuté sur Windows Server Core ou Windows Nano Server dans certaines conditions, les stratégies d’exécution peuvent échouer avec l’erreur suivante :

AuthorizationManager check failed.
At line:1 char:1
+ C:\scriptpath\scriptname.ps1
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : SecurityError: (:) [], PSSecurityException
    + FullyQualifiedErrorId : UnauthorizedAccess

PowerShell utilise des API dans Windows Desktop Shell (explorer.exe) pour valider la zone d’un fichier de script. Windows Shell n’est pas disponible sur Windows Server Core et Windows Nano Server.

Vous pouvez également obtenir cette erreur sur n’importe quel système Windows si Windows Desktop Shell n’est pas disponible ou ne répond pas. Par exemple, pendant l’authentification, un script d’ouverture de session PowerShell peut démarrer l’exécution avant que le Bureau Windows soit prêt, ce qui entraîne un échec.

L’utilisation d’une stratégie d’exécution de ByPass ou AllSigned ne nécessite pas de vérification de zone qui évite le problème.

Voir aussi