AppLocker, App Control for Business (WDAC) et distribution d'applications métier — Avant que le « contrôle d'exécution » ne vous bloque

« Une fois installée sur le PC du client, l’application ne démarre pas. Un double-clic ne produit rien. » — ce type de signalement nous parvient de plus en plus souvent pour des applications Windows développées sur mesure. En creusant la cause, on découvre que ce qui arrêtait l’application sans même afficher de boîte de dialogue d’erreur était le contrôle d’exécution des applications, dont le déploiement progresse chez les clients.

Windows dispose de plusieurs mécanismes permettant de n’autoriser l’exécution que des applications approuvées : AppLocker, App Control for Business (longtemps appelé WDAC, Windows Defender Application Control), et, côté grand public, Smart App Control. Dans le contexte de la sécurité, la plupart des explications adoptent le point de vue de « celui qui déploie » ces contrôles. Cet article change d’angle et se place du côté de celui qui développe et distribue l’application : les schémas types dans lesquels votre propre application métier se retrouve bloquée chez un client, les journaux à consulter pour confirmer un blocage, et les mesures que les équipes de développement et de distribution peuvent prendre en amont. Il résume également, à l’intention des équipes informatiques envisageant de déployer ces contrôles sur leurs propres PC, les points essentiels côté déploiement.

1. La conclusion, d’abord

• Pensez le contrôle d’exécution comme quatre mécanismes distincts : SmartScreen, qui avertit et laisse l’utilisateur choisir ; AppLocker, qui applique des règles par utilisateur ou groupe ; App Control for Business, qui s’applique à toute la machine ; et Smart App Control, qui agit automatiquement pour les particuliers (voir le tableau de décision du chapitre 2).
• L’idée selon laquelle « AppLocker est réservé à Enterprise » est dépassée. Depuis la KB 5024351, sur Windows 10 version 2004 et ultérieure ainsi que sur toutes les éditions de Windows 11, l’application forcée ne nécessite plus d’édition particulière.¹
• App Control for Business fonctionne sur toutes les éditions client de Windows 10/11 et sur Windows Server 2016 et ultérieur. Microsoft recommande d’utiliser App Control plutôt qu’AppLocker chaque fois que c’est possible.²
• La signature de code est au cœur des mesures côté distribution. Signez non seulement l’exe, mais tous les binaires, y compris les DLL, ainsi que l’installateur, avec des informations d’éditeur cohérentes (chapitre 5). Avec la généralisation de Smart App Control, une application non signée peut désormais ne pas fonctionner même sur un PC personnel.³
• La preuve d’un blocage peut être établie dans le journal d’événements. Pour AppLocker, l’événement clé est le 8004 du journal « AppLocker - EXE and DLL » ; pour App Control, c’est le 3077 de « CodeIntegrity - Operational » (voir le tableau du chapitre 4).⁴⁵
• Un script PowerShell peut, plutôt qu’être « bloqué », se retrouver « exécuté en mode restreint ». Dans un environnement App Control, un script qui ne correspond pas à la stratégie s’exécute en mode de langage contraint (Constrained Language Mode), ce qui produit un dysfonctionnement difficile à diagnostiquer : « ça s’exécute, mais seules certaines opérations échouent ».⁵
• Côté déploiement, commencez toujours par le mode audit. AppLocker comme App Control disposent d’un mode qui enregistre « ce qui aurait été bloqué » sans réellement bloquer, correspondant aux événements 8003 et 3076.⁴⁵

2. Distinguer les quatre mécanismes

Commençons par la carte d’ensemble. Les noms se ressemblent et prêtent facilement à confusion, aussi allons-nous les distinguer selon « qui gère », « à quelle unité cela s’applique » et « comment cela agit ».

2.1. SmartScreen — le seul mécanisme qui arrête par un « avertissement »

SmartScreen est un mécanisme qui « avertit à propos de ce qui a une mauvaise réputation », et par défaut l’utilisateur peut passer outre. Dans un environnement géré, cependant, une stratégie interdisant de passer outre l’avertissement peut être activée, auquel cas SmartScreen fonctionne lui aussi, dans les faits, comme un blocage (ce sujet est traité dans « Windows SmartScreen et la signature de code »).

Du point de vue de celui qui distribue, ce qui caractérise SmartScreen, c’est qu’il agit par défaut même sans administrateur pour écrire une règle, et que la raison du blocage est la « réputation », pas une stratégie. La façon d’y remédier diffère donc des trois autres mécanismes : plutôt que de faire écrire une règle d’autorisation par le client, on résout le problème par la signature et l’accumulation de réputation. Les sections 2.2 à 2.4 qui suivent portent sur des mécanismes qui bloquent, plutôt qu’ils n’avertissent.

2.2. AppLocker — le vétéran, avec un contrôle par utilisateur

AppLocker est un contrôle d’exécution introduit avec Windows 7. Il définit des règles à partir des attributs du certificat de signature de code (l’éditeur), des attributs de fichier issus des métadonnées de signature (nom de fichier d’origine, version) ou de hachages, et des chemins de fichiers. La stratégie peut s’appliquer à l’ensemble de l’ordinateur, ou à des utilisateurs ou groupes spécifiques.²

C’est là que porte le plus souvent la confusion sur les exigences d’édition. La documentation actuelle est claire : depuis la KB 5024351, sur Windows 10 version 2004 et ultérieure ainsi que sur toutes les éditions de Windows 11, l’application forcée d’une stratégie AppLocker ne nécessite aucune édition particulière. Sur les versions plus anciennes (Windows 10 antérieur à 2004, Windows Server 2019 inclus), l’ancienne restriction subsiste : l’application forcée d’une stratégie distribuée par stratégie de groupe n’est prise en charge que sur les éditions Enterprise et Server, tandis qu’une stratégie distribuée par MDM est prise en charge sur toutes les éditions.¹

Si l’on décompose « ce qu’on peut faire sous Pro » en deux questions distinctes — peut-on créer des règles ? et les règles créées sont-elles réellement appliquées (forcées) ? — on obtient le tableau suivant. C’est parce que ces deux aspects sont distincts que l’idée reçue a survécu.¹

On croit souvent, à tort, qu’« on ne peut même pas créer de règles sous Pro », mais la création est possible sur n’importe quelle édition. Ce qui différait autrefois, c’était l’application forcée, et même à l’époque, une distribution par MDM permettait déjà de l’appliquer sous Pro. Les types de règles applicables (fichiers exécutables, programme d’installation Windows, scripts, DLL, applications empaquetées) ne varient pas selon l’édition.¹ Notez par ailleurs que, quelle que soit l’édition, les règles ne sont pas évaluées si le service Application Identity (AppIDSvc) n’est pas en cours d’exécution (chapitre 6).

AppLocker comporte toutefois une réserve importante. Microsoft indique lui-même explicitement qu’AppLocker ne satisfait pas aux critères de service (servicing criteria du MSRC) applicables à une fonctionnalité de sécurité. Autrement dit, même si une technique de contournement est découverte, elle n’est pas traitée en tant que telle comme une vulnérabilité de sécurité.²

2.3. App Control for Business — la référence en tant que fonctionnalité de sécurité

App Control for Business est le nom actuel du mécanisme apparu sous Windows 10 sous les appellations « Device Guard » et « intégrité de code configurable (WDAC) ». La stratégie s’applique à toute la machine et affecte tous les utilisateurs de l’appareil. Les règles peuvent s’appuyer sur les attributs du certificat de signature, les attributs de fichier ou les hachages, une évaluation par l’Intelligent Security Graph (ISG) de Microsoft, le processus ayant lancé l’installation (un installateur géré), le chemin du fichier (Windows 10 1903 et ultérieur), ou le processus à l’origine du lancement.²

Celui-ci est conçu comme une fonctionnalité de sécurité définie selon les critères de service du MSRC. Ses conditions d’utilisation sont également larges : vous pouvez créer et appliquer une stratégie sur n’importe quelle édition client de Windows 10/11, ou sur Windows Server 2016 et ultérieur. La distribution peut se faire via un MDM tel qu’Intune, via Configuration Manager, ou via PowerShell. Une distribution par stratégie de groupe est également possible, mais elle se limite au format à stratégie unique fonctionnant sur Windows Server 2016/2019.²

Sur le choix entre les deux, les recommandations de Microsoft sont claires : si App Control permet de le mettre en œuvre, il faut l’utiliser. App Control continue d’être amélioré, alors qu’AppLocker ne reçoit plus que des correctifs de sécurité, sans nouvelle fonctionnalité. AppLocker convient dans les cas où coexistent d’anciennes versions de Windows auxquelles on souhaite distribuer la même stratégie, sur des PC partagés nécessitant des règles différentes par utilisateur ou groupe, et en complément d’App Control pour ajouter des restrictions par utilisateur.²

2.4. Smart App Control — un contrôle d’exécution « déjà activé » sur les PC personnels

Smart App Control est une fonctionnalité de protection destinée aux utilisateurs individuels de Windows 11. Lorsqu’une application tente de s’exécuter, un service de sécurité cloud vérifie s’il peut prédire de manière fiable la sécurité de cette application, et bloque les applications jugées malveillantes, ainsi que les applications non signées dont la fiabilité ne peut être confirmée. Sur un PC neuf, la fonctionnalité démarre en mode d’évaluation, et Windows détermine automatiquement si elle convient à l’utilisateur pour décider de l’activer ou non (elle se désactive automatiquement pour un utilisateur susceptible d’être bloqué fréquemment, comme un développeur).³

Pour celui qui distribue, l’implication est simple : le contrôle d’exécution est désormais présent par défaut même sur des PC hors gestion d’entreprise, c’est-à-dire chez des clients petites entreprises ou travailleurs indépendants. Même sans qu’aucun administrateur n’ait écrit de stratégie, une application non signée peut être bloquée. Les recommandations de Microsoft aux développeurs mentionnent elles aussi la signature de l’application avec un certificat valide comme moyen d’éviter le blocage.³

3. Les schémas types dans lesquels votre application se retrouve bloquée

Voici, classés par cause, les schémas réellement rencontrés sur le terrain du développement sous contrat et de la distribution de logiciels packagés.

Le point commun à tous ces cas, c’est que le côté distribution ne fournit pas de façon stable les fondements (signature, chemin, hachage) sur lesquels le côté autorisation doit s’appuyer. Même si le service informatique du client souhaite écrire une règle d’éditeur, si seule une partie des binaires est signée, il n’a d’autre choix que d’écrire une règle de hachage — et une règle de hachage se casse à chaque nouvelle version que vous publiez. La responsabilité du blocage peut sembler incomber au côté déploiement, mais en pratique, c’est souvent le côté distribution qui rend les règles fragiles.

4. Confirmer ce qui s’est passé grâce au journal

Que le contrôle d’exécution soit ou non la cause du problème « ça ne démarre pas » peut être confirmé dans le journal d’événements, sans avoir à deviner. Il existe deux endroits à consulter.

4.1. Événements AppLocker

Consultez, dans l’Observateur d’événements, l’arborescence Journaux des applications et des services\Microsoft\Windows\AppLocker.⁴ Pour ceux qui l’ouvrent pour la première fois, voici le chemin à suivre.

Observateur d’événements (tapez « Observateur d’événements » dans le menu Démarrer, ou exécutez eventvwr.msc via Exécuter) > Journaux des applications et des services > Microsoft > Windows > AppLocker > EXE and DLL / MSI and Script / Packaged app-Deployment / Packaged app-Execution

Dans un environnement en anglais, le chemin correspondant est Applications and Services Logs > Microsoft > Windows > AppLocker. Si vous préférez vous passer de l’interface graphique, ouvrez PowerShell en tant qu’administrateur et lisez le journal avec la commande suivante (c’est aussi la façon la plus rapide de procéder lorsque vous demandez cela à un client : transmettez-lui simplement cette ligne).

# Récupérer les blocages AppLocker (8004) et les audits (8003) des dernières 24 heures
Get-WinEvent -FilterHashtable @{
    LogName   = 'Microsoft-Windows-AppLocker/EXE and DLL'
    Id        = 8003, 8004
    StartTime = (Get-Date).AddDays(-1)
} | Format-List TimeCreated, Id, Message

L’événement enregistre le chemin du fichier concerné, s’il a été autorisé ou bloqué, le type de règle appliquée (chemin, hachage, éditeur) et son nom, ainsi que le SID de l’utilisateur ou du groupe de la règle.⁴ La lecture demande toutefois de la prudence. Dans une exploitation de type liste blanche, la plupart des blocages ne correspondent pas à « une règle de refus qui s’est appliquée », mais à un refus implicite parce qu’aucune règle d’autorisation ne correspondait. Dans ce cas, ce que confirme l’événement 8004 se limite au « fait qu’il y a eu blocage et au fichier concerné » ; le nom de la règle n’est alors d’aucune aide. Lorsqu’une règle de refus explicite est en cause, son nom indique directement la cause, mais pour un refus implicite, il faut déterminer « quelle règle d’autorisation manque » en comparant avec la stratégie actuellement appliquée.

4.2. Événements App Control for Business (WDAC)

Les blocages d’App Control apparaissent ailleurs, dans Journaux des applications et des services\Microsoft\Windows\CodeIntegrity\Operational. Le contrôle des exe, DLL et pilotes s’y trouve, tandis que le contrôle des MSI, scripts et COM apparaît dans le journal « AppLocker - MSI and Script » vu précédemment — c’est ainsi que se répartissent les rôles.⁵

Observateur d’événements > Journaux des applications et des services > Microsoft > Windows > CodeIntegrity > Operational (dans un environnement en anglais : Applications and Services Logs > Microsoft > Windows > CodeIntegrity > Operational)

# Afficher ensemble les blocages App Control (3077), les audits (3076) et les informations de signature correspondantes (3089)
Get-WinEvent -FilterHashtable @{
    LogName   = 'Microsoft-Windows-CodeIntegrity/Operational'
    Id        = 3076, 3077, 3089
    StartTime = (Get-Date).AddDays(-1)
} | Sort-Object TimeCreated | Format-List TimeCreated, Id, Message

Lorsque vous ne savez pas « lequel des deux mécanismes est à l’origine du blocage », le plus sûr est d’aligner ces deux journaux sur la même plage horaire et de les comparer.

L’événement 3089 est souvent négligé, mais il est important. Il est généré une fois par signature présente sur le fichier ; pour un fichier non signé, un seul événement est généré, avec un nombre de signatures égal à zéro. C’est ici que l’on peut confirmer des défauts côté distribution tels que « le fichier est traité comme non signé alors qu’il aurait dû être signé » ou « la signature d’un ancien certificat est restée en place ».⁵

Le comportement des scripts appelle une attention particulière. L’événement 8029 indique qu’« un script a été bloqué », mais l’application forcée réelle est déléguée au comportement propre à l’hôte de script : PowerShell, par exemple, n’arrête pas complètement un script qui ne correspond pas à la stratégie, mais l’exécute en mode de langage contraint (Constrained Language Mode).⁵ La création d’objets .NET étant largement restreinte dans ce mode, le résultat est un dysfonctionnement à mi-chemin : « le script lui-même s’exécute, mais une seule ligne en cours de route échoue ». Si votre application inclut un script, ignorer ce mode de dysfonctionnement peut faire traîner l’investigation en longueur (les aspects pratiques de la signature de script sont couverts dans « Stratégie d’exécution PowerShell et signature de script »).

Notez par ailleurs que le journal « AppLocker - MSI and Script » n’existe pas sur l’édition Windows Server Core.⁵ Gardez cela à l’esprit lorsque vous enquêtez sur une application déployée sur un serveur.

5. Ce que peut faire celui qui distribue — rendre l’application « facile à couvrir par des règles »

Plutôt que d’agir après coup une fois le blocage survenu, la bonne approche consiste à distribuer l’application dans un état où le service informatique du client peut écrire une règle d’autorisation stable. Il n’y a pas grand-chose à faire.

1. Apposez une signature Authenticode sur tous les binaires. Pas seulement l’exe, mais aussi vos DLL compilées en interne, l’installateur (MSI/exe d’installation) et jusqu’aux scripts inclus. Les règles d’éditeur s’appuient sur les métadonnées de signature (éditeur, nom du produit, nom de fichier, version) : si les binaires sont signés, vous permettez d’écrire une règle qui survit aux mises à jour, du type « autoriser ce produit de cet éditeur, quelle que soit la version ».² Choisissez un certificat basé sur RSA, délivré par une autorité de certification de confiance. Un certificat auto-signé ou délivré par une AC interne ne fonctionnera pas sur un PC client qui ne fait pas confiance à cette AC, et n’est pas non plus pris en charge par Smart App Control. De plus, la vérification de signature de Smart App Control ne prenant pas en charge les signatures ECC (courbes elliptiques), signer avec un certificat ECC peut faire traiter l’application comme non signée sur un PC personnel.⁶ App Control impose la même contrainte : les règles basées sur le signataire ne prennent en charge que RSA (jusqu’à 4096 bits), et un fichier signé en ECDSA ne peut pas être autorisé par une règle d’éditeur (l’événement d’information de signature 3089 affichera alors VerificationError = 23).⁷ Choisir l’ECC en pensant « c’est plus récent, donc plus solide » se retourne contre vous du point de vue du contrôle d’exécution.
2. Ajoutez toujours un horodatage. La validité de la signature est ainsi préservée même après l’expiration du certificat. La procédure pratique de signature et sa relation avec SmartScreen sont détaillées dans un autre article.
3. Gardez stables les informations d’éditeur et la ressource de version des fichiers. Lorsque vous renouvelez un certificat, un changement de sujet (nom de l’organisation) casse les règles d’éditeur. Si vous modifiez la façon dont le nom de l’entreprise est écrit, ou l’origine du certificat, incluez un avis préalable aux clients dans les notes de version. Un autre point souvent négligé est que le « nom du produit », le « nom de fichier d’origine » et la « version » d’une règle d’éditeur sont tirés de la ressource de version de chaque fichier (informations d’assemblage), et non du certificat. Laisser ces champs vides, ou changer le nom du produit ou le nom du fichier exécutable à chaque version, casse toute règle ciblant un produit ou un fichier précis, même si le signataire reste identique.
4. Rapprochez l’emplacement de vos exécutables des conventions standard. Installez sous Program Files et abandonnez les conceptions qui extraient les exe/DLL vers %TEMP% ou %APPDATA% à l’exécution pour les lancer depuis là. Une conception qui s’exécute depuis un emplacement accessible en écriture est fondamentalement incompatible avec un environnement basé sur des règles de chemin.
5. Revoyez la conception de la mise à jour automatique. Signez également le programme de mise à jour lui-même, afin que la mise à jour forme une boucle fermée où « un binaire signé remplace un binaire signé ». Lorsque la distribution passe par Intune ou Configuration Manager, si le client a configuré cet agent de distribution comme installateur géré, il devient possible d’autoriser les binaires arrivés via l’installateur. Cela ne s’active pas automatiquement — cela suppose une configuration explicite côté administrateur — mais avoir un MSI prêt pour une installation silencieuse offre cette option au client (la conception sécurisée de la mise à jour automatique est traitée dans « Sécurité de la mise à jour automatique »).
6. Préparez à l’avance les informations à fournir en cas de blocage. En indiquant clairement, dans le « guide de déploiement », le sujet de la signature, la liste des binaires nécessaires à l’exécution et le chemin d’installation, le service informatique du client pourra écrire une règle sur cette seule base. En cas de problème, demander de vérifier les identifiants d’événements du chapitre 4 permet de régler la question en un seul aller-retour.

Ces six points constituent aussi, tels quels, une bonne préparation face à Smart App Control. Un binaire signé et dont la réputation s’est accumulée a moins de risques de déclencher le blocage automatique sur un PC personnel.³

5.1. Obtenir un certificat de signature de code pour la première fois

Comme on peut rester bloqué au stade de « il faut signer », voici la marche à suivre concrète pour ceux qui ne possèdent pas encore de certificat.

Choisir le certificat. Ce qu’il faut, c’est un certificat de signature de code délivré par une autorité de certification publique (une AC commerciale). Un certificat auto-signé ou délivré par une AC interne ne peut pas être vérifié sur un PC client qui ne fait pas confiance à cette AC, et ne peut donc pas être utilisé pour la distribution. Les certificats d’AC publiques se déclinent en OV (validation de l’existence de l’organisation) et en EV, à l’examen plus rigoureux, mais du point de vue des règles d’éditeur d’AppLocker et d’App Control, les deux permettent d’écrire une règle de la même manière. App Control propose bien une option de règle « exiger la signature EV » (Required:EV Signers), mais la documentation indique explicitement qu’elle n’est pas prise en charge actuellement, si bien qu’il n’y a pour l’instant aucune raison de choisir l’EV pour des besoins de contrôle d’exécution.⁷

Penser au coût. Le montant varie selon l’AC et la durée de validité, donc il faudra obtenir un devis, mais connaître la structure des postes facilite la comparaison. Depuis le 1er juin 2023, selon les exigences du CA/Browser Forum, qu’il s’agisse d’OV ou d’EV, la clé privée doit être générée et stockée sur un matériel équivalent au minimum au FIPS 140-2 niveau 2 (un HSM ou un jeton USB).⁸ Le coût comprend donc non seulement « le certificat lui-même », mais aussi « les frais d’utilisation du jeton, du HSM, ou d’un service de signature cloud proposé par l’AC ». Si vous souhaitez signer automatiquement dans un pipeline CI/CD, un service de signature cloud est généralement plus simple à mettre en place qu’un jeton physique : abordez donc le mode d’exploitation de la signature dès la demande de devis.

La commande de signature minimale. Utilisez signtool, fourni avec le Windows SDK.

:: Signer le fichier (hachage SHA-256, ajout d'un horodatage RFC 3161)
signtool sign /fd sha256 /tr <URL du serveur d'horodatage> /td sha256 /a MyApp.exe

:: Vérifier la signature (validation selon la stratégie Authenticode, affichage des détails)
signtool verify /pa /v MyApp.exe

/fd correspond à l’algorithme de hachage du fichier, /tr à l’URL du serveur d’horodatage RFC 3161, /td à l’algorithme de hachage de l’horodatage, et /a indique de sélectionner automatiquement le certificat approprié dans le magasin de certificats. Utilisez l’URL de serveur d’horodatage indiquée par l’AC auprès de laquelle vous avez acheté le certificat. Si vous signez avec une clé sur un jeton ou un HSM, la spécification CSP/KSP figure dans le guide de configuration de l’AC. La même commande permet de signer aussi bien les DLL que l’installateur, donc l’approche la plus sûre consiste à l’appliquer à tout à la fin du build.

Ce qui casse lors du renouvellement du certificat. Une règle d’éditeur s’appuie sur les informations d’éditeur de la signature (chaîne de certificats et sujet). Les changements suivants font donc silencieusement cesser la correspondance avec la règle côté client.

• Vous avez modifié la façon dont le nom de l’entreprise est écrit (par exemple, en changeant le sujet du certificat de Komura Soft LLC à 合同会社小村ソフト, la raison sociale japonaise officielle). Même pour la même entreprise, une chaîne de caractères différente correspond à un éditeur différent.
• Vous avez changé d’autorité de certification. Une règle App Control de niveau Publisher est une combinaison « certificat d’AC intermédiaire (PCA) + CN du certificat feuille » ; changer d’AC change donc le PCA, et la correspondance cesse.⁷
• Vous avez changé le nom du fichier exécutable ou le nom du produit. Une règle de niveau FilePublisher inclut, en plus de ces éléments, le nom de fichier d’origine (OriginalFileName) et une version minimale.⁷

Dans tous les cas, le symptôme est le même : dès le remplacement par la version mise à jour, l’application cesse de démarrer, mais uniquement dans cet environnement. Et du point de vue du client, c’est simplement « ça s’est cassé après la mise à jour », donc personne ne soupçonne la signature d’en être la cause. Lorsque vous renouvelez ou modifiez un certificat, placez dans les notes de version un avis mettant en regard les anciennes et nouvelles informations de signature (sujet, AC émettrice), afin que le service informatique du client puisse ajouter la règle.

6. Points essentiels pour celui qui déploie (le service informatique)

Pour celui qui déploie le contrôle d’exécution sur ses propres PC, cet article se limite ici à l’essentiel.

1. Choisir la technologie. En règle générale, App Control for Business. Ajoutez AppLocker en complément pour les PC partagés nécessitant un contrôle par utilisateur, ou les environnements mêlant d’anciennes versions d’OS.² Pour les PC à usage fixe comme les terminaux en kiosque, commencer par restreindre le shell (voir « Mode kiosque et accès attribué ») avant d’y réfléchir permet de garder des règles plus simples.
2. Commencez toujours par le mode audit. Avec AppLocker en mode « Audit seulement », les événements 8003 et 8006 enregistrent ce qui aurait été bloqué si l’application était forcée ; avec le mode audit d’App Control, ce sont les événements 3076 et 8028 qui remplissent ce rôle.⁴⁵ La démarche — collecter jusqu’à ce qu’un cycle complet d’activité soit passé, puis basculer vers l’application forcée — est exactement la même que pour la signature SMB ou la restriction NTLM. Notez qu’il existe un préalable si vous utilisez AppLocker : sa stratégie n’est pas évaluée si le service Application Identity (AppIDSvc) n’est pas en cours d’exécution, et aucun événement n’apparaît, même en mode audit, sans lui. Avant de commencer l’audit, configurez le démarrage automatique de ce service sur les postes concernés.
3. Tenez un registre des exceptions. Une ancienne application métier qui continue d’être utilisée sans être signée doit être enregistrée en exception par une règle de hachage. Cette liste constitue en elle-même la liste des « éléments à remplacer un jour » : reliez-la à la gestion de vos actifs et révisez-la chaque année.

Pour éviter de renvoyer vers un autre article concernant l’étape 2, « commencer par le mode audit », voici le déroulé minimal directement ici.

Pour AppLocker (3 étapes)

1. Activez le mode audit. Dans l’éditeur de gestion des stratégies de groupe (ou secpol.msc en local), ouvrez Configuration ordinateur > Stratégies > Paramètres Windows > Paramètres de sécurité > Stratégies de contrôle d’application > AppLocker, faites un clic droit sur AppLocker et choisissez Propriétés. Pour chaque collection de règles (fichiers exécutables, programme d’installation Windows, scripts, applications empaquetées), cochez « Configuré » et sélectionnez « Audit seulement ». Créez également les règles par défaut pour chaque collection, et configurez sur les postes concernés le démarrage automatique du service Application Identity (AppIDSvc) (sans lui en cours d’exécution, la stratégie n’est pas évaluée, et aucun événement n’apparaît).

2. Collectez les événements. Jusqu’à ce qu’un cycle complet d’activité soit passé, collectez l’événement 8003 (exe/DLL) de Microsoft-Windows-AppLocker/EXE and DLL ainsi que l’événement 8006 (scripts/MSI) de MSI and Script.⁴ Une précaution s’impose ici : le PowerShell du chapitre 4 fixe le nom du journal à « EXE and DLL », donc tel quel, il ne récupère pas le 8006 des scripts et des MSI. Les journaux étant distincts, il faut exécuter la commande sur les deux, comme suit.

    # En mode audit, collecter dans les deux journaux « ce qui aurait été bloqué si l'application était forcée »
    $since = (Get-Date).AddDays(-7)
    $collections = @(
        @{ LogName = 'Microsoft-Windows-AppLocker/EXE and DLL';    Id = 8003 }
        @{ LogName = 'Microsoft-Windows-AppLocker/MSI and Script'; Id = 8006 }
    )
    foreach ($c in $collections) {
        Get-WinEvent -FilterHashtable ($c + @{ StartTime = $since }) -ErrorAction SilentlyContinue |
            Select-Object TimeCreated, LogName, Id, Message
    }
   

   -ErrorAction SilentlyContinue est ajouté car Get-WinEvent renvoie une erreur pour un journal ne contenant aucun événement correspondant. Si les applications empaquetées sont également soumises au contrôle, ajoutez de la même façon Packaged app-Deployment / Packaged app-Execution. Vérifiez que les traitements par lots mensuels et annuels ont bien été couverts.

3. Basculez vers l’application forcée. Intégrez dans des règles d’autorisation ce qui est apparu en 8003 et 8006, puis passez à « Appliquer les règles » sur le même écran Propriétés. Après le basculement, surveillez 8004 (blocages exe/DLL) et 8007 (blocages scripts/MSI).

Pour App Control for Business, le déroulé est le même : distribuez le XML de stratégie avec l’option de règle 3 (Enabled:Audit Mode) activée (configurez-la avec l’App Control Policy Wizard, ou la cmdlet Set-RuleOption), collectez 3076 et 8028, puis retirez cette option pour basculer vers l’application forcée. Microsoft recommande lui aussi de vérifier d’abord l’impact avec Enabled:Audit Mode.⁷

7. Conclusion

• Pensez le contrôle d’exécution en distinguant SmartScreen, qui « avertit », d’AppLocker / App Control for Business / Smart App Control, qui « bloquent » (SmartScreen fonctionne toutefois lui aussi comme un blocage effectif sous une stratégie de gestion interdisant de passer outre l’avertissement).
• La restriction d’édition d’AppLocker est déjà levée (Windows 10 2004 et ultérieur, toutes les éditions de Windows 11), et App Control a toujours fonctionné sur toutes les éditions client. « Nos clients sont sous Pro, donc cela ne nous concerne pas » ne tient plus.¹²
• Avec Smart App Control, le contrôle d’exécution est désormais présent même sur des PC personnels que personne ne gère. Un logiciel distribué non signé peut, pour cette seule raison, ne pas fonctionner.³
• Confirmez un blocage dans le journal d’événements : pour AppLocker, l’essentiel est le 8004 (journal EXE and DLL) ; pour App Control, c’est le 3077 accompagné de l’information de signature 3089 (journal CodeIntegrity - Operational).⁴⁵
• Les mesures côté distribution : une signature cohérente sur tous les binaires, un horodatage, un emplacement d’installation standard, une mise à jour automatique signée, et la mise à disposition d’informations dans le guide de déploiement. Rendre l’application facile à couvrir par une règle pour le client résume à lui seul l’ensemble de la prévention des blocages.
• Côté déploiement, collectez un cycle complet en mode audit (8003 / 3076) avant de basculer vers l’application forcée. Cette démarche est identique à celle des autres renforcements de sécurité.

Articles liés

• Pourquoi Windows affiche « Windows a protégé votre PC »
• Conception sécurisée de la mise à jour automatique - Pourquoi HTTPS seul ne suffit pas
• Choisir sa méthode de distribution d’application Windows - MSI/MSIX/ClickOnce/xcopy/mise à jour maison
• Stratégie d’exécution PowerShell et signature de script — Guide pratique pour sortir de l’habitude « Bypass en guise de solution »
• Guide de gestion des faux positifs (False Positive) de Windows Defender
• Mode kiosque Windows et accès attribué
• Solutions concrètes après la fin de support de Windows 10 — Tableau de décision ESU, LTSC, remplacement

Domaines de conseil associés

合同会社小村ソフト (Komura Software LLC) prend en charge le développement et la modification d’applications métier fonctionnant correctement dans des environnements de contrôle d’exécution (AppLocker / App Control for Business), la conception de la distribution et de la mise à jour automatique intégrant la signature de code, ainsi que l’investigation des cas où une application ne démarre pas chez un client.

• Développement d’applications Windows
• Modification et maintenance de logiciels Windows existants
• Investigation de bugs et analyse des causes
• Contact

Références

Articles associés

Articles récents partageant les mêmes étiquettes, pour approfondir des sujets proches.

Sujets associés

Ces pages replacent le sujet dans un contexte plus large de services et de décisions.

Services liés à ce sujet

Cet article est directement lié aux services suivants.

Questions fréquentes

Questions souvent posées lors d’une consultation sur le sujet de cet article.

AppLocker n'est-il pas inutilisable avec l'édition Pro ?

Cette idée reçue est dépassée. Depuis la KB 5024351, sur Windows 10 version 2004 et ultérieure ainsi que sur toutes les éditions de Windows 11, l'application forcée d'une stratégie AppLocker ne nécessite plus d'édition particulière. L'ancienne restriction — « l'application forcée via une distribution par stratégie de groupe n'est possible que sur les éditions Enterprise et Server » — ne s'applique plus qu'aux versions antérieures à Windows 10 2004 et jusqu'à Windows Server 2019 (et même dans ce cas, une distribution via MDM fonctionne sur toutes les éditions). Même dans un environnement composé essentiellement de postes Pro de PME, AppLocker fait désormais partie des options possibles.

Faut-il acheter un certificat de signature de code EV ?

Du point de vue des règles d'éditeur d'AppLocker et d'App Control for Business, un certificat OV (validation d'organisation) comme un certificat EV permettent tous deux d'écrire des règles basées sur les informations du signataire. Notez par ailleurs que l'idée selon laquelle « avec un certificat EV, l'avertissement SmartScreen disparaît dès la première exécution » est dépassée : aujourd'hui, un fichier signé en EV doit être envisagé, tout comme en OV, sur la base d'une accumulation de réputation (ce point est détaillé dans un autre article, « Windows SmartScreen et la signature de code »). Ce qui compte, plus que le type de certificat, c'est de signer l'ensemble des binaires — pas seulement l'exe, mais aussi les DLL et l'installateur — avec un sujet cohérent, d'y ajouter un horodatage, et de garder les informations d'éditeur stables lors du renouvellement du certificat. Les règles d'éditeur s'appuient sur ces informations de signataire ; si l'état de signature varie d'une version à l'autre, la règle du côté du client se casse.

Notre application semble avoir été bloquée chez un client, mais je ne trouve rien dans le journal. Où faut-il regarder ?

La cause la plus fréquente est que le journal à consulter est réparti en deux systèmes distincts. Un blocage d'un exe/DLL par AppLocker apparaît sous la forme de l'événement 8004 (ou 8003 en mode audit) dans le journal « AppLocker - EXE and DLL » ; les scripts et les MSI apparaissent en 8007 (ou 8006) dans le journal « AppLocker - MSI and Script ». Un blocage par App Control for Business (WDAC), en revanche, apparaît sous la forme de l'événement 3077 (ou 3076 en mode audit) dans le journal « CodeIntegrity - Operational », avec les informations de signature correspondantes enregistrées en 3089. De plus, lorsqu'un script, un MSI ou un objet COM est intercepté par App Control, cela apparaît dans le journal « AppLocker - MSI and Script » sous les événements 8029, 8036 et 8040. Lorsque vous enquêtez sans savoir quel mécanisme est en cause, comparez les journaux CodeIntegrity - Operational et ceux d'AppLocker en les alignant par horodatage.

Que faut-il faire pour que Smart App Control ne bloque pas notre application ?

En pratique, il s'agit de la signature de code. Lorsqu'une application s'exécute, Smart App Control vérifie la prédiction de sécurité établie par un service cloud ainsi que la présence d'une signature valide sur l'application, et bloque les applications jugées malveillantes ou les applications non signées dont la fiabilité ne peut être confirmée. Microsoft indique lui-même, dans ses recommandations aux développeurs, qu'il faut signer l'application avec un certificat valide. Attention toutefois à l'algorithme de signature : la vérification de Smart App Control ne prend pas en charge les signatures en cryptographie sur courbes elliptiques (ECC), et seules les applications signées avec un certificat basé sur RSA peuvent être autorisées à s'exécuter. Smart App Control n'est pas une fonctionnalité de gestion d'entreprise, mais une protection destinée aux utilisateurs individuels de Windows 11 ; son activation ou sa désactivation est décidée automatiquement à partir d'un mode d'évaluation, donc côté distribution, il est plus prudent de partir du principe qu'« un exécutable non signé peut ne pas fonctionner sur un PC personnel ».

Profil de l’auteur

Page de présentation de l’auteur de l’article.

Go Komura

Représentant de KomuraSoft LLC

Spécialisé dans le développement de logiciels Windows, le conseil technique et l’analyse de pannes, notamment pour les systèmes existants et les incidents difficiles à reproduire.