Contrôler l’intégrité des appareils Windows

• S’applique à:

  ✅ Windows 11, ✅ Windows 10

Cet article détaille une solution de bout en bout qui vous aide à protéger les ressources à valeur élevée en appliquant, en contrôlant et en signalant l’intégrité des appareils Windows.

Introduction

Pour les scénarios BYOD (Bring Your Own Device), les utilisateurs apportent des appareils disponibles dans le commerce pour accéder à la fois aux ressources professionnelles et à leurs données personnelles. Les utilisateurs souhaitent utiliser l’appareil de leur choix pour accéder aux applications, aux données et aux ressources de l’organisation, non seulement à partir du réseau interne, mais aussi de n’importe où. Ce phénomène est également connu sous le nom de consumérisation de l’informatique.

Les utilisateurs souhaitent bénéficier d’une expérience de productivité optimale lors de l’accès aux applications d’entreprise et de l’utilisation des données de l’organisation à partir de leurs appareils. Cela signifie qu’ils ne tolèrent pas qu’on leur demande d’entrer leurs informations d’identification professionnelles chaque fois qu’ils accèdent à une application ou à un serveur de fichiers. Du point de vue de la sécurité, cela signifie également que les utilisateurs manipulent des informations d’identification d’entreprise et des données d’entreprise sur des appareils non gérés.

Avec l’utilisation accrue de BYOD, il y aura plus de systèmes non managés et potentiellement non sains accédant aux services d’entreprise, aux ressources internes et aux applications cloud.

Même les appareils gérés peuvent être compromis et devenir dangereux. Les organisations doivent détecter quand la sécurité a été violée et réagir le plus tôt possible afin de protéger les ressources de grande valeur.

À mesure que Microsoft avance, les investissements en matière de sécurité sont de plus en plus axés sur les défenses préventives de sécurité, ainsi que sur les fonctionnalités de détection et de réponse.

Windows est un composant important d’une solution de sécurité de bout en bout qui se concentre non seulement sur l’implémentation de défenses préventives de sécurité, mais ajoute des fonctionnalités d’attestation d’intégrité des appareils à la stratégie de sécurité globale.

Description d’une solution de sécurité de bout en bout robuste

Le paysage des menaces informatiques d’aujourd’hui augmente à une vitesse jamais rencontrée auparavant. La sophistication des attaques criminelles augmente, et il ne fait aucun doute que les programmes malveillants ciblent désormais les consommateurs et les professionnels de tous les secteurs.

Au cours des dernières années, une catégorie particulière de menaces est devenue prédominante : les menaces persistantes avancées (APT). Le terme APT est couramment utilisé pour décrire toute attaque qui semble cibler des organisations individuelles de manière continue. En fait, ce type d’attaque implique généralement des adversaires déterminés qui peuvent utiliser toutes les méthodes ou techniques nécessaires.

Avec les phénomènes BYOD, un appareil mal entretenu représente une cible de choix. Pour un attaquant, il s’agit d’un moyen simple de violer le périmètre du réseau de sécurité, d’accéder à des ressources de grande valeur, puis de voler des ressources de grande valeur.

Les attaquants ciblent des individus, non pas spécifiquement en raison de qui ils sont, mais en raison de la personne pour laquelle ils travaillent. Un appareil infecté introduit un programme malveillant dans une organisation, même si l’organisation a renforcé le périmètre des réseaux ou a investi dans sa posture défensive. Une stratégie défensive n’est pas suffisante contre ces menaces.

Une approche différente

Plutôt que l’accent traditionnel sur la prévention des compromissions, une stratégie de sécurité efficace suppose que les adversaires déterminés vont avec succès violer toutes les défenses. Cela signifie qu’il est nécessaire de passer des contrôles de sécurité préventifs à la détection et à la réponse aux problèmes de sécurité. La mise en œuvre de la stratégie de gestion des risques équilibre donc les investissements dans la prévention, la détection et la réponse.

Étant donné que les appareils mobiles sont de plus en plus utilisés pour accéder aux informations d’entreprise, il est nécessaire d’évaluer la sécurité ou l’intégrité des appareils. Cette section explique comment provisionner l’évaluation de l’intégrité des appareils de telle sorte que les ressources de grande valeur puissent être protégées contre les appareils défectueux.

Les appareils utilisés pour accéder aux ressources d’entreprise doivent être approuvés. Une approche de sécurité de bout en bout efficace permet d’évaluer l’intégrité des appareils et d’utiliser l’état de sécurité actuel lors de l’octroi de l’accès à une ressource de grande valeur.

Une conception robuste doit établir l’identité de l’utilisateur, renforcer la méthode d’authentification si nécessaire et apprendre un comportement similaire à l’emplacement réseau à partir duquel l’utilisateur se connecte régulièrement. En outre, une approche moderne doit être en mesure de publier du contenu sensible uniquement si les appareils utilisateur sont déterminés comme étant sains et sécurisés.

La figure suivante montre une solution conçue pour évaluer l’intégrité des appareils à partir du cloud. L’appareil authentifie l’utilisateur via une connexion à un fournisseur d’identité dans le cloud. Si la ressource gérée contient des informations hautement confidentielles, le moteur d’accès conditionnel du fournisseur d’identité peut choisir de vérifier la conformité de sécurité de l’appareil mobile avant que l’accès ne soit accordé. L’appareil de l’utilisateur est en mesure de prouver son état d’intégrité qui peut être envoyé à tout moment ou lorsque la gestion des appareils mobiles (GPM) le demande.

Les appareils Windows peuvent être protégés contre les rootkits et les bootkits de bas niveau à l’aide de technologies matérielles de bas niveau telles que le démarrage sécurisé UEFI (Unified Extensible Firmware Interface).

Le démarrage sécurisé est un processus de validation de microprogramme qui permet d’empêcher les attaques rootkit ; il fait partie de la spécification UEFI. L’objectif d’UEFI est de définir un moyen standard pour le système d’exploitation de communiquer avec le matériel moderne, qui peut fonctionner plus rapidement et avec des fonctions d’entrée/sortie (E/S) plus efficaces que les systèmes BIOS plus anciens, pilotés par l’interruption logicielle.

Un module d’attestation d’intégrité de l’appareil peut communiquer des données de démarrage mesurées protégées par un module de plateforme sécurisée (TPM) à un service distant. Une fois l’appareil démarré, les données de mesure du processus de démarrage sont envoyées à un service cloud approuvé (service d’attestation d’intégrité) à l’aide d’un canal de communication plus sécurisé et inviolable.

Le service d’attestation d’intégrité à distance effectue une série de vérifications sur les mesures. Il valide les points de données liés à la sécurité, notamment l’état de démarrage (démarrage sécurisé, mode débogage, etc.) et l’état des composants qui gèrent la sécurité (BitLocker, Device Guard, etc.). Il transmet ensuite l’état d’intégrité de l’appareil en envoyant un objet blob chiffré d’intégrité à l’appareil.

Une solution GPM applique généralement des stratégies de configuration et déploie des logiciels sur les appareils. GPM définit la base de référence de sécurité et connaît le niveau de conformité de l’appareil avec des vérifications régulières pour voir quels logiciels sont installés et quelle configuration est appliquée, et déterminer l’état d’intégrité de l’appareil.

Une solution MDM demande à l’appareil d’envoyer des informations d’intégrité de l’appareil et de transférer l’objet blob chiffré d’intégrité au service d’attestation d’intégrité à distance. Le service d’attestation d’intégrité à distance vérifie les données d’intégrité de l’appareil, vérifie que la gestion des appareils mobiles communique avec le même appareil, puis émet un rapport d’intégrité de l’appareil à la solution MDM.

Une solution GPM évalue les assertions d’intégrité et, en fonction des règles d’intégrité appartenant à l’organisation, peut décider si l’appareil est sain. Si l’appareil est sain et conforme, GPM transmet ces informations au fournisseur d’identité afin que la stratégie de contrôle d’accès de l’organisation puisse être appelée pour accorder l’accès.

L’accès au contenu est ensuite autorisé au niveau de confiance approprié, quel que soit l’état d’intégrité et les autres éléments conditionnels indiqués.

En fonction des exigences et de la sensibilité de la ressource gérée, l’état d’intégrité de l’appareil peut être combiné avec les informations d’identité de l’utilisateur lors du traitement d’une demande d’accès. L’accès au contenu est ensuite autorisé au niveau de confiance approprié. Le moteur d’accès conditionnel peut être structuré pour permettre davantage de vérification en fonction de la sensibilité de la ressource managée. Par exemple, si l’accès à des données de grande valeur est demandé, une authentification de sécurité supplémentaire peut être nécessaire en demandant à l’utilisateur de répondre à un appel téléphonique avant que l’accès ne soit accordé.

Investissements de Microsoft en matière de sécurité dans Windows

Dans Windows, il existe trois piliers des investissements :

• Sécuriser les identités. Microsoft fait partie de l’alliance FIDO qui vise à fournir une méthode d’authentification sécurisée interopérable en s’éloignant de l’utilisation des mots de passe pour l’authentification, à la fois sur le système local et pour les services tels que les ressources locales et les ressources cloud.
• Protection des informations. Microsoft effectue des investissements pour permettre aux organisations d’avoir un meilleur contrôle sur les personnes ayant accès aux données importantes et sur ce qu’elles peuvent faire avec ces données. Avec Windows, les organisations peuvent tirer parti de stratégies qui spécifient quelles applications sont considérées comme des applications d’entreprise et peuvent être approuvées pour accéder aux données sécurisées.
• Résistance aux menaces. Microsoft aide les organisations à mieux sécuriser les ressources d’entreprise contre les menaces de programmes malveillants et d’attaques en utilisant des défenses de sécurité reposant sur du matériel.

Protéger, contrôler et créer des rapports sur l’état de sécurité des appareils Windows

Cette section est une vue d’ensemble qui décrit différentes parties de la solution de sécurité de bout en bout qui permet de protéger les ressources et les informations de grande valeur contre les attaquants et les programmes malveillants.

Nombre	Partie de la solution	Description
1	Appareil Windows	La première fois qu’un appareil Windows est sous tension, l’écran OOBE (Out-of-Box Experience) s’affiche. Pendant l’installation, l’appareil peut être automatiquement inscrit dans l’ID Microsoft Entra et inscrit dans mdm. Un appareil Windows avec TPM peut signaler l’état d’intégrité à tout moment à l’aide du service d’attestation d’intégrité disponible avec toutes les éditions prises en charge de Windows.
2	Fournisseur d’identité	L’ID Microsoft Entra contient les utilisateurs, les appareils inscrits et l’application inscrite du locataire de l’organisation. Un appareil appartient toujours à un utilisateur et un utilisateur peut avoir plusieurs appareils. Un appareil est représenté sous la forme d’un objet avec différents attributs, tels que l’état de conformité de l’appareil. Un GPM approuvé peut mettre à jour l’état de conformité. L’ID Microsoft Entra est plus qu’un dépôt. Microsoft Entra ID est en mesure d’authentifier les utilisateurs et les appareils et peut également autoriser l’accès aux ressources managées. Microsoft Entra ID dispose d’un moteur de contrôle d’accès conditionnel qui utilise l’identité de l’utilisateur, l’emplacement de l’appareil et également l’état de conformité de l’appareil lors de la prise d’une décision d’accès approuvé.
3	Gestion des périphériques mobiles	Windows dispose d’une prise en charge GPM qui permet de gérer l’appareil de manière prête à l’emploi sans déployer d’agent. GPM peut être Microsoft Intune ou toute solution GPM tierce compatible avec Windows.
4	Attestation d’intégrité à distance	Le service d’attestation d’intégrité est un service cloud approuvé géré par Microsoft qui effectue une série de vérifications d’intégrité et signale à GPM les fonctionnalités de sécurité Windows activées sur l’appareil. La vérification de sécurité inclut l’état de démarrage (WinPE, mode sans échec, modes débogage/test) et les composants qui gèrent la sécurité et l’intégrité des opérations d’exécution (BitLocker, Device Guard).
5	Ressource gérée par l’entreprise	La ressource gérée par l’entreprise est la ressource à protéger. Par exemple, la ressource peut être Office 365, d’autres applications cloud, des ressources web locales publiées par l’ID Microsoft Entra ou même un accès VPN.

La combinaison d’appareils Windows, de fournisseur d’identité, de GPM et d’attestation d’intégrité à distance crée une solution robuste de bout en bout qui fournit la validation de l’intégrité et la conformité des appareils qui accèdent à des ressources de grande valeur.

Protéger les appareils et les informations d’identification d’entreprise contre les menaces

Cette section décrit ce que Windows offre en termes de défenses de sécurité et les contrôles qui peuvent être mesurés et signalés.

Défenses de sécurité basées sur le matériel Windows

Les formes les plus agressives de programmes malveillants essaient de s’insérer dans le processus de démarrage le plus tôt possible afin qu’ils puissent prendre le contrôle du système d’exploitation tôt et empêcher les mécanismes de protection et les logiciels anti-programme malveillant de fonctionner. Ce type de code malveillant est souvent appelé rootkit ou bootkit. La meilleure façon d’éviter d’avoir à faire face à des programmes malveillants de bas niveau consiste à sécuriser le processus de démarrage afin que l’appareil soit protégé dès le début. Windows prend en charge plusieurs couches de protection de démarrage. Certaines de ces fonctionnalités sont disponibles uniquement si des types spécifiques de matériel sont installés. Pour plus d’informations, consultez la section Configuration matérielle requise .

Windows prend en charge les fonctionnalités permettant d’empêcher le chargement de programmes malveillants de bas niveau sophistiqués tels que les rootkits et les bootkits pendant le processus de démarrage :

• Module de plateforme sécurisée. Un module de plateforme sécurisée (TPM) est un composant matériel qui fournit des fonctionnalités de sécurité uniques.

  Windows utilise les caractéristiques de sécurité d’un module TPM pour mesurer la séquence d’intégrité de démarrage (et, sur cette base, déverrouiller automatiquement les lecteurs protégés par BitLocker), pour protéger les informations d’identification ou pour l’attestation d’intégrité.

  Un module de plateforme sécurisée implémente des contrôles qui répondent à la spécification décrite par le Groupe de calcul approuvé (TCG). Au moment de la rédaction de cet article, il existe deux versions de la spécification TPM produites par TCG qui ne sont pas compatibles l’une avec l’autre :

  • La première spécification TPM, version 1.2, a été publiée en février 2005 par le TCG et normalisée selon la norme ISO/IEC 11889.
  • La dernière spécification TPM, appelée TPM 2.0, a été publiée en avril 2014 et a été approuvée par le Comité technique mixte ISO/IEC (JTC) comme ISO/IEC 11889:2015.

  Windows utilise le module de plateforme sécurisée pour les calculs de chiffrement dans le cadre de l’attestation d’intégrité et pour protéger les clés pour BitLocker, Windows Hello, les cartes à puce virtuelles et d’autres certificats à clé publique. Pour plus d’informations, consultez Configuration requise du module de plateforme sécurisée (TPM) dans Windows.

  Windows reconnaît les spécifications TPM des versions 1.2 et 2.0 produites par le TCG. Pour les fonctionnalités de sécurité les plus récentes et modernes, Windows prend uniquement en charge TPM 2.0.

  TPM 2.0 fournit une révision majeure des fonctionnalités par rapport à TPM 1.2 :

  • Mettre à jour la puissance du chiffrement pour répondre aux besoins de sécurité modernes

    • Prise en charge de SHA-256 pour les pcrs
    • Prise en charge de la commande HMAC

  • Flexibilité des algorithmes de chiffrement pour prendre en charge les besoins du gouvernement

    • TPM 1.2 est fortement limité en termes d’algorithmes qu’il peut prendre en charge
    • TPM 2.0 peut prendre en charge des algorithmes arbitraires avec des mises à jour mineures des documents de spécification TCG

  • Cohérence entre les implémentations

    • La spécification TPM 1.2 offre aux fournisseurs une grande latitude lors du choix des détails de l’implémentation
    • TPM 2.0 normalise une grande partie de ce comportement

• Démarrage sécurisé. Les appareils avec microprogramme UEFI peuvent être configurés pour charger uniquement des chargeurs de démarrage de système d’exploitation approuvés. Le démarrage sécurisé ne nécessite pas de module TPM.

  La protection la plus basique est la fonctionnalité de démarrage sécurisé, qui est une partie standard de l’architecture UEFI 2.2+. Sur un PC doté d’un BIOS conventionnel, toute personne qui peut prendre le contrôle du processus de démarrage peut démarrer à l’aide d’un autre chargeur de système d’exploitation et éventuellement accéder aux ressources système. Lorsque le démarrage sécurisé est activé, vous pouvez démarrer uniquement à l’aide d’un chargeur de système d’exploitation signé à l’aide d’un certificat stocké dans la base de données de démarrage sécurisé UEFI. Naturellement, le certificat Microsoft utilisé pour signer numériquement les chargeurs de système d’exploitation Windows se trouve dans ce magasin, ce qui permet à UEFI de valider le certificat dans le cadre de sa stratégie de sécurité. Le démarrage sécurisé doit être activé par défaut sur tous les ordinateurs certifiés pour Windows dans le cadre du programme de compatibilité matérielle Windows.

  Le démarrage sécurisé est une fonctionnalité basée sur un microprogramme UEFI, qui permet de signer et de vérifier les fichiers de démarrage critiques et les pilotes au moment du démarrage. Le démarrage sécurisé vérifie les valeurs de signature du Gestionnaire de démarrage Windows, du magasin BCD, du fichier chargeur du système d’exploitation Windows et d’autres DLL critiques de démarrage au moment du démarrage avant que le système ne soit autorisé à démarrer entièrement dans un système d’exploitation utilisable à l’aide de stratégies définies par l’OEM au moment de la génération. Le démarrage sécurisé empêche de nombreux types de rootkit de démarrage, de programmes malveillants et d’autres attaques liées à la sécurité contre la plateforme Windows. Le démarrage sécurisé protège le processus de démarrage du système d’exploitation, qu’il s’agisse d’un démarrage à partir d’un disque dur local, d’une clé USB, d’un PXE ou d’un DVD, ou dans l’environnement de récupération Windows (RE) complet. Le démarrage sécurisé protège l’environnement de démarrage d’une installation Windows en vérifiant les signatures des composants de démarrage critiques pour confirmer qu’une activité malveillante ne les a pas compromis. La protection du démarrage sécurisé prend fin après le chargement du fichier noyau Windows (ntoskrnl.exe).

  Remarque

  Le démarrage sécurisé protège la plateforme jusqu’au chargement du noyau Windows. Ensuite, les protections comme ELAM prennent le relais.

• Stratégie de configuration de démarrage sécurisé. Étend la fonctionnalité de démarrage sécurisé à la configuration Windows critique.

  Parmi les exemples d’informations de configuration protégées, citons la protection de désactiver le bit d’exécution (option NX) ou la garantie que la stratégie de signature de test (intégrité du code) ne peut pas être activée. Cette action de protection garantit que les fichiers binaires et la configuration de l’ordinateur peuvent être approuvés une fois le processus de démarrage terminé. La stratégie de configuration de démarrage sécurisé effectue cette action de protection avec la stratégie UEFI. Ces signatures pour ces stratégies sont signées de la même façon que les fichiers binaires du système d’exploitation sont signés pour être utilisés avec le démarrage sécurisé.

  La stratégie de configuration de démarrage sécurisé doit être signée par une clé privée qui correspond à l’une des clés publiques stockées dans la liste Clé d’échange de clés (KEK). L’autorité de certification Microsoft sera présente dans la liste kek de tous les systèmes de démarrage sécurisé certifiés Windows. Par défaut, une stratégie signée par microsoft KEK doit être exécutée sur tous les systèmes de démarrage sécurisé. BootMgr doit vérifier la signature par rapport à la liste kek avant d’appliquer une stratégie signée. Avec Windows, la stratégie de configuration de démarrage sécurisé par défaut est incorporée dans bootmgr.

  Le chargeur de démarrage vérifie la signature numérique du noyau Windows avant de le charger. Le noyau Windows vérifie à son tour tous les autres composants du processus de démarrage de Windows, y compris les pilotes de démarrage, les fichiers de démarrage et le composant ELAM. Cette étape est importante et protège le reste du processus de démarrage en vérifiant que tous les composants de démarrage Windows sont intègres et peuvent être approuvés.

• Logiciel anti-programme malveillant à lancement anticipé. L'ELAM teste tous les pilotes avant leur chargement et empêche le chargement des pilotes non approuvés.

  Les applications anti-programme malveillant traditionnelles ne démarrent qu’après le chargement des pilotes de démarrage, ce qui donne à un rootkit déguisé en pilote la possibilité de fonctionner. ELAM est un mécanisme Windows introduit dans une version précédente de Windows qui permet aux logiciels anti-programme malveillant de s’exécuter au début de la séquence de démarrage. Ainsi, le composant anti-programme malveillant est le premier composant tiers à exécuter et à contrôler l’initialisation d’autres pilotes de démarrage jusqu’à ce que le système d’exploitation Windows soit opérationnel. Lorsque le système est démarré avec un environnement d’exécution complet (accès réseau, stockage, etc.), un logiciel anti-programme malveillant complet est chargé.

  ELAM peut charger un pilote anti-programme malveillant Microsoft ou non Microsoft avant tous les pilotes et applications de démarrage non-Microsoft, ce qui permet de poursuivre la chaîne de confiance établie par le démarrage sécurisé et le démarrage approuvé. Étant donné que le système d’exploitation n’a pas encore démarré et que Windows doit démarrer le plus rapidement possible, ELAM a une tâche simple : examiner chaque pilote de démarrage et déterminer s’il figure dans la liste des pilotes approuvés. S’il n’est pas approuvé, Windows ne le charge pas.

  Remarque

  Windows Defender, le logiciel anti-programme malveillant de Microsoft inclus par défaut dans Windows, prend en charge ELAM ; il peut être remplacé par une solution tierce compatible anti-programme malveillant. Le nom du pilote Windows Defender ELAM est WdBoot.sys. Windows Defender utilise son pilote ELAM pour restaurer toutes les modifications malveillantes apportées au pilote Windows Defender lors du prochain redémarrage. Cela empêche les programmes malveillants en mode noyau d’apporter des modifications durables au pilote de mini-filtre de Windows Defender avant l’arrêt ou le redémarrage.

  Le pilote signé ELAM est chargé avant tout autre pilote ou application tiers, ce qui permet au logiciel anti-programme malveillant de détecter et de bloquer toute tentative de falsification du processus de démarrage en essayant de charger du code non signé ou non approuvé.

  Le pilote ELAM est un petit pilote avec une petite base de données de stratégie qui a une portée étroite, axée sur les pilotes chargés tôt au lancement du système. La base de données de stratégie est stockée dans une ruche de Registre qui est également mesurée sur le TPM, pour enregistrer les paramètres opérationnels du pilote ELAM. Un pilote ELAM doit être signé par Microsoft et le certificat associé doit contenir la référence EKU complémentaire (1.3.6.1.4.1.311.61.4.1).

• Sécurité basée sur la virtualisation (Hyper-V + noyau sécurisé). La sécurité basée sur la virtualisation est une nouvelle limite de sécurité appliquée qui vous permet de protéger les parties critiques de Windows.

  La sécurité basée sur la virtualisation isole le code sensible comme l’intégrité du code en mode noyau ou les informations d’identification de domaine d’entreprise sensibles du reste du système d’exploitation Windows. Pour plus d’informations, consultez la section Sécurité basée sur la virtualisation .

• Intégrité du code protégée par l’hyperviseur (HVCI). L’intégrité du code protégée par l’hyperviseur est une fonctionnalité de Device Guard qui garantit que seuls les pilotes, les exécutables et les DLL conformes à la stratégie d’intégrité du code Device Guard sont autorisés à s’exécuter.

  Lorsqu’il est activé et configuré, Windows peut démarrer les services de sécurité basés sur la virtualisation Hyper-V. HVCI permet de protéger le noyau système (noyau), les pilotes privilégiés et les défenses système, comme les solutions anti-programme malveillant, en empêchant les programmes malveillants de s’exécuter tôt dans le processus de démarrage ou après le démarrage.

  HVCI utilise la sécurité basée sur la virtualisation pour isoler l’intégrité du code. La seule façon dont la mémoire du noyau peut devenir exécutable consiste à effectuer une vérification de l’intégrité du code. Cette dépendance vis-à-vis de la vérification signifie que les pages mémoire du noyau ne peuvent jamais être accessibles en écriture et que le code exécutable (W+X) et le code exécutable ne peuvent pas être directement modifiés.

  Remarque

  Les appareils Device Guard qui exécutent l’intégrité du code en mode noyau avec une sécurité basée sur la virtualisation doivent avoir des pilotes compatibles. Pour plus d’informations, consultez le billet de blog Compatibilité des pilotes avec Device Guard dans Windows .

  La fonctionnalité d’intégrité du code Device Guard permet aux organisations de contrôler quel code est approuvé pour s’exécuter dans le noyau Windows et quelles applications sont approuvées pour s’exécuter en mode utilisateur. Il est configurable à l’aide d’une stratégie. La stratégie d’intégrité du code Device Guard est un fichier binaire que Microsoft vous recommande de signer. La signature de la stratégie d’intégrité du code facilite la protection contre un utilisateur malveillant disposant de privilèges d’administrateur qui tente de modifier ou de supprimer la stratégie d’intégrité du code actuelle.

• Credential Guard. Credential Guard protège les informations d’identification d’entreprise avec l’isolation des informations d’identification basées sur le matériel.

  Dans Windows, Credential Guard vise à protéger les informations d’identification d’entreprise de domaine contre le vol et la réutilisation par des programmes malveillants. Avec Credential Guard, Windows a implémenté une modification architecturale qui empêche fondamentalement les formes actuelles de l’attaque pass-the-hash (PtH).

  Cet état sans attaque est accompli en utilisant Hyper-V et la nouvelle fonctionnalité de sécurité basée sur la virtualisation pour créer un conteneur protégé où le code et les secrets approuvés sont isolés du noyau Windows. Cette réussite signifie que même si le noyau Windows est compromis, un attaquant n’a aucun moyen de lire et d’extraire les données nécessaires pour lancer une attaque PtH. Credential Guard empêche cet accès non autorisé, car la mémoire dans laquelle les secrets sont stockés n’est plus accessible à partir du système d’exploitation standard, même en mode noyau : l’hyperviseur contrôle qui peut accéder à la mémoire.

• Attestation d’intégrité. Le microprogramme de l’appareil enregistre le processus de démarrage, et Windows peut l’envoyer à un serveur approuvé qui peut vérifier et évaluer l’intégrité de l’appareil.

  Windows prend des mesures du microprogramme UEFI et chacun des composants Windows et anti-programme malveillant est effectué au fur et à mesure qu’ils se chargent pendant le processus de démarrage. En outre, ils sont pris et mesurés séquentiellement, pas tous à la fois. Une fois ces mesures terminées, leurs valeurs sont signées numériquement et stockées en toute sécurité dans le module de plateforme sécurisée et ne peuvent pas être modifiées, sauf si le système est réinitialisé.

  Pour plus d’informations, consultez Démarrage sécurisé et Démarrage mesuré : renforcement des composants de démarrage précoce contre les programmes malveillants.

  Lors de chaque démarrage suivant, les mêmes composants sont mesurés, ce qui permet de comparer les mesures par rapport à une base de référence attendue. Pour plus de sécurité, les valeurs mesurées par le module TPM peuvent être signées et transmises à un serveur distant, qui peut ensuite effectuer la comparaison. Ce processus, appelé attestation d’intégrité de l’appareil distant, permet au serveur de vérifier l’état d’intégrité de l’appareil Windows.

  Bien que le démarrage sécurisé soit une forme proactive de protection, l’attestation d’intégrité est une forme réactive de protection de démarrage. L’attestation d’intégrité est fournie désactivée dans Windows et est activée par un logiciel anti-programme malveillant ou un fournisseur GPM. Contrairement au démarrage sécurisé, l’attestation d’intégrité n’arrête pas le processus de démarrage et n’entre pas dans la correction lorsqu’une mesure ne fonctionne pas. Mais avec le contrôle d’accès conditionnel, l’attestation d’intégrité permet d’empêcher l’accès aux ressources de grande valeur.

Sécurité basée sur la virtualisation

La sécurité basée sur la virtualisation fournit une nouvelle limite d’approbation pour Windows et utilise la technologie d’hyperviseur Hyper-V pour améliorer la sécurité de la plateforme. La sécurité basée sur la virtualisation fournit un environnement d’exécution sécurisé pour exécuter un code windows approuvé spécifique (trustlet) et protéger les données sensibles.

La sécurité basée sur la virtualisation permet de se protéger contre un noyau compromis ou un utilisateur malveillant disposant de privilèges d’administrateur. La sécurité basée sur la virtualisation n’essaie pas de se protéger contre un attaquant physique.

Les services Windows suivants sont protégés par la sécurité basée sur la virtualisation :

• Credential Guard (isolation des informations d’identification LSA) : empêche les attaques pass-the-hash et le vol d’informations d’identification d’entreprise qui se produisent en lisant et en vidant le contenu de la mémoire lsass
• Device Guard (Intégrité du code Hyper-V) : Device Guard utilise la nouvelle sécurité basée sur la virtualisation dans Windows pour isoler le service d’intégrité du code du noyau Windows lui-même, ce qui permet au service d’utiliser des signatures définies par votre stratégie contrôlée par l’entreprise pour vous aider à déterminer ce qui est fiable. En effet, le service d’intégrité du code s’exécute avec le noyau dans un conteneur protégé par l’hyperviseur Windows.
• Autres services isolés : par exemple, sur Windows Server 2016, il existe la fonctionnalité vTPM qui vous permet d’avoir des machines virtuelles chiffrées sur des serveurs.

Remarque

La sécurité basée sur la virtualisation est disponible uniquement avec l’édition Enterprise. La sécurité basée sur la virtualisation nécessite des appareils avec UEFI (2.3.1 ou version ultérieure) avec démarrage sécurisé activé, processeur x64 avec extensions de virtualisation et SLAT activés. IOMMU, TPM 2.0. et la prise en charge de la mémoire sécurisée remplacée sont facultatives, mais recommandées.

Le schéma ci-dessous est une vue d’ensemble de Windows avec sécurité basée sur la virtualisation.

Credential Guard

Dans Windows, quand Credential Guard est activé, le service de sous-système de l’autorité de sécurité locale (lsass.exe) exécute un code sensible en mode utilisateur isolé pour protéger les données contre les programmes malveillants qui peuvent s’exécuter en mode utilisateur normal. Cette exécution de code permet de s’assurer que les données protégées ne sont pas volées et réutilisées sur des machines distantes, ce qui atténue de nombreuses attaques de type PtH.

Credential Guard permet de protéger les informations d’identification en les chiffrant avec une clé par démarrage ou persistante :

• La clé par démarrage est utilisée pour toutes les informations d’identification en mémoire qui ne nécessitent pas de persistance. Une clé de session TGT (Ticket-Granting Ticket) est un exemple de ces informations d’identification. Cette clé est négociée avec un centre de distribution de clés (KDC) chaque fois que l’authentification se produit et est protégée par une clé par démarrage.
• La clé persistante, ou un dérivé, est utilisée pour protéger les éléments stockés et rechargés après un redémarrage. Cette protection est destinée au stockage à long terme et doit être protégée avec une clé cohérente. Credential Guard est activé par une clé de Registre, puis activé à l’aide d’une variable UEFI. Cette activation est effectuée pour vous protéger contre les modifications à distance de la configuration. L’utilisation d’une variable UEFI implique qu’un accès physique est nécessaire pour modifier la configuration. Lorsque lsass.exe détecte que l’isolation des informations d’identification est activée, il génère LsaIso.exe en tant que processus isolé, ce qui garantit qu’il s’exécute en mode utilisateur isolé. Le démarrage de LsaIso.exe est effectué avant l’initialisation d’un fournisseur de support de sécurité, ce qui garantit que les routines de prise en charge du mode sécurisé sont prêtes avant le début de toute authentification.

Device Guard

Device Guard est une fonctionnalité de Windows Entreprise qui permet aux organisations de verrouiller un appareil pour l’empêcher d’exécuter des logiciels non approuvés. Dans cette configuration, les seules applications autorisées à s’exécuter sont les applications approuvées par l’organisation.

La décision de confiance d’exécuter du code est effectuée à l’aide de l’intégrité du code Hyper-V, qui s’exécute dans la sécurité basée sur la virtualisation, un conteneur protégé par Hyper-V qui s’exécute avec Windows standard.

L’intégrité du code Hyper-V est une fonctionnalité qui valide l’intégrité d’un pilote ou d’un fichier système chaque fois qu’il est chargé en mémoire. L’intégrité du code détecte si un pilote ou un fichier système non signé est chargé dans le noyau, ou si un fichier système a été modifié par un logiciel malveillant exécuté par un compte d’utilisateur disposant de privilèges d’administrateur. Sur les versions x64 de Windows, les pilotes en mode noyau doivent être signés numériquement.

Remarque

Indépendamment de l’activation de la stratégie Device Guard, les pilotes Windows doivent être signés par Microsoft, et plus précisément par le portail WHQL (Windows Hardware Quality Labs). En outre, à compter d’octobre 2015, le portail WHQL n’acceptera que les soumissions de pilotes, y compris les soumissions de pilotes en mode noyau et en mode utilisateur, qui ont un certificat de signature de code de validation étendue (« EV ») valide.

Avec Device Guard, les organisations peuvent désormais définir leur propre stratégie d’intégrité du code pour une utilisation sur les systèmes x64 exécutant Windows Entreprise. Les organisations ont la possibilité de configurer la stratégie qui détermine ce qui est approuvé pour l’exécution. Il s’agit notamment des pilotes et des fichiers système, ainsi que des applications de bureau et des scripts traditionnels. Le système est ensuite verrouillé pour exécuter uniquement les applications approuvées par l’organisation.

Device Guard est une fonctionnalité intégrée de Windows Entreprise qui empêche l’exécution d’applications et de code indésirables. Device Guard peut être configuré à l’aide de deux actions de règle : autoriser et refuser :

• Autoriser limite l’exécution des applications à une liste autorisée de code ou d’éditeur approuvé et bloque tout le reste.
• Deny termine l’approche d’autorisation d’un éditeur approuvé en bloquant l’exécution d’une application spécifique.

Au moment de la rédaction de cet article, et selon les dernières recherches de Microsoft, plus de 90% des programmes malveillants sont complètement non signés. Par conséquent, l’implémentation d’une stratégie Device Guard de base peut simplement et efficacement aider à bloquer les programmes malveillants. En fait, Device Guard a le potentiel d’aller plus loin et peut également aider à bloquer les programmes malveillants signés.

Device Guard doit être planifié et configuré pour être vraiment efficace. Il ne s’agit pas seulement d’une protection activée ou désactivée. Device Guard est une combinaison de fonctionnalités de sécurité matérielle et de fonctionnalités de sécurité logicielle qui, lorsqu’elles sont configurées ensemble, peuvent verrouiller un ordinateur pour garantir le système le plus sûr et le plus résistant possible.

Il existe trois parties différentes qui composent la solution Device Guard dans Windows :

• La première partie est un ensemble de base de fonctionnalités de sécurité matérielle introduites avec la version précédente de Windows. TPM pour les opérations de chiffrement matérielles et UEFI avec microprogramme moderne, ainsi que le démarrage sécurisé, vous permet de contrôler l’appareil en cours d’exécution au démarrage des systèmes.
• Après la fonctionnalité de sécurité matérielle, il y a le moteur d’intégrité du code. Dans Windows, l’intégrité du code est désormais entièrement configurable et réside désormais en mode utilisateur isolé, une partie de la mémoire protégée par la sécurité basée sur la virtualisation.
• La dernière partie de Device Guard est la facilité de gestion. La configuration de l’intégrité du code est exposée via des objets de stratégie de groupe spécifiques, des applets de commande PowerShell et des fournisseurs de services de configuration GPM (CSP).

Pour plus d’informations sur le déploiement de Device Guard dans une entreprise, consultez le guide de déploiement de Device Guard.

Scénarios Device Guard

Comme décrit précédemment, Device Guard est un moyen puissant de verrouiller les systèmes. Device Guard n’est pas destiné à être utilisé à grande échelle et il n’est peut-être pas toujours applicable, mais il existe des scénarios très intéressants.

Device Guard est utile et applicable sur les systèmes de charges de travail fixes tels que les caisses enregistreuses, les bornes de travail, les stations de travail d’administration sécurisées (SAW) ou les bureaux bien gérés. Device Guard est très pertinent sur les systèmes qui disposent d’un logiciel bien défini qui sont censés s’exécuter et qui ne changent pas trop fréquemment. Cela peut également aider à protéger les travailleurs de l’information (IW) au-delà des SAW, tant que ce dont ils ont besoin pour s’exécuter est connu et que l’ensemble des applications ne va pas changer quotidiennement.

Les SAP sont des ordinateurs conçus pour aider à réduire considérablement le risque de compromission des programmes malveillants, des attaques par hameçonnage, des sites web factices et des attaques PtH, entre autres risques de sécurité. Bien que les SAP ne puissent pas être considérés comme une solution de sécurité « silver bullet » pour ces attaques, ces types de clients sont utiles dans le cadre d’une approche de sécurité en couches et de défense en profondeur.

Pour protéger les ressources à valeur élevée, les SAP sont utilisées pour établir des connexions sécurisées à ces ressources.

De même, sur les stations de travail d’entreprise entièrement managées, où les applications sont installées à l’aide d’un outil de distribution comme Microsoft Configuration Manager, Intune ou toute autre gestion d’appareils tierce, Device Guard est applicable. Dans ce type de scénario, l’organisation a une bonne idée du logiciel qu’un utilisateur moyen exécute.

Il peut être difficile d’utiliser Device Guard sur des stations de travail d’entreprise légèrement gérées où l’utilisateur est généralement autorisé à installer des logiciels par lui-même. Lorsqu’une organisation offre une grande flexibilité, il est difficile d’exécuter Device Guard en mode d’application. Toutefois, Device Guard peut être exécuté en mode Audit et, dans ce cas, le journal des événements contient un enregistrement de tous les fichiers binaires qui ont enfreint la stratégie Device Guard. Lorsque Device Guard est utilisé en mode Audit, les organisations peuvent obtenir des données enrichies sur les pilotes et les applications que les utilisateurs installent et exécutent.

Avant de pouvoir bénéficier de la protection incluse dans Device Guard, la stratégie d’intégrité du code doit être créée à l’aide des outils fournis par Microsoft, mais la stratégie peut être déployée avec des outils de gestion courants, comme la stratégie de groupe. La stratégie d’intégrité du code est un document XML encodé en binaire qui inclut des paramètres de configuration pour les modes Utilisateur et Noyau de Windows, ainsi que des restrictions sur les hôtes de script Windows. La stratégie d’intégrité du code Device Guard limite le code qui peut s’exécuter sur un appareil.

Remarque

La stratégie Device Guard peut être connectée à Windows, ce qui ajoute une protection supplémentaire contre les utilisateurs administratifs qui modifient ou suppriment cette stratégie.

La stratégie Device Guard signée offre une protection renforcée contre un administrateur local malveillant qui tente de vaincre Device Guard.

Lorsque la stratégie est signée, le GUID de la stratégie est stocké dans une variable sécurisée ueFI pré-système d’exploitation qui offre une protection contre la falsification. La seule façon de mettre à jour la stratégie Device Guard ultérieurement consiste à fournir une nouvelle version de la stratégie signée par le même signataire ou à partir d’un signataire spécifié dans le cadre de la stratégie Device Guard dans la section UpdateSigner.

L’importance de la signature des applications

Sur les ordinateurs équipés de Device Guard, Microsoft propose de passer d’un monde où les applications non signées peuvent être exécutées sans restriction à un monde où seul le code signé et approuvé est autorisé à s’exécuter sur Windows.

Avec Windows, les organisations mettent des applications métier à la disposition des membres de l’organisation via l’infrastructure du Microsoft Store. Plus précisément, les applications métier sont disponibles dans un magasin privé dans le Microsoft Store public. Microsoft Store signe et distribue les applications Windows universelles et les applications Windows classiques. Toutes les applications téléchargées à partir du Microsoft Store sont signées.

Dans les organisations d’aujourd’hui, de nombreuses applications métier ne sont pas signées. La signature de code est souvent perçue comme un problème difficile à résoudre pour diverses raisons, telles que le manque d’expertise en matière de signature de code. Même si la signature de code est une bonne pratique, de nombreuses applications internes ne sont pas signées.

Windows inclut des outils qui permettent aux professionnels de l’informatique de prendre des applications qui ont déjà été empaquetées et de les exécuter via un processus pour créer davantage de signatures qui peuvent être distribuées avec les applications existantes.

Pourquoi les solutions anti-programme malveillant et de gestion des appareils sont-elles toujours nécessaires ?

Bien que les mécanismes de liste d’autorisation garantissent efficacement que seules les applications approuvées peuvent être exécutées, ils ne peuvent pas empêcher la compromission d’une application approuvée (mais vulnérable) par du contenu malveillant conçu pour exploiter une vulnérabilité connue. Device Guard ne protège pas contre le code malveillant en mode utilisateur exécuté en exploitant les vulnérabilités.

Les vulnérabilités sont des faiblesses dans les logiciels qui peuvent permettre à un attaquant de compromettre l’intégrité, la disponibilité ou la confidentialité de l’appareil. Certaines des pires vulnérabilités permettent aux attaquants d’exploiter l’appareil compromis en le faisant exécuter du code malveillant à l’insu de l’utilisateur.

Il est courant de voir des attaquants distribuer du contenu spécialement conçu pour tenter d’exploiter des vulnérabilités connues dans des logiciels en mode utilisateur tels que les navigateurs web (et leurs plug-ins), les machines virtuelles Java, les lecteurs PDF ou les éditeurs de documents. À ce jour, 90 % des vulnérabilités découvertes affectent les applications en mode utilisateur par rapport aux pilotes du système d’exploitation et du mode noyau qui les hébergent.

Pour lutter contre ces menaces, la mise à jour corrective est le contrôle le plus efficace, les logiciels anti-programme malveillant formant des couches de défense complémentaires.

La plupart des logiciels d’application n’ont aucune possibilité de mise à jour. Par conséquent, même si le fournisseur de logiciels publie une mise à jour qui corrige la vulnérabilité, l’utilisateur peut ne pas savoir que la mise à jour est disponible ou comment l’obtenir, et reste donc vulnérable aux attaques. Les organisations doivent toujours gérer les appareils et corriger les vulnérabilités.

Les solutions GPM sont de plus en plus répandues en tant que technologie de gestion des appareils légers. Windows étend les fonctionnalités de gestion qui sont devenues disponibles pour les MMM. Une fonctionnalité clé que Microsoft a ajoutée à Windows est la possibilité pour les mdms d’acquérir une déclaration forte de l’intégrité des appareils à partir d’appareils gérés et inscrits.

Attestation d’intégrité des appareils

L’attestation d’intégrité de l’appareil utilise le module de plateforme sécurisée pour fournir des mesures fiables et vérifiables sur le plan du chiffrement de la chaîne de logiciels utilisée pour démarrer l’appareil.

Pour les appareils Windows, Microsoft introduit une nouvelle API publique qui permettra aux logiciels GPM d’accéder à un service d’attestation distant appelé Service d’attestation d’intégrité Windows. Un résultat d’attestation d’intégrité, en plus d’autres éléments, peut être utilisé pour autoriser ou refuser l’accès aux réseaux, applications ou services, selon que les appareils s’avèrent sains ou non.

Pour plus d’informations sur l’attestation d’intégrité de l’appareil, consultez la section Détecter un appareil Windows défectueux .

Conditions d'octroi de licence d'édition Windows

Le tableau suivant répertorie les éditions De Windows qui prennent en charge le service d’attestation d’intégrité de l’appareil :

Windows Pro	Windows Entreprise	Windows Pro Education/SE	Windows Éducation
Oui	Oui	Oui	Oui

Les droits de licence du service d’attestation d’intégrité de l’appareil sont accordés par les licences suivantes :

Windows Pro/Professionnel Éducation/SE	Windows Entreprise E3	Windows Entreprise E5	Windows Éducation A3	Windows Éducation A5
Oui	Oui	Oui	Oui	Oui

Pour plus d’informations à propos des licences Windows, consultez Vue d’ensemble des licences Windows.

Configuration matérielle requise

Le tableau suivant détaille la configuration matérielle requise pour les services de sécurité basés sur la virtualisation et la fonctionnalité d’attestation d’intégrité. Pour plus d’informations, consultez Configuration matérielle minimale requise.

Matériel	Motivation
Microprogramme UEFI 2.3.1 ou version ultérieure avec démarrage sécurisé activé	Requis pour prendre en charge le démarrage sécurisé UEFI. Le démarrage sécurisé UEFI garantit que l’appareil démarre uniquement du code autorisé. En outre, l’intégrité du démarrage (démarrage sécurisé de la plateforme) doit être prise en charge conformément aux exigences de la spécification de compatibilité matérielle pour les systèmes pour Windows sous la sous-section : « System.Fundamentals.Firmware.CS.UEFISecureBoot.ConnectedStandby »
Les extensions de virtualisation, telles qu’Intel VT-x, AMD-V et SLAT, doivent être activées	Requis pour prendre en charge la sécurité basée sur la virtualisation. Note: Device Guard peut être activé sans utiliser la sécurité basée sur la virtualisation.
Processeur X64	Requis pour prendre en charge la sécurité basée sur la virtualisation qui utilise l’hyperviseur Windows. Hyper-V est pris en charge uniquement sur le processeur x64 (et non sur x86). La protection d’accès direct à la mémoire (DMA) peut être activée pour fournir une protection supplémentaire de la mémoire, mais nécessite que les processeurs incluent des technologies de protection DMA.
IOMMU, par exemple Intel VT-d, AMD-Vi	La prise en charge de l’IOMMU dans Windows améliore la résilience du système contre les attaques DMA.
Module de plateforme sécurisée	Requis pour prendre en charge l’attestation d’intégrité et nécessaire pour d’autres protections clés pour la sécurité basée sur la virtualisation. TPM 2.0 est pris en charge. La prise en charge de TPM 1.2 a été ajoutée à partir de Windows 10, version 1607 (RS1)

Cette section a présenté des informations sur plusieurs contrôles étroitement liés dans Windows. Les défenses multicouches et l’approche en profondeur aident à éradiquer les programmes malveillants de bas niveau pendant la séquence de démarrage. La sécurité basée sur la virtualisation est une modification fondamentale de l’architecture du système d’exploitation qui ajoute une nouvelle limite de sécurité. Device Guard et Credential Guard aident respectivement à bloquer le code non approuvé et à protéger les informations d’identification du domaine d’entreprise contre le vol et la réutilisation. Cette section a également brièvement abordé l’importance de la gestion des appareils et de la mise à jour corrective des vulnérabilités. Toutes ces technologies peuvent être utilisées pour renforcer et verrouiller les appareils tout en limitant le risque que des attaquants les compromettent.

Détecter un appareil Windows défectueux

À l’heure actuelle, de nombreuses organisations considèrent que les appareils sont conformes à la stratégie de l’entreprise uniquement après avoir passé diverses vérifications qui montrent, par exemple, que le système d’exploitation est dans l’état correct, correctement configuré et que la protection de sécurité est activée. Malheureusement, avec les systèmes d’aujourd’hui, cette forme de création de rapports n’est pas entièrement fiable, car les logiciels malveillants peuvent usurper une déclaration logicielle sur l’intégrité du système. Un rootkit, ou un exploit de bas niveau similaire, peut signaler un faux état sain aux outils de conformité traditionnels.

Le plus grand défi avec les rootkits est qu’ils peuvent être indétectables pour le client. Comme ils commencent avant les logiciels anti-programme malveillant et qu’ils disposent de privilèges au niveau du système, ils peuvent complètement se déguiser tout en continuant à accéder aux ressources système. Par conséquent, les ordinateurs traditionnels infectés par des rootkits semblent être sains, même avec un logiciel anti-programme malveillant en cours d’exécution.

Comme nous l’avons vu précédemment, la fonctionnalité d’attestation d’intégrité de Windows utilise le composant matériel TPM pour enregistrer en toute sécurité une mesure de chaque composant lié au démarrage, y compris le microprogramme, le noyau Windows et même les pilotes de démarrage précoces. Étant donné que l’attestation d’intégrité utilise les fonctionnalités de sécurité matérielles de TPM, le journal de tous les composants mesurés au démarrage reste hors de portée de tout programme malveillant.

Une fois que les appareils ont attesté d’un état de démarrage approuvé, ils peuvent prouver qu’ils n’exécutent pas de programmes malveillants de bas niveau susceptibles d’usurper des vérifications de conformité ultérieures. L’attestation d’intégrité basée sur le module de plateforme sécurisée fournit une ancre fiable de confiance pour les ressources qui contiennent des données à valeur élevée.

Quel est le concept d’intégrité de l’appareil ?

Pour comprendre le concept d’intégrité des appareils, il est important de connaître les mesures traditionnelles que les professionnels de l’informatique ont prises pour empêcher la violation de programmes malveillants. Les technologies de contrôle des programmes malveillants sont très axées sur la prévention de l’installation et de la distribution.

Toutefois, l’utilisation de technologies traditionnelles de prévention des programmes malveillants, comme les solutions anti-programme malveillant ou de mise à jour corrective, entraîne un nouvel ensemble de problèmes pour les professionnels de l’informatique : la possibilité de surveiller et de contrôler la conformité des appareils accédant aux ressources de l’organisation.

La définition de la conformité des appareils varie en fonction de l’anti-programme malveillant installé d’une organisation, des paramètres de configuration des appareils, de la base de référence de gestion des correctifs et d’autres exigences de sécurité. Toutefois, l’intégrité de l’appareil fait partie de la stratégie de conformité globale de l’appareil.

L’intégrité de l’appareil n’est pas binaire et dépend de l’implémentation de la sécurité de l’organisation. Le service d’attestation d’intégrité fournit des informations au GPM sur lequel les fonctionnalités de sécurité sont activées pendant le démarrage de l’appareil à l’aide du module de plateforme sécurisée (TPM) matériel fiable.

Mais l’attestation d’intégrité fournit uniquement des informations, c’est pourquoi une solution MDM est nécessaire pour prendre et appliquer une décision.

Attestation d’intégrité des appareils distants

Dans Windows, l’attestation d’intégrité fait référence à une fonctionnalité où les données de démarrage mesuré générées pendant le processus de démarrage sont envoyées à un service d’attestation d’intégrité d’appareil distant géré par Microsoft.

Cette approche est la plus sécurisée disponible pour les appareils Windows afin de détecter quand les défenses de sécurité sont arrêtées. Pendant le processus de démarrage, les valeurs du journal TCG et des PRC sont envoyées à un service cloud Microsoft distant. Les journaux sont ensuite vérifiés par le service d’attestation d’intégrité pour déterminer les modifications qui se sont produites sur l’appareil.

Une partie de confiance telle qu’une GPM peut inspecter le rapport généré par le service d’attestation d’intégrité à distance.

Remarque

Pour utiliser la fonctionnalité d’attestation d’intégrité de Windows, l’appareil doit être équipé d’un TPM discret ou microprogramme. Il n’existe aucune restriction sur une édition particulière de Windows.

Windows prend en charge les scénarios d’attestation d’intégrité en autorisant les applications à accéder au fournisseur de services de configuration d’attestation d’intégrité sous-jacent afin que les applications puissent demander un jeton d’attestation d’intégrité. La mesure de la séquence de démarrage peut être vérifiée à tout moment localement par un anti-programme malveillant ou un agent MDM.

L’attestation d’intégrité de l’appareil à distance combinée à une gestion des appareils mobiles fournit une méthode basée sur le matériel pour signaler l’état de sécurité actuel et détecter les modifications, sans avoir à approuver le logiciel s’exécutant sur le système.

Dans le cas où du code malveillant est en cours d’exécution sur l’appareil, l’utilisation d’un serveur distant est requise. Si un rootkit est présent sur l’appareil, l’anti-programme malveillant n’est plus fiable et son comportement peut être détourné par un code malveillant s’exécutant au début de la séquence de démarrage. C’est la raison pour laquelle il est important d’utiliser le démarrage sécurisé et Device Guard pour contrôler le code qui est chargé pendant la séquence de démarrage.

Le logiciel anti-programme malveillant peut effectuer une recherche pour déterminer si la séquence de démarrage contient des signes de programmes malveillants, tels qu’un rootkit. Il peut également envoyer le journal TCG et les PCR à un serveur d’attestation d’intégrité distant pour fournir une séparation entre le composant de mesure et le composant de vérification.

L’attestation d’intégrité enregistre les mesures dans différents registres de configuration de plateforme TPM (PCR) et journaux TCG pendant le processus de démarrage.

Lorsque vous démarrez un appareil équipé de TPM, une mesure de différents composants est effectuée. Ces composants incluent le microprogramme, les pilotes UEFI, le microcode du processeur, ainsi que tous les pilotes Windows dont le type est Démarrage. Les mesures brutes sont stockées dans les registres PCR TPM, tandis que les détails de tous les événements (chemin d’accès exécutable, certification de l’autorité, etc.) sont disponibles dans le journal TCG.

Le processus d’attestation d’intégrité fonctionne comme suit :

1. Les composants de démarrage matériel sont mesurés.
2. Les composants de démarrage du système d’exploitation sont mesurés.
3. Si Device Guard est activé, la stratégie Device Guard actuelle est mesurée.
4. Le noyau Windows est mesuré.
5. Le logiciel antivirus est démarré en tant que premier pilote en mode noyau.
6. Les pilotes de démarrage sont mesurés.
7. Le serveur GPM par le biais de l’agent MDM émet une commande de contrôle d’intégrité à l’aide du csp Attestation d’intégrité.
8. Les mesures de démarrage sont validées par le service d’attestation d’intégrité

Remarque

Par défaut, les 100 derniers journaux de démarrage système et tous les journaux de reprise associés sont archivés dans le dossier %SystemRoot%\logs\measuredboot. Le nombre de journaux conservés peut être défini avec le Registre REG_DWORD valeur PlatformLogRetention sous la clé HKLM\SYSTEM\CurrentControlSet\Services\TPM . La valeur 0 désactive l’archivage des journaux et la valeur 0xffffffff conserve tous les journaux.

Le processus suivant décrit comment les mesures de démarrage d’intégrité sont envoyées au service d’attestation d’intégrité :

1. Le client (un appareil Windows avec TPM) lance la demande avec le service d’attestation d’intégrité de l’appareil distant. Étant donné que le serveur d’attestation d’intégrité est censé être un service cloud Microsoft, l’URI est déjà préprovisionné dans le client.

2. Le client envoie ensuite le journal TCG, les données signées AIK (valeurs PCR, compteur de démarrage) et les informations du certificat AIK.

3. Le service d’attestation de heath à distance de l’appareil :

   1. Vérifie que le certificat AIK est émis par une autorité de certification connue et approuvée et que le certificat est valide et non révoqué.
   2. Vérifie que la signature sur les guillemets PCR est correcte et cohérente avec la valeur du journal TCG.
   3. Analyse les propriétés dans le journal TCG.
   4. Émet le jeton d’intégrité de l’appareil qui contient les informations d’intégrité, les informations AIK et les informations du compteur de démarrage. Le jeton d’intégrité contient également une heure d’émission valide. Le jeton d’intégrité de l’appareil est chiffré et signé, ce qui signifie que les informations sont protégées et accessibles uniquement pour l’émission du service d’attestation d’intégrité.

4. Le client stocke l’objet blob chiffré d’intégrité dans son magasin local. Le jeton d’intégrité de l’appareil contient l’état d’intégrité de l’appareil, un ID d’appareil (Windows AIK) et le compteur de démarrage.

Composants d’attestation d’intégrité de l’appareil

La solution d’attestation d’intégrité de l’appareil implique différents composants qui sont le TPM, le fournisseur csp d’attestation d’intégrité et le service d’attestation d’intégrité Windows. Ces composants sont décrits dans cette section.

Module de plateforme sécurisée

Cette section décrit comment les fichiers PCR (qui contiennent des données de configuration système), la clé d’approbation (EK) (qui jouent le rôle de carte d’identité pour le module de plateforme sécurisée), le SRK (qui protège les clés) et les kits AIK (qui peuvent signaler l’état de la plateforme) sont utilisés pour la création de rapports d’attestation d’intégrité.

De manière simplifiée, le module de plateforme sécurisée est un composant passif avec des ressources limitées. Il peut calculer des nombres aléatoires, des clés RSA, déchiffrer des données courtes, stocker les hachages pris lors du démarrage de l’appareil.

Un module TPM est incorporé dans un seul composant :

• Un générateur de clés RSA 2048 bits
• Un générateur de nombres aléatoires
• Mémoire non volatile pour le stockage des clés EK, SRK et AIK
• Un moteur de chiffrement pour chiffrer, déchiffrer et signer
• Mémoire volatile pour le stockage des pcr et des clés RSA

Clé d’approbation

Le module de plateforme sécurisée dispose d’une clé de chiffrement unique incorporée appelée clé d’approbation. La clé d’approbation TPM est une paire de clés asymétriques (taille RSA 2 048 bits).

La clé publique de la clé d’approbation est utilisée pour envoyer des paramètres sensibles en toute sécurité, par exemple lors de la prise en main du module de plateforme sécurisée qui contient le hachage de définition du mot de passe du propriétaire. La clé privée EK est utilisée lors de la création de clés secondaires telles que des SDK.

La clé d’approbation fait office de carte d’identité pour le module de plateforme sécurisée. Pour plus d’informations, consultez Comprendre la clé d’approbation TPM.

La clé d’approbation est souvent accompagnée d’un ou deux certificats numériques :

• Un certificat est produit par le fabricant du module de plateforme sécurisée et est appelé certificat d’approbation. Le certificat d’approbation est utilisé pour prouver l’authenticité du module de plateforme sécurisée (par exemple, qu’il s’agit d’un vrai module de plateforme sécurisée fabriqué par un fabricant de puces spécifique) aux processus, applications ou services cloud locaux. Le certificat d’approbation est créé pendant la fabrication ou la première fois que le module de plateforme sécurisée est initialisé en communiquant avec un service en ligne.
• L’autre certificat est produit par le générateur de plateforme et est appelé certificat de plateforme pour indiquer qu’un TPM spécifique est intégré à un certain appareil. Pour certains appareils qui utilisent un module de plateforme sécurisée basé sur un microprogramme produit par Intel ou Qualcomm, le certificat d’approbation est créé lorsque le module de plateforme sécurisée est initialisé pendant l’OOBE de Windows.

Remarque

Le démarrage sécurisé protège la plateforme jusqu’au chargement du noyau Windows. Ensuite, les protections comme le démarrage approuvé, l’intégrité du code Hyper-V et ELAM prennent le relais. Un appareil qui utilise Intel TPM ou Qualcomm TPM obtient un certificat signé en ligne auprès du fabricant qui a créé la puce, puis stocke le certificat signé dans le stockage TPM. Pour que l’opération réussisse, si vous filtrez l’accès à Internet à partir de vos appareils clients, vous devez autoriser les URL suivantes :

• Pour le module TPM du microprogramme Intel : https://ekop.intel.com/ekcertservice
• Pour le module de plateforme sécurisée (TPM) du microprogramme Qualcomm : https://ekcert.spserv.microsoft.com/

Clés d’identité d’attestation

Étant donné que le certificat d’approbation est unique pour chaque appareil et ne change pas, son utilisation peut présenter des problèmes de confidentialité, car il est théoriquement possible de suivre un appareil spécifique. Pour éviter ce problème de confidentialité, Windows émet une ancre d’attestation dérivée basée sur le certificat d’approbation. Cette clé intermédiaire, qui peut être attestée d’une clé d’approbation, est la clé d’identité d’attestation (AIK) et le certificat correspondant est appelé certificat AIK. Ce certificat AIK est émis par un service cloud Microsoft.

Remarque

Avant que l’appareil puisse signaler son intégrité à l’aide des fonctions d’attestation TPM, un certificat AIK doit être provisionné conjointement avec un service tiers comme le service d’autorité de certification cloud Microsoft. Une fois provisionnée, la clé privée AIK peut être utilisée pour signaler la configuration de la plateforme. Windows crée une signature sur l’état du journal de la plateforme (et une valeur de compteur monotone) à chaque démarrage à l’aide de l’AIK.

L’AIK est une paire de clés asymétrique (publique/privée) qui est utilisée comme substitut de l’EK en tant qu’identité pour le TPM à des fins de confidentialité. La partie privée d’un AIK n’est jamais révélée ou utilisée en dehors du module de plateforme sécurisée et ne peut être utilisée qu’à l’intérieur du module de plateforme sécurisée pour un ensemble limité d’opérations. En outre, il ne peut être utilisé que pour la signature et uniquement pour les opérations limitées définies par TPM.

Windows crée des AIK protégés par le TPM, le cas échéant, qui sont des clés de signature RSA 2048 bits. Microsoft héberge un service cloud appelé Microsoft Cloud CA pour établir par chiffrement qu’il communique avec un vrai TPM et que le module TPM possède l’AIK présenté. Une fois que le service d’autorité de certification Microsoft Cloud a établi ces faits, il émet un certificat AIK pour l’appareil Windows.

De nombreux appareils existants qui seront mis à niveau vers Windows 10 n’auront pas de TPM, ou le module de plateforme sécurisée ne contiendra pas de certificat d’approbation. Pour prendre en charge ces appareils, Windows 10 autorise l’émission de certificats AIK sans la présence d’un certificat d’approbation. Ces certificats AIK ne sont pas émis par l’autorité de certification Microsoft Cloud. Ces certificats ne sont pas aussi fiables qu’un certificat d’approbation qui est gravé dans l’appareil pendant la fabrication, mais ils fournissent la compatibilité pour les scénarios avancés tels que Windows Hello Entreprise sans TPM.

Dans le certificat AIK émis, un OID spécial est ajouté pour attester que le certificat d’approbation a été utilisé pendant le processus d’attestation. Ces informations peuvent être utilisées par une partie de confiance pour décider s’il faut rejeter les appareils attestés à l’aide de certificats AIK sans certificat d’approbation ou les accepter. Un autre scénario peut être de ne pas autoriser l’accès aux ressources de valeur élevée à partir d’appareils attestés par un certificat AIK qui n’est pas soutenu par un certificat d’approbation.

Clé racine de stockage

La clé racine de stockage (SRK) est également une paire de clés asymétriques (RSA avec une longueur minimale de 2 048 bits). Le SRK a un rôle majeur et est utilisé pour protéger les clés TPM, de sorte que ces clés ne peuvent pas être utilisées sans le TPM. La clé SRK est créée lorsque la propriété du TPM est prise.

Registres de configuration de la plateforme

Le module de plateforme sécurisée contient un ensemble de registres conçus pour fournir une représentation cryptographique du logiciel et de l’état du système qui a démarré. Ces registres sont appelés registres de configuration de plateforme (PCR).

La mesure de la séquence de démarrage est basée sur le journal PCR et TCG. Pour établir une racine statique de confiance, lorsque l’appareil démarre, l’appareil doit être en mesure de mesurer le code du microprogramme avant l’exécution. Dans ce cas, la racine principale de confiance pour la mesure (CRTM) est exécutée à partir du démarrage, calcule le hachage du microprogramme, puis le stocke en développant le registre PCR[0] et transfère l’exécution au microprogramme.

Les PCR sont définis sur zéro lorsque la plateforme est démarrée, et c’est le travail du microprogramme qui démarre la plateforme pour mesurer les composants dans la chaîne de démarrage et pour enregistrer les mesures dans les pcrs. En règle générale, les composants de démarrage prennent le hachage du composant suivant qui doit être exécuté et enregistrent les mesures dans les pcr. Le composant initial qui démarre la chaîne de mesures est implicitement approuvé. Ce composant est le CRTM. Les fabricants de plateforme doivent disposer d’un processus de mise à jour sécurisé pour le CRTM ou ne pas autoriser les mises à jour de celui-ci. Les fichiers PCR enregistrent un hachage cumulé des composants qui ont été mesurés.

La valeur d’un test DEP en soi est difficile à interpréter (il s’agit simplement d’une valeur de hachage), mais les plateformes conservent généralement un journal avec les détails de ce qui a été mesuré, et les PCR s’assurent simplement que le journal n’a pas été falsifié. Les journaux sont appelés journaux TCG. Chaque fois qu’un registre EST étendu, une entrée est ajoutée au journal TCG. Ainsi, tout au long du processus de démarrage, une trace du code exécutable et des données de configuration est créée dans le journal TCG.

Provisionnement du module de plateforme sécurisée (TPM)

Pour que le module de plateforme sécurisée d’un appareil Windows soit utilisable, il doit d’abord être provisionné. Le processus d’approvisionnement diffère en fonction des versions du module de plateforme sécurisée, mais en cas de réussite, le module de plateforme sécurisée est utilisable et les données d’autorisation du propriétaire (ownerAuth) pour le module de plateforme sécurisée sont stockées localement dans le Registre.

Lorsque le module de plateforme sécurisée est provisionné, Windows tente d’abord de déterminer les valeurs EK et ownerAuth stockées localement en recherchant dans le Registre à l’emplacement suivant : HKLM\SYSTEM\CurrentControlSet\Services\TPM\WMI\Endorsement

Pendant le processus d’approvisionnement, l’appareil peut avoir besoin d’être redémarré.

L’applet de commande PowerShell Get-TpmEndorsementKeyInfo peut être utilisée avec des privilèges d’administration pour obtenir des informations sur la clé d’approbation et les certificats du module de plateforme sécurisée.

Si la propriété TPM n’est pas connue, mais que l’EK existe, la bibliothèque cliente provisionne le module de plateforme sécurisée et stocke la valeur ownerAuth obtenue dans le Registre si la stratégie le permet, stocke la partie publique SRK à l’emplacement suivant : HKLM\SYSTEM\CurrentControlSet\Services\TPM\WMI\Admin\SRKPub

Dans le cadre du processus d’approvisionnement, Windows crée une AIK avec le TPM. Lorsque cette opération est effectuée, la partie publique AIK résultante est stockée dans le Registre à l’emplacement suivant : HKLM\SYSTEM\CurrentControlSet\Services\TPM\WMI\WindowsAIKPub

Remarque

Pour l’approvisionnement des certificats AIK et le filtrage de l’accès à Internet, vous devez autoriser l’URL générique suivante : https://\*.microsoftaik.azure.net

Fournisseur de services de configuration Attestation d’intégrité Windows

Windows contient un fournisseur de services de configuration (CSP) spécialisé pour interagir avec la fonctionnalité d’attestation d’intégrité. Un fournisseur de solutions Cloud est un composant qui se connecte au client GPM Windows et fournit un protocole publié pour la façon dont les serveurs MDM peuvent configurer les paramètres et gérer les appareils Windows. Le protocole de gestion est représenté sous la forme d’une arborescence qui peut être spécifiée en tant qu’URI avec des fonctions à exécuter sur les URI telles que « get », « set », « delete », etc.

La liste suivante est celle des fonctions effectuées par le fournisseur de services de configuration d’attestation d’intégrité Windows :

• Collecte les données utilisées pour vérifier l’état d’intégrité d’un appareil
• Transfère les données au service d’attestation d’intégrité
• Provisionne le certificat d’attestation d’intégrité qu’il reçoit du service d’attestation d’intégrité
• Sur demande, transfère le certificat d’attestation d’intégrité (reçu du service d’attestation d’intégrité) et les informations d’exécution associées au serveur MDM pour vérification

Au cours d’une session d’attestation d’intégrité, le csp Attestation d’intégrité transfère les journaux TCG et les valeurs des rcp qui sont mesurées pendant le démarrage, à l’aide d’un canal de communication sécurisé au service d’attestation d’intégrité.

Lorsqu’un serveur GPM valide qu’un appareil a attesté auprès du service d’attestation d’intégrité, il reçoit un ensemble d’instructions et de revendications sur la façon dont cet appareil a démarré, avec l’assurance que l’appareil n’a pas redémarré entre le moment où il a attesté son intégrité et le moment où le serveur MDM l’a validé.

Service d’attestation d’intégrité Windows

Le rôle du service d’attestation d’intégrité Windows est essentiellement d’évaluer un ensemble de données d’intégrité (valeurs de journal TCG et DEP), d’effectuer une série de détections (en fonction des données d’intégrité disponibles) et de générer un objet blob d’intégrité chiffré ou de produire un rapport aux serveurs MDM.

Remarque

Les serveurs d’appareil et GPM doivent avoir accès à has.spserv.microsoft.com à l’aide du protocole TCP sur le port 443 (HTTPS).

La vérification de la validité d’une attestation TPM et du journal associé s’effectue en plusieurs étapes :

1. Tout d’abord, le serveur doit vérifier que les rapports sont signés par des AIK dignes de confiance. Cette vérification peut être effectuée en vérifiant que la partie publique de l’AIK est répertoriée dans une base de données de ressources, ou peut-être qu’un certificat a été vérifié.
2. Une fois la clé vérifiée, l’attestation signée (structure de devis) doit être vérifiée pour voir s’il s’agit d’une signature valide par rapport aux valeurs DEP.
3. Ensuite, les journaux doivent être vérifiés pour s’assurer qu’ils correspondent aux valeurs DUP signalées.
4. Enfin, les journaux eux-mêmes doivent être examinés par une solution MDM pour voir s’ils représentent des configurations de sécurité connues ou valides. Par exemple, une vérification simple peut être de voir si les premiers composants du système d’exploitation mesurés sont connus pour être bons, que le pilote ELAM est comme prévu et que le fichier de stratégie du pilote ELAM est à jour. Si toutes ces vérifications réussissent, une instruction d’attestation peut être émise qui peut être utilisée ultérieurement pour déterminer si le client doit ou non se voir accorder l’accès à une ressource.

Le service d’attestation d’intégrité fournit les informations suivantes à une solution MDM sur l’intégrité de l’appareil :

• Activation du démarrage sécurisé
• Activation du démarrage et du débogage du noyau
• Activation de BitLocker
• VSM activé
• Mesure de stratégie d’intégrité du code Device Guard signée ou non signée
• ELAM chargé
• Démarrage en mode sans échec, activation DEP, activation de la signature de test
• Le module de plateforme sécurisée de l’appareil a été provisionné avec un certificat d’approbation approuvé

Pour obtenir l’exhaustivité des mesures, consultez Certificat d’intégrité CSP.

La liste suivante présente certains éléments clés qui peuvent être signalés à GPM pour les appareils Windows :

• Mesure DE LAP0
• Démarrage sécurisé activé
• La base de données de démarrage sécurisé correspond à la base de données attendue
• Le dbx de démarrage sécurisé est à jour
• Le GUID de stratégie de démarrage sécurisé correspond à attendu
• BitLocker activé
• Sécurité basée sur la virtualisation activée
• ELAM a été chargé
• La version d’intégrité du code est à jour
• Le hachage de la stratégie d’intégrité du code correspond aux attentes

Utiliser GPM et le service d’attestation d’intégrité

Pour rendre l’intégrité de l’appareil pertinente, la solution MDM évalue le rapport d’intégrité de l’appareil et est configurée en fonction des exigences d’intégrité des appareils de l’organisation.

Une solution qui utilise GPM et le service d’attestation d’intégrité se compose de trois parties principales :

1. Un appareil avec l’attestation d’intégrité activée. Cette activation est effectuée dans le cadre de l’inscription auprès d’un fournisseur MDM (l’attestation d’intégrité est désactivée par défaut).

2. Une fois ce service activé et chaque démarrage par la suite, l’appareil envoie des mesures d’intégrité au service d’attestation d’intégrité hébergé par Microsoft, et il reçoit un objet blob d’attestation d’intégrité en retour.

3. À tout moment après ce cycle, un serveur GPM peut demander l’objet blob d’attestation d’intégrité à partir de l’appareil et demander au service d’attestation d’intégrité de déchiffrer le contenu et de vérifier qu’il a été attesté.

   

L’interaction entre un appareil Windows, le service d’attestation d’intégrité et la gestion des appareils mobiles peut être effectuée comme suit :

1. Le client lance une session avec le serveur MDM. L’URI du serveur MDM fait partie de l’application cliente qui lance la demande. Le serveur MDM à ce stade peut demander les données d’attestation d’intégrité à l’aide de l’URI CSP approprié.

2. Le serveur GPM spécifie un nonce avec la requête.

3. Le client envoie ensuite le nonce entre guillemets AIK + le compteur de démarrage et les informations de l’objet blob d’intégrité. Cet objet blob d’intégrité est chiffré avec une clé publique du service d’attestation d’intégrité que seul le service d’attestation d’intégrité peut déchiffrer.

4. Le serveur MDM :

   1. Vérifie que le nonce est comme prévu.
   2. Transmet les données entre guillemets, le nonce et l’objet blob d’intégrité chiffré au serveur du service d’attestation d’intégrité.

5. Service d’attestation d’intégrité :

   1. Déchiffre l’objet blob d’intégrité.
   2. Vérifie que le compteur de démarrage dans le guillemet est correct à l’aide de l’AIK dans l’objet blob d’intégrité et qu’il correspond à la valeur de l’objet blob d’intégrité.
   3. Vérifie que la valeur nonce correspond dans le devis et à celle qui est passée à partir de GPM.
   4. Étant donné que le compteur de démarrage et la valeur nonce sont entre guillemets avec l’AIK de l’objet blob d’intégrité, cela prouve également que l’appareil est le même que celui pour lequel l’objet blob d’intégrité a été généré.
   5. Renvoie les données au serveur MDM, y compris les paramètres d’intégrité, l’actualisation, etc.

Remarque

Le serveur MDM (partie de confiance) n’effectue jamais la validation du devis ou du compteur de démarrage lui-même. Il obtient les données entre guillemets et l’objet blob d’intégrité (qui est chiffré) et envoie les données au service d’attestation d’intégrité pour validation. De cette façon, l’AIK n’est jamais visible par le GPM, ce qui répond donc aux problèmes de confidentialité.

La définition des exigences de conformité des appareils est la première étape pour s’assurer que les appareils inscrits qui ne répondent pas aux exigences d’intégrité et de conformité sont détectés, suivis et que les actions sont appliquées par la solution MDM.

L’intégrité des appareils qui tentent de se connecter aux ressources doit être évaluée afin que les appareils non conformes et non conformes puissent être détectés et signalés. Pour être entièrement efficace, une solution de sécurité de bout en bout doit imposer une conséquence pour les appareils défectueux, comme refuser l’accès à des ressources de grande valeur. Cette conséquence pour un appareil défectueux est l’objectif du contrôle d’accès conditionnel, qui est détaillé dans la section suivante.

Contrôler la sécurité d’un appareil Windows avant l’octroi de l’accès

La technologie de contrôle d’accès d’aujourd’hui, dans la plupart des cas, vise à s’assurer que les bonnes personnes ont accès aux ressources appropriées. Si les utilisateurs peuvent s’authentifier, ils ont accès aux ressources à l’aide d’un appareil que le personnel informatique et les systèmes de l’organisation connaissent peu. Peut-être y a-t-il des vérifications telles que s’assurer qu’un appareil est chiffré avant d’accorder l’accès à l’e-mail, mais que se passe-t-il si l’appareil est infecté par un programme malveillant ?

Le processus d’attestation d’intégrité de l’appareil distant utilise des données de démarrage mesurées pour vérifier l’état d’intégrité de l’appareil. L’intégrité de l’appareil est ensuite disponible pour une solution GPM telle qu’Intune.

Remarque

Pour obtenir les dernières informations sur la prise en charge des fonctionnalités Intune et Windows, consultez Nouveautés de Microsoft Intune.

La figure ci-dessous montre comment le service d’attestation d’intégrité est censé fonctionner avec le service GPM Intune basé sur le cloud de Microsoft.

Une solution MDM peut ensuite utiliser des instructions d’état d’intégrité et les faire passer au niveau suivant en les associant aux stratégies clientes qui permettront d’accorder l’accès conditionnel en fonction de la capacité de l’appareil à prouver qu’il est exempt de programmes malveillants, que son système anti-programme malveillant est fonctionnel et à jour, que le pare-feu est en cours d’exécution et que l’état du correctif des appareils est conforme.

Enfin, les ressources peuvent être protégées en refusant l’accès aux points de terminaison qui ne peuvent pas prouver qu’ils sont sains. Cette fonctionnalité est très nécessaire pour les appareils BYOD qui doivent accéder aux ressources de l’organisation.

Prise en charge intégrée de la gestion des appareils mobiles dans Windows

Windows dispose d’un client GPM fourni dans le cadre du système d’exploitation. Ce client MDM permet aux serveurs GPM de gérer les appareils Windows sans nécessiter d’agent distinct.

Prise en charge des serveurs GPM non-Microsoft

Les serveurs GPM non-Microsoft peuvent gérer Windows à l’aide du protocole MDM. Le client de gestion intégré est en mesure de communiquer avec un serveur compatible qui prend en charge le protocole OMA-DM pour effectuer des tâches de gestion d’entreprise. Pour plus d’informations, consultez Intégration de Microsoft Entra à MDM.

Remarque

Les serveurs GPM n’ont pas besoin de créer ou de télécharger un client pour gérer Windows. Pour plus d’informations, consultez Gestion des appareils mobiles.

Le serveur GPM tiers aura la même expérience utilisateur interne cohérente pour l’inscription, ce qui offre également une simplicité pour les utilisateurs Windows.

Gestion de Windows Defender par GPM tiers

Cette infrastructure de gestion permet aux professionnels de l’informatique d’utiliser des produits compatibles MDM comme Intune, pour gérer l’attestation d’intégrité, Device Guard ou Windows Defender sur les appareils Windows, y compris les BYOD qui ne sont pas joints à un domaine. Les professionnels de l’informatique pourront gérer et configurer toutes les actions et paramètres qu’ils connaissent pour personnaliser à l’aide d’Intune avec Intune Endpoint Protection sur des systèmes d’exploitation de bas niveau. Les administrateurs qui gèrent uniquement les appareils joints à un domaine par le biais d’une stratégie de groupe peuvent facilement passer à la gestion des appareils Windows à l’aide de GPM, car la plupart des paramètres et actions sont partagés entre les deux mécanismes.

Pour plus d’informations sur la gestion de la sécurité et des paramètres système Windows avec une solution MDM, consultez Paramètres d’URI personnalisés pour les appareils Windows.

Contrôle d’accès conditionnel

Sur la plupart des plateformes, l’inscription de l’appareil Microsoft Entra se produit automatiquement lors de l’inscription. Les états de l’appareil sont écrits par la solution MDM dans l’ID Microsoft Entra, puis lus par Office 365 (ou par toute application Windows autorisée qui interagit avec l’ID Microsoft Entra) la prochaine fois que le client tente d’accéder à une charge de travail compatible Office 365.

Si l’appareil n’est pas inscrit, l’utilisateur recevra un message contenant des instructions sur la façon d’inscrire (également appelée inscription). Si l’appareil n’est pas conforme, l’utilisateur reçoit un message différent qui le redirige vers le portail web MDM, où il peut obtenir plus d’informations sur le problème de conformité et la façon de le résoudre.

L’ID Microsoft Entra authentifie l’utilisateur et l’appareil, GPM gère les stratégies de conformité et d’accès conditionnel, et le service d’attestation d’intégrité signale l’intégrité de l’appareil de manière attestée.

Contrôle d’accès conditionnel Office 365

Microsoft Entra ID applique des stratégies d’accès conditionnel pour sécuriser l’accès aux services Office 365. Un administrateur client peut créer une stratégie d’accès conditionnel qui empêche un utilisateur sur un appareil non conforme d’accéder à un service Office 365. L’utilisateur doit se conformer aux stratégies d’appareil de l’entreprise pour que l’accès au service puisse être accordé. L’administrateur peut également créer une stratégie qui exige que les utilisateurs inscrivent simplement leurs appareils pour accéder à un service Office 365. Les stratégies peuvent être appliquées à tous les utilisateurs d’une organisation, ou limitées à quelques groupes cibles et améliorées au fil du temps pour inclure davantage de groupes cibles.

Lorsqu’un utilisateur demande l’accès à un service Office 365 à partir d’une plateforme d’appareil prise en charge, Microsoft Entra authentifie l’utilisateur et l’appareil à partir desquels l’utilisateur lance la demande . et accordent l’accès au service uniquement lorsque l’utilisateur est conforme à la stratégie définie pour le service. Les utilisateurs qui n’ont pas leur appareil inscrit reçoivent des instructions de correction sur la façon d’inscrire et de devenir conformes pour accéder aux services Office 365 d’entreprise.

Lorsqu’un utilisateur s’inscrit, l’appareil est inscrit avec l’ID Microsoft Entra et inscrit auprès d’une solution GPM compatible comme Intune.

Remarque

Microsoft travaille avec des éditeurs de logiciels indépendants GPM tiers pour prendre en charge l’inscription MDM automatisée et les vérifications d’accès basées sur des stratégies. Les étapes d’activation de l’inscription automatique à la gestion des appareils mobiles avec l’ID Microsoft Entra et Intune sont expliquées dans le billet de blog Windows, Id Microsoft Entra et Microsoft Intune : Inscription GPM automatique optimisée par le cloud ! .

Lorsqu’un utilisateur inscrit un appareil avec succès, l’appareil devient approuvé. L’ID Microsoft Entra fournit l’authentification unique pour accéder aux applications d’entreprise et applique une stratégie d’accès conditionnel pour accorder l’accès à un service non seulement la première fois que l’utilisateur demande l’accès, mais chaque fois que l’utilisateur demande à renouveler l’accès.

L’accès aux services est refusé à l’utilisateur lorsque les informations d’identification de connexion sont modifiées, qu’un appareil est perdu/volé ou que la stratégie de conformité n’est pas respectée au moment de la demande de renouvellement.

Selon le type d’application de messagerie que les employés utilisent pour accéder à Exchange Online, le chemin permettant d’établir un accès sécurisé à la messagerie peut être légèrement différent. Toutefois, les composants clés : ID Microsoft Entra, Office 365/Exchange Online et Intune sont les mêmes. L’expérience informatique et l’expérience utilisateur final sont également similaires.

Les clients qui tentent d’accéder à Office 365 seront évalués pour les propriétés suivantes :

• L’appareil est-il géré par un GPM ?
• L’appareil est-il inscrit avec l’ID Microsoft Entra ?
• L’appareil est-il conforme ?

Pour atteindre un état conforme, l’appareil Windows doit :

• Inscrivez-vous avec une solution MDM.
• Inscrivez-vous avec l’ID Microsoft Entra.
• Être conforme aux stratégies d’appareil définies par la solution MDM.

Remarque

À l’heure actuelle, les stratégies d’accès conditionnel sont appliquées de manière sélective sur les utilisateurs sur les appareils iOS et Android. Pour plus d’informations, consultez le billet de blog Microsoft Entra ID, Microsoft Intune et Windows - Utilisation du cloud pour moderniser la mobilité d’entreprise ! .

Contrôle d’accès conditionnel des applications cloud et locales

Le contrôle d’accès conditionnel est un puissant moteur d’évaluation de stratégie intégré à l’ID Microsoft Entra. Il offre aux professionnels de l’informatique un moyen simple de créer des règles d’accès au-delà d’Office 365 qui évaluent le contexte de connexion d’un utilisateur pour prendre des décisions en temps réel sur les applications auxquelles ils doivent être autorisés à accéder.

Les professionnels de l’informatique peuvent configurer des stratégies de contrôle d’accès conditionnel pour les applications SaaS cloud sécurisées par l’ID Microsoft Entra et même les applications locales. Les règles d’accès dans l’ID Microsoft Entra utilisent le moteur d’accès conditionnel pour vérifier l’état d’intégrité et de conformité de l’appareil signalé par une solution GPM compatible comme Intune afin de déterminer s’il faut autoriser l’accès.

Pour plus d’informations sur l’accès conditionnel, consultez Préversion de l’accès conditionnel Azure pour les applications SaaS.

Remarque

Le contrôle d’accès conditionnel est une fonctionnalité d’ID Microsoft Entra P1 ou P2 qui est également disponible avec EMS. Si vous n’avez pas d’abonnement Microsoft Entra ID P1 ou P2, vous pouvez obtenir un essai à partir du site Microsoft Azure .

Pour les applications locales, il existe deux options pour activer le contrôle d’accès conditionnel en fonction de l’état de conformité d’un appareil :

• Pour les applications locales publiées via le proxy d’application Microsoft Entra, vous pouvez configurer des stratégies de contrôle d’accès conditionnel comme vous le feriez pour les applications cloud. Pour plus d’informations, consultez Utilisation du proxy d’application Microsoft Entra pour publier des applications locales pour les utilisateurs distants.
• En outre, Microsoft Entra Connect synchronise les informations de conformité de l’appareil de l’ID Microsoft Entra avec AD local. ADFS sur Windows Server 2016 prend en charge le contrôle d’accès conditionnel en fonction de l’état de conformité d’un appareil. Les professionnels de l’informatique configurent des stratégies de contrôle d’accès conditionnel dans ADFS qui utilisent l’état de conformité de l’appareil signalé par une solution GPM compatible pour sécuriser les applications locales.

Le processus suivant décrit le fonctionnement de l’accès conditionnel Microsoft Entra :

1. L’utilisateur s’est déjà inscrit auprès de GPM via l’accès au lieu de travail/la jonction Azure AD, qui inscrit l’appareil avec l’ID Microsoft Entra.
2. Lorsque l’appareil démarre ou reprend à partir de la mise en veille prolongée, une tâche « Tpm-HASCertRetr » est déclenchée pour demander en arrière-plan un objet blob d’attestation d’intégrité. L’appareil envoie des mesures de démarrage TPM au service d’attestation d’intégrité.
3. Le service d’attestation d’intégrité valide l’état de l’appareil et émet un objet blob chiffré sur l’appareil en fonction de l’état d’intégrité avec des détails sur les vérifications ayant échoué (le cas échéant).
4. L’utilisateur ouvre une session et l’agent MDM contacte le serveur Intune/MDM.
5. Le serveur GPM pousse les nouvelles stratégies si elles sont disponibles et interroge l’état de l’objet blob d’intégrité et d’autres états d’inventaire.
6. L’appareil envoie un objet blob d’attestation d’intégrité précédemment acquis, ainsi que la valeur de l’autre inventaire d’état demandé par le serveur Intune/MDM.
7. Le serveur Intune/MDM envoie l’objet blob d’attestation d’intégrité au service d’attestation d’intégrité pour être validé.
8. Le service d’attestation d’intégrité vérifie que l’appareil qui a envoyé l’objet blob d’attestation d’intégrité est sain et retourne ce résultat au serveur Intune/MDM.
9. Le serveur Intune/GPM évalue la conformité en fonction de la conformité et de l’état d’inventaire/attestation d’intégrité interrogé de l’appareil.
10. Le serveur Intune/MDM met à jour l’état de conformité par rapport à l’objet d’appareil dans l’ID Microsoft Entra.
11. L’utilisateur ouvre l’application et tente d’accéder à une ressource gérée par l’entreprise.
12. Accès contrôlé par une revendication de conformité dans l’ID Microsoft Entra.
13. Si l’appareil est conforme et que l’utilisateur est autorisé, un jeton d’accès est généré.
14. L’utilisateur peut accéder à la ressource gérée par l’entreprise.

Pour plus d’informations sur la jonction Microsoft Entra, voir Microsoft Entra ID & Windows : Better Together for Work or School, a white paper.

Le contrôle d’accès conditionnel est un sujet que de nombreuses organisations et professionnels de l’informatique peuvent ne pas connaître et qu’ils devraient. Les différents attributs qui décrivent un utilisateur, un appareil, la conformité et le contexte d’accès sont puissants lorsqu’ils sont utilisés avec un moteur d’accès conditionnel. Le contrôle d’accès conditionnel est une étape essentielle qui aide les organisations à sécuriser leur environnement.

Plats à emporter et résumé

La liste suivante contient des points clés de haut niveau pour améliorer la posture de sécurité de toute organisation. Toutefois, les quelques points à retenir présentés dans cette section ne doivent pas être interprétés comme une liste exhaustive des meilleures pratiques de sécurité.

• Comprendre qu’aucune solution n’est 100 % sécurisée

  Si des adversaires déterminés ayant une intention malveillante obtiennent un accès physique à l’appareil, ils pourraient éventuellement briser ses couches de sécurité et le contrôler.

• Utiliser l’attestation d’intégrité avec une solution MDM

  L’intégrité des appareils qui tentent de se connecter à des ressources de grande valeur doit être évaluée afin que les appareils non sains et non conformes puissent être détectés, signalés et éventuellement bloqués.

• Utiliser Credential Guard

  Credential Guard est une fonctionnalité qui permet de protéger considérablement les informations d’identification du domaine d’entreprise contre les attaques pass-the-hash.

• Utiliser Device Guard

  Device Guard est une véritable avancée en matière de sécurité et un moyen efficace de vous protéger contre les programmes malveillants. La fonctionnalité Device Guard dans Windows bloque les applications non approuvées (applications non autorisées par votre organisation).

• Signer la stratégie Device Guard

  La stratégie Device Guard signée permet de se protéger contre un utilisateur disposant de privilèges d’administrateur qui tente d’échouer la stratégie actuelle. Lorsqu’une stratégie est signée, la seule façon de modifier Device Guard ultérieurement consiste à fournir une nouvelle version de la stratégie signée par le même signataire ou à partir d’un signataire spécifié dans le cadre de la stratégie Device Guard.

• Utiliser la sécurité basée sur la virtualisation

  Lorsque l’intégrité du code en mode noyau est protégée par la sécurité basée sur la virtualisation, les règles d’intégrité du code sont toujours appliquées même si une vulnérabilité autorise l’accès à la mémoire en mode noyau non autorisé. N’oubliez pas que les appareils Device Guard qui exécutent l’intégrité du code du noyau avec une sécurité basée sur la virtualisation doivent avoir des pilotes compatibles.

• Commencer à déployer Device Guard avec le mode Audit

  Déployez la stratégie Device Guard sur des ordinateurs et des appareils ciblés en mode Audit. Surveillez le journal des événements d’intégrité du code qui indique qu’un programme ou un pilote aurait été bloqué si Device Guard a été configuré en mode Application. Ajustez les règles Device Guard jusqu’à ce qu’un niveau de confiance élevé ait été atteint. Une fois la phase de test terminée, la stratégie Device Guard peut être basculée en mode d’application.

• Créer une machine de référence isolée lors du déploiement de Device Guard

  Étant donné que le réseau d’entreprise peut contenir des programmes malveillants, vous devez commencer à configurer un environnement de référence isolé de votre réseau d’entreprise principal. Après cela, vous pouvez créer une stratégie d’intégrité du code qui inclut les applications approuvées que vous souhaitez exécuter sur vos appareils protégés.

• Utiliser AppLocker quand cela est judicieux

  Bien qu’AppLocker ne soit pas considéré comme une nouvelle fonctionnalité Device Guard, il complète les fonctionnalités de Device Guard pour certains scénarios tels que la possibilité de refuser une application Windows universelle spécifique pour un utilisateur spécifique ou un groupe d’utilisateurs.

• Verrouiller le microprogramme et la configuration

  Une fois Windows installé, verrouillez l’accès aux options de démarrage du microprogramme. Ce verrouillage empêche un utilisateur disposant d’un accès physique de modifier les paramètres UEFI, de désactiver le démarrage sécurisé ou de démarrer d’autres systèmes d’exploitation. En outre, pour vous protéger contre la tentative d’un administrateur de désactiver Device Guard, ajoutez une règle dans la stratégie Device Guard actuelle qui refusera et bloquera l’exécution de l’outil C :\Windows\System32\SecConfig.efi .

L’attestation d’intégrité est une fonctionnalité clé de Windows qui inclut des composants client et cloud pour contrôler l’accès aux ressources de grande valeur en fonction de l’identité d’un utilisateur et de son appareil et de la conformité à la stratégie de gouvernance d’entreprise. Les organisations peuvent choisir de détecter et de signaler les appareils défectueux, ou de configurer des règles d’application d’intégrité en fonction de leurs besoins. L’attestation d’intégrité fournit un modèle de sécurité de bout en bout et des points d’intégration, que les fournisseurs et les développeurs de logiciels peuvent utiliser pour créer et intégrer une solution personnalisée.

Articles connexes

• Protéger les informations d’identification de domaine dérivées avec Credential Guard
• Guide de déploiement de Device Guard
• Vue d’ensemble de la technologie du module de plateforme sécurisée