Guide de planification d’une structure protégée et de machines virtuelles protégées pour les hébergeurs

• S’applique à:

  ✅ Windows Server 2025, ✅ Windows Server 2022, ✅ Windows Server 2019, ✅ Windows Server 2016

Cette rubrique décrit les décisions de planification qui devront être prises pour permettre aux machines virtuelles protégées de s’exécuter sur votre infrastructure. Que vous mettiez à niveau une infrastructure Hyper-V existante ou que vous en créiez une, l’exécution de machines virtuelles protégées se compose de deux composants principaux :

• Le service Host Guardian (SGH) fournit une attestation et une protection des clés afin que vous puissiez vous assurer que les machines virtuelles protégées s’exécuteront uniquement sur des hôtes Hyper-V approuvés et sains. 
• Les hôtes Hyper-V approuvés et sains sur lesquels les machines virtuelles protégées (et les machines virtuelles régulières) peuvent s’exécuter sont appelés hôtes protégés.

Décision #1 : niveau de confiance dans l’infrastructure

La façon dont vous implémentez le service Host Guardian et les hôtes Hyper-V protégés dépend principalement de la force de confiance que vous cherchez à obtenir dans votre infrastructure. La force de confiance est régie par le mode d’attestation. Il existe deux options qui s’excluent mutuellement :

1. Attestation approuvée par le module de plateforme sécurisée (TPM)

   Si votre objectif est de protéger les machines virtuelles contre les administrateurs malveillants ou une infrastructure compromise, vous utiliserez l’attestation approuvée par TPM. Cette option fonctionne bien pour les scénarios d’hébergement multilocataire ainsi que pour les ressources à valeur élevée dans les environnements d’entreprise, tels que les contrôleurs de domaine ou les serveurs de contenu comme SQL ou SharePoint. Les stratégies d’intégrité du code protégées par l’hyperviseur (HVCI) sont mesurées et leur validité est appliquée par SGH avant que l’hôte ne soit autorisé à exécuter des machines virtuelles protégées.

2. Attestation de clé d’hôte

   Si vos besoins sont principalement déterminés par la conformité qui exige que les machines virtuelles soient chiffrées au repos et en cours d’exécution, vous utiliserez l’attestation de clé d’hôte. Cette option fonctionne bien pour les centres de données à usage général où vous êtes à l’aise avec les administrateurs d’infrastructure et d’hôte Hyper-V ayant accès aux systèmes d’exploitation invités des machines virtuelles pour la maintenance et les opérations quotidiennes.

   Dans ce mode, l’administrateur d’infrastructure est seul responsable de la garantie de l’intégrité des hôtes Hyper-V. Étant donné que SGH ne joue aucun rôle dans la décision de ce qui est ou n’est pas autorisé à s’exécuter, les programmes malveillants et les débogueurs fonctionnent comme prévu.

   Cependant, les débogueurs qui tentent de s’attacher directement à un processus (tels que WinDbg.exe), sont bloqués pour les machines virtuelles protégées, car le processus Worker de la machine virtuelle (VMWP.exe) est un PPL (Protected Process Light). Les autres techniques de débogage, telles que celles utilisées par LiveKd.exe, ne sont pas bloquées. Contrairement aux machines virtuelles protégées, le processus de travail pour les machines virtuelles prises en charge par le chiffrement ne s’exécute pas en tant que PPL, de sorte que les débogueurs traditionnels comme WinDbg.exe continueront à fonctionner normalement.

   Un mode d’attestation similaire nommé attestation de confiance Administration (basé sur Active Directory) est déconseillé à compter de Windows Server 2019.

Le niveau de confiance que vous choisissez détermine la configuration matérielle requise pour vos hôtes Hyper-V, ainsi que les stratégies que vous appliquez sur l’infrastructure. Si nécessaire, vous pouvez déployer votre infrastructure protégée à l’aide du matériel existant et de l’attestation approuvée par l’administrateur, puis la convertir en attestation approuvée par TPM lorsque le matériel a été mis à niveau et que vous devez renforcer la sécurité de l’infrastructure.

Décision #2 : infrastructure Hyper-V existante par rapport à une nouvelle infrastructure Hyper-V distincte

Si vous disposez d’une infrastructure existante (Hyper-V ou autre), il est très probable que vous puissiez l’utiliser pour exécuter des machines virtuelles protégées avec des machines virtuelles régulières. Certains clients choisissent d’intégrer des machines virtuelles protégées à leurs outils et infrastructures existants, tandis que d’autres les séparent pour des raisons professionnelles.

Planification de l’administrateur SGH pour le service Host Guardian

Déployez le service Host Guardian (SGH) dans un environnement hautement sécurisé, qu’il s’agisse d’un serveur physique dédié, d’une machine virtuelle protégée, d’une machine virtuelle sur un hôte Hyper-V isolé (séparé de l’infrastructure qu’il protège) ou d’un autre abonnement Azure.

Domaine	Détails
Configuration requise	Un serveur (cluster à trois nœuds recommandé pour la haute disponibilité) Pour le secours, au moins deux serveurs SGH sont requis Les serveurs peuvent être virtuels ou physiques (serveur physique avec TPM 2.0 recommandé ; TPM 1.2 également pris en charge) Installation de Server Core de Windows Server 2016 ou ultérieure Ligne de vision réseau vers l’infrastructure permettant la configuration HTTP ou de secours Certificat HTTPS recommandé pour la validation d’accès
Dimensionnement	Chaque nœud de serveur SGH de taille moyenne (8 cœurs/4 Go) peut gérer 1000 hôtes Hyper-V.
Gestion	Désignez des personnes spécifiques qui géreront le SGH. Elles doivent être séparées des administrateurs d’infrastructure. À titre de comparaison, les clusters SGH peuvent être considérés de la même manière qu’une autorité de certification en termes d’isolation administrative, de déploiement physique et de niveau global de confidentialité de la sécurité.
Active Directory du Service Guardian hôte	Par défaut, SGH installe son propre Active Directory interne pour la gestion. Il s’agit d’une forêt autonome et autogérée. Il s’agit de la configuration recommandée pour vous aider à isoler SGH de votre infrastructure. Si vous disposez déjà d’une forêt Active Directory hautement privilégiée que vous utilisez pour l’isolation, vous pouvez utiliser cette forêt au lieu de la forêt par défaut SGH. Il est important que SGH ne soit pas joint à un domaine dans la même forêt que les hôtes Hyper-V ou vos outils de gestion de structure. Cela pourrait permettre à un administrateur d’infrastructure de prendre le contrôle sur SGH.
Récupération d'urgence	Vous disposez de trois options : Installez un cluster SGH distinct dans chaque centre de données et autorisez les machines virtuelles protégées à s’exécuter dans les centres de données principaux et de sauvegarde. Cela évite d’avoir à étendre le cluster sur un WAN et vous permet d’isoler les machines virtuelles afin qu’elles s’exécutent uniquement dans leur site désigné. Installez SGH sur un cluster étendu entre deux centres de données (ou plus). Cela fournit une résilience si le WAN tombe en panne, mais repousse les limites du clustering de basculement. Vous ne pouvez pas isoler les charges de travail sur un seul site ; une machine virtuelle autorisée à s’exécuter dans un site peut s’exécuter sur n’importe quel autre site. Inscrivez votre hôte Hyper-V auprès d’un autre SGH en tant que basculement. Sauvegardez chaque serveur SGH en exportant sa configuration pour pouvoir toujours effectuer une récupération locale. Pour plus d’informations, consultez Export-HgsServerState et Import-HgsServerState.
Clés Service Guardian hôte	Un service Host Guardian utilise deux paires de clés asymétriques, une clé de chiffrement et une clé de signature, chacune représentée par un certificat SSL. Il existe deux options pour générer ces clés : Autorité de certification interne : vous pouvez générer ces clés à l’aide de votre infrastructure PKI interne. Cela convient à un environnement de centre de données. Autorités de certification approuvées publiquement : utilisez un ensemble de clés obtenues auprès d’une autorité de certification approuvée publiquement. Il s’agit de l’option que les hôtes doivent utiliser. Notez que s’il est possible d’utiliser des certificats auto-signés, cela n’est pas recommandé pour les scénarios de déploiement autres que les laboratoires de preuve de concept. En plus d’avoir des clés SGH, un hôte peut utiliser « apportez votre propre clé », où les locataires peuvent fournir leurs propres clés afin que certains (ou tous) les locataires puissent avoir leur propre clé SGH spécifique. Cette option convient aux hôtes qui peuvent fournir un processus hors bande permettant aux locataires de charger leurs clés.
Stockage de clés Service Guardian hôte	Pour une sécurité maximale, les clés SGH doivent être créées et stockées exclusivement dans un module de sécurité matériel (HSM). Si vous n’utilisez pas de HSM, il est vivement recommandé d’appliquer BitLocker sur les serveurs SGH.

Planification de l’administrateur d’infrastructure pour les hôtes protégés

Domaine	Détails
Matériel	Attestation de clé d’hôte : vous pouvez utiliser n’importe quel matériel existant en tant qu’hôte protégé. Il existe quelques exceptions (pour vous assurer que votre hôte peut utiliser de nouveaux mécanismes de sécurité à partir de Windows Server 2016, consultez Matériel compatible avec Windows Server 2016 protection de l’intégrité du code basée sur la virtualisation). Attestation approuvée par TPM : vous pouvez utiliser n’importe quel matériel doté de la qualification supplémentaire Hardware Assurance tant qu’il est configuré de manière appropriée (consultez Configurations de serveur conformes aux machines virtuelles protégées et protection basée sur la virtualisation de l’intégrité du code pour la configuration spécifique). Cela inclut TPM 2.0 et UEFI version 2.3.1c et ultérieures.
Système d''exploitation	Nous vous recommandons d’utiliser l’option Server Core pour le système d’exploitation hôte Hyper-V.
Impact sur les performances	En fonction des tests de performances, nous prévoyons une différence de densité d’environ 5 % entre l’exécution de machines virtuelles protégées et de machines virtuelles non protégées. Cela signifie que si un hôte Hyper-V donné peut exécuter 20 machines virtuelles non protégées, vous pouvez vous attendre à ce qu’il puisse exécuter 19 machines virtuelles protégées. Veillez à vérifier le dimensionnement avec vos charges de travail classiques. Par exemple, il peut y avoir des valeurs aberrantes avec des charges de travail d’E/S intensives orientées écriture qui affectent davantage la différence de densité.
Éléments à prendre en compte en matière de filiale	À partir de Windows Server version 1709, vous pouvez spécifier une URL de secours pour un serveur SGH virtualisé qui s’exécute localement en tant que machine virtuelle protégée dans la filiale. L’URL de secours peut être utilisée à chaque fois que la filiale perd la connectivité avec les serveurs SGH dans le centre de données. Sur les versions précédentes de Windows Server, un hôte Hyper-V s’exécutant dans une filiale a besoin d’une connectivité au service Host Guardian pour mettre sous tension ou pour migrer en direct des machines virtuelles protégées. Pour plus d’informations, consultez Considérations relatives aux filiales.