about_Execution_Policies

  • Article

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 restreint 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êcher 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 qui n’est pas pris en charge. Bien que Get-ExecutionPolicy les retours Unrestricted sur les plateformes non-Windows correspondent vraiment, le comportement correspond Bypass vraiment 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 de 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.
    • Risques liés à l’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 auprès 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 électronique et de messagerie instantanée.
    • Ne nécessite pas de signatures numériques sur des 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éblocé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 qu’Internet et des scripts signés susceptibles d’ê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 concerne Restricted 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.

    Remarque

    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 est efficace uniquement dans une étendue particulière.

Les valeurs valides sont MachinePolicyScope , 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 précédence. La stratégie qui est prioritaire est efficace dans la session active, même si une stratégie plus restrictive a été définie à un niveau inférieur de priorité.

Pour plus d’informations, consultez Set-ExecutionPolicy.

  • MachinePolicy

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

  • UserPolicy

    Défini par une 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 Get-ExecutionPolicy de 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 de 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 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.

Remarque

Dans Windows Vista et les 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 elle ne modifie 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 Undefinedd’exécution sur .

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, 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 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 à 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 $env:PSExecutionPolicyPreference variable d’environnement. 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’une 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 de stratégie de groupe Activer l’exécution des scripts 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 Restricted stratégie d’exécution.

  • 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

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: LocalMachine
Execution Policy: CurrentUser

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

Dans Windows, les 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é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.

Remarque

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. L’interpréteur de commandes Windows 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 d’case activée zone qui évite le problème.

Voir aussi