Partager via


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 de l’ordinateur local et de 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 restreint les actions de l’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 un 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 de console indiquant qu’elle n’est pas prise en charge. Bien que Get-ExecutionPolicy retourne Unrestricted sur des plateformes non Windows, le comportement correspond Bypass vraiment, car 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écuter des 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 serveur Windows.
    • Les scripts peuvent s’exécuter.
    • Nécessite une signature numérique d’un éditeur approuvé sur les scripts et fichiers de configuration téléchargés à partir d’Internet, y compris les programmes de messagerie électronique et de messagerie instantanée.
    • Ne nécessite pas de signatures numériques sur les scripts qui sont écrits sur l’ordinateur local et qui ne sont pas 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 provenant de sources autres qu’Internet et des scripts signés qui peuvent ê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, y compris les fichiers de mise en forme et 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 d’accès UNC (Universal Naming Convention) des chemins Internet, les scripts identifiés par un chemin 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 qui n’est effective que dans une étendue particulière.

Les valeurs valides pour Scope sont MachinePolicy, UserPolicy, Process, CurrentUser 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 à un niveau de priorité inférieur.

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 la stratégie d’exécution définie pour l’ordinateur local.

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

Par exemple, la commande suivante obtient la stratégie d’exécution pour 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 prend effet 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 modifiiez à 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 les versions ultérieures de Windows, pour exécuter des commandes qui modifient la stratégie d’exécution de l’ordinateur local, é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 de modification d’une stratégie d’exécution peut réussir, mais toujours pas modifier la stratégie d’exécution effective.

Par exemple, une commande qui définit la stratégie d’exécution de 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 pour 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 d’un Scope:

Set-ExecutionPolicy -ExecutionPolicy Undefined -Scope CurrentUser

Si aucune stratégie d’exécution n’est définie dans une étendue quelconque, 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 de pwsh.exe pour définir une stratégie d’exécution pour une nouvelle session PowerShell. La stratégie affecte uniquement la session active 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 ou à partir de PowerShell, puis utilisez le paramètre ExecutionPolicy de pour définir la stratégie d’exécution pwsh.exe .

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 une 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 de 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 des scripts sont les suivants :

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

  • Si vous activez le paramètre Activer 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 le paramètre Activer l’exécution du script n’est pas configuré, cela 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 des scripts aux nœuds Configuration de l’ordinateur et Configuration de l’utilisateur dans l’Éditeur de stratégie de groupe dans les chemins d’accès suivants.

Pour Windows XP et Windows Server 2003 :

Administrative Templates\Windows Components\Windows PowerShell

Pour Windows Vista et les versions ultérieures de Windows :

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

Les stratégies définies dans le nœud Configuration de l’ordinateur ont la priorité sur les stratégies définies dans le nœud Configuration de l’utilisateur.

Pour plus d’informations, consultez about_Group_Policy_Settings.

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

Lors de la détermination de 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: LocalMachine
Execution Policy: CurrentUser

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

Dans Windows, des programmes comme 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écutera pas de scripts non signés qui sont téléchargés à partir d’Internet, y compris les 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 parce qu’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, lors de 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 zone case activée ce qui évite le problème.

Voir aussi