Politique effective AppLocker : tester les règles utilisateur

Qu'est-ce qu'une politique effective AppLocker ?

Une politique effective AppLocker est la politique qui s'applique à un ordinateur Windows donné via Group Policy, en combinant sa politique AppLocker locale avec les politiques AppLocker du domaine qui lui sont appliquées. Son examen permet de déterminer quelles règles devraient affecter un fichier pour l'utilisateur visé. Une GPO nommée « AppLocker » constitue une étiquette administrative ; elle n'établit ni ces règles, ni leur mode, ni le blocage d'une exécution. Référence de Get-AppLockerPolicy

Pour une équipe Active Directory qui examine un constat relatif au contrôle des applications, le résultat utile est un dossier de preuves rattaché à un appareil, un utilisateur et une charge de travail. Identifiez le canal de déploiement, conservez la politique effective, examinez ses collections, évaluez des fichiers représentatifs et préparez un test d'exécution contrôlé. Gardez les mesures manquantes visibles jusqu'à ce qu'un administrateur puisse les recueillir.

Ce guide s'appuie sur la documentation primaire vérifiée le 4 octobre 2026 et sur l'implémentation du collecteur décrite ci-dessous. Les commandes PowerShell sont des exemples issus de la documentation, destinés aux administrateurs autorisés. Elles n'ont pas été exécutées sur un poste pour cet article ; aucun résultat de test ni aucune remédiation réussie ne sont revendiqués.

Fonctionnement : identifier le canal de déploiement et les collections

Étape 1 : distinguer les déploiements Group Policy et CSP

Demandez au responsable de la gestion de l'appareil si AppLocker est déployé via Group Policy ou via le fournisseur de services de configuration AppLocker (CSP). La référence Microsoft de Get-AppLockerPolicy indique explicitement que la cmdlet ne comprend que les déploiements GP et peut renvoyer des données incorrectes lorsque la politique a été appliquée via CSP. Un export GP vide ne permet pas de trancher la question du CSP.

La référence du CSP AppLocker documente les restrictions de lancement des applications avec des nœuds de politique propres à chaque collection. Pour un appareil géré via CSP, conservez le profil de gestion responsable, les données de politique des collections et les preuves de leur application à l'appareil obtenues par ce canal. Définissez comment l'équipe de gestion établira l'état appliqué de l'appareil avant de revendiquer une couverture. La procédure d'export GP de cet article ne peut pas fournir ces preuves pour CSP.

Consignez les éléments suivants avant de choisir la méthode de vérification :

Ces champs constituent une proposition de fiche de revue. Renseignez-les avec des observations réelles ; un nom de politique ou une affectation non confirmée ne suffit pas à clôturer une ligne.

Étape 2 : consigner les collections et les modes d'application

Microsoft définit cinq collections de règles AppLocker : fichiers exécutables, fichiers Windows Installer, scripts, DLL, ainsi qu'applications et programmes d'installation empaquetés. Un test limité aux exécutables laisse les autres collections applicables sans examen. La collection DLL n'est pas activée par défaut ; examinez ses implications en matière de compatibilité et de performances avant de l'ajouter au pilote.

Pour chaque collection pertinente, conservez ses règles, les SID des utilisateurs ou groupes, les conditions, les exceptions et le mode configuré. Le schéma XML de la référence CSP comprend les valeurs AuditOnly, Enabled et NotConfigured pour l'application des collections. Conservez la valeur exacte observée, ainsi que le réglage dans la console et la source de déploiement ; ne résumez pas toute la politique comme « activée » parce qu'une collection est appliquée.

La procédure Audit only de Microsoft distingue l'évaluation des règles et la journalisation des décisions de leur application effective. Une collection en audit peut identifier des fichiers qui seraient refusés alors que ces fichiers continuent de s'exécuter. Consignez une collection absente ou un mode ambigu comme un point de revue distinct, sans déduire une protection à partir d'une autre collection.

Si le parc utilise aussi WDAC, notre guide de vérification de l'identité et de l'activation des politiques App Control explique l'inventaire CiTool et les preuves relatives aux politiques Code Integrity. Notre guide de vérification des GUID et actions Defender ASR sur les postes contrôle la configuration des règles de comportement avec Get-MpPreference. Conservez les preuves propres à chaque contrôle lorsqu'ils coexistent.

Détection : exporter, évaluer et corréler les preuves d'exécution

Étape 1 : exporter la politique effective déployée via GP

Sur l'ordinateur évalué et géré via GP, la procédure de test de Microsoft utilise une session Windows PowerShell avec des droits d'administration pour exporter la politique :

Get-AppLockerPolicy -Effective -XML > C:\Effective.xml

Choisissez un emplacement autorisé pour les preuves et conservez l'export original avec les détails de la machine, de l'heure et du canal de déploiement. Examinez toutes les collections applicables avant de tester des fichiers. Un échec d'export est un échec de collecte ; un export au contenu inattendu nécessite une investigation par rapport à la configuration prévue. Aucun de ces résultats ne devient conforme en omettant l'appareil.

Utilisez cet export pour évaluer l'état GP observé. Si vous évaluez plutôt une politique proposée, identifiez-la comme candidate et conservez-la séparément. Tester un fichier XML candidat n'établit pas qu'un appareil a reçu cette politique candidate.

Étape 2 : tester des fichiers représentatifs pour l'utilisateur visé

La même procédure Microsoft fournit cet exemple, avec un répertoire Office et un utilisateur d'exemple :

Get-ChildItem 'C:\Program Files\Microsoft Office\' -filter *.exe -Recurse | Convert-Path | Test-AppLockerPolicy -XMLPolicy C:\Effective.xml -User contoso\zwie -Filter Denied,DeniedByDefault | Export-CSV C:\BlockedFiles.csv

Remplacez le répertoire, l'identité et l'emplacement de sortie par des valeurs approuvées pour l'évaluation. Cette commande évalue des fichiers selon la politique indiquée et exporte des décisions filtrées. Le nom du fichier ne fait pas du CSV un journal de blocages d'exécution. Le filtre d'exécutables de l'exemple ne teste pas non plus les scripts, les programmes d'installation, les dépendances DLL ou les applications empaquetées.

La référence de Test-AppLockerPolicy répertorie Allowed, AllowedByDefault, Denied et DeniedByDefault comme filtres de décision. Conservez une évaluation non filtrée en plus de tout rapport ciblé sur les fichiers refusés. Sinon, un rapport vide limité aux refus ne permet pas de savoir quels fichiers ont été évalués ni de confirmer l'inclusion des cas interdits prévus.

Spécifiez un compte individuel représentatif pour les règles impliquant des groupes imbriqués, comme le recommande la référence de la cmdlet. Tester un nom de groupe ou l'administrateur ayant recueilli l'export peut répondre à une question d'autorisation différente de celle de l'accès de l'utilisateur visé. Répétez l'évaluation pour les populations d'utilisateurs sensiblement différentes et conservez leurs identités avec les résultats.

Construisez un ensemble fini de tests avec les responsables des applications. Incluez, lorsque c'est pertinent, les processus approuvés de lancement, d'installation, de mise à jour et d'exécution de scripts, ainsi que des fichiers inoffensifs volontairement situés hors de l'ensemble d'applications approuvé. Pour chaque cas, consignez la décision attendue, l'identité du fichier ou du paquet, la collection applicable, l'utilisateur et le résultat de l'évaluation. Les fichiers manquants et les erreurs d'évaluation restent des lacunes explicites. Ne fabriquez pas un résultat conforme à partir d'un examen limité à un répertoire.

Étape 3 : examiner les bons journaux AppLocker

La procédure de surveillance de Microsoft situe les journaux AppLocker sous Applications and Services Logs → Microsoft → Windows → AppLocker. Examinez EXE and DLL pour ces types de fichiers et MSI and Script pour les programmes d'installation et les scripts ; incluez Packaged app-Deployment et Packaged app-Execution lorsque ces collections entrent dans le périmètre.

La référence des événements AppLocker documente ces distinctions utiles :

La documentation Microsoft des règles de script nuance les événements de blocage des scripts : l'hôte de script met en œuvre l'application des règles. Les scripts PowerShell signalés comme bloqués peuvent néanmoins s'exécuter en Constrained Language Mode ; les scripts autorisés s'exécutent en Full Language Mode. Pour un test de script, consignez l'hôte, le mode de langage et les opérations observées, sans traiter le seul événement 8007 comme une preuve qu'aucun code de script n'a été exécuté.

Conservez tous les détails des événements, dont le fichier, l'heure, le contexte de règle et l'identité, avec la fiche de test. Un événement concernant un fichier dont l'exécution a été tentée ne peut pas établir la couverture de toutes les charges de travail ou de tous les utilisateurs. Des journaux silencieux nécessitent de vérifier l'activité effectivement exercée, les autorisations de collecte et la conservation avant toute interprétation.

Remédiation : valider un pilote réversible de l'audit à l'application (Remediation)

Étape 1 : approuver le comportement attendu avant de modifier les règles

Tranchez trois décisions opérationnelles : quelles preuves couvrent le canal de déploiement, quelles collections et quels modes affectent l'utilisateur visé, et quels scénarios autorisés et interdits seront validés en laboratoire. Désignez le responsable de la politique, les approbateurs des applications et l'opérateur chargé de la restauration. Conservez la politique actuelle et une procédure de restauration approuvée avant de distribuer un changement.

Utilisez des équipements pilotes pouvant être restaurés et du matériel de test inoffensif. Convenez des processus indispensables qui doivent rester disponibles et des cas interdits qui doivent échouer après l'application des règles. L'échec d'un processus d'administration ou métier nécessaire arrête l'extension jusqu'à ce que son responsable examine la règle. Une autorisation inattendue pour un cas interdit nécessite aussi une investigation ; le seul bon fonctionnement des usages métier n'établit pas la restriction prévue.

Étape 2 : configurer Audit only et tester le pilote

Pour une politique gérée par GPO, utilisez Group Policy Management Console pour gérer la GPO responsable. La procédure Audit only de Microsoft demande aux administrateurs d'ouvrir AppLocker → Properties → Enforcement, de sélectionner Configured pour chaque collection choisie, de choisir Audit only, puis de confirmer. Local Security Policy est l'outil correspondant pour la gestion des politiques locales.

Avant de tester le pilote, vérifiez que Application Identity (AppIDSvc) est en cours d'exécution. Microsoft indique que l'arrêt de ce service empêche l'application des règles AppLocker. Pour un déploiement Group Policy, configurez le démarrage automatique dans au moins une GPO qui applique des règles AppLocker, sous Computer Configuration → Windows Settings → Security Settings → System Services → Application Identity. Conservez l'état observé du service avec l'export de politique. Procédure du service Application Identity

Après l'application, recueillez à nouveau la politique et répétez les évaluations pour l'utilisateur visé. Exécutez les scénarios approuvés dans le pilote et examinez les événements d'audit par rapport aux décisions attendues. Demandez aux responsables des applications d'expliquer les dépendances et les exceptions proposées. Rattachez chaque exception à une exigence précise, un approbateur et une décision de revue. Ne transformez pas chaque fichier audité en règle d'autorisation simplement pour supprimer le bruit d'audit.

Étape 3 : appliquer les collections approuvées et valider l'exécution

La procédure Enforce rules de Microsoft utilise le même onglet Properties → Enforcement : sélectionnez Configured pour la collection à modifier et choisissez Enforce rules. Effectuez ce changement par l'intermédiaire du responsable et du canal établis après la revue du pilote. Un déploiement CSP exige sa propre procédure de gestion approuvée.

Réexportez la politique GP après l'application, comparez les collections et les modes, puis répétez l'évaluation des règles. Effectuez ensuite les tests d'exécution approuvés en tant qu'utilisateur visé sur le pilote. Consignez le comportement réel et les événements correspondants pour les scénarios nécessaires comme pour les scénarios interdits. Si le comportement diffère de l'évaluation, examinez l'artefact de politique, l'état de l'application, le contexte utilisateur et la collection applicable avant toute extension.

Ne passez à d'autres populations que lorsque les réviseurs désignés acceptent les preuves et la préparation à la restauration. Gardez les appareils inconnus et les charges de travail non testées dans la fiche de changement. Le critère d'achèvement est le comportement approuvé observé sur la population évaluée, avec les limites et les exceptions consignées.

Comment EtcSec détecte ce problème

L'etc-collector d'EtcSec comprend ANSSI_R37_APPLOCKER_NOT_ENFORCED. Au commit 0423094759d50002457031317098417993e19510, Detect() dans public/internal/audit/detectors/ad/compliance/anssi/anssi-r37-applocker-not-enforced.go:41 convertit en minuscules le DisplayName de chaque GPO recueillie et recherche applocker, wdac, code integrity ou srp. Un seul nom correspondant suffit à laisser Count 0 ; l'absence de nom correspondant produit Count 1, avec une sévérité Medium. Ce compteur ne représente pas un nombre de postes non protégés.

Le prédicat ne lit aucune règle XML AppLocker, aucun mode de collection ni aucune autorisation propre à un utilisateur. Il n'établit pas l'application d'une GPO à un appareil. Un nom évocateur peut faire disparaître le signal sans application des règles ; une véritable politique portant un autre nom peut laisser le signal présent. Renommer une GPO change cette heuristique sans prouver une amélioration de la sécurité.

Le fournisseur LDAP dans public/internal/providers/ldap/client.go:1007 récupère les métadonnées des GPO. L'échec de sa recherche renvoie une erreur, mais public/internal/audit/engine.go:521 écarte l'erreur de GetGPOs lors de l'affectation des GPO renvoyées. Ce signal seul ne peut donc pas distinguer une collecte de GPO échouée d'une collecte réussie sans indice dans les noms. Établissez indépendamment la qualité de la collecte avant de l'interpréter.

R37 est un identifiant historique du détecteur, pas le numéro de la recommandation normative AppLocker. Le code associe ce contrôle à ANSSI PA-099 R11. Le guide PA-099, daté du 2 octobre 2023, page 28 recommande un durcissement du système et des logiciels qui contribue à l'isolation des Tiers. Cette recommandation générale ne transforme pas l'heuristique sur les noms en test de conformité propre à AppLocker.