Résoudre les problèmes liés au service Guardian hôte

Article
08/22/2024

Cet article décrit la résolution des problèmes courants rencontrés lors du déploiement ou de l’exploitation d’un serveur SGH (Host Guardian Service) dans une infrastructure protégée.

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

Si vous n’êtes pas sûr de la nature de votre problème, essayez d’abord d’exécuter les diagnostics de structure protégée sur vos serveurs HGS et les hôtes Hyper-V pour limiter les causes potentielles .

Certificats

SGH nécessite plusieurs certificats pour fonctionner, notamment le certificat de chiffrement et de signature configuré par l’administrateur, ainsi qu’un certificat d’attestation géré par SGH lui-même. Si ces certificats sont configurés de manière incorrecte, HGS ne peut pas traiter les demandes des hôtes Hyper-V souhaitant attester ou déverrouiller des protecteurs de clé pour les machines virtuelles protégées. Les sections suivantes couvrent les problèmes courants liés aux certificats configurés sur SGH.

Autorisations de certificat

SGH doit être en mesure d’accéder aux clés publiques et privées des certificats de chiffrement et de signature ajoutés à SGH par l’empreinte numérique du certificat. Plus précisément, le compte de service managé de groupe (gMSA) qui exécute le service SGH doit accéder aux clés. Pour rechercher le gMSA utilisé par SGH, exécutez la commande suivante dans une invite PowerShell avec élévation de privilèges sur votre serveur SGH :

(Get-IISAppPool -Name KeyProtection).ProcessModel.UserName

La façon dont vous accordez au compte gMSA l’accès à l’utilisation de la clé privée dépend de l’emplacement où la clé est stockée : sur l’ordinateur en tant que fichier de certificat local, sur un module de sécurité matériel (HSM) ou à l’aide d’un fournisseur de stockage de clés tiers personnalisé.

Accorder l’accès aux clés privées sauvegardées par logiciel

Si vous utilisez un certificat auto-signé ou un certificat émis par une autorité de certification qui n’est pas stockée dans un module de sécurité matériel ou un fournisseur de stockage de clés personnalisées, vous pouvez modifier les autorisations de clé privée en effectuant les étapes suivantes :

Ouvrez le gestionnaire de certificats local (certlm.msc).
Développez Certificats personnels>et recherchez le certificat de signature ou de chiffrement que vous souhaitez mettre à jour.
Cliquez avec le bouton droit sur le certificat et sélectionnez Toutes les tâches>gérer les clés privées.
Sélectionnez Ajouter pour accorder à un nouvel utilisateur l’accès à la clé privée du certificat.
Dans le sélecteur d’objets, entrez le nom du compte gMSA pour SGH trouvé précédemment, puis sélectionnez OK.
Vérifiez que le gMSA a l’accès Lecture sur la clé privée.
Cliquez sur OK pour fermer la fenêtre Autorisations.

Si vous exécutez HGS sur Server Core ou que vous gérez le serveur à distance, vous ne pourrez pas gérer les clés privées à l’aide du gestionnaire de certificats local. Au lieu de cela, vous devez télécharger le module PowerShell Outils Guarded Fabric, qui vous permettra de gérer les autorisations dans PowerShell.

Ouvrez une console PowerShell avec élévation de privilèges sur la machine Server Core ou utilisez la communication à distance PowerShell avec un compte disposant d’autorisations d’administrateur local sur SGH.
Exécutez les commandes suivantes pour installer le module PowerShell Guarded Fabric Tools et accorder au compte gMSA l’accès à la clé privée.

$certificateThumbprint = '<ENTER CERTIFICATE THUMBPRINT HERE>'

# Install the Guarded Fabric Tools module, if necessary
Install-Module -Name GuardedFabricTools -Repository PSGallery

# Import the module into the current session
Import-Module -Name GuardedFabricTools

# Get the certificate object
$cert = Get-Item "Cert:\LocalMachine\My\$certificateThumbprint"

# Get the gMSA account name
$gMSA = (Get-IISAppPool -Name KeyProtection).ProcessModel.UserName

# Grant the gMSA read access to the certificate
$cert.Acl = $cert.Acl | Add-AccessRule $gMSA Read Allow

Accorder l’accès au HSM ou aux clés privées personnalisées sauvegardées par un fournisseur

Si les clés privées de votre certificat sont sauvegardées par un module de sécurité matériel (HSM) ou un fournisseur de stockage de clés personnalisé (KSP), le modèle d’autorisation dépend de votre fournisseur de logiciels spécifique. Pour obtenir de meilleurs résultats, consultez la documentation de votre fournisseur ou le site de support pour plus d’informations sur la façon dont les autorisations de clé privée sont gérées pour votre appareil/logiciel spécifique. Dans tous les cas, le gMSA utilisé par SGH nécessite des autorisations de lecture sur les clés privées de chiffrement, de signature et de certificat de communication afin qu’il puisse effectuer des opérations de signature et de chiffrement.

Certains modules de sécurité matérielle ne prennent pas en charge l’octroi de comptes d’utilisateur spécifiques l’accès à une clé privée ; ils autorisent plutôt l’accès au compte d’ordinateur à toutes les clés d’un jeu de clés spécifique. Pour ces appareils, il est généralement suffisant de donner à l’ordinateur l’accès à vos clés et HGS est en mesure de tirer parti de cette connexion.

Conseils pour les HSM

Vous trouverez ci-dessous des options de configuration suggérées pour vous aider à utiliser correctement les clés HSM avec SGH en fonction des expériences de Microsoft et de ses partenaires. Ces conseils sont fournis pour votre commodité et ne sont pas garantis être corrects au moment de la lecture, ni ne sont-ils approuvés par les fabricants de HSM. Si vous avez d’autres questions, contactez le fabricant de votre HSM pour obtenir des informations précises sur votre appareil spécifique.

Marque/série HSM	Suggestion
Gemalto SafeNet	Vérifiez que la propriété Utilisation de la clé dans le fichier de demande de certificat est définie sur 0xa0, ce qui permet d’utiliser le certificat pour la signature et le chiffrement. En outre, vous devez accorder au compte gMSA un accès en lecture à la clé privée à l’aide de l’outil gestionnaire de certificats local (voir les étapes ci-dessus).
nCipher nShield	Vérifiez que chaque nœud SGH a accès au monde de la sécurité contenant les clés de signature et de chiffrement. En outre, vous pourriez avoir besoin d’accorder au gMSA un accès en lecture à la clé privée à l’aide du gestionnaire de certificats local (voir les étapes ci-dessus).
Utimaco CryptoServers	Vérifiez que la propriété Utilisation de la clé dans le fichier de demande de certificat est définie sur 0x13, ce qui permet d’utiliser le certificat pour le chiffrement, le déchiffrement et la signature.

Demandes de certificat

Si vous utilisez une autorité de certification pour émettre vos certificats dans un environnement PKI (Public Key Infrastructure), vous devez vous assurer que votre demande de certificat inclut la configuration minimale requise pour l’utilisation de ces clés par HGS.

Certificats de signature

Propriété CSR	Valeur requise
Algorithm	RSA
Taille de la clé	Au moins 2 048 bits
Utilisation de la clé	Signature/Sign/DigitalSignature

Certificats de chiffrement

Propriété CSR	Valeur requise
Algorithm	RSA
Taille de la clé	Au moins 2 048 bits
Utilisation de la clé	Chiffrement/Chiffrement/DataEncipherment

Modèles services de certificats Active Directory

Si vous utilisez des modèles de certificat ADCS (Active Directory Certificate Services) pour créer les certificats, nous vous recommandons d’utiliser un modèle avec les paramètres suivants :

Propriété de modèle ADCS	Valeur requise
Catégorie de fournisseur	Fournisseur de stockage de clés
Nom de l'algorithme	RSA
Taille de clé minimale	2 048
Objectif	Signature et chiffrement
Extension d’utilisation des clés	Signature numérique, chiffrement de clé, chiffrement des données (« Autoriser le chiffrement des données utilisateur »)

Dérive temporelle

Si le temps de votre serveur a considérablement dérivé de celui d’autres nœuds SGH ou hôtes Hyper-V dans votre infrastructure protégée, vous pouvez rencontrer des problèmes avec la validité du certificat du signataire d’attestation. Le certificat de signataire d’attestation est créé et renouvelé en arrière-plan sur SGH et est utilisé pour signer les certificats d’intégrité émis aux hôtes protégés par le service d’attestation.

Pour actualiser le certificat du signataire d’attestation, exécutez la commande suivante dans une invite PowerShell avec élévation de privilèges.

Start-ScheduledTask -TaskPath \Microsoft\Windows\HGSServer -TaskName
AttestationSignerCertRenewalTask

Vous pouvez également exécuter manuellement la tâche planifiée en ouvrant le planificateur de tâches (taskschd.msc), en accédant à la bibliothèque>du planificateur de tâches Microsoft>Windows>HGSServer et en exécutant la tâche nommée AttestationSignerCertRenewalTask.

Basculement des modes d’attestation

Si vous passez SGH du mode TPM au mode Active Directory ou vice versa à l’aide de l’applet de commande Set-HgsServer , l’application du nouveau mode d’attestation peut prendre jusqu’à 10 minutes pour chaque nœud de votre cluster SGH.

Il s’agit du comportement normal.

Il est conseillé de ne supprimer aucune stratégie autorisant les hôtes du mode d’attestation précédent tant que vous n’avez pas vérifié que tous les hôtes sont attestant correctement à l’aide du nouveau mode d’attestation.

Problème connu lors du passage du mode TPM au mode AD

Si vous avez initialisé votre cluster SGH en mode TPM et passez ultérieurement en mode Active Directory, il existe un problème connu qui empêche les autres nœuds de votre cluster HGS de basculer vers le nouveau mode d’attestation. Pour vous assurer que tous les serveurs SGH appliquent le mode d’attestation approprié, exécutez Set-HgsServer -TrustActiveDirectory sur chaque nœud de votre cluster SGH.

Ce problème ne s’applique pas si vous passez du mode TPM au mode AD et que le cluster a été configuré à l’origine en mode AD.

Vous pouvez vérifier le mode d’attestation de votre serveur SGH en exécutant Get-HgsServer.

Stratégies de chiffrement du vidage de la mémoire

Si vous essayez de configurer des stratégies de chiffrement de vidage de mémoire et que vous ne voyez pas les stratégies de vidage HGS par défaut (Hgs_NoDumps, Hgs_DumpEncryption et Hgs_DumpEncryptionKey) ou l’applet de commande de stratégie de vidage (Add-HgsAttestationDumpPolicy), il est probable que vous n’ayez pas la dernière mise à jour cumulative installée.

Pour résoudre ce problème, mettez à jour votre serveur SGH vers la dernière mise à jour cumulative de Windows et activez les nouvelles stratégies d’attestation.

Veillez à mettre à jour vos hôtes Hyper-V vers la même mise à jour cumulative avant d’activer les nouvelles stratégies d’attestation, car les hôtes qui n’ont pas les nouvelles fonctionnalités de chiffrement de vidage installées échoueront probablement une fois la stratégie SGH activée.

Messages d’erreur de certificat de clé d’approbation

Lorsque vous inscrivez un hôte à l’aide de l’applet de commande Add-HgsAttestationTpmHost , deux identificateurs TPM sont extraits du fichier d’identificateur de plateforme fourni : le certificat de clé d’approbation (EKcert) et la clé d’approbation publique (EKpub). Le certificat EK identifie le fabricant du module de plateforme sécurisée, en fournissant des garanties que le module de plateforme sécurisée est authentique et fabriqué selon la chaîne d’approvisionnement normale. L’EKpub identifie de manière unique ce TPM spécifique, et c’est l’une des mesures que SGH utilise pour accorder à un hôte l’accès permettant d’exécuter des machines virtuelles dotées d’une protection maximale.

Vous recevrez une erreur lorsque vous inscrivez un hôte TPM si l’une des deux conditions est vraie :

Le fichier d’identificateur de plateforme ne contient pas de certificat de clé d’approbation.
Le fichier d’identificateur de plateforme contient un certificat de clé d’approbation, mais ce certificat n’est pas approuvé sur votre système.

Certains fabricants de TPM n’incluent pas de certificats EK dans leurs modules TPM.

Si vous pensez que c’est le cas avec votre module TPM, vérifiez auprès de votre fabricant d'ordinateurs OEM que vos TPM ne doivent pas avoir de certificat EK et utilisez l’indicateur -Force pour inscrire manuellement l’hôte auprès de SGH. Si votre module de plateforme sécurisée doit avoir un certificat EKcert mais qu’un certificat n’a pas été trouvé dans le fichier d’identificateur de plateforme, vérifiez que vous utilisez une console PowerShell d’administrateur (avec élévation de privilèges) lors de l’exécution de Get-PlatformIdentifier sur l’hôte.

Si vous avez reçu l’erreur indiquant que votre certificat EKcert n’est pas approuvé, vérifiez que vous avez installé le package de certificats racines TPM approuvés sur chaque serveur SGH et que le certificat racine de votre fournisseur TPM est présent dans le magasin « TrustedTPM_RootCA » de l’ordinateur local. Tous les certificats intermédiaires applicables doivent également être installés dans le magasin « TrustedTPM_IntermediateCA » sur l’ordinateur local. Après avoir installé les certificats racine et intermédiaire, vous devez être en mesure d’exécuter Add-HgsAttestationTpmHost correctement.

Privilèges de compte de service administré de groupe (gMSA)

Le compte de service SGH (gMSA utilisé pour le pool d’applications Key Protection Service dans IIS) doit recevoir le privilège Générer des audits de sécurité, également appelé SeAuditPrivilege. Si ce privilège est manquant, la configuration SGH initiale réussit et IIS démarre, mais le service de protection de clés n’est pas fonctionnel et retourne l’erreur HTTP 500 (« Erreur du serveur dans l’application /KeyProtection »). Vous pouvez également observer les messages d’avertissement suivants dans le journal des événements d’application.

System.ComponentModel.Win32Exception (0x80004005): A required privilege is not held by the client
at Microsoft.Windows.KpsServer.Common.Diagnostics.Auditing.NativeUtility.RegisterAuditSource(String pszSourceName, SafeAuditProviderHandle& phAuditProvider)
at Microsoft.Windows.KpsServer.Common.Diagnostics.Auditing.SecurityLog.RegisterAuditSource(String sourceName)

Failed to register the security event source.
   at System.Web.HttpApplicationFactory.EnsureAppStartCalledForIntegratedMode(HttpContext context, HttpApplication app)
   at System.Web.HttpApplication.RegisterEventSubscriptionsWithIIS(IntPtr appContext, HttpContext context, MethodInfo[] handlers)
   at System.Web.HttpApplication.InitSpecial(HttpApplicationState state, MethodInfo[] handlers, IntPtr appContext, HttpContext context)
   at System.Web.HttpApplicationFactory.GetSpecialApplicationInstance(IntPtr appContext, HttpContext context)
   at System.Web.Hosting.PipelineRuntime.InitializeApplication(IntPtr appContext)

Failed to register the security event source.
   at Microsoft.Windows.KpsServer.Common.Diagnostics.Auditing.SecurityLog.RegisterAuditSource(String sourceName)
   at Microsoft.Windows.KpsServer.Common.Diagnostics.Auditing.SecurityLog.ReportAudit(EventLogEntryType eventType, UInt32 eventId, Object[] os)
   at Microsoft.Windows.KpsServer.KpsServerHttpApplication.Application_Start()

A required privilege is not held by the client
   at Microsoft.Windows.KpsServer.Common.Diagnostics.Auditing.NativeUtility.RegisterAuditSource(String pszSourceName, SafeAuditProviderHandle& phAuditProvider)
   at Microsoft.Windows.KpsServer.Common.Diagnostics.Auditing.SecurityLog.RegisterAuditSource(String sourceName)

En outre, vous remarquerez peut-être qu’aucune des applets de commande du service de protection de clés (par exemple , Get-HgsKeyProtectionCertificate) ne fonctionne et retourne plutôt des erreurs.

Pour résoudre ce problème, vous devez accorder à gMSA l’option « Générer des audits de sécurité » (SeAuditPrivilege). Pour ce faire, vous pouvez utiliser la stratégie de sécurité locale SecPol.msc sur chaque nœud du cluster SGH ou la stratégie de groupe. Vous pouvez également utiliser l’outil SecEdit.exe pour exporter la stratégie de sécurité actuelle, apporter les modifications nécessaires dans le fichier de configuration (qui est un texte brut), puis l’importer de nouveau.

Note

Lors de la configuration de ce paramètre, la liste des principes de sécurité définis pour un privilège remplace entièrement les valeurs par défaut (elle ne concatène pas). Par conséquent, lors de la définition de ce paramètre de stratégie, veillez à inclure à la fois les titulaires par défaut de ce privilège (service réseau et service local) en plus du gMSA que vous ajoutez.

Partage via