Politique d'exécution PowerShell

Introduction aux politiques d'exécution de PowerShell

Dans PowerShell, les stratégies d'exécution sont une fonctionnalité de sécurité conçue pour contrôler les conditions dans lesquelles les scripts PowerShell s'exécutent sur un système. Ces politiques ne sont pas exactement un mécanisme de sécurité mais sont destinées à servir le but suivant :

• Prévenez l'exécution accidentelle de scripts
• Aidez à gérer le risque d'exécuter des scripts provenant de sources inconnues ou non fiables

Les politiques d'exécution jouent un rôle important dans l'amélioration de la sécurité des scripts. Elles agissent comme une première ligne de défense en restreignant les types de scripts pouvant être exécutés sur un système. Elles établissent également la confiance pour les sources de scripts, comme les politiques telles que AllSigned et RemoteSigned qui garantissent que les scripts proviennent de sources fiables. Cela aide à réduire les erreurs humaines, comme dans une situation où les utilisateurs pourraient exécuter sans le savoir des scripts téléchargés à partir de pièces jointes d'e-mails ou du web. Dans un contexte plus large, les organisations peuvent utiliser les politiques d'exécution pour imposer des pratiques de sécurité cohérentes à travers les machines et les utilisateurs.

Cependant, vous devez également garder à l'esprit que :

• Les stratégies d'exécution ne constituent pas une limite de sécurité. Elles peuvent être outrepassées par des utilisateurs disposant de privilèges administratifs ou contournées via des indicateurs spécifiques de PowerShell.
• Leur objectif principal est d'empêcher l'exécution accidentelle, pas d'arrêter les acteurs malveillants avec une intention délibérée.

Les stratégies d'exécution PowerShell doivent être utilisées dans le cadre d'une stratégie de sécurité plus large, incluant des scripts signés, des dépôts sécurisés et d'autres mesures de protection.

Comprendre les politiques d'exécution PowerShell

Commençons par voir comment les politiques d'exécution fonctionnent en pratique. Lorsque vous exécutez un script, PowerShell vérifie la politique d'exécution.

• Si le script répond aux exigences, telles qu'être signé par un éditeur de confiance ou provenir d'une source locale, il s'exécute.
• Si le script ne répond pas aux exigences de la politique, PowerShell empêche son exécution et affiche un message d'erreur.

Principaux avantages

Certains avantages clés des stratégies d'exécution PowerShell sont :

• Empêche l'exécution accidentelle de scripts malveillants – Les politiques d'exécution réduisent le risque d'exécuter involontairement des scripts non fiables ou nuisibles, en particulier ceux téléchargés depuis internet.
• Encourage les pratiques de script sécurisées – Des politiques telles que AllSigned et RemoteSigned encouragent les auteurs et les utilisateurs de scripts à signer les scripts avec des certificats de confiance, garantissant ainsi leur authenticité et intégrité.
• Différenciez les scripts locaux et distants – Des politiques telles que RemoteSigned permettent aux scripts créés localement de s'exécuter sans restrictions tout en appliquant des contrôles plus stricts sur les scripts distants ou téléchargés.
• Configuration flexible – Les politiques d'exécution peuvent être appliquées à différents niveaux (Process, CurrentUser, LocalMachine, MachinePolicy et UserPolicy), donnant aux administrateurs le contrôle sur la manière et le lieu d'application des politiques.
• Dérogations temporaires pour plus de flexibilité – Les dérogations temporaires (par exemple, en utilisant -ExecutionPolicy Bypass) permettent d'exécuter des scripts dans des scénarios contrôlés sans modifier de manière permanente les paramètres de sécurité du système.
• Favorise la conformité organisationnelle – Les politiques d'exécution peuvent être appliquées dans toute une organisation via la stratégie de groupe pour garantir des pratiques de sécurité cohérentes pour l'exécution de scripts.
• Sensibilise à la sécurité des scripts – En exigeant une action explicite, comme signer des scripts ou contourner des politiques, les politiques d'exécution incitent les utilisateurs à réfléchir de manière critique sur les sources des scripts et leur fiabilité.

Principales limitations

Certaines limitations clés des stratégies d'exécution de PowerShell sont :

• Les politiques d'exécution ne constituent pas une limite de sécurité car elles ne sont pas conçues pour prévenir les attaques délibérées. Un utilisateur averti disposant de privilèges administratifs peut facilement les contourner en :
• En utilisant le drapeau -ExecutionPolicy Bypass
• Modification du registre système
• Exécuter des scripts au sein d'un autre processus ou contourner complètement PowerShell
• Les politiques d'exécution n'analysent pas le contenu des scripts. Même les scripts signés peuvent contenir du code malveillant si la clé de signature est compromise.
• Les politiques d'exécution ont une portée de protection limitée car elles ne s'appliquent qu'aux scripts et commandes PowerShell. Elles ne contrôlent pas les autres types de scripts (par exemple, VBScript, Python) ou les fichiers exécutables, laissant des lacunes dans la protection.
• Des politiques strictes telles que AllSigned peuvent entraîner des retards si les utilisateurs n'ont pas accès à une infrastructure de signature fiable ou travaillent fréquemment avec des scripts non signés.
• Les politiques d'exécution dépendent de la conformité des utilisateurs. Des utilisateurs non formés pourraient contourner ou désactiver ces politiques sans en comprendre pleinement les conséquences.
• Plusieurs portées de politiques, telles que MachinePolicy, UserPolicy et Process, peuvent créer de la confusion, en particulier dans des environnements avec des configurations mixtes ou chevauchantes.
• Les scripts automatisés ou les pipelines CI/CD peuvent rencontrer des problèmes en raison de politiques restrictives, nécessitant une configuration supplémentaire ou des dérogations temporaires de politique.
• Les politiques d'exécution peuvent créer un faux sentiment de sécurité. Les administrateurs et les utilisateurs pourraient à tort supposer qu'il s'agit d'un mécanisme de sécurité robuste, alors qu'elles sont avant tout une protection contre l'exécution accidentelle de scripts.

Le tableau suivant résume les principaux avantages et limitations des stratégies d'exécution PowerShell.

Types de stratégies d'exécution PowerShell

PowerShell propose six types de stratégies d'exécution.

Restreint

Ceci est la politique d'exécution par défaut sur les systèmes Windows. Elle bloque l'exécution de tous les scripts, empêchant ainsi les administrateurs d'automatiser les tâches à l'aide de scripts. Sous cette politique, seules les commandes individuelles peuvent être exécutées de manière interactive.

Comme cette politique garantit des restrictions maximales d'exécution de scripts, elle est idéale pour les environnements où les scripts ne sont pas nécessaires.

RemoteSigned

Il s'agit de la politique d'exécution par défaut pour les serveurs Windows. Cette politique exige que les scripts distants, tels que ceux téléchargés depuis Internet, soient signés par un éditeur de confiance. Les scripts écrits sur l'ordinateur local n'ont pas besoin d'être signés. Dans l'ensemble, cette politique équilibre la sécurité et la commodité, bien qu'elle puisse causer des désagréments dans certains scénarios.

Pour exécuter un script non signé téléchargé depuis internet, vous devez le débloquer, par exemple en utilisant le cmdlet Unblock-File.

AllSigned

Cette politique repose sur des certificats de confiance et une infrastructure de certificats. Selon celle-ci, seuls les scripts et fichiers de configuration signés par un éditeur de confiance peuvent s'exécuter. Les scripts non signés ou altérés ne peuvent pas s'exécuter. De plus, l'utilisateur est invité à confirmer avant d'exécuter tout script, même s'il est signé.

Cette politique est la meilleure pour les environnements qui mettent fortement l'accent sur l'intégrité des scripts et l'authentification.

Sans restriction

Cette politique permet à tous les scripts de s'exécuter sans restriction, bien que des avertissements soient affichés pour les scripts distants non signés avant l'exécution. C'est la politique d'exécution par défaut pour les ordinateurs non Windows et elle ne peut pas être modifiée.

Comme cette politique augmente le risque d'exécuter des scripts malveillants ou nuisibles, elle devrait être limitée aux environnements de développement ou de test où la flexibilité est privilégiée par rapport à la sécurité.

Contourner

Cette politique permet aux scripts de s'exécuter librement, sans avertissements ni invites. Utilisez cette option dans des scénarios d'automatisation, des pipelines CI/CD ou lorsque les politiques d'exécution interfèrent avec des flux de travail légitimes. Attention, l'absence de protection ou de restrictions peut multiplier le risque d'exécution accidentelle ou malveillante de scripts.

Indéfini

L'utilisation de cette option supprime la politique d'exécution pour la portée actuelle. Si toutes les portées sont indéfinies, la politique effective par défaut est Restricted pour les clients Windows et RemoteSigned pour Windows Server. Elle est utilisée pour effacer les paramètres de politique d'exécution pour une portée.

Portée des politiques d'exécution PowerShell

Les stratégies d'exécution PowerShell peuvent être appliquées à différents niveaux, qui déterminent comment et où la politique est appliquée. Les niveaux permettent aux administrateurs de contrôler le comportement d'exécution des scripts à différents échelons, tels que pour des utilisateurs individuels, tous les utilisateurs sur une machine ou une seule session. Les différents niveaux sont discutés ci-dessous.

Les politiques d'exécution pour l'utilisateur actuel et l'ordinateur local sont stockées dans les fichiers de configuration PowerShell. La politique d'exécution pour une session spécifique est stockée uniquement en mémoire et est perdue lorsque la session est fermée.

Précédence de portée

Lorsque plusieurs stratégies d'exécution sont définies à différents niveaux, PowerShell utilise l'ordre de priorité suivant pour déterminer quelle stratégie est effective (de la plus haute à la plus basse priorité) :

1. Stratégie de groupe : MachinePolicy
2. Stratégie de groupe : UserPolicy
3. Politique d'exécution : Process
4. Politique d'exécution : LocalMachine
5. Politique d'exécution : CurrentUser

N'oubliez pas ce qui suit :

• Les paramètres de stratégie de groupe (MachinePolicy et UserPolicy) remplacent les configurations locales.
• Si aucun périmètre n'est spécifié lors de la définition d'une politique d'exécution, LocalMachine est utilisé par défaut.
• Si une stratégie de groupe est en place, les tentatives de modification de la politique avec Set-ExecutionPolicy à des portées inférieures échoueront.

Définition des stratégies d'exécution PowerShell

Définir une stratégie d'exécution PowerShell détermine comment les scripts sont exécutés sur un système.

Vérifiez la politique d'exécution actuelle

Utilisez le cmdlet suivant pour vérifier la politique d'exécution actuelle :

      Get-ExecutionPolicy
      

Vérifiez les politiques pour tous les périmètres

Utilisez le cmdlet suivant pour vérifier les politiques pour tous les périmètres :

      Get-ExecutionPolicy -List
      

Définissez une politique d'exécution

Utilisez le cmdlet Set-ExecutionPolicy pour définir une politique d'exécution pour PowerShell.

Syntaxe de commande

      Set-ExecutionPolicy <PolicyName> -Scope <Scope>
      

Exemple 1 – Définir une politique d'exécution

Utilisez le cmdlet suivant pour définir la politique sur Unrestricted.

      Set-ExecutionPolicy Unrestricted
      

Appuyez sur Y pour continuer ou L pour annuler l'action.

Exemple 2 – Spécifiez la portée de la politique d'exécution

Vous pouvez définir la politique à différents niveaux (portées). Utilisez le cmdlet suivant pour définir la politique sur RemoteSigned pour la machine locale :

      Set-ExecutionPolicy RemoteSigned -Scope LocalMachine
      

Notez ce qui suit :

• Vous devez exécuter PowerShell en tant qu'administrateur pour définir les stratégies d'exécution pour le périmètre LocalMachine.
• Si une politique est appliquée par Group Policy (MachinePolicy ou UserPolicy), elle prévaudra sur les autres paramètres, et toute tentative de modification de la politique entraînera une erreur.

Appliquez la politique d'exécution d'un ordinateur distant à un ordinateur local

Pour appliquer une stratégie d'exécution PowerShell d'un ordinateur distant à un ordinateur local, vous pouvez utiliser une combinaison de l'exécution à distance PowerShell et de l'applet de commande Set-ExecutionPolicy. Voici comment faire :

      Invoke-Command -ComputerName TargetComputer -ScriptBlock {

    Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Force

} -Credential (Get-Credential)
      

Ici, -ComputerName spécifie l'ordinateur cible. -ScriptBlock contient la commande à exécuter (Set-ExecutionPolicy dans ce cas). -Credential vous permet de spécifier des identifiants si le compte actuel n'a pas les permissions sur l'ordinateur cible.

Forcez le paramètre de stratégie

Pour contourner les invites lors des changements de politique d'exécution, utilisez le paramètre -Force.

      Set-ExecutionPolicy RemoteSigned -Force
      

Supprimer une politique d'exécution

Pour supprimer une politique pour un périmètre spécifique, définissez la politique sur Undefined.

      Set-ExecutionPolicy Undefined -Scope CurrentUser
      

Si tous les périmètres sont définis sur Undefined, la politique par défaut devient Restricted.

Contourner temporairement les stratégies d'exécution PowerShell

Vous pouvez contourner temporairement les stratégies d'exécution lors de l'exécution d'un script dans PowerShell sans changer définitivement la politique. Cependant, contourner les stratégies d'exécution peut exposer votre système à des risques de sécurité. Assurez-vous que les scripts que vous exécutez proviennent de sources fiables.

Notez également que des privilèges administratifs peuvent être nécessaires pour certaines commandes.

Exemple 1 : Contourner la politique d'exécution pour un script unique

Cette commande contourne la politique d'exécution pour cette invocation spécifique de PowerShell.

      powershell.exe -ExecutionPolicy Bypass -File "C:\Temp\Script.ps1"
      

Exemple 2 : Contournement dans la session actuelle

Vous pouvez temporairement modifier la politique d'exécution pour la durée de la session actuelle.

      Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass
      

Ici, -Scope Process garantit que la modification est limitée à la session PowerShell actuelle. Lorsque vous fermez la session, la politique d'exécution reviendra à son paramètre d'origine.

Exemple 3 : Exécutez des scripts sans changer de politique

Utilisez le paramètre -Command pour exécuter directement le script en ligne.

powershell.exe -ExecutionPolicy Bypass -Command “& { . ‘C:\Temp\Script.ps1’ }”

Utilisez Group Policy pour gérer la politique d'exécution

Le paramètre de stratégie de groupe Turn on Script Execution permet de gérer la politique d'exécution des ordinateurs de votre entreprise. Le paramètre de stratégie de groupe remplace les politiques d'exécution définies dans PowerShell dans tous les contextes.

• Lorsque Turn on Script Execution est désactivé, les scripts ne s'exécutent pas. Cela équivaut à la politique d'exécution Restricted.
• Vous pouvez activer Turn on Script Execution et sélectionner une politique d'exécution.
• Lorsque Turn on Script Execution n'est pas configuré, cela n'a aucun effet. La politique d'exécution définie dans PowerShell est effective.

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

Un script signé est un script PowerShell qui comprend :

• Le contenu du script
• Une signature numérique d'une autorité de certification (CA) de confiance ou un certificat auto-signé

Cela garantit que les scripts proviennent d'une source fiable et qu'ils n'ont pas été modifiés après leur signature. Les scripts signés contribuent à renforcer la sécurité dans les environnements nécessitant un contrôle sur les scripts pouvant être exécutés.

Les politiques d'exécution suivantes sont liées aux scripts signés :

• AllSigned – Exige que tous les scripts et fichiers de configuration soient signés par un éditeur de confiance.
• RemoteSigned – Exige que les scripts téléchargés depuis internet soient signés par un éditeur de confiance. Les scripts locaux n'ont pas besoin d'être signés.

Signer un script

Pour signer un script, vous avez besoin d'un certificat de signature de code.

• Vous pouvez obtenir un certificat d'une autorité de certification (CA) ou générer un certificat auto-signé en utilisant le cmdlet New-SelfSignedCertificate.
• Utilisez le cmdlet Set-AuthenticodeSignature pour signer le script.

Voici comment vous pouvez signer le script.

      $cert = Get-Item Cert:\CurrentUser\My\CERT_THUMBPRINT
      

      Set-AuthenticodeSignature -FilePath "C:\Temp\Script.ps1" -Certificate $cert
      

Remplacez CERT_THUMBPRINT par l'empreinte réelle de votre certificat.

Voir le statut de signature du script

Pour vérifier si un script est signé et le statut de la signature, utilisez :

      Get-AuthenticodeSignature -FilePath "C:\Temp\Script.ps1"
      

Gérez les scripts non approuvés ou non signés

Pour gérer les autorisations pour les scripts sans contourner complètement les politiques, considérez ce qui suit :

• Si un script est marqué comme ‘provenant d'internet’, débloquez-le.
• Lors de l'exécution de scripts signés d'un éditeur pour la première fois, vous devrez peut-être approuver le certificat de l'éditeur. Vous pouvez l'ajouter comme fiable à l'aide des outils de gestion des certificats.

Exemple : Débloquer un script

Parfois, un script peut être bloqué car il a été téléchargé depuis internet. Utilisez la cmdlet Unblock-File pour le débloquer sans contourner les politiques d'exécution.

      Unblock-File -Path "C:\Temp\Script.ps1"
      

Gérer les permissions des scripts

La gestion des autorisations de script dans PowerShell implique de contrôler quels scripts peuvent être exécutés et par qui. Cela inclut la configuration des politiques d'exécution, l'utilisation des permissions de fichiers et l'application des pratiques de signature de code.

Contrôlez l'exécution de scripts à l'aide des stratégies d'exécution PowerShell

Les stratégies d'exécution limitent les conditions dans lesquelles les scripts peuvent s'exécuter. Différentes politiques appliquent différentes restrictions. Par exemple, aucun script ne peut être exécuté sous la politique Restricted.

Utilisez la signature de code pour les scripts

La signature de scripts garantit que seuls les scripts fiables peuvent s'exécuter dans des environnements dotés de politiques strictes.

Utilisez les autorisations de fichiers NTFS

Restreignez l'accès aux fichiers de script en modifiant les permissions de fichier ou de dossier. Voici comment vous pouvez accorder ou refuser des permissions.

1. Cliquez avec le bouton droit sur le fichier script ou le dossier et choisissez Propriétés.
2. Allez dans l'onglet Sécurité et cliquez sur Modifier.
3. Ajoutez ou supprimez des utilisateurs ou des groupes et attribuez les permissions appropriées (par exemple, Lire, Écrire, Exécuter).
4. Refusez les permissions aux utilisateurs non autorisés pour empêcher l'exécution ou la modification.

Contrôlez les permissions en utilisant Group Policy

La stratégie de groupe peut appliquer des autorisations de script et des politiques d'exécution sur plusieurs systèmes. Pour configurer une stratégie de groupe :

1. Ouvrez la console de Group Policy Management (GPMC).
2. Accédez à Configuration de l'ordinateur > Modèles d'administration > Composants Windows > Windows PowerShell.
3. Définissez la politique d'exécution souhaitée à l'aide de la politique « Activer l'exécution de scripts ».

Sécurisez les scripts provenant de sources Internet

Les scripts téléchargés depuis internet sont marqués comme non sécurisés. Ouvrez le script dans un éditeur de texte pour vérifier sa sécurité avant de l'exécuter.

Meilleures pratiques pour la définition des politiques d'exécution

Définir correctement les stratégies d'exécution PowerShell est essentiel pour équilibrer la sécurité et la fonctionnalité. D'un point de vue sécurité, vous devez comprendre que les stratégies d'exécution ne sont pas une limite de sécurité robuste, mais un outil pour prévenir l'exécution accidentelle de scripts. Elles devraient être utilisées avec d'autres mesures de sécurité comme les contrôles d'accès, la signature de scripts et la protection des points de terminaison. Dans les environnements d'entreprise, appliquez des politiques cohérentes à travers les stratégies de groupe et éduquez les utilisateurs sur les meilleures pratiques pour minimiser les risques.

Voici ci-dessous quelques bonnes pratiques pour configurer des politiques d'exécution qui équilibrent la sécurité avec la fonctionnalité.

Utilisez la politique la moins permissive

Vous devriez appliquer la politique d'exécution Restricted ou AllSigned chaque fois que possible pour renforcer les contrôles. RemoteSigned est un choix pratique pour les environnements qui nécessitent une certaine flexibilité mais doivent toujours se protéger contre les menaces externes.

Évitez d'utiliser le contournement de manière permanente

Utilisez la politique d'exécution Bypass uniquement dans des scénarios d'automatisation ou de dépannage spécifiques. Revenez à une politique plus stricte une fois la tâche terminée.

Utilisez la signature numérique

Signez les scripts en utilisant une autorité de certification (CA) de confiance pour garantir l'intégrité et l'authenticité. Vous devez également encourager les développeurs de scripts à signer leurs scripts, en particulier pour une utilisation avec la politique AllSigned.

Mettez en œuvre la surveillance et la journalisation

Activez la journalisation pour les activités PowerShell (par exemple, la journalisation des blocs de script, la journalisation des modules et la transcription) afin de détecter et de répondre aux activités suspectes.

Utilisez le cmdlet suivant pour activer la journalisation du module :

      Set-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ModuleLogging" -Name EnableModuleLogging -Value 1
      

Les journaux peuvent être consultés dans l'Observateur d'événements sous Journaux des applications et des services > Microsoft > Windows > PowerShell.

Vous pouvez également utiliser des outils comme Microsoft Defender for Endpoint ou des solutions SIEM pour surveiller les journaux.

Tester les politiques dans un environnement non productif

Pour éviter les surprises, testez les politiques d'exécution dans un environnement contrôlé avant de les déployer à l'échelle de l'organisation. Cela garantira également que les scripts légitimes et les flux de travail d'automatisation ne soient pas perturbés.

Utilisez des changements de politique conditionnels

Pour gérer les flux de travail nécessitant de la flexibilité, modifiez temporairement les politiques en utilisant le paramètre -Scope Process. La cmdlet est la suivante :

      Set-ExecutionPolicy -ExecutionPolicy Bypass -Scope Process
      

Prenez en compte l'Environnement lors de l'Application de la Politique

Les politiques d'exécution PowerShell recommandées varient en fonction de l'environnement.

• Environnement de développement – RemoteSigned reste la politique recommandée. Elle offre une flexibilité pour les développeurs afin d'exécuter des scripts locaux sans les signer et garantit que les scripts téléchargés depuis internet sont signés et fiables. Vous devriez également activer la journalisation des blocs de script pour surveiller l'exécution des scripts.
• Environnement de test/développement – Utilisez la politique RemoteSigned ou AllSigned. RemoteSigned est pratique pour tester un mélange de scripts locaux et externes avec des vérifications d'intégrité de base tandis que AllSigned impose un contrôle plus strict en exigeant que tous les scripts soient signés.
• Environnement de production – Utilisez la politique AllSigned ou Restricted. AllSigned garantit que seuls les scripts signés par un éditeur de confiance sont exécutés. Cependant, Restricted est l'option la plus sécurisée pour les environnements qui ne dépendent pas des scripts PowerShell. Vous devriez également appliquer des politiques via Group Policy pour assurer la cohérence à travers les systèmes.
• Environnement d'automatisation – Bypass est la politique recommandée (uniquement pour des tâches spécifiques). Cela permet aux tâches d'automatisation de s'exécuter sans interruption, en particulier lorsque les politiques sont gérées par d'autres mécanismes, comme la liste blanche d'applications et les pipelines DevOps. Vous devez également sécuriser l'environnement d'automatisation avec des contrôles d'accès appropriés et des audits réguliers.
• Environnements hautement sécurisés – La politique Restricted devrait être votre choix car elle empêche l'exécution de tous les scripts.

Dépannage des erreurs de politique d'exécution

Voici des erreurs courantes liées aux stratégies d'exécution de PowerShell et leurs solutions.

« L'exécution de scripts est désactivée sur ce système »

Vous pourriez recevoir un message d'erreur comme :

Le fichier C:\Temp\Script.ps1 ne peut pas être chargé car l'exécution de scripts est désactivée sur ce système.

Cause: La politique d'exécution est définie sur Restreinte ou Non définie, ce qui empêche l'exécution de tous les scripts.

Solution: Vérifiez la politique actuelle et modifiez-la temporairement pour la session spécifique. Alternativement, vous pouvez changer la politique pour l'utilisateur actuel ou la machine :

Pour modifier la politique pour la session actuelle, utilisez le cmdlet suivant :

      Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass
      

Pour modifier la politique pour l'utilisateur ou la machine actuelle, utilisez le cmdlet suivant :

      Set-ExecutionPolicy -Scope CurrentUser -ExecutionPolicy RemoteSigned
      

« Ne peut pas être chargé car le script n'est pas signé numériquement »

Vous pourriez recevoir un message d'erreur comme :

Le fichier C:\Temp\Script.ps1 ne peut pas être chargé. Le fichier n'est pas signé numériquement.

Cause: La politique d'exécution est définie sur AllSigned ou RemoteSigned, ce qui nécessite que les scripts soient signés.

Solution : Utilisez RemoteSigned au lieu de AllSigned si vous faites confiance aux scripts locaux. Ou vous pouvez temporairement contourner la politique.

« L’accès à la clé de registre est refusé »

Vous pourriez recevoir un message d'erreur comme :

Set-ExecutionPolicy : L'accès à la clé de registre est refusé.

Cause: Vous n'avez pas les autorisations suffisantes pour modifier la politique d'exécution au niveau du scope LocalMachine.

Solution: Exécutez PowerShell en tant qu'administrateur ou configurez la politique pour l'utilisateur actuel en utilisant le cmdlet suivant :

      Set-ExecutionPolicy -Scope CurrentUser -ExecutionPolicy RemoteSigned
      

Conflits de politique d'exécution entre les portées

Des portées différentes (MachinePolicy, UserPolicy, Process, CurrentUser, LocalMachine) ont des politiques contradictoires.

Cause: Une politique plus stricte à un niveau supérieur (comme MachinePolicy) prévaut sur une politique plus permissive à un niveau inférieur (comme LocalMachine).?

Solution: Vérifiez les politiques pour tous les périmètres en utilisant le cmdlet suivant :

      Get-ExecutionPolicy -List
      

Une fois que vous avez ces informations, vous pouvez modifier la politique au niveau approprié ou exécuter des scripts dans une session avec une politique plus permissive.

« Impossible de modifier la stratégie d'exécution car elle est contrôlée par un objet de stratégie de groupe (GPO) »

Ce problème survient lorsque la politique d'exécution est appliquée par la stratégie de groupe, empêchant les modifications locales.

Solution: Consultez votre administrateur système pour modifier la stratégie de groupe. Pour une solution rapide, cependant, vous pouvez temporairement contourner la politique.

« Étendue de la politique non reconnue »

Vous pourriez recevoir un message d'erreur comme :

Set-ExecutionPolicy : La portée spécifiée n'est pas reconnue.

Cause: Une faute de frappe dans le nom de la portée.

Solution: Assurez-vous que la portée est correctement spécifiée comme l'une de ces.

Comportement inattendu dans différentes versions de PowerShell

Les anciennes versions de PowerShell, telles que la 2.0, gèrent différemment les stratégies d'exécution ou manquent de certaines fonctionnalités.

Solution: Mettez à niveau vers la dernière version de PowerShell.

Scripts marqués comme bloqués

Vous pourriez recevoir un message d'erreur comme :

Le fichier ne peut pas être chargé. Le fichier n'est pas signé numériquement ou a été téléchargé depuis internet et est bloqué.

Cause: Le script est marqué comme bloqué car il a été téléchargé depuis internet.

Solution: Débloquez le script à l'aide de la cmdlet suivante :

      Unblock-File -Path C:\Temp\Script.ps1
      

Conclusion : Choisir la bonne stratégie d'exécution PowerShell

Vous devez prendre en compte ces facteurs lors du choix d'une politique d'exécution efficace.

• Identifiez l'environnement avant de choisir une politique d'exécution car différents environnements nécessitent une politique différente. Par exemple, pour les serveurs de production, AllSigned ou RemoteSigned est préférable pour appliquer un certain niveau de vérification des scripts.
• Vous devriez également évaluer vos exigences de sécurité et décider en conséquence. Par exemple, utilisez AllSigned si vous disposez d'un processus de signature de code robuste et souhaitez appliquer un contrôle strict sur l'exécution des scripts. Ou utilisez Restricted pour les systèmes qui ne devraient pas exécuter de scripts.
• Pensez à vos besoins en automatisation. Il serait plus simple d'utiliser la politique Bypass dans des environnements où des scripts sont exécutés automatiquement par des processus de confiance.
• Enfin, évaluez la source des scripts. Si les scripts proviennent de l'intérieur et sont fiables, RemoteSigned offre un équilibre entre utilisabilité et sécurité. Et si les scripts sont un mélange de sources internes et externes, envisagez AllSigned pour une sécurité renforcée.

FAQ

Qu'est-ce que la variable $env:psexecutionpolicypreference ?

La variable d'environnement $env:PSExecutionPolicyPreference est utilisée dans PowerShell pour remplacer temporairement la politique d'exécution pour une seule session sans modifier les politiques d'exécution à l'échelle du système ou spécifiques à l'utilisateur. Lorsque vous fermez la session, le changement est perdu.

Vous pouvez utiliser $env:psexecutionpolicypreference de la manière suivante :

• Attribuez une valeur à $env:PSExecutionPolicyPreference pour modifier temporairement la politique d'exécution, comme indiqué ci-dessous :

$env:PSExecutionPolicyPreference = “Bypass”

Après cela, les scripts s'exécuteront sans restrictions pendant la durée de la session.

• Vérifiez la valeur actuelle de cette variable, comme indiqué ci-dessous :

$env:PSExecutionPolicyPreference

• Supprimez la politique temporaire et revenez au comportement par défaut, comme indiqué ci-dessous :

Remove-Item Env:PSExecutionPolicyPreference