sécurité basée sur la virtualisation (VBS)

La sécurité basée sur la virtualisation, ou VBS, utilise la virtualisation matérielle et l’hyperviseur Windows pour créer un environnement virtuel isolé qui devient la racine de confiance du système d’exploitation qui suppose que le noyau peut être compromis. Windows utilise cet environnement isolé pour héberger un certain nombre de solutions de sécurité, leur offrant une protection considérablement accrue contre les vulnérabilités dans le système d’exploitation et empêchant l’utilisation d’attaques malveillantes qui tentent de vaincre les protections. VBS applique des restrictions pour protéger les ressources vitales du système et du système d’exploitation, ou pour protéger les ressources de sécurité telles que les informations d’identification d’utilisateur authentifiées.

L’intégrité de la mémoire est un exemple de solution de sécurité, qui protège et renforce Windows en exécutant l’intégrité du code en mode noyau dans l’environnement virtuel isolé de VBS. L’intégrité du code en mode noyau est le processus Windows qui vérifie tous les pilotes et fichiers binaires en mode noyau avant leur démarrage, et empêche le chargement de fichiers système ou de pilotes non signés ou non approuvés dans la mémoire système. L’intégrité de la mémoire limite également les allocations de mémoire du noyau qui peuvent être utilisées pour compromettre le système, en veillant à ce que les pages mémoire du noyau ne soient rendues exécutables qu’après avoir passé des vérifications d’intégrité du code dans l’environnement d’exécution sécurisé, et que les pages exécutables elles-mêmes ne sont jamais accessibles en écriture. De cette façon, même s’il existe des vulnérabilités telles qu’un dépassement de mémoire tampon qui permettent aux programmes malveillants de tenter de modifier la mémoire, les pages de codes exécutables ne peuvent pas être modifiées et la mémoire modifiée ne peut pas être rendue exécutable.

Notes

L’intégrité de la mémoire est parfois appelée intégrité du code protégée par l’hyperviseur (HVCI) ou intégrité du code appliquée à l’hyperviseur, et a été initialement publiée dans le cadre de Device Guard. Device Guard n’est plus utilisé, sauf pour localiser l’intégrité de la mémoire et les paramètres VBS dans stratégie de groupe ou le Registre Windows.

VBS nécessite que les composants suivants soient présents et correctement configurés.

Notez que le module de plateforme sécurisée n’est pas obligatoire, mais nous vous recommandons vivement d’implémenter le module de plateforme sécurisée.

Configuration matérielle	Détails
Processeur 64 bits	La sécurité basée sur la virtualisation (VBS) nécessite l’hyperviseur Windows, qui est uniquement pris en charge sur les processeurs IA 64 bits avec des extensions de virtualisation, notamment Intel VT-X et AMD-v.
Traduction d’adresse de second niveau (SLAT, Second Level Address Translation)	VBS nécessite également que la prise en charge de la virtualisation du processeur inclue la traduction d’adresses de deuxième niveau (SLAT), Intel VT-X2 avec des tables de pages étendues (EPT) ou AMD-v avec l’indexation de virtualisation rapide (RVI).
IOMWU ou SMMUs (Intel VT-D, AMD-Vi, Arm64 SMMUs)	Tous les appareils d’E/S compatibles avec DMA doivent se trouver derrière un IOMMU ou un SMMU. Un IOMMU peut être utilisé pour améliorer la résilience du système contre les attaques de mémoire.
Trusted Platform Module (TPM) 2.0	Les TPM, discrets ou microprogrammes, suffiront. Pour plus d’informations, consultez Module de plateforme sécurisée (TPM) 2.0.
Prise en charge du microprogramme pour la protection SMM	Le microprogramme système doit respecter les recommandations de renforcement du code SMM décrites dans la spécification WMST (Security Mitigations Table) Windows SMM. La spécification WSMT contient les détails d’une table ACPI qui a été créée pour une utilisation avec les systèmes d’exploitation Windows qui prennent en charge les fonctionnalités VBS. Le microprogramme doit implémenter les protections décrites dans la spécification WSMT et définir les indicateurs de protection correspondants comme décrit dans la spécification pour signaler la conformité à ces exigences au système d’exploitation.
Rapports de mémoire UEFI (Unified Extensible Firmware Interface)	Le microprogramme UEFI doit respecter le format de création de rapports de carte mémoire et les instructions d’allocation de mémoire suivants pour que le microprogramme garantisse la compatibilité avec VBS. Table d’attributs de mémoire UEFI v2.6 (MAT) - Pour garantir la compatibilité avec VBS, le microprogramme doit séparer proprement les plages de mémoire du runtime EFI pour le code et les données, et signaler cela au système d’exploitation. La séparation et la création de rapports appropriés des plages de mémoire du runtime EFI permettent à VBS d’appliquer les protections de page nécessaires aux pages de code des services d’exécution EFI au sein de la région sécurisée VBS. La transmission de ces informations au système d’exploitation s’effectue à l’aide de la EFI_MEMORY_ATTRIBUTES_TABLE. Pour implémenter le MAT UEFI, suivez ces instructions : L’intégralité du runtime EFI doit être décrite dans ce tableau. Tous les attributs appropriés pour les pages EfiRuntimeServicesData et EfiRuntimeServicesCode doivent être marqués. Ces plages doivent être alignées sur les limites des pages (4 Ko) et ne peuvent pas se chevaucher. Protections de page EFI - Toutes les entrées doivent inclure des attributs EFI_MEMORY_RO, EFI_MEMORY_XP ou les deux. Toute la mémoire UEFI marquée comme exécutable doit être en lecture seule. La mémoire marquée comme accessible en écriture ne doit pas être exécutable. Les entrées ne peuvent être laissées avec aucun des attributs définis, ce qui indique que la mémoire est à la fois exécutable et accessible en écriture.
Demande de remplacement de mémoire sécurisée (MOR) révision 2	Le mor sécurisé v2 est amélioré pour protéger le paramètre de verrouillage MOR à l’aide d’une variable sécurisée UEFI. Cela permet de vous protéger contre les attaques de mémoire avancées. Pour plus d’informations, consultez Implémentation de mor sécurisé.
Pilotes compatibles avec l’intégrité de la mémoire	Vérifiez que tous les pilotes système ont été testés et vérifiés pour être compatibles avec l’intégrité de la mémoire. Le kit de pilotes Windows et le vérificateur de pilotes contiennent des tests de compatibilité des pilotes avec l’intégrité de la mémoire. Il existe trois étapes pour vérifier la compatibilité des pilotes : Utilisez Driver Verifier avec les vérifications de compatibilité de l’intégrité du code activées. Exécutez le test de préparation de l’intégrité du code de l’hyperviseur dans windows HLK. Testez le pilote sur un système avec VBS et l’intégrité de la mémoire activées. Cette étape est impérative pour valider le comportement du pilote avec l’intégrité de la mémoire, car les outils d’analyse du code statique ne sont tout simplement pas capables de détecter toutes les violations d’intégrité de la mémoire possibles au moment de l’exécution.

VBS fonctionne sur les machines virtuelles qui prennent en charge la virtualisation imbriquée. Cela inclut toutes les machines virtuelles Gen2 et les machines virtuelles Gen1 qui prennent en charge la virtualisation imbriquée. La liste des séries de machines virtuelles prises en charge est détaillée dans le tableau ci-dessous.

Nom de la série de machines virtuelles	Virtualisation imbriquée	VM Gen
Av2	Oui	1 (certaines tailles internes prennent en charge la génération 2)
B	Non	1 et 2
Dsv2/Dv2/Dv3/Ev3	Oui	1
Dsv3/Ddsv3	Oui	1 et 2
Dsv4/Ddsv4	Oui	1 et 2
Esv3/Edsv3	Oui	1 et 2
Esv4/Edsv4	Oui	1 et 2
Ev4/Edv4	Oui	Ev4 - 1 uniquement Edv4 -1&2
Dv4/Ddv4	Oui	1 et 2
Dv5/Ddv5/Dsv5/Ddsv5	Oui	1 et 2
Ev5/Edv5/Esv5/Edsv5	Oui	1 et 2
Dasv5/Dadsv5/Easv5/ Eadsv5	Oui	1 et 2
Ebsv5/Edbsv5	Oui	1 et 2
Fsv2	Oui	1 et 2
Fx	Oui	2
Lsv2	Oui	1 et 2

Rubriques connexes

Pour plus d’informations sur Hyper-V, consultez Hyper-V sur Windows Server 2016 ou Présentation d’Hyper-V sur Windows 10. Pour plus d’informations sur l’hyperviseur, consultez Spécifications de l’hyperviseur.