Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
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.
Cet article explique comment créer une stratégie App Control for Business à l’aide de la stratégie Smart App Control en tant que modèle. Smart App Control est une solution de sécurité basée sur le contrôle d’application conçue pour les utilisateurs grand public. Il utilise la même technologie que Contrôle d’application pour les entreprises. Il est donc facile à utiliser comme base d’une stratégie d’entreprise tout aussi robuste mais flexible.
Astuce
Microsoft recommande la stratégie créée dans cet article comme stratégie de démarrage idéale pour la plupart des déploiements App Control sur les appareils des utilisateurs finaux. 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. Vous pouvez renforcer la stratégie au fil du temps pour obtenir une posture de sécurité globale plus forte sur vos appareils gérés par App Control, comme décrit dans les articles ultérieurs.
Comme nous l’avons fait dans le déploiement d’App Control for Business dans différents scénarios, nous allons utiliser l’exemple fictif de Lamna Healthcare Company (Lamna) pour illustrer ce scénario. Lamna a l’intention d’adopter des stratégies d’application plus fortes, y compris 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 (elle/elle) est la responsable de l’équipe informatique chargée du déploiement d’App Control. Lamna dispose actuellement de stratégies d’utilisation des applications assouplies et d’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 probablement utiliser des stratégies différentes pour différents segments d’utilisateurs. Mais pour l’instant, Alice veut une stratégie qui peut couvrir la plupart des utilisateurs sans aucune modification, la stratégie « Signé & Fiable » de Smart App Control adaptée à Lamna.
Analyser la façon dont le « cercle de confiance » de Smart App Control s’adapte à vos besoins
Alice suit les instructions de l’article Planifier la gestion du cycle de vie de la stratégie de contrôle des applications et commence par analyser le « cercle de confiance » pour la stratégie du contrôle d’application intelligent. Alice lit les articles d’aide en ligne de Microsoft sur Smart App Control pour bien le comprendre. De cette lecture, Alice apprend que Smart App Control autorise uniquement le code signé approuvé publiquement ou le code non signé que l’Intelligent Security Graph (ISG) prédit comme étant sûr. Le code signé approuvé publiquement signifie que l’émetteur du certificat de signature est l’une des autorités de certification du programme racine de confiance de Microsoft. L’exécution du code non signé est bloquée si l’ISG ne peut pas prédire que l’exécution du code est sécurisée. Et le code déterminé comme étant dangereux est toujours bloqué.
Alice réfléchit maintenant à la façon d’adapter la stratégie pour l’utilisation de Lamna. Alice souhaite créer une stratégie initiale aussi souple que possible, tout en offrant une valeur de sécurité durable. Certains au sein de Lamna préconisent une approche plus agressive que les plans d’Alice. Ils veulent immédiatement verrouiller les appareils des utilisateurs finaux et espérer des retombées limitées. Mais l’équipe de direction est d’accord avec Alice pour dire que la culture des applications de Lamna, formée lentement au fil du temps, ne disparaîtra pas du jour au lendemain et que la stratégie initiale nécessite donc beaucoup de flexibilité.
Tenez compte des facteurs clés de votre organization
Alice identifie ensuite les facteurs clés de l’environnement de Lamna qui affectent le « cercle de confiance » de l’entreprise. La politique doit être souple pour répondre aux besoins de l’entreprise à court et moyen terme. Cela donne à Lamna le temps d’introduire de nouveaux processus et stratégies de gestion des applications afin de rendre pratique une stratégie de contrôle d’application plus restrictive à l’avenir. Les facteurs clés aident également Alice à choisir les systèmes à inclure dans le premier déploiement. Alice écrit ces facteurs dans le document de planification :
- Privilèges utilisateur : La plupart des utilisateurs sont des utilisateurs standard, mais près d’un quart disposent de droits d’administrateur local sur leurs appareils et la possibilité d’exécuter n’importe quelle application de leur choix est un facteur important.
- Systèmes d’exploitation : Windows 11 exécute la plupart des appareils des utilisateurs, mais Lamna s’attend à ce que 10 % des clients restent sur Windows 10 au cours du prochain exercice, en particulier dans les plus petits bureaux satellites. Les serveurs et l’équipement spécialisé de Lamna sont hors de portée pour l’instant.
- Gestion des clients : Lamna utilise Microsoft Intune pour tous les appareils Windows 11, déployés en tant que Microsoft Entra cloud natif. Ils continuent d’utiliser Microsoft Endpoint Configuration Manager (MEMCM) pour la plupart des appareils Windows 10, déployés en tant que jointure hybride Microsoft Entra.
- Gestion des applications : Lamna dispose de centaines d’applications métier dans ses unités commerciales. L’équipe d’Alice déploie la plupart de ces applications, mais pas toutes, à l’aide de Intune. Et il y a une longue liste d’applications utilisées par les petites équipes, y compris de nombreuses applications « Shadow IT », qui n’ont pas de charte officielle, mais qui sont essentielles pour les employés qui les utilisent.
- Développement d’applications et signature de code : Les unités commerciales de Lamna ne sont pas normalisées sur les plateformes et les frameworks de développement, donc une variabilité et une complexité significatives sont probables. Presque toutes les applications utilisent du code non signé, ou pour la plupart non signé. Bien que l’entreprise exige désormais la signature de code, les certificats de signature de code de Lamna proviennent de son infrastructure à clé publique (PKI) d’entreprise et nécessitent des règles personnalisées dans la stratégie.
Définir le « cercle de confiance » pour les appareils gérés légèrement
Sur la base de ces facteurs, Alice écrit les pseudo-règles pour la version Lamna de la stratégie signée & digne de confiance de Microsoft :
« Pilotes de noyau certifiés Windows et Microsoft » Une ou plusieurs règles de signataire autorisant :
- Windows et ses composants.
- Pilotes de noyau signés par l’autorité de certification WhQL (Hardware Quality Labs) Windows.
« Code signé approuvé publiquement » Une ou plusieurs règles de signataire autorisant :
- Code signé avec des certificats émis par toute autorité de certification participant au programme racine de confiance Microsoft (« AuthRoot ») ou code non-système d’exploitation signé par Microsoft.
Code signé Lamna Une ou plusieurs règles de signataire autorisant :
- Code signé par des certificats émis par l’autorité de certification privée (PCA) Lamna Codesigning, le certificat intermédiaire émis à partir de leur propre infrastructure à clé publique interne.
Autoriser les applications en fonction de leur « réputation » Option de stratégie autorisant :
- Les applications prédites comme étant « sûres » par l’ISG.
Autoriser le programme d’installation géré Option de stratégie autorisant :
- Code écrit sur le système par un processus désigné par la stratégie comme programme d’installation managé. Pour la stratégie d’installation managée de Lamna, Alice inclut l’extension de gestion Intune, ainsi que des processus de mise à jour automatique connus pour les applications largement utilisées. Alice inclut également une règle de chemin de fichier, « D :\ Lamna Helpdesk* », dans laquelle les administrateurs du support technique de Lamna sont formés pour copier les programmes d’installation d’application et les scripts qu’ils utilisent pour réparer les applications et les systèmes de l’utilisateur.
Administration règles de chemin d’accès uniquement Une ou plusieurs règles de chemin de fichier pour les emplacements suivants :
- « C :\Program Files* »
- « C :\Program Files (x86)* »
- « %windir%* »
- « D :\Lamna Helpdesk* »
Modifiez le modèle de stratégie « Signé & fiable » pour votre organization
Alice télécharge l’Assistant Stratégie de contrôle d’application à partir de https://aka.ms/appcontrolwizard et l’exécute.
Dans la page d’accueil, Alice voit trois options : Créateur de stratégie, Rédacteur de stratégie et Fusion de stratégie. Alice sélectionne Policy Creator qui l’amène à la page suivante.
Dans Sélectionner un type de stratégie, Alice doit choisir de créer une stratégie Format de stratégie multiple ou Format de stratégie unique . Étant donné que tous les appareils des utilisateurs finaux s’exécutent Windows 11 ou les versions actuelles de Windows 10, Alice conserve le format de stratégie multiple par défaut. De même, le choix entre stratégie de base et stratégie supplémentaire est simple et, ici aussi, laisse la stratégie de base par défaut sélectionnée. Alice sélectionne Suivant pour continuer.
La page suivante est l’endroit où Alice sélectionnera un modèle de base pour la stratégie. L’Assistant Contrôle d’application offre trois modèles de stratégies à utiliser lors de la création d’une stratégie de base. Chaque stratégie de modèle applique des règles légèrement différentes pour modifier son modèle de cercle de confiance et de sécurité de la stratégie. Les trois stratégies de modèle sont les suivantes :
Stratégie de base de modèle Description Mode Windows par défaut Le mode Windows par défaut autorise les composants suivants : - Composants du système d’exploitation Windows : tout fichier binaire installé par une nouvelle installation de Windows
- Applications empaquetées MSIX signées par le signataire MarketPlace du Microsoft Store
- Applications Microsoft Office365, OneDrive et Microsoft Teams
- Pilotes signés WHQL
Autoriser le mode Microsoft Autoriser le mode Microsoft autorise les composants suivants : - Tout le code autorisé par le mode Windows par défaut, plus...
- Tous les logiciels signés par Microsoft
Mode Signé et digne de confiance Le mode Signé et fiable autorise les composants suivants : - Tout le code autorisé par le mode Autoriser Microsoft, plus...<
- Fichiers créés ou installés par un processus configuré en tant que programme d’installation managé
- Fichiers ayant une bonne réputation par Microsoft Defender technologie intelligent de graphe de sécurité
Alice sélectionne le modèle de mode Signé et fiable , puis Suivant, en acceptant les valeurs par défaut pour le nom de fichier et l’emplacement de la stratégie.
Dans Configurer le modèle de stratégie - Règles de stratégie, Alice passe en revue l’ensemble des options activées pour la stratégie. La plupart des options du modèle sont déjà définies comme recommandé par Microsoft. Les seules modifications apportées par Alice sont de case activée les options du programme d’installation managé et exiger whQL. De cette façon, les applications installées par Intune ou l’un des autres programmes d’installation gérés sont automatiquement autorisées, et seuls les pilotes de noyau créés pour Windows 10 ou une version ultérieure peuvent s’exécuter. La sélection de Suivant fait avancer l’Assistant.
La page Règles de fichier affiche les règles de la stratégie de modèle en mode signé et fiable. Alice ajoute la règle Signer pour approuver le code signé par Lamna, et les règles de chemin de fichier pour autoriser le code dans les emplacements accessibles en écriture uniquement par l’administrateur sous les deux répertoires Program Files, le répertoire Windows et le dossier Helpdesk de Lamna.
Pour créer chaque règle, Alice sélectionne + Ajouter personnalisé , ce qui ouvre la boîte de dialogue Règles personnalisées dans laquelle les conditions de la règle sont définies. Pour la première règle, les sélections par défaut pour Étendue de la règle et Action de la règle sont correctes. Pour la liste déroulante Type de règle, l’option Serveur de publication est le bon choix pour créer une règle de signataire. Alice sélectionne ensuite Parcourir et sélectionne un fichier signé par un certificat émis par l’autorité de certification lamna Codesigning. L’Assistant affiche les informations de signature et les informations extraites de la section d’en-tête de ressource (RSRC) du fichier, comme le nom du produit et le nom de fichier d’origine avec des cases à cocher de chaque élément. Dans ce cas, étant donné qu’elle a l’intention d’autoriser tout ce qui est signé avec les certificats de signature de code internes de Lamna, Alice laisse uniquement l’autorité de certification émettrice et l’éditeur cochés. Avec les conditions de règle pour l’ensemble de règles Lamna Codesigning PCA, Alice sélectionne Créer une règle et voit que la règle est incluse dans la liste. Alice répète ces étapes pour le reste des règles personnalisées de Lamna.
Maintenant que toutes les modifications décrites dans les pseudo-règles sont effectuées, Alice sélectionne Suivant et l’Assistant crée les fichiers de stratégie De contrôle d’application. Les fichiers de sortie incluent un formulaire XML et une forme binaire compilée de la stratégie. Alice effectue une révision du fichier de stratégie XML pour confirmer que le résultat semble correct, puis ferme l’Assistant.
Alice charge les deux fichiers dans un référentiel GitHub créé spécifiquement pour les fichiers de stratégie de contrôle d’application de Lamna.
La stratégie de démarrage d’Alice est maintenant prête à être déployée en mode audit sur les appareils gérés de Lamna.
Considérations relatives à la sécurité de cette stratégie
Afin de minimiser le risque d’affecter négativement la productivité des utilisateurs, Alice a défini une stratégie qui fait plusieurs compromis entre la sécurité et la flexibilité de l’application 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 :
- Pour empêcher la falsification des stratégies App Control, utilisez des stratégies App Control signées sur les systèmes exécutant le microprogramme UEFI (Unified Extensible Firmware Interface).
- Pour supprimer la nécessité d’approuver le programme d’installation managé, créez et déployez des fichiers catalogue signés ou déployez des stratégies mises à jour dans le cadre de vos procédures de déploiement d’applications et de mise à jour d’application régulières.
- Pour contrôler l’accès à d’autres ressources et données d’entreprise, utilisez la mesure du temps de démarrage de l’état de configuration d’App Control à partir du journal TCG (Trusted Computing Group) avec attestation de l’appareil.
Stratégies non signées
Tout processus exécuté en tant qu’administrateur peut remplacer ou supprimer des stratégies non signées sans conséquence. De même, les stratégies supplémentaires non signées peuvent modifier le « cercle de confiance » pour une stratégie de base non signée qui inclut l’option 17 Enabled :Allow Supplemental Policies.
Atténuations possibles :
- Pour empêcher la falsification des stratégies App Control, utilisez des stratégies App Control signées sur les systèmes exécutant le microprogramme UEFI.
- Pour réduire le risque, limitez les personnes autorisées à passer à l’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 nécessité d’approuver le programme d’installation managé, créez et déployez des fichiers catalogue signés ou déployez des stratégies mises à jour dans le cadre de vos procédures de déploiement d’applications et de mise à jour d’application régulières.
- Pour réduire le risque, limitez les personnes autorisées à passer à l’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 :
- Pour supprimer la nécessité d’approuver l’ISG, effectuez un audit complet de l’utilisation et de l’installation des applications existantes. Intégrez toutes les applications que vous trouvez qui ne sont actuellement pas gérées à votre solution de distribution de logiciels, comme Microsoft Intune. Implémentez des stratégies pour exiger que les applications soient gérées par le service informatique. Ensuite, passez de l’ISG au programme d’installation managé, aux fichiers catalogue signés et/ou aux règles de stratégie mises à jour, puis déployez-les dans le cadre de vos procédures de déploiement d’applications et de mise à jour d’application régulières.
- Pour collecter davantage de données à utiliser dans les enquêtes sur les incidents de sécurité et les révisions post-incident, déployez une stratégie de contrôle d’application hautement restrictive en mode audit. Les données capturées dans les journaux des événements App Control contiennent des informations utiles sur tout le code qui s’exécute et qui n’est pas signé par Windows. Pour éviter que votre stratégie n’affecte les performances et les fonctionnalités de votre appareil, assurez-vous qu’elle autorise au minimum le code Windows qui s’exécute dans le cadre du processus de démarrage.
Stratégies supplémentaires
Les stratégies supplémentaires sont conçues pour étendre le « cercle de confiance » défini par la stratégie de base. Si la stratégie de base est également non signée, tout processus exécuté en tant qu’administrateur peut placer une stratégie supplémentaire non signée et développer le « cercle de confiance » de 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.
- Passez des règles de chemin de fichier à un programme d’installation managé ou à des règles basées sur une signature.
Programme malveillant signé
La signature de code seule n’est pas une solution de sécurité, mais elle fournit deux blocs de construction critiques qui rendent possibles des solutions de sécurité comme App Control. Tout d’abord, la signature de code associe fortement le code à une identité réelle... et une identité réelle peut faire face à des conséquences qu’une figure sans nom, ombrageux responsable de programmes malveillants non signés ne fait pas. Deuxièmement, la signature du code fournit une preuve de chiffrement que le code en cours d’exécution reste inchangé depuis que l’éditeur l’a signé. Une stratégie de contrôle d’application qui nécessite que tout le code soit signé, ou la stratégie l’autorise explicitement, augmente les enjeux et les coûts d’un attaquant. Mais il reste des moyens pour un attaquant motivé d’obtenir son code malveillant signé et approuvé, au moins pendant un certain temps. Et même lorsque le logiciel provient d’une source digne de confiance, cela ne signifie pas qu’il est sûr de s’exécuter. N’importe quel code peut exposer des fonctionnalités puissantes qu’un acteur malveillant pourrait exploiter pour sa propre mauvaise intention. Et les vulnérabilités peuvent transformer le code le plus bénin en quelque chose de vraiment dangereux.
Atténuations possibles :
- Utilisez un logiciel anti-programme malveillant ou antivirus réputé 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.
Ce que vous devez lire ensuite
En savoir plus sur les programmes d’installation gérés : comment ils fonctionnent, comment les configurer et quelles sont leurs limitations dans Autoriser automatiquement les applications déployées par un programme d’installation managé.
Découvrez comment déployer votre stratégie de démarrage et la voir en action dans Déploiement de stratégies App Control for Business.