Obtenir des certificats pour SGH
S’applique à : Windows Server 2022, Windows Server 2019, Windows Server 2016
Lorsque vous déployez SGH, vous êtes invité à fournir des certificats de signature et de chiffrement qui seront utilisés pour protéger les informations sensibles nécessaires au démarrage d’une machine virtuelle dotée d'une protection maximale. Ces certificats ne quittent jamais SGH. Ils sont utilisés pour déchiffrer les clés de machine virtuelle dotée d’une protection maximale uniquement quand l’hôte sur lequel ils s’exécutent a prouvé qu’il est sain. Les locataires (propriétaires de machines virtuelles) utilisent la moitié publique des certificats pour autoriser votre centre de données à exécuter leurs machines virtuelles dotées d’une protection maximale. Cette section décrit les étapes nécessaires à l’obtention de certificats de signature et de chiffrement compatibles pour SGH.
Demander des certificats à votre autorité de certification
Bien que cela ne soit pas obligatoire, il est vivement recommandé d’obtenir vos certificats auprès d’une autorité de certification approuvée. Cela permet aux propriétaires de machines virtuelles de vérifier qu’ils autorisent le serveur SGH approprié (c’est-à-dire le fournisseur de services ou le centre de données) à exécuter leurs machines virtuelles dotées d’une protection maximale. Dans un scénario d’entreprise, vous pouvez choisir d’utiliser votre propre AC d’entreprise pour émettre ces certificats. Les hébergeurs et les fournisseurs de services doivent utiliser à la place une autorité de certification publique bien connue.
Les certificats de signature et de chiffrement doivent être émis avec les propriétés de certificat suivantes (sauf si celles-ci portent la mention « recommandée ») :
| Propriété de modèle de certificat | Valeur requise |
|---|---|
| Fournisseur de chiffrement | N’importe quel fournisseur de stockage de clés (KSP). Les fournisseurs de services de chiffrement hérités ne sont pas pris en charge. |
| Algorithme de clé | RSA |
| Taille de clé minimale | 2 048 bits |
| Algorithme de signature | Recommandé : SHA256 |
| Utilisation de la clé | Signature numérique et chiffrement des données |
| Utilisation améliorée de la clé | Authentification du serveur |
| Stratégie de renouvellement des clés | Le renouvellement doit être effectué avec la même clé. Le renouvellement des certificats SGH avec des clés distinctes empêche le démarrage des machines virtuelles dotées d’une protection maximale. |
| Nom d'objet | Recommandé : nom ou adresse web de votre entreprise. Ces informations sont affichées à l’intention des propriétaires de machines virtuelles dans l’Assistant Fichier de données de protection. |
Ces impératifs s’appliquent, que vous utilisiez des certificats basés sur du matériel ou un logiciel. Pour des raisons de sécurité, il est recommandé de créer vos clés SGH dans un module HSM (module de sécurité matériel) pour empêcher la copie des clés privées en dehors du système. Suivez les conseils d’aide de votre fournisseur HSM pour demander des certificats avec les attributs ci-dessus. Veillez à installer et autoriser le fournisseur de stockage de clés (KSP) lié au module HSM sur chaque nœud SGH.
Chaque nœud SGH doit avoir accès aux mêmes certificats de signature et de chiffrement. Si vous utilisez des certificats basés sur un logiciel, vous pouvez les exporter vers un fichier PFX avec un mot de passe, et permettre à SGH de gérer les certificats à votre place. Vous pouvez également choisir d’installer les certificats dans le magasin de certificats de la machine locale sur chaque nœud SGH, et fournir l’empreinte numérique à SGH. Les deux options sont expliquées dans la rubrique Initialiser le cluster SGH.
Créer des certificats autosignés pour des scénarios de test
Si vous créez un environnement de labo SGH, et si vous ne disposez pas ou ne souhaitez pas utiliser d’autorité de certification, vous pouvez créer des certificats autosignés. Vous recevrez un avertissement au moment de l’importation des informations de certificat dans l’Assistant Fichier de données de protection, mais toutes les fonctionnalités resteront les mêmes.
Pour créer des certificats autosignés et les exporter vers un fichier PFX, exécutez les commandes suivantes dans PowerShell :
$certificatePassword = Read-Host -AsSecureString -Prompt 'Enter a password for the PFX file'
$signCert = New-SelfSignedCertificate -Subject 'CN=HGS Signing Certificate' -KeyUsage DataEncipherment, DigitalSignature
Export-PfxCertificate -FilePath '.\signCert.pfx' -Password $certificatePassword -Cert $signCert
# Remove the certificate from "Personal" container
Remove-Item $signCert.PSPath
# Remove the certificate from "Intermediate certification authorities" container
Remove-Item -Path "Cert:\LocalMachine\CA\$($signCert.Thumbprint)"
$encCert = New-SelfSignedCertificate -Subject 'CN=HGS Encryption Certificate' -KeyUsage DataEncipherment, DigitalSignature
Export-PfxCertificate -FilePath '.\encCert.pfx' -Password $certificatePassword -Cert $encCert
# Remove the certificate from "Personal" container
Remove-Item $encCert.PSPath
# Remove the certificate from "Intermediate certification authorities" container
Remove-Item -Path "Cert:\LocalMachine\CA\$($encCert.Thumbprint)"
Demander un certificat SSL
Toutes les clés et les informations sensibles transmises entre les hôtes Hyper-V et SGH sont chiffrées au niveau du message. En d’autres termes, les informations sont chiffrées à l’aide de clés connues de SGH ou d’Hyper-V. Ainsi, personne ne peut renifler votre trafic réseau pour voler les clés de vos machines virtuelles. Toutefois, si vous avez des impératifs de conformité, ou si vous préférez simplement chiffrer toutes les communications entre Hyper-V et SGH, vous pouvez configurer SGH avec un certificat SSL, qui chiffrera toutes les données au niveau du transport.
Les hôtes Hyper-V et les nœuds SGH doivent approuver le certificat SSL que vous fournissez. Il est donc recommandé de demander le certificat SSL à votre autorité de certification d’entreprise. Quand vous demandez le certificat, veillez à spécifier les éléments suivants :
| Propriété du certificat SSL | Valeur requise |
|---|---|
| Nom d'objet | Adresse utilisée par les clients SGH (autrement dit, les hôtes Service Guardian) pour accéder au serveur SGH. Il s’agit généralement de l’adresse DNS de votre cluster SGH, que l’on appelle nom de réseau distribué ou objet d’ordinateur virtuel (VCO). Il s’agit de la concaténation de votre nom de service SGH fourni à Initialize-HgsServer et de votre nom de domaine SGH. |
| Autre nom de l'objet | Si vous utilisez un autre nom DNS pour atteindre votre cluster SGH (par exemple s’il se trouve derrière un équilibreur de charge, ou si vous utilisez des adresses différentes pour un sous-ensemble de nœuds dans une topologie complexe), veillez à inclure ces noms DNS dans le champ SAN de votre demande de certificat. Notez que si l’extension SAN est renseignée, le nom de sujet est ignoré. Le SAN doit donc inclure toutes les valeurs, notamment celle que vous placez normalement dans le nom de sujet. |
Les options permettant de spécifier ce certificat au moment de l’initialisation du serveur SGH sont décrites dans Configurer le premier nœud SGH. Vous pouvez également ajouter ou changer le certificat SSL plus tard à l’aide de l’applet de commande Set-HgsServer.