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. » — lors de la distribution d’une application métier, la cause n’est pas seulement un défaut de l’application elle-même : le contrôle d’exécution des applications de l’environnement client peut aussi en être responsable. Il arrive que l’exe démarre et que seules les DLL ou les scripts livrés avec lui soient arrêtés.

Dans ce cas, plutôt que de changer d’emblée la signature ou l’emplacement d’installation, il faut isoler quel mécanisme a arrêté quel fichier, et sur quel fondement.

Cet article organise le contrôle d’exécution de Windows du point de vue de celui qui conçoit et distribue l’application. Après avoir distingué AppLocker, App Control for Business (anciennement WDAC = Windows Defender Application Control), Smart App Control et SmartScreen, il enchaîne sur les blocages typiques, la lecture des journaux d’événements et les mesures à prendre avant la distribution. Il clôt par une procédure destinée au service informatique qui déploie ces contrôles sur ses propres PC.

1. D’abord la conclusion

• Distinguez d’abord les quatre mécanismes, puis confirmez la cible dans le journal. L’avertissement SmartScreen, le contrôle AppLocker par utilisateur ou groupe, le contrôle App Control à l’échelle de la machine et la protection Smart App Control pour les PC personnels ne sont pas la même chose. Pour un exe/DLL AppLocker, l’enquête s’articule autour de 8004 ; pour App Control, autour de 3077 et des informations de signature 3089. Pour les scripts et les MSI, consultez aussi l’autre journal.¹²
• Côté distribution, faites une application dont les règles d’autorisation restent cohérentes après une mise à jour. Le cœur de cela est une signature cohérente qui couvre non seulement l’exe, mais aussi les DLL, l’installateur et les scripts livrés. Alignez aussi les informations d’éditeur, les attributs de fichier, l’emplacement d’installation et le flux de mise à jour automatique. Même sur un PC qui n’est pas sous gestion d’entreprise, Smart App Control peut arrêter une application non signée.³⁴
• Côté déploiement, faites tourner un cycle métier complet en mode audit avant de passer à l’application forcée. Choisissez App Control lorsque c’est possible, et AppLocker lorsqu’un contrôle par utilisateur est nécessaire. On ne peut pas se dire « les PC du client sont en Pro, cela ne nous concerne pas ». Depuis la KB 5024351, sur Windows 10 2004 et ultérieur ainsi que sur Windows 11, l’application forcée d’AppLocker ne nécessite plus d’édition particulière, et App Control prend en charge toutes les éditions client.³⁵

Lecture selon l’objectif

Avec PowerShell, un script n’est pas toujours bloqué complètement : il peut s’exécuter en mode de langage contraint, et seules certaines opérations échouent. Cette différence est aussi traitée au chapitre 4.²

Dans le diagramme, un trait continu marque une relation qui vaut toujours et un trait pointillé une relation conditionnelle (les conditions figurent dans l’explication de chaque relation sur la page de détail). La liste complète des relations (36 au total, avec preuve et niveau de certitude) et les définitions des concepts principaux sont rassemblées sur la page de détail de la carte des connaissances (en japonais). Données : JSON-LD / Turtle

2. Distinguer les quatre mécanismes

Les produits aux noms proches se séparent selon « la cible », « la façon d’agir » et « qui gère ». Commencez par voir s’il s’agit de répondre à un avertissement, ou de confronter le fichier aux règles d’autorisation d’un administrateur.

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

SmartScreen est un mécanisme qui avertit d’après la réputation d’un fichier. Il agit par défaut même sans administrateur pour écrire une règle, et l’utilisateur peut en général passer l’avertissement et exécuter.

Toutefois, si une stratégie de gestion interdit de passer l’avertissement, SmartScreen devient lui aussi, dans les faits, un blocage. « C’est un avertissement, donc on peut forcément exécuter » n’est pas le bon sens.

Côté distribution, les mesures se distinguent de « faire écrire une règle d’autorisation par le client » comme pour AppLocker. Avec SmartScreen, la signature et l’accumulation de réputation sont au centre. Le détail est traité dans « Pourquoi Windows affiche « Windows a protégé votre PC » ». Les sections 2.2 à 2.4 qui suivent portent sur des mécanismes qui bloquent l’exécution, plutôt qu’ils n’avertissent.

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

Sur quel fondement, et l’exécution de qui

AppLocker a été introduit avec Windows 7. Les fondements des règles sont les attributs du certificat de signature de code (l’éditeur), les attributs de fichier issus des métadonnées de signature (nom de fichier d’origine, version), le hachage et le chemin du fichier. La stratégie peut s’appliquer à l’ordinateur entier, ou à des utilisateurs ou groupes spécifiques.³

Séparer « pouvoir créer des règles » et « pouvoir les appliquer de force »

Les exigences d’édition se comprennent plus clairement en séparant ces deux points. 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.⁵

Sur les Windows plus anciens, la différence selon le mode de distribution subsiste. Sur Windows 10 antérieur à 2004 et jusqu’à Windows Server 2019 inclus, les conditions historiques restent : l’application forcée d’une stratégie distribuée par stratégie de groupe n’est possible que sur les éditions Enterprise et Server ; une distribution MDM fonctionne sur toutes les éditions.⁵

Même sous Pro, on peut créer des règles. L’ancienne restriction portait surtout sur la possibilité d’appliquer de force, et une distribution MDM permettait déjà alors d’appliquer de force sous Pro. Les types de règles — fichiers exécutables, Windows Installer, scripts, DLL, applications empaquetées — ne changent pas non plus selon l’édition.⁵

Il y a aussi une condition distincte de l’édition. Si le service Application Identity (AppIDSvc) n’est pas en cours d’exécution, les règles ne sont pas évaluées. On le vérifie au chapitre 6, en même temps que la préparation de l’audit.

Positionnement en tant que fonction de sécurité

Microsoft indique explicitement qu’AppLocker ne satisfait pas les critères de service (servicing criteria) de l’MSRC pour une fonction de sécurité. Même si une technique de contournement est trouvée, ce seul fait ne suffit pas à la traiter comme une vulnérabilité de sécurité. C’est aussi un point de distinction avec App Control, traité ensuite.³

2.3. App Control for Business — le choix de fond en tant que fonction de sécurité

Un mécanisme qui s’applique à toute la machine

App Control for Business est le nom actuel du mécanisme qui, sous Windows 10, s’appelait « intégrité du code configurable » dans le cadre de Device Guard. On l’a longtemps appelé WDAC. La stratégie s’applique à toute la machine et affecte tous les utilisateurs de l’appareil. Celle-ci est conçue comme une fonction de sécurité définie par les critères de service de l’MSRC.³

Les fondements des règles se structurent ainsi.³

Conditions d’usage et modes de distribution

Une stratégie peut être créée et appliquée sur n’importe quelle édition client de Windows 10/11, ou sur Windows Server 2016 et ultérieur. Pour la distribution, on peut utiliser un MDM tel qu’Intune, Configuration Manager, ou PowerShell. La stratégie de groupe est aussi possible, mais uniquement au format de stratégie unique qui fonctionne sur Windows Server 2016/2019.³

Comment le distinguer d’AppLocker

Microsoft recommande d’utiliser App Control lorsque l’on peut l’implémenter avec App Control. App Control continue d’être amélioré, tandis qu’AppLocker reçoit des correctifs de sécurité mais plus de nouvelles fonctionnalités.³

AppLocker convient lorsqu’on veut distribuer la même stratégie à un environnement mixte qui inclut d’anciens Windows, ou lorsqu’on veut faire varier les règles par utilisateur ou groupe sur un PC partagé. On peut aussi s’en servir en complément d’App Control, pour ajouter une restriction par utilisateur.³

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

Smart App Control est une protection destinée aux utilisateurs individuels de Windows 11. À l’exécution, il vérifie la prédiction de sécurité d’un service cloud et la présence d’une signature valide. Il bloque les applications jugées malveillantes, ainsi que celles qui n’ont pas de signature valide et dont la confiance ne peut être confirmée.⁴

Sur un PC neuf, il commence en mode d’évaluation ; Windows juge s’il convient à cet utilisateur, puis l’active ou le désactive. Chez un utilisateur susceptible d’être souvent bloqué, comme un développeur, il se désactive automatiquement.⁴

Le point à retenir côté distribution est qu’un contrôle d’exécution agit même sur un PC pour lequel le service informatique n’a écrit aucune stratégie. Les clients TPE ou indépendants ne sont pas hors sujet. Une application non signée peut s’arrêter, et Microsoft indique aussi aux développeurs de signer avec un certificat valide. Le choix du certificat est structuré au chapitre 5.⁴

3. Les schémas typiques dans lesquels votre application est bloquée

Vérifiez non seulement « le binaire principal démarre-t-il », mais aussi l’installation, le chargement des DLL, les scripts, les plug-ins et la mise à jour automatique. Les schémas qui posent souvent problème en développement sur mesure et en distribution de packages sont les suivants.

La cause commune : le fondement des règles d’autorisation n’est pas stable

Ce que le tableau a en commun, c’est que le côté qui autorise a besoin d’un fondement (signature, chemin, hachage) que le côté qui distribue ne fournit pas de façon stable.

Par exemple, signer seulement l’exe ne permet pas d’appliquer la même règle d’éditeur à une DLL non signée. Autoriser par une règle de hachage individuelle impose de mettre à jour la règle dès que le binaire change. Ce qui semble dû au contrôle du client est parfois, en réalité, un livrable ou une méthode de mise à jour qui rend les règles fragiles.

Une fois les candidats réduits d’après les symptômes, confirmez dans le journal suivant le fichier réellement arrêté. Les mesures se pensent après.

4. Confirmer ce qui s’est passé dans le journal

Dans le journal d’événements, séparez « le fait d’avoir été arrêté » et « ce qu’il faut corriger ». L’entrée se fait par deux familles, AppLocker et CodeIntegrity, mais le point important est qu’un événement App Control peut aussi être enregistré sous un nom de journal AppLocker.²

4.1. Les événements AppLocker

Ouvrir le journal et choisir le type de cible

L’Observateur d’événements s’ouvre en recherchant « Observateur d’événements » dans le menu Démarrer, ou en saisissant eventvwr.msc dans Exécuter.¹

Observateur d’événements > Journaux des applications et des services > Microsoft > Windows > AppLocker > EXE and DLL / MSI and Script / Packaged app-Deployment / Packaged app-Execution

Dans un environnement anglais, il s’agit de Applications and Services Logs > Microsoft > Windows > AppLocker.

Pour extraire avec PowerShell, ouvrez une session administrateur et exécutez la commande suivante. Cet exemple ne récupère que l’audit et le blocage des exe/DLL des dernières 24 heures. Les scripts et les MSI n’y figurent pas.

# Extraire les blocages (8004) et les audits (8003) AppLocker 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

Correspondance à une règle de refus, ou règles d’autorisation insuffisantes

L’événement enregistre le chemin du fichier cible, le résultat autorisé ou bloqué, le type de règle (chemin, hachage, éditeur), le nom de la règle, et le SID de l’utilisateur ou du groupe.¹

Toutefois, dans une exploitation de type liste d’autorisation, on voit surtout des « refus implicites » : aucune règle d’autorisation n’a correspondu.

Un 8004 donne le fait du blocage et la cible, mais un refus implicite ne se diagnostique pas à partir du seul nom de règle. Il ne suffit pas de lire l’événement : il faut le recouper avec la stratégie en vigueur.

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

Les journaux se séparent entre exe, DLL, pilotes, et les scripts

Le contrôle des exe, DLL et pilotes se consulte dans le journal CodeIntegrity suivant. Le contrôle des MSI, scripts et COM s’enregistre dans le journal AppLocker - MSI and Script déjà vu.²

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

# Voir ensemble les blocages (3077) et audits (3076) App Control, 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

Cette commande récupère les 3076, 3077 et 3089 de CodeIntegrity. Pour les MSI, scripts et COM, consultez aussi AppLocker - MSI and Script à part, d’après le tableau ci-dessous. Tant que vous ne savez pas quel mécanisme est en cause, recoupez AppLocker et CodeIntegrity sur la même plage horaire.

Avec 3089, confirmer la signature réellement évaluée

Un 3089 est généré pour chaque signature du fichier. Pour un fichier non signé, un événement avec un nombre de signatures égal à 0 est émis. La correspondance avec 3076, 3077, etc. se fait par ID d’activité de corrélation.²

Les problèmes du type « nous avons signé, mais c’est traité comme non signé » ou « une signature d’un ancien certificat reste » se confirment dans ces informations de signature. Recoupez l’état du fichier que vous avez vérifié côté distribution avec celui qui a été évalué chez le client.

Même un 8029 ne signifie pas forcément que PowerShell s’arrête complètement

8029 indique un blocage de script, mais l’application forcée réelle est déléguée à l’hôte de scripts. PowerShell n’arrête pas complètement un script non autorisé par la stratégie : il l’exécute en mode de langage contraint (Constrained Language Mode).²

Dans ce mode, la création d’objets .NET est largement restreinte. D’où le symptôme « le script a démarré, mais une seule ligne a échoué en cours de route ». Pour un script livré, ne jugez pas seulement au démarrage. La pratique de la signature est traitée dans « Politique d’exécution PowerShell et signature de scripts ».

Notez que l’édition Windows Server Core n’a pas le journal AppLocker - MSI and Script. Lorsque vous enquêtez sur une application serveur, faites aussi attention à la présence du journal.²

5. Mesures côté distribution — une application pour laquelle les règles sont « faciles à écrire »

L’objectif est de distribuer dans un état où le service informatique du client peut écrire des règles d’autorisation stables. La signature est la mesure centrale, mais cela ne signifie pas que, signature ou non, l’application s’exécute indépendamment de la stratégie du client. Ce qu’il faut aligner se répartit en six points.

Cette préparation vaut aussi pour Smart App Control. Un binaire signé, dont la réputation s’accumule, a moins de chances d’être pris dans le blocage automatique d’un PC personnel.⁴

5.1. Lorsque vous prenez un certificat de signature de code pour la première fois

Choisir un certificat RSA d’une autorité de certification de confiance

Pour une distribution à des clients externes, choisissez un certificat de signature de code basé sur RSA, émis par une autorité de certification publique (CA commerciale). Un certificat auto-signé ou une CA interne ne se vérifie pas sur un PC client qui ne fait pas confiance à cette CA, et n’est pas non plus pris en charge par Smart App Control.⁶

Vérifiez aussi l’algorithme. La vérification de signature de Smart App Control ne prend pas en charge les signatures ECC (courbes elliptiques). Une signature ECC peut être traitée, sur un PC personnel, comme l’équivalent d’une absence de signature.⁶

Avec App Control aussi, les règles basées sur le signataire ne prennent en charge que RSA (jusqu’à 4096 bits). Tenter d’autoriser une signature ECDSA par une règle d’éditeur enregistre VerificationError = 23 dans le 3089 correspondant. Choisir l’ECC seulement parce que « c’est plus récent et plus fort » crée un problème de compatibilité avec le contrôle d’exécution.⁷

OV et EV : du point de vue des règles d’éditeur, les deux conviennent

Parmi les certificats de CA publiques, il y a l’OV, avec vérification de l’existence de l’entreprise, et l’EV, avec un examen plus strict. Les règles d’éditeur d’AppLocker et d’App Control se créent avec l’un comme avec l’autre.

App Control a une option de règle Required:EV Signers, mais la documentation officielle la dit non prise en charge à ce jour. Il n’y a donc pas de raison de choisir l’EV pour le contrôle d’exécution traité ici. Le rapport avec SmartScreen est structuré à part dans « Pourquoi Windows affiche « Windows a protégé votre PC » ».⁷

Estimer, au-delà du prix du certificat, le stockage de la clé privée et l’exploitation de la signature

Le coût varie selon la CA et la durée de validité. Dans le devis, vérifiez, en plus du certificat lui-même, le jeton, le HSM, ou les frais du service de signature cloud proposé par la CA.

Pour les certificats émis à compter du 1er juin 2023, les exigences du CA/Browser Forum imposent, OV comme EV, de générer et stocker la clé privée dans un matériel équivalent FIPS 140-2 niveau 2 ou supérieur (HSM ou jeton USB).⁸

Si vous signez automatiquement dans une CI/CD, un service de signature cloud est parfois plus simple à configurer qu’un jeton physique. Avant d’acheter le certificat, il est pratique de discuter aussi le flux, du build à la signature.

Signer tous les binaires et ajouter un horodatage

La signature Authenticode ne se limite pas à l’exe : alignez vos DLL compilées, l’installateur (MSI / exe d’installation) et les scripts livrés. Avec des métadonnées de signature, le client peut écrire une règle qui tient aux mises à jour, du type « ce produit de cet éditeur, quelle que soit la version ».³

L’horodatage se met pour que la signature reste valide après l’expiration du certificat. Un exemple minimal avec signtool du Windows SDK est le suivant.

:: Signer (hacher en SHA-256 et ajouter un horodatage RFC 3161)
signtool sign /fd sha256 /tr <URL du serveur d'horodatage> /td sha256 /a MyApp.exe

:: Vérifier la signature (valider selon la stratégie Authenticode et afficher le détail)
signtool verify /pa /v MyApp.exe

Pour le serveur d’horodatage, utilisez l’URL indiquée par la CA chez qui vous avez acheté. Si vous utilisez la clé d’un jeton ou d’un HSM, vérifiez aussi dans la documentation de la CA la spécification CSP/KSP. Les DLL comme l’installateur se signent avec la même commande, donc le flux consiste à signer et vérifier en lot à la fin du build.

5.2. Traiter un changement de certificat ou d’attributs de fichier comme un changement de règle chez le client

Même avec une signature cohérente, une version mise à jour s’arrête si ce que la règle compare a changé. Il ne s’agit pas seulement du sujet du certificat ou de la chaîne. Le nom de produit, le nom de fichier d’origine et la version viennent de la ressource de version de chaque fichier (informations d’assembly), pas du certificat.

Le Publisher d’App Control est « certificat PCA (en général un cran sous la racine) + CN du certificat feuille » ; FilePublisher y ajoute l’attribut FileName du fichier signé (par défaut OriginalFileName) et une version minimale.⁷

Pour le client, ces changements ressemblent à « après la mise à jour, cela ne démarre plus, et seulement dans cet environnement ». Lorsque vous changez la dénomination, la CA ou les attributs de produit et de fichier, mettez dans les notes de version, côte à côte, les informations de signature anciennes et nouvelles (sujet, CA émettrice), et prévenez à l’avance. Cela permet au service informatique du client d’ajouter ou de mettre à jour les règles d’autorisation.

5.3. Stabiliser l’emplacement et le flux de mise à jour automatique

Placez les exécutables sous Program Files, par exemple, et évitez un design qui déploie un exe/DLL dans %TEMP% ou %APPDATA% à l’exécution pour le lancer. Un design qui s’exécute dans un emplacement où l’utilisateur peut écrire s’accorde mal avec un environnement à règles de chemin.

Pour la mise à jour automatique, signez aussi le programme de mise à jour lui-même, et faites un flux qui remplace un binaire signé par un binaire signé. Le détail de la conception de sécurité est dans « Conception de la sécurité des mises à jour automatiques ».

Dans une distribution par Intune ou Configuration Manager, si le client a configuré l’agent de distribution comme programme d’installation géré, on peut autoriser les binaires entrés par ce chemin. Ce n’est pas automatique du seul fait de distribuer via Intune : une configuration explicite de l’administrateur est le préalable. Prévoir un MSI compatible avec l’installation silencieuse donne cette option au client.

5.4. Rassembler dans le guide d’installation les informations pour écrire les règles

Dans le guide d’installation remis au client, indiquez le sujet de la signature, la liste des binaires nécessaires à l’exécution, et le chemin d’installation. Ce sont les fondements dont le service informatique a besoin pour écrire les règles d’autorisation.

En cas de blocage, faites en sorte de pouvoir demander une vérification en citant les noms de journaux et les ID d’événements du chapitre 4. Cela réduit les allers-retours du type « ça ne démarre pas » et permet de recouper tout de suite le fichier cible et les informations de signature.

6. Points essentiels côté déploiement (service informatique)

Le schéma de base côté déploiement est, dans cet ordre : choisir la technique → confirmer l’impact par un audit → aligner les règles d’autorisation puis appliquer de force → gérer les exceptions dans la durée. L’important est de ne pas commencer à bloquer d’un coup sur tous les postes.

6.1. Choisir la technique selon l’usage, et aligner les préalables de l’audit

Le principe est App Control for Business. Combinez AppLocker lorsqu’un contrôle par utilisateur est nécessaire sur un PC partagé, ou lorsque d’anciens OS sont mélangés.³ Sur un PC à usage fixe tel qu’un kiosque, restreindre d’abord l’usage par une limitation du shell simplifie les règles. Voir aussi « Verrouiller un poste professionnel en mode kiosque — Choisir entre Assigned Access et Shell Launcher, et concevoir l’exploitation ».

L’audit rassemble, sans arrêter le métier, « ce qui aurait été bloqué si l’application forcée était active ». Pour AppLocker, le fonctionnement d’AppIDSvc est un préalable : si le service est arrêté, aucun événement d’audit n’est émis non plus. Configurez le démarrage automatique sur les postes concernés avant de commencer.

L’idée de collecter jusqu’à ce qu’un cycle métier soit passé, puis de passer à l’application forcée, est la même que pour la signature SMB ou les restrictions NTLM. Incluez les lots mensuels et annuels ; ne terminez pas la vérification sur les seules opérations quotidiennes.

6.2. AppLocker : trois étapes de l’audit à l’application forcée

1. Activer le mode audit. Dans l’éditeur de gestion des stratégies de groupe (en local, secpol.msc), ouvrez Configuration de l’ordinateur > Stratégies > Paramètres Windows > Paramètres de sécurité > Stratégies de contrôle d’application > AppLocker. Cliquez avec le bouton droit sur AppLocker, ouvrez Propriétés, et pour chaque collection de règles (fichiers exécutables, Windows Installer, scripts, applications empaquetées) choisissez « Configurer », puis « Audit uniquement ». Créez les règles par défaut de chaque collection, et configurez aussi le démarrage automatique d’AppIDSvc.

2. Rassembler les événements depuis le journal qui correspond à la cible. Pour les exe/DLL, c’est 8003 de EXE and DLL ; pour les scripts et MSI, 8006 de MSI and Script. La commande de la section 4.1 ne concerne que EXE and DLL, donc elle ne ramasse pas 8006. Pour voir les deux, extraire en séparant les journaux comme suit.¹

    # En mode audit, rassembler depuis deux journaux « ce qui aurait été bloqué »
    $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
    }
   

   Get-WinEvent renvoie une erreur pour un journal sans événement correspondant, d’où -ErrorAction SilentlyContinue dans cet exemple. Même sans sortie, vérifiez le fonctionnement du service, le journal cible et la période d’extraction. Si les applications empaquetées sont aussi concernées, ajoutez Packaged app-Deployment / Packaged app-Execution de la même façon, et vérifiez jusqu’aux lots mensuels et annuels.

3. Aligner les règles d’autorisation, puis passer à l’application forcée. Confirmez les fichiers métier nécessaires apparus en 8003 et 8006, et intégrez-les aux règles d’autorisation. Ensuite, dans le même écran Propriétés, passez à « Appliquer les règles ». Après le basculement, surveillez les blocages 8004 (exe/DLL) et 8007 (scripts et MSI).

6.3. App Control : retirer l’option d’audit pour passer à l’application forcée

Distribuez le XML de stratégie avec l’option de règle 3 (Enabled:Audit Mode). Pour la configurer, utilisez l’App Control Policy Wizard ou le cmdlet Set-RuleOption.⁷

Confirmez l’impact métier avec 3076 et 8028, alignez les règles d’autorisation, puis supprimez l’option d’audit : vous passez en mode d’application forcée. Microsoft recommande aussi de vérifier d’abord une nouvelle stratégie en mode audit.⁷

6.4. Lier les exceptions non signées à la gestion des actifs

Les anciennes applications métier que l’on continue d’utiliser non signées s’enregistrent en exception par une règle de hachage. Cette liste est aussi la liste des actifs à renouveler. Ne vous arrêtez pas à créer l’exception : reliez-la à la gestion des actifs et revoyez-la chaque année.

7. Synthèse

La réponse au contrôle d’exécution se structure en trois points : distinguer le mécanisme, confirmer dans le journal, et produire un livrable dont les règles d’autorisation restent stables.

SmartScreen est essentiellement un avertissement, mais sous une stratégie qui interdit de passer outre, il devient un blocage. Distinguez le traitement de celui d’AppLocker, d’App Control et de Smart App Control. La restriction d’édition d’AppLocker a été assouplie, et App Control s’utilise sur toutes les éditions client. Smart App Control agit aussi sur un PC personnel, donc « c’est du Pro » ou « il n’y a pas de service informatique » ne suffit pas à dire que cela ne concerne pas.⁵³⁴

Lorsqu’une application ne démarre pas, prenez pour entrée 8004 d’AppLocker, 3077 et 3089 d’App Control, et recoupez aussi les journaux des scripts et MSI. Si seule une fonction échoue, vérifiez aussi le mode de langage contraint de PowerShell.¹²

Côté distribution, alignez une signature cohérente de tous les binaires, un horodatage, des informations d’éditeur et des attributs de fichier stables, un emplacement standard, une mise à jour automatique signée, et un guide d’installation. Le principe est de faire une application pour laquelle le client écrit facilement des règles d’autorisation, et les maintient après une mise à jour.

Côté déploiement, faites tourner un cycle métier avec 8003 et 8006 d’AppLocker, 3076 et 8028 d’App Control, puis passez à l’application forcée. Aligner distribution et exploitation réduit les cas « cela ne fonctionne que chez le client ».

Articles associés

• Pourquoi Windows affiche « Windows a protégé votre PC »
• Conception de la sécurité des mises à jour automatiques - Pourquoi HTTPS seul ne suffit pas
• Choisir une méthode de distribution d’application Windows - MSI/MSIX/ClickOnce/xcopy/Updater personnalisé
• Politique d’exécution PowerShell et signature de scripts — Guide pratique pour sortir de l’exploitation « on colmate avec Bypass »
• Quand votre application Windows maison est signalée comme un virus — gérer les faux positifs de Microsoft Defender et composer avec l’impact sur les performances
• Verrouiller un poste professionnel en mode kiosque — Choisir entre Assigned Access et Shell Launcher, et concevoir l’exploitation
• La solution pragmatique après la fin du support de Windows 10 — Tableau de décision ESU, LTSC et renouvellement de matériel

Domaines de conseil associés

KomuraSoft LLC traite le développement et l’évolution d’applications métier qui fonctionnent sous contrôle d’exécution (AppLocker / App Control for Business), la conception d’une distribution et d’une mise à jour automatique intégrant la signature de code, et l’investigation des cas où une application ne démarre pas chez le client.

• Développement d’applications Windows
• Maintenance et évolution de logiciels Windows existants
• Analyse de dysfonctionnements et des causes racines
• Nous contacter

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 a été mise à jour. 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 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.