Application de script avec App Control for Business

Vue d’ensemble de l’application des scripts

Par défaut, l’application des scripts est activée pour toutes les stratégies de contrôle des applications, sauf si l’option 11 Désactivé : Application des scripts est définie dans la stratégie. L’application du script App Control implique une liaison entre un hôte de script compatible, tel que PowerShell, et App Control. Toutefois, l’hôte de script gère le comportement réel d’application. Certains hôtes de scripts, comme l’hôte d’application Microsoft HTML (mshta.exe), bloquent toute exécution de code si une stratégie UMCI de contrôle d’application est active. La plupart des hôtes de script demandent d’abord à App Control si un script doit être autorisé à s’exécuter en fonction des stratégies de contrôle d’application actuellement actives. L’hôte de script bloque, autorise ou modifie ensuite l’exécution du script pour protéger au mieux l’utilisateur et l’appareil.

La validation des scripts signés est effectuée à l’aide de l’API WinVerifyTrust. Pour réussir la validation, la racine de signature doit être présente dans le magasin racine approuvé sur l’appareil et votre stratégie de contrôle d’application doit l’autoriser. Ce comportement est différent de la validation du contrôle d’application pour les fichiers exécutables, qui ne nécessite pas l’installation du certificat racine.

Préparer des scripts pour le contrôle d’application

Exiger des éditeurs de scripts qu’ils signent chaque script, module, manifeste et fichier dépendant chargé par l’application. La signature du script de point d’entrée uniquement n’est pas suffisante lorsqu’il importe des modules, des sources de points d’autres fichiers ou lance des scripts d’assistance.

Les scripts ne contiennent normalement pas de ressources de version PE (Portable Executable). Ajoutez des métadonnées authentifiées à chaque signature de script afin que le contrôle d’application puisse créer des règles qui identifient le script par son nom de fichier d’origine, son produit et sa version. Utilisez des valeurs stables entre les versions et évitez les noms génériques partagés par des scripts non liés.

Pour les commandes de signature et les mappages de métadonnées à règle, consultez Utiliser des métadonnées signées pour les scripts et les fichiers non-PE.

Lorsque vous acceptez les scripts dans votre environnement :

• Vérifiez la signature incorporée ou du catalogue avant le déploiement.
• Vérifiez que la signature est liée à une racine dans le magasin racine approuvé de l’appareil.
• Vérifiez que la stratégie de contrôle d’application autorise le signataire et l’étendue de fichier prévus.
• Testez l’installation, l’importation, le dot-sourcing, les fonctionnalités facultatives, les mises à jour, la réparation et la suppression en mode audit.
• Examinez les événements 8028, 8029, 8037 et 8038 dans le journal AppLocker - MSI et script .
• Exiger une nouvelle signature ou un nouveau catalogue chaque fois que le script change.

App Control partage le journal des événements AppLocker - MSI et Script pour tous les événements d’application de script. Chaque fois qu’un hôte de script demande à App Control si un script doit être autorisé, un événement est enregistré avec la réponse App Control renvoyée à l’hôte de script. Pour plus d’informations sur les événements d’application des scripts App Control, consultez Présentation des événements App Control.

Hôtes de script compatibles qui font partie de Windows

PowerShell

Vos stratégies de contrôle d’application doivent autoriser tous les scripts PowerShell (.ps1), modules (.psm1) et manifestes (.psd1) pour qu’ils s’exécutent avec les droits de langue complète.

Vos stratégies de contrôle des applications doivent également autoriser les modules dépendants chargés par un module autorisé, et les fonctions de module doivent être exportées explicitement par nom lorsque le contrôle d’application est appliqué. Les modules qui ne spécifient aucune fonction exportée (aucune liste de noms d’exportation) se chargent toujours, mais aucune fonction de module n’est accessible. Les modules qui utilisent des caractères génériques (*) dans leur nom ne seront pas chargés.

Tout script PowerShell non autorisé par la stratégie App Control fonctionne toujours, mais uniquement en mode Langage contraint.

Le point-sourcing PowerShell n’est pas recommandé. Au lieu de cela, les scripts doivent utiliser des modules PowerShell pour fournir des fonctionnalités communes. Si un fichier de script autorisé tente d’exécuter des fichiers de script source, ces fichiers de script doivent également transmettre la stratégie.

App Control place le PowerShell interactif en mode de langage contraint si une stratégie UMCI de contrôle d’application est appliquée et si une stratégie de contrôle d’application active active l’application du script, même si cette stratégie est en mode audit. Pour exécuter un PowerShell interactif avec des droits de langue complète, vous devez désactiver l’application des scripts pour toutes les stratégies.

Pour plus d’informations, consultez À propos des modes de langage et du mode de langage contraint.

VBscript, cscript et jscript

Vos stratégies de contrôle d’application doivent autoriser l’exécution de tous les scripts à l’aide de l’hôte de script Windows (wscript.exe) ou de l’hôte de script basé sur la console Microsoft (cscript.exe). Si ce n’est pas le cas, le script est bloqué.

Microsoft HTML Application Host (MSHTA) et MSXML

Toute exécution de code à l’aide de MSHTA ou MSXML est bloquée si une stratégie de contrôle d’application avec application de script est active, même si cette stratégie est en mode audit.

Objets COM

Le contrôle d’application applique en outre une liste d’autorisation restreinte pour les objets COM que votre stratégie de contrôle d’application peut étendre ou restreindre davantage. L’application des objets COM n’est pas affectée par l’option11 Disabled :Script Enforcement. Pour plus d’informations sur l’autorisation ou le refus des objets COM, consultez Autoriser l’inscription d’objets COM.

Scripts qui ne sont pas directement contrôlés par le contrôle d’application

Le contrôle d’application ne contrôle pas directement le code exécuté via le processeur de commande Windows (cmd.exe), y compris les fichiers de script .bat/.cmd. Toutefois, tout ce qu’un script de traitement par lots tente d’exécuter est soumis au contrôle du contrôle d’application. Si vous n’avez pas besoin d’exécuter cmd.exe, il est recommandé de le bloquer purement et simplement ou de l’autoriser uniquement par exception en fonction du processus d’appel. Voir Utiliser une stratégie App Control for Business pour contrôler des plug-ins, des compléments et des modules spécifiques.

Le contrôle d’application ne contrôle pas les scripts exécutés via un hôte de script non compatible, tel que de nombreux moteurs tiers Java ou Python. Si votre stratégie de contrôle des applications permet à un hôte de script non compatible de s’exécuter, vous autorisez implicitement l’exécution de tous les scripts via cet hôte. Pour les hôtes de script non-Microsoft, vous devez vérifier auprès du fournisseur de case activée si ses hôtes de script sont compatibles avec la stratégie de contrôle d’application.