/
/

Comprendre les politiques d’exécution PowerShell

par Team Ninja
powershell execution policies blog banner

Points clés

PowerShell, un outil incontournable pour l’administration, le scripting et l’automatisation

  • Les politiques d’exécution PowerShell sont une fonction de protection des utilisateurs sous Windows qui encadre la façon dont les scripts peuvent s’exécuter. Elles aident à limiter l’exécution accidentelle de code non approuvé, sans pour autant constituer une frontière de sécurité.
  • Les politiques d’exécution PowerShell disponibles sont AllSigned, RemoteSigned, Restricted, Unrestricted, Bypass et Undefined.
  • Les politiques d’exécution peuvent s’appliquer à plusieurs portées, dont MachinePolicy, UserPolicy, Process, CurrentUser et LocalMachine, ce qui permet aux administrateurs de maîtriser la façon dont elles sont appliquées aux utilisateurs, aux sessions et aux systèmes.
  • Les politiques moins restrictives, comme Unrestricted et Bypass, offrent plus de souplesse et de rapidité, mais augmentent le risque de sécurité : il est donc essentiel de trouver un équilibre entre facilité d’utilisation, type d’environnement et exigences de sécurité de l’entreprise.
  • Les bonnes pratiques en matière de politique d’exécution PowerShell consistent à retenir la politique effective la moins permissive, à imposer la signature des scripts lorsque c’est pertinent, à documenter l’usage des politiques et à réexaminer régulièrement les configurations.
  • Les problèmes courants liés aux politiques d’exécution concernent souvent les autorisations, les conflits de portée, les scripts non signés ou bloqués, ou encore l’application par stratégie de groupe. Ils se résolvent généralement en élevant les privilèges, en signant ou en débloquant les scripts, en vérifiant la portée effective et en contrôlant les paramètres de stratégie de groupe ou des logiciels de sécurité.

Développé par Microsoft, PowerShell s’est imposé comme une référence moderne pour l’administration, le scripting et l’automatisation sous Windows. En associant une interface en ligne de commande à un langage de script, PowerShell a profondément transformé la gestion des environnements Windows.
Reposant sur le framework .NET, PowerShell s’intègre naturellement aux technologies Microsoft grâce à des commandes concises, appelées cmdlets, qui permettent d’interagir avec les composants du système, de manipuler des données et d’automatiser les fonctions administratives. Cette approche basée sur les scripts permet de simplifier les tâches, de gagner en efficacité et d’automatiser les opérations courantes. PowerShell prend également en charge la gestion des événements, la planification des tâches et l’administration à distance, ce qui en fait une solution complète pour les administrateurs informatiques, les professionnels de la cybersécurité et les spécialistes du scripting.

Ce guide est consacré aux politiques d’exécution PowerShell : il explique leur importance, leur fonctionnement, leur gestion, leur incidence sur la sécurité du système et les bonnes pratiques associées. L’objectif est de comprendre comment ces politiques d’exécution encadrent l’exécution des scripts et participent à une approche de défense en profondeur dans les environnements Windows.

Exécutez des scripts PowerShell, appliquez vos politiques et gagnez du temps avec les solutions d’automatisation NinjaOne.

Voir une démo dès maintenant

Les politiques d’exécution PowerShell en bref

Les politiques d’exécution PowerShell constituent un mécanisme de protection des utilisateurs dans les environnements Windows, et non une frontière de sécurité. Elles déterminent le niveau de confiance accordé aux scripts avant leur exécution. Ces politiques visent à trouver un équilibre entre la possibilité d’exécuter des scripts à des fins légitimes et la réduction des risques de sécurité associés. En appliquant une politique d’exécution, les administrateurs peuvent imposer un environnement de scripting cohérent et sécurisé, ce qui limite les risques de compromission du système par des scripts malveillants.

Voici les différents types de politiques d’exécution disponibles :

  • AllSigned : avec cette politique, tous les scripts, y compris ceux créés localement, doivent être signés numériquement par un éditeur approuvé pour pouvoir s’exécuter. Cette approche garantit que seuls les scripts autorisés peuvent s’exécuter, mais elle laisse subsister le risque d’exécuter un script malveillant qui aurait été signé.
  • Bypass : cette politique autorise l’exécution de n’importe quel script sans restriction. Elle doit être utilisée avec une extrême prudence, voire pas du tout, car elle peut exposer les systèmes à des risques de sécurité en permettant l’exécution de scripts non signés et non vérifiés.
  • RemoteSigned : cette politique exige que les scripts téléchargés depuis Internet (identifiés par un Identifier) soient signés numériquement avant leur exécution, tandis que les scripts créés localement peuvent s’exécuter sans signature.
  • Restricted : cette politique empêche l’exécution des fichiers de script, mais ne bloque pas toutes les formes d’exécution de code PowerShell.
  • Undefined : cette politique indique qu’aucune politique d’exécution n’est définie pour la portée concernée. La politique effective est alors déterminée par d’autres portées ou par la valeur par défaut de la plateforme.
  • Unrestricted : cette politique autorise l’exécution des scripts sans aucune restriction, qu’ils soient locaux ou issus d’Internet. Pratique pour le développement et les tests, elle ne doit pas être utilisée en production en raison des risques de sécurité importants qu’elle représente.

Bien comprendre ces politiques d’exécution permet aux administrateurs et aux professionnels de la sécurité d’adopter l’approche la plus adaptée aux exigences de sécurité de leurs systèmes.
Les sections suivantes abordent la gestion des politiques d’exécution PowerShell, les bonnes pratiques et leurs implications.

Gérer les politiques d’exécution PowerShell

Définir et modifier correctement les politiques d’exécution PowerShell est essentiel pour mettre en place un environnement de scripting sécurisé. Les administrateurs peuvent utiliser la cmdlet Set-ExecutionPolicy pour configurer ces politiques. En comprenant les risques et les avantages des différentes configurations, ils peuvent prendre des décisions éclairées, en cohérence avec leurs objectifs de sécurité.
Le premier point à considérer est la portée de la politique d’exécution, avec les options suivantes :

  • MachinePolicy : cette portée est définie par une stratégie de groupe et ne peut pas être remplacée par les paramètres locaux de politique d’exécution.
  • UserPolicy : cette portée est définie par une stratégie de groupe et applique la politique d’exécution aux utilisateurs d’une machine donnée. Elle est particulièrement utile pour maintenir un environnement de scripting homogène pour tous les utilisateurs.
  • Process : à cette portée, les politiques d’exécution s’appliquent uniquement à la session PowerShell en cours. Elle offre un contrôle plus granulaire de l’exécution des scripts selon les besoins.
  • CurrentUser : cette portée applique la politique d’exécution à la session de l’utilisateur actuel. Elle ne nécessite aucune élévation de privilèges.
  • LocalMachine : il s’agit de la portée par défaut, qui s’applique à tous les utilisateurs d’une machine. Elle est remplacée par les portées Process et CurrentUser, ainsi que par toute portée définie par une stratégie de groupe.

Toute modification de la politique d’exécution a une incidence directe sur la sécurité du système et sur l’exécution des scripts. Une politique plus restrictive, comme « Restricted » ou « AllSigned », renforce la sécurité en réduisant le risque d’exécution de scripts non autorisés ou malveillants. Elle peut toutefois imposer des étapes supplémentaires, comme la signature des scripts, source de charge administrative.
Une politique plus souple, comme « Unrestricted » ou « Bypass », facilite l’exécution des scripts en supprimant les obstacles, mais au prix d’une exposition potentielle du système à des risques de sécurité. Ces politiques doivent être adoptées avec précaution, uniquement dans des environnements contrôlés et pour des durées limitées, ou pendant les phases de développement et de test. Les administrateurs doivent tenir compte des exigences de sécurité de leur entreprise et des besoins spécifiques de leurs utilisateurs lorsqu’ils choisissent ou modifient une politique d’exécution. Trouver le bon équilibre entre sécurité et fonctionnalité permet de maintenir un environnement de scripting PowerShell sûr.
Dans les sections suivantes, nous examinons les bonnes pratiques liées aux politiques d’exécution PowerShell, les problèmes fréquemment rencontrés lors de leur gestion et leur cohérence avec les règles de sécurité de l’entreprise. Ces éléments aideront les administrateurs et les professionnels de la sécurité à prendre des décisions éclairées pour obtenir un environnement de scripting sûr et efficace.

Bonnes pratiques pour les politiques d’exécution PowerShell

Pour choisir une politique d’exécution PowerShell adaptée à chaque environnement, la bonne pratique consiste à prendre en compte la nature des scripts qui seront exécutés, le niveau de sécurité requis et le rôle des utilisateurs. Par exemple :

  • Environnement de production : en production, il est prudent d’adopter une politique plus restrictive comme « AllSigned » ou « RemoteSigned ». Les scripts sont ainsi signés et authentifiés avant leur exécution, ce qui réduit le risque de code non autorisé ou malveillant.
  • Environnement de développement : dans un environnement de développement, une politique plus souple comme « Bypass » ou « Unrestricted » peut faciliter les tests et le dépannage. Ces politiques ne doivent toutefois jamais être reprises en production.

Gérer et modifier les politiques en toute sécurité

Pour les administrateurs informatiques, les professionnels de la cybersécurité et toute personne impliquée dans l’administration Windows et le scripting PowerShell, il est essentiel de savoir gérer ces politiques en toute sécurité.
Voici les bonnes pratiques pour gérer et modifier les politiques d’exécution PowerShell :

  • Documenter les politiques d’exécution : assurez-vous que les administrateurs et les utilisateurs comprennent les implications des différentes politiques d’exécution. Rédigez une documentation claire indiquant quelles politiques conviennent à quels scénarios.
  • Imposer la signature des scripts : pour les politiques plus restrictives comme « AllSigned » et « RemoteSigned », imposez la signature des scripts à l’aide de signatures numériques. Cela ajoute un niveau de sécurité supplémentaire en garantissant l’authenticité des scripts.
  • Choisir la portée la moins permissive : déterminez la portée appropriée pour définir les politiques d’exécution. Tenez compte de l’impact sur les utilisateurs et les processus dans les différentes portées, mais aussi des conséquences sur la sécurité du système et de la cohérence avec la politique de sécurité. La bonne pratique consiste à retenir la politique qui offre le moindre privilège tout en assurant la fonction requise.
  • Réexaminer les politiques : passez régulièrement en revue et auditez les politiques d’exécution de tout l’environnement. Vérifiez qu’elles restent conformes aux exigences de sécurité et aux règles internes.

Problèmes courants et solutions

La définition des politiques d’exécution PowerShell peut créer des difficultés qui affectent le fonctionnement des scripts et du système. Voici quelques problèmes fréquents :

  • Accès refusé : les utilisateurs peuvent rencontrer des erreurs « Accès refusé » lorsqu’ils tentent de modifier les politiques d’exécution sans disposer de privilèges administratifs.
  • Scripts bloqués : les politiques plus restrictives comme « AllSigned » peuvent empêcher l’exécution de scripts non signés ou mal signés, ce qui génère de la frustration chez les utilisateurs.
  • Scripts non approuvés : des scripts provenant d’Internet peuvent être bloqués par des politiques comme « RemoteSigned », même lorsqu’ils sont sûrs et légitimes.

Pour résoudre ces problèmes et garantir la bonne exécution des scripts, suivez ces étapes de dépannage :

  • Élever les privilèges : vérifiez que vous disposez de privilèges administratifs lorsque vous modifiez les politiques d’exécution. Lancez PowerShell avec des droits d’administrateur en effectuant un clic droit puis en sélectionnant « Exécuter en tant qu’administrateur ».
  • Signature des scripts : avec des politiques comme « AllSigned », veillez à ce que les scripts soient correctement signés avec des signatures numériques valides. Cela évite les fausses erreurs « Accès refusé ».
  • Approuver les éditeurs : pour les politiques « AllSigned » et « RemoteSigned », établissez une relation de confiance avec les éditeurs en important leurs certificats dans le magasin de certificats.
  • Débloquer les fichiers : si un fichier de script téléchargé depuis Internet est bloqué, débloquez-le avec la cmdlet « Unblock-File ».
  • Vérifier les problèmes de portée : gardez à l’esprit la portée de la politique d’exécution. En cas de problème, vérifiez que la politique est définie au bon niveau de portée.
  • Vérifier les restrictions liées aux stratégies de groupe : dans les environnements de domaine, les stratégies de groupe peuvent imposer des politiques d’exécution spécifiques. Contrôlez les paramètres de stratégie de groupe qui s’appliquent au système, ainsi que son emplacement.
  • Utiliser la communication à distance PowerShell : si des politiques « Restricted » ou « AllSigned » bloquent l’exécution locale, la communication à distance PowerShell exécute les scripts selon la politique d’exécution effective et les contrôles de sécurité du système distant.
  • Vérifier les logiciels de sécurité : certains logiciels de sécurité peuvent interférer avec l’exécution des scripts. Désactivez-les temporairement ou ajustez leurs paramètres pour effectuer le diagnostic.
  • Rechercher les conflits : soyez attentif aux conflits possibles entre les paramètres locaux et ceux des stratégies de groupe. Veillez à la cohérence de l’application de la politique d’exécution.

Comme toujours, une démarche par élimination permet de remonter à la source du problème. Si un script qui échoue fonctionne avec des droits élevés, examinez de plus près les autorisations. S’il fonctionne en contournant la politique, vérifiez les restrictions de la machine, et ainsi de suite. En traitant ces problèmes courants et en suivant les étapes de dépannage ci-dessus, les administrateurs et les professionnels peuvent gérer efficacement les politiques d’exécution PowerShell, éviter les blocages lors de l’exécution des scripts et maintenir un environnement de scripting sécurisé.

Cohérence avec les règles de sécurité de l’entreprise

Aligner les politiques d’exécution Windows PowerShell sur les règles de sécurité de l’entreprise est indispensable pour maintenir un environnement de scripting sûr et maîtrisé. Les entreprises ont souvent des exigences et des politiques de sécurité précises qui définissent la manière dont les scripts doivent être exécutés. En alignant les politiques d’exécution sur ces règles, elles garantissent la cohérence, réduisent les risques et renforcent leur posture de sécurité globale.

L’importance des audits et des revues de politique réguliers

Des audits et des revues de politique réguliers permettent de s’assurer que les politiques d’exécution restent efficaces et à jour. À mesure que les besoins de l’entreprise évoluent et que les menaces changent, les politiques d’exécution peuvent nécessiter des ajustements.
Des revues régulières permettent aux entreprises de :

  • S’adapter à un paysage des menaces mouvant : la cybersécurité est un domaine en constante évolution. Des revues régulières aident les entreprises à anticiper les nouvelles menaces et à ajuster leurs politiques en conséquence.
  • Évaluer l’efficacité des politiques : les entreprises peuvent déterminer si les politiques d’exécution en place réduisent effectivement les risques ou si des ajustements sont nécessaires.
  • Garantir la conformité : les exigences de conformité peuvent évoluer dans le temps. Des revues régulières permettent de vérifier que les politiques d’exécution respectent les normes de conformité en vigueur.
  • Repérer les conflits de politiques : dans les environnements complexes, des conflits de politiques ou des effets indésirables peuvent survenir. Des audits réguliers aident à les identifier et à les résoudre.
  • Maintenir la cohérence : avec le temps, de nouveaux scripts et de nouveaux utilisateurs peuvent apparaître. Les audits permettent de vérifier que les politiques d’exécution sont appliquées de manière homogène dans toute l’entreprise.
  • Limiter les scripts non autorisés : des revues régulières aident à détecter et à traiter les scripts non autorisés ou malveillants qui pourraient passer inaperçus en production.

Avec une stratégie de politiques d’exécution bien définie et appliquée de façon cohérente, les entreprises peuvent exploiter toute la puissance du scripting PowerShell tout en conservant une posture de sécurité solide.

NinjaOne permet aux professionnels de l’informatique d’exécuter des commandes PowerShell à distance sur les appareils Windows, macOS et Linux.

Commencez un essai gratuit dès aujourd’hui

Les politiques d’exécution PowerShell, un pilier de la sécurité du système

Utilisées à bon escient, les politiques d’exécution PowerShell constituent un contrôle opérationnel important au sein d’une stratégie de sécurité plus large et d’une administration Windows efficace. Ces politiques jouent le rôle de gardiens de l’exécution des scripts : elles aident les administrateurs à limiter l’exécution accidentelle de scripts non approuvés et à maintenir une cohérence opérationnelle. En fixant des limites à l’exécution des scripts, les entreprises réduisent le risque qu’un code malveillant ou involontaire compromette leurs systèmes. L’éventail des politiques d’exécution disponibles, chacune conçue pour un cas d’utilisation de sécurité précis, illustre le contrôle précis dont disposent les administrateurs sur le comportement d’exécution des scripts.

Les politiques d’exécution PowerShell vont au-delà de simples règles et paramètres de configuration : elles traduisent un engagement en faveur d’opérations informatiques cohérentes et sécurisées. En appliquant les bonnes pratiques présentées ici, vous êtes sur la bonne voie pour obtenir un environnement Windows sûr, efficace et résilient.

Découvrez également le guide vidéo Comprendre les politiques d’exécution PowerShell.

FAQs

Oui. Les politiques d’exécution s’appliquent toujours lorsque des scripts sont lancés par des outils comme le Planificateur de tâches, des plateformes RMM ou des services, sauf si l’hôte les contourne explicitement. La politique effective dépend du contexte d’exécution, de la portée et de toute application par stratégie de groupe sur le système.

Oui. Elles peuvent être contournées à l’aide d’options en ligne de commande, de commandes encodées ou d’hôtes d’exécution alternatifs : c’est pourquoi elles ne doivent pas être considérées comme une frontière de sécurité. Elles servent avant tout de garde-fou contre l’exécution accidentelle ou non autorisée de scripts, et non de défense contre des menaces actives.

Les politiques d’exécution ne bloquent pas le chargement des modules de la même manière qu’elles bloquent les fichiers de script, en particulier pour les modules installés depuis des emplacements approuvés. En revanche, les scripts contenus dans les modules peuvent rester soumis aux contrôles de politique selon la façon dont ils sont appelés.

Cela se produit généralement lorsque les politiques d’exécution sont imposées par une stratégie de groupe à la portée MachinePolicy ou UserPolicy, ce qui remplace les paramètres locaux. Vous pouvez le vérifier en exécutant Get-ExecutionPolicy -List afin d’afficher la politique effective et son origine.

Non. Les politiques d’exécution ne sont appliquées que sur les systèmes Windows. Sur macOS et Linux, PowerShell s’appuie sur les autorisations de fichiers du système d’exploitation pour contrôler l’exécution des scripts.

You might also like

Prêt à simplifier les aspects les plus complexes de l'informatique et de la sécurité ?