Guide de déploiement de Microsoft Device Guard

Article
04/01/2016

Microsoft Device Guard est un ensemble de fonctionnalités destinées à renforcer l’intégrité des systèmes logiciels et du matériel, qui modifient radicalement la sécurité du système d’exploitation Windows. Windows 10 utilise Microsoft Device Guard en plus de mécanismes de protection de l’intégrité du code et de fonctionnalités matérielles avancées (extensions de virtualisation de processeur, Module de plateforme sécurisée (TPM) et conversion d’adresses de second niveau) afin de proposer une sécurité moderne et complète aux utilisateurs. Ce guide explore les fonctionnalités individuelles de Microsoft Device Guard et explique comment les planifier, les configurer et les déployer.

Introduction à Microsoft Device Guard

Actuellement, le paysage des menaces de sécurité est plus incisif que jamais. Les attaques modernes ciblent la génération de revenus, le vol de propriété intellectuelle et la dégradation des systèmes, ce qui se traduit par des pertes financières. Bon nombre des pirates informatiques modernes à l’origine de ces attaques sont financés par des États, pour des raisons inconnues, ainsi que par des organisations de cyberterrorisme étendues, aux fonds importants. Ces menaces, susceptibles d’atteindre les systèmes de l’entreprise via un simple e-mail, peuvent nuire de manière permanente à la réputation de cette dernière en matière de sécurisation des ressources logicielles, tout en compromettant sa réussite financière. Windows 10 propose de nouvelles fonctionnalités de gestion de la sécurité, qui permettent de lutter efficacement contre un pourcentage important des menaces actuelles connues.

D’après une estimation, plus de 300 000 nouvelles variantes de programmes malveillants sont identifiées chaque jour. Malheureusement, les sociétés actuelles utilisent une méthode surannée pour identifier les logiciels malveillants et empêcher leur utilisation. Il s’avère que les PC actuels considèrent comme fiables toutes les fonctionnalités exécutées, jusqu’à ce que l’analyse des signatures de programmes malveillants signale une menace ; le logiciel anti-programme malveillant tente ensuite de nettoyer le PC, alors que les effets de l’attaque se font déjà sentir, bien souvent. Ce système basé sur l’analyse des signatures se contente de réagir à une infection et de s’assurer qu’elle ne se reproduira plus. Dans ce modèle, le système pilotant la détection de programmes malveillants s’appuie sur la découverte de ces derniers. À ce moment seulement, une signature est fournie au client afin qu’il supprime la menace. Cela implique qu’un PC doit être infecté au préalable. Selon le délai entre la détection d’un programme malveillant et l’envoi d’une signature au client, soit vous perdrez des données, soit le système restera sûr.

En plus de solutions anti-programme malveillant, il existe des mécanismes de création de « listes blanches », par exemple AppLocker. Ces mécanismes appliquent des règles uniques ou des règles d’acceptation ou de refus générales pour les applications en cours d’exécution. Certes, cette solution est davantage axée sur la prévention que les fonctions de détection basées sur des signatures, mais elle nécessite une maintenance continue importante. Dans Windows 10, ces applications sont plus efficaces lorsqu’elles sont déployées en parallèle avec Microsoft Device Guard.

Ce dernier met un terme au modèle de détection actuel, qui détecte, puis bloque les programmes suspects, en n’autorisant que les applications fiables à s’exécuter, et c’est tout. Cette méthode est conforme à la stratégie de prévention efficace associée à la sécurité des téléphones portables. Grâce à Device Guard, Microsoft a révolutionné le mode de gestion des applications non fiables par le système d’exploitation Windows. Ainsi, ses défenses sont nettement plus difficiles à franchir. Ce nouveau modèle, axé sur la prévention plutôt que sur la détection, offre aux clients Windows la sécurité requise pour gérer les menaces modernes. Dès le moment où il est implémenté, la majorité de ces menaces deviennent entièrement obsolètes.

Microsoft Device Guard modifie radicalement la sécurité du système d’exploitation Windows en tirant parti de nouvelles options de sécurité basées sur la virtualisation, ainsi que d’un modèle de système d’exploitation pour appareils mobiles qui ne considère pas les applications comme fiables dès le départ. Ainsi, les programmes malveillants ont beaucoup plus de difficulté à franchir les défenses des systèmes. En ayant recours à des stratégies d’intégrité du code configurables, les entreprises peuvent définir précisément les applications autorisées à fonctionner au sein de leur environnement. La protection de l’intégrité du code configurable ne se limite pas aux applications du Windows Store ; vous pouvez l’utiliser avec les applications Win32 existantes, signées ou non, sans avoir à repackager l’application. De plus, vous pouvez déployer cette fonction de protection en tant que fonctionnalité autonome lorsque l’entreprise ne possède pas le matériel requis pour pouvoir utiliser Microsoft Device Guard. En plus de la protection de l’intégrité du code, Windows 10 tire parti de fonctionnalités matérielles avancées (extensions de virtualisation de processeur, unités IOMMU (Input/Output Memory Management Units), Module de plateforme sécurité (TPM) et conversion d’adresses de second niveau (SLAT)) afin de proposer aux utilisateurs une sécurité moderne et complète. Déployée avec Credential Guard et la protection de l’intégrité du code configurable, la solution Microsoft Device Guard constituera l’un des plus importants déploiements de logiciel de sécurité côté client susceptibles d’être effectués par une entreprise actuellement. Dans ce guide, vous découvrirez les fonctionnalités individuelles de Microsoft Device Guard et saurez comment les planifier, les configurer et les déployer. Associée à la protection de l’intégrité du code configurable, la solution Microsoft Device Guard est prévue pour un déploiement en parallèle avec d’autres fonctionnalités de Windows visant à atténuer les menaces, comme Credential Guard et AppLocker.

Vue d’ensemble de Device Guard

Device Guard est un ensemble de fonctionnalités destinées à renforcer l’intégrité des systèmes logiciels et matériels. Ces fonctions modifient radicalement la sécurité du système d’exploitation Windows en tirant parti de nouvelles options de sécurité basées sur la virtualisation, ainsi que d’un modèle de système d’exploitation pour appareils mobiles qui ne considère pas les applications comme fiables dès le départ. Ce modèle inclut une fonctionnalité clé, la protection de l’intégrité du code configurable, qui permet à l’entreprise de sélectionner chaque éditeur de logiciel ou logiciel fiable autorisé à exécuter du code sur les ordinateurs clients. C’est grâce à cela que la sécurité en place sur les téléphones mobiles est si efficace. En outre, Device Guard propose aux entreprises une méthode de signature des applications cœur de métier, afin qu’elles puissent se fier à leur propre code sans devoir être repackagées. De plus, grâce à cette méthode de signature, les entreprises peuvent s’assurer de la fiabilité des applications tierces. Associée à Credential Guard, à AppLocker et à la protection de l’intégrité du code configurable, la solution Microsoft Device Guard constitue la solution de protection de la sécurité la plus exhaustive que Microsoft ait jamais proposée aux clients Windows.

Ces nouvelles offres de gestion de la sécurité des clients reposent sur des fonctionnalités matérielles avancées comme les extensions de virtualisation de processeur, les unités IOMMU et la conversion d’adresses de second niveau (SLAT). Ces fonctionnalités matérielles sont intégrées à des niveaux supplémentaires du système d’exploitation, ce qui permet à Windows 10 d’en tirer parti encore plus efficacement. Ainsi, la technologie d’hyperviseur de type 1 utilisée pour exécuter les machines virtuelles dans Microsoft Hyper-V permet également d’isoler les services Windows principaux au sein d’un conteneur protégé, basé sur la virtualisation. Il s’agit d’un des nombreux exemples illustrant l’intégration plus approfondie des fonctionnalités matérielles avancées dans le système d’exploitation Windows 10, afin de proposer une sécurité moderne et complète aux utilisateurs. Ces fonctionnalités matérielles sont désormais disponibles sur les marchés de l’informatique grand public et d’entreprise. Pour en savoir plus, consultez la rubrique Considérations relatives au matériel du présent document.

Parallèlement à ces nouvelles fonctionnalités, certains composants de Device Guard correspondent à des technologies ou des outils qui ont été inclus dans cette offre de sécurité stratégique afin d’offrir aux clients le système d’exploitation Windows le plus sûr possible. Device Guard a pour objectif de proposer des fonctionnalités de sécurité client à utiliser avec d’autres outils de lutte contre les menaces proposés par le système d’exploitation Windows. Certains de ces outils sont mentionnés dans le présent guide. En plus de présenter chaque fonctionnalité, ce document vous guide lors de sa configuration et de son déploiement.

Intégrité du code configurable

Windows propose deux modes d’exploitation : le mode utilisateur et le mode noyau. La base du système d’exploitation s’exécute en mode noyau, niveau auquel ce système communique directement avec les ressources matérielles. Le mode utilisateur permet principalement d’exécuter des applications et de gérer l’intermédiation vers et depuis le mode noyau pour les demandes en matière de ressources matérielles. Par exemple, lorsqu’une application exécutée en mode utilisateur nécessite davantage de mémoire, le processus en mode utilisateur doit demander des ressources au mode noyau, et non à la mémoire RAM directement.

La protection de l’intégrité du code est un composant du système d’exploitation Windows qui s’assure que le code lancé par Windows est fiable et sécurisé. Comme le système d’exploitation, la protection de l’intégrité du code Windows inclut également deux composants principaux : la protection de l’intégrité du code en mode noyau (KMCI, Kernel Mode Code Integrity) et la protection de l’intégrité du code en mode utilisateur (UMCI, User Mode Code Integrity). La fonction KMCI a été utilisée dans les dernières versions du système d’exploitation Windows, afin d’empêcher le mode noyau d’exécuter des pilotes non signés. Même si cette méthode est efficace, les programmes malveillants n’utilisent pas uniquement les pilotes pour tenter d’accéder à l’espace associé au mode noyau dans le système d’exploitation. Toutefois, Microsoft a élevé le niveau standard du code du mode noyau et ce, dans les versions prêtes à l’emploi de Windows 10, tout en proposant aux entreprises un moyen de définir leurs propres normes en termes d’intégrité UMCI et KMCI. Avec le service d’intégrité du code lui-même et au travers des règles qu’utilise un client Windows pour vérifier qu’une application est autorisée à s’exécuter, Microsoft propose dans Windows 10 une sécurité beaucoup plus étroite que celle des versions précédentes. Depuis le début, l’intégrité UMCI est uniquement disponible dans Windows RT et sur les appareils Windows Phone. Pour cette raison, les virus et programmes malveillants ont beaucoup plus de difficulté à franchir leurs défenses. Les normes ayant assuré la réussite de la fonction UMCI sont désormais disponibles dans Windows 10 également.

Depuis toujours, la plupart des programmes malveillants ne sont pas signés. En déployant de simples stratégies d’intégrité du code, les entreprises se protègent contre les programmes malveillants non signés, qui sont responsables de plus de 95 % des attaques actuelles, selon une estimation. Ces stratégies permettent à l’entreprise de sélectionner chaque fichier binaire autorisé à s’exécuter, tant en mode utilisateur qu’en mode noyau, du niveau du signataire à celui du hachage. Lorsqu’elles sont entièrement appliquées, le mode utilisateur de Windows fonctionne comme un téléphone portable : seules des applications ou signatures spécifiques sont considérées comme fiables et autorisées à s’exécuter. Cette seule fonctionnalité suffit à modifier radicalement la sécurité d’une entreprise. Ce mécanisme de sécurité supplémentaire ne se limite pas aux applications Windows ; vous n’êtes pas obligé de réécrire votre application afin de la rendre compatible avec vos applications non signées existantes. Vous pouvez implémenter la stratégie d’intégrité du code configurable sans activer le logiciel Device Guard ; toutefois, cette stratégie est prévue pour s’exécuter en conjonction avec ce dernier lorsque le matériel pris en charge est disponible. Pour savoir comment configurer, déployer et gérer des stratégies d’intégrité du code, consultez la rubrique Stratégies d’intégrité du code du présent document.

Fonctions de sécurité matérielles et sécurité basée sur la virtualisation

La protection et les fonctionnalités principales de Microsoft Device Guard sont d’abord appliquées au niveau du matériel. Les appareils dotés de processeurs proposant des technologies SLAT et des extensions de virtualisation (comme VT-x (Intel Virtualization Technology) et AMD-V) pourront bénéficier de fonctionnalités de sécurité basée sur la virtualisation qui renforcent la sécurité de Windows. Microsoft Device Guard utilise ces fonctionnalités pour isoler les services Windows principaux critiques pour la sécurité et l’intégrité du système d’exploitation. Grâce à cette isolation, ces services sont moins vulnérables tant en mode utilisateur qu’en mode noyau ; il s’agit d’une barrière infranchissable pour la plupart des programmes malveillants actuellement utilisés. L’un de ces services isolés, le service d’intégrité du code Windows, pilote la fonctionnalité d’intégrité du code configurable en mode noyau de Device Guard. Il empêche le code ayant réussi à accéder aux opérations du mode noyau de compromettre le service d’intégrité du code.

Une autre fonctionnalité de Windows 10 qui utilise la sécurité basée sur la virtualisation est Credential Guard. Credential Guard offre une protection supplémentaire aux utilisateurs des domaines Active Directory, en stockant les informations d’identification du domaine dans le conteneur de virtualisation qui héberge les services de sécurité Windows, comme le service d’intégrité du code. En isolant ces informations d’identification de domaine des modes utilisateur et noyau actifs, le système les protège plus efficacement contre le vol. Pour plus d’informations sur la complémentarité entre les fonctionnalités Credential Guard et Device Guard, consultez la section Device Guard avec Credential Guard. Pour savoir comment activer Credential Guard, consultez la rubrique Activer Credential Guard du présent document.

Device Guard avec AppLocker

Bien qu’elle ne soit pas considérée comme une nouvelle fonctionnalité de Microsoft Device Guard, la solution AppLocker complète ce dernier lorsque la fonction de gestion de l’intégrité du code ne peut pas être entièrement implémentée, ou qu’elle ne porte pas sur l’ensemble des scénarios voulus. Il existe de nombreux scénarios illustrant l’utilisation de stratégies d’intégrité du code en parallèle avec des règles AppLocker. Pour obtenir les meilleurs résultats, vous devez appliquer ces stratégies au niveau le plus restrictif possible de votre entreprise, en utilisant AppLocker pour ajuster les restrictions à un niveau encore inférieur.

Remarque Voici un exemple illustrant la nécessité d’associer AppLocker à Device Guard : lorsque l’entreprise souhaite restreindre les applications universelles. Les applications universelles ont déjà été signalées par Microsoft comme fiables et autorisées à s’exécuter ; l’entreprise peut ne pas souhaiter lancer certaines applications universelles dans l’environnement. À cette fin, vous pouvez utiliser une règle AppLocker.

Nous vous recommandons d’exécuter AppLocker et Device Guard en parallèle au sein de votre entreprise, qui bénéficie alors simultanément des avantages de ces deux fonctions de sécurité et propose la sécurité la plus exhaustive au plus grand nombre d’appareils possible. En plus de ces fonctionnalités, Microsoft vous recommande de continuer à utiliser une solution antivirus d’entreprise, pour mettre en place un portefeuille complet de fonctions de sécurité d’entreprise.

Device Guard avec Credential Guard

Même si le logiciel Credential Guard n’est pas une fonction de Device Guard, de nombreuses entreprises choisiront sans doute de les déployer ensemble, afin de bénéficier d’une protection supplémentaire contre le vol d’informations d’identification. Tout comme la protection basée sur la virtualisation de l’intégrité du code en mode noyau, Credential Guard valorise la technologie d’hyperviseur pour protéger les informations d’identification de domaine. Cette prévention permet de résister aux techniques de type « pass-the-hash » et « pass-the-ticket ». En utilisant l’authentification multifacteur avec Credential Guard, les entreprises peuvent bénéficier d’une protection renforcée contre ces menaces. Pour en savoir plus sur le déploiement de Credential Guard sur les clients Windows 10 Entreprise, consultez la rubrique Activer Credential Guard du présent document. En plus d’activer Credential Guard côté client, les entreprises peuvent déployer des mécanismes de prévention au niveau du contrôleur de domaine et de l’autorité de certification, afin de protéger le système contre le vol d’informations d’identification. Microsoft publiera prochainement des informations sur ces mécanismes de correction supplémentaires.

Facilité de gestion unifiée

Vous pouvez facilement gérer les fonctionnalités de Device Guard, en utilisant les outils de gestion des clients et d’entreprise traditionnels que les professionnels de l’informatique utilisent tous les jours. Utilisez les outils de gestion suivants pour activer et gérer Device Guard :

Stratégie de groupe. Windows 10 fournit un modèle d’administration permettant de configurer et de déployer les stratégies d’intégrité du code configurables pour votre entreprise. Ce modèle vous permet également de spécifier les fonctionnalités de sécurité basées sur le matériel que vous souhaitez activer et déployer. Vous pouvez gérer ces paramètres en parallèle avec vos objets de stratégie de groupe existants, ce qui simplifie l’implémentation des fonctionnalités de Device Guard. En plus de ces fonctions de protection de l’intégrité du code et de gestion de la sécurité basée sur le matériel, vous pouvez également gérer vos fichiers catalogues au moyen de la Stratégie de groupe. Pour en savoir plus sur les fichiers catalogues, consultez la rubrique Fichiers catalogues du présent document.
Microsoft System Center Configuration Manager. Vous pouvez utiliser le logiciel System Center Configuration Manager (SCCM) pour simplifier le déploiement et la gestion des fichiers catalogues, les stratégies d’intégrité du code et les fonctions de sécurité basées sur le matériel, ainsi que pour assurer le contrôle de version. Pour en savoir plus sur le déploiement des fichiers catalogues via SCCM, consultez la rubrique Déployer des fichiers catalogues avec System Center Configuration Manager du présent document.
Microsoft Intune. Les entreprises pourront valoriser une version à venir de Microsoft Intune lors du déploiement et de la gestion des stratégies d’intégrité du code et des fichiers catalogues.
Windows PowerShell. Le logiciel Windows PowerShell sert principalement à créer et gérer des stratégies d’intégrité du code. Ces stratégies représentent le plus puissant composant de Device Guard. Pour consulter une procédure pas à pas expliquant comment créer, soumettre à un audit, gérer, appliquer et déployer des stratégies d’intégrité du code, consultez la rubrique Stratégies d’intégrité du code du présent document.

Ces options offrent la même expérience que les solutions de gestion d’entreprise existantes. Pour plus d’informations sur la gestion et le déploiement des fonctionnalités de gestion de l’intégrité du code et du matériel dans Device Guard, consultez la rubrique Déploiement de Device Guard du présent document.

Planifier le déploiement de Device Guard

Dans cette rubrique, vous en saurez plus sur les sujets suivants :

Approche planifiée du déploiement de la protection de l’intégrité du code d’entreprise. Le déploiement de Device Guard au sein de votre entreprise nécessite une approche planifiée. Dans cette rubrique, vous pourrez consulter des recommandations générales sur l’approche à adopter pour déployer la fonction de protection de l’intégrité du code d’entreprise au sein de la société.
Scénarios de déploiement de Device Guard. Lorsque vous planifiez le déploiement de Device Guard, Microsoft vous recommande de catégoriser chaque appareil de votre organisation dans un scénario de déploiement. Ces scénarios proposent une feuille de route pour le déploiement de Device Guard.
Adoption de la signature du code. La signature du code joue un rôle important dans les processus de gestion de la sécurité offerts par Device Guard. Cette rubrique décrit les options de signature de code, ainsi que les avantages et inconvénients de chaque méthode.
Considérations relatives au matériel. Plusieurs fonctionnalités de Device Guard nécessitent du matériel avancé. Cette rubrique décrit la configuration requise pour chacune de ces fonctionnalités et les éléments à rechercher lors de l’actualisation suivante du matériel.

Approche planifiée du déploiement de la protection de l’intégrité du code d’entreprise

Les entreprises qui envisagent d’utiliser Device Guard ne doivent pas s’attendre à un déploiement complet du jour au lendemain. Avant de pouvoir implémenter Device Guard, vous devez prévoir l’impact de cette opération pour l’utilisateur final comme pour le professionnel de l’informatique. En outre, le déploiement des fonctionnalités de Device Guard en entreprise nécessite une approche planifiée, par étapes, afin de garantir que les systèmes des utilisateurs finaux sont à même de mettre en application les nouvelles restrictions liées à la sécurité. Effectuez les tâches générales suivantes pour planifier le déploiement de Device Guard dans votre entreprise :

Regroupez les appareils selon des fonctions similaires. Classez les machines selon les groupes décrits dans la rubrique Scénarios de déploiement de Device Guard du présent document. Cette opération marque le début de la création d’une feuille de route pour le déploiement de Device Guard. De plus, elle permet de disposer de groupes lors d’implémentations plus complexes ou plus simples. À cette étape, évaluez le nombre de stratégies Device Guard requises. La solution la plus simple consiste à appliquer des stratégies à toute votre entreprise, mais cela peut ne pas répondre aux besoins de vos services individuels.

Pour déterminer le nombre de stratégies adapté pour votre entreprise, essayez de répartir les groupes définis en services ou rôles. Ensuite, posez-vous les questions suivantes : De quels logiciels chaque service ou rôle a-t-il besoin pour effectuer ses tâches ? Doit-il pouvoir installer et exécuter les logiciels des autres services ? Devons-nous créer une stratégie d’intégrité du code de base alignée sur notre catalogue d’applications ? Les utilisateurs doivent-ils être autorisés à installer n’importe quelle application, ou celle-ci doit-elle figurer dans la liste des applications acceptées ? Devons-nous autoriser les employés à utiliser leurs propres appareils ? Ces questions vous aideront à déterminer le nombre de stratégies requises par votre organisation. Enfin, essayez d’identifier les personnes ou services qui peuvent nécessiter un niveau de privilèges plus élevé. Par exemple, le service X doit-il être autorisé à installer et à exécuter l’application XYZ, même si aucun autre service ne peut le faire ? Si la réponse est « oui » et que cela se justifie, il vous faudra définir une deuxième stratégie d’intégrité du code pour ce groupe. Dans le cas contraire, vous serez sans doute à même de fusionner plusieurs stratégies pour simplifier la gestion. Pour en savoir plus sur les stratégies d’intégrité du code configurables, consultez la rubrique Stratégies d’intégrité du code du présent document.
Créez des stratégies d’intégrité du code sur des PC de référence. Une fois les groupes d’appareils créés, vous pouvez générer des stratégies d’intégrité du code à aligner avec ces groupes, de la même manière que vous géreriez des images d’entreprise. Lorsque vous avez séparé ces groupes et défini des PC de référence qui reproduisent les logiciels et le matériel requis par ces groupes individuels, créez des stratégies d’intégrité du code pour chacun. Une fois ces stratégies générées, vous pouvez les fusionner afin de créer une stratégie principale, ou les gérer et les déployer au cas par cas. Pour accéder à des instructions pas à pas sur la création de stratégies d’intégrité du code, consultez la rubrique Créer des stratégies d’intégrité du code sur des PC de référence du présent document.
Soumettez des stratégies d’intégrité du code à un audit. Microsoft vous recommande de tester les stratégies d’intégrité du code en mode audit avant de les appliquer. Le mode audit permet aux administrateurs d’exécuter la stratégie d’intégrité du code sur un système, sans réellement bloquer quelque fonction que ce soit. Plutôt que d’empêcher les applications de se lancer, il consigne les événements avec chaque exception à la stratégie. De cette façon, vous pouvez facilement mettre en évidence les problèmes qui n’ont pas été détectés durant l’analyse initiale. Vous pouvez créer des stratégies d’intégrité du code supplémentaires en utilisant les événements d’audit, puis les fusionner dans la stratégie existante. Pour savoir comment soumettre des stratégies d’intégrité du code à un audit, consultez la rubrique Soumettre des stratégies d’intégrité du code à un audit du présent document.
Évaluez les applications métier qui ne sont actuellement pas signées et créez un fichier catalogue pour elles. Grâce aux fichiers catalogues, les entreprises peuvent signer les applications qui ne présentent pas de fichiers binaires signés de manière numérique, ou les applications auxquelles un client souhaite associer une deuxième signature. Ces applications peuvent être internes ou provenir de tiers ; elles n’ont pas besoin d’être repackagées. Lorsque vous créez des stratégies d’intégrité de code au niveau de la règle au-dessus des valeurs de hachage, vous ne découvrirez pas les applications non signées. Pour inclure ces applications dans vos stratégies d’intégrité du code, il vous suffit de créer, de signer et de déployer un fichier catalogue. Pour en savoir plus sur les fichiers catalogues, consultez la rubrique Fichiers catalogues du présent document.
Activez les fonctionnalités de sécurité matérielles de votre choix. Chaque type d’appareil détecté via la procédure de la rubrique Scénarios de déploiement de Device Guard tire parti de différentes configurations de protection de l’intégrité du matériel et des logiciels. Vous devez évaluer les fonctionnalités de gestion de la sécurité basée sur le matériel séparément des stratégies d’intégrité du code, car elles offrent des fonctions supplémentaires. Pour savoir comment configurer les fonctionnalités de gestion de la sécurité basée sur le matériel, consultez la rubrique Configurer les fonctionnalités de sécurité basée sur le matériel du présent document.
Déployez les stratégies d’intégrité du code et les fichiers catalogues. Une fois que vous avez créé et signé les fichiers catalogues nécessaires, puis généré et soumis les stratégies d’intégrité du code à un audit, vous pouvez déployer ces dernières par étapes. Microsoft vous recommande vivement de déployer ces composants sur les ordinateurs d’un groupe d’utilisateurs test, même une fois que le service informatique les a testés et validés. Vous bénéficiez ainsi d’un contrôle final de la qualité avant le déploiement des fichiers catalogues et des stratégies à un niveau plus étendu. Pour en savoir plus sur le déploiement des fichiers catalogues avec une Stratégie de groupe, consultez la rubrique Déployer des fichiers catalogues avec une Stratégie de groupe du présent document. Pour en savoir plus sur le déploiement des stratégies d’intégrité du code, consultez la rubrique Déployer et gérer des stratégies d’intégrité du code avec une Stratégie de groupe du présent document.

Scénarios de déploiement de Device Guard

Pour simplifier le déploiement de Device Guard pour votre entreprise, Microsoft vous recommande de regrouper les appareils selon différents scénarios de déploiement, décrits dans la présente rubrique. Les entreprises ne peuvent pas simplement « mettre en marche » un logiciel comme Device Guard. En général, l’implémentation de ce dernier est effectuée par étapes. Pour savoir à quelle étape de l’approche d’implémentation globale de Device Guard vous pouvez tirer parti de ces scénarios, consultez la rubrique Approche planifiée du déploiement de la protection de l’intégrité du code d’entreprise du présent document.

Appareils présentant une charge de travail fixe

Les listes des applications approuvées sur les appareils présentant une charge de travail fixe changent rarement, car les tâches effectuées jour après jour sont les mêmes. Voici quelques exemples d’appareils de ce type : bornes, systèmes de point de vente et PC de centres d’appels. Ces appareils peuvent facilement tirer pleinement parti des capacités complètes de Device Guard et nécessitent peu de gestion, ou une modification réduite des stratégies. L’implémentation de Device Guard sur ces appareils s’effectue sans difficulté et ne requiert qu’une administration continue limitée. Lorsque la solution Device Guard est entièrement implémentée, les utilisateurs peuvent uniquement exécuter les applications installées, gérées et validées par le service informatique.

Les composants de Device Guard applicables aux appareils présentant une charge de travail fixe sont les suivants :

Protection offerte par la sécurité basée sur la virtualisation de KMCI

Stratégie UMCI appliquée

Appareils entièrement gérés

Sur les appareils entièrement gérés, le service informatique limite le type des logiciels installés et restreint leur exécution ; toutefois, il permet aux utilisateurs de demander l’installation de logiciels supplémentaires, ou fournit une liste des logiciels approuvés figurant dans un catalogue d’applications. Voici quelques exemples d’appareils de ce type : ordinateurs de bureau et portables verrouillés qui appartiennent à l’entreprise. Grâce à ces appareils, vous pouvez établir une stratégie d’intégrité du code de référence et appliquer la stratégie d’intégrité du code. Le service informatique gère les stratégies et met à jour les appareils lorsque de nouvelles applications sont approuvées ou sont incluses dans le catalogue de System Center Configuration Manager.

Les composants de Device Guard applicables aux appareils entièrement gérés sont les suivants :

Protection offerte par la sécurité basée sur la virtualisation de KMCI
Stratégie UMCI appliquée

Dans ce scénario, une liste d’applications est fournie et approuvée ; la stratégie d’approbation est constamment réévaluée lorsqu’un utilisateur demande l’ajout d’une nouvelle application. Lorsqu’une application est approuvée sur l’ensemble des appareils de ce type, les nouvelles demandes d’utilisateurs portant sur cette application ne nécessitent aucune mise à jour de la stratégie (alignement avec le catalogue d’applications). De plus, vous pouvez associer ce mécanisme avec un processus d’intégration des nouvelles applications que vous devez ajouter au catalogue d’applications central. L’implémentation initiale de Device Guard sur les appareils entièrement gérés est un processus simple ; cependant, le traitement des signatures approuvées associées aux applications acceptées et récemment ajoutées prend plus de temps.

Appareils avec gestion allégée

Les appareils avec gestion allégée sont des ordinateurs appartenant à l’entreprise sur lesquels les utilisateurs bénéficient d’un contrôle total. Cela inclut les applications installées sur ces ordinateurs. Ces appareils exécutent la solution antivirus et les outils de gestion client de l’entreprise, mais ne sont pas limités par des stratégies de conformité et de demandes d’installation de logiciels.

Les composants de Device Guard applicables aux appareils à gestion allégée sont les suivants :

Protection offerte par la sécurité basée sur la virtualisation de KMCI
Stratégie UMCI en mode audit

BYOD

Device Guard n’est pas adapté à la gestion des appareils associés à un modèle BYOD. Si les employés sont autorisés à apporter leurs propres appareils, ils peuvent avoir des difficultés à les utiliser en dehors du lieu de travail, du fait de la méthode employée pour gérer les applications en mode utilisateur qu’ils hébergent. Par ailleurs, les fonctionnalités de Device Guard sont difficiles à gérer d’un point de vue administratif. Pour les appareils de ce groupe, envisagez le recours à d’autres fonctionnalités de sécurisation renforcée et de sécurité avec des solutions d’accès conditionnel GPM, comme Microsoft Intune.

Adoption de la signature du code

La signature du code est essentielle pour garantir une implémentation réussie des stratégies d’intégrité du code configurables. Ces stratégies peuvent valider les certificats de signature d’éditeurs de logiciels indépendants comme de clients. Dans Windows 10, toutes les applications du Windows Store sont signées. De plus, vous pouvez facilement approuver toute autre application signée, en ajoutant le certificat de signature à la stratégie d’intégrité du code.

Quant aux applications non signées, les clients disposent de plusieurs options pour les signer, de sorte que les stratégies d’intégrité du code puissent les approuver. Ils peuvent par exemple recourir à la signature de code intégré classique. Les entreprises dotées d’équipes de développement en interne peuvent intégrer la signature du code binaire dans leur processus de développement d’applications, puis ajouter le certificat de signature à leurs stratégies d’intégrité du code. La deuxième option permettant de signer une application non signée est le recours à des fichiers catalogues. Dans Windows 10, les clients ont la possibilité de créer des fichiers catalogues lorsqu’ils surveillent l’installation et la première exécution d’une application. Pour en savoir plus sur la signature d’applications cœur de métier ou tierces non signées, consultez la rubrique Applications cœur de métier existantes du présent document.

Applications cœur de métier existantes

Jusqu’à présent, les applications cœur de métier existantes étaient difficiles à approuver lorsqu’elles étaient signées par une source autre que le Windows Store, voire non signées. Dans Windows 10, la signature des applications tierces et cœur de métier non signées a été simplifiée. Pour cette nouvelle méthode de signature, les applications n’ont pas besoin d’être repackagées. Grâce aux fichiers catalogues, les administrateurs peuvent signer les applications non signées en surveillant leur installation et leur démarrage initial, tout simplement. En utilisant ces informations de surveillance, un administrateur peut générer un fichier catalogue. Les fichiers catalogues sont de simples listes de hachages SHA 2 (Secure Hash Algorithm 2) incluant les fichiers binaires découverts. Les valeurs de hachage de ces fichiers binaires sont mises à jour chaque fois qu’une application est actualisée. Pour cette raison, un fichier catalogue mis à jour est requis. Afin de simplifier l’administration, envisagez d’incorporer la signature du code intégré dans le processus de développement de l’application. Pour en savoir plus sur la génération des fichiers catalogues, consultez la rubrique Fichiers catalogues du présent document.

Remarque

Les fichiers catalogues sont des listes des valeurs de hachage de fichiers binaires. Si l’application numérisée est mise à jour, vous devrez créer un fichier catalogue. Cela dit, la signature binaire est toujours vivement recommandée pour toutes les futures applications, de sorte qu’aucun fichier catalogue n’est nécessaire.

Lorsque vous créez un fichier catalogue, vous devez le signer au moyen de l’infrastructure à clé publique ou d’un certificat de signature de code acheté au préalable. Lors de la signature, les stratégies d’intégrité du code peuvent approuver le signataire ou le certificat de signature associé à ces fichiers. Pour en savoir plus sur la signature des fichiers catalogues, consultez la rubrique Fichiers catalogues du présent document.

Développement d’applications

Même si les applications internes peuvent être signées une fois qu’elles sont packagées, via des fichiers catalogues, Microsoft vous recommande vivement d’intégrer la signature du code intégré dans le processus de développement de l’application. Lors de la signature des applications, ajoutez simplement le certificat de signature de code utilisé pour signer vos applications dans votre stratégie d’intégrité du code. Ainsi, la stratégie d’intégrité du code approuvera toute application à venir signée avec ce certificat. L’intégration de la signature du code dans un processus de développement d’applications interne peut offrir de nombreux avantages à votre service informatique lorsque vous implémentez des stratégies d’intégrité du code.

Considérations relatives au matériel

Pour assurer la réussite de l’implémentation de Device Guard dans votre entreprise, il est impératif de choisir soigneusement le fournisseur du matériel et les modèles spécifiques à acheter lors de l’actualisation matérielle suivante. En tenant compte du cycle de vie du matériel actuel, envisagez le recours au processus traité dans la rubrique Approche planifiée du déploiement de la protection de l’intégrité du code d’entreprise du présent document lorsque vous définissez l’ordre de remplacement du matériel au sein de l’entreprise. Device Guard doit être déployé par étapes. Pour cette raison, vous avez le temps de prévoir son implémentation de manière méthodique.

Pour l’implémentation des différentes fonctionnalités de Device Guard, divers dispositifs matériels sont requis. Certaines fonctionnalités pourront probablement être activées avec votre matériel actuel, alors que d’autres ne le pourront pas. Toutefois, pour les organisations qui souhaitent implémenter Device Guard dans son intégralité, plusieurs fonctionnalités matérielles avancées seront nécessaires. Pour obtenir des détails supplémentaires sur les fonctionnalités matérielles requises pour les composants de Device Guard, consultez le tableau ci-dessous.

Condition requise	Description
Windows 10 Entreprise	Le PC doit exécuter Windows 10 Entreprise.
Version du microprogramme UEFI 2.3.1 ou supérieure et démarrage sécurisé	Pour vérifier que le microprogramme utilise la version UEFI 2.3.1 ou supérieure et le démarrage sécurisé, vous pouvez le comparer à la configuration requise System.Fundamentals.Firmware.CS.UEFISecureBoot.ConnectedStandby du Programme de compatibilité matérielle Windows.
Extensions de virtualisation	Les extensions de virtualisation suivantes sont requises pour prendre en charge la sécurité basée sur la virtualisation : Intel VT-x ou AMD-V Traduction d’adresse de second niveau
Verrouillage du microprogramme	Le programme d’installation du microprogramme doit être verrouillé pour empêcher le démarrage des autres systèmes d’exploitation et éviter les modifications apportées aux paramètres UEFI. Vous devez également désactiver les méthodes de démarrage autrement qu’à partir du disque dur.
Architecture x64	Les fonctionnalités utilisées par la sécurité basée sur la virtualisation de l’hyperviseur Windows peuvent être exécutées sur un PC 64 bits uniquement.
Une IOMMU (unité de gestion de mémoire d’entrée/sortie) VT-d ou AMD Vi	Dans Windows 10, une IOMMU améliore la résilience du système contre les attaques de mémoire. ¹
Processus de mise à jour de microprogramme sécurisé	Pour vérifier que le microprogramme est conforme au processus de mise à jour de microprogramme sécurisé, vous pouvez le comparer à la configuration requise System.Fundamentals.Firmware.UEFISecureBoot du Programme de compatibilité matérielle Windows.

Déploiement de Device Guard

Dans cette rubrique, vous en saurez plus sur les sujets suivants :

Configurer les fonctionnalités de sécurité basée sur le matériel. Cette rubrique explique comment activer les fonctionnalités de sécurité basée sur le matériel dans Device Guard. Vous allez également vérifier que les fonctionnalités sont activées via l’interface WMI (Windows Management Infrastructure) et le fichier Msinfo32.exe.
Fichiers catalogues. Dans cette rubrique, vous allez créer, signer et déployer des fichiers catalogues. Vous déploierez les fichiers catalogues à l’aide de la Stratégie de groupe et de SCCM (System Center Configuration Manager). En outre, vous utiliserez SCCM pour inventorier les fichiers catalogue déployés à des fins de création de rapports.
Stratégies d’intégrité du code. Cette rubrique fournit des informations sur la création, le fusionnement, le traitement, le déploiement, la suppression et la soumission à un audit des stratégies d’intégrité du code configurables, tant signées que non signées.

Configurer les fonctionnalités de sécurité basée sur le matériel

Les fonctionnalités de sécurité basée sur le matériel constituent une grande partie des offres de sécurité de Device Guard. La sécurité basée sur la virtualisation renforce la fonction principale de Device Guard : la protection de l’intégrité du code configurable. La configuration de la sécurité basée sur le matériel s’effectue en trois étapes dans Device Guard :

Vérifier que la configuration matérielle requise est respectée et activée. Vérifiez que vos ordinateurs clients possèdent le matériel nécessaire pour pouvoir exécuter ces fonctionnalités. Une liste des configurations matérielles requises pour la sécurité basée sur le matériel est disponible dans la rubrique Considérations relatives au matériel du présent document. En outre, si vous recherchez du nouveau matériel à installer, envisagez de recourir aux appareils abordés dans la rubrique Appareils compatibles avec Device Guard du présent document.
Activer les fonctionnalités Windows nécessaires. L’activation de ces fonctions pour la sécurité basée sur le matériel peut être effectuée de plusieurs manières. Pour en savoir plus sur les fonctions Windows requises, consultez la rubrique Configuration des fonctions Windows requise pour la sécurité basée sur la virtualisation du présent document.
Activer les dispositifs de votre choix. Une fois le matériel nécessaire et les fonctionnalités Windows, activées, vous êtes prêt à démarrer la sécurité basée sur le matériel. Dans le cas de la fonction Démarrage sécurisé de l’interface UEFI, consultez la rubrique Activer la fonction Démarrage sécurisé de l’interface UEFI du présent document. Pour savoir comment activer la fonction de sécurité basée sur la virtualisation du service KMCI, consultez la rubrique Activer la sécurité basée sur la virtualisation pour la protection de l’intégrité du code en mode noyau du présent document. Enfin, pour savoir comment activer Credential Guard, consultez la rubrique Activer Credential Guard du présent document.

Configuration des fonctions Windows requise pour la sécurité basée sur la virtualisation

En plus de la configuration matérielle requise décrite dans la rubrique Considérations relatives au matériel, vous devez activer certains dispositifs du système d’exploitation avant la sécurité basée sur la virtualisation, à savoir Microsoft Hyper-V et le mode utilisateur isolé (voir figure 1).

Remarque

Vous pouvez configurer ces fonctionnalités manuellement, à l’aide de Windows PowerShell ou de l’API de gestion et de maintenance des images de déploiement (DISM). Pour en savoir plus sur ces méthodes, consultez la documentation relative à Credential Guard.

Figure 1. Activation des fonctionnalités du système d’exploitation relatives à la sécurité basée sur la virtualisation

Une fois ces fonctionnalités activées, vous pouvez configurer les dispositifs de sécurité basée sur le matériel de votre choix. Pour savoir comment activer la fonction de protection basée sur la virtualisation de l’intégrité du code en mode noyau, consultez la rubrique Activer la sécurité basée sur la virtualisation pour la protection de l’intégrité du code en mode noyau du présent document. Pour savoir comment activer la fonction Démarrage sécurisé de l’interface UEFI, consultez la rubrique Activer la fonction Démarrage sécurisé de l’interface UEFI du présent document. Enfin, pour savoir comment activer Credential Guard, consultez la rubrique Activer Credential Guard du présent document.

Activer la fonction Démarrage sécurisé de l’interface UEFI

Avant de démarrer ce processus, vérifiez que l’appareil cible respecte la configuration matérielle requise par la fonction Démarrage sécurisé de l’interface UEFI, telle que décrite dans la rubrique Considérations relatives au matériel du présent document. Pour démarrer la fonction Démarrage sécurisé, vous avez deux options : la configuration manuelle des clés de Registre appropriées et le déploiement de la Stratégie de groupe. Procédez comme suit pour configurer manuellement la fonction Démarrage sécurisé sur un ordinateur exécutant Windows 10 :

Remarque

Cette fonction est associée à deux niveaux de sécurité de plate-forme, à savoir Démarrage sécurisé et protection contre les DMA, et Démarrage sécurisé autonome. La protection contre les DMA, qui assure une protection supplémentaire de la mémoire, n’est activée que sur les systèmes dont les processeurs présentent des technologies de protection contre les DMA (IOMMU). En l’absence de processeurs IOMMU et la protection contre les DMA étant désactivée, les clients ne sont pas protégés contre les attaques visant les pilotes.

Accédez à la sous-clé de Registre HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\DeviceGuard.
Définissez la valeur DWORD EnableVirtualizationBasedSecurity sur 1.
Définissez la valeur DWORD RequirePlatformSecurityFeatures selon vos besoins :
- Définissez cette valeur sur 1 pour activer l’option Démarrage sécurisé.
- Définissez cette valeur sur 2 pour activer l’option Démarrage sécurisé et protection contre les DMA.
Redémarrez l’ordinateur client.

L’exécution de cette procédure manuellement sur chaque ordinateur protégé de l’entreprise prendrait malheureusement trop de temps. La Stratégie de groupe offre un moyen beaucoup plus simple de déployer la fonction Démarrage sécurisé de l’interface UEFI dans votre entreprise. Cet exemple permet de créer une unité d’organisation de test appelée DG Enabled PCs. Si vous préférez, vous pouvez associer la stratégie à une unité d’organisation existante, puis définir la portée de l’objet de stratégie de groupe via les groupes de sécurité de l’ordinateur portant le nom approprié.

Remarque

Microsoft vous recommande de permettre le test de cette fonction sur un groupe d’ordinateurs de test avant de la déployer sur des machines actuellement à la disposition d’utilisateurs.

Utiliser la Stratégie de groupe pour déployer la fonction Démarrage sécurisé

Pour créer un objet de stratégie de groupe, cliquez avec le bouton droit de la souris sur l’unité d’organisation à laquelle associer cet objet, puis sélectionnez Créer un objet GPO dans ce domaine, et le lier ici.

Figure 2. Création d’un objet de stratégie de groupe lié à une unité d’organisation
Donnez à cet objet le nom suivant : Objet GPO test pour Démarrage Sécurisé Contoso. Pour les besoins de cet exemple, l’objet de stratégie de groupe porte le nom Contoso Secure Boot GPO Test, Pour les besoins de cet exemple, vous pouvez choisir le nom que vous souhaitez. Dans l’idéal, ce nom doit respecter la convention de dénomination associée aux objets de stratégie de groupe.
Pour ouvrir l’Éditeur de gestion des stratégies de groupe, cliquez sur le nouvel objet de stratégie de groupe avec le bouton droit de la souris, puis cliquez sur Modifier.
Au sein de l’objet de stratégie de groupe sélectionné, accédez à l’emplacement suivant : Configuration ordinateur\Modèles d’administration\Système\Device Guard. Ensuite, cliquez avec le bouton droit de la souris sur l’option Activer la sécurité basée sur la virtualisation et sélectionnez Modifier.

Figure 3. Activation de la sécurité basée sur la virtualisation
Cliquez sur Activé, puis sélectionnez l’option Démarrage sécurisé et protection contre les DMA dans la liste Sélectionner le niveau de sécurité de plateforme.

Figure 4. Activation de la fonction Démarrage sécurisé

Remarque

La fonction Démarrage sécurisé de Device Guard est optimisée lorsqu’elle est associée à la protection contre les DMA. Si votre matériel contient des processeurs IOMMU requis pour la protection contre les DMA, n’oubliez pas de sélectionner le niveau de sécurité de plate-forme Démarrage sécurisé et protection contre les DMA. S’il n’en inclut pas, vous pouvez tirer parti des mécanismes de correction offerts par la fonction Démarrage sécurisé sans protection contre les DMA.
Fermez l’Éditeur de gestion des stratégies de groupe, puis redémarrez l’ordinateur de test qui exécute Windows 10. Une fois ce paramètre configuré, la fonction Démarrage sécurisé de l’interface UEFI est activée au démarrage.
Consultez le journal d’événements de l’ordinateur de test relatif aux objets de stratégie de groupe Device Guard.

Les stratégies Device Guard traitées sont consignées dans l’Observateur d’événements, à l’emplacement suivant : Journaux des applications et des services\Microsoft\Windows\DeviceGuard-GPEXT\Opérationnel. Lorsque la stratégie Activer la sécurité basée sur la virtualisation est correctement traitée, l’événement présentant l’ID 7000 est consigné ; il contient les paramètres sélectionnés dans cette stratégie.

Activer la sécurité basée sur la virtualisation pour la protection de l’intégrité du code en mode noyau

Avant de commencer ce processus, vérifiez que l’ordinateur souhaité respecte la configuration matérielle requise pour la sécurité basée sur la virtualisation, décrite dans la rubrique Considérations relatives au matériel, et activez les fonctions Windows traitées dans la rubrique Configuration des fonctions Windows requise pour la sécurité basée sur la virtualisation du présent document. Lorsqu’elle est validée, vous pouvez activer la protection basée sur la virtualisation de KMCI de deux manières : via la configuration manuelle des sous-clés de Registre appropriées et via le déploiement de la Stratégie de groupe.

Remarque

Tous les pilotes du système doivent être compatibles avec la protection basée sur la virtualisation de l’intégrité du code ; dans le cas contraire, votre système risque d’échouer. Microsoft vous recommande de permettre le test de cette fonction sur un groupe d’ordinateurs de test avant de l’activer sur des ordinateurs déployés.

Pour configurer manuellement la protection basée sur la virtualisation de KMCI, procédez comme suit :

Accédez à la sous-clé de Registre HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\DeviceGuard.
Définissez la valeur DWORD HypervisorEnforcedCodeIntegrity sur 1.
Redémarrez de l’ordinateur client.

L’exécution de cette procédure manuellement sur chaque ordinateur protégé de l’entreprise prendrait trop de temps. Utilisez plutôt la stratégie de groupe pour déployer la protection basée sur la virtualisation de KMCI. Cet exemple crée une unité d’organisation de test appelée DG Enabled PCs, que vous utiliserez pour lier l’objet de stratégie de groupe. Si vous préférez, vous pouvez associer la stratégie à une unité d’organisation existante plutôt que de créer une unité d’organisation de test, puis définir la portée de la stratégie via les groupes de sécurité de l’ordinateur portant le nom approprié.

Remarque

Microsoft vous recommande de permettre le test de cette fonction sur un groupe d’ordinateurs de test avant de la déployer sur des machines actuellement à la disposition d’utilisateurs. Si elle n’est pas testée, il se peut que cette fonctionnalité cause l’instabilité du système et entraîne la défaillance du système d’exploitation du client.

Pour utiliser la Stratégie de groupe afin de configurer la sécurité basée sur la virtualisation de KMCI, procédez comme suit :

Créez un objet de stratégie de groupe, en cliquant avec le bouton droit de la souris sur l’unité d’organisation à laquelle associer cet objet, puis en sélectionnant Créer un objet GPO dans ce domaine, et le lier ici.

Figure 5. Création d’un objet de stratégie de groupe lié à une unité d’organisation
Donnez à cet objet le nom suivant :Test objet de stratégie de groupe protection CI VBS Contoso.

Pour les besoins de cet exemple, l’objet de stratégie de groupe porte le nom Contoso VBS CI Protection GPO Test, mais vous pouvez choisir le nom que vous souhaitez. Dans l’idéal, ce nom doit respecter la convention de dénomination associée aux objets de stratégie de groupe.
Ouvrez l’Éditeur de gestion des stratégies de groupe. Ensuite, cliquez sur le nouvel objet de stratégie de groupe avec le bouton droit de la souris, puis sélectionnez Modifier.
Au sein de l’objet de stratégie de groupe sélectionné, accédez à l’emplacement suivant : Configuration ordinateur\Modèles d’administration\Système\Device Guard. Ensuite, cliquez avec le bouton droit de la souris sur l’option Activer la sécurité basée sur la virtualisation et sélectionnez Modifier.

Figure 6. Activation de la sécurité basée sur la virtualisation
Choisissez l’option Activé, puis cochez la case Activer la protection de l’intégrité du code basée sur la virtualisation.

Figure 7. Activation de la sécurité basée sur la virtualisation de KMCI
Fermez l’Éditeur de gestion des stratégies de groupe, puis redémarrez l’ordinateur de test qui exécute Windows 10. Lorsque ce paramètre est configuré, la sécurité basée sur la virtualisation de KMCI prend effet lors du redémarrage.
Consultez le journal d’événements du client de test relatif aux objets de stratégie de groupe Device Guard.

Les stratégies Device Guard traitées sont consignées dans l’Observateur d’événements, à l’emplacement suivant : Journaux des applications et des services\Microsoft\Windows\DeviceGuard-GPEXT\Opérationnel. Lorsque la stratégie Activer la sécurité basée sur la virtualisation est correctement traitée, l’événement présentant l’ID 7000 est consigné ; il contient les paramètres sélectionnés dans cette stratégie.

Activer Credential Guard

Credential Guard offre un niveau supplémentaire de protection des informations d’identification aux utilisateurs du domaine, en stockant ces informations dans un conteneur virtuel éloigné du système d’exploitation, tant en mode noyau qu’en mode utilisateur. Ainsi, un système compromis ne peut pas accéder à ces informations. En plus d’activer Credential Guard côté client, vous pouvez déployer des mécanismes de correction supplémentaires au niveau du contrôleur de domaine et de l’autorité de certification, afin d’empêcher tout vol d’informations d’identification. Microsoft publiera prochainement des informations sur ces mécanismes de correction supplémentaires.

Avant de commencer ce processus, vérifiez que le système souhaité respecte la configuration matérielle requise pour la sécurité basée sur la virtualisation, décrite dans la rubrique Considérations relatives au matériel, et que vous avez activé les fonctions Windows traitées dans la rubrique Configuration des fonctions Windows requise pour la sécurité basée sur la virtualisation du présent document. Une fois la validation effectuée, vous pouvez activer Credential Guard manuellement, en configurant les sous-clés de Registre appropriées ou en déployant la stratégie de groupe.

Pour configurer la sécurité basée sur la virtualisation de Credential Guard manuellement, procédez comme suit :

Accédez à la sous-clé de Registre HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa.
Définissez la valeur DWORD LsaCfgFlags sur 1.
Redémarrez de l’ordinateur client.

Pour éviter de perdre trop de temps à effectuer des déploiements manuels, vous pouvez déployer Credential Guard dans votre entreprise en utilisant la stratégie de groupe. Cet exemple crée une unité d’organisation appelée DG Enabled PCs. Pour activer Credential Guard, vous pouvez créer un lien vers une unité d’organisation, puis étendre la portée d’application de l’objet de stratégie de groupe, à l’aide de groupes de sécurité.

Remarque

Microsoft vous recommande d’activer Credential Guard avant de joindre un ordinateur au domaine, afin de vous assurer que toutes les informations d’identification sont correctement protégées. Pour que cette protection soit assurée, l’idéal serait que les sous-clés de Registre appropriées soient définies au cours du processus de création d’images.

Pour activer Credential Guard via la stratégie de groupe, procédez comme suit :

Créez un objet de stratégie de groupe, en cliquant avec le bouton droit de la souris sur l’unité d’organisation à laquelle associer cet objet, puis en cliquant sur Créer un objet GPO dans ce domaine, et le lier ici.

Figure 8. Création d’un objet de stratégie de groupe lié à une unité d’organisation
Donnez au nouvel objet de stratégie de groupe le nom suivant : Test objet stratégie groupe Credential Guard Contoso.

Pour les besoins de cet exemple, l’objet de stratégie de groupe porte le nom Contoso Credential Guard GPO Test, mais vous pouvez choisir le nom que vous souhaitez. Dans l’idéal, ce nom doit respecter la convention de dénomination associée aux objets de stratégie de groupe.
Ouvrez l’Éditeur de gestion des stratégies de groupe. Ensuite, cliquez sur le nouvel objet de stratégie de groupe avec le bouton droit de la souris, puis cliquez sur Modifier.
Au sein de l’objet de stratégie de groupe sélectionné, accédez à l’emplacement suivant : Configuration ordinateur\Modèles d’administration\Système\Device Guard. Cliquez avec le bouton droit de la souris sur l’option Activer la sécurité basée sur la virtualisation et sélectionnez Modifier.

Figure 9. Activation de la sécurité basée sur la virtualisation
Sélectionnez l’option Activé, puis cochez la case Activer la protection des informations d’identification.

Figure 10. Activation de Credential Guard
Fermez l’Éditeur de gestion des stratégies de groupe, puis redémarrez l’ordinateur de test qui exécute Windows 10.

Remarque

Le niveau de sécurité de plate-forme par défaut est Démarrage sécurité. Si des processeurs IOMMU sont disponibles au sein des ordinateurs protégés, nous vous recommandons de sélectionner l’option Démarrage sécurisé et protection contre les DMA, afin d’étendre la liste des corrections disponibles via Credential Guard.
Consultez le journal d’événements du client de test relatif aux objets de stratégie de groupe Device Guard.

Remarque

Toutes les stratégies Device Guard traitées sont consignées dans l’Observateur d’événements, à l’emplacement suivant : Journaux des applications et des services\Microsoft\Windows\DeviceGuard-GPEXT\Opérationnel.

Pour en savoir plus sur le fonctionnement de Credential Guard et accéder à des options de configuration supplémentaires, consultez la documentation relative à Credential Guard.

Valider les fonctionnalités activées de sécurité basée sur le matériel de Device Guard

Windows 10 et Windows Server 2016 et plus disposent d’une classe WMI pour les propriétés et fonctionnalités liées à Device Guard : Win32_DeviceGuard. Cette classe peut être interrogée à partir d’une session Windows PowerShell avec élévation de privilèges, à l’aide de la commande suivante :

Get-CimInstance –ClassName Win32_DeviceGuard –Namespace root\Microsoft\Windows\DeviceGuard

Remarque

La classe WMI Win32_DeviceGuard est uniquement disponible sur l’édition Entreprise de Windows 10.

La sortie de cette commande détaille les fonctionnalités de sécurité basée sur le matériel, ainsi que les fonctionnalités qui sont activées. Pour en savoir plus sur la signification de chaque propriété, consultez le tableau 1.

Tableau 1. Propriétés de l’élément Win32_DeviceGuard

Propriétés	Description	Valeurs valides
AvailableSecurityProperties	Ce champ permet d’énumérer et de créer des rapports sur l’état des propriétés de sécurité pertinentes pour Device Guard.	0. Si cette valeur est présente, cela signifie qu’il n’existe aucune propriété pertinente sur l’appareil. 1. Si cette valeur est présente, cela signifie que la prise en charge de l’hyperviseur est disponible. 2. Si cette valeur est présente, cela signifie que la fonction Démarrage sécurisé est disponible. 3. Si cette valeur est présente, cela signifie que la protection contre les DMA est disponible.
InstanceIdentifier	Chaîne spécifique à un appareil particulier.	Déterminée par la fonction WMI.
RequiredSecurityProperties	Ce champ décrit les propriétés de sécurité requises pour activer la sécurité basée sur la virtualisation.	0. Aucune valeur n’est requise. 1. Si cette valeur est présente, cela signifie que la fonction Démarrage sécurisé est requise. 2. Si cette valeur est présente, cela signifie que la protection contre les DMA est requise. 3. Si cette valeur est présente, cela signifie que la fonction Démarrage sécurisé et la protection contre les DMA sont toutes deux nécessaires.
SecurityServicesConfigured	Ce champ indique si le service HVCI ou Credential Guard a été configuré.	0. Aucun service n’est configuré. 1. Si cette valeur est présente, cela signifie que Credential Guard est configuré. 2. Si cette valeur est présente, cela signifie que le service HVCI est configuré.
SecurityServicesRunning	Ce champ indique si le service HVCI ou Credential Guard est en cours d’exécution.	0. Aucun service n’est en cours d’exécution. 1. Si cette valeur est présente, cela signifie que Credential Guard est en cours d’exécution. 2. Si cette valeur est présente, cela signifie que le service HVCI est en cours d’exécution.
Version	Ce champ indique la version de la classe WMI.	La seule valeur valide est pour l’instant est 1.0.
VirtualizationBasedSecurityStatus	Ce champ indique si la sécurité basée sur la virtualisation est activée et en cours d’exécution.	0. La sécurité basée sur la virtualisation n’est pas activée. 1. La sécurité basée sur la virtualisation est activée, mais n’est pas en cours d’exécution. 2. La sécurité basée sur la virtualisation est activée et en cours d’exécution.
PSComputerName	Ce champ indique le nom de l’ordinateur.	Toutes les valeurs de nom d’ordinateur valides.

Pour déterminer quelles fonctions Device Guard sont disponibles et activées, vous pouvez aussi exécuter msinfo32.exe depuis une session PowerShell avec élévation de privilèges. Lorsque vous exécutez ce programme, les propriétés de Device Guard sont affichées sur la partie inférieure de la section Résumé système (voir figure 11).

Figure 11. Propriétés de Device Guard dans la fenêtre Résumé système

Fichiers catalogues

L’application de Device Guard sur un système nécessite que chaque application approuvée soit associée à une signature, ou que ses hachages binaires soient ajoutés à la stratégie d’intégrité du code. Pour de nombreuses entreprises, cela peut être un problème lors de l’examen des applications cœur de métier non signées. Pour éviter que les entreprises ne soient contraintes de remettre en forme et de signer ces applications, Windows 10 propose un outil appelé « Inspecteur de package », qui effectue le suivi du processus d’installation de tous les fichiers binaires déployés et exécutés. Si cet outil découvre ces fichiers, il les détaille dans un fichier catalogue. Les fichiers catalogue vous offrent un moyen d’approuver les applications non signées existantes, qu’elles soient développées en interne ou par un tiers ; cela concerne également les applications signées que vous souhaitez approuver, mais dont vous ne souhaitez pas approuver le signataire. Une fois créés, ces fichiers peuvent être signés ; les certificats de signature peuvent être ajoutés aux stratégies d’intégrité du code existantes. Ensuite, les fichiers catalogues peuvent être distribués aux clients.

Remarque

Le logiciel Windows 10 Entreprise ou Windows Server 2016 est requis pour la création et l’utilisation de ces fichiers.

Créer un fichier catalogue

Pour pouvoir ajouter une application non signée à une stratégie d’intégrité du code, vous devez commencer par créer un fichier catalogue. Pour ce faire, copiez chacune des commandes suivantes dans une session Windows PowerShell avec élévation des privilèges, puis procédez comme suit :

Remarque

Lorsque vous établissez une convention d’affectation de noms, la détection des fichiers catalogues déployés ultérieurs est plus simple. Dans ce guide, vous allez utiliser la convention d’affectation de noms suivante : *-Contoso.cat. Pour savoir en quoi cette pratique facilite la création d’un inventaire ou la détection des fichiers catalogues, consultez la section Création d’un inventaire des fichiers catalogues avec System Center Configuration Manager du présent document.

Assurez-vous qu’une stratégie d’intégrité du code est actuellement exécutée en mode audit.

L’outil Inspecteur de package ne détecte pas systématiquement les fichiers d’installation qui ont été supprimés de l’ordinateur lors du processus d’installation. Pour vérifier que ces fichiers binaires sont également approuvés, la stratégie d’intégrité du code que vous avez créée et soumise à un audit via les rubriques Créer des stratégies d’intégrité du code sur des PC de référence et Soumettre des stratégies d’intégrité du code à un audit doit être déployée, en mode audit, sur le système exécutant l’outil Inspecteur de package.

Remarque

Ce processus ne doit pas être effectué sur un système exécutant une stratégie Device Guard appliquée, mais uniquement avec une stratégie en cours d’exécution en mode audit. Si une stratégie est actuellement appliquée, vous ne pourrez pas installer, ni exécuter l’application.
Lancez l’outil Inspecteur de package et analysez le lecteur C.

PackageInspector.exe Start C:

Remarque

Cet outil peut surveiller les installations sur n’importe quel lecteur local. Dans cet exemple, nous installerons l’application sur le lecteur C, mais n’importe quel autre lecteur peut être utilisé.
Copiez le support d’installation sur le lecteur C.

En copiant ce support sur C, vous vous assurez que l’outil Inspecteur de package détecte et classe le programme d’installation. Si vous ignorez cette étape, il se peut que la stratégie d’intégrité du code à venir approuve l’exécution de l’application, mais non son installation.
Installez et démarrez l’application.

Installez l’application sur le lecteur C. Cela fait, démarrez l’application ; vérifiez que toutes les mises à jour du produit sont installées, et que tout contenu téléchargeable est détecté lors de l’analyse. Ensuite, fermez et rouvrez l’application pour vous assurer que l’analyse a capturé tous les fichiers binaires.

Remarque

Chaque fichier binaire qui s’exécute en même temps que l’outil Inspecteur de package est capturé dans le catalogue. Par conséquent, veillez à ne pas effectuer d’autres installations ou mises à jour pendant l’analyse, afin de limiter les risques d’approbation de fichiers binaires incorrects. Par ailleurs, si vous voulez ajouter plusieurs applications à un même fichier catalogue, il vous suffit de répéter l’installation et d’exécuter le processus alors que l’analyse est en cours.
Arrêtez l’analyse, puis générez des fichiers catalogues et de définition. Une fois l’installation et la configuration initiales des applications effectuées, arrêtez l’analyse lancée par l’outil Inspecteur de package, puis générez les fichiers de définition et catalogues sur votre Bureau, via les commandes suivantes :

$ExamplePath=$env:userprofile+"\Desktop"

$CatFileName=$ExamplePath+"\LOBApp-Contoso.cat"

$CatDefName=$ExamplePath+"\LOBApp.cdf"

PackageInspector.exe Stop C: -Name $CatFileName -cdfpath $CatDefName

Remarque

Cette analyse crée un catalogue regroupant les valeurs de hachage pour chaque fichier binaire découvert. Si les applications qui ont été analysées sont mises à jour, reproduisez ce processus pour approuver les valeurs de hachage des nouveaux fichiers binaires.

Cela fait, les fichiers sont enregistrés sur votre Bureau. Pour que ce fichier catalogue puisse être approuvé dans une stratégie d’intégrité du code, le catalogue doit d’abord être signé. Ensuite, le certificat de signature peut être inclus dans la stratégie d’intégrité du code et le fichier catalogue peut être distribué sur les différents ordinateurs clients. Les fichiers catalogues peuvent être signés à l’aide d’un certificat et de SignTool.exe, un outil gratuit disponible dans le SDK Windows. Pour en savoir plus sur la signature des fichiers catalogues avec l’outil SignTool.exe, consultez la rubrique Signature de catalogues avec l’outil SignTool.exe du présent document.

Signature de catalogues avec l’outil SignTool.exe

Device Guard facilite la signature et l’approbation des applications cœur de métier non signées pour les entreprises. Dans cette rubrique, vous allez signer un fichier catalogue généré via la rubrique précédente, en utilisant l’outil PackageInspector.exe. Pour en savoir plus sur la création de fichiers catalogues, consultez la rubrique Créer un fichier catalogue du présent document. Pour les besoins de cet exemple, vous avez besoin des éléments suivants :

l’outil SignTool.exe, qui se trouve dans le SDK Windows pour Windows 7 ou plus ;
le fichier catalogue que vous avez créé via la rubrique Créer un fichier catalogue, ou tout autre fichier catalogue créé précédemment ;
le certificat de signature de code de l’autorité de certification interne, ou tout certificat de signature de code acheté.

En l’absence de certificat de ce type, consultez la rubrique Créer un certificat de signature de code Device Guard du présent document pour savoir comment en créer un. En plus d’utiliser le certificat que vous avez créé via la rubrique Créer un certificat de signature de code Device Guard, cet exemple signe le fichier catalogue que vous avez créé via la rubrique Créer un fichier catalogue du présent document. Si vous utilisez un autre certificat ou fichier catalogue, appliquez cette procédure en appliquant les variables et le certificat appropriés. Pour signer un fichier catalogue existant, copiez chacune des commandes suivantes dans une session Windows PowerShell avec élévation des privilèges :

Initialisez les variables qui seront utilisées :
```
$ExamplePath=$env:userprofile+"\Desktop"

$CatFileName=$ExamplePath+"\LOBApp-Contoso.cat"
```
Remarque

Pour les besoins de cet exemple, vous allez utiliser le fichier catalogue que vous avez créé via la rubrique Créer un fichier catalogue du présent document. Si vous signez un autre fichier catalogue, veillez à mettre à jour les variables $ExamplePath et $CatFileName en indiquant les informations correctes.
Importez le certificat de signature de code. Importez le certificat qui sera utilisé pour signer le fichier catalogue dans le magasin personnel de l’utilisateur effectuant la signature. Pour les besoins de cet exemple, vous allez utiliser le certificat que vous avez créé via la rubrique Créer un certificat de signature de code Device Guard du présent document.
Signez le fichier catalogue avec l’outil Signtool.exe :
```
<Path to signtool.exe> sign /n "ContosoDGSigningCert" /fd sha256 /v $CatFileName
```
Remarque

La variable <Path to signtool.exe> doit correspondre au chemin d’accès complet de l’outil SignTool.exe. ContosoDGSigningCert correspond au nom du sujet du certificat que vous utiliserez pour signer le fichier catalogue. Ce certificat doit être importé dans votre magasin de certificats personnels sur l’ordinateur sur lequel vous tentez de signer le fichier catalogue.

Remarque

Pour en savoir plus sur l’outil SignTool.exe et l’ensemble des commutateurs supplémentaires, voir SignTool.exe (outil Sign Tool).
Vérifiez la signature numérique du fichier catalogue. Cliquez avec le bouton droit de la souris sur le fichier catalogue, puis cliquez sur Propriétés. Sur l’onglet Signatures numériques, vérifiez que votre certificat de signature existe et présente un algorithme sha256, comme illustré dans la figure 12.

Figure 12. Vérification de l’existence du certificat de signature
Copiez le fichier catalogue à l’emplacement suivant : C:\Windows\System32\racine_cat\{F750E6C3-38EE-11D1-85E5-00C04FC295EE}.

À des fins de test, vous pouvez copier manuellement les fichiers catalogues signés dans le dossier prévu à cet effet. Pour les implémentations à grande échelle, Microsoft vous recommande d’utiliser les préférences des fichiers de la stratégie de groupe pour copier les fichiers catalogues appropriés sur l’ensemble des machines de votre choix, ou un produit de gestion des systèmes d’entreprise, comme SCCM. Cela simplifie également la gestion des versions de catalogues.

Déployer des fichiers catalogues avec la stratégie de groupe

Afin de simplifier la gestion des fichiers catalogues, vous pouvez utiliser les préférences de la stratégie de groupe pour déployer ces fichiers sur les PC adéquats de votre entreprise. Le processus suivant vous guide lors du déploiement d’un fichier catalogue signé appelé LOBApp-Contoso.cat sur une unité d’organisation appelée « PC activés DG », avec un objet de stratégie de groupe appelé Test objet stratégie groupe fichier catalogue DG Contoso.

Remarque

Cette procédure pas à pas nécessite la création préalable d’un fichier catalogue signé. Vous devez en outre disposer d’un PC client doté de Windows 10, sur lequel le déploiement d’une Stratégie de groupe sera testé. Pour en savoir plus sur la création et la signature des fichiers catalogues, consultez la rubrique Fichiers catalogues du présent document.

Pour déployer des fichiers catalogues avec la stratégie de groupe, procédez comme suit :

Depuis un contrôleur de domaine ou un PC client hébergeant les Outils d’administration de serveur distant, ouvrez la Console de gestion des stratégies de groupe, en exécutant le fichier GPMC.MSC ou en recherchant « Console de gestion des stratégies de groupe ».
Créez un objet de stratégie de groupe, en cliquant avec le bouton droit de la souris sur l’unité d’organisation « PC activés DG », puis en cliquant sur Créer un objet GPO dans ce domaine, et le lier ici, comme indiqué dans la figure 13.

Remarque

Cette unité d’organisation est un simple exemple d’emplacement pour la création d’un lien avec l’objet de stratégie de groupe de test que vous avez créé via cette rubrique. En effet, vous pouvez utiliser le nom de votre choix. Par ailleurs, le filtrage des groupes de sécurité est une possibilité à prendre en compte lorsque vous envisagez de partitionner les stratégies, en fonction de la méthode abordée dans la rubrique Approche planifiée du déploiement de la protection de l’intégrité du code d’entreprise du présent document.

Figure 13. Création d’un objet de stratégie de groupe
Donnez au nouvel objet de stratégie de groupe le nom suivant : Test objet stratégie groupe fichier catalogue DG Contoso.

Pour les besoins de cet exemple, l’objet de stratégie de groupe porte le nom Contoso DG Catalog File GPO Test , mais vous pouvez choisir le nom que vous souhaitez.
Ouvrez l’Éditeur de gestion des stratégies de groupe. Ensuite, cliquez sur le nouvel objet de stratégie de groupe avec le bouton droit de la souris, puis cliquez sur Modifier.
Au sein de l’objet de stratégie de groupe, accédez à l’emplacement suivant : Configuration ordinateur\Préférences\Paramètres Windows\Fichiers. Cliquez sur Fichiers avec le bouton droit de la souris, pointez vers Nouveau, puis cliquez sur Fichier, comme indiqué dans la figure 14.

Figure 14. Création d’un fichier
Configurez le partage de fichiers catalogues.

Pour utiliser ce paramètre de manière à assurer le déploiement cohérent du fichier LOBApp-Contoso.cat, vous devez placer le fichier source sur un partage accessible au compte de chaque ordinateur déployé. Cet exemple utilise un partage sur un ordinateur client doté de Windows 10, appelé « \\Contoso-Win10\Partage ». Le fichier catalogue déployé est copié sur ce partage.
Pour assurer la cohérence des versions, accédez à la boîte de dialogue Nouvelles propriétés de Fichier (voir figure 15), puis sélectionnez l’option Remplacer dans la liste Action, afin de vous assurer que la version utilisée est la plus récente.

Figure 15. Définition des nouvelles propriétés de fichier
Dans la zone Fichiers source, saisissez le nom du partage accessible, en incluant le nom du fichier catalogue (par exemple : \\Contoso-Win10\partage\LOBApp-Contoso.cat).
Dans la zone Fichier de destination saisissez la chaîne suivante : C:\Windows\System32\racine_cat\{F750E6C3-38EE-11D1-85E5-00C04FC295EE}\LOBApp-Contoso.cat.

Remarque

Le nom « LOBApp-Contoso.cat » n’est pas obligatoire pour le catalogue. Il a été utilisé dans la rubrique Créer un fichier catalogue du présent document, donc nous l’utilisons également ici.
Sur l’onglet Commun de la boîte de dialogue Nouvelles propriétés de Fichier, choisissez l’option Supprimer l’élément lorsqu’il n’est plus appliqué. Cela permet de vérifier que le fichier catalogue est supprimé de tous les systèmes, au cas où vous devriez cesser d’approuver cette application.
Cliquez sur OK pour terminer la création du fichier.
Fermez l’Éditeur de gestion des stratégies de groupe, puis mettez la stratégie à jour sur l’ordinateur de test qui exécute Windows 10, en lançant le programme GPUpdate.exe. Une fois la stratégie mise à jour, vérifiez que le fichier catalogue se trouve bien à l’emplacement C:\Windows\System32\racine_cat\{F750E6C3-38EE-11D1-85E5-00C04FC295EE} de l’ordinateur doté de Windows 10.

Déployer des fichiers catalogues avec System Center Configuration Manager

Au lieu de la Stratégie de groupe, vous pouvez utiliser System Center Configuration Manager pour déployer des fichiers catalogue sur les ordinateurs gérés de votre environnement. Cette méthode peut simplifier le déploiement et la gestion de fichiers catalogues multiples, tout en assurant la création de rapports sur chaque catalogue déployé par chaque client ou collection. Parallèlement au déploiement de ces fichiers, le logiciel System Center Configuration Manager peut servir à l’inventaire des fichiers catalogues actuellement déployés, à des fins de mise en conformité ou de création de rapports. Procédez comme suit pour créer un package de déploiement pour les fichiers catalogues :

Remarque

L’exemple suivant utilise un partage réseau appelé « \\Partages\CatalogShare » comme source pour les fichiers catalogues. Si vous disposez de fichiers catalogues spécifiques pour les collections, ou préférez les déployer au cas par cas, utilisez la structure de dossiers qui convient le mieux à votre entreprise.

Ouvrez la console du gestionnaire de configuration et sélectionnez l’espace de travail Bibliothèque de logiciels.
Accédez à l’emplacement Vue d’ensemble\Gestion des applications, cliquez avec le bouton droit de la souris sur Packages, puis sélectionnez Créer le package.
Donnez un nom au package, définissez votre organisation en tant que fabricant, puis sélectionnez un numéro de version approprié (voir figure 16).

Figure 16. Spécification d’informations sur le nouveau package
Cliquez sur Suivant, puis sélectionnez le type de programme Programme standard.
Sur la page Programme standard, choisissez un nom, puis définissez la propriété Ligne de commande sur XCopy \\Partages\CatalogShare C:\Windows\System32\racine_cat\{F750E6C3-38EE-11D1-85E5-00C04FC295EE} /H /K /E /Y.
Sur la page Programme standard, sélectionnez les options suivantes (voir figure 17) :
- Dans le champ Nom, saisissez Programme copie fichier catalogue Contoso.
- Dans Ligne de commande, accédez à l’emplacement du programme.
- Dans Dossier Démarrage, saisissez le chemin C:\Windows\System32.
- Dans la liste Exécuter, sélectionnez Masqué.
- Dans la liste Le programme peut s’exécuter, choisissez Qu’un utilisateur ait ouvert une session ou non.
- Dans la liste Mode lecteur liste, sélectionnez S’exécute avec le nom UNC.
Figure 17. Spécification d’informations sur le programme standard
Acceptez les valeurs par défaut pour le reste de l’assistant, puis fermez ce dernier.

Une fois le package de déploiement créé, déployez-le dans une collection, afin que les clients puissent recevoir les fichiers catalogues. Dans cet exemple, vous allez déployer le package que vous venez de créer dans une collection de test :

Dans l’espace de travail Bibliothèque de logiciels, accédez à l’emplacement Vue d’ensemble\Gestion des applications\Packages, puis cliquez avec le bouton droit de la souris sur le package du fichier catalogue, puis sélectionnez Déployer.
Sur la page Général, sélectionnez la collection de test sur laquelle déployer les fichiers catalogues, puis cliquez sur Suivant.
Sur la page Contenu, cliquez sur Ajouter pour sélectionner le point de distribution du contenu à la collection sélectionnée, puis cliquez sur Suivant.
Sur la page Paramètres de déploiement, sélectionnez Requis dans la zone Objectif.
Sur la page Planification, cliquez sur Nouveau.
Dans la boîte de dialogue Calendrier d’attribution, sélectionnez Attribuer immédiatement après cet événement, définissez la valeur sur Dès que possible, puis cliquez sur OK.
Sur la page Planification, cliquez sur Suivant.
Sur la page Expérience utilisateur (voir figure 18), définissez les options suivantes, puis cliquez sur Suivant :
- Cochez la case Installation de logiciel.
- Cochez la case Valider les changements à l’échéance ou pendant une fenêtre de maintenance (redémarrage requis).
Figure 18. Spécification de l’expérience utilisateur
Sur la page Points de distribution, dans la zone Options de déploiement, sélectionnez Exécuter le programme à partir du point de distribution, puis cliquez sur Suivant.
Sur la page Résumé, passez en revue les sélections, puis cliquez sur Suivant.
Fermez l’assistant.

Création d’un inventaire des fichiers catalogues avec System Center Configuration Manager

Lorsque des fichiers catalogue ont été déployés sur les ordinateurs au sein de votre environnement, via SCCM ou la Stratégie de groupe, vous pouvez créer un inventaire de ces derniers grâce à la fonction d’inventaire logiciel de SCCM. Ce processus vous guide lors de l’activation de l’inventaire logiciel, afin de découvrir les fichiers catalogues sur vos systèmes gérés, via la création et le déploiement d’une nouvelle stratégie de paramètres pour les clients.

Remarque

Une convention d’affectation de noms standard pour les fichiers catalogues permet de simplifier considérablement le processus d’inventaire logiciel des fichiers catalogues. Dans cet exemple, l’élément -Contoso a été ajouté à tous les noms de fichiers catalogues.

Ouvrez la console du gestionnaire de configuration et sélectionnez l’espace de travail Administration.
Accédez à l’emplacement Vue d’ensemble\Paramètres du client, cliquez avec le bouton droit de la souris sur Paramètres du client, puis cliquez sur Créer des paramètres de périphérique client personnalisés.
Donnez un nom à la nouvelle stratégie, puis cochez la case Inventaire logiciel dans la liste Sélectionnez puis configurez les paramètres personnalisés pour les périphériques client (voir figure 19).

Figure 19. Sélection des paramètres personnalisés
Dans le volet de navigation, cliquez sur Inventaire logiciel, puis cliquez sur Définir des types (voir figure 20).

Figure 20. Définition de l’inventaire logiciel
Dans la boîte de dialogue Configurer le paramètre client, cliquez sur le bouton Démarrer pour ouvrir la boîte de dialogue Propriétés du fichier inventorié.
Dans la zone Nom, saisissez *Contoso.cat, puis cliquez sur Définir.

Remarque

*Contoso.cat correspond à la convention d’affectation de noms utilisée dans cet exemple. Ce nom doit reproduire la convention de d’affectation de noms que vous utilisez pour vos propres fichiers catalogues.
Dans la boîte de dialogue Propriétés du chemin d’accès, sélectionnez Variable ou chemin d’accès, puis saisissez la chaîne C:\Windows\System32\racine_cat\{F750E6C3-38EE-11D1-85E5-00C04FC295EE} dans la zone (voir figure 21).

Figure 21. Définition des propriétés du chemin d’accès
Cliquez sur OK.
La stratégie des paramètres des clients étant créée, cliquez avec le bouton droit de la souris sur la nouvelle stratégie, cliquez sur Déployer, puis sélectionnez la collection sur laquelle créer l’inventaire des fichiers catalogues.

Lors du cycle d’inventaire logiciel suivant, lorsque les clients ciblés reçoivent la nouvelle stratégie de paramètres des clients, vous pouvez afficher les fichiers d’inventaire dans les rapports SCCM intégrés, ou dans l’Explorateur de ressources. Pour afficher les fichiers inventoriés sur un client au sein de l’Explorateur de ressources, procédez comme suit :

Ouvrez la console du gestionnaire de configuration et sélectionnez l’espace de travail Ressources et Conformité.
Accédez à l’emplacement Vue d’ensemble\Appareils, puis recherchez l’appareil sur lequel afficher les fichiers inventoriés.
Cliquez avec le bouton droit de la souris sur l’ordinateur, pointez sur Démarrer, puis cliquez sur Explorateur de ressources.
Dans l’Explorateur de ressources, accédez à l’emplacement Logiciels\Détails du fichier pour afficher les fichiers catalogues inventoriés.

Remarque

Si aucun élément ne s’affiche dans cette vue, accédez à l’emplacement Logiciels\Dernière analyse logicielle de l’Explorateur de ressources pour vérifier que le client a récemment terminé l’analyse de l’inventaire logiciel.

Stratégies d’intégrité du code

Les stratégies d’intégrité du code gèrent les normes permettant à un ordinateur exécutant Windows 10 de déterminer si une application est fiable et peut être exécutée. Pour accéder à une vue d’ensemble de l’intégrité du code, consultez la rubrique Intégrité du code configurable du présent document.

Actuellement, l’une des pratiques souvent appliquées par les services informatiques en matière de création d’images système consiste à créer une image « de référence », qui illustre le système idéal, puis à utiliser cette image pour le clonage des ressources supplémentaires de l’entreprise. Les stratégies d’intégrité du code suivent une méthodologie similaire, qui commence par la création d’un PC de référence. Par exemple, lors de la création d’images, vous pouvez disposer de plusieurs PC de référence associés au modèle, au service, à l’application définie, etc. Bien que le processus associé à la création de stratégies d’intégrité du code soit similaire à celui de la création d’images, ces stratégies doivent être gérées de manière indépendante. Évaluez la nécessité de créer des stratégies d’intégrité du code supplémentaires, selon les applications dont l’installation et l’autorisation doivent être autorisées et les utilisateurs concernés.

Remarque

Une seule stratégie d’intégrité du code peut être active sur un ordinateur à la fois. Quel que soit le mode choisi pour le déploiement de cette stratégie, cette dernière prend le nom « SIPolicy.p7b » et est copiée à l’emplacement C:\Windows\System32\CodeIntegrity. Tenez compte de ce facteur lorsque vous créez des stratégies d’intégrité du code.

Si vous le souhaitez, vous pouvez aligner les stratégies d’intégrité du code sur votre catalogue de logiciels, ainsi que toutes les applications approuvées par le service informatique. Une méthode simple pour implémenter ces stratégies consiste à recourir à des images existantes pour créer une stratégie d’intégrité du code principale. Pour ce faire, créez une stratégie d’intégrité du code à partir de chaque image, puis fusionnez les stratégies. Ainsi, les applications installées sur l’ensemble de ces images seront autorisées à s’exécuter, même si les applications sont installées sur un ordinateur basé sur une image différente. Par ailleurs, vous pouvez choisir de créer une stratégie pour les applications de base et d’ajouter les stratégies en fonction du service ou du rôle de l’ordinateur. Les entreprises ont le choix entre différents modes de création, de fusion, de traitement ou de gestion de leurs stratégies.

Remarque

La rubrique suivante part du principe que vous allez déployer des stratégies d’intégrité du code en même temps que Device Guard. Il est cependant possible d’utiliser la fonction de protection de l’intégrité du code configurable sans avoir à activer Device Guard.

Règles des stratégies d’intégrité du code

Ces règles incluent plusieurs composantes. Les deux composantes principales, qui peuvent être configurées, sont appelées règles de stratégie et règles de fichier, respectivement. Les règles de stratégie d’intégrité du code sont des options que le créateur d’une stratégie peut indiquer sur cette dernière. Ces options portent sur l’activation du mode audit, l’intégrité UMCI, etc. Vous pouvez modifier ces options dans une stratégie d’intégrité du code nouvelle ou existante. Les règles de fichier correspondent au niveau auquel l’analyse de la stratégie d’intégrité du code lie chaque approbation binaire. Par exemple, le niveau de hachage doit détailler chaque hachage découvert sur le système au sein de la stratégie d’intégrité du code générée. Ainsi, lorsqu’un fichier binaire se prépare à s’exécuter, le service d’intégrité du code valide sa valeur de hachage en fonction des hachages approuvés détectés dans la stratégie d’intégrité du code. En fonction de ce résultat, le fichier binaire sera ou non autorisé à s’exécuter.

Pour modifier les options de règle de stratégie d’une stratégie d’intégrité du code existante, utilisez l’applet de commande Set-RuleOption de Windows PowerShell. Tenez compte des exemples suivants pour savoir comment utiliser cette applet de commande afin d’ajouter et de supprimer une option de règle sur une stratégie d’intégrité du code existante :

Pour activer l’intégrité UMCI, ajoutez l’option de règle 0 à une stratégie existante, en exécutant la commande suivante :

Set-RuleOption -Option 0 -FilePath <Path to policy>
Pour désactiver l’intégrité UMCI sur une stratégie d’intégrité du code existante, supprimez l’option de règle 0 en exécutant la commande suivante :

Set-RuleOption -Option 0 -FilePath <Path to policy> -Delete

Vous pouvez définir plusieurs options de règle au sein d’une stratégie d’intégrité du code. Le tableau 2 répertorie chaque règle et sa signification globale.

Tableau 2. Stratégie d’intégrité du code : options de règle de stratégie

Option de règle	Description
0 - Activé:UMCI	Les stratégies d’intégrité du code limitent les fichiers binaires en mode noyau et en mode utilisateur. Par défaut, seuls les fichiers binaires en mode noyau sont limités. L’activation de cette option de règle permet de valider les scripts et fichiers exécutables du mode utilisateur.
1 - Activé:Protection du menu de démarrage	Cette option n’est pas prise en charge pour le moment.
2 - Requis:WHQL	Par défaut, les pilotes hérités qui ne sont pas signés par le laboratoire WHQL (Windows Hardware Quality Labs) sont autorisés à s’exécuter. L’activation de cette règle nécessite que chaque pilote exécuté soit signé par le laboratoire WHQL et supprime la prise en charge des pilotes hérités. À l’avenir, chaque nouveau pilote compatible avec Windows 10 devra être certifié par le laboratoire WHQL.
3 - Activé:Mode audit (valeur par défaut)	Permet l’exécution de fichiers binaires en dehors de la stratégie d’intégrité du code, mais enregistre chaque occurrence dans le journal des événements CodeIntegrity, qui peut être utilisé pour mettre à jour la stratégie existante avant sa mise en œuvre. Pour appliquer une stratégie d’intégrité du code, supprimez cette option.
4 - Désactivé:Signature de la version d’évaluation	Si cette option est activée, les stratégies d’intégrité du code n’approuvent pas les fichiers binaires signés par la version d’évaluation racine. Cette option peut être utilisée lorsqu’une entreprise souhaite uniquement exécuter les fichiers binaires publiés, et non les builds de version d’évaluation.
5 - Activé:Stratégie par défaut implicite	Cette option n’est pas prise en charge pour le moment.
6 - Activé:Stratégie d’intégrité système non signée (par défaut)	Permet à la stratégie de rester non signée. Lorsque cette option est supprimée, la stratégie doit être signée et ajouter l’élément UpdatePolicySigners à la stratégie pour permettre toute modification future de cette dernière.
7 - Autorisé:Stratégie de débogage augmentée	Cette option n’est pas prise en charge pour le moment.
8 - Requis:Signataires de validation étendue	Selon cette règle, les pilotes doivent avoir été soumis par un partenaire titulaire d’un certificat de vérification étendue (EV, Extended Verification) en plus d’être signés par le laboratoire WHQL. Tous les pilotes de Windows 10 et versions ultérieures devront respecter cette condition requise.
9 - Activé:Menu des options de démarrage avancées	Le menu d’options préalables au démarrage F8 est désactivé par défaut pour toutes les stratégies d’intégrité du code. Si vous définissez cette option de règle, le menu F8 s’affiche pour les utilisateurs physiquement présents.
10 - Activé:Audit au démarrage en cas d’échec	Cette option est utilisée lorsque la stratégie d’intégrité du code est en mode de mise en conformité. Lorsqu’un pilote échoue au démarrage, la stratégie d’intégrité du code est placée en mode audit afin que le système d’exploitation Windows puisse se charger. Les administrateurs peuvent valider la cause de l’échec dans le journal des événements CodeIntegrity.

Les niveaux de règle de fichier permettent aux administrateurs de spécifier le niveau auquel ils souhaitent approuver leurs applications. Ce niveau d’approbation peut être peu élevé (hachage de chaque fichier binaire, par exemple), ou très élevé, comme celui du certificat de l’Assistant Compatibilité des programmes. Les niveaux de règle de fichier sont indiqués lorsque vous créez une stratégie d’intégrité du code à partir d’une analyse, et lorsque vous créez une stratégie à partir d’événements d’audit. En outre, pour combiner les niveaux de règle détectés dans plusieurs stratégies, vous pouvez fusionner ces dernières. Lors de la fusion, les stratégies d’intégrité du code combinent leurs règles de fichier. Chaque niveau de règle de fichier présente ses propres avantages et inconvénients. Le tableau 3 vous permet de sélectionner le niveau de protection approprié pour les ressources d’administration et le scénario de déploiement Device Guard disponibles.

Tableau 3. Stratégie d’intégrité du code : niveaux de règle de fichier

Niveau de règle	Description
Hash	Spécifie des valeurs de hachage individuelles pour chaque fichier binaire détecté. Bien que ce niveau soit spécifique, il peut provoquer une surcharge administrative supplémentaire, liée à la gestion des valeurs de hachage des versions de produit actuelles. Chaque fois qu’un fichier binaire est mis à jour, la valeur de hachage change, ce qui nécessite la mise à jour de la stratégie.
FileName	Spécifie les noms des fichiers binaires. Bien que les valeurs de hachage d’une application soient modifiées lors de la mise à jour, les noms de fichiers ne le sont généralement pas. La sécurité ainsi offerte est moins spécifique que le niveau de hachage, mais elle ne nécessite généralement pas la mise à jour de la stratégie lorsqu’un fichier binaire est modifié.
SignedVersion	Ce paramètre associe la règle d’éditeur avec un numéro de version de fichier. Cette option vous permet d’exécuter toutes les applications provenant de l’éditeur spécifié dont la version de fichier est située au niveau du numéro de version, ou plus.
Publisher	Il s’agit d’une combinaison du certificat de l’Assistant Compatibilité des programmes et du nom commun (CN) sur le certificat feuille. Si un certificat de l’Assistant Compatibilité des programmes est utilisé pour signer des applications de plusieurs entreprises (comme VeriSign), ce niveau de règle permet d’approuver le certificat de l’Assistant Compatibilité des programmes, mais uniquement pour l’entreprise dont le nom figure sur le certificat feuille (par exemple, Intel, dans le cas des pilotes de périphérique). Ce niveau permet d’approuver un certificat associé à une longue période de validité, mais uniquement lorsqu’il est combiné avec un certificat feuille approuvé.
FilePublisher	Il s’agit de l’association du niveau de règle de fichier d’éditeur et du niveau de règle SignedVersion. Tout fichier signé par l’éditeur approuvé qui présente la version spécifiée, ou une version plus récente, est approuvé.
LeafCertificate	Ajoute les signataires approuvés au niveau du certificat de signature individuel. Ce niveau présente un avantage par rapport au niveau de hachage individuel : les nouvelles versions du produit présenteront des valeurs de hachage différentes, mais un même certificat de signature. Grâce à ce niveau, aucune mise à jour des stratégies n’est requise pour l’exécution de la nouvelle version de l’application. Toutefois, la période de validité des certificats feuille est nettement plus réduite que celle des certificats de l’Assistant Compatibilité des programmes ; de ce fait, la mise à jour de la stratégie d’intégrité du code lors de l’expiration de ces certificats nécessite une surcharge administrative.
PcaCertificate	Ajoute le certificat le plus élevé à la chaîne de certificats fournie aux signataires. Il s’agit généralement d’un certificat situé au-dessous du certificat racine, car l’analyse ne valide pas les éléments au-dessus de la signature présentée en se connectant ou en effectuant des recherches dans les magasins racines locaux.
RootCertificate	Non pris en charge actuellement.
WHQL	Les fichiers binaires sont approuvés s’ils ont été validés par le laboratoire WHQL. Cela concerne principalement les fichiers binaires du noyau.
WHQLPublisher	Il s’agit de l’association du nom commun et de la valeur WHQL sur le certificat feuille ; cela concerne principalement les fichiers binaires du noyau.
WHQLFilePublisher	Indique que les fichiers binaires ont été validés et signés par le laboratoire WHQL avec un éditeur spécifique (WHQLPublisher), et que le fichier binaire présente la version spécifiée, ou une version plus récente. Cela concerne principalement les fichiers binaires du noyau.

Remarque

Lorsque vous créez des stratégies d’intégrité de code avec l’applet de commande New-CIPolicy, vous pouvez spécifier un niveau de règle de fichier principal en incluant le paramètre –Level. Pour les fichiers binaires découverts qui ne peuvent pas être approuvés en fonction des critères de règle de fichier principaux, utilisez le paramètre –Fallback. Par exemple, si le niveau de la règle de fichier principal est « PCACertificate », mais que vous souhaitez également approuver les applications non signées, utilisez le niveau de règle « Hash » en tant que niveau de secours pour ajouter les valeurs de hachage des fichiers binaires qui ne disposent pas d’un certificat de signature.

Créer des stratégies d’intégrité du code sur des PC de référence

La création d’une stratégie d’intégrité du code de référence à partir d’un système de référence est un processus simple. Cette rubrique souligne le processus requis pour créer une stratégie d’intégrité du code avec Windows PowerShell. Pour les besoins de cet exemple, vous devez d’abord initier les variables à utiliser lors de la création. Pour éviter d’utiliser des variables, vous pouvez simplement indiquer les chemins d’accès de fichiers complets dans la commande. Ensuite, créez la stratégie d’intégrité du code en analysant le système, afin de détecter les applications installées. Lors de sa création, le fichier de stratégie est converti au format binaire, afin que Windows puisse utiliser son contenu.

Remarque

Avant de commencer cette procédure, vous devez vous assurer que le PC de référence ne présente aucun virus ou programme malveillant. Chaque élément de logiciel installé doit être considéré comme digne de confiance avant la création de cette stratégie. En outre, vérifiez que les logiciels que vous souhaitez analyser sont installés sur le système avant de créer la stratégie d’intégrité du code.

Pour créer cette dernière, copiez chacune des commandes suivantes dans une session Windows PowerShell avec élévation des privilèges, dans l’ordre :

Initialisez les variables que vous utiliserez :

$CIPolicyPath=$env:userprofile+"\Desktop\"

$InitialCIPolicy=$CIPolicyPath+"InitialScan.xml"

$CIPolicyBin=$CIPolicyPath+"DeviceGuardPolicy.bin"
Créez la stratégie d’intégrité du code en analysant le système, afin de détecter les applications installées :

New-CIPolicy -Level PcaCertificate -FilePath $InitialCIPolicy –UserPEs 3> CIPolicyLog.txt

Remarque

Si vous spécifiez le paramètre –UserPEs, l’option de règle 0 - Activé:UMCI est automatiquement ajoutée à la stratégie d’intégrité du code. Si vous ne spécifiez pas ce paramètre, utilisez la commande suivante pour activer l’intégrité UMCI :

Set-RuleOption -Option 0 -FilePath $InitialCIPolicy

Remarque

Vous pouvez ajouter le paramètre –Fallback pour identifier toutes les applications non découvertes à l’aide du niveau de règle de fichier principal spécifié par le paramètre –Level. Pour en savoir plus sur les options de niveau de règle de fichier, consultez la rubrique Règles des stratégies d’intégrité du code du présent document.

Remarque

Si vous souhaitez spécifier que la stratégie d’intégrité du code ne doit faire de recherches que sur un lecteur spécifique, il vous suffit d’utiliser le paramètre –ScanPath. Sans ce paramètre, comme illustré dans l’exemple, l’ensemble du système est analysé.
Convertissez la stratégie d’intégrité du code au format binaire :

ConvertFrom-CIPolicy $InitialCIPolicy $CIPolicyBin

Une fois que vous avez effectué ces étapes, le fichier binaire Device Guard (DeviceGuardPolicy.bin) et le fichier .xml d’origine (InitialScan.xml) sont disponibles sur votre Bureau. Vous pouvez utiliser la version du fichier binaire en tant que stratégie d’intégrité du code, ou vous connecter pour renforcer la sécurité.

Remarque

Microsoft vous recommande de conserver le fichier .xml d’origine de la stratégie à utiliser lorsque vous avez besoin de fusionner la stratégie d’intégrité du code avec une autre stratégie, ou de mettre à jour ses options de règle. Sinon, il vous faut créer une stratégie suite à une nouvelle analyse, à des fins de maintenance. Pour savoir comment fusionner des stratégies d’intégrité du code à un audit, consultez la rubrique Fusionner des stratégies d’intégrité du code du présent document.

Microsoft vous recommande d’exécuter chaque stratégie d’intégrité du code en mode audit avant de l’appliquer. Cela permet aux administrateurs de découvrir tout problème éventuel lié à la stratégie sans voir apparaître des boîtes de dialogue affichant des messages d’erreur. Pour savoir comment soumettre une stratégie d’intégrité du code à un audit, consultez la rubrique Soumettre des stratégies d’intégrité du code à un audit du présent document.

Soumettre des stratégies d’intégrité du code à un audit

Lorsque des stratégies d’intégrité du code sont exécutées en mode audit, les administrateurs peuvent détecter les applications que l’analyse initiale des stratégies n’a pas pu découvrir, et identifier toute nouvelle application installée et exécutée depuis la création de la stratégie d’origine. Lorsqu’une stratégie d’intégrité du code est exécutée en mode audit, tout fichier binaire lancé qui aurait été refusé si la stratégie avait été appliquée est consignée dans le journal des événements, à l’emplacement Journaux des applications et des services\Microsoft\CodeIntegrity\Opérationnel. Une fois validés, les fichiers binaires consignés peuvent aisément être ajoutés à une nouvelle stratégie d’intégrité du code. Lorsqu’une stratégie d’exception est créée, vous pouvez la fusionner dans vos stratégies d’intégrité du code existantes.

Remarque

Avant de commencer ce processus, vous devez créer un fichier binaire pour la stratégie d’intégrité du code. Si ce n’est déjà fait, consultez la rubrique Créer une stratégie d’intégrité du code en mode audit du présent document pour accéder à une procédure pas à pas d’exécution du processus, afin de créer une stratégie d’intégrité du code et de la convertir au format binaire.

Pour soumettre une stratégie d’intégrité du code à un audit avec la stratégie locale :

Copiez le fichier DeviceGuardPolicy.bin créé via la rubrique Créer des stratégies d’intégrité du code sur des PC de référence du présent document à l’emplacement C:\Windows\System32\CodeIntegrity.
Sur le système à exécuter en mode audit, ouvrez l’Éditeur de stratégie de groupe locale en exécutant le fichier GPEdit.msc.
Accédez à l’emplacement suivant : Configuration ordinateur\Modèles d’administration\Système\Device Guard, puis sélectionnez Déployer la stratégie d’intégrité du code. Activez ce paramètre en utilisant le chemin d’accès de fichier suivant : C:\Windows\System32\CodeIntegrity\DeviceGuardPolicy.bin, comme illustré dans la figure 22.

Remarque

DeviceGuardPolicy.bin n’est pas un nom de stratégie requis. Il s’agit simplement du nom utilisé dans la rubrique Créer des stratégies d’intégrité du code sur des PC de référence du présent document, que nous avons réutilisé ici. En outre, ce fichier de stratégie ne doit pas nécessairement être copié sur tous les systèmes. Vous pouvez également copier les stratégies d’intégrité du code sur un partage de fichiers auquel tous les comptes d’ordinateur ont accès.

Remarque

Toute stratégie sélectionnée ici est convertie et se voit affecter le nom « SIPolicy.p7b » lorsqu’elle est déployée sur les différents ordinateurs.

Figure 22. Déploiement de la stratégie d’intégrité du code

Remarque

Vous avez peut-être remarqué que le paramètre d’objet de stratégie de groupe fait référence à un fichier .p7b, alors que cette stratégie utilise un fichier .bin. Tous les types de stratégie déployés (.bin, .p7b ou .p7) sont convertis et se voient affecter le nom « SIPolicy.p7b » lorsqu’ils sont placés sur les ordinateurs dotés de Windows 10. Microsoft vous recommande de rendre vos stratégies d’intégrité du code conviviales et d’autoriser le système à convertir les noms de stratégies à votre place. Ce faisant, vous vous assurez que les stratégies sont aisément identifiables lorsqu’elles sont affichées dans un partage ou tout autre référentiel central.
Redémarrez le système de référence pour activer la stratégie d’intégrité du code.
Surveillez le journal des événements CodeIntegrity. En mode audit, toute exception associée à la stratégie d’intégrité du code déployée est consignée dans le journal des événements, à l’emplacement Journaux des applications et des services\Microsoft\CodeIntegrity\Opérationnel, comme indiqué à la figure 23.

Figure 23. Exceptions relatives à la stratégie d’intégrité du code déployée
Validez les exceptions associées aux stratégies d’intégrité du code.

Lorsque vous exécutez une stratégie d’intégrité du code en mode audit, Microsoft vous recommande de rechercher et de valider chaque exception consignée. En plus de découvrir l’application qui déclenche l’exception et de faire en sorte qu’elle soit ajoutée à la stratégie d’intégrité du code, vous devez vérifier le niveau de fichier à utiliser pour approuver chaque application. Bien que le niveau de règle de fichier Hash intercepte toutes ces exceptions, cela n’est peut-être pas le moyen idéal d’approuver toutes les exceptions. Pour en savoir plus sur les niveaux de règle de fichier et leur objectif, consultez la rubrique Règles des stratégies d’intégrité du code du présent document.
Créez la stratégie d’intégrité du code à partir des événements d’audit.

Pour en savoir plus sur la création de stratégies d’intégrité du code à partir d’événements d’audit, consultez la rubrique Créer des stratégies d’intégrité du code sur des PC de référence du présent document.

Remarque

Pour tester une stratégie, vous pouvez aussi donner au fichier de test le nom « SIPolicy.p7b », puis le placer à l’emplacement C:\Windows\System32\CodeIntegrity, plutôt que de le déployer avec la stratégie de l’ordinateur local.

Créer une stratégie d’intégrité du code en mode audit

Lorsque vous exécutez des stratégies d’intégrité du code en mode audit, vous devez valider toutes les exceptions et déterminer si vous devez les ajouter à la stratégie d’intégrité du code que vous souhaitez soumettre à un audit. Utilisez le système comme vous le feriez normalement pour vous assurer que toutes les exceptions d’utilisation sont consignées. Pour créer une stratégie d’intégrité du code à partir des événements d’audit, procédez comme suit dans une session Windows PowerShell avec élévation de privilèges :

Initialisez les variables qui seront utilisées :

$CIPolicyPath=$env:userprofile+"\Desktop\"

$CIAuditPolicy=$CIPolicyPath+"DeviceGuardAuditPolicy.xml"
Analysez les résultats de l’audit.

Avant de créer une stratégie d’intégrité du code à partir des événements d’audit, Microsoft vous recommande d’analyser chaque exception, comme indiqué dans les étapes 5 et 6 de la rubrique Soumettre des stratégies d’intégrité du code à un audit du présent document.
Générez une stratégie d’intégrité du code à partir des événements d’audit consignés :

New-CIPolicy -Audit -Level Hash -FilePath $CIAuditPolicy –UserPEs 3> CIPolicylog.txt

Remarque

Lorsque vous créez des stratégies à partir d’événements d’audit, vous devez envisager avec soin le niveau de règle de fichier que vous sélectionnez pour approbation. Dans cet exemple, vous utilisez le niveau de règle Hash, qui doit être utilisé en dernier recours.

Une fois que vous avez effectué ces étapes, le fichier .xml de la stratégie d’audit Device Guard (DeviceGuardAuditPolicy.xml) est disponible sur votre Bureau. Vous pouvez désormais l’utiliser pour mettre à jour la stratégie d’intégrité du code existante que vous avez exécutée en mode audit, en fusionnant les deux stratégies. Pour savoir comment fusionner cette stratégie d’audit avec la stratégie d’intégrité du code existante, consultez la rubrique Fusionner des stratégies d’intégrité du code du présent document.

Remarque

Vous avez peut-être remarqué qu’aucune version de fichier binaire de cette stratégie n’a été générée, contrairement à la procédure effectuée via la rubrique Créer des stratégies d’intégrité du code sur des PC de référence. En effet, les stratégies d’intégrité du code créées à partir d’un journal d’audit n’ont pas pour objectif de fonctionner en tant que stratégies autonomes, mais plutôt d’être associées à la mise à jour des stratégies d’intégrité du code existantes.

Fusionner des stratégies d’intégrité du code

Lorsque vous développez des stratégies d’intégrité du code, vous devez parfois fusionner deux stratégies, par exemple lorsque la stratégie d’intégrité du code est créée et soumise à un audit, ou lorsque vous créez une stratégie principale unique en utilisant plusieurs stratégies créées à partir de PC de référence. Comme chaque ordinateur Windows 10 peut inclure une seule stratégie d’intégrité du code, ces stratégies doivent être correctement gérées. Dans cet exemple, les événements d’audit ont été enregistrés au sein d’une stratégie d’intégrité du code secondaire, que vous fusionnez ensuite avec la stratégie d’intégrité du code initiale.

Remarque

L’exemple suivant utilise les fichiers .xml de la stratégie d’intégrité du code que vous avez créés via les rubriques Créer des stratégies d’intégrité du code sur des PC de référence et Soumettre des stratégies d’intégrité du code à un audit du présent document. Toutefois, vous pouvez suivre ce processus en combinant les deux stratégies d’intégrité du code de votre choix.

Pour fusionner ces deux stratégies, procédez comme suit dans une session Windows PowerShell avec élévation de privilèges :

Initialisez les variables qui seront utilisées :

$CIPolicyPath=$env:userprofile+"\Desktop\"

$InitialCIPolicy=$CIPolicyPath+"InitialScan.xml"

$AuditCIPolicy=$CIPolicyPath+"DeviceGuardAuditPolicy.xml"

$MergedCIPolicy=$CIPolicyPath+"MergedPolicy.xml"

$CIPolicyBin=$CIPolicyPath+"NewDeviceGuardPolicy.bin"

Remarque

Les variables de cette section s’attendent spécifiquement à trouver sur votre Bureau une stratégie initiale portant le nom « InitialScan.xml », ainsi qu’une stratégie d’intégrité du code d’audit appelée « DeviceGuardAuditPolicy.xml ». Si vous souhaitez fusionner d’autres stratégies d’intégrité du code, mettez les variables à jour en conséquence.
Fusionnez les deux stratégies pour créer une stratégie d’intégrité du code :

Merge-CIPolicy -PolicyPaths $InitialCIPolicy,$AuditCIPolicy -OutputFilePath $MergedCIPolicy
Convertissez la stratégie d’intégrité du code fusionnée au format binaire :

ConvertFrom-CIPolicy $MergedCIPolicy $CIPolicyBin

Maintenant que vous avez créé une stratégie d’intégrité du code appelée « NewDeviceGuardPolicy.bin », vous pouvez la déployer sur les systèmes manuellement, ou via une solution de gestion des clients Microsoft ou la Stratégie de groupe. Pour en savoir plus sur le déploiement de la nouvelle stratégie via la Stratégie de groupe, consultez la rubrique Déployer et gérer des stratégies d’intégrité du code via une Stratégie de groupe du présent document.

Appliquer des stratégies d’intégrité du code

Chaque stratégie d’intégrité du code est créée avec le mode audit activé. Une fois que vous avez déployé et testé une stratégie d’intégrité du code en mode audit, en vous apprêtant à la tester dans le mode appliqué, procédez comme suit dans une session Windows PowerShell avec élévation de privilèges :

Remarque

Chaque stratégie d’intégrité du code doit d’abord être testée en mode audit. Pour savoir comment soumettre des stratégies d’intégrité du code à un audit, consultez la rubrique Soumettre des stratégies d’intégrité du code à un audit du présent document.

Initialisez les variables qui seront utilisées :

$CIPolicyPath=$env:userprofile+"\Desktop\"

$InitialCIPolicy=$CIPolicyPath+"InitialScan.xml"

$EnforcedCIPolicy=$CIPolicyPath+"EnforcedPolicy.xml"

$CIPolicyBin=$CIPolicyPath+"EnforcedDeviceGuardPolicy.bin"

Remarque

La stratégie d’intégrité du code initiale référencée par cette session a été créée via la rubrique Créer des stratégies d’intégrité du code sur des PC de référence du présent document. Si vous en utilisez une autre, mettez à jour les variables CIPolicyPath et InitialCIPolicy.
Copiez le fichier initial afin de conserver une copie d’origine :

cp $InitialCIPolicy $EnforcedCIPolicy
Supprimez l’option de règle en mode audit :

Set-RuleOption -Option 3 -FilePath $EnforcedCIPolicy -Delete

Remarque

Au lieu d’ajouter l’option Appliqué, le système applique les stratégies d’intégrité du code de manière implicite lorsqu’aucune option Mode audit activé n’est présente.
Convertissez la nouvelle stratégie d’intégrité du code au format binaire :

ConvertFrom-CIPolicy $EnforcedCIPolicy $CIPolicyBin

Remarque

Microsoft vous recommande vivement d’activer les options de règle 9 et 10 avant d’exécuter toute stratégie appliquée pour la première fois. Si elles sont déjà présentes dans la stratégie, ne les supprimez pas. En effet, si vous les supprimez, Windows est autorisé à démarrer lorsque la stratégie d’intégrité du code empêche un pilote en mode noyau de s’exécuter et fournit aux administrateurs une invite de commandes préalable au démarrage. Lorsque vous êtes prêt à effectuer le déploiement en entreprise, vous pouvez supprimer ces options.

Maintenant que cette stratégie a été appliquée, vous pouvez la déployer sur vos ordinateurs de test. Donnez à la stratégie le nom «SIPolicy.p7b » et copiez-la à l’emplacement C:\Windows\System32\CodeIntegrity à des fins de test, ou déployez-la via la Stratégie de groupe, en suivant les instructions de la rubrique Déployer et gérer des stratégies d’intégrité du code avec une Stratégie de groupe du présent document. Vous pouvez aussi la déployer via le logiciel de gestion des clients, en suivant les instructions de la rubrique relative au déploiement et à la gestion de stratégies d’intégrité du groupe via des solutions de gestion des clients Microsoft.

Signature de stratégies d’intégrité du code avec l’outil SignTool.exe

Les stratégies d’intégrité du code signées donnent aux entreprises le niveau de protection contre les programmes malveillants le plus élevé disponible dans Windows 10. Comme leurs règles de stratégie appliquées, les stratégies signées ne peuvent pas être modifiées ou supprimées par l’utilisateur ou l’administrateur de l’ordinateur. Ces stratégies sont conçues pour éviter toute modification administrative, ainsi que tout accès illicite par du code malveillant exploitant une faille de sécurité en mode noyau. Ceci dit, il est beaucoup plus difficile de supprimer les stratégies d’intégrité du code lorsqu’elles sont signées. Avant de signer et de déployer une stratégie d’intégrité du code, Microsoft vous recommande de la soumettre à un audit, afin de découvrir toutes les applications bloquées qui devraient être autorisées à s’exécuter. Pour savoir comment soumettre des stratégies d’intégrité du code à un audit, consultez la rubrique Soumettre des stratégies d’intégrité du code à un audit du présent document.

Pour signer des stratégies d’intégrité du code à l’aide d’un certificat généré par une autorité de certification sur site ou un certificat de signature de code acheté, vous devez suivre une procédure très simple. Si vous ne disposez d’aucun certificat de signature de code exporté au format .pfx (qui contient des clés privées, des extensions et des certificats racine), créez-en un via l’autorité de certification sur site, en vous référant à la rubrique Créer un certificat de signature de code Device Guard du présent document. Avant de signer des stratégies d’intégrité du code pour la première fois, veillez à activer les options de règle 9 et 10, afin que les options de dépannage soient disponibles pour les administrateurs du test. Une fois ces éléments validés et prêts à être déployés en entreprise, vous pouvez supprimer ces options. Pour savoir comment ajouter des options de règle, consultez la rubrique Règles des stratégies d’intégrité du code du présent document.

Remarque

La signature des stratégies d’intégrité du code constitue la dernière étape du déploiement de la fonction d’intégrité du code. Il est beaucoup plus difficile de supprimer une stratégie d’intégrité du code lorsqu’elle est signée. Avant de déployer une stratégie d’intégrité du code signée sur les ordinateurs clients déployés, veillez à tester son impact sur un sous-ensemble d’ordinateurs.

Pour pouvoir signer une stratégie d’intégrité du code via l’outil SignTool.exe, vous devez disposer des composants suivants :

l’outil SignTool.exe, qui se trouve dans le SDK Windows (pour Windows 7 ou plus) ;
le format binaire de la stratégie d’intégrité du code que vous avez généré via la rubrique Créer des stratégies d’intégrité du code sur des PC de référence, ou une autre stratégie d’intégrité du code créée par vos soins ;
un certificat de signature de code de l’autorité de certification interne, ou tout certificat de signature de code acheté.

En l’absence de certificat de ce type, consultez la rubrique Créer un certificat de signature de code Device Guard du présent document pour découvrir comment en créer un. Si vous utilisez un autre certificat ou une autre stratégie d’intégrité du code, veillez à mettre à jour les étapes suivantes en utilisant le certificat et les variables appropriés, afin que les commandes fonctionnent correctement. Pour signer la stratégie d’intégrité du code existante, copiez chacune des commandes suivantes dans une session Windows PowerShell avec élévation des privilèges :

Initialisez les variables qui seront utilisées :

$CIPolicyPath=$env:userprofile+"\Desktop\" $InitialCIPolicy=$CIPolicyPath+"InitialScan.xml" $CIPolicyBin=$CIPolicyPath+"DeviceGuardPolicy.bin"

Remarque

Cet exemple repose sur la stratégie d’intégrité du code créée via la rubrique Créer des stratégies d’intégrité du code sur des PC de référence du présent document. Si vous signez une autre stratégie, veillez à mettre à jour les variables $CIPolicyPath et $CIPolicyBin en indiquant les informations correctes.
Importez le certificat de signature de code au format .pfx. Importez le certificat de signature de code que vous allez utiliser pour signer la stratégie d’intégrité du code dans le magasin personnel de l’utilisateur effectuant la signature, sur l’ordinateur utilisé pour cette opération. Pour les besoins de cet exemple, vous allez utiliser le certificat créé via la rubrique Créer un certificat de signature du code Device Guard du présent document.
Exportez le certificat de signature de code au format .cer. Une fois le certificat de signature de code importé, exportez la version au format .cer sur votre Bureau. Cette version sera ajoutée à la stratégie, afin de pouvoir être mise à jour ultérieurement.
Accédez à votre Bureau, utilisé en tant que répertoire de travail :

cd $env:USERPROFILE\Desktop
Ajoutez un certificat de signataire mis à jour dans la stratégie d’intégrité du code :

Add-SignerRule -FilePath $InitialCIPolicy -CertificatePath <Path to exported .cer certificate> -Kernel -User –Update

Remarque

<Path to exported .cer certificate> doit correspondre au chemin d’accès complet du certificat exporté à l’étape 3.

Remarque

L’ajout de signataires mis à jour est essentiel pour permettre la modification ou la désactivation ultérieure de la stratégie. Pour en savoir plus sur la désactivation de stratégies d’intégrité du code, consultez la rubrique Désactiver des stratégies d’intégrité du code signées dans Windows du présent document.
Supprimez l’option de règle de stratégie non signée :

Set-RuleOption -Option 6 -FilePath $InitialCIPolicy -Delete
Convertissez la stratégie au format binaire :

ConvertFrom-CIPolicy $InitialCIPolicy $CIPolicyBin
Signez la stratégie d’intégrité du code à l’aide de l’outil SignTool.exe :

<Path to signtool.exe> sign -v /n "ContosoDGSigningCert" -p7 . -p7co 1.3.6.1.4.1.311.79.1 -fd sha256 $CIPolicyBin

Remarque

La variable <Path to signtool.exe> doit correspondre au chemin d’accès complet de l’outil SignTool.exe. La valeur ContosoDGSigningCert correspond au nom du sujet du certificat qui sera utilisé pour signer la stratégie d’intégrité du code. Vous devez importer ce certificat dans votre magasin de certificats personnels, sur l’ordinateur que vous utilisez pour signer la stratégie.
Validez le fichier signé. Lorsque vous avez terminé, les commandes doivent permettre la création d’un fichier de stratégie signé, appelé « DeviceGuardPolicy.bin.p7 », sur votre Bureau. Vous pouvez déployer ce fichier de la même manière qu’une stratégie appliquée ou non appliquée. Pour en savoir plus sur le déploiement de stratégies d’intégrité du code, consultez la rubrique Déployer et gérer des stratégies d’intégrité du code via une Stratégie de groupe du présent document.

Désactiver des stratégies d’intégrité du code non signées

Il peut arriver que l’administrateur souhaite désactiver une stratégie d’intégrité du code. Dans le cas des stratégies d’intégrité du code non signées, ce processus est simple. Selon le mode de déploiement de la stratégie d’intégrité du code, une stratégie non signée peut être désactivée de deux manières. Si une stratégie d’intégrité du code a été manuellement activée et copiée à l’emplacement du dossier CodeIntegrity, il vous suffit de supprimer le fichier et de redémarrer l’ordinateur. Les emplacements suivants peuvent inclure des stratégies d’intégrité du code en cours d’exécution :

<Partition du système EFI> \Microsoft\Boot\
<Volume_système d’exploitation>\Windows\System32\CodeIntegrity\

Si la stratégie d’intégrité du code a été déployée à l’aide de la Stratégie de groupe, l’objet de stratégie de groupe qui est active et déploie cette stratégie doit être défini sur la valeur Désactivé. Alors, la stratégie d’intégrité du code sera désactivée lors du prochain redémarrage de l’ordinateur.

Désactiver des stratégies d’intégrité du code signées dans Windows

Les stratégies signées protègent le système Windows contre toute manipulation d’administration et contre les programmes malveillants ayant usurpé un accès de niveau administrateur au système. De ce fait, les stratégies d’intégrité du code signées sont conçues pour être beaucoup plus difficiles à supprimer que les stratégies non signées. Elles se protègent implicitement contre la modification ou la suppression. Cela explique que les administrateurs aient plus de difficultés à les supprimer. Si la stratégie d’intégrité du code signée est activée et copiée manuellement dans le dossier CodeIntegrity, vous devez effectuer les étapes suivantes pour supprimer cette stratégie :

Remarque

À titre de référence, les stratégies d’intégrité du code signées doivent être remplacées et supprimées aux emplacements suivants :

<Partition du système EFI> \Microsoft\Boot\
<Volume_système d’exploitation>\Windows\System32\CodeIntegrity\

Remplacez la stratégie existante par une autre stratégie signée, pour laquelle l’option de règle 6 - Activé:Stratégie d’intégrité système non signée (par défaut) est activée.

Remarque

Pour être effective, cette stratégie doit être signée via un certificat préalablement ajouté dans la section UpdatePolicySigners de la stratégie signée d’origine que vous souhaitez remplacer.
Redémarrez de l’ordinateur client.
Vérifiez que la nouvelle stratégie signée existe bien sur l’ordinateur client.

Remarque

Si la stratégie signée qui contient l’option de règle 6 n’a pas été traitée sur le client, l’ajout d’une stratégie non signée peut provoquer l’échec du démarrage.
Supprimez la nouvelle règle.
Redémarrez de l’ordinateur client.

Si la stratégie d’intégrité du code signée a été déployée à l’aide de la Stratégie de groupe, vous devez effectuer les étapes suivantes :

Remplacez la stratégie existante de l’objet de stratégie de groupe par une autre stratégie signée, pour laquelle l’option de règle 6 - Activé:Stratégie d’intégrité système non signée (par défaut) est activée.

Remarque

Pour être effective, cette stratégie doit être signée via un certificat préalablement ajouté dans la section UpdatePolicySigners de la stratégie signée d’origine que vous souhaitez remplacer.
Redémarrez de l’ordinateur client.
Vérifiez que la nouvelle stratégie signée existe bien sur l’ordinateur client.

Remarque

Si la stratégie signée qui contient l’option de règle 6 n’a pas été traitée sur le client, l’ajout d’une stratégie non signée peut provoquer l’échec du démarrage.
Désactivez l’objet de stratégie de groupe.
Supprimez la nouvelle règle.
Redémarrez de l’ordinateur client.

Désactiver des stratégies d’intégrité du code signées dans le BIOS

Il peut arriver qu’une stratégie d’intégrité du code signée entraîne l’échec du démarrage du système. Dans la mesure où les stratégies d’intégrité du code appliquent les pilotes en mode noyau, il est important qu’elles soient intégralement testées sur chaque configuration logicielle et matérielle avant d’être mise en œuvre et signée. Les stratégies d’intégrité du code signées sont validées lors de la séquence préalable au démarrage, via la fonction Démarrage sécurisé. Lorsque vous désactivez la fonctionnalité Démarrage sécurisé dans le BIOS, puis supprimez le fichier des emplacements suivants sur le disque du système d’exploitation, le système est autorisé à démarrer dans Windows :

<Partition du système EFI> \Microsoft\Boot\
<Volume_système d’exploitation>\Windows\System32\CodeIntegrity\

Déployer et gérer des stratégies d’intégrité du code via une Stratégie de groupe

Les stratégies d’intégrité du code peuvent facilement être déployées et gérées via la Stratégie de groupe. Un modèle d’administration Device Guard sera disponible dans Windows Server 2016 ; il vous permettra de simplifier le déploiement de fonctionnalités de sécurité matérielles et de stratégies d’intégrité du code de Device Guard. La procédure suivante vous guide lors du déploiement d’une stratégie d’intégrité du code appelée DeviceGuardPolicy.bin sur l’unité d’organisation de test DG Enabled PCs, à l’aide d’un objet de stratégie de groupe appelé Test objet stratégie groupe Contoso.

Remarque

Cette procédure pas à pas nécessite la création préalable d’une stratégie d’intégrité du code. Vous devez en outre disposer d’un PC client doté de Windows 10, sur lequel le déploiement d’une Stratégie de groupe sera testé. Pour en savoir plus sur la création d’une stratégie d’intégrité du code, consultez la rubrique Créer des stratégies d’intégrité du code sur des PC de référence du présent document.

Remarque

Les stratégies d’intégrité du code signées peuvent entraîner une erreur de démarrage lorsqu’elles sont déployées. Microsoft vous recommande de tester les stratégies d’intégrité du code signées de manière approfondie et ce, sur chaque plate-forme matérielle, avant tout déploiement en entreprise.

Pour déployer et gérer des stratégies d’intégrité du code via une Stratégie de groupe, procédez comme suit :

Sur un contrôleur de domaine installé sur un ordinateur client hébergeant la fonction RSAT, ouvrez l’outil GPMC en exécutant le fichier GPMC.MSC, ou saisissez la chaîne « Gestion des stratégies de groupe » dans la fonction de recherche de Windows.
Créez un objet de stratégie de groupe, en cliquant avec le bouton droit de la souris sur l’unité d’organisation « PC activés DG », puis en cliquant sur Créer un objet GPO dans ce domaine, et le lier ici, comme indiqué dans la figure 24.

Remarque

Cette unité d’organisation est un simple exemple d’emplacement pour la création d’un lien avec l’objet de stratégie de groupe de test créé via cette rubrique. Vous pouvez utiliser le nom d’unité de votre choix. Par ailleurs, le filtrage des groupes de sécurité est une option à prendre en compte lorsque vous envisagez de partitionner les stratégies, en fonction de la méthode abordée dans la rubrique Approche planifiée du déploiement de la protection de l’intégrité du code d’entreprise du présent document.

Figure 24. Création d’un objet de stratégie de groupe
Nommez le nouvel objet de stratégie comme suit : Test objet stratégie groupe Contoso. Ce nom est indiqué pour les besoins de cet exemple ; vous pouvez choisir le nom que vous souhaitez.
Ouvrez l’Éditeur de gestion des stratégies de groupe. Ensuite, cliquez sur le nouvel objet de stratégie de groupe avec le bouton droit de la souris, puis cliquez sur Modifier.
Dans l’objet de stratégie de groupe sélectionné, accédez à l’emplacement suivant : Configuration ordinateur\Modèles d’administration\Système\Device Guard. Ensuite, cliquez avec le bouton droit de la souris sur Déployer la stratégie d’intégrité du code, puis cliquez sur Modifier.

Figure 25. Modification de la stratégie d’intégration du code
Dans la boîte de dialogue Déployer la stratégie d’intégrité du code, sélectionnez l’option Activé, puis indiquez le chemin d’accès du déploiement de la stratégie d’intégrité du code.

Dans ce paramètre de stratégie, vous spécifiez le chemin d’accès local de la stratégie sur l’ordinateur client, ou le chemin d’accès UNC (Universal Naming Convention) que les ordinateurs clients utiliseront pour récupérer la dernière version de la stratégie. Dans cet exemple, le fichier DeviceGuardPolicy.bin est copié sur l’ordinateur de test, active ce paramètre et utilise le chemin d’accès du fichier suivant : C:\Windows\System32\CodeIntegrity\DeviceGuardPolicy.bin, comme indiqué dans la figure 26.

Remarque

DeviceGuardPolicy.bin n’est pas un nom de stratégie requis ; il s’agit simplement du nom utilisé dans la rubrique Créer des stratégies d’intégrité du code sur des PC de référence du présent document, que nous avons réutilisé ici. En outre, ce fichier de stratégie ne doit pas nécessairement être copié sur tous les ordinateurs. Vous pouvez également copier les stratégies d’intégrité du code sur un partage de fichiers auquel les comptes d’ordinateur ont accès. Toute stratégie sélectionnée ici est convertie et se voit affecter le nom « SIPolicy.p7b » lorsqu’elle est déployée sur les différents ordinateurs clients.

Figure 26. Activation de la stratégie d’intégrité du code

Remarque

Vous avez peut-être remarqué que le paramètre d’objet de stratégie de groupe fait référence à un fichier .p7b, alors que cet exemple utilise un fichier .bin pour la stratégie. Tous les types de stratégie déployés (.bin, .p7b ou .p7) sont convertis et se voient affecter le nom « SIPolicy.p7b » lorsqu’ils sont placés sur les ordinateurs clients dotés de Windows 10. Rendez vos stratégies d’intégrité du code conviviales et autorisez le système à convertir les noms de stratégies à votre place, afin de vous assurer qu’elles sont aisément identifiables lorsqu’elles sont affichées dans un partage ou tout autre référentiel central.
Fermez l’Éditeur de gestion des stratégies de groupe et redémarrez l’ordinateur de test qui exécute Windows 10. Le redémarrage de l’ordinateur client met à jour la stratégie d’intégrité du code. Pour savoir comment soumettre des stratégies d’intégrité du code à un audit, consultez la rubrique Soumettre des stratégies d’intégrité du code à un audit du présent document.

Créer un certificat de signature de code Device Guard

Pour signer des fichiers catalogue ou des stratégies d’intégrité du code en interne, vous devez disposer d’un certificat de signature de code public ou d’une autorité de certification interne. Si vous avez acheté un certificat de signature de code, vous pouvez ignorer ces étapes et passer aux rubriques qui présentent les étapes nécessaires pour signer des fichiers catalogue et des stratégies d’intégrité du code. Si vous n’avez pas acheté de certificat, mais disposez d’une autorité de certification interne, procédez comme suit pour créer un certificat de signature de code :

Ouvrez le composant logiciel enfichable MMC (Microsoft Management Console) et sélectionnez votre autorité de certification émettrice.
Une fois connecté, cliquez avec le bouton droit de la souris sur Modèles de certificats, puis cliquez sur Gérer pour ouvrir la console des modèles de certification.

Figure 27. Gestion des modèles de certificat
Dans le volet de navigation, cliquez avec le bouton droit de la souris sur le certificat de signature de code, puis sélectionnez Dupliquer le modèle.
Sur l’onglet Compatibilité, désélectionnez la case à cocher Afficher les modifications résultantes. Choisissez Windows Server 2012 dans la liste Autorité de certification, puis choisissez Windows 8/Windows Server 2012 dans la liste Destinataire du certificat.
Sur l’onglet Général, remplissez les champs Nom complet du modèle et Nom du modèle. Cet exemple utilise le certificat de signature de catalogue DG.
Sur l’onglet Traitement de la demande, cochez la case Autoriser l’exportation de la clé privée.
Sur l’onglet Extensions, cochez la case Contraintes de base, puis cliquez sur Modifier.
Dans la boîte de dialogue Modifier les extensions de contraintes de base, cochez la case Activer cette extension, comme indiqué dans la figure 28.

Figure 28. Activation de contraintes sur le nouveau modèle
Si un gestionnaire de certificats est requis pour l’approbation des certificats émis, accédez à l’onglet Conditions d’émission et sélectionnez Approbation du gestionnaire de certificat de l’autorité de certification.
Sur l’onglet Nom du sujet, choisissez Fournir dans la demande.
Sur l’onglet Sécurité, vérifiez que le compte qui sera utilisé pour demander le certificat est autorisé à inscrire ce dernier.
Cliquez sur OK pour créer le modèle, puis fermez la console des modèles de certification.

Une fois le modèle de certificat créé, vous devez le publier dans le magasin de modèles publiés de l’autorité de certification. Pour ce faire, procédez comme suit :

Dans le composant logiciel enfichable MMC (Microsoft Management Console) de l’autorité de certification, cliquez avec le bouton droit de la souris sur Modèles de certificats, pointez sur Nouveau, puis cliquez sur Modèle de certificat à délivrer, comme indiqué dans la figure 29.

Une liste de modèles disponibles pour l’émission s’affiche, notamment le modèle que vous venez de créer.

Figure 29. Sélection du nouveau modèle de certificat à émettre
Sélectionnez le certificat de signature du catalogue DG, puis cliquez sur OK.

Le modèle pouvant désormais être émis, vous devez en demander un à l’ordinateur doté de Windows 10 que vous utilisez pour créer et signer des fichiers catalogues. Pour commencer, ouvrez la console MMC, puis procédez comme suit :

Dans la console MMC, accédez au menu Fichier, puis cliquez sur Ajouter/Supprimer un composant logiciel enfichable. Double-cliquez sur Certificats, puis sélectionnez Mon compte d’utilisateur.
Dans le composant logiciel enfichable Certificats, cliquez avec le bouton droit de la souris sur le dossier du magasin personnel, pointez sur Toutes les tâches, puis cliquez sur Demander un nouveau certificat.
Cliquez sur Suivant deux fois pour accéder à la liste de sélection du certificat.
Dans la liste Demander un certificat, sélectionnez le certificat de signature de code qui vient d’être créé, puis sélectionnez le texte en bleu qui indique que des informations supplémentaires sont requises, comme indiqué dans la figure 30.

Figure 30. Obtention d’informations supplémentaires pour le certificat de signature de code
Accédez à la boîte de dialogue Propriétés du certificat, puis, pour Type, sélectionnez Nom commun. Dans le champ Valeur, sélectionnez ContosoDGSigningCert, puis cliquez sur Ajouter. Une fois l’élément ajouté, cliquez sur OK.
Inscrivez-le, puis terminez la procédure.

Remarque

Si un gestionnaire de certificats est requis pour l’approbation des certificats émis et si vous avez demandé l’approbation de la direction sur le modèle, la demande doit être approuvée dans l’autorité de certification avant toute émission vers le client.

Ce certificat doit être installé dans le magasin personnel de l’utilisateur, sur l’ordinateur qui effectuera la signature des fichiers catalogues et des stratégies d’intégrité du code. Si la signature doit être effectuée sur l’ordinateur depuis lequel vous avez demandé le certificat, aucune exportation du certificat vers un fichier .pfx n’est requise, car il existe déjà dans votre magasin personnel. Si vous effectuez la signature depuis un autre ordinateur, vous devez exporter le certificat au format .pfx, avec les clés et propriétés requises. Pour ce faire, procédez comme suit :

Cliquez avec le bouton droit de la souris sur le certificat, pointez sur Toutes les tâches, puis cliquez sur Exporter.
Cliquez sur Suivant, puis sélectionnez Oui, exporter la clé privée.
Choisissez les paramètres par défaut, puis sélectionnez Exporter toutes les propriétés étendues.
Définissez un mot de passe, choisissez un chemin d’exportation, puis sélectionnez le nom de fichier DGCatSigningCert.pfx.

Une fois le certificat exporté, importez-le dans le magasin personnel de l’utilisateur qui procédera à la signature des fichiers catalogues ou stratégies d’intégrité du code, sur l’ordinateur qui effectuera cette opération.