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

Cet article décrit les solutions aux problèmes courants rencontrés lors du déploiement ou de l’utilisation d’un serveur du service Guardian hôte (SGH) 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 l’infrastructure protégée diagnostics sur vos serveurs SGH et 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és par l’administrateur, ainsi qu’un certificat d’attestation géré par SGH lui-même. Si ces certificats sont mal configurés, SGH ne peut pas traiter les demandes des hôtes Hyper-V souhaitant attester ou déverrouiller des protecteurs de clés pour les machines virtuelles dotées d’une protection maximale. Les sections suivantes traitent des 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 géré de groupe (gMSA) qui exécute le service SGH a besoin d’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 l’accès au compte gMSA pour utiliser la clé privée dépend de l’emplacement de stockage de la clé : 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é dans un module de sécurité matériel ou un fournisseur de stockage de clés personnalisé, vous pouvez modifier les autorisations de clé privée en effectuant les étapes suivantes :

  1. Ouvrez le gestionnaire de certificats local (certlm.msc).
  2. DéveloppezCertificatspersonnels> et recherchez le certificat de signature ou de chiffrement que vous souhaitez mettre à jour.
  3. Cliquez avec le bouton droit sur le certificat et sélectionnez Toutes les tâches>Gérer les clés privées.
  4. Sélectionnez Ajouter pour accorder à un nouvel utilisateur l’accès à la clé privée du certificat.
  5. Dans le sélecteur d’objets, entrez le nom du compte gMSA pour SGH trouvé précédemment, puis sélectionnez OK.
  6. Vérifiez que le gMSA dispose d’un accès en lecture au certificat.
  7. Sélectionnez OK pour fermer la fenêtre d’autorisation.

Si vous exécutez SGH sur Server Core ou si 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 Guarded Fabric Tools, qui vous permettra de gérer les autorisations dans PowerShell.

  1. Ouvrez une console PowerShell avec élévation de privilèges sur l’ordinateur Server Core ou utilisez la communication à distance PowerShell avec un compte disposant d’autorisations d’administrateur local sur SGH.
  2. 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 à HSM ou à des 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 ou le site de support de votre fournisseur 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 du certificat de chiffrement, de signature et de communication afin qu’il puisse effectuer des opérations de signature et de chiffrement.

Certains modules de sécurité matériels ne prennent pas en charge l’octroi d’un accès à une clé privée à des comptes d’utilisateur spécifiques . Au lieu de cela, ils autorisent le compte d’ordinateur à accéder à toutes les clés d’un jeu de clés spécifique. Pour ces appareils, il suffit généralement de donner à l’ordinateur l’accès à vos clés et SGH est en mesure de tirer parti de cette connexion.

Conseils pour les modules HSM

Vous trouverez ci-dessous des options de configuration suggérées pour vous aider à utiliser avec succès des 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 d’être corrects au moment de la lecture, ni ils ne sont 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 l’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. Vous devrez peut-être également accorder au gMSA l’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 d’infrastructure à clé publique (PKI), vous devez vous assurer que votre demande de certificat inclut la configuration minimale requise pour l’utilisation de ces clés par SGH.

Certificats de signature

Propriété CSR Valeur obligatoire
Algorithme RSA
Taille de clé Au moins 2 048 bits
Utilisation de la clé Signature/Signature/DigitalSignature

Certificats de chiffrement

Propriété CSR Valeur obligatoire
Algorithme RSA
Taille de clé Au moins 2 048 bits
Utilisation de la clé Chiffrement/Chiffrer/DataEncipherment

Modèles des 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 obligatoire
Catégorie de fournisseur Fournisseur de stockage de clés
Nom de l’algorithme RSA
Taille de clé minimale 2048
Objectif Signature et chiffrement
Extension d’utilisation de clé 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 de 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 de 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 à Bibliothèque> du planificateur de tâchesMicrosoft>Windows>HGSServer et en exécutant la tâche nommée AttestationSignerCertRenewalTask.

Basculement des modes d’attestation

Si vous passez du mode TPM au mode Active Directory ou vice versa à l’aide de l’applet de commande Set-HgsServer , jusqu’à 10 minutes peuvent être nécessaires pour que chaque nœud de votre cluster SGH commence à appliquer le nouveau mode d’attestation.

Il s’agit d’un comportement normal.

Il est recommandé de ne pas supprimer les stratégies autorisant les hôtes du mode d’attestation précédent tant que vous n’avez pas vérifié que tous les hôtes attestent 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 que vous basculez ultérieurement vers le mode Active Directory, il existe un problème connu qui empêche d’autres nœuds de votre cluster SGH de basculer vers le nouveau mode d’attestation. Pour vous assurer que tous les serveurs SGH appliquent le mode d’attestation correct, 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é initialement configuré 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 mémoire

Si vous essayez de configurer des stratégies de chiffrement de vidage mémoire et que vous ne voyez pas les stratégies de vidage SGH 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 la dernière mise à jour cumulative ne soit pas 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 l’assurance que le module de plateforme sécurisée est authentique et fabriqué dans le cadre de la chaîne d’approvisionnement normale. EKpub identifie de manière unique ce TPM spécifique et est l’une des mesures que SGH utilise pour accorder à un hôte l’accès pour exécuter des machines virtuelles dotées d’une protection maximale.

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

  • 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 TPM.

Si vous pensez que c’est le cas avec votre TPM, vérifiez auprès de votre 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 TPM doit avoir un certificat EKcert mais qu’un certificat est introuvable dans le fichier d’identificateur de plateforme, vérifiez que vous utilisez une console PowerShell 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é 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 devriez être en mesure de s’exécuter Add-HgsAttestationTpmHost correctement.

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

Le compte de service SGH (gMSA utilisé pour le pool d’applications de service de protection de clé dans IIS) doit se voir accorder le privilège Générer des audits de sécurité , également appelé SeAuditPrivilege. Si ce privilège est manquant, la configuration initiale de SGH réussit et IIS démarre, mais le service de protection de clé 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 de l’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)

ou

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é (par exemple, Get-HgsKeyProtectionCertificate) ne fonctionne et retourne à la place des erreurs.

Pour résoudre ce problème, vous devez accorder à gMSA le « 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 stratégie de groupe. Vous pouvez également utiliser SecEdit.exe outil 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 le réimporter.

Remarque

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 les titulaires par défaut de ce privilège (service réseau et service local) en plus du compte gMSA que vous ajoutez.