Configuration du service Guardian hôte

  • Article

S’applique à : Windows Server 2022, Windows Server 2019, Windows Server 2016

Le service Guardian hôte (SGH) est la pièce centrale de la solution de structure protégée. Il est chargé de s’assurer que les hôtes Hyper-V dans l’infrastructure sont connus de l’hébergeur ou de l’entreprise et qu’ils exécutent des logiciels approuvés. Ils sont également chargés de la gestion des clés utilisées pour démarrer des machines virtuelles dotées d’une protection maximale. Lorsqu’un locataire décide de vous approuver pour héberger ses machines virtuelles dotées d’une protection maximale, il fait confiance à votre configuration et à la gestion du SGH. Par conséquent, il est très important de suivre les meilleures pratiques lors de la gestion du SGH de sorte à garantir la sécurité, la disponibilité et la fiabilité de votre structure protégée. Les conseils présentés dans les sections suivantes traitent des problèmes opérationnels les plus courants auxquels sont confrontés les administrateurs de SGH.

Limitation de l’accès administrateur au SGH

En raison de la nature sensible à la sécurité du SGH, il est important de s’assurer que ses administrateurs sont des membres hautement approuvés de votre organisation et, dans l’idéal, distincts des administrateurs de vos ressources de structure. En outre, il est recommandé de gérer uniquement SGH à partir de stations de travail sécurisées à l’aide de protocoles de communication sécurisés, tels que WinRM pour HTTPS.

Séparation des tâches

Lors de la configuration du SGH, vous avez la possibilité de créer une forêt Active Directory isolée uniquement pour SGH ou de joindre le SGH à un domaine approuvé existant. Cette décision, ainsi que les rôles que vous attribuez aux administrateurs de votre organisation, déterminent la limite d’approbation pour le SGH. Toute personne disposant d’un accès au SGH, que ce soit directement en tant qu’administrateur ou indirectement en tant qu’administrateur d’un autre élément (p. ex., Active Directory) qui peut influencer le SGH, a le contrôle sur votre structure protégée. Les administrateurs SGH choisissent quels hôtes Hyper-V sont autorisés à exécuter des machines virtuelles dotées d’une protection maximale et à gérer les certificats nécessaires au démarrage des machines virtuelles dotées d’une protection maximale. Un attaquant ou un administrateur malveillant qui a accès au SGH peut utiliser cette puissance pour autoriser des hôtes compromis à exécuter des machines virtuelles dotées d’une protection maximale, lancer une attaque par déni de service en supprimant des éléments de clé, etc.

Pour éviter ce risque, il est vivement recommandé de limiter le chevauchement entre les administrateurs de votre SGH (y compris le domaine auquel SGH est joint) et les environnements Hyper-V. En s’assurant qu’aucun administrateur n’a accès aux deux systèmes, un attaquant devra compromettre deux comptes différents de deux personnes pour modifier les stratégies SGH. Cela signifie également que les administrateurs de domaine et d’entreprise pour les deux environnements Active Directory ne doivent pas être la même personne et que SGH ne doit pas utiliser la même forêt Active Directory que vos hôtes Hyper-V. Toute personne qui peut s’accorder l’accès à davantage de ressources présente un risque pour la sécurité.

Utilisation de Just Enough Administration

SGH est fourni avec des rôles JEA (Just Enough Administration) intégrés pour vous aider à le gérer de manière plus sécurisée. JEA vous permet de déléguer des tâches d’administration à des utilisateurs qui ne sont pas administrateurs, ce qui signifie que les personnes qui gèrent les stratégies SGH n’ont pas besoin d’être des administrateurs de l’ensemble de la machine ou du domaine. JEA fonctionne en limitant les commandes qu’un utilisateur peut exécuter dans une session PowerShell et en utilisant un compte local temporaire en arrière-plan (unique pour chaque session utilisateur) pour exécuter les commandes qui nécessitent normalement une élévation.

SGH est fourni avec les deux rôles JEA préconfigurés ci-dessous :

  • Administrateur SGH qui permet aux utilisateurs de gérer toutes les stratégies SGH, y compris l’autorisation des nouveaux hôtes à exécuter des machines virtuelles dotées d’une protection maximale.
  • Réviseur SGH qui autorise uniquement les utilisateurs à auditer les stratégies existantes. Ils ne peuvent pas modifier la configuration de SGH.

Pour utiliser JEA, vous devez d’abord créer un utilisateur standard et en faire un membre du groupe d’administrateurs ou de réviseurs SGH. Si vous avez l’habitude Install-HgsServer de configurer une nouvelle forêt pour SGH, ces groupes sont nommés respectivement « administrateurs nom_service » et « réviseurs nom_service », où nom_service est le nom réseau du cluster SGH. Si vous avez joint SGH à un domaine existant, vous devez faire référence aux noms de groupe que vous avez spécifiés dans Initialize-HgsServer.

Création d’utilisateurs standard pour les rôles d’administrateur et de réviseur SGH

$hgsServiceName = (Get-ClusterResource HgsClusterResource | Get-ClusterParameter DnsName).Value
$adminGroup = $hgsServiceName + "Administrators"
$reviewerGroup = $hgsServiceName + "Reviewers"

New-ADUser -Name 'hgsadmin01' -AccountPassword (Read-Host -AsSecureString -Prompt 'HGS Admin Password') -ChangePasswordAtLogon $false -Enabled $true
Add-ADGroupMember -Identity $adminGroup -Members 'hgsadmin01'

New-ADUser -Name 'hgsreviewer01' -AccountPassword (Read-Host -AsSecureString -Prompt 'HGS Reviewer Password') -ChangePasswordAtLogon $false -Enabled $true
Add-ADGroupMember -Identity $reviewerGroup -Members 'hgsreviewer01'

Audit des stratégies avec le rôle de réviseur

Sur une machine distante qui dispose d’une connectivité réseau au SGH, exécutez les commandes suivantes dans PowerShell pour entrer la session JEA avec les informations d’identification du réviseur. Il est important de noter que, étant donné que le compte réviseur n’est qu’un utilisateur standard, il ne peut pas être utilisé pour la communication à distance Windows PowerShell standard, l’accès Bureau à distance au SGH, etc.

Enter-PSSession -ComputerName <hgsnode> -Credential '<hgsdomain>\hgsreviewer01' -ConfigurationName 'microsoft.windows.hgs'

Vous pouvez ensuite vérifier les commandes autorisées dans la session avec Get-Command et exécuter toutes les commandes autorisées pour auditer la configuration. Dans l’exemple ci-dessous, nous vérifions quelles stratégies sont activées sur SGH.

Get-Command

Get-HgsAttestationPolicy

Saisissez la commande Exit-PSSession ou son alias, exit, lorsque vous avez terminé d’utiliser la session JEA.

Ajout d’une nouvelle stratégie à SGH à l’aide du rôle administrateur

Pour modifier réellement une stratégie, vous devez vous connecter au point de terminaison JEA avec une identité qui appartient au groupe « AdministrateursSGH ». Dans l’exemple ci-dessous, nous montrons comment copier une nouvelle stratégie d’intégrité du code dans SGH et l’inscrire à l’aide de JEA. La syntaxe peut être différente de celle dont vous avez l’habitude. Cela permet de s’adapter à certaines des restrictions de JEA, comme le fait de ne pas avoir accès au système de fichiers complet.

$cipolicy = Get-Item "C:\temp\cipolicy.p7b"
$session = New-PSSession -ComputerName <hgsnode> -Credential '<hgsdomain>\hgsadmin01' -ConfigurationName 'microsoft.windows.hgs'
Copy-Item -Path $cipolicy -Destination 'User:' -ToSession $session

# Now that the file is copied, we enter the interactive session to register it with HGS
Enter-PSSession -Session $session
Add-HgsAttestationCiPolicy -Name 'New CI Policy via JEA' -Path 'User:\cipolicy.p7b'

# Confirm it was added successfully
Get-HgsAttestationPolicy -PolicyType CiPolicy

# Finally, remove the PSSession since it is no longer needed
Exit-PSSession
Remove-PSSession -Session $session

Surveillance de SGH

Sources d’événements et transfert

Les événements de SGH s’affichent dans le journal des événements Windows sous deux sources :

  • HostGuardianService-Attestation
  • HostGuardianService-KeyProtection

Vous pouvez afficher ces événements en ouvrant l’observateur d'événements et en accédant à Microsoft-Windows-HostGuardianService-Attestation et Microsoft-Windows-HostGuardianService-KeyProtection.

Dans un environnement volumineux, il est souvent préférable de transférer des événements à un collecteur d’événements Windows central pour faciliter l’analyse des événements. Pour plus d’informations, consultez la documentation sur le transfert d’événements Windows.

Utilisation de System Center Operations Manager

Vous pouvez également utiliser System Center 2016 - Operations Manager pour surveiller SGH et vos hôtes protégés. Le pack d’administration d’infrastructure protégée dispose d’analyses d’événements pour vérifier les mauvaises configurations courantes pouvant entraîner un temps d’arrêt du centre de données, y compris les hôtes ne transmettant pas l’attestation et les serveurs SGH signalant des erreurs.

Pour commencer, installez et configurez SCOM 2016 et téléchargez le pack d’administration d’infrastructure protégée. Le guide du pack d’administration inclus explique comment configurer le pack d’administration et comprendre l’étendue de ses moniteurs.

Sauvegarde et restauration de SGH

Planification de la récupération d’urgence

Lors de la rédaction de vos plans de récupération d’urgence, il est important de prendre en compte les exigences uniques du service Guardian hôte dans votre infrastructure protégée. Si vous perdez certains ou tous vos nœuds SGH, vous pouvez rencontrer des problèmes de disponibilité immédiats qui empêchent les utilisateurs de démarrer leurs machines virtuelles dotées d’une protection maximale. Dans un scénario où vous perdez l’intégralité de votre cluster SGH, vous devez disposer de sauvegardes complètes de la configuration SGH pour restaurer votre cluster SGH et reprendre les opérations normales. Cette section décrit les étapes nécessaires à la préparation d’un tel scénario.

Tout d’abord, il est essentiel de comprendre ce qu’il est important de sauvegarder avec SGH. SGH conserve plusieurs informations qui l’aident à déterminer quels hôtes sont autorisés à exécuter des machines virtuelles dotées d’une protection maximale. notamment :

  1. Identificateurs de sécurité Active Directory pour les groupes contenant des hôtes approuvés (lors de l’utilisation de l’attestation Active Directory)
  2. Identificateurs de module de plateforme sécurisée (TPM) uniques pour chaque hôte de votre environnement
  3. Stratégies TPM pour chaque configuration unique de l’hôte
  4. Stratégies d’intégrité du code qui déterminent les logiciels autorisés à s’exécuter sur vos hôtes.

Ces artefacts d’attestation nécessitent une coordination avec les administrateurs de votre infrastructure d’hébergement, ce qui peut compliquer l’obtention de ces informations après un sinistre.

En outre, SGH nécessite l’accès à deux certificats ou plus utilisés pour chiffrer et signer les informations nécessaires au démarrage d’une machine virtuelle dotée d’une protection maximale (le protecteur de clé). Ces certificats sont bien connus (utilisés par les propriétaires de machines virtuelles dotées d’une protection maximale pour autoriser votre infrastructure à exécuter leurs machines virtuelles) et doivent être restaurés après un sinistre pour une expérience de récupération transparente. Si vous ne restaurez pas SGH avec les mêmes certificats après un sinistre, chaque machine virtuelle doit être mise à jour pour autoriser vos nouvelles clés à déchiffrer leurs informations. Pour des raisons de sécurité, seul le propriétaire de la machine virtuelle peut mettre à jour la configuration de cette dernière pour autoriser ces nouvelles clés, ce qui signifie que l’échec de la restauration de vos clés après un sinistre entraîne la nécessité pour chaque propriétaire de machine virtuelle de prendre des mesures pour que leurs machines virtuelles s’exécutent à nouveau.

Se préparer au pire

Pour vous préparer à une perte complète de SGH, vous devez suivre ces deux étapes :

  1. Sauvegarder les stratégies d’attestation SGH
  2. Sauvegarder les clés SGH

Des conseils sur la méthode d’exécution de ces deux étapes sont fournis dans la section Sauvegarde de SGH.

Il est également recommandé, mais pas obligatoire, de sauvegarder la liste des utilisateurs autorisés à gérer SGH dans son domaine Active Directory ou Active Directory lui-même.

Les sauvegardes doivent être effectuées régulièrement pour s’assurer que les informations sont à jour et stockées de manière sécurisée afin d’éviter toute falsification ou vol.

Il n’est pas recommandé de sauvegarder ou de tenter de restaurer une image système entière d’un nœud SGH. Si vous avez perdu l’intégralité de votre cluster, la meilleure pratique consiste à configurer un nouveau nœud SGH et à restaurer uniquement l’état SGH, et non l’ensemble du système d’exploitation du serveur.

Récupération après la perte d’un nœud

Si vous perdez un ou plusieurs nœuds (mais pas tous les nœuds) dans votre cluster SGH, vous pouvez simplement ajouter des nœuds à votre cluster en suivant les instructions du guide de déploiement. Les stratégies d’attestation sont synchronisées automatiquement, tout comme tous les certificats fournis à SGH en tant que fichiers PFX avec mots de passe associés. Pour les certificats ajoutés à SGH à l’aide d’une empreinte (certificats non exportables et matériels, généralement), vous devez vous assurer que chaque nouveau nœud a accès à la clé privée de chaque certificat.

Récupération après la perte de l’ensemble du cluster

Si l’ensemble de votre cluster SGH tombe en panne et que vous ne parvenez pas à le remettre en ligne, vous devez restaurer SGH à partir d’une sauvegarde. La restauration de SGH à partir d’une sauvegarde implique d’abord la configuration d’un nouveau cluster SGH conformément aux instructions du guide de déploiement. Il est fortement recommandé, mais pas obligatoire, d’utiliser le même nom de cluster lors de la configuration de l’environnement SGH de récupération pour faciliter la résolution de noms à partir d’hôtes. L’utilisation du même nom évite d’avoir à reconfigurer les hôtes avec de nouvelles URL d’attestation et de protection de clé. Si vous avez restauré des objets dans le domaine Active Directory qui sauvegarde SGH, il est recommandé de supprimer les objets représentant le cluster SGH, les ordinateurs, le compte de service et les groupes JEA avant d’initialiser le serveur SGH.

Une fois que vous avez configuré votre premier nœud SGH (p. ex., il a été installé et initialisé), suivez les procédures sous Restaurer SGH à partir d’une sauvegarde pour restaurer les stratégies d’attestation et les moitiés publiques des certificats de protection de clé. Vous devez restaurer manuellement les clés privées de vos certificats selon les instructions de votre fournisseur de certificats (p. ex., importer le certificat dans Windows ou configurer l’accès aux certificats HSM). Une fois le premier nœud configuré, vous pouvez continuer à installer des nœuds supplémentaires sur le cluster jusqu’à ce que vous ayez atteint la capacité et la résilience souhaitées.

Sauvegarde de SGH

L’administrateur SGH doit être responsable de la sauvegarde de SGH sur une base régulière. Une sauvegarde complète contient du matériel de clé sensible qui doit être correctement sécurisé. Si une entité non approuvée accède à ces clés, elle peut utiliser ce matériel pour configurer un environnement SGH malveillant dans le but de compromettre les machines virtuelles dotées d’une protection maximale.

Sauvegarde des stratégies d’attestation Pour sauvegarder les stratégies d’attestation SGH, exécutez la commande suivante sur n’importe quel nœud de serveur SGH opérationnel. Vous serez invité à fournir un mot de passe pour cet utilisateur. Ce mot de passe est utilisé pour chiffrer tous les certificats ajoutés à SGH à l’aide d’un fichier PFX (au lieu d’une empreinte de certificat).

Export-HgsServerState -Path C:\temp\HGSBackup.xml

Notes

Si vous utilisez l’attestation approuvée par l’administrateur, vous devez sauvegarder séparément l’appartenance aux groupes de sécurité utilisés par SGH pour autoriser les hôtes protégés. SGH sauvegarde uniquement le SID des groupes de sécurité, et non l’appartenance à ceux-ci. Si ces groupes sont perdus lors d’un sinistre, vous devez recréer le ou les groupes et y ajouter à nouveau chaque hôte protégé.

Sauvegarde de certificats

La commande Export-HgsServerState sauvegardera tous les certificats PFX ajoutés à SGH au moment de l’exécution de la commande. Si vous avez ajouté des certificats à SGH à l’aide d’une empreinte (généralement pour les certificats non exportables et matériels), vous devrez sauvegarder manuellement les clés privées de vos certificats. Pour identifier les certificats inscrits auprès de SGH et qui doivent être sauvegardés manuellement, exécutez la commande PowerShell suivante sur n’importe quel nœud serveur SGH opérationnel.

Get-HgsKeyProtectionCertificate | Where-Object { $_.CertificateData.GetType().Name -eq 'CertificateReference' } | Format-Table Thumbprint, @{ Label = 'Subject'; Expression = { $_.CertificateData.Certificate.Subject } }

Pour chacun des certificats répertoriés, vous devez sauvegarder manuellement la clé privée. Si vous utilisez un certificat logiciel non exportable, contactez votre autorité de certification pour vous assurer qu’elle dispose d’une sauvegarde de votre certificat et/ou peut le réémettre à la demande. Pour les certificats créés et stockés dans des modules de sécurité matériels, vous devez consulter la documentation de votre appareil pour obtenir des conseils sur la planification de la récupération d’urgence.

Vous devez stocker les sauvegardes de certificat en même temps que vos sauvegardes de stratégie d’attestation dans un emplacement sécurisé afin que les deux éléments puissent être restaurés ensemble.

Configuration supplémentaire à sauvegarder

L’état du serveur SGH sauvegardé n’inclut pas le nom de votre cluster SGH, les informations d’Active Directory ou les certificats SSL utilisés pour sécuriser les communications avec les API SGH. Ces paramètres sont importants pour la cohérence, mais pas pour que votre cluster SGH soit de nouveau en ligne après un sinistre.

Pour capturer le nom du service SGH, exécutez Get-HgsServer et notez le nom plat dans les URL d’attestation et de protection de clé. Par exemple, si l’URL d’attestation est « https://hgs.contoso.com/Attestation », « SGH » est le nom du service SGH.

Le domaine Active Directory utilisé par SGH doit être géré comme n’importe quel autre domaine Active Directory. Lors de la restauration du SGH après un sinistre, vous n’aurez pas nécessairement besoin de recréer les objets exacts présents dans le domaine actuel. Toutefois, la récupération sera plus facile si vous sauvegardez Active Directory et conservez une liste des utilisateurs JEA autorisés à gérer le système, ainsi que l’appartenance à tous les groupes de sécurité utilisés par l’attestation approuvée par l’administrateur pour autoriser les hôtes protégés.

Pour identifier l’empreinte des certificats SSL configurés pour SGH, exécutez la commande suivante dans PowerShell. Vous pouvez ensuite sauvegarder ces certificats SSL en fonction des instructions de votre fournisseur de certificats.

Get-WebBinding -Protocol https | Select-Object certificateHash

Restauration de SGH à partir d’une sauvegarde

Les étapes suivantes décrivent comment restaurer les paramètres SGH à partir d’une sauvegarde. Les étapes sont pertinentes pour les deux situations où vous essayez d’annuler les modifications apportées à vos instances SGH déjà en cours d’exécution et lorsque vous mettez en place un tout nouveau cluster SGH après une perte complète de votre précédent.

Configurer un cluster SGH de remplacement

Avant de pouvoir restaurer SGH, vous devez disposer d’un cluster SGH initialisé sur lequel vous pouvez restaurer la configuration. Si vous importez simplement des paramètres qui ont été accidentellement supprimés dans un cluster existant (en cours d’exécution), vous pouvez ignorer cette étape. Si vous récupérez après une perte complète de SGH, vous devez installer et initialiser au moins un nœud SGH en suivant les instructions du guide de déploiement.

Plus précisément, vous devez :

  1. Configurer le domaine SGH ou joindre SGH à un domaine existant
  2. Initialiser le serveur SGH à l’aide de vos clés existantes ou d’un ensemble de clés temporaires. Vous pouvez supprimer les clés temporaires après avoir importé vos clés réelles à partir des fichiers de sauvegarde SGH.
  3. Importer les paramètres SGH à partir de votre sauvegarde pour restaurer les groupes hôtes approuvés, les stratégies d’intégrité du code, les bases de référence TPM et les identificateurs TPM approuvés

Conseil

Le nouveau cluster SGH n’a pas besoin d’utiliser les mêmes certificats, le même nom de service ou de domaine que l’instance SGH à partir de laquelle votre fichier de sauvegarde a été exporté.

Importation des paramètres à partir d’une sauvegarde

Pour restaurer des stratégies d’attestation, des certificats PFX et les clés publiques des certificats non PFX sur votre nœud SGH à partir d’un fichier de sauvegarde, exécutez la commande suivante sur un nœud serveur SGH initialisé. Vous serez invité à saisir le mot de passe que vous avez spécifié lors de la création de la sauvegarde.

Import-HgsServerState -Path C:\Temp\HGSBackup.xml

Si vous souhaitez uniquement importer des stratégies d’attestation approuvées par l’administrateur ou des stratégies d’attestation approuvées par TPM, vous pouvez le faire en spécifiant les indicateurs -ImportActiveDirectoryModeState ou -ImportTpmModeState dans Import-HgsServerState.

Vérifiez que la dernière mise à jour cumulative pour Windows Server 2016 est installée avant d’exécuter Import-HgsServerState. Si vous ne le faites pas, une erreur d’importation peut se produire.

Notes

Si vous restaurez des stratégies sur un nœud SGH existant sur lequel une ou plusieurs de ces stratégies sont déjà installées, la commande d’importation affiche une erreur pour chaque stratégie en double. Il s’agit d’un comportement attendu qui peut être ignoré en toute sécurité dans la plupart des cas.

Réinstallation des clés privées pour les certificats

Si l’un des certificats utilisés sur le SGH à partir duquel la sauvegarde a été créée a été ajouté à l’aide d’empreintes numériques, seule la clé publique de ces certificats sera incluse dans le fichier de sauvegarde. Cela signifie que vous devez installer manuellement et/ou accorder l’accès aux clés privées pour chacun de ces certificats avant que SGH puisse traiter les demandes provenant d’hôtes Hyper-V. Les actions nécessaires pour effectuer cette étape varient en fonction de la façon dont votre certificat a été émis à l’origine. Pour les certificats logiciels émis par une autorité de certification, vous devez contacter votre autorité de certification pour obtenir la clé privée et l’installer sur chaque nœud SGH en fonction de leurs instructions. De même, si vos certificats sont sauvegardés sur le matériel, vous devez consulter la documentation du fournisseur de votre module de sécurité matérielle pour installer le ou les pilotes nécessaires sur chaque nœud SGH pour vous connecter au HSM et accorder à chaque machine l’accès à la clé privée.

Pour rappel, les certificats ajoutés à SGH à l’aide d’empreintes nécessitent une réplication manuelle des clés privées sur chaque nœud. Vous devez répéter cette étape sur chaque nœud supplémentaire que vous ajoutez au cluster SGH restauré.

Passage en revue des stratégies d’attestation importées

Une fois que vous avez importé vos paramètres à partir d’une sauvegarde, il est recommandé d’examiner attentivement toutes les stratégies importées à l’aide de Get-HgsAttestationPolicy pour vous assurer que seuls les hôtes auxquels vous faites confiance pour exécuter des machines virtuelles dotées d’une protection maximale seront en mesure d’attester avec succès. Si vous trouvez des stratégies qui ne correspondent plus à votre posture de sécurité, vous pouvez les désactiver ou les supprimer.

Exécution des diagnostics pour vérifier l’état du système

Une fois que vous avez terminé la configuration et la restauration de l’état de votre nœud SGH, vous devez exécuter l’outil de diagnostic SGH pour vérifier l’état du système. Pour ce faire, exécutez la commande suivante sur le nœud SGH où vous avez restauré la configuration :

Get-HgsTrace -RunDiagnostics

Si le « Résultat global » n’est pas « Pass », des étapes supplémentaires sont nécessaires pour terminer la configuration du système. Pour plus d’informations, vérifiez les messages signalés dans les sous-tests qui ont échoué.

Mise à jour corrective de SGH

Il est important de maintenir vos nœuds du service Guardian hôte à jour en installant la dernière mise à jour cumulative lors de sa sortie. Si vous configurez un nouveau nœud SGH, il est vivement recommandé d’installer toutes les mises à jour disponibles avant d’installer le rôle SGH ou de le configurer. Cela garantit que toutes les fonctionnalités nouvelles ou modifiées prendront effet immédiatement.

Lors de la mise à jour corrective de votre infrastructure protégée, il est fortement recommandé de commencer par mettre à niveau tous les hôtes Hyper-V avant de mettre à niveau SGH. Cela permet de s’assurer que toutes les modifications apportées aux stratégies d’attestation sur SGH sont effectuées une fois que les hôtes Hyper-V ont été mis à jour afin de fournir les informations nécessaires pour eux. Si une mise à jour change le comportement des stratégies, elles ne sont pas automatiquement activées pour éviter d’interrompre votre infrastructure. Ces mises à jour nécessitent que vous suiviez les instructions de la section suivante pour activer les stratégies d’attestation nouvelles ou modifiées. Nous vous encourageons à lire les notes de publication de Windows Server et les mises à jour cumulatives que vous installez pour vérifier si les mises à jour de stratégie sont requises.

Mises à jour nécessitant l’activation de la stratégie

Si une mise à jour pour SGH introduit ou modifie de manière significative le comportement d’une stratégie d’attestation, une étape supplémentaire est nécessaire pour activer la stratégie modifiée. Les modifications de stratégie ne sont appliquées qu’après l’exportation et l’importation de l’état SGH. Vous ne devez activer les stratégies nouvelles ou modifiées qu’après avoir appliqué la mise à jour cumulative à tous les hôtes et à tous les nœuds SGH de votre environnement. Une fois que chaque ordinateur a été mis à jour, exécutez les commandes suivantes sur n’importe quel nœud SGH pour déclencher le processus de mise à niveau :

$password = Read-Host -AsSecureString -Prompt "Enter a temporary password"
Export-HgsServerState -Path .\temporaryExport.xml -Password $password
Import-HgsServerState -Path .\temporaryExport.xml -Password $password

Si une nouvelle stratégie a été introduite, elle est désactivée par défaut. Pour activer la nouvelle stratégie, recherchez-la d’abord dans la liste des stratégies Microsoft (avec le préfixe « SGH_ ») puis activez-la à l’aide des commandes suivantes :

Get-HgsAttestationPolicy

Enable-HgsAttestationPolicy -Name <Hgs_NewPolicyName>

Gestion des stratégies d’attestation

SGH gère plusieurs stratégies d’attestation qui définissent l’ensemble minimal de conditions requises qu’un hôte doit respecter pour être considéré comme « sain » et autorisé à exécuter des machines virtuelles dotées d’une protection maximale. Certaines de ces stratégies sont définies par Microsoft, d’autres sont ajoutées par vous pour définir les stratégies d’intégrité du code autorisées, les bases de référence TPM et les hôtes dans votre environnement. Une maintenance régulière de ces stratégies est nécessaire pour s’assurer que les hôtes peuvent continuer à attester correctement à mesure que vous les mettez à jour et les remplacez, et pour garantir que les hôtes ou configurations non approuvés ne sont pas autorisés à attester correctement.

Pour l’attestation approuvée par l’administrateur, il n’existe qu’une seule stratégie qui détermine si un hôte est sain, à savoir, l’appartenance à un groupe de sécurité connu et approuvé. L’attestation TPM est plus compliquée et implique différentes stratégies pour mesurer le code et la configuration d’un système avant de déterminer s’il est sain.

Un SGH unique peut être configuré à la fois avec des stratégies Active Directory et TPM, mais le service vérifie uniquement les stratégies pour le mode actuel pour lequel il est configuré lorsqu’un hôte tente d’attester. Pour vérifier le mode de votre serveur SGH, exécutez Get-HgsServer.

Stratégies par défaut

Pour l’attestation approuvée par TPM, plusieurs stratégies intégrées sont configurées sur SGH. Certaines de ces stratégies sont « verrouillées », ce qui signifie qu’elles ne peuvent pas être désactivées pour des raisons de sécurité. Le tableau ci-dessous explique l’objectif de chaque stratégie par défaut.

Nom de la stratégie Objectif
Hgs_SecureBootEnabled Nécessite que le démarrage sécurisé soit activé sur les hôtes. Cela est nécessaire pour mesurer les fichiers binaires de démarrage et d’autres paramètres verrouillés par UEFI.
Hgs_UefiDebugDisabled Garantit que les hôtes n’ont pas de débogueur de noyau activé. Les débogueurs en mode utilisateur sont bloqués avec des stratégies d’intégrité du code.
Hgs_SecureBootSettings Stratégie négative pour s’assurer que les hôtes correspondent à au moins une base de référence TPM (définie par l’administrateur).
Hgs_CiPolicy Stratégie négative pour garantir que les hôtes utilisent l’une des stratégies CI définies par l’administrateur.
Hgs_HypervisorEnforcedCiPolicy Nécessite que la stratégie d’intégrité du code soit appliquée par l’hyperviseur. La désactivation de cette stratégie affaiblit vos protections contre les attaques de stratégie d’intégrité du code en mode noyau.
Hgs_FullBoot Garantit que l’hôte n’a pas repris de veille ou de mise en veille prolongée. Les hôtes doivent être correctement redémarrés ou arrêtés pour passer cette stratégie.
Hgs_VsmIdkPresent Nécessite l’exécution de la sécurité basée sur la virtualisation sur l’hôte. L’IDK représente la clé nécessaire pour chiffrer les informations renvoyées à l’espace mémoire sécurisé de l’hôte.
Hgs_PageFileEncryptionEnabled Nécessite que les fichiers de page soient chiffrés sur l’hôte. La désactivation de cette stratégie peut entraîner une exposition d’informations si un fichier de page non chiffré est inspecté à la recherche de secrets de locataire.
Hgs_BitLockerEnabled Nécessite que BitLocker soit activé sur l’hôte Hyper-V. Cette stratégie est désactivée par défaut pour des raisons de performances et il n’est pas recommandé d’activer cette stratégie. Cette stratégie n’a aucune incidence sur le chiffrement des machines virtuelles dotées d’une protection maximale.
Hgs_IommuEnabled Nécessite que l’hôte dispose d’un appareil IOMMU en cours d’utilisation pour empêcher les attaques d’accès direct à la mémoire. La désactivation de cette stratégie et l’utilisation d’hôtes sans IOMMU activé peuvent exposer des secrets de machine virtuelle client à des attaques de mémoire directes.
Hgs_NoHibernation Nécessite la désactivation de la mise en veille prolongée sur l’hôte Hyper-V. La désactivation de cette stratégie peut permettre aux hôtes d’enregistrer la mémoire de machine virtuelle protégée dans un fichier de mise en veille prolongée non chiffré.
Hgs_NoDumps Nécessite que les vidages de mémoire soient désactivés sur l’hôte Hyper-V. Si vous désactivez cette stratégie, il est recommandé de configurer le chiffrement de vidage pour empêcher l’enregistrement de la mémoire de machine virtuelle protégée dans des fichiers de vidage sur incident non chiffrés.
Hgs_DumpEncryption Nécessite que les vidages de mémoire, s’ils sont activés sur l’hôte Hyper-V, soient chiffrés avec une clé de chiffrement approuvée par SGH. Cette stratégie ne s’applique pas si les vidages ne sont pas activés sur l’hôte. Si cette stratégie et Hgs_NoDumps sont tous les deux désactivés, la mémoire de machine virtuelle protégée peut être enregistrée dans un fichier de vidage non chiffré.
Hgs_DumpEncryptionKey Stratégie négative pour s’assurer que les hôtes configurés pour autoriser les vidages de mémoire utilisent une clé de chiffrement de fichier de vidage définie par l’administrateur connue de SGH. Cette stratégie ne s’applique pas lorsque Hgs_DumpEncryption est désactivé.

Autorisation de nouveaux hôtes protégés

Pour autoriser un nouvel hôte à devenir un hôte protégé (par exemple, attester avec succès), SGH doit approuver l’hôte et (lorsqu’il est configuré pour utiliser l’attestation approuvée par le module de plateforme sécurisée) le logiciel qui s’exécute sur celui-ci. Les étapes d’autorisation d’un nouvel hôte diffèrent en fonction du mode d’attestation pour lequel SGH est actuellement configuré. Pour vérifier le mode d’attestation de votre infrastructure protégée, exécutez Get-HgsServer sur n’importe quel nœud SGH.

Configuration logicielle

Sur le nouvel hôte Hyper-V, vérifiez que Windows Server 2016 édition Datacenter est installée. Windows Server 2016 Standard ne peut pas exécuter de machines virtuelles dotées d’une protection maximale dans une infrastructure protégée. L’hôte peut être installé Expérience utilisateur ou Server Core.

Sur le serveur avec expérience de bureau et Server Core, vous devez installer les rôles serveur de support Hyper-V et Host Guardian Hyper-V :

Install-WindowsFeature Hyper-V, HostGuardian -IncludeManagementTools -Restart

Attestation approuvée par l’administrateur

Pour inscrire un nouvel hôte dans SGH lors de l’utilisation de l’attestation approuvée par l’administrateur, vous devez d’abord ajouter l’hôte à un groupe de sécurité dans le domaine auquel il est joint. En règle générale, chaque domaine a un groupe de sécurité pour les hôtes protégés. Si vous avez déjà inscrit ce groupe auprès de SGH, la seule action que vous devez effectuer consiste à redémarrer l’hôte pour actualiser son appartenance au groupe.

Vous pouvez vérifier les groupes de sécurité approuvés par SGH en exécutant la commande suivante :

Get-HgsAttestationHostGroup

Pour inscrire un nouveau groupe de sécurité auprès de SGH, commencez par capturer l’identificateur de sécurité (SID) du groupe dans le domaine de l’hôte, puis inscrivez-le auprès de SGH.

Add-HgsAttestationHostGroup -Name "Contoso Guarded Hosts" -Identifier "S-1-5-21-3623811015-3361044348-30300820-1013"

Des instructions relatives à la manière de configurer l’approbation entre le domaine hôte et SGH sont disponibles dans le guide de déploiement.

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

Lorsque SGH est configuré en mode TPM, les hôtes doivent passer toutes les stratégies verrouillées et les stratégies « activées » avec le préfixe « SGH_ », ainsi qu’au moins une ligne de base de module de plateforme sécurisée, un identificateur TPM et une stratégie d’intégrité du code. Chaque fois que vous ajoutez un nouvel hôte, vous devez inscrire le nouvel identificateur TPM auprès de SGH. Tant que l’hôte exécute le même logiciel (et a la même stratégie d’intégrité du code appliquée) et la même base de référence TPM qu’un autre hôte dans votre environnement, vous n’avez pas besoin d’ajouter de nouvelles stratégies d’intégration continue ou de nouvelles bases de référence.

Ajout de l’identificateur TPM pour un nouvel hôte Sur le nouvel hôte, exécutez la commande suivante pour capturer l’identificateur TPM. Veillez à spécifier un nom unique pour l’hôte qui vous aidera à le rechercher sur SGH. Vous aurez besoin de ces informations si vous désaffectez l’hôte ou si vous souhaitez l’empêcher d’exécuter des machines virtuelles dotées d’une protection maximale dans SGH.

(Get-PlatformIdentifier -Name "Host01").InnerXml | Out-File C:\temp\host01.xml -Encoding UTF8

Copiez ce fichier sur votre serveur SGH, puis exécutez la commande suivante pour inscrire l’hôte auprès de SGH.

Add-HgsAttestationTpmHost -Name 'Host01' -Path C:\temp\host01.xml

Ajout d’une nouvelle ligne de base de plateforme sécurisée (TPM) Si le nouvel hôte exécute une nouvelle configuration de matériel ou de microprogramme pour votre environnement, vous devrez peut-être utiliser une nouvelle base de référence TPM. Pour cela, exécutez la commande suivante sur chaque hôte :

Get-HgsAttestationBaselinePolicy -Path 'C:\temp\hardwareConfig01.tcglog'

Notes

Si vous recevez une erreur indiquant que votre hôte n’a pas réussi la validation et n’atteste pas correctement, ne vous inquiétez pas. Il s’agit d’une vérification des prérequis pour vous assurer que votre hôte peut exécuter des machines virtuelles dotées d’une protection maximale, ce qui signifie probablement que vous n’avez pas encore appliqué de stratégie d’intégrité du code ou d’autre paramètre requis. Lisez le message d’erreur, apportez les modifications suggérées par celui-ci, puis réessayez. Vous pouvez également ignorer la validation à ce stade en ajoutant l’indicateur -SkipValidation à la commande.

Copiez la base de référence TPM sur votre serveur SGH, puis inscrivez-la avec la commande suivante. Nous vous encourageons à utiliser une convention d’affectation de noms qui vous aide à comprendre la configuration du matériel et du microprogramme de cette classe d’hôte Hyper-V.

Add-HgsAttestationTpmPolicy -Name 'HardwareConfig01' -Path 'C:\temp\hardwareConfig01.tcglog'

Ajout d’une nouvelle stratégie d’intégrité du code Si vous avez modifié la stratégie d’intégrité du code en cours d’exécution sur vos hôtes Hyper-V, vous devez inscrire la nouvelle stratégie auprès de SGH pour que ces hôtes puissent attester correctement. Sur un hôte de référence, qui sert d’image maître pour les machines Hyper-V approuvées dans votre environnement, capturez une nouvelle stratégie CI à l’aide de la commande New-CIPolicy. Nous vous encourageons à utiliser le niveau FilePublisher et le hachage de secours pour les stratégies CI de l’hôte Hyper-V. Vous devez d’abord créer une stratégie CI en mode audit pour vous assurer que tout fonctionne comme prévu. Après avoir validé un exemple de charge de travail sur le système, vous pouvez appliquer la stratégie et copier la version appliquée dans SGH. Pour obtenir la liste complète des options de configuration de la stratégie d’intégrité du code, consultez la documentation Device Guard.

# Capture a new CI policy with the FilePublisher primary level and Hash fallback and enable user mode code integrity protections
New-CIPolicy -FilePath 'C:\temp\ws2016-hardware01-ci.xml' -Level FilePublisher -Fallback Hash -UserPEs

# Apply the CI policy to the system
ConvertFrom-CIPolicy -XmlFilePath 'C:\temp\ws2016-hardware01-ci.xml' -BinaryFilePath 'C:\temp\ws2016-hardware01-ci.p7b'
Copy-Item 'C:\temp\ws2016-hardware01-ci.p7b' 'C:\Windows\System32\CodeIntegrity\SIPolicy.p7b'
Restart-Computer

# Check the event log for any untrusted binaries and update the policy if necessary
# Consult the Device Guard documentation for more details

# Change the policy to be in enforced mode
Set-RuleOption -FilePath 'C:\temp\ws2016-hardare01-ci.xml' -Option 3 -Delete

# Apply the enforced CI policy on the system
ConvertFrom-CIPolicy -XmlFilePath 'C:\temp\ws2016-hardware01-ci.xml' -BinaryFilePath 'C:\temp\ws2016-hardware01-ci.p7b'
Copy-Item 'C:\temp\ws2016-hardware01-ci.p7b' 'C:\Windows\System32\CodeIntegrity\SIPolicy.p7b'
Restart-Computer

Une fois votre stratégie créée, testée et appliquée, copiez le fichier binaire (.p7b) sur votre serveur SGH et inscrivez la stratégie.

Add-HgsAttestationCiPolicy -Name 'WS2016-Hardware01' -Path 'C:\temp\ws2016-hardware01-ci.p7b'

Ajout d’une clé de chiffrement de vidage de mémoire

Lorsque la stratégie Hgs_NoDumps est désactivée et que la stratégie Hgs_DumpEncryption est activée, les hôtes protégés sont autorisés à avoir des vidages de mémoire (y compris les vidages sur incident) à activer tant que ces vidages sont chiffrés. Les hôtes protégés ne passent l’attestation que s’ils ont des vidages de mémoire désactivés ou s’ils les chiffrent avec une clé connue de SGH. Par défaut, aucune clé de chiffrement de vidage n’est configurée sur SGH.

Pour ajouter une clé de chiffrement de vidage à SGH, utilisez l’applet de commande Add-HgsAttestationDumpPolicy pour fournir à SGH le hachage de votre clé de chiffrement de vidage. Si vous capturez un planning de référence TPM sur un hôte Hyper-V configuré avec le chiffrement de vidage, le hachage est inclus dans le tcglog et peut être fourni à l’applet de commande Add-HgsAttestationDumpPolicy.

Add-HgsAttestationDumpPolicy -Name 'DumpEncryptionKey01' -Path 'C:\temp\TpmBaselineWithDumpEncryptionKey.tcglog'

Vous pouvez également fournir directement la représentation sous forme de chaîne du hachage à l’applet de commande.

Add-HgsAttestationDumpPolicy -Name 'DumpEncryptionKey02' -PublicKeyHash '<paste your hash here>'

Veillez à ajouter chaque clé de chiffrement de vidage unique à SGH si vous choisissez d’utiliser différentes clés dans votre infrastructure protégée. Les hôtes qui chiffrent des vidages de mémoire avec une clé non connue de SGH ne passeront pas l’attestation.

Pour plus d’informations sur la configuration du chiffrement de vidage sur les hôtes, consultez la documentation Hyper-V.

Vérifier si le système a réussi l’attestation

Après avoir inscrit les informations nécessaires auprès de SGH, vous devez vérifier si l’hôte réussit l’attestation. Sur l’hôte Hyper-V nouvellement ajouté, exécutez Set-HgsClientConfiguration et fournissez les URL appropriées pour votre cluster SGH. Ces URL peuvent être obtenues en exécutant Get-HgsServer sur n’importe quel nœud SGH.

Set-HgsClientConfiguration -KeyProtectionServerUrl 'https://hgs.bastion.local/KeyProtection' -AttestationServerUrl 'https://hgs.bastion.local/Attestation'

Si l’état résultant n’indique pas « IsHostGuarded : True », vous devez résoudre les problèmes de configuration. Sur l’hôte qui a échoué à l’attestation, exécutez la commande suivante pour obtenir un rapport détaillé sur les problèmes qui peuvent vous aider à résoudre l’attestation ayant échoué.

Get-HgsTrace -RunDiagnostics -Detailed

Important

Si vous utilisez Windows Server 2019 ou Windows 10, version 1809 et que vous utilisez des stratégies d’intégrité du code, Get-HgsTrace peut renvoyer un échec pour le diagnostic actif de la stratégie d’intégrité du code. Vous pouvez ignorer ce résultat en toute sécurité lorsqu’il s’agit du seul diagnostic défaillant.

Passer en revue les stratégies d’attestation

Pour passer en revue l’état actuel des stratégies configurées sur SGH, exécutez les commandes suivantes sur n’importe quel nœud SGH :

# List all trusted security groups for admin-trusted attestation
Get-HgsAttestationHostGroup

# List all policies configured for TPM-trusted attestation
Get-HgsAttestationPolicy

Si vous trouvez une stratégie activée qui ne répond plus à vos exigences de sécurité (p. ex., une ancienne stratégie d’intégrité du code qui est désormais considérée comme non sécurisée), vous pouvez la désactiver en remplaçant le nom de la stratégie dans la commande suivante :

Disable-HgsAttestationPolicy -Name 'PolicyName'

De même, vous pouvez utiliser Enable-HgsAttestationPolicy pour réactiver une stratégie.

Si vous n’avez plus besoin d’une stratégie et que vous souhaitez la supprimer de tous les nœuds SGH, exécutez Remove-HgsAttestationPolicy -Name 'PolicyName' pour supprimer définitivement la stratégie.

Modification des modes d’attestation

Si vous avez démarré votre infrastructure protégée à l’aide d’une attestation approuvée par l’administrateur, vous voudrez probablement effectuer une mise à niveau vers le mode d’attestation TPM beaucoup plus puissant dès que vous avez suffisamment d’hôtes compatibles avec TPM 2.0 dans votre environnement. Lorsque vous êtes prêt à basculer, vous pouvez précharger tous les artefacts d’attestation (stratégies CI, lignes de base TPM et identificateurs TPM) dans SGH tout en continuant à exécuter SGH avec une attestation approuvée par l’administrateur. Pour ce faire, suivez simplement les instructions de la section autoriser un nouvel hôte protégé.

Une fois que vous avez ajouté toutes vos stratégies à SGH, l’étape suivante consiste à exécuter une tentative d’attestation synthétique sur vos hôtes pour voir s’ils réussissent l’attestation en mode TPM. Cela n’affecte pas l’état opérationnel actuel de SGH. Les commandes ci-dessous doivent être exécutées sur une machine qui a accès à tous les hôtes de l’environnement et à au moins un nœud SGH. Si votre pare-feu ou d’autres stratégies de sécurité empêchent cela, vous pouvez ignorer cette étape. Lorsque cela est possible, nous vous recommandons d’exécuter l’attestation synthétique pour vous indiquer si le basculement vers le mode TPM entraîne un temps d’arrêt pour vos machines virtuelles.

# Get information for each host in your environment
$hostNames = 'host01.contoso.com', 'host02.contoso.com', 'host03.contoso.com'
$credential = Get-Credential -Message 'Enter a credential with admin privileges on each host'
$targets = @()
$hostNames | ForEach-Object { $targets += New-HgsTraceTarget -Credential $credential -Role GuardedHost -HostName $_ }

$hgsCredential = Get-Credential -Message 'Enter an admin credential for HGS'
$targets += New-HgsTraceTarget -Credential $hgsCredential -Role HostGuardianService -HostName 'HGS01.bastion.local'

# Initiate the synthetic attestation attempt
Get-HgsTrace -RunDiagnostics -Target $targets -Diagnostic GuardedFabricTpmMode

Une fois les diagnostics terminés, passez en revue les informations sorties pour déterminer si des hôtes auraient échoué à l’attestation en mode TPM. Réexécutez les diagnostics jusqu’à ce que chaque hôte réussisse, puis passez le mode SGH en mode TPM.

Le passage au mode TPM ne prend qu’une seconde. Exécutez la commande suivante sur n’importe quel nœud SGH pour mettre à jour le mode d’attestation.

Set-HgsServer -TrustTpm

Si vous rencontrez des problèmes et que vous devez revenir en mode Active Directory, vous pouvez le faire en exécutant Set-HgsServer -TrustActiveDirectory.

Une fois que vous avez confirmé que tout fonctionne comme prévu, vous devez supprimer tous les groupes hôtes Active Directory approuvés de SGH et supprimer l’approbation entre les domaines SGH et de la structure. Si vous laissez l’approbation Active Directory en place,il se peut que quelqu’un réactive l’approbation et bascule SGH en mode Active Directory, ce qui peut permettre au code non approuvé de s’exécuter sans avoir été coché sur vos hôtes protégés.

Gestion des clés

La solution de structure protégée utilise plusieurs paires de clés publiques/privées pour valider l’intégrité des différents composants de la solution et chiffrer les secrets de locataire. Le service Guardian hôte est configuré avec au moins deux certificats (avec des clés publiques et privées), qui sont utilisés pour signer et chiffrer les clés utilisées pour démarrer des machines virtuelles protégées. Ces clés doivent être gérées avec soin. Si la clé privée est acquise par un adversaire, il sera en mesure de déjouer les machines virtuelles en cours d’exécution sur votre infrastructure ou de configurer un cluster SGH imposteur qui utilise des stratégies d’attestation plus faibles pour contourner les protections que vous mettez en place. Si vous perdez les clés privées lors d’un sinistre et que vous ne les trouvez pas dans une sauvegarde, vous devez configurer une nouvelle paire de clés et recréer chaque machine virtuelle pour autoriser vos nouveaux certificats.

Cette section traite des rubriques générales sur la gestion des clés pour vous aider à configurer vos clés afin qu’elles soient fonctionnelles et sécurisées.

Ajout de nouvelles clés

Bien que SGH soit initialisé avec un ensemble de clés, vous pouvez ajouter plusieurs clés de chiffrement et de signature. Les deux raisons les plus courantes pour lesquelles vous ajoutez de nouvelles clés à SGH sont les suivantes :

  1. Pour prendre en charge les scénarios « apportez votre propre clé » où les locataires copient leurs clés privées dans votre module de sécurité matérielle et autorisent uniquement leurs clés à démarrer leurs machines virtuelles protégées.
  2. Pour remplacer les clés existantes pour SGH en ajoutant d’abord les nouvelles clés et en conservant les deux ensembles de clés jusqu’à ce que chaque configuration de machine virtuelle ait été mise à jour pour utiliser les nouvelles clés.

Le processus d’ajout de vos nouvelles clés diffère en fonction du type de certificat que vous utilisez.

Option 1 : ajout d’un certificat stocké dans un HSM

Notre approche recommandée pour sécuriser les clés SGH consiste à utiliser des certificats créés dans un module de sécurité matériel (HSM). Les HSM garantissent que l’utilisation de vos clés est liée à l’accès physique à un appareil sensible à la sécurité dans votre centre de données. Chaque HSM est différent et a un processus unique pour créer des certificats et les inscrire auprès de SGH. Les étapes ci-dessous sont destinées à fournir des conseils approximatifs pour l’utilisation de certificats sauvegardés dans un HSM. Consultez la documentation de votre fournisseur de HSM pour connaître les étapes et les fonctionnalités exactes.

  1. Installez le logiciel HSM sur chaque nœud SGH dans votre cluster. Selon que vous disposez d’un réseau ou d’un appareil HSM local, vous devrez peut-être configurer le HSM pour accorder à votre ordinateur l’accès à son magasin de clés.

  2. Créer deux certificats dans le HSM avec des clés RSA 2 048 bits pour le chiffrement et la signature

    1. Créer un certificat de chiffrement avec la propriété d’utilisation de la clé de chiffrement des données dans votre HSM
    2. Créer un certificat de signature avec la propriété d’utilisation de la clé signature numérique dans votre HSM

  3. Installez les certificats dans le magasin de certificats local de chaque nœud SGH conformément aux instructions de votre fournisseur HSM.

  4. Si votre HSM utilise des autorisations granulaires pour accorder des applications ou des utilisateurs spécifiques à l’utilisation de la clé privée, vous devez accorder à votre compte de service managé de groupe SGH l’accès au certificat. Vous pouvez trouver le nom du compte gMSA SGH en exécutant (Get-IISAppPool -Name KeyProtection).ProcessModel.UserName

  5. Ajoutez les certificats de signature et de chiffrement à SGH en remplaçant les empreintes par celles de vos certificats dans les commandes suivantes :

    Add-HgsKeyProtectionCertificate -CertificateType Encryption -Thumbprint "AABBCCDDEEFF00112233445566778899"
Add-HgsKeyProtectionCertificate -CertificateType Signing -Thumbprint "99887766554433221100FFEEDDCCBBAA"

Option 2 : Ajout de certificats logiciels non exportables

Si vous disposez d’un certificat logiciel émis par l’autorité de certification de votre entreprise ou par une autorité de certification publique disposant d’une clé privée non exportable, vous devez ajouter votre certificat à SGH à l’aide de son empreinte numérique.

  1. Installez le certificat sur votre ordinateur en fonction des instructions de votre autorité de certification.

  2. Accordez au compte de service managé de groupe SGH un accès en lecture à la clé privée du certificat. Vous pouvez trouver le nom du compte gMSA SGH en exécutant (Get-IISAppPool -Name KeyProtection).ProcessModel.UserName

  3. Inscrivez le certificat auprès de SGH à l’aide de la commande suivante et en remplaçant dans l’empreinte numérique de votre certificat (remplacez Chiffrement par Signature pour la signature des certificats) :

    Add-HgsKeyProtectionCertificate -CertificateType Encryption -Thumbprint "AABBCCDDEEFF00112233445566778899"

Important

Vous devez installer manuellement la clé privée et accorder l’accès en lecture au compte gMSA sur chaque nœud SGH. SGH ne peut pas répliquer automatiquement les clés privées pour n’importe quel certificat inscrit par son empreinte numérique.

Option 3 : Ajout de certificats stockés dans des fichiers PFX

Si vous disposez d’un certificat logiciel avec une clé privée exportable qui peut être stockée au format de fichier PFX et sécurisée avec un mot de passe, SGH peut gérer automatiquement vos certificats pour vous. Les certificats ajoutés avec les fichiers PFX sont répliqués automatiquement sur chaque nœud de votre cluster SGH qui sécurise l’accès aux clés privées. Pour ajouter un nouveau certificat à l’aide d’un fichier PFX, exécutez les commandes suivantes sur n’importe quel nœud SGH (remplacez Chiffrement par Signature pour la signature des certificats) :

$certPassword = Read-Host -AsSecureString -Prompt "Provide the PFX file password"
Add-HgsKeyProtectionCertificate -CertificateType Encryption -CertificatePath "C:\temp\encryptionCert.pfx" -CertificatePassword $certPassword

Identification et modification des certificats principaux Bien que SGH puisse prendre en charge plusieurs certificats de signature et de chiffrement, il utilise une paire comme certificats « principaux ». Il s’agit des certificats qui seront utilisés si quelqu’un télécharge les métadonnées du tuteur pour ce cluster SGH. Pour vérifier quels certificats sont actuellement marqués comme certificats principaux, exécutez la commande suivante :

Get-HgsKeyProtectionCertificate -IsPrimary $true

Pour définir un nouveau certificat de chiffrement ou de signature principal, recherchez l’empreinte du certificat souhaité et marquez-le comme principal à l’aide des commandes suivantes :

Get-HgsKeyProtectionCertificate
Set-HgsKeyProtectionCertificate -CertificateType Encryption -Thumbprint "AABBCCDDEEFF00112233445566778899" -IsPrimary
Set-HgsKeyProtectionCertificate -CertificateType Signing -Thumbprint "99887766554433221100FFEEDDCCBBAA" -IsPrimary

Renouvellement ou remplacement de clés

Lorsque vous créez les certificats utilisés par SGH, une date d’expiration est attribuée aux certificats en fonction de la stratégie de votre autorité de certification et de vos informations de demande. Normalement, dans les scénarios où la validité du certificat est importante, comme la sécurisation des communications HTTP, les certificats doivent être renouvelés avant leur expiration pour éviter une interruption de service ou un message d’erreur inquiétant. SGH n’utilise pas de certificats dans ce sens. SGH utilise simplement des certificats comme moyen pratique de créer et de stocker une paire de clés asymétriques. Un certificat de chiffrement ou de signature expiré sur SGH n’indique pas une faiblesse ou une perte de protection pour les machines virtuelles protégées. En outre, les vérifications de révocation de certificat ne sont pas effectuées par SGH. Si un certificat SGH ou le certificat de l’autorité émettrice est révoqué, cela n’aura pas d’impact sur l’utilisation du certificat par SGH.

La seule fois où vous devez vous soucier d’un certificat SGH est si vous avez des raisons de croire que sa clé privée a été volée. Dans ce cas, l’intégrité de vos machines virtuelles protégées est menacée, car la possession de la moitié privée de la paire de clés de chiffrement et de signature SGH suffit à supprimer les protections sur une machine virtuelle ou à mettre en place un serveur SGH factice qui a des stratégies d’attestation plus faibles.

Si vous vous trouvez dans cette situation ou si les normes de conformité vous obligent à actualiser régulièrement les clés de certificat, les étapes suivantes décrivent le processus de modification des clés sur un serveur SGH. Notez que les conseils suivants représentent une entreprise importante qui entraînera une interruption du service de chaque machine virtuelle desservie par le cluster SGH. La planification appropriée de la modification des clés SGH est nécessaire pour réduire les interruptions de service et garantir la sécurité des machines virtuelles clientes.

Sur un nœud SGH, procédez comme suit pour inscrire une nouvelle paire de certificats de chiffrement et de signature. Consultez la section sur l’ajout de nouvelles clés pour obtenir des informations détaillées sur les différentes façons d’ajouter de nouvelles clés à SGH.

  1. Créez une paire de certificats de chiffrement et de signature pour votre serveur SGH. Dans l’idéal, ceux-ci seront créés dans un module de sécurité matérielle.

  2. Inscrire les nouveaux certificats de chiffrement et de signature avec Add-HgsKeyProtectionCertificate

    Add-HgsKeyProtectionCertificate -CertificateType Signing -Thumbprint <Thumbprint>
Add-HgsKeyProtectionCertificate -CertificateType Encryption -Thumbprint <Thumbprint>

  3. Si vous avez utilisé des empreintes numériques, vous devez accéder à chaque nœud du cluster pour installer la clé privée et accorder à SGH gMSA l’accès à la clé.

  4. Faire des nouveaux certificats les certificats par défaut dans SGH

    Set-HgsKeyProtectionCertificate -CertificateType Signing -Thumbprint <Thumbprint> -IsPrimary
Set-HgsKeyProtectionCertificate -CertificateType Encryption -Thumbprint <Thumbprint> -IsPrimary

À ce stade, la protection des données créées avec des métadonnées obtenues à partir du nœud SGH utilisera les nouveaux certificats, mais les machines virtuelles existantes continueront de fonctionner, car les anciens certificats sont toujours présents.

Pour vous assurer que toutes les machines virtuelles existantes fonctionneront avec les nouvelles clés, vous devez mettre à jour le protecteur de clés sur chaque machine virtuelle.

Il s’agit d’une action qui nécessite que le propriétaire de la machine virtuelle (personne ou entité en possession du tuteur « propriétaire ») soit impliqué. Pour chaque machine virtuelle protégée, effectuez les étapes suivantes :

  1. Arrêtez la machine virtuelle. La machine virtuelle ne peut pas être réactivée tant que les étapes restantes ne sont pas terminées, sinon vous devrez recommencer le processus.

  2. Enregistrez le protecteur de clé actuel dans un fichier : Get-VMKeyProtector -VMName 'VM001' | Out-File '.\VM001.kp'

  3. Transférez le KP au propriétaire de la machine virtuelle

  4. Chargez le propriétaire de télécharger les informations du tuteur mises à jour à partir de SGH et de les importer sur son système local

  5. Lisez le KP actuel en mémoire, accordez au nouveau gardien l’accès au KP et enregistrez-le dans un nouveau fichier en exécutant les commandes suivantes :

    $kpraw = Get-Content -Path .\VM001.kp
$kp = ConvertTo-HgsKeyProtector -Bytes $kpraw
$newGuardian = Get-HgsGuardian -Name 'UpdatedHgsGuardian'
$updatedKP = Grant-HgsKeyProtectorAccess -KeyProtector $kp -Guardian $newGuardian
$updatedKP.RawData | Out-File .\updatedVM001.kp

  6. Copiez le KP mis à jour dans l’infrastructure d’hébergement.

  7. Appliquez le KP à la machine virtuelle d’origine :

    $updatedKP = Get-Content -Path .\updatedVM001.kp
Set-VMKeyProtector -VMName VM001 -KeyProtector $updatedKP

  8. Enfin, démarrez la machine virtuelle et vérifiez qu’elle s’exécute correctement.

    Notes

    Si le propriétaire de la machine virtuelle définit un protecteur de clé incorrect sur la machine virtuelle et n’autorise pas votre infrastructure à exécuter la machine virtuelle, vous ne pourrez pas démarrer la machine virtuelle protégée. Pour revenir au dernier protecteur de clé correct connu, exécutez Set-VMKeyProtector -RestoreLastKnownGoodKeyProtector

    Une fois que toutes les machines virtuelles ont été mises à jour pour autoriser les nouvelles clés de tuteur, vous pouvez désactiver et supprimer les anciennes clés.

  9. Obtenez les empreintes des anciens certificats à partir de Get-HgsKeyProtectionCertificate -IsPrimary $false

  10. Désactivez chaque certificat en exécutant les commandes suivantes :

    Set-HgsKeyProtectionCertificate -CertificateType Signing -Thumbprint <Thumbprint> -IsEnabled $false
Set-HgsKeyProtectionCertificate -CertificateType Encryption -Thumbprint <Thumbprint> -IsEnabled $false

  11. Après avoir vérifié que les machines virtuelles sont toujours en mesure de démarrer avec les certificats désactivés, supprimez les certificats de SGH en exécutant les commandes suivantes :

    Remove-HgsKeyProtectionCertificate -CertificateType Signing -Thumbprint <Thumbprint>`
Remove-HgsKeyProtectionCertificate -CertificateType Encryption -Thumbprint <Thumbprint>`

Important

Les sauvegardes de machine virtuelle contiennent d’anciennes informations de protection de clé qui permettent d’utiliser les anciens certificats pour démarrer la machine virtuelle. Si vous savez que votre clé privée a été compromise, vous devez supposer que les sauvegardes de machine virtuelle peuvent également être compromises et prendre les mesures appropriées. La destruction de la configuration de la machine virtuelle à partir des sauvegardes (.vmcx) supprime les protecteurs de clés, au prix de la nécessité d’utiliser le mot de passe de récupération BitLocker pour démarrer la machine virtuelle la prochaine fois.

Réplication de clé entre nœuds

Chaque nœud du cluster SGH doit être configuré avec les mêmes certificats de chiffrement, de signature et SSL (lorsqu’ils sont configurés). Cela est nécessaire pour garantir que les hôtes Hyper-V qui atteignent n’importe quel nœud du cluster peuvent avoir leurs demandes correctement traitées.

Si vous avez initialisé le serveur SGH avec des certificats PFX, alors SGH répliquera automatiquement la clé publique et privée de ces certificats sur chaque nœud du cluster. Il vous suffit d’ajouter les clés sur un seul nœud.

Si vous avez initialisé le serveur SGH avec des références de certificat ou des empreintes, SGH répliquera uniquement la clé publique dans le certificat sur chaque nœud. En outre, SGH ne peut pas s’accorder l’accès à la clé privée sur n’importe quel nœud dans ce scénario. Par conséquent, il vous incombe de réaliser les actions suivantes :

  1. Installez la clé privée sur chaque nœud SGH
  2. Accordez au compte de service managé de groupe SGH (gMSA) l’accès à la clé privée sur chaque nœud. Ces tâches ajoutent une charge opérationnelle supplémentaire, mais elles sont requises pour les clés et certificats HSM avec des clés privées non exportables.

Les certificats SSL ne sont jamais répliqués sous quelque forme que ce soit. Il vous incombe d’initialiser chaque serveur SGH avec le même certificat SSL et de mettre à jour chaque serveur chaque fois que vous choisissez de renouveler ou de remplacer le certificat SSL. Lorsque vous remplacez le certificat SSL, il est recommandé de le faire à l’aide de l’applet de commande Set-HgsServer.

Annulation de la configuration SGH

Si vous devez désactiver ou reconfigurer de manière significative un serveur SGH, vous pouvez le faire à l’aide des applets de commande Clear-HgsServer ou Uninstall-HgsServer.

Suppression de la configuration SGH

Pour supprimer un nœud du cluster SGH, utilisez l’applet de commande Clear-HgsServer. Cette applet de commande apporte les modifications suivantes sur le serveur sur lequel elle est exécutée :

  • Annulation de l’inscription des services d’attestation et de protection des clés
  • Suppression du point de terminaison de gestion JEA « microsoft.windows.hgs »
  • Suppression de l’ordinateur local du cluster de basculement SGH

Si le serveur est le dernier nœud SGH du cluster, le cluster et sa ressource de nom de réseau distribué correspondante sont également détruits.

# Removes the local computer from the HGS cluster
Clear-HgsServer

Une fois l’opération de suppression terminée, le serveur SGH peut être réinitialisé avec Initialize-HgsServer. Si vous avez utilisé Install-HgsServer pour configurer un domaine Active Directory Domain Services, ce domaine restera configuré et opérationnel après l’opération de suppression.

Désinstallation de SGH

Si vous souhaitez supprimer un nœud du cluster SGH et rétrograder le contrôleur domaine Active Directory qui s’exécute sur celui-ci, utilisez l’applet de commande Uninstall-HgsServer. Cette applet de commande apporte les modifications suivantes sur le serveur sur lequel elle est exécutée :

  • Annulation de l’inscription des services d’attestation et de protection des clés
  • Suppression du point de terminaison de gestion JEA « microsoft.windows.hgs »
  • Suppression de l’ordinateur local du cluster de basculement SGH
  • Rétrogradation du contrôleur de domaine Active Directory, s’il est configuré

Si le serveur est le dernier nœud SGH du cluster, le domaine, le cluster de basculement et la ressource nom du réseau distribué du cluster sont également détruits.

# Removes the local computer from the HGS cluster and demotes the ADDC (restart required)
$newLocalAdminPassword = Read-Host -AsSecureString -Prompt "Enter a new password for the local administrator account"
Uninstall-HgsServer -LocalAdministratorPassword $newLocalAdminPassword -Restart

Une fois l’opération de désinstallation terminée et l’ordinateur redémarré, vous pouvez réinstaller ADDC et SGH à l’aide de Install-HgsServer ou joindre l’ordinateur à un domaine et initialiser le serveur SGH dans ce domaine avec Initialize-HgsServer.

Si vous n’avez plus l’intention d’utiliser l’ordinateur comme nœud SGH, vous pouvez supprimer le rôle de Windows.

Uninstall-WindowsFeature HostGuardianServiceRole