Inscrire un ordinateur auprès du Service Guardian hôte
S’applique à :
SQL Server 2019 (15.x) et versions ultérieures - Windows uniquement
Cet article explique comment inscrire des ordinateurs SQL Server pour attester auprès du service Guardian hôte (SGH).
Note
Le processus d’inscription d’un serveur SQL Server auprès de SGH nécessite un effort conjoint de l’administrateur SGH et de l’administrateur d’ordinateur SQL Server. Consultez Rôles et responsabilités lors de la configuration de l’attestation avec SGH.
Avant de commencer, veillez à déployer au moins un ordinateur SGH et à configurer le service d’attestation SGH. Pour plus d’informations, consultez Déployer le service Guardian hôte pour SQL Server.
Étape 1 : Installer les composants du client d’attestation
Note
Cette étape doit être effectuée par l’administrateur de l’ordinateur SQL Server.
Pour permettre à un client SQL de vérifier qu’il parle à un ordinateur SQL Server digne de confiance, l’ordinateur SQL Server doit être attesté avec le service Guardian hôte. Le processus d’attestation est géré par un composant Windows facultatif appelé « client SGH ». Les étapes ci-dessous vous aideront à installer ce composant et à commencer l’attestation d’ordinateurs.
Vérifiez que l’ordinateur SQL Server répond aux conditions préalables décrites dans la documentation de planification du SGH.
Exécutez la commande suivante dans une console PowerShell avec élévation de privilèges pour installer la fonctionnalité Prise en charge d’Hyper-V Guardian hôte, celle-ci contenant le client SGH et les composants d’attestation.
Enable-WindowsOptionalFeature -Online -FeatureName HostGuardian -AllRedémarrez pour terminer l’installation.
Étape 2 : Vérifier que la sécurité basée sur la virtualisation est en cours d’exécution
Note
Cette étape doit être effectuée par l’administrateur de l’ordinateur SQL Server.
Quand vous installez la fonctionnalité Prise en charge d’Hyper-V Guardian hôte, la sécurité basée sur la virtualisation (VBS) est automatiquement configurée et activée.
Les enclaves pour SQL Server Always Encrypted sont protégées et exécutées dans l’environnement VBS.
VBS peut ne pas démarrer si aucun appareil IOMMU n’est installé et activé sur l’ordinateur.
Pour déterminer si VBS est en cours d’exécution, ouvrez l’outil Informations système en exécutant msinfo32.exe et recherchez les éléments Virtualization-based security dans la partie inférieure de Résumé système.
Le premier élément à examiner est Virtualization-based security. Il peut avoir l’une des trois valeurs suivantes :
Runningsignifie que la fonctionnalité VBS est correctement configurée et qu’elle a pu démarrer. Si l’ordinateur affiche cet état, vous pouvez passer à l’étape 3.Enabled but not runningsignifie que la fonctionnalité VBS est configurée pour s’exécuter, mais que le matériel ne répond pas aux exigences minimales de sécurité pour exécuter VBS. Vous devrez peut-être changer la configuration du matériel dans le BIOS ou l’UEFI pour activer des fonctionnalités de processeur facultatives comme une unité IOMMU. Ou, si le matériel ne prend vraiment pas en charge les fonctionnalités requises, vous devrez peut-être réduire les exigences de sécurité de VBS. Continuez à lire cette section pour en savoir plus.Not enabledsignifie que la fonctionnalité VBS n’est pas configurée pour s’exécuter. Étant donné que la fonctionnalité Prise en charge d’Hyper-V Guardian hôte active automatiquement VBS, nous vous recommandons de répéter l’étape 1 si vous voyez cet état.
Si VBS n’est pas en cours d’exécution sur l’ordinateur, examinez les propriétés Virtualization-based security. Comparez les valeurs de l’élément Required Security Properties à celles de l’élément Available Security Properties.
Les propriétés obligatoires doivent être égales aux propriétés de sécurité disponibles ou à un sous-ensemble de celles-ci pour que VBS s’exécute.
Dans le contexte de l’attestation des enclaves SQL Server, les propriétés de sécurité ont l’importance suivante :
- La propriété
Base virtualization supportest toujours obligatoire, car elle représente les fonctionnalités matérielles minimales pour exécuter un hyperviseur. Secure Bootest recommandé, mais pas obligatoire pour SQL Server Always Encrypted. Le démarrage sécurisé assure une protection contre les rootkits, car il exige l’exécution d’un chargeur de démarrage signé par Microsoft immédiatement après l’initialisation de l’UEFI. Si vous utilisez l’attestation du module de plateforme sécurisée (TPM), l’activation du démarrage sécurisé est mesurée et appliquée, que VBS soit configuré ou non pour exiger un démarrage sécurisé.DMA Protectionest recommandé, mais pas obligatoire pour SQL Server Always Encrypted. La protection DMA utilise une unité IOMMU pour protéger la mémoire de VBS et de l’enclave contre les attaques d’accès direct à la mémoire. Dans un environnement de production, vous devez toujours utiliser des ordinateurs avec une protection DMA. Dans un environnement de développement/test, vous pouvez supprimer l’obligation d’utiliser une protection DMA. Si l’instance SQL Server est virtualisée, vous n’aurez probablement pas de protection DMA disponible et vous devrez supprimer la configuration requise pour que VBS s’exécute. Pour plus d’informations sur la réduction des garanties de sécurité en cas d’exécution dans une machine virtuelle, passez en revue le modèle d’approbation.
Avant d’abaisser les fonctionnalités de sécurité exigées par VBS, contactez votre fabricant d’ordinateurs OEM ou votre fournisseur de services cloud afin de voir s’il existe un moyen d’activer les spécifications de plateforme manquantes dans l’UEFI ou le BIOS (par exemple, en activant le démarrage sécurisé, Intel VT-d ou AMD IOV).
Pour changer les fonctionnalités de sécurité de la plateforme obligatoires pour VBS, exécutez la commande suivante dans une console PowerShell avec élévation de privilèges :
# Value 0 = No security features required
# Value 1 = Only Secure Boot is required
# Value 2 = Only DMA protection is required (default configuration)
# Value 3 = Both Secure Boot and DMA protection are required
Set-ItemProperty -Path HKLM:\SYSTEM\CurrentControlSet\Control\DeviceGuard -Name RequirePlatformSecurityFeatures -Value 0
Après avoir modifié le Registre, redémarrez l’ordinateur SQL Server et vérifiez si VBS est en cours d’exécution.
Si l’ordinateur est géré par votre entreprise, la stratégie de groupe ou Microsoft Endpoint Manager peut remplacer les modifications que vous apportez à ces clés de Registre après le redémarrage. Contactez votre support technique pour savoir si des stratégies gérant votre configuration VBS sont déployées.
Étape 3 : Configurer l’URL d’attestation
Note
Cette étape doit être effectuée par l’administrateur de l’ordinateur SQL Server.
Ensuite, vous allez configurer l’ordinateur SQL Server avec l’URL du service d’attestation SGH, que vous avez obtenue auprès de l’administrateur SGH.
Dans une console PowerShell avec élévation de privilèges, mettez à jour et exécutez la commande suivante pour configurer l’URL d’attestation.
- Remplacez
hgs.bastion.localpar le nom du cluster SGH. - Vous pouvez exécuter
Get-HgsServersur n’importe quel ordinateur SGH pour récupérer le nom du cluster. - L’URL d’attestation doit toujours se terminer par
/Attestation. - SQL Server ne tirant pas parti des fonctionnalités de protection de clé de SGH, indiquez une URL factice comme
http://localhostpour-KeyProtectionServerUrl
Set-HgsClientConfiguration -AttestationServerUrl "https://hgs.bastion.local/Attestation" -KeyProtectionServerUrl "http://localhost"
À moins que vous n’ayez déjà inscrit cet ordinateur auprès de SGH, la commande signale un échec d’attestation. Ce résultat est normal.
Le champ AttestationMode dans la sortie de l’applet de commande indique le mode d’attestation utilisé par SGH.
Passez à l’étape 4A pour inscrire l’ordinateur en mode TPM ou à l’étape 4B pour l’inscrire en mode clé d’hôte.
Étape 4A : Inscrire un ordinateur en mode TPM
Note
Cette étape est effectuée conjointement par l’administrateur de l’ordinateur SQL Server et l’administrateur SGH. Pour plus d’informations, consultez les notes ci-dessous.
Préparation
Note
Cette action doit être effectuée par l’administrateur de l’ordinateur SQL Server.
Dans cette étape, vous collectez des informations sur l’état du TPM de l’ordinateur et l’inscrivez auprès de SGH.
Si le service d’attestation SGH est configuré pour utiliser le mode de clé d’hôte, passez plutôt à l’étape 4B.
Avant de commencer à collecter les mesures TPM, vérifiez que vous utilisez une configuration valide et connue de l’ordinateur SQL Server. L’ordinateur doit être équipé de tout le matériel nécessaire. Son microprogramme et ses logiciels doivent également être à jour. SGH mesure les ordinateurs par rapport à cette base de référence au moment de l’attestation. Il est donc important d’être dans l’état souhaité le plus sécurisé possible lors de la collecte des mesures du TPM.
Trois fichiers de données sont collectés pour l’attestation TPM, dont certains peuvent être réutilisés si vos ordinateurs sont configurés de manière identique.
| Artefact d’attestation | Ce qu’il mesure | Unicité |
|---|---|---|
| Identificateur de plateforme | Paire de clés de type EK (Endorsement Key) publique dans le TPM de l’ordinateur et certificat de paire de clés de type EK du fabricant du TPM. | 1 pour chaque ordinateur |
| Base de référence TPM | Registres de contrôle de plateforme (PCR) dans le TPM qui mesurent la configuration du microprogramme et du système d’exploitation chargée pendant le processus de démarrage. Citons par exemple l’état du démarrage sécurisé et le chiffrement ou non des vidages sur incident. | 1 base de référence par configuration d’ordinateur (un ordinateur aux caractéristiques matérielles et logiciels identiques peut utiliser la même base de référence) |
| Stratégie d’intégrité du code | Stratégie de contrôle d’application Windows Defender que vous approuvez pour protéger les ordinateurs | 1 par stratégie CI unique déployée sur les ordinateurs |
Vous pouvez configurer plusieurs artefacts d’attestation de chaque type sur SGH pour prendre en charge des configurations matérielles et logicielles diversifiées. SGH exige uniquement qu’un ordinateur en attente d’attestation respecte une stratégie dans chaque catégorie de stratégie. Par exemple, si vous avez trois bases de référence TPM inscrites sur SGH, il suffit que les mesures de l’ordinateur correspondent à l’une de ces bases de référence pour que les exigences de la stratégie soient satisfaites.
Configurer une stratégie d’intégrité du code
Note
Ces étapes ci-dessous doivent être effectuées par l’administrateur de l’ordinateur SQL Server.
SGH exige qu’une stratégie de contrôle d’application Windows Defender (WDAC) soit appliquée à chaque ordinateur en attente d’attestation en mode TPM. Les stratégies d’intégrité du code WDAC restreignent les logiciels qui peuvent s’exécuter sur un ordinateur. Pour cela, elles vérifient chaque processus qui tente d’exécuter du code par rapport à une liste d’éditeurs et de hachages de fichiers approuvés. Pour le cas d’usage SQL Server, les enclaves sont protégées par la sécurité basée sur la virtualisation et ne peuvent pas être modifiées à partir du système d’exploitation hôte. La rigueur de la stratégie WDAC n’affecte donc pas la sécurité des requêtes chiffrées. Par conséquent, il est recommandé de déployer une stratégie en mode audit sur les ordinateurs SQL Server pour répondre à l’exigence d’attestation sans imposer de restrictions supplémentaires sur le système.
Si vous utilisez déjà une stratégie d’intégrité du code WDAC personnalisée sur les ordinateurs pour renforcer la configuration du système d’exploitation, vous pouvez passer à Collecter les informations d’attestation du TPM.
Des exemples de stratégies prédéfinies sont disponibles sur Windows Server 2019, Windows 10 version 1809 et ultérieur. La stratégie
AllowAllpermet à n’importe quel logiciel de s’exécuter sur l’ordinateur sans aucune restriction. Convertissez la stratégie en une forme binaire comprise par le système d’exploitation et SGH pour pouvoir vous en servir. Dans une console PowerShell avec élévation de privilèges, exécutez les commandes suivantes pour compiler la stratégieAllowAll:# We are changing the policy to disable enforcement and user mode code protection before compiling $temppolicy = "$HOME\Desktop\allowall_edited.xml" Copy-Item -Path "$env:SystemRoot\schemas\CodeIntegrity\ExamplePolicies\AllowAll.xml" -Destination $temppolicy Set-RuleOption -FilePath $temppolicy -Option 0 -Delete Set-RuleOption -FilePath $temppolicy -Option 3 ConvertFrom-CIPolicy -XmlFilePath $temppolicy -BinaryFilePath "$HOME\Desktop\allowall_cipolicy.bin"Suivez les instructions du guide de déploiement du contrôle d’application Windows Defender pour déployer le fichier sur les ordinateurs SQL Server à l’aide de la
allowall_cipolicy.binstratégie de groupe. Pour les ordinateurs de groupe de travail, suivez le même processus à l’aide de l’Éditeur de stratégie de groupe locale (gpedit.msc).Exécutez
gpupdate /forcesur les ordinateurs SQL Server pour configurer la nouvelle stratégie d’intégrité du code, puis redémarrez les ordinateurs pour appliquer la stratégie.
Collecter les informations d’attestation du TPM
Note
Ces étapes ci-dessous doivent être effectuées par l’administrateur de l’ordinateur SQL Server.
Répétez les étapes suivantes pour chaque ordinateur SQL Server qui sera attesté avec HGS :
L’ordinateur étant dans un état valide connu, exécutez les commandes suivantes dans PowerShell pour collecter les informations d’attestation du TPM :
# Collects the TPM EKpub and EKcert $name = $env:computername $path = "$HOME\Desktop" (Get-PlatformIdentifier -Name $name).Save("$path\$name-EK.xml") # Collects the TPM baseline (current PCR values) Get-HgsAttestationBaselinePolicy -Path "$path\$name.tcglog" -SkipValidation # Collects the applied CI policy, if one exists Copy-Item -Path "$env:SystemRoot\System32\CodeIntegrity\SIPolicy.p7b" -Destination "$path\$name-CIpolicy.bin"Partagez les trois fichiers d’attestation avec l’administrateur SGH.
Inscrire l’ordinateur SQL Server auprès de SGH
Note
Les étapes ci-dessous doivent être effectuées par l’administrateur SGH.
Répétez les étapes suivantes pour chaque ordinateur SQL Server qui sera attesté avec HGS :
Copiez les fichiers d’attestation, que vous avez obtenus de l’administrateur d’ordinateur SQL Server sur le serveur SGH.
Sur le serveur SGH, exécutez les commandes suivantes dans une console PowerShell avec élévation de privilèges pour inscrire l’ordinateur SQL Server :
# TIP: REMEMBER TO CHANGE THE FILENAMES # Registers the unique TPM with HGS (required for every computer) Add-HgsAttestationTpmHost -Path "C:\temp\SQL01-EK.xml" # Registers the TPM baseline (required ONCE for each unique hardware and software configuration) Add-HgsAttestationTpmPolicy -Name "MyHWSoftwareConfig" -Path "C:\temp\SQL01.tcglog" # Registers the CI policy (required ONCE for each unique CI policy) Add-HgsAttestationCiPolicy -Name "AllowAll" -Path "C:\temp\SQL01-CIpolicy.bin"Astuce
Si vous rencontrez une erreur lors de l’inscription de l’identificateur TPM unique, vérifiez que vous avez importé les certificats racines et intermédiaires du TPM sur l’ordinateur SGH que vous utilisez.
Outre l’identificateur de plateforme, la base de référence TPM et la stratégie d’intégrité du code, vous devrez peut-être changer des stratégies intégrées qui sont configurées et appliquées par SGH. Ces stratégies intégrées sont mesurées par rapport à la base de référence TPM que vous collectez à partir du serveur et représentent un large éventail de paramètres de sécurité qui doivent être activés pour protéger l’ordinateur. Si vous avez des ordinateurs qui ne disposent pas d’une unité IOMMU pour vous protéger contre les attaques DMA (par exemple, une machine virtuelle), vous devez désactiver la stratégie IOMMU.
Pour désactiver l’exigence IOMMU, exécutez la commande suivante sur le serveur SGH :
Disable-HgsAttestationPolicy Hgs_IommuEnabled
Note
Si vous désactivez la stratégie IOMMU, aucune unité IOMMU ne sera exigée pour tout ordinateur en attente d’attestation par SGH. Vous ne pouvez pas désactiver la stratégie IOMMU pour un seul ordinateur.
Vous pouvez passer en revue la liste des stratégies et hôtes TPM inscrits à l’aide des commandes PowerShell suivantes :
Get-HgsAttestationTpmHost
Get-HgsAttestationTpmPolicy
Étape 4B : Inscrire un ordinateur en mode clé hôte
Note
Cette étape est effectuée conjointement par l’administrateur de l’ordinateur SQL Server et l’administrateur SGH. Pour plus d’informations, consultez les notes ci-dessous.
Cette étape vous guide tout au long du processus de génération d’une clé unique pour l’hôte et de son inscription auprès de SGH. Si le service d’attestation SGH est configuré pour utiliser le mode TPM, suivez plutôt les instructions de l’étape 4A.
Générer une clé pour un ordinateur SQL Server
Note
Cette partie doit être effectuée conjointement par l’administrateur de l’ordinateur SQL Server.
L’attestation de clé hôte fonctionne en générant une paire de clés asymétriques sur l’ordinateur SQL Server et en fournissant un SGH avec la moitié publique de cette clé.
Répétez les étapes suivantes pour chaque ordinateur SQL Server qui sera attesté avec HGS :
Pour générer la paire de clés, exécutez la commande suivante dans une console PowerShell avec élévation de privilèges :
Set-HgsClientHostKey Get-HgsClientHostKey -Path "$HOME\Desktop\$env:computername-key.cer"Si vous avez déjà créé une clé d’hôte et que vous souhaitez générer une nouvelle paire de clés, utilisez les commandes suivantes à la place :
Remove-HgsClientHostKey Set-HgsClientHostKey Get-HgsClientHostKey -Path "$HOME\Desktop\$env:computername-key.cer"Partagez le fichier de certificat avec l’administrateur SGH.
Inscrire l’ordinateur SQL Server auprès de SGH
Note
Les étapes ci-dessous doivent être effectuées par l’administrateur SGH.
Répétez les étapes suivantes pour chaque ordinateur SQL Server qui sera attesté avec HGS :
Copiez le fichier de certificat, que vous avez obtenu auprès de l’administrateur de l’ordinateur SQL Server, sur un serveur SGH.
Exécutez la commande suivante dans une console PowerShell avec élévation de privilèges pour inscrire l’ordinateur SQL Server :
Add-HgsAttestationHostKey -Name "YourComputerName" -Path "C:\temp\yourcomputername.cer"
Étape 5 : Confirmer que l’hôte peut attester correctement
Note
Cette étape doit être effectuée par l’administrateur de l’ordinateur SQL Server.
Une fois que vous avez inscrit l’ordinateur SQL Server auprès de SGH (étape 4A pour le mode TPM, étape 4B pour le mode clé hôte), vous devez confirmer qu’il est en mesure d’attester correctement.
Vous pouvez vérifier la configuration du client d’attestation SGH et effectuer une tentative d’attestation à tout moment avec Get-HgsClientConfiguration.
La sortie de la commande doit ressembler à ce qui suit :
PS C:\> Get-HgsClientConfiguration
IsHostGuarded : True
Mode : HostGuardianService
KeyProtectionServerUrl : http://localhost
AttestationServerUrl : http://hgs.bastion.local/Attestation
AttestationOperationMode : HostKey
AttestationStatus : Passed
AttestationSubstatus : NoInformation
FallbackKeyProtectionServerUrl :
FallbackAttestationServerUrl :
IsFallbackInUse : False
Les deux champs les plus importants de la sortie sont AttestationStatus (qui indique si l’ordinateur a obtenu l’attestation) et AttestationSubStatus (qui explique les stratégies que l’ordinateur n’a pas respectées en cas d’échec de l’attestation de l’ordinateur).
Les valeurs les plus courantes pouvant apparaître dans AttestationStatus sont expliquées ci-dessous :
AttestationStatus |
Explication |
|---|---|
| Expiré | L’hôte a déjà obtenu l’attestation, mais le certificat d’intégrité qu’il a reçu a expiré. Vérifiez que l’heure de l’hôte et celle du SGH sont synchronisées. |
InsecureHostConfiguration |
L’ordinateur n’a pas respecté une ou plusieurs des stratégies d’attestation configurées sur le serveur SGH. Pour plus d’informations, voir AttestationSubStatus. |
| NotConfigured | L’ordinateur n’est pas configuré avec une URL d’attestation. Configurez l’URL d’attestation. |
| Transmis(e) | L’ordinateur a passé l’attestation et est approuvé pour exécuter des enclaves SQL Server. |
TransientError |
La tentative d’attestation a échoué en raison d’une erreur temporaire. Cette erreur signifie généralement qu’un problème s’est produit au moment de contacter SGH sur le réseau. Examinez la connexion réseau et vérifiez que l’ordinateur peut résoudre et acheminer le nom du service SGH. |
TpmError |
L’appareil TPM de l’ordinateur a signalé une erreur durant la tentative d’attestation. Consultez les journaux TPM pour plus d’informations. L’effacement du TPM peut résoudre le problème, mais veillez à suspendre BitLocker et d’autres services qui reposent sur le TPM avant de l’effacer. |
UnauthorizedHost |
La clé d’hôte n’est pas connue du SGH. Suivez les instructions de l’étape 4B pour inscrire l’ordinateur auprès de SGH. |
Si AttestationStatus indique InsecureHostConfiguration, le champ AttestationSubStatus contient un ou plusieurs noms de stratégie ayant échoué.
Le tableau ci-dessous liste les valeurs les plus courantes et explique comment corriger les erreurs.
| AttestationSubStatus | Ce que cela signifie et que faire |
|---|---|
| CodeIntegrityPolicy | La stratégie d’intégrité du code sur l’ordinateur n’est pas inscrite auprès du SGH ou l’ordinateur n’utilise pas actuellement de stratégie d’intégrité du code. Pour obtenir de l’aide, consultez Configurer une stratégie d’intégrité du code. |
| DumpsEnabled | L’ordinateur est configuré pour autoriser les vidages sur incident, mais la stratégie Hgs_DumpsEnabled interdit les vidages. Désactivez les vidages sur cet ordinateur ou désactivez la stratégie Hgs_DumpsEnabled pour continuer. |
| FullBoot | L’ordinateur est sorti d’un état de veille ou de veille prolongée, ce qui a entraîné des changements au niveau des mesures TPM. Redémarrez l’ordinateur pour générer des mesures TPM propres. |
| HibernationEnabled | L’ordinateur est configuré pour autoriser la mise en veille prolongée avec des fichiers de mise en veille prolongée non chiffrés. Pour résoudre ce problème, désactivez la mise en veille prolongée sur l’ordinateur. |
| HypervisorEnforcedCodeIntegrityPolicy | L’ordinateur n’est pas configuré pour utiliser une stratégie d’intégrité du code. Vérifiez la stratégie de groupe ou la stratégie de groupe locale > Configuration ordinateur > Modèles d’administration > Système > Protection du périphérique > Activer la sécurité basée sur la virtualisation > Protection basée sur la virtualisation de l’intégrité du code. Cet élément de stratégie doit être « activé sans verrouillage de l’UEFI ». |
| Iommu | Aucune appareil IOMMU n’est activé sur cet ordinateur. S’il s’agit d’un ordinateur physique, activez l’unité IOMMU dans le menu Configuration UEFI. S’il s’agit d’une machine virtuelle et qu’aucune unité IOMMU n’est disponible, exécutez Disable-HgsAttestationPolicy Hgs_IommuEnabled sur le serveur SGH. |
| SecureBoot | Le démarrage sécurisé n’est pas activé sur cet ordinateur. Activez le démarrage sécurisé dans le menu de configuration UEFI pour résoudre cette erreur. |
| VirtualSecureMode | La sécurité basée sur la virtualisation n’est pas en cours d’exécution sur cet ordinateur. Suivez les instructions de l’étape 2 : vérifiez que VBS est en cours d’exécution sur l’ordinateur. |
Étapes suivantes
Commentaires
Bientôt disponible : Tout au long de 2024, nous allons supprimer progressivement GitHub Issues comme mécanisme de commentaires pour le contenu et le remplacer par un nouveau système de commentaires. Pour plus d’informations, consultez https://aka.ms/ContentUserFeedback.
Envoyer et afficher des commentaires pour