Partager via

Créer une stratégie de contrôle d’application pour les appareils gérés légèrement

Remarque

Certaines fonctionnalités d’App Control for Business sont disponibles uniquement sur des versions spécifiques de Windows. En savoir plus sur la disponibilité des fonctionnalités De contrôle d’application.

Cette section décrit le processus de création d’une stratégie App Control for Business pour les appareils gérés légèrement au sein d’un organization. En règle générale, les organisations qui débutent avec App Control réussissent le mieux si elles commencent par une stratégie permissive comme celle décrite dans cet article. Les organisations peuvent choisir de renforcer la stratégie au fil du temps pour obtenir une posture de sécurité globale plus forte sur leurs appareils gérés par App Control, comme décrit dans les articles ultérieurs.

Remarque

Certaines des options App Control for Business décrites dans cette rubrique ne sont disponibles que sur Windows 10 version 1903 ou ultérieure, ou Windows 11. Lorsque vous utilisez cette rubrique pour planifier vos propres stratégies de contrôle d’application de organization, déterminez si vos clients gérés peuvent utiliser tout ou partie de ces fonctionnalités et évaluez l’impact des fonctionnalités qui peuvent être indisponibles sur vos clients. Vous devrez peut-être adapter ces conseils pour répondre aux besoins de votre organization spécifique.

Comme dans Le déploiement d’App Control for Business dans différents scénarios : types d’appareils, nous allons utiliser l’exemple de Lamna Healthcare Company (Lamna) pour illustrer ce scénario. Lamna tente d’adopter des stratégies d’application plus fortes, notamment l’utilisation d’App Control pour empêcher les applications indésirables ou non autorisées de s’exécuter sur leurs appareils gérés.

Alice Pena est la responsable de l’équipe informatique chargée du déploiement d’App Control. Lamna a actuellement des stratégies d’utilisation des applications libres et une culture de flexibilité maximale des applications pour les utilisateurs. Alice sait donc qu’elle doit adopter une approche incrémentielle du contrôle d’application et utiliser différentes stratégies pour différentes charges de travail.

Pour la plupart des utilisateurs et des appareils, Alice souhaite créer une stratégie initiale aussi souple que possible afin de réduire l’impact sur la productivité des utilisateurs, tout en offrant une valeur de sécurité.

Définir le « cercle de confiance » pour les appareils gérés légèrement

Alice identifie les facteurs clés suivants pour arriver au « cercle de confiance » pour les appareils gérés légèrement par Lamna, qui incluent actuellement la plupart des appareils des utilisateurs finaux :

  • Tous les clients exécutent Windows 10 version 1903 ou ultérieure, ou Windows 11 ;
  • Tous les clients sont gérés par Configuration Manager ou avec Intune.
  • Certaines applications, mais pas toutes, sont déployées à l’aide de Configuration Manager ;
  • La plupart des utilisateurs sont des administrateurs locaux sur leurs appareils ;
  • Certaines équipes peuvent avoir besoin de règles supplémentaires pour autoriser des applications spécifiques qui ne s’appliquent généralement pas à tous les autres utilisateurs.

Sur la base de ce qui précède, Alice définit les pseudo-règles pour la stratégie :

  1. Règles « Windows works » qui autorisent :

    • Windows
    • WHQL (pilotes de noyau tiers)
    • Applications signées du Windows Store

  2. Les règles « ConfigMgr fonctionnent » qui incluent :

    • Règles de signature et de hachage pour que les composants Configuration Manager fonctionnent correctement.
    • Autoriser la règle d’installation managée à autoriser Configuration Manager en tant que programme d’installation géré.

  3. Autoriser Intelligent Security Graph (ISG) (autorisation basée sur la réputation)

  4. Applications signées à l’aide d’un certificat émis par une autorité de certification du programme racine de confiance Windows

  5. Administration règles de chemin d’accès uniquement pour les emplacements suivants :

    • C :\Program Files*
    • C :\Program Files (x86)*
    • %windir%*

Créer une stratégie de base personnalisée à l’aide d’un exemple de stratégie de base De contrôle d’application

Après avoir défini le « cercle de confiance », Alice est prête à générer la stratégie initiale pour les appareils légèrement gérés par Lamna. Alice décide d’utiliser l’exemple SmartAppControl.xml pour créer la stratégie de base initiale, puis la personnaliser pour répondre aux besoins de Lamna.

Alice effectue ces étapes pour effectuer cette tâche :

  1. Sur un appareil client, exécutez les commandes suivantes dans une session de Windows PowerShell avec élévation de privilèges pour initialiser des variables :

    Remarque

    Si vous préférez utiliser un autre exemple de stratégie de base App Control for Business, remplacez l’exemple de chemin de stratégie par votre stratégie de base préférée dans cette étape.

    $PolicyPath = $env:userprofile+"\Desktop\"
$PolicyName= "Lamna_LightlyManagedClients_Audit"
$LamnaPolicy=Join-Path $PolicyPath "$PolicyName.xml"
$ExamplePolicy=$env:windir+"\schemas\CodeIntegrity\ExamplePolicies\SmartAppControl.xml"

  2. Copiez l’exemple de stratégie sur le bureau :

    Copy-Item $ExamplePolicy $LamnaPolicy

  3. Modifiez la stratégie pour supprimer la règle non prise en charge :

    Remarque

    SmartAppControl.xmlest disponible sur Windows 11 version 22H2 et ultérieure. Cette stratégie inclut la règle « Enabled :Conditional Windows Lockdown Policy » qui n’est pas prise en charge pour les stratégies de contrôle d’application d’entreprise et doit être supprimée. Pour plus d’informations, consultez Contrôle d’application et Contrôle d’application intelligent. Si vous utilisez un exemple de stratégie autre que SmartAppControl.xml, ignorez cette étape.

    [xml]$xml = Get-Content $LamnaPolicy
$ns = New-Object System.Xml.XmlNamespaceManager($xml.NameTable)
$ns.AddNamespace("ns", $xml.DocumentElement.NamespaceURI)
$node = $xml.SelectSingleNode("//ns:Rules/ns:Rule[ns:Option[.='Enabled:Conditional Windows Lockdown Policy']]", $ns)
$node.ParentNode.RemoveChild($node)
$xml.Save($LamnaPolicy)

  4. Donnez à la nouvelle stratégie un ID unique, un nom descriptif et un numéro de version initiale :

    Set-CIPolicyIdInfo -FilePath $LamnaPolicy -PolicyName $PolicyName -ResetPolicyID
Set-CIPolicyVersion -FilePath $LamnaPolicy -Version "1.0.0.0"

  5. Utilisez Configuration Manager pour créer et déployer une stratégie d’audit sur l’appareil client exécutant Windows 10 version 1903 ou ultérieure, ou Windows 11. Fusionnez la stratégie Configuration Manager avec l’exemple de stratégie.

    Remarque

    Si vous n’utilisez pas Configuration Manager, ignorez cette étape.

    $ConfigMgrPolicy=$env:windir+"\CCM\DeviceGuard\MergedPolicy_Audit_ISG.xml"
Merge-CIPolicy -OutputFilePath $LamnaPolicy -PolicyPaths $LamnaPolicy,$ConfigMgrPolicy
Set-RuleOption -FilePath $LamnaPolicy -Option 13 # Managed Installer

  6. Modifiez la stratégie pour définir des règles de stratégie supplémentaires :

    Set-RuleOption -FilePath $LamnaPolicy -Option 3  # Audit Mode
Set-RuleOption -FilePath $LamnaPolicy -Option 12 # Enforce Store Apps
Set-RuleOption -FilePath $LamnaPolicy -Option 19 # Dynamic Code Security

  7. Ajoutez des règles pour autoriser les répertoires Windows et Program Files :

    $PathRules += New-CIPolicyRule -FilePathRule "%windir%\*"
$PathRules += New-CIPolicyRule -FilePathRule "%OSDrive%\Program Files\*"
$PathRules += New-CIPolicyRule -FilePathRule "%OSDrive%\Program Files (x86)\*"
Merge-CIPolicy -OutputFilePath $LamnaPolicy -PolicyPaths $LamnaPolicy -Rules $PathRules

  8. Si nécessaire, ajoutez d’autres règles de signataire ou de fichier pour personnaliser davantage la stratégie pour votre organization.

  9. Utilisez ConvertFrom-CIPolicy pour convertir la stratégie App Control for Business au format binaire :

    [xml]$PolicyXML = Get-Content $LamnaPolicy
$LamnaPolicyBin = Join-Path $PolicyPath "$($PolicyXML.SiPolicy.PolicyID).cip"
ConvertFrom-CIPolicy $LamnaPolicy $LamnaPolicyBin

  10. Chargez votre xml de stratégie de base et le fichier binaire associé dans une solution de contrôle de code source, telle que GitHub ou une solution de gestion de documents comme Office 365 SharePoint.

À ce stade, Alice dispose désormais d’une stratégie initiale prête à être déployée en mode audit sur les clients managés dans Lamna.

Considérations relatives à la sécurité de cette stratégie gérée légèrement

Afin de réduire l’impact sur la productivité des utilisateurs, Alice a défini une stratégie qui fait plusieurs compromis entre la sécurité et la flexibilité des applications utilisateur. Voici quelques-uns des compromis :

  • Utilisateurs disposant d’un accès administratif

    Ce compromis est le compromis le plus percutant en matière de sécurité. Il permet à l’utilisateur de l’appareil, ou au programme malveillant s’exécutant avec les privilèges de l’utilisateur, de modifier ou de supprimer la stratégie De contrôle d’application sur l’appareil. En outre, les administrateurs peuvent configurer n’importe quelle application pour qu’elle agisse comme un programme d’installation géré, ce qui leur permettrait d’obtenir une autorisation d’application persistante pour les applications ou les fichiers binaires qu’ils souhaitent.

    Atténuations possibles :

    • Utilisez des stratégies de contrôle d’application signées et la protection d’accès AU BIOS UEFI pour empêcher la falsification des stratégies de contrôle d’application.
    • Pour supprimer la configuration requise pour le programme d’installation managé, créez et déployez des fichiers catalogue signés dans le cadre du processus de déploiement de l’application.
    • Utilisez l’attestation d’appareil pour détecter l’état de configuration du contrôle d’application au démarrage et utilisez ces informations pour conditionner l’accès aux ressources d’entreprise sensibles.

  • Stratégies non signées

    Les stratégies non signées peuvent être remplacées ou supprimées sans conséquence par tout processus exécuté en tant qu’administrateur. Les stratégies de base non signées qui activent également des stratégies supplémentaires peuvent avoir leur « cercle de confiance » modifié par n’importe quelle stratégie supplémentaire non signée.

    Atténuations possibles :

    • Utilisez des stratégies de contrôle d’application signées et la protection d’accès AU BIOS UEFI pour empêcher la falsification des stratégies de contrôle d’application.
    • Limitez les personnes autorisées à être élevées en administrateur sur l’appareil.

  • Programme d’installation managé

    Consultez considérations relatives à la sécurité avec le programme d’installation managé

    Atténuations possibles :

    • Pour supprimer la configuration requise pour le programme d’installation managé, créez et déployez des fichiers catalogue signés dans le cadre du processus de déploiement de l’application.
    • Limitez les personnes autorisées à être élevées en administrateur sur l’appareil.

  • Intelligent Security Graph (ISG)

    Consultez considérations relatives à la sécurité avec le graphe de sécurité intelligent

    Atténuations possibles :

    • Implémentez des stratégies qui nécessitent que les applications soient gérées par le service informatique. Auditez l’utilisation des applications existantes et déployez des applications autorisées à l’aide d’une solution de distribution de logiciels, comme Microsoft Intune. Passer d’ISG à un programme d’installation managé ou à des règles basées sur des signatures.
    • Utilisez une stratégie de mode d’audit restrictive pour auditer l’utilisation des applications et augmenter la détection des vulnérabilités.

  • Stratégies supplémentaires

    Les stratégies supplémentaires sont conçues pour assouplir la stratégie de base associée. En outre, l’autorisation des stratégies non signées permet à tout processus administrateur d’étendre le « cercle de confiance » défini par la stratégie de base sans restriction.

    Atténuations possibles :

    • Utilisez des stratégies de contrôle d’application signées qui autorisent uniquement les stratégies supplémentaires signées autorisées.
    • Utilisez une stratégie de mode d’audit restrictive pour auditer l’utilisation des applications et augmenter la détection des vulnérabilités.

  • Règles FilePath

    Voir plus d’informations sur les règles de chemin de fichier

    Atténuations possibles :

    • Limitez les personnes autorisées à être élevées en administrateur sur l’appareil.
    • Migrer des règles de chemin de fichier vers le programme d’installation managé ou les règles basées sur des signatures.

  • Fichiers signés

    Bien que les fichiers signés par code vérifient l’identité de l’auteur et garantissent que le code n’a été modifié par personne autre que l’auteur, cela ne garantit pas que le code signé est sécurisé.

    Atténuations possibles :

    • Utilisez un logiciel anti-programme malveillant ou antivirus de bonne réputation avec une protection en temps réel, comme Microsoft Defender, pour protéger vos appareils contre les fichiers malveillants, les logiciels de publicité et d’autres menaces.

À la prochaine étape