App Control for Business : architecture, politiques et stratégie de déploiement

L’essentiel

App Control for Business applique des politiques d’intégrité du code aux exécutables, bibliothèques, scripts et pilotes selon les options choisies. Une policy de base peut être complétée par des supplemental policies sans reconstruire toute la confiance.

Les règles peuvent faire confiance à un éditeur, un certificat intermédiaire, un nom de fichier signé, un chemin sous conditions ou un hachage. Plus la règle est précise, plus elle demande de maintenance; plus elle est large, plus son risque doit être justifié.

Je déploie d’abord en Audit, collecte et qualifie les événements, corrige les gaps, teste le rollback puis passe en Enforced par vagues. Audit n’est pas une formalité: il constitue l’inventaire réel des dépendances.

App Control for Business applique des politiques d’intégrité du code aux exécutables, bibliothèques, scripts et pilotes selon les options choisies. Une policy de base peut être complétée par des supplemental policies sans reconstruire toute la confiance.

Pourquoi cette technologie existe

Une politique de base établit les règles et options principales. Les politiques supplémentaires peuvent élargir les autorisations si la base les accepte, ce qui facilite la délégation et la maintenance par domaine applicatif.

Le multiple policy format fournit des PolicyID distincts et permet de gérer plusieurs politiques actives. Les identifiants, versions et friendly names sont conservés dans un registre de changement pour comprendre la combinaison réellement appliquée.

Les règles Publisher résistent mieux aux mises à jour lorsque la signature et le niveau choisi restent stables. Les règles FilePublisher ajoutent le nom et la version; les hachages sont précis mais doivent changer à chaque binaire.

App Control for Business s’appuie sur la chaîne Policy → CSP → CI → Events. Comprendre le rôle de chaque étape permet de distinguer la demande envoyée, le traitement réellement effectué et l’état finalement observé.

Les dépendances importantes sont inventaire des applications et propriétaires, Windows supporté et firmware sain, canaux d’événements collectés, référentiel XML versionné. Elles font partie du fonctionnement de la technologie: leur absence peut expliquer un résultat sans remettre en cause le composant étudié.

Les cas limites les plus utiles à connaître sont Trop d’événements Audit, Application non signée et DLL bloquée. Ils montrent où le modèle nominal peut diverger et quelles données permettent de lire cette divergence.

Le parcours devient plus concret en suivant les composants dans leur ordre réel. Policy ouvre la séquence: Base et supplemental définissent la confiance. CSP prend ensuite le relais: Intune distribue la politique au poste. Le traitement se poursuit avec CI, où Code Integrity évalue le binaire à l’exécution. Enfin, Events ferme la boucle: Audit et blocages alimentent les décisions. Cette lecture évite de confondre un ordre envoyé avec son exécution, puis son exécution avec l’état restitué à l’administrateur. Elle indique aussi où chercher l’heure, l’identité et le résultat qui permettront de rapprocher deux observations.

Les limites se comprennent mieux à partir de situations concrètes. « Trop d’événements Audit » conduit d’abord à vérifier Signer, éditeur et fréquence, car la cause possible est Inventaire initial large. Pour « Application non signée », la preuve utile devient Hash et propriétaire. Les cas « DLL bloquée » et « Policy inattendue active » montrent enfin que deux symptômes proches peuvent appartenir à des phases différentes. Cette distinction n’est pas un détour de dépannage: elle fait partie du modèle de fonctionnement et explique la manière dont App Control for Business expose ses états, ses délais et ses erreurs.

Dans un environnement réel, les conditions inventaire des applications et propriétaires, Windows supporté et firmware sain, canaux d’événements collectés, référentiel XML versionné doivent être réunies en même temps. La validation porte ensuite sur Créer une politique base avec identifiant unique, Déployer en Audit sur une cohorte, Collecter et qualifier les événements et Ajouter des règles minimales justifiées. Ce croisement est important: un prérequis confirme que le scénario peut fonctionner, alors qu’un contrôle de validation prouve qu’il a effectivement fonctionné. Il reste donc possible d’avoir une plateforme éligible mais mal configurée, ou une première exécution réussie dont l’état n’est pas encore visible dans le service. Le modèle présenté dans cet article sert précisément à lire ces écarts sans attribuer trop vite le résultat au mauvais composant. Il donne aussi au support un vocabulaire commun pour décrire l’étape atteinte et la preuve encore manquante.

Architecture, composants et flux de données

Une politique de base établit les règles et options principales. Les politiques supplémentaires peuvent élargir les autorisations si la base les accepte, ce qui facilite la délégation et la maintenance par domaine applicatif.

Le multiple policy format fournit des PolicyID distincts et permet de gérer plusieurs politiques actives. Les identifiants, versions et friendly names sont conservés dans un registre de changement pour comprendre la combinaison réellement appliquée.

Les règles Publisher résistent mieux aux mises à jour lorsque la signature et le niveau choisi restent stables. Les règles FilePublisher ajoutent le nom et la version; les hachages sont précis mais doivent changer à chaque binaire.

Prérequis, compatibilité et limites de support

Le fonctionnement décrit suppose inventaire des applications et propriétaires, Windows supporté et firmware sain, canaux d’événements collectés, référentiel XML versionné, processus de demande d’autorisation. Ces conditions permettent de distinguer une limite de App Control for Business d’un scénario simplement non éligible.

• inventaire des applications et propriétaires
• Windows supporté et firmware sain
• canaux d’événements collectés
• référentiel XML versionné
• processus de demande d’autorisation
• groupe Audit représentatif
• rollback testé hors ligne

Cycle de fonctionnement, étape par étape

Le cycle de App Control for Business traverse Policy → CSP → CI → Events. La procédure détaille ce que produit chaque composant et la preuve attendue avant de passer à l’étape suivante.

Dans App Control for Business, les étapes « Identifier les composants », « Observer le traitement », « Relier les états », « Valider le modèle » séparent l’intention, son transport, son traitement et le résultat final.

Fonctionnement détaillé de App Control for Business

Une politique de base établit les règles et options principales. Les politiques supplémentaires peuvent élargir les autorisations si la base les accepte, ce qui facilite la délégation et la maintenance par domaine applicatif.

Le multiple policy format fournit des PolicyID distincts et permet de gérer plusieurs politiques actives. Les identifiants, versions et friendly names sont conservés dans un registre de changement pour comprendre la combinaison réellement appliquée.

Les règles Publisher résistent mieux aux mises à jour lorsque la signature et le niveau choisi restent stables. Les règles FilePublisher ajoutent le nom et la version; les hachages sont précis mais doivent changer à chaque binaire.

• inventaire des applications et propriétaires
• Windows supporté et firmware sain
• canaux d’événements collectés
• référentiel XML versionné

Traitement, exploitation et cas limites de App Control for Business

Les règles de chemin nécessitent une analyse des droits d’écriture. Autoriser un répertoire modifiable par un utilisateur donne indirectement la possibilité d’y déposer du code approuvé par le chemin.

Le mode Audit permet l’exécution et génère des événements qui auraient été bloqués. Le mode Enforced bloque; les deux doivent être testés avec scripts, DLL, installateurs, pilotes et composants de boot selon les options activées.

Intune propose des contrôles intégrés ou l’import XML via Endpoint security App Control for Business. Le CSP ApplicationControl transporte et gère les politiques; je garde le XML source, sa version et son empreinte hors du portail.

• Tester Enforced sur le laboratoire
• Valider rollback et support
• Étendre par anneaux avec surveillance

Lire les états propres à App Control for Business

Le canal Microsoft-Windows-CodeIntegrity/Operational montre activation, audit et blocage. Les canaux AppLocker MSI and Script et EXE and DLL complètent l’analyse pour les scripts et le Managed Installer.

Les événements d’audit sont transformés en demandes applicatives avec propriétaire, source, signature, prévalence, criticité et décision. Je n’ajoute pas automatiquement toute ligne observée à l’allowlist.

Le rollback est déployé et testé avant Enforced. Une politique AllowAll temporaire ou une politique de remplacement doit respecter la procédure Microsoft, les signatures éventuelles et le mode de déploiement utilisé.

• Trop d’événements Audit — Signer, éditeur et fréquence
• Application non signée — Hash et propriétaire
• DLL bloquée — CodeIntegrity event
• Policy inattendue active — CiTool -lp

Pilote et suivi opérationnel de App Control for Business

Le pilote couvre le périmètre App Control for Business, WDAC, Intune, Code Integrity et contrôle Créer une politique base avec identifiant unique. Déployer en Audit sur une cohorte. Collecter et qualifier les événements. Les résultats sont segmentés selon les populations réellement concernées par App Control for Business.

Les cas d’échec « Trop d’événements Audit », « Application non signée », « DLL bloquée » sont reproduits lorsque c’est possible. Ils vérifient que l’écart reste visible et que la procédure indique une preuve exploitable.

Le suivi après déploiement conserve Audit avant Enforced, ne pas autoriser un chemin utilisateur inscriptible, traiter les drivers séparément, versionner chaque PolicyID. Une évolution de version, de licence ou de dépendance déclenche une nouvelle lecture de ces points.

Interfaces d’observation, commandes et exemples

Les exemples rendent visibles Créer une politique base avec identifiant unique. Déployer en Audit sur une cohorte. Collecter et qualifier les événements. Ajouter des règles minimales justifiées. Leur intérêt est d’identifier le producteur de chaque donnée et le moment où elle est mise à jour.

Pour App Control for Business, les interfaces documentées restent la référence de conception. Les fichiers, tâches ou clés observés localement servent à expliquer un état précis et peuvent évoluer avec le composant.

# Collecte de diagnostic
$ErrorActionPreference = 'Stop'
try {
  CiTool.exe -lp -json
  Get-WinEvent -LogName 'Microsoft-Windows-CodeIntegrity/Operational' -MaxEvents 150 |
    Select-Object TimeCreated,Id,LevelDisplayName,Message
  Get-WinEvent -LogName 'Microsoft-Windows-AppLocker/MSI and Script' -MaxEvents 100 |
    Select-Object TimeCreated,Id,LevelDisplayName,Message
} catch { Write-Error "Collecte App Control impossible : $($_.Exception.Message)"; exit 1 }

Observabilité : où lire l’état réel

La chronologie de App Control for Business relie Policy, CSP, CI, Events. Les heures et identifiants communs permettent de savoir si les états appartiennent à la même tentative.

La collecte commence par Créer une politique base avec identifiant unique. Déployer en Audit sur une cohorte. Collecter et qualifier les événements. Ajouter des règles minimales justifiées. Ces contrôles conservent l’état qui explique le symptôme avant une nouvelle évaluation.

Les résultats sont lus avec les causes « Inventaire initial large », « Aucune chaîne publisher », « Option DLL activée » en tête, sans déduire une correction d’un code ou d’un statut isolé.

• Créer une politique base avec identifiant unique.
• Déployer en Audit sur une cohorte.
• Collecter et qualifier les événements.
• Ajouter des règles minimales justifiées.
• Tester Enforced sur le laboratoire
• Valider rollback et support
• Étendre par anneaux avec surveillance

Validation du modèle et cas d’usage

Le modèle est cohérent lorsque Créer une politique base avec identifiant unique, Déployer en Audit sur une cohorte, Collecter et qualifier les événements et Ajouter des règles minimales justifiées. Ces contrôles relient la configuration du service au résultat réellement observé.

• Créer une politique base avec identifiant unique.
• Déployer en Audit sur une cohorte.
• Collecter et qualifier les événements.
• Ajouter des règles minimales justifiées.
• Tester Enforced sur le laboratoire
• Valider rollback et support
• Étendre par anneaux avec surveillance

Limites, modes de panne et lecture des erreurs

Les écarts connus de App Control for Business incluent Trop d’événements Audit, Application non signée, DLL bloquée, Policy inattendue active. Le tableau les replace dans leur phase et précise la donnée à contrôler.

Adoption progressive, réversibilité et vigilance

L’adoption de App Control for Business commence sur le périmètre App Control for Business, WDAC, Intune, Code Integrity, Under the Hood — Policy, CSP, CI, Events, inventaire des applications et propriétaires, Windows supporté et firmware sain, canaux d’événements collectés. Les limites et actions de réversibilité ci-dessous cadrent la progression.