Déployer AppLocker : scripts, installeurs, apps empaquetées

Le guide pilier App Control recommande App Control for Business comme socle pour tout l'appareil et réserve AppLocker à ce qu'il fait encore bien : les règles par utilisateur et par groupe, les gains rapides sur les systèmes où App Control n'est pas prêt, et le blocage des points de lancement classiques accessibles en écriture par les utilisateurs. Ce guide présente le déploiement complet d'AppLocker, collection par collection, avec les données d'audit qui l'empêchent de paralyser l'activité.

AppLocker n'est pas obsolète. Il reçoit des correctifs de sécurité mais plus de nouvelles fonctionnalités, et il est appliqué en mode utilisateur par le service Application Identity. Gardez ces deux faits en tête : il est facile à déployer, et facile à contourner pour quiconque dispose de droits d'administration ; il va donc de pair avec la suppression des droits d'administrateur local.

Les cinq collections de règles

Chaque collection a son propre paramètre d'application. Une collection sans règle n'est pas appliquée, et une collection comportant des règles mais sans paramètre d'application est appliquée. Ce second comportement surprend : définissez toujours le mode explicitement.

Il existe trois types de règles : éditeur (signataire, produit, nom de fichier, version), chemin et hash de fichier. Préférez les règles d'éditeur ; elles survivent aux mises à jour. N'utilisez les règles de chemin que pour des dossiers dans lesquels les utilisateurs standard ne peuvent pas écrire.

Étape 1 : prérequis

• Service Application Identity en démarrage Automatic. Utilisez Computer Configuration > Policies > Windows Settings > Security Settings > System Services > Application Identity. Sur les versions actuelles de Windows, vous ne pouvez pas modifier son type de démarrage dans la console Services : la stratégie est donc la méthode fiable.
• Édition prise en charge. Historiquement, AppLocker n'était appliqué que sur les éditions Entreprise, Éducation et Server. Depuis KB5024351, Windows 10 2004 et versions ultérieures ainsi que toutes les versions de Windows 11 l'appliquent sur toutes les éditions, y compris Professionnel. Sur les versions plus anciennes (dont Windows Server 2019), les stratégies distribuées par stratégie de groupe ne fonctionnent que sur les éditions Entreprise et Server, tandis que les stratégies distribuées par MDM fonctionnent sur toutes les éditions.
• Une UO pilote avec un ensemble d'utilisateurs représentatif : finance, développeurs, support et une borne partagée si vous en avez une.

Les règles AppLocker se trouvent sous Computer Configuration > Policies > Windows Settings > Security Settings > Application Control Policies > AppLocker. Sur les appareils gérés par Intune, la stratégie AppLocker est distribuée via le CSP AppLocker sous forme de paramètres OMA-URI personnalisés contenant le XML de la collection de règles, un nœud par collection : ./Vendor/MSFT/AppLocker/ApplicationLaunchRestrictions/{Grouping}/EXE/Policy, avec MSI, Script, StoreApps et DLL à la place de EXE pour les autres collections ({Grouping} est un nom unique, idéalement un GUID).

Étape 2 : démarrer en mode audit avec des valeurs par défaut saines

Dans le nœud AppLocker, ouvrez Configure rule enforcement et réglez les règles Executable, Windows Installer, Script et Packaged app sur Audit only. Puis, pour chaque collection, faites un clic droit et choisissez Create Default Rules. Les règles par défaut sont un point de départ, pas une conception ; deux modifications s'imposent immédiatement.

Fermer les dossiers accessibles en écriture sous %WINDIR%. La règle par défaut « Everyone peut tout exécuter sous %WINDIR% » inclut des sous-dossiers dans lesquels les utilisateurs standard peuvent écrire, ce qui en fait des rampes de lancement. Exemples courants :

• C:\Windows\Tasks
• C:\Windows\Temp
• C:\Windows\tracing
• C:\Windows\System32\spool\drivers\color
• C:\Windows\System32\Tasks

Ajoutez-les comme exceptions aux règles de chemin %WINDIR% des exécutables et des scripts. Recherchez-en d'autres sur votre build avec AccessChk de Sysinternals pour les groupes Users et Everyone, car la liste varie selon la version et les logiciels installés.

Refuser aux utilisateurs standard les binaires de contournement connus. Les règles par défaut autorisent tous les binaires Windows signés, y compris ceux qui exécutent du code arbitraire : mshta.exe, wscript.exe, cscript.exe, regsvr32.exe, msbuild.exe et installutil.exe sont des exemples fréquents. Ajoutez des règles de refus par éditeur pour ceux dont vos utilisateurs n'ont pas besoin, ciblées sur les utilisateurs standard plutôt que sur Everyone afin que l'outillage d'administration continue de fonctionner.

Étape 3 : collecter les données d'audit et en tirer des règles

Laissez le pilote en audit pendant deux à quatre semaines, assez longtemps pour couvrir les traitements de fin de mois. AppLocker journalise dans Applications and Services Logs > Microsoft > Windows > AppLocker :

Générez des règles candidates directement à partir des événements d'audit sur un appareil pilote :

Get-AppLockerFileInformation -EventLog -EventType Audited `
  -LogPath "Microsoft-Windows-AppLocker/EXE and DLL" |
  New-AppLockerPolicy -RuleType Publisher, Hash -User Everyone -Optimize -Xml |
  Out-File .\candidate-exe.xml

Ou à partir d'un dossier de référence :

Get-AppLockerFileInformation -Directory "C:\Program Files (x86)\Contoso" -Recurse |
  New-AppLockerPolicy -RuleType Publisher, Hash -User Everyone -Optimize -Xml |
  Out-File .\contoso.xml

Relisez chaque candidat avant de l'importer. Les données d'audit d'un utilisateur qui a lancé un téléchargement quelconque produiront une règle autorisant ce téléchargement. Ciblez les règles sur des groupes quand cela a du sens : les outils d'ingénierie pour GG-Engineering, pas pour Everyone.

Importez les règles relues dans la GPO avec Set-AppLockerPolicy -XmlPolicy .\contoso.xml -Ldap "LDAP://CN={GPO-GUID},CN=Policies,CN=System,DC=corp,DC=example" -Merge.

Étape 4 : scripts, installeurs et applications empaquetées

Scripts. Appliquer les règles de scripts a un effet de bord important : PowerShell s'exécute en mode de langage contraint pour les scripts et les sessions interactives que la stratégie n'autorise pas. Cela bloque l'essentiel du PowerShell offensif, mais casse aussi les scripts d'administration lancés depuis des dossiers accessibles en écriture par les utilisateurs. Stockez les scripts d'administration dans un chemin réservé aux administrateurs ou signez-les, et autorisez explicitement les scripts d'ouverture de session : ajoutez des règles de chemin pour \\corp.example\SYSVOL\* et \\corp.example\NETLOGON\* (uniquement si ces partages ne sont accessibles en écriture qu'aux administrateurs, ce qui devrait être le cas). Voir le guide sur la journalisation PowerShell et le CLM pour les détails.

Windows Installer. La règle par défaut « tous les MSI signés » permet aux utilisateurs de lancer n'importe quel installeur signé, ce qui est large mais repose sur le fait que la plupart des MSI exigent une élévation. Resserrez-la en règles d'éditeur pour votre catalogue logiciel si les utilisateurs ne doivent jamais rien installer eux-mêmes.

Applications empaquetées. La règle par défaut autorise tous les packages MSIX signés, y compris toutes les applications du Store. Si vous voulez contrôler quelles applications du Store peuvent s'exécuter, remplacez-la par des règles d'éditeur par package ; générez-les à partir des applications installées avec Get-AppxPackage | Get-AppLockerFileInformation.

Étape 5 : appliquer par anneaux

Passez une collection à la fois en Enforce rules, en commençant par les exécutables, puis les scripts, puis les installeurs et les applications empaquetées. Pour chaque anneau, continuez à surveiller les 8003, 8006, 8021 et 8024 sur les appareils restés en audit, et les 8004, 8007, 8022 et 8025 sur les appareils en application.

Règles par utilisateur sur les appareils partagés

C'est là qu'AppLocker bat encore App Control, qui applique la même stratégie à tous les utilisateurs d'un appareil. Sur les machines partagées comme les postes d'accueil, les terminaux d'atelier, les salles de formation et les postes infirmiers, vous pouvez donner des règles différentes à des populations différentes sur le même matériel :

• Comptes de borne et d'équipe : une courte liste de règles d'éditeur pour l'application métier et le navigateur, rien d'autre. Aucune règle de script en dehors des scripts d'ouverture de session.
• Groupes informatique locale et support : leurs outils de support en plus.
• Administrateurs : la règle par défaut « tous les fichiers », puisqu'ils sont protégés par d'autres contrôles.

Ciblez chaque règle sur un groupe plutôt que sur Everyone, et gérez les groupes dans Active Directory ou Microsoft Entra ID pour que les changements d'appartenance n'imposent pas de modifier la stratégie. Combinez cela avec un shell restreint ou un accès affecté (assigned access) lorsque l'appareil est une vraie borne.

Ce qui casse

• Installeurs par utilisateur : les applications qui s'installent dans %LOCALAPPDATA% (fréquent pour la visioconférence, la messagerie et les outils de développement) sont bloquées par défaut. Fournissez une version à l'échelle de la machine via votre outil de déploiement.
• Outils de mise à jour automatique qui déposent de nouveaux exécutables dans des chemins accessibles en écriture par les utilisateurs.
• Scripts d'ouverture de session depuis SYSVOL ou NETLOGON quand les règles de scripts sont appliquées sans les règles de chemin ci-dessus.
• Compléments et macros Office qui lancent des scripts depuis des dossiers temporaires.
• Outils d'assistance à distance du support téléchargés à la volée. Préinstallez-en un qui soit approuvé.

Vérifier

Get-Service AppIDSvc | Select-Object Status, StartType
Get-AppLockerPolicy -Effective -Xml | Out-File .\effective.xml
Test-AppLockerPolicy -XmlPolicy .\effective.xml -Path "$env:LOCALAPPDATA\Temp\test.exe" -User CORP\jdoe
$ExecutionContext.SessionState.LanguageMode   # ConstrainedLanguage pour un utilisateur standard quand les règles de scripts sont appliquées

Test-AppLockerPolicy renvoie Allowed, Denied ou DeniedByDefault par fichier et par utilisateur, ce qui le rend utile lors des revues de changements. Transférez les ID d'événements de blocage vers votre SIEM ; une rafale d'événements 8004 pour un même utilisateur signifie souvent que quelqu'un a lancé une charge utile d'hameçonnage.

Liste de contrôle

• Service Application Identity en démarrage automatique par GPO sur chaque appareil ciblé
• Mode d'application défini explicitement pour chaque collection
• Règles par défaut créées, avec des exceptions pour les dossiers accessibles en écriture sous %WINDIR%
• Règles de refus pour les binaires de contournement dont les utilisateurs standard n'ont pas besoin
• Deux à quatre semaines de données d'audit examinées avant l'application
• Règles d'éditeur privilégiées, ciblées sur des groupes quand c'est possible
• Règles de scripts appliquées avec SYSVOL/NETLOGON autorisés et scripts d'administration signés
• Événements de blocage (8004, 8007, 8022, 8025) transférés et assortis d'alertes

AppLocker est la couche rapide, par utilisateur. Pour un contrôle que les administrateurs locaux ne peuvent pas simplement désactiver, associez-le à App Control et à un managed installer ; le domaine Contrôle des applications liste toute la série.