Partager via

Utiliser App Control pour sécuriser PowerShell

  • Article

Windows 10 comprend deux technologies, App Control for Business et AppLocker, que vous pouvez utiliser pour contrôler les applications. Ils vous permettent de créer une expérience de verrouillage pour vous aider à sécuriser votre environnement PowerShell.

AppLocker repose sur les fonctionnalités de contrôle d’application des stratégies de restriction logicielle. AppLocker vous permet de créer des règles pour autoriser ou refuser des applications à des utilisateurs ou groupes spécifiques. Vous identifiez les applications sur la base des propriétés uniques des fichiers.

Application Control for Business, introduit dans Windows 10 en tant que Windows Defender Application Control (WDAC), vous permet de contrôler quels pilotes et applications sont autorisés à s’exécuter sur Windows.

Détection de stratégie de verrouillage

PowerShell détecte les stratégies à l’échelle du système AppLocker et App Control for Business. AppLocker n’a pas le moyen d’interroger l’état d’application de la stratégie. Pour détecter si une stratégie de contrôle d’application à l’échelle du système est appliquée par AppLocker, PowerShell crée deux fichiers temporaires et des tests s’ils peuvent être exécutés. Les noms de fichiers utilisent le format de nom suivant :

  • $env:TEMP/__PSAppLockerTest__<random-8dot3-name>.ps1
  • $env:TEMP/__PSAppLockerTest__<random-8dot3-name>.psm1

App Control for Business est le système de contrôle d’application préféré pour Windows. App Control fournit des API qui vous permettent de découvrir la configuration de la stratégie. App Control est conçu comme une fonctionnalité de sécurité sous les critères de maintenance définis par le Centre de réponse à la sécurité Microsoft (MSRC). Pour plus d’informations, consultez Contrôles d’application pour la disponibilité des fonctionnalités Windows et App Control et AppLocker.

Remarque

Lorsque vous choisissez entre App Control ou AppLocker, nous vous recommandons d’implémenter le contrôle d’application à l’aide de App Control for Business plutôt que d’AppLocker. Microsoft n’investit plus dans AppLocker. Même si AppLocker peut continuer à recevoir des correctifs de sécurité, il ne recevra pas d’améliorations des fonctionnalités.

Application de la stratégie de contrôle d’application

Lorsque PowerShell s’exécute sous une stratégie De contrôle d’application, son comportement change en fonction de la stratégie de sécurité définie. Sous une stratégie App Control, PowerShell exécute des scripts et des modules approuvés autorisés par la stratégie en FullLanguage mode. Tous les autres scripts et blocs de script ne sont pas approuvés et s’exécutent en mode ConstrainedLanguage. PowerShell génère des erreurs lorsque les scripts non approuvés tentent d’effectuer des actions qui ne sont pas autorisées en mode ConstrainedLanguage. Il peut s’avérer difficile de savoir pourquoi un script ne parvient pas à s’exécuter correctement en mode ConstrainedLanguage.

Audit de stratégie App Control

PowerShell 7.4 a ajouté une nouvelle fonctionnalité pour prendre en charge les stratégies App Control en mode Audit . En mode audit, PowerShell exécute les scripts non approuvés en mode ConstrainedLanguage sans erreur, mais par contre, il enregistre les messages dans le journal des événements. Les messages de journal décrivent les restrictions qui s’appliqueraient si la stratégie était en mode Appliquer.

Historique des modifications

Windows PowerShell 5.1 était la première version de PowerShell à prendre en charge App Control. Les fonctionnalités de sécurité de App Control et AppLocker s’améliorent avec chaque nouvelle version de PowerShell. Les sections suivantes décrivent l'évolution de cette prise en charge dans chaque version de PowerShell. Les modifications sont cumulatives, de sorte que les fonctionnalités décrites dans les versions ultérieures incluent celles des versions antérieures.

Modifications dans PowerShell 7.4

Sur Windows, lorsque PowerShell s’exécute sous une stratégie App Control, son comportement change en fonction de la stratégie de sécurité définie. Sous une stratégie App Control, PowerShell exécute des scripts et des modules approuvés autorisés par la stratégie en FullLanguage mode. Tous les autres scripts et blocs de script ne sont pas approuvés et s’exécutent en mode ConstrainedLanguage. PowerShell lève des erreurs lorsque les scripts non approuvés tentent d’effectuer des actions non autorisées. Il est difficile de savoir pourquoi un script ne parvient pas à s’exécuter correctement en mode ConstrainedLanguage.

PowerShell 7.4 prend désormais en charge les stratégies App Control en mode Audit . En mode audit, PowerShell exécute les scripts non approuvés en mode ConstrainedLanguage, mais journalise les messages dans le journal des événements au lieu de lever des erreurs. Les messages de journal décrivent les restrictions qui s’appliqueraient si la stratégie était en mode Appliquer.

Modifications dans PowerShell 7.3

  • PowerShell 7.3 prend désormais en charge la possibilité de bloquer ou d’autoriser les fichiers de script PowerShell via l’API App Control.

Modifications dans PowerShell 7.2

  • Il existait un scénario corner case (hors utilisation normale) dans AppLocker où vous aviez seulement des règles de Refus et où le mode contraint n’était pas utilisé pour appliquer la stratégie qui vous autorisait à contourner la stratégie d’exécution. À compter de PowerShell 7.2, un changement a été effectué pour garantir la prévalence des règles AppLocker sur une commande Set-ExecutionPolicy -ExecutionPolicy Bypass.

  • PowerShell 7.2 interdit désormais l’utilisation de la Add-Type cmdlet dans une NoLanguage session PowerShell en mode sur un ordinateur verrouillé.

  • PowerShell 7.2 interdit désormais aux scripts d’utiliser des objets COM dans des conditions de verrouillage du système AppLocker. Les applets de commande qui utilisent COM ou DCOM en interne ne sont pas affectées.

Pour aller plus loin