¶ Importance
Avec les vSphere Trusted Environments et le Virtual Machine Encryption, vous pouvez chiffrer vos hôtes ESXi et vos charges de travail sensibles d’une manière encore plus sécurisée.
¶ Leçons du Module
- Démarrage sécurisé d’un hôte ESXi
- Sécurisation des machines virtuelles
- Chiffrement des machines virtuelles (VM Encryption)
- Fournisseurs de clés (Key Providers)
- Autorité de confiance vSphere (vSphere Trust Authority)
¶ Leçon 1 : Démarrage sécurisé d’ESXi
¶ Objectifs d’apprentissage
- Utiliser UEFI Secure Boot pour les hôtes ESXi
- Planifier le démarrage sécurisé et la prise en charge de TPM 2.0 pour un hôte ESXi
¶ UEFI Secure Boot pour les hôtes ESXi
UEFI Secure Boot fait partie de la norme du firmware Unified Extensible Firmware Interface (UEFI).
Avec UEFI Secure Boot activé, une machine refuse de charger tout pilote UEFI sauf si le chargeur de démarrage du système d’exploitation est signé cryptographiquement.
ESXi prend en charge UEFI Secure Boot s’il est activé dans le matériel.
Pour garantir que le code de démarrage est exécuté sans modification, UEFI utilise une signature numérique fournie par un créateur de code de confiance.
La signature numérique est intégrée dans chaque section de code exécutable.
À l’aide d’une paire de clés publique-privée, le créateur du code signe le code avec une clé privée, qui peut ensuite être vérifiée par rapport à la clé publique préinstallée avant l’exécution du code.
Si le code exécutable est marqué comme modifié ou invalide, il n’est pas exécuté dans le processus de démarrage.
Le système peut alors adopter un autre chemin de démarrage, ou l’utilisateur peut être notifié afin de prendre des mesures correctives.
¶ Séquence de démarrage sécurisé UEFI pour les hôtes ESXi
ESXi prend en charge UEFI Secure Boot à chaque niveau de la pile de démarrage.
La séquence de démarrage se déroule comme suit :
-
Le bootloader ESXi contient une clé publique VMware.
Le bootloader utilise cette clé pour vérifier la signature du noyau (kernel) et d’un petit sous-ensemble du système qui inclut un Secure Boot VIB Verifier. -
Le VIB verifier vérifie chaque paquet VIB installé sur le système.
À ce stade, l’ensemble du système démarre avec la racine de confiance (root of trust) contenue dans les certificats faisant partie du firmware UEFI.
¶ Dépannage du démarrage sécurisé UEFI
Après avoir installé ESXi sur une machine hôte en mode UEFI, il se peut que la machine ne parvienne pas à démarrer.
Si un paquet (VIB ou driver) a été altéré, vous rencontrerez un écran violet.
Pour résoudre les problèmes liés au secure boot, procédez comme suit :
- Redémarrez l’hôte avec le secure boot désactivé.
- Exécutez le script de vérification du secure boot.
(Pour plus d’informations sur l’exécution du script Run the Secure Boot Validation Script on an Upgraded ESXi Host, consultez : https://docs.vmware.com/en/VMware-vSphere/8.0/vsphere-esxi-upgrade/GUID-DD075A38-8900-459F-BD9D-69DC87CCE11B.html) - Examinez les informations dans le fichier /var/log/esxupdate.log.
¶ Script de validation du démarrage sécurisé UEFI
L’exécution du secure boot validation script permet de vérifier si un hôte ESXi peut démarrer avec le secure boot activé ou non.
Avant d’exécuter le script, vous devez vérifier :
- Que le hardware prend en charge UEFI Secure Boot
- Que tous les VIBs sont signés avec un niveau d’acceptation d’au moins PartnerSupported
Si l’hôte ESXi contient des VIBs non signés, le script de validation échouera.
Si vous incluez des VIBs au niveau CommunitySupported, vous ne pouvez pas utiliser le secure boot.
¶ TPM 2.0 sur les hôtes ESXi
vSphere 6.7 a introduit la prise en charge du TPM 2.0.
ESXi peut utiliser des puces Trusted Platform Module (TPM) pour renforcer la sécurité des hôtes.
Le TPM protège les utilisateurs contre les attaques logicielles visant à voler des informations sensibles en corrompant le code système ou le BIOS, ou en modifiant la configuration de la plateforme.
Le TPM est une norme industrielle pour les cryptoprocesseurs sécurisés. Le Trusted Computing Group (TCG) est responsable des spécifications techniques du TPM.
Le microprocesseur dédié sécurise le matériel en intégrant des clés cryptographiques dans les appareils.
Vous devez avoir le UEFI Secure Boot activé pour pouvoir activer le TPM 2.0.
Lorsque vous installez ou mettez à niveau vers vSphere 7.0 Update 2 ou une version ultérieure, et qu’un hôte ESXi dispose d’un TPM, celui-ci scelle les informations sensibles à l’aide d’une politique TPM basée sur les valeurs PCR pour le UEFI Secure Boot.
Cette valeur est ensuite chargée lors des redémarrages suivants si la politique est validée comme vraie.
¶ Prise en charge de Quick Boot sur les serveurs ESXi avec processeur TPM 2.0
Les hôtes avec TPM 2.0 activé passent par un processus de démarrage sécurisé (secure boot) et d’attestation, qui vérifie la configuration de l’hôte.
Ce mécanisme constitue un moyen efficace de détecter et de se protéger contre les logiciels malveillants et d’autres erreurs de configuration.
Introduit dans vSphere 8 Update 1, Quick Boot est désormais compatible avec TPM 2.0.
Quick Boot est utilisé dans les activités de gestion du cycle de vie telles que les mises à jour, correctifs, montées de version, etc., et permet de gagner un temps considérable.
¶ À propos de l’attestation à distance
Le matériel TPM atteste de l’identité d’un hôte ESXi.
Ce processus est appelé attestation à distance (Remote Attestation).
L’attestation à distance permet d’authentifier et d’attester l’état du logiciel de l’hôte à un moment donné.
Le matériel TPM enregistre et stocke en toute sécurité les mesures de l’image de l’hyperviseur :
- Les mesures sont enregistrées dans les Registres de configuration de la plateforme (PCR — Platform Configuration Registers).
- L’état enregistré de ces mesures est appelé une citation (quote).
- Ces mesures peuvent être utilisées pour détecter tout changement concernant les éléments pouvant être chargés en mémoire.
¶ QCM : Démarrage sécurisé ESXi
Laquelle des affirmations suivantes décrit avec précision le comportement d’un hôte ESXi lorsque UEFI Secure Boot est activé et qu’une signature VIB invalide est détectée pendant la séquence de démarrage ?
☐ Un écran violet s’affiche, indiquant que le démarrage sécurisé UEFI a échoué en raison d’un VIB invalide.
☐ L’hôte continue de démarrer normalement sans aucune indication de l’échec du démarrage sécurisé UEFI.
☐ Le démarrage sécurisé UEFI ne peut pas être activé sur un hôte ESXi, donc ce scénario n’est pas applicable.
☐ L’hôte désactive automatiquement le démarrage sécurisé UEFI et poursuit le processus de démarrage.
¶ Réponses : Démarrage sécurisé ESXi
Laquelle des affirmations suivantes décrit avec précision le comportement d’un hôte ESXi lorsque UEFI Secure Boot est activé et qu’une signature VIB invalide est détectée pendant la séquence de démarrage ?
✓ Un écran violet s’affiche, indiquant que le démarrage sécurisé UEFI a échoué en raison d’un VIB invalide.
☐ L’hôte continue de démarrer normalement sans aucune indication de l’échec du démarrage sécurisé UEFI.
☐ Le démarrage sécurisé UEFI ne peut pas être activé sur un hôte ESXi, donc ce scénario n’est pas applicable.
☐ L’hôte désactive automatiquement le démarrage sécurisé UEFI et poursuit le processus de démarrage.
¶ Revue des objectifs d’apprentissage
- Utiliser le démarrage sécurisé UEFI Secure Boot pour les hôtes ESXi.
- Planifier la prise en charge du démarrage sécurisé et de TPM 2.0 pour un hôte ESXi.
¶ Leçon 2 : Sécurisation des machines virtuelles (VMs)
¶ Objectifs d’apprentissage
- Identifier le rôle de vTPM et VBS dans la sécurisation des machines virtuelles.
- Avec les Intel Software Guard Extensions (SGX), les programmes peuvent créer des régions mémoire privées appelées enclaves.
- Secure Encrypted Virtualization with Encrypted State (SEV-ES) est une fonctionnalité matérielle activée dans les processeurs AMD.
- Activer la vMotion chiffrée de vSphere.
¶ Protection des machines virtuelles avec UEFI Secure Boot
Vous pouvez activer le démarrage sécurisé UEFI (UEFI Secure Boot) dans une machine virtuelle (VM) si les conditions préalables suivantes sont remplies :
- La VM utilise un micrologiciel EFI.
- Le système d’exploitation invité prend en charge le démarrage sécurisé UEFI.
- Le matériel virtuel est de version 13 ou supérieure.
Pour prendre en charge efficacement UEFI Secure Boot dans une VM, consultez la documentation du fournisseur du système d’exploitation invité concernant la configuration et l’utilisation du micrologiciel EFI.
Pour certaines versions matérielles de VM et certains systèmes d’exploitation, vous activez UEFI Secure Boot exactement de la même manière que pour une machine physique.
Dans un système d’exploitation prenant en charge UEFI Secure Boot, chaque composant du logiciel de démarrage est signé, y compris le chargeur d’amorçage, le noyau du système d’exploitation et les pilotes du système d’exploitation.
La configuration par défaut d’une VM inclut plusieurs certificats de signature de code :
- Un certificat Microsoft utilisé uniquement pour le démarrage de Windows.
- Un certificat Microsoft utilisé pour le code tiers signé par Microsoft, tel que les chargeurs d’amorçage Linux.
- Un certificat VMware utilisé uniquement pour démarrer ESXi à l’intérieur d’une machine virtuelle.
La configuration par défaut de la VM inclut également un certificat permettant d’authentifier les demandes de modification de la configuration UEFI Secure Boot, y compris la liste de révocation du démarrage sécurisé UEFI à partir de la machine virtuelle.
Ce certificat est une clé de chiffrement Microsoft (KEK).
Dans la plupart des cas, il n’est pas nécessaire de remplacer les certificats existants.
Pour obtenir une liste des systèmes d’exploitation qui prennent en charge UEFI Secure Boot, consultez le VMware Compatibility Guide à l’adresse suivante : https://www.vmware.com/resources/compatibility
¶ vTPM virtuel sur les hôtes ESXi
Le TPM virtuel VMware (vTPM) est compatible avec TPM 2.0 et crée une puce TPM virtuelle utilisable par la machine virtuelle et le système d’exploitation invité qu’elle héberge.
Le vTPM prend en charge les opérations de clonage et de réattribution de clé avec vSphere Native Key Provider, Standard Key Provider et vSphere Trust Authority.
vSphere 8 a introduit la compatibilité avec le format OVF pour les machines virtuelles équipées de périphériques vTPM.
¶ Utilisation du vTPM dans une machine virtuelle
vSphere 6.7 a introduit la prise en charge du Virtual Trusted Platform Module (vTPM).
Grâce à ce dispositif, vous pouvez ajouter un cryptoprocesseur virtuel TPM 2.0 à une machine virtuelle (VM).
Le vTPM virtuel prend en charge les opérations de clonage et de réattribution de clés avec vSphere Native Key Provider, Standard Key Provider et vSphere Trust Authority.
Un vTPM est une émulation logicielle des fonctionnalités d’un TPM matériel :
- Le système d’exploitation invité peut créer et stocker des clés privées de manière sécurisée, sans jamais les exposer.
- Le système d’exploitation invité peut utiliser ces clés privées pour le chiffrement ou la signature.
Avec un vTPM, un tiers peut attester à distance (valider) l’identité du firmware et du système d’exploitation invité.
Cas d’utilisation du vTPM :
- Un système d’exploitation peut vérifier que le firmware chargé n’a pas été compromis depuis le dernier démarrage.
- Une application peut vérifier que le système d’exploitation ne contient aucun composant malveillant.
Compromettre le système d’exploitation invité compromet souvent ses secrets internes,
mais activer un vTPM dans la machine virtuelle réduit considérablement ce risque.
Vous pouvez ajouter un vTPM à une nouvelle VM ou à une VM existante.
Introduit avec vSphere 8, le vTPM est désormais compatible avec le format OVF pour les machines virtuelles disposant de périphériques vTPM.
- Le vTPM utilise la technologie de chiffrement des machines virtuelles (VM Encryption) pour sécuriser les données du module TPM virtuel.
- Lorsque vous configurez un vTPM, le chiffrement des VM crypte automatiquement le répertoire principal de la machine virtuelle (qui contient les fichiers
*.nvram,*.vmx,*.vmsn, les instantanés, les fichiers de mémoire, etc.), mais pas les disques. - Vous pouvez choisir d’ajouter un chiffrement explicite pour la machine virtuelle et ses disques à l’aide de la fonction VM Encryption.
- Vous pouvez sauvegarder une machine virtuelle équipée d’un vTPM :
— La sauvegarde doit inclure toutes les données de la VM, y compris le fichier .nvram.
— Si votre sauvegarde n’inclut pas le fichier .nvram, vous ne pouvez pas restaurer une VM avec un vTPM.
— Comme les fichiers principaux de la VM sont chiffrés, vous devez vous assurer que les clés de chiffrement sont disponibles au moment de la restauration. - Vous pouvez supprimer un vTPM d’une machine virtuelle.
Cependant, la suppression d’un vTPM rend toutes les données chiffrées de la machine virtuelle irrécupérables. - Avant de supprimer un vTPM d’une VM, désactivez toutes les applications du système d’exploitation invité qui utilisent le vTPM.
Le vTPM peut être activé sur une VM en modifiant les paramètres de celle-ci via le vSphere Client.
Le vTPM peut être supprimé d’une VM, mais la machine virtuelle doit être éteinte au préalable.
Avant de retirer le vTPM, désactivez toutes les applications qui l’utilisent.
Si vous ne désactivez pas ces applications, la machine virtuelle pourrait ne pas démarrer lors de la mise sous tension.
¶ Conditions préalables à l’ajout d’un vTPM
Pour utiliser un vTPM, votre environnement vSphere doit répondre à des exigences spécifiques :
¶ Exigences relatives aux composants :
- ESXi 6.7 ou version ultérieure
- vCenter Server 6.7 ou version ultérieure pour les machines virtuelles Windows,
vCenter Server 7.0 Update 2 ou version ultérieure pour les machines virtuelles Linux. - Serveur de gestion de clés (interne ou externe) configuré dans vCenter pour chiffrer une machine virtuelle.
¶ Exigences relatives à la machine virtuelle :
- Firmware EFI
- Version matérielle de la VM 14 ou ultérieure
- Windows 10 (64 bits) ou Windows Server 2016 (64 bits) ou système d’exploitation invité plus récent
Le vTPM ne nécessite pas la présence d’une puce TPM 2.0 physique sur l’hôte ESXi.
Cependant, si vous souhaitez effectuer une attestation d’hôte, une entité externe, telle qu’une puce TPM 2.0 physique, est requise.
¶ Tolérance aux pannes vSphere avec vTPM
Introduit dans vSphere 8 Update 1, la Tolérance aux pannes (Fault Tolerance) pour une machine virtuelle utilisant un module vTPM est désormais prise en charge.
Cette fonctionnalité aide les administrateurs à assurer une disponibilité continue et une sécurité renforcée pour les machines virtuelles critiques.
La Tolérance aux pannes fournit une disponibilité continue pour une machine virtuelle en maintenant une VM identique qui peut rapidement prendre le relais en cas de défaillance.
¶ Sécurité basée sur la virtualisation pour les systèmes d’exploitation invités Windows
Windows 10 et Windows Server 2016 (versions 64 bits uniquement) intègrent une technologie de sécurité appelée sécurité basée sur la virtualisation (VBS – Virtualization-Based Security).
VBS utilise la technologie de virtualisation Hyper-V de Microsoft pour isoler les services principaux du système d’exploitation Windows dans un environnement virtualisé.
Cet environnement virtualisé offre les avantages de sécurité suivants :
- Un niveau de protection supplémentaire pour les services clés de Windows
- Un environnement d’exécution isolé pour les activités des utilisateurs
- Une meilleure protection du système d’exploitation hôte contre les attaques
La sécurité basée sur la virtualisation (VBS) de Microsoft — une fonctionnalité de Windows 10 et Windows Server 2016 (et des versions ultérieures) — utilise la virtualisation matérielle et logicielle pour renforcer la sécurité du système en créant un sous-système isolé, restreint par l’hyperviseur et spécialisé.
Avec VBS, vous pouvez utiliser les fonctionnalités de sécurité Windows suivantes pour renforcer votre système et isoler les secrets clés du système et des utilisateurs afin qu’ils ne soient pas compromis :
- Credential Guard : vise à isoler et à protéger les secrets système et utilisateur clés contre toute compromission.
- Device Guard : fournit un ensemble de fonctionnalités qui fonctionnent ensemble pour empêcher et éliminer les logiciels malveillants sur un système Windows.
- Configurable Code Integrity : garantit que seul le code de confiance s’exécute, à partir du chargeur de démarrage.
Pour plus d’informations sur la sécurité basée sur la virtualisation, consultez la documentation Microsoft.
¶ Exigences et limitations de VBS
Pour utiliser VBS dans une machine virtuelle (VM), vous devez respecter les prérequis suivants :
- La machine virtuelle doit être de version matérielle 14 ou ultérieure.
- Le système d’exploitation invité doit être Windows 10 ou Windows Server 2016, ou une version ultérieure (64 bits).
- La VM doit s’exécuter sur un hôte ESXi version 6.7 ou ultérieure pour les hôtes basés sur Intel, et 7.0 Update 2 ou ultérieure pour les hôtes basés sur AMD.
Les machines virtuelles avec VBS activé utilisent UEFI et le démarrage sécurisé (Secure Boot) par défaut.
Les fonctionnalités suivantes ne sont pas prises en charge avec VBS :
- vSphere Fault Tolerance
- Passage PCI (PCI passthrough)
- Ajout à chaud de processeur ou de mémoire (Hot add of CPU or memory)
L’utilisation de processeurs AMD pour VBS nécessite vSphere 7.0 Update 2 ou une version ultérieure.
¶ Activation de VBS
Pour activer VBS lors de la création d’une machine virtuelle (VM), sélectionnez Windows 10 ou Windows Server 2016 (ou version ultérieure), puis cochez la case Enable Windows Virtualization Based Security (Activer la sécurité Windows basée sur la virtualisation).
L’activation de VBS expose au système d’exploitation invité plusieurs fonctionnalités d’assistance matérielle la virtualisation assistée par matériel, la gestion de la mémoire d’entrée-sortie (IOMMU), le firmware EFI et le démarrage sécurisé UEFI (Secure Boot).
Après avoir activé VBS pour une machine virtuelle, vous devez également activer VBS à l’intérieur du système d’exploitation invité.
¶ À propos de SGX
La technologie Intel Software Guard Extensions (SGX) répond aux besoins de l’informatique de confiance (trusted computing).
L’informatique de confiance fait référence à diverses technologies et propositions visant à résoudre les problèmes de sécurité informatique :
- Avec Intel SGX, les programmes peuvent créer des régions de mémoire privées appelées enclaves.
- Les données contenues dans ces enclaves ne peuvent être consultées que par le programme qui les a créées.
- La région de l’enclave est isolée des autres programmes, systèmes d’exploitation, hyperviseurs, etc.
- Les enclaves sont utilisées par les programmes pour sécuriser les données.
- Le vSGX (Virtual SGX) expose la technologie SGX d’Intel aux machines virtuelles (VM) exécutées dans un environnement vSphere.
Ces problèmes sont résolus par des améliorations matérielles et des modifications logicielles associées.
Plusieurs grands fabricants de matériel et éditeurs de logiciels, collectivement connus sous le nom de Trusted Computing Group (TCG), coopèrent dans ce projet et établissent des plans spécifiques.
Pour plus d’informations sur le Trusted Computing Group, consultez : https://trustedcomputinggroup.org
Les données contenues dans une application peuvent être compromises par un logiciel malveillant ou un bogue du système d’exploitation ou de l’hyperviseur.
Les programmeurs peuvent utiliser Intel SGX pour créer des enclaves, c’est-à-dire des régions de mémoire privées. Les données contenues dans ces enclaves sont protégées contre l’accès et la modification non autorisés, même par des logiciels malveillants exécutés à des niveaux de privilèges supérieurs. Intel SGX offre cette protection sans perturber la capacité du logiciel légitime à planifier et gérer l’utilisation des ressources de la plateforme.
Le vSGX est implémenté dans la pile de virtualisation principale de vSphere.
Grâce à vSGX, les applications exécutées sur des machines virtuelles peuvent créer leurs propres enclaves.
¶ À propos de AMD SEV-ES
La technologie SEV-ES (Secure Encrypted Virtualization with Encrypted State) est une fonctionnalité matérielle intégrée aux processeurs AMD.
SEV-ES chiffre la mémoire de la machine virtuelle (VM) et l’état des registres, protégeant ainsi ces données contre tout accès par l’hyperviseur ou d’autres machines virtuelles fonctionnant sur le même hyperviseur.
¶ À propos de vSphere vMotion chiffré
Le vSphere vMotion chiffré garantit la confidentialité, l’intégrité et l’authenticité des données transférées lors d’une tâche vMotion.
Le vSphere vMotion chiffré prend en charge toutes les variantes de vSphere vMotion pour les machines virtuelles non chiffrées, y compris la migration entre différentes instances et versions de vCenter.
Le vSphere vMotion chiffré sécurise la communication sur le réseau vMotion afin que les données sensibles ne puissent pas être interceptées pendant la migration de la mémoire.
vCenter génère une clé de chiffrement à usage unique (nonce) et inclut cette clé dans une communication (ou spécification de migration) entre l’hôte ESXi source et l’hôte ESXi de destination. Cette clé est utilisée pour chiffrer et déchiffrer les données transmises sur le réseau vMotion.
Lors d’une migration vSphere vMotion entre différentes instances de vCenter, l’instance vCenter locale génère la clé de chiffrement et l’inclut dans une communication sécurisée via TLS vers l’instance vCenter distante. Les deux instances de vCenter transmettent ensuite les clés requises à leurs hôtes ESXi respectifs, qui communiquent directement à l’aide de ces clés.
Pour les disques chiffrés, les données sont toujours transmises sous forme chiffrée.
Pour les disques non chiffrés, les conditions suivantes s’appliquent :
- Si les données du disque sont transférées au sein du même hôte (par exemple lors d’un changement de datastore), le transfert est non chiffré.
- Si les données sont transférées entre plusieurs hôtes et que le vMotion chiffré est activé, le transfert est chiffré.
- Si le vMotion chiffré n’est pas activé, le transfert reste non chiffré.
Pour les machines virtuelles déjà chiffrées, la migration avec vSphere vMotion utilise toujours le vMotion chiffré.
Il est impossible de désactiver le vMotion chiffré pour les VMs chiffrées.
¶ Configuration de vSphere vMotion chiffré
vSphere vMotion utilise toujours le chiffrement lors de la migration des machines virtuelles chiffrées.
Pour les machines virtuelles non chiffrées, vous pouvez modifier les paramètres de la VM pour utiliser l’un des états suivants :
- Désactivé (Disabled) : ne pas utiliser vSphere vMotion chiffré.
- Opportuniste (Opportunistic – par défaut) : utiliser vSphere vMotion chiffré si les hôtes source et de destination le prennent en charge.
- Obligatoire (Required) : utiliser uniquement vSphere vMotion chiffré.
¶ Revue des objectifs d’apprentissage
- Identifier le rôle du vTPM et de la VBS dans la sécurisation des machines virtuelles.
- Avec les Intel Software Guard Extensions (SGX), les programmes peuvent créer des régions de mémoire privées appelées enclaves.
- La Virtualisation Sécurisée Chiffrée avec État Chiffré (SEV-ES) est une fonctionnalité matérielle activée dans les processeurs AMD.
- Activer le vSphere vMotion chiffré.
¶ Leçon 3 : Chiffrement des machines virtuelles (VM Encryption)
¶ Objectifs d’apprentissage
- Décrire les composants d’une architecture de chiffrement de machine virtuelle
- Gérer les machines virtuelles chiffrées
- Utiliser le chiffrement avec les clones instantanés
- Migrer des machines virtuelles chiffrées
- Lister les événements et alarmes liés au chiffrement des machines virtuelles
¶ À propos du chiffrement des machines virtuelles (VM Encryption)
Le chiffrement des machines virtuelles fournit plusieurs fonctions.
| Fonction | Description |
|---|---|
| Chiffrement | • Protection des disques VM et des fichiers de métadonnées, tels que .nvram et .vswp• Protection multicouche des clés |
| Orchestration | • Déploiement simplifié à l’aide de politiques de stockage • Agnostique : • Indépendant du stockage • Indépendant du système d’exploitation invité |
| Contrôle des clés | • Gestion des clés assurée par des serveurs de clés et le vSphere Native Key Provider • Utilisation de la norme KMIP (Key Management Interoperability Protocol) • Non-persistance des clés pour une sécurité accrue |
| Contrôle d’accès | • Rôle défini pour les administrateurs ne disposant pas d’autorisations de chiffrement • Tâches cryptographiques autorisées uniquement pour les administrateurs disposant des permissions appropriées |
Le chiffrement des machines virtuelles protège non seulement les données présentes sur le disque, mais aussi le fichier d’échange (swap file) et toute information spécifique à l’invité qui pourrait être contenue dans les fichiers .vmx ou .nvram.
Le chiffrement des VM met également en œuvre un mécanisme de protection multicouche des clés, rendant la compromission de la sécurité de la VM quasiment impossible.
Le chiffrement des VM simplifie la configuration grâce aux capacités d’orchestration des politiques de stockage vCenter.
Grâce à ces politiques, il est possible d’appliquer le chiffrement à tout type de machine virtuelle, indépendamment du système d’exploitation invité ou du stockage utilisé.
En utilisant des serveurs de clés externes de niveau entreprise, le risque d’exposition est limité, car vSphere n’a pas besoin de gérer ni de conserver les clés sur disque au sein de l’environnement vSphere. En adoptant la norme KMIP (Key Management Interoperability Protocol), vSphere peut s’intégrer à différents fournisseurs et produits de serveurs de gestion de clés (KMS).
Depuis vSphere 7.0 Update 2, vous pouvez utiliser le vSphere Native Key Provider intégré pour activer des technologies de chiffrement telles que les TPM virtuels (vTPM).
Vous pouvez restreindre l’accès aux opérations cryptographiques en appliquant des rôles et permissions aux utilisateurs.
Seuls les utilisateurs disposant des autorisations nécessaires peuvent effectuer des tâches cryptographiques, telles que le chiffrement ou le déchiffrement d’une machine virtuelle.
¶ Vue d’ensemble du chiffrement des machines virtuelles (VM Encryption)
En activant le chiffrement sur les machines virtuelles (VM), vous pouvez protéger vos données confidentielles.
Le chiffrement des machines virtuelles a été introduit avec vSphere 6.5.
- Les disques de machines virtuelles (VMDK) sont chiffrés et ne peuvent être accessibles qu’à l’aide d’une clé numérique.
- Le contrôle d’accès vSphere limite l’accès à la clé numérique nécessaire pour le déchiffrement.
- Les données en transit sont également chiffrées.
Par exemple, la communication réseau entre la machine virtuelle chiffrée et d’autres systèmes en réseau — y compris d’autres machines virtuelles, des machines physiques ou des périphériques externes — est protégée.
¶ Interopérabilité du chiffrement des machines virtuelles
À partir de vSphere 6.7 :
-
Le clonage est pris en charge, sous certaines conditions.
— Les clones complets sont pris en charge.
— Les clones liés (linked clones) sont également pris en charge, et le clone hérite de l’état de chiffrement du parent, y compris des clés. -
Une VM chiffrée peut être reprendre à partir d’un état suspendu.
-
Une VM chiffrée peut être restaurée à partir d’un instantané mémoire.
-
Les VM chiffrées disposant d’un instantané mémoire et d’un état suspendu peuvent être migrées entre hôtes ESXi.
-
Les VM chiffrées doivent être éteintes pour la plupart des opérations de chiffrement de VM, à l’exception des cas suivants :
— Une VM chiffrée sous tension peut être clonée.
— Un re-chiffrement partiel (shallow recrypt) peut être effectué sur une VM chiffrée sous tension. -
Toutes les solutions de sauvegarde qui utilisent les API vSphere Storage – Data Protection pour la sauvegarde des disques virtuels ne sont pas forcément compatibles avec le chiffrement des VM.
Le chiffrement des machines virtuelles vSphere présente certaines limitations concernant les périphériques et les fonctionnalités avec lesquels il peut interagir à partir de vSphere 6.5 et versions ultérieures :
-
Les clones complets sont pris en charge. Le clone hérite de l’état de chiffrement du parent, y compris des clés. Vous pouvez re-chiffrer un clone complet avec de nouvelles clés ou le déchiffrer entièrement.
-
Les clones liés sont pris en charge. Le clone hérite de l’état de chiffrement du parent, y compris des clés. Vous ne pouvez pas déchiffrer le clone lié ni le re-chiffrer avec des clés différentes.
-
À partir de vSphere 6.7, vous pouvez reprendre à partir d’un état suspendu d’une machine virtuelle chiffrée ou revenir à un instantané mémoire d’une machine virtuelle chiffrée. Vous pouvez également migrer une machine virtuelle chiffrée avec un instantané mémoire et un état suspendu entre hôtes ESXi.
-
Les tâches suivantes ne peuvent pas être effectuées sur une machine virtuelle chiffrée :
— Pour la plupart des opérations de chiffrement, la machine virtuelle doit être éteinte. Vous pouvez cloner une machine virtuelle chiffrée ou effectuer un re-chiffrement partiel (shallow recrypt) lorsque la machine virtuelle est sous tension.
— Vous ne pouvez pas chiffrer une machine virtuelle qui contient déjà des instantanés. Consolidez tous les instantanés existants avant d’effectuer le chiffrement. -
Vous pouvez utiliser le chiffrement des machines virtuelles vSphere avec IPv6, soit en mode IPv6 uniquement, soit en mode mixte. Vous pouvez configurer le KMS (Key Management Server) avec des adresses IPv6. vCenter et KMS peuvent être configurés pour utiliser uniquement des adresses IPv6.
Pour plus d’informations sur l’interopérabilité du chiffrement des machines virtuelles, consultez : https://docs.vmware.com/en/VMware-vSphere/8.0/vsphere-security/GUID-C0AF1F3A-67B4-41A6-A933-7E52A3603D9D.html
Certaines fonctionnalités ne sont pas compatibles avec le chiffrement des machines virtuelles vSphere :
- Bibliothèque de contenu
- Collecteur de vidage ESXi (ESXi Dump Collector)
- Utilisation du chiffrement des machines virtuelles vSphere avec d’autres produits VMware, tels que Workstation
- Envoi de la sortie d’une machine virtuelle chiffrée vers un port série ou parallèle
- Certains types de configurations de disques VMDK ne sont pas pris en charge, notamment :
— Un disque virtuel nommé non associé à une machine virtuelle, également appelé First Class Disk (FCD)
— RDM (Raw Device Mapping)
— Disques multi-écrivains ou partagés (MSCS, WSFC ou Oracle RAC)
Vous ne pouvez pas envoyer la sortie d’une machine virtuelle chiffrée vers un port série ou parallèle. Même si la configuration semble réussir, la sortie est redirigée vers un fichier.
Si un disque virtuel est chiffré et que vous sélectionnez Multi-writer dans la page Modifier les paramètres de la machine virtuelle, le bouton OK est désactivé.
Pour plus d’informations sur l’interopérabilité du chiffrement des machines virtuelles, consultez : https://docs.vmware.com/en/VMware-vSphere/8.0/vsphere-security/GUID-C0AF1F3A-67B4-41A6-A933-7E52A3603D9D.html
¶ Améliorations du chiffrement des machines virtuelles (VM Encryption Enhancements)
Les améliorations suivantes du chiffrement des machines virtuelles ont été introduites avec vSphere 7 :
- Tolérance aux pannes vSphere (vSphere Fault Tolerance).
- Migrations inter-vCenter de machines virtuelles chiffrées.
- Tolérance aux pannes pour les machines virtuelles chiffrées sans vTPM.
- Chiffrement à l’échelle du cluster (Cluster-Wide Encryption).
- De nouvelles API améliorent la gestion de l’environnement de chiffrement des machines virtuelles.
- De nouveaux événements et alertes peuvent être utilisés pour surveiller l’environnement de chiffrement.
Les améliorations introduites dans vSphere 7 renforcent la fonctionnalité générale du chiffrement des machines virtuelles.
Elles sont basées sur des analyses comparatives et des retours des clients et partenaires VMware.
Pour réduire le risque qu’un administrateur accède à des données sans autorisation, les machines virtuelles peuvent être chiffrées, et l’accès aux fonctions de chiffrement et de déchiffrement peut être limité à un sous-ensemble d’administrateurs.
Ce type de chiffrement peut être mis en œuvre à l’aide des privilèges cryptographiques intégrés dans vSphere.
¶ Avantages du chiffrement des machines virtuelles (Advantages of VM Encryption)
Le chiffrement des machines virtuelles présente plusieurs avantages par rapport à d’autres solutions similaires sur le marché :
- Aucun agent invité n’est requis.
- La méthodologie est uniforme pour tous les systèmes d’exploitation invités.
- Toutes les données de la machine virtuelle sont protégées, y compris les fichiers d’échange (swap), et pas seulement les fichiers de disque virtuel.
- Un contrôle précis des clés est possible : les machines virtuelles et les disques peuvent utiliser des clés différentes.
- L’orchestration est facilitée grâce aux stratégies de stockage des machines virtuelles (VM storage policies).
- Compatibilité avec KMIP, un langage standard industriel pour la gestion des clés de sécurité. KMIP permet l’échange interopérable de données entre différents serveurs et clients de gestion de clés.
¶ Cas d’utilisation métier : Sécurisation des machines virtuelles (Securing VMs)
Une exigence courante dans la politique de sécurité d’une entreprise consiste à protéger les données des machines virtuelles (VM) contre les utilisateurs administratifs :
¶ Problème :
- Une grande entreprise dispose de plusieurs administrateurs vSphere et de stockage.
- L’entreprise doit protéger ses données confidentielles.
- L’entreprise doit réduire le risque qu’une personne télécharge facilement un fichier VMDK ou l’ensemble d’une machine virtuelle vers un périphérique de stockage amovible et quitte l’entreprise avec ces données.
¶ Solution :
- Grâce au chiffrement des machines virtuelles (VM encryption), l’entreprise peut sécuriser les données confidentielles contenues dans un fichier VMDK, de sorte que ces données soient illisibles sans la clé numérique utilisée pour chiffrer le disque.
- La clé n’est lisible dans aucun fichier. Elle est protégée par une couche supplémentaire de chiffrement.
- L’entreprise accorde l’accès à cette clé uniquement à un nombre limité de personnes.
La clé numérique utilisée pour chiffrer une machine virtuelle est protégée par une couche supplémentaire de chiffrement, un peu comme si l’on plaçait la clé d’un coffre-fort dans un autre coffre-fort.
Les administrateurs vSphere réguliers peuvent continuer à effectuer leurs activités quotidiennes sans changement, mais les privilèges cryptographiques sont accordés uniquement à un sous-ensemble de ces administrateurs.
L’accès aux fichiers de machines virtuelles ne signifie pas que les administrateurs de stockage ou vSphere peuvent emporter le fichier VM (VMDK) et en lire le contenu en dehors du site.
¶ Architecture du chiffrement des machines virtuelles (VM Encryption Architecture)
L’architecture du chiffrement des machines virtuelles comprend les composants suivants :
-
vCenter :
- Communique avec un serveur KMS et demande des clés au nom des hôtes ESXi.
-
Hôtes ESXi :
- Exécutent les machines virtuelles chiffrées.
-
L’un des serveurs de gestion de clés suivants :
- Fournisseur de clés standard (Standard key provider)
- Fournisseur de clés de confiance (Trusted key provider)
- Fournisseur de clés natif vSphere (vSphere Native Key Provider)
¶ Serveurs KMS vSphere pris en charge (Supported vSphere KMS Servers)
-
Fournisseur de clés standard :
- Serveur externe qui fournit des clés à des services proposés par un fournisseur de sécurité tiers.
-
Fournisseur de clés de confiance :
- vSphere Trust Authority (vTA)
-
Fournisseur de clés natif vSphere :
- Introduit dans vSphere 7.0 Update 2, vous pouvez utiliser le fournisseur de clés natif intégré pour activer des technologies de chiffrement telles que les TPM virtuels (vTPM).
| Fournisseur de clés (Key Provider) | Serveur de clés externe requis ? | Configuration rapide ? | Fonctionne uniquement avec vSphere ? |
|---|---|---|---|
| Fournisseur de clés standard | Oui | Non | Non |
| Fournisseur de clés de confiance | Oui | Non | Non |
| Fournisseur de clés natif vSphere | Non | Oui | Oui |
¶ Prérequis pour le chiffrement des machines virtuelles (VM Encryption Prerequisites)
Pour chiffrer une machine virtuelle (VM), vous devez remplir plusieurs prérequis :
- Un serveur KMS enregistré pouvant fournir des clés à vCenter.
- Une stratégie de stockage de chiffrement (encryption storage policy).
Par exemple, vous pouvez utiliser la stratégie intégrée VM Encryption Policy.
Pour chiffrer des machines virtuelles, vous devez créer une stratégie de stockage avec le filtre de chiffrement activé.
Vous créez une règle commune dans la stratégie de stockage qui définit les propriétés de chiffrement.
Les propriétés de chiffrement par défaut sont appropriées dans la plupart des cas.
Vous créez une stratégie personnalisée uniquement si vous souhaitez combiner le chiffrement avec d’autres fonctionnalités, comme la mise en cache ou la réplication.
Vous devez définir la valeur Allow I/O filters before encryption sur True afin d’activer l’utilisation d’un filtre de réplication avant le filtre de chiffrement.
Le filtre de réplication voit les données en texte clair avant qu’elles ne soient chiffrées.
¶ Activation du chiffrement lors de la création d’une machine virtuelle
Si une nouvelle machine virtuelle (VM) dispose d’une stratégie de stockage de chiffrement appliquée,
elle est chiffrée immédiatement au moment de sa création.
Vous n’avez pas besoin d’effectuer d’étapes supplémentaires pour chiffrer la nouvelle VM.
La stratégie de stockage de chiffrement peut être appliquée à n’importe quelle VM,
quel que soit le type de système d’exploitation ou le stockage sur lequel la VM réside.
Pour chiffrer une nouvelle VM, procédez comme suit :
- Dans l’assistant New Virtual Machine, cochez la case Encrypt this virtual machine pour n’afficher que les stratégies de chiffrement.
- Sélectionnez une stratégie de chiffrement dans le menu déroulant VM Storage Policy.
¶ Chiffrement des machines virtuelles existantes
Le chiffrement d’une machine virtuelle (VM) existante diffère légèrement du chiffrement d’une nouvelle VM.
Lorsqu’une stratégie de stockage de chiffrement de VM est appliquée à une VM existante,
vSphere exécute automatiquement les tâches suivantes :
- Un disque dupliqué est créé avec le filtre d’E/S de chiffrement appliqué.
- Les données sont copiées du disque non chiffré vers le nouveau disque, et les données sont chiffrées.
- Une fois toutes les données copiées, le nouveau fichier VMDK chiffré est rattaché à la VM.
- L’ancien disque non chiffré est ensuite supprimé.
Cette opération est effectuée disque par disque. Vous devez disposer d’un espace libre équivalent au moins à la capacité du plus grand disque disponible dans le datastore pour terminer l’opération.
Cette opération n’est autorisée que lorsque la VM est arrêtée.
Pour les données d’une VM existante, un disque dupliqué est créé avec le filtre d’E/S de chiffrement appliqué.
Les données sont ensuite copiées du disque non chiffré vers le nouveau disque chiffré,
en appliquant le chiffrement au cours du processus de copie.
Une fois toutes les données copiées, le nouveau fichier VMDK chiffré est attaché à la VM,
et l’ancien disque non chiffré est supprimé.
La VM doit être hors tension.
¶ Déverrouillage des machines virtuelles chiffrées
Lorsqu’elle est arrêtée, une VM passe à l’état verrouillé si sa clé de chiffrement de clé (KEK) est indisponible.
Une KEK peut être indisponible pour les raisons suivantes :
- La KEK est manquante sur l’hôte ESXi.
- La KEK est manquante sur le cluster KMS.
- Le cluster KMS a rencontré une erreur.
vCenter déclenche une alerte lorsqu’une VM passe à l’état verrouillé.
Pour déverrouiller une machine virtuelle (VM), assurez-vous d’abord que la clé requise est disponible sur le cluster KMS.
Dans le vSphere Client, cliquez sur Unlock VM pour déverrouiller la VM chiffrée :
- L’API Unlock Virtual Machine envoie la clé de chiffrement de la VM à l’hôte ESXi.
¶ À propos du KMS
Pour préparer l’environnement au chiffrement des machines virtuelles, vous devez configurer le KMS.
Le KMS présente les caractéristiques suivantes :
- Doit être compatible avec KMIP 1.1 : le KMIP (Key Management Interoperability Protocol) est une norme industrielle pour la gestion des clés de sécurité.
- Fournit un service de gestion de clés pour les clients KMIP, tels que vCenter.
- Peut être configuré avec un serveur proxy KMIP.
- Est accessible via IP en IPv4 uniquement, IPv6 uniquement, ou en mode mixte (IPv4 et IPv6).
Pour vSphere, le KMS doit être un serveur qui communique à l’aide du protocole KMIP.
vCenter implémente un client KMIP capable d’émettre des commandes au format KMIP
pour demander des clés à l’aide d’identifiants spécifiques.
Un serveur KMIP peut renvoyer les valeurs de clés à vCenter via un canal sécurisé.
Disposer d’un KMS permet que toutes les tâches de gestion des clés soient centralisées
sur un serveur unique ou un cluster de serveurs.
Plusieurs instances de vCenter peuvent accéder au même cluster KMS et partager les mêmes clés.
Une gestion centralisée réduit la surface d’attaque liée à la gestion des clés.
Au lieu de gérer des clés réparties sur plusieurs emplacements, vous sécurisez un seul serveur ou un nombre limité de serveurs, ce qui est plus simple et plus sûr.
Les serveurs proxy KMIP permettent d’étendre la capacité de gestion des clés du KMS vers un site distant. Grâce à ces serveurs proxy, vous pouvez conserver votre serveur de clés principal en sécurité
dans votre centre de données central, tout en permettant à des bureaux distants d’utiliser ces services sans compromettre la sécurité.
Enfin, le protocole KMIP ne nécessite qu’un réseau compatible IP, ce qui est courant dans la majorité des centres de données.
Le KMS n’est requis que si vous n’utilisez pas le vSphere Native Key Provider (NKP).
¶ Certificat client KMIP
Le type de certificat utilisé par le client KMIP (vCenter) dépend du serveur KMS.
- Certains fournisseurs acceptent les certificats auto-générés.
- Certains fournisseurs exigent que le KMS génère un certificat de confiance pour le client,
lequel doit ensuite être téléchargé par le client. - D’autres fournisseurs acceptent uniquement un certificat client fourni par le KMS lui-même.
Vérifiez auprès du fournisseur du KMS pour connaître les exigences spécifiques.
Les différents fournisseurs de KMS ont des exigences variables concernant le format du certificat client utilisé par vCenter.
Certains fournisseurs autorisent l’utilisation du certificat propre au client, comme un certificat auto-signé ou signé par une autorité de certification (CA). D’autres fournisseurs exigent que le certificat utilisé par le client soit signé par le serveur KMS.
Vous pouvez utiliser le vSphere Client pour fournir les détails du certificat
en fonction des exigences de sécurité propres à chaque type d’implémentation.
¶ Clusters de gestion des clés
Le KMS joue un rôle essentiel dans la protection des machines virtuelles (VM).
Rendez le KMS hautement disponible en créant un cluster de gestion des clés :
- Un cluster de gestion des clés est un groupe de serveurs de gestion de clés basés sur KMIP qui répliquent les clés entre eux.
- Un cluster doit contenir des serveurs de gestion de clés provenant d’un seul fournisseur.
- Un cluster permet d’éviter les points de défaillance uniques.
- Un cluster par défaut est autorisé pour chaque instance de vCenter.
- Le cluster est identifié dans vCenter par une valeur de nom de cluster (Cluster Name).
Pour se protéger contre une éventuelle défaillance d’un KMS (également appelé serveur KMIP), des clusters KMIP sont formés.
Ces clusters offrent une protection contre les pannes.
vCenter conserve une liste de serveurs de gestion des clés présents dans le cluster.
Si le premier KMS de la liste n’est pas disponible, vCenter tente de communiquer avec le suivant, et ainsi de suite.
Pour former un cluster KMIP, les serveurs KMIP doivent provenir d’un seul fournisseur.
Consultez la documentation du fournisseur pour connaître les étapes de création d’un cluster KMIP.
Une fois les clés répliquées, un client peut demander la clé à n’importe quel serveur participant au cluster. Ainsi, si un serveur tombe en panne, un autre serveur peut fournir la clé.
Bien que plusieurs clusters KMIP puissent être ajoutés à vCenter, un seul cluster doit être défini comme cluster par défaut.
Le cluster par défaut est celui à partir duquel vCenter demande de nouvelles clés.
Les clés peuvent également être récupérées à partir de clusters non par défaut si le cluster est identifié.
Les clusters de serveurs KMIP sont identifiés par un nom convivial défini par l’utilisateur,
renseigné dans le vSphere Client.
¶ Résumé des clés
Le KMS (Key Management Server) fournit des clés pour sécuriser les hôtes ESXi et les machines virtuelles (VM).
| Type de clé | Description | Emplacement de la clé | Créée par |
|---|---|---|---|
| Clé d’hôte (Host key) | Utilisée pour chiffrer les vidages mémoire (core dumps). | Stockée dans la mémoire de l’hôte ESXi et sur le KMS. | KMS |
| Clé de chiffrement des données (DEK - Data Encryption Key) | Utilisée pour chiffrer la machine virtuelle (VM). | Stockée dans le fichier de configuration de la VM (au format chiffré). | Hôte ESXi sur lequel la VM a été chiffrée |
| Clé de chiffrement des clés (KEK - Key Encryption Key) | Utilisée pour chiffrer la DEK. | Stockée en mémoire sur chaque hôte ESXi du cluster et sur le KMS. | KMS |
¶ Rôle de vCenter dans le chiffrement des machines virtuelles (VM)
vCenter remplit plusieurs fonctions importantes dans le chiffrement des machines virtuelles :
- Stocke les informations d’identification du KMS
- Gère les clés utilisées pour le chiffrement :
— Identifie les clés par UUID
— Récupère les clés depuis le KMS - Transmet les clés aux hôtes ESXi lorsque nécessaire
- Gère les autorisations
- Met en œuvre et gère les stratégies de stockage
- Enregistre les événements à des fins d’audit
vCenter lui-même ne peut pas être chiffré.
vCenter stocke les informations de connexion au KMS et constitue le seul composant vSphere capable de communiquer avec le KMS pour récupérer les clés.
Un hôte ESXi ne peut pas demander directement de clés au KMS ; vCenter exécute les opérations de gestion des clés pour le compte des hôtes ESXi.
vCenter fournit un mécanisme permettant d’identifier les clés à l’aide d’un identifiant unique, lequel peut être stocké dans un fichier VMX ou VMDK d’une VM.
vCenter peut utiliser ces identifiants pour demander les clés au serveur KMS lorsque cela est nécessaire, puis transférer ces clés aux hôtes ESXi.
vCenter fournit également le cadre de gestion des autorisations pour les tâches cryptographiques.
Vous pouvez limiter l’accès à certaines opérations critiques à un sous-ensemble d’administrateurs, tout en permettant aux autres administrateurs de continuer leurs activités quotidiennes.
vCenter gère les stratégies de stockage qui définissent si une VM est chiffrée ou non.
Enfin, vCenter enregistre les événements à des fins d’audit.
Les informations d’audit incluent notamment l’identité de l’utilisateur ayant initié l’événement.
¶ Communication entre le KMS et vCenter
Pour sécuriser la communication entre le serveur KMIP (KMS) et le client KMIP (vCenter), une relation de confiance doit être établie.
vCenter stocke les informations de clé privée dans le VMware Endpoint Certificate Store (VECS).
vCenter utilise TLS 1.2 lors de la communication avec le KMS.
Une fois la confiance établie entre le KMS (serveur KMIP) et le vCenter (client KMIP),
vCenter stocke les informations d’identification du KMS.
Le VMware Endpoint Certificate Store (VECS) conserve les informations de clé privée SSL.
¶ S’assurer que l’hôte ESXi est cryptographiquement sûr
Un hôte ESXi s’assure qu’il est cryptographiquement sûr avant de pouvoir gérer des VMs chiffrées.
Lorsqu’un utilisateur effectue une tâche de chiffrement, par exemple la création d’une VM chiffrée, les opérations suivantes sont exécutées automatiquement :
- vCenter demande une clé au KMS pour le cluster, connue sous le nom de host key.
- vCenter récupère les host keys depuis le KMS et envoie une clé d’hôte à chaque hôte du cluster.
- L’hôte installe sa host key dans sa mémoire cache de clés et active le chiffrement des core dumps.
La host key est utilisée pour chiffrer les core dumps.
Les utilisateurs disposant des privilèges requis peuvent effectuer des opérations cryptographiques. Ces opérations incluent la création de VMs chiffrées, le chiffrement de VMs existantes et le déchiffrement de VMs chiffrées.
Lorsque le mode de chiffrement d’hôte est activé sur un hôte d’un cluster, il est également activé pour tous les autres hôtes du cluster.
Le mode de chiffrement d’hôte ne peut pas être désactivé tant que les hôtes du cluster gèrent des VMs chiffrées.
¶ Flux du processus de chiffrement de VM
Une fois que l’hôte est cryptographiquement sûr, il peut recevoir des clés pour la VM :
- vCenter demande une VM KEK au KMS.
- Le KMS envoie l’identifiant de la clé (Key ID) à vCenter.
- vCenter transmet la KEK directement à l’hôte ESXi.
Si l’hôte appartient à un cluster, vCenter envoie la KEK à chaque hôte du cluster. La KEK est stockée dans la mémoire de l’hôte. La KEK elle-même n’est jamais stockée sur le système vCenter, seul l’identifiant de la clé (Key ID) l’est.
Lorsqu’une opération cryptographique se produit, vCenter doit déterminer si une clé de VM doit être transmise aux hôtes ESXi.
vCenter récupère la Key Encryption Key (KEK) depuis le KMS, mais la KEK n’est jamais stockée sur vCenter, pas même dans sa mémoire. La KEK reste dans la mémoire de vCenter uniquement pendant le transit vers l’hôte ESXi.
vCenter transmet la KEK à l’hôte ESXi qui exécute l’opération cryptographique.
Si l’hôte appartient à un cluster, ce dernier est considéré comme la limite de sécurité.
Dans ce cas, vCenter envoie la KEK à tous les hôtes du cluster afin que toute opération de cluster — comme les migrations vSphere vMotion ou les opérations vSphere HA — puisse se dérouler correctement.
Les KEK restent dans la mémoire de l’hôte ESXi jusqu’au prochain redémarrage.
De plus, les core dumps sont chiffrés.
- L’hôte ESXi génère une clé appelée Data Encryption Key (DEK).
- La DEK est utilisée pour chiffrer la VM et ses disques.
- L’hôte ESXi utilise la KEK pour chiffrer la DEK.
- La DEK est stockée dans le fichier de configuration de la VM, sous une forme chiffrée.
Si un hôte ESXi redémarre, la KEK de la VM n’est plus présente dans la mémoire de l’hôte. vCenter demande alors la KEK correspondante au KMS, à l’aide du Key ID, et la met à disposition de l’hôte ESXi lorsque celui-ci est de nouveau en fonctionnement.
L’hôte ESXi peut ensuite déchiffrer la DEK de la VM, si nécessaire.
Comme les KEK sont stockées dans la mémoire de l’hôte et que vSphere chiffre tous les core dumps (à l’aide du HEK), la KEK ne peut pas être découverte.
¶ QCM : Clés de VM
D’où un hôte ESXi extrait-il la Key Encryption Key (KEK) d’une VM lorsque cela est nécessaire ?
☐ Virtual Machine Disk (VMDK)
☐ Virtual Machine Configuration File (VMX)
☐ Key Management Server (KMS)
☐ Hypervisor Security Module (HSM)
¶ Réponse : Clés de VM
D’où un hôte ESXi extrait-il la Key Encryption Key (KEK) d’une VM lorsque cela est nécessaire ?
☐ Virtual Machine Disk (VMDK)
☐ Virtual Machine Configuration File (VMX)
✓ Key Management Server (KMS) Administrator
☐ Hypervisor Security Module (HSM)
Lorsqu’un hôte ESXi doit récupérer la Key Encryption Key (KEK) d’une machine virtuelle, il l’obtient à partir du Key Management Server (KMS).
Les hôtes ESXi ne peuvent pas extraire la clé d’une VM directement depuis le KMS ou vCenter.
¶ Gestion du chiffrement des VM
Les privilèges cryptographiques de vCenter :
- Le rôle vCenter Administrator possède des privilèges cryptographiques.
- Cependant, tous les administrateurs ne doivent pas être en mesure de contrôler les opérations de chiffrement ou d’accéder aux clés.
- vCenter fournit un rôle appelé No Cryptography Administrator, destiné aux administrateurs qui n’ont pas besoin de privilèges de chiffrement.
- Les rôles Administrator et No Cryptography Administrator sont des rôles intégrés et ne peuvent pas être modifiés.
¶ Rôle vCenter : No Cryptography Administrator
Ce rôle n’inclut pas les privilèges suivants :
- Opérations cryptographiques
- Diagnostics globaux
- Ajouter un hôte à un cluster
- Ajouter un hôte autonome
- Gérer les groupes d’utilisateurs
Il existe un rôle prédéfini appelé No Cryptography Administrator.
Vous pouvez également créer des rôles personnalisés qui incluent des privilèges cryptographiques.
Le rôle No Cryptography Administrator n’inclut pas le privilège Add Host, car cette tâche peut nécessiter l’installation d’une clé d’hôte, ce qui en ferait une opération cryptographique.
¶ QCM : Privilèges cryptographiques
Quel rôle vCenter prédéfini permet à un utilisateur d’effectuer des opérations cryptographiques ?
☐ Administrator
☐ Virtual Machine Power User
☐ Virtual Machine Console User
☐ No Cryptography Administrator
¶ Réponses : Privilèges cryptographiques
Quel rôle vCenter prédéfini permet à un utilisateur d’effectuer des opérations cryptographiques ?
✓ Administrator
☐ Virtual Machine Power User
☐ Virtual Machine Console User
☐ No Cryptography Administrator
Vous pouvez également créer un rôle personnalisé qui possède certains privilèges cryptographiques, mais le seul rôle prédéfini avec des privilèges cryptographiques est le rôle Administrator.
¶ Migration inter-vCenter et clonage d’une VM chiffrée
Dans vSphere 7 et versions ultérieures, vous pouvez effectuer des opérations cryptographiques entre plusieurs instances de vCenter :
¶ Pour le clonage
- Lors du clonage d’une VM non chiffrée, vous pouvez chiffrer la VM de destination.
- Lors du clonage d’une VM chiffrée, vous pouvez déchiffrer la VM de destination.
- Lors du clonage d’une VM chiffrée, vous pouvez rechiffrer la VM de destination.
¶ Pour les migrations
- Vous pouvez migrer une VM chiffrée entre différents vCenters lorsque le même KMS est configuré sur les deux instances de vCenter.
- Vous ne pouvez pas déchiffrer la VM pendant la migration.
- Vous ne pouvez pas rechiffrer la VM pendant la migration.
Les VMs peuvent être allumées ou éteintes lors du clonage ou de la migration entre plusieurs instances de vCenter.
Pendant l’opération de migration, vous ne pouvez pas changer les clés, et donc le rechiffrement de la VM pendant la migration n’est pas pris en charge.
De même, vous ne pouvez pas modifier la stratégie de stockage pendant la migration, et par conséquent, le déchiffrement de la VM pendant la migration n’est pas pris en charge.
¶ Effectuer un rechiffrement superficiel de VMs avec Snapshots
Introduit dans vSphere 7, il est possible d’effectuer un rechiffrement superficiel (shallow rekey) d’une VM chiffrée avec des Snapshots, que la VM soit allumée ou éteinte.
Vous pouvez chiffrer uniquement les VMs ayant une seule branche de Snapshot (les branches multiples ne sont pas prises en charge).
Dans une branche de Snapshot, un Snapshot est rechiffrée à la fois :
- Si l’opération de rechiffrement échoue avant de rechiffrer toutes les Snapshots de la chaîne, certaines Snapshots seront chiffrées avec la nouvelle clé et d’autres utiliseront l’ancienne clé.
- Pour corriger ce problème, effectuez à nouveau le rechiffrement superficiel.
Vous utilisez PowerCLI pour exécuter le shallow rekey.
Un rechiffrement complet (deep rekey) remplace toutes les clés d’une VM par de nouvelles clés, du haut vers le bas. Cette opération nécessite la réécriture de toutes les données chiffrées dans la VM.
Un rechiffrement superficiel (shallow rekey) ne remplace que les clés gérées de niveau supérieur dans une VM, à savoir la KEK. Seule une petite quantité de données chiffrées doit être réécrite.
¶ Clonage d’une VM chiffrée avec la technologie Instant Clone
Introduite dans vSphere 7, la technologie Instant Clone prend en charge le clonage d’une VM chiffrée (la VM parente).
Un Instant Clone est une VM enfant qui partage les disques virtuels et la mémoire avec la VM parente de manière continue.
Par défaut, la VM enfant chiffrée issue d’un Instant Clone hérite des mêmes clés que la VM parente.
Ce processus de clonage comporte certaines limitations :
- Pendant l’opération d’Instant Clone, la VM chiffrée ne peut pas être rechiffrée (superficiellement ou complètement), ni déchiffrée.
- Après avoir créé un Instant Clone d’une VM chiffrée, vous ne pouvez pas rechiffrer (superficiellement ou complètement) ni déchiffrer la VM source ou la VM de destination.
Vous pouvez créer un Instant Clone d’une VM à l’aide de PowerCLI ou de l’API.
Vous ne pouvez pas modifier la stratégie de stockage ni changer les clés de chiffrement pendant l’opération d’Instant Clone.
¶ Clonage d’une VM : chiffrement ou déchiffrement de la VM de destination
Pour chiffrer ou déchiffrer la VM de destination, modifiez la stratégie de stockage (storage policy) de la VM.
Le déchiffrement d’une VM peut présenter un risque de sécurité.
Par conséquent, comme bonne pratique, limitez le privilège de déchiffrement des VMs à un nombre restreint d’utilisateurs.
¶ Exigences système lors du clonage d’une VM
Pour le chiffrement, le déchiffrement et le rechiffrement des VMs pendant le clonage, les exigences suivantes doivent être respectées :
- Établir une connexion de confiance (trusted connection) avec le KMS et sélectionner un KMS par défaut.
- Si le clonage s’effectue entre plusieurs hôtes ESXi, les hôtes source et destination doivent exécuter vSphere 7 ou une version ultérieure.
¶ Opérations de chiffrement de VM lors du clonage d’une VM
Introduit dans vSphere 7, les opérations cryptographiques sont prises en charge lors du clonage d’une machine virtuelle (VM).
Lors du clonage d’une VM non chiffrée :
-
Vous pouvez chiffrer la VM de destination en modifiant la stratégie de stockage (storage policy) de la VM de destination pour utiliser la VM Encryption Policy (ou une stratégie de chiffrement personnalisée).
-
Vous pouvez déchiffrer la VM de destination en modifiant la stratégie de stockage de la VM de destination vers une stratégie non chiffrée.
-
Vous pouvez rechiffrer la VM de destination en utilisant PowerCLI pour rekey les VMs.
Vous pouvez effectuer soit un shallow rekey, soit un deep rekey.
Un shallow rekey (ou rechiffrement léger) modifie la clé de chiffrement des clés (KEK) associée à la VM. La clé de chiffrement des données (DEK) est ensuite encapsulée (wrapped) avec la nouvelle KEK.
Un deep rekey (ou rechiffrement complet) modifie la DEK et rechiffre toutes les données à l’aide de cette nouvelle clé DEK. Cette opération nécessite de l’espace disque temporaire et est plus lente qu’un shallow rekey, car toutes les données chiffrées doivent être réécrites.
Commande PowerCLI pour le rechiffrement : Set-VMEncryptionKey -VM <nom_VM> -RekeyType <Shallow|Deep>
¶ Sauvegarde des machines virtuelles chiffrées
Vous pouvez sauvegarder des machines virtuelles chiffrées à l’aide d’une solution de sauvegarde et de restauration qui utilise les API vSphere Storage – Data Protection (VAPD).
La solution de sauvegarde et de restauration peut également fournir son propre mécanisme de chiffrement.
La capacité à sauvegarder une VM chiffrée dépend du mode de transport utilisé par la solution de sauvegarde.
| Mode de transport | Description |
|---|---|
| Mode Hot-add | • Une machine virtuelle proxy résidant sur un hôte ayant un accès direct aux disques de la VM à sauvegarder peut effectuer les lectures directement depuis le disque virtuel et réaliser une copie disque-à-disque des données de sauvegarde. |
| Mode NBD/NBDSSL | • Lorsque aucun autre mode de transport n’est disponible, ce mode est utilisé. • L’hôte ESXi effectue les lectures puis envoie les données via le réseau local (LAN), en utilisant le protocole NFC. |
Un mode de transport définit la méthode utilisée pour transférer les données vers le serveur de sauvegarde.
Pour plus d’informations sur les modes de transport, consultez le Virtual Disk Development Kit (VDDK) à l’adresse : https://developer.vmware.com/web/sdk
Le serveur de sauvegarde doit d’abord déterminer si une machine virtuelle (VM) est chiffrée.
La majorité des solutions de sauvegarde permettent aux VMs d’être chiffrées lors de la sauvegarde.
Si la VM est chiffrée :
- Le mode SAN n’est pas pris en charge.
- Les modes NBD ou NBD-SSL sont disponibles et peuvent être utilisés.
Si le mode Hot-add est utilisé et que la machine proxy est une VM :
- Le mode Hot-add est disponible, mais la machine proxy doit également être chiffrée.
Si le mode Hot-add est utilisé et que la machine proxy est physique :
- Le mode Hot-add est disponible, mais la machine proxy doit également être chiffrée.
L’utilisateur vCenter enregistré comme utilisateur de l’appliance de sauvegarde doit disposer de privilèges cryptographiques.
Les données de sauvegarde sont stockées en texte clair sur le serveur de sauvegarde :
- N’accordez les privilèges de restauration qu’à des personnes de confiance.
- Configurez une stratégie pour rechiffrer une VM restaurée.
Si la VM est chiffrée, le mode SAN est immédiatement exclu comme mode de transport possible.
Les produits de sauvegarde qui dépendent de ce mode ne peuvent pas sauvegarder les VMs chiffrées.
Les blocs de données sont chiffrés et, sans assistance de vSphere, le serveur de sauvegarde ne peut pas utiliser les données.
Si le proxy de sauvegarde est une machine physique, le mode Hot-add est également exclu, et le mode NBD ou NBD-SSL est utilisé.
L’hôte ESXi est alors chargé d’ouvrir le disque, de déchiffrer les données, puis d’envoyer les données déchiffrées en texte clair vers le serveur de sauvegarde.
Si l’utilisateur utilisé pour enregistrer l’appliance de sauvegarde dans vCenter ne possède pas de privilèges cryptographiques,
le disque ne peut pas être déchiffré pour envoyer les données vers le serveur de sauvegarde.
Quel que soit le mode de transport, les données de sauvegarde sont stockées sur le serveur de sauvegarde en texte clair.
De ce fait, une VM restaurée peut l’être en tant que machine non chiffrée.
Les privilèges de restauration des VMs doivent être accordés uniquement à des personnes de confiance,
idéalement des utilisateurs disposant de privilèges cryptographiques,
afin que la VM puisse être rechiffrée immédiatement après sa restauration.
¶ Événements et alertes de chiffrement des VM
Dans vSphere 7 et les versions ultérieures, certains journaux affichant des avertissements et des messages d’erreur permettent de fournir des informations sur l’état de fonctionnement de vCenter et de l’environnement de chiffrement des VM.
-
Événement d’avertissement :
- Un core dump chiffré existe.
-
Événements critiques :
- Espace disque insuffisant pour effectuer l’opération cryptographique.
- Échec de la création de clé sur le cluster KMS.
- Le serveur KMS est injoignable.
Ces événements vous aident à identifier les problèmes potentiels.
¶ Revue des objectifs d’apprentissage
- Décrire les composants d’une architecture de chiffrement de VM
- Gérer les VM chiffrées
- Utiliser le chiffrement avec les instant clones
- Migrer des VM chiffrées
- Lister les événements et alertes de chiffrement des VM
¶ Leçon 4 : Key Providers
¶ Objectifs d’apprentissage
- Identifier le rôle du Key Provider dans vCenter.
¶ Vue d’ensemble du Standard Key Provider
Un Standard Key Provider peut être utilisé lorsque vous souhaitez que vCenter récupère des clés auprès d’un serveur de clés tiers.
Le vCenter est responsable de la distribution de ces clés aux hôtes ESXi nécessaires au sein de vSphere.
¶ Options disponibles
Les administrateurs peuvent choisir parmi les options suivantes lors de la configuration d’un Standard Key Provider :
- Amazon Web Services Key Management Service
- Microsoft Azure Key Vault
- Microsoft Azure Dedicated HSM
- Google Cloud Key Management Service
- Thales Vormetric Data Security Manager
- External Key Management Systems
¶ Considérations de mise en œuvre
Facteurs importants à prendre en compte lors de la mise en œuvre de Standard Key Providers dans vSphere :
- Vérifiez la compatibilité entre les versions de vSphere et le Standard Key Provider sélectionné à l’aide du VMware Compatibility Guide – https://www.vmware.com/resources/compatibility/search.php
- Évaluez les fonctionnalités de sécurité et les certifications de conformité du Key Provider choisi.
- Définissez les politiques de rotation et d’archivage des clés.
¶ Vue d’ensemble du vSphere Native Key Provider
Dans vSphere 7.0 Update 2 et versions ultérieures, vous pouvez utiliser le vSphere Native Key Provider intégré pour activer les technologies de chiffrement telles que les TPM virtuels (vTPM) et le VM Encryption.
Le vSphere Native Key Provider ne fonctionne qu’avec les produits d’infrastructure VMware et n’est pas conforme à KMIP 1.1.
Actuellement, vSphere Native Key Provider ne prend pas en charge le chiffrement First Class Disk (FCD).
¶ Fonctionnalités du vSphere Native Key Provider
Les fonctionnalités du vSphere Native Key Provider incluent les éléments suivants :
- Permet l’utilisation de vTPMs, du vSphere Virtual Machine Encryption et du vSAN Data at Rest Encryption, lorsque vous ne souhaitez pas ou n’avez pas besoin d’un serveur de clés externe.
- Ne fournit pas d’interopérabilité externe, de prise en charge KMIP, de modules matériels de sécurité (HSM) ni d’autres fonctionnalités qu’un serveur de clés externe tiers traditionnel peut offrir.
- Répond aux besoins des organisations qui ne peuvent pas utiliser ou ne souhaitent pas utiliser de serveur de clés externe.
- Améliore la sanitation des données et la réutilisation des systèmes en permettant une utilisation plus précoce des technologies de chiffrement sur les supports difficiles à nettoyer, tels que les disques flash et SSD.
- Fonctionne avec plusieurs vCenters en mode Enhanced Linked Mode.
- Fonctionne avec la configuration vCenter High Availability (HA).
¶ Exigences du vSphere Native Key Provider
Pour utiliser le vSphere Native Key Provider, vous devez :
- Vous assurer que le vCenter et les hôtes ESXi exécutent vSphere 7.0 Update 2 ou une version ultérieure.
- Configurer les hôtes ESXi dans un cluster.
- Configurer la sauvegarde et la restauration basées sur des fichiers du vCenter, et stocker les sauvegardes de manière sécurisée.
¶ vSphere Native Key Provider vMotion et Cross-vCenter vMotion
Le vSphere Native Key Provider prend en charge vMotion et Encrypted vMotion entre les hôtes ESXi.
Le Cross-vCenter vMotion est pris en charge si le vSphere Native Key Provider est configuré sur l’hôte de destination.
¶ vSphere Native Key Provider et mode Enhanced Linked
Vous pouvez configurer un vSphere Native Key Provider unique qui peut être partagé entre plusieurs systèmes vCenter configurés en Enhanced Linked Mode.
Les étapes principales de ce scénario sont les suivantes :
- Créer le vSphere Native Key Provider sur l’un des vCenter.
- Sauvegarder le Native Key Provider sur le vCenter où il a été créé.
- Exporter le Native Key Provider.
- Importer le Native Key Provider vers les autres vCenter dans la configuration Enhanced Linked Mode.
¶ Revue des objectifs d’apprentissage
- Reconnaître le rôle du Key Provider dans vCenter.
¶ Leçon 5 : vSphere Trust Authority
¶ Objectifs d’apprentissage
- Décrire vSphere Trust Authority
- Énumérer les cas d’utilisation de vSphere Trust Authority
- Expliquer l’architecture générale de vSphere Trust Authority
¶ À propos de vSphere Trust Authority
vSphere Trust Authority sécurise un environnement vSphere et ses charges de travail :
- Utilise une racine matérielle de confiance pour sécuriser l’environnement
- Rend compte des logiciels exécutés sur un hôte
- Mesure ou atteste les logiciels à l’aide d’un Trusted Platform Module (TPM)
Un utilisateur Administrateur Trust Authority doit configurer les paramètres suivants :
- Versions d’ESXi autorisées
- Fabricants ou dispositifs TPM approuvés
- Cela est important pour se protéger contre les vulnérabilités découvertes dans une version particulière d’ESXi ou dans une implémentation spécifique de TPM.
Un fournisseur de clés de confiance (trusted key provider) est requis.
Un rapport d’attestation valide est nécessaire avant que l’accès ne soit accordé au fournisseur de clés.
¶ À propos de l’administrateur vSphere Trust Authority
Pour activer vSphere Trust Authority, vous devez ajouter un utilisateur au groupe vSphere TrustedAdmins.
- Cet utilisateur devient l’administrateur Trust Authority.
- Utilisez un utilisateur distinct de l’administrateur vCenter pour le rôle d’administrateur Trust Authority.
- Vous devez ajouter un administrateur Trust Authority pour le cluster Trust Authority et pour le cluster de confiance (Trusted Cluster).
- L’appartenance au groupe est validée par ESXi à l’aide de l’authentification par jeton SAML.
¶ Cas d’utilisation de vSphere Trust Authority
Vous pouvez utiliser vSphere Trust Authority pour effectuer des tâches de sécurité :
- Fournir aux hôtes ESXi une racine matérielle de confiance et des capacités d’attestation à distance.
- Effectuer des opérations cryptographiques sur les machines virtuelles (VM), mais avec un niveau renforcé de gestion des clés de chiffrement :
- Le transfert de clés est effectué via le cluster Trust Authority au lieu de vCenter.
- Une attestation est requise pour l’accès aux clés.
- Chiffrer vCenter.
Dans vSphere 7 et versions ultérieures, vous pouvez créer une base informatique de confiance, qui se compose d’un ensemble sécurisé et gérable d’hôtes ESXi.
vSphere Trust Authority met en œuvre un service d’attestation à distance pour les hôtes ESXi que vous souhaitez approuver.
De plus, vSphere Trust Authority améliore la prise en charge de l’attestation TPM 2.0 (ajoutée à vSphere 6.7) afin de mettre en place des restrictions d’accès aux clés de chiffrement, protégeant ainsi mieux les secrets des charges de travail des VM.
En outre, vSphere Trust Authority ne permet qu’aux administrateurs autorisés de Trust Authority de configurer les services et les hôtes de Trust Authority.
L’administrateur Trust Authority peut être le même utilisateur que l’administrateur vSphere ou un utilisateur distinct.
¶ Composants de vSphere Trust Authority
vSphere Trust Authority se compose d’un cluster vSphere Trust Authority et d’un fournisseur de clés de confiance (KMS).
D’autres clusters ESXi sont attestés par rapport au cluster Trust Authority.
¶ Concepts clés de vSphere Trust Authority :
- Trust Authority Cluster : Ensemble restreint d’hôtes ESXi disposant d’une configuration approuvée et vérifiée.
- Administré par un nombre limité d’administrateurs de confiance.
- Trusted Key Provider (aussi appelé serveur de gestion de clés [KMS]) : Fournisseur de clés que seul le cluster Trust Authority est autorisé à connaître.
- Attested Cluster (ou Trusted Cluster) : Cluster dont le rapport d’attestation doit être validé par le cluster Trust Authority.
¶ Composants ESXi
Les services exécutés sur les hôtes ESXi activés pour vSphere Trust Authority :
Tous les services de vSphere Trust Authority s’exécutent derrière le Reverse Proxy et le transfert d’API (API Forwarder).
L’Agent d’infrastructure de confiance communique sur le port 443 avec les hôtes Trust Authority.
¶ Les ports internes suivants sont utilisés :
- Service d’attestation : Port 7889
- Service de fournisseur de clés : Port 7888
- Agent d’infrastructure de confiance : Port 7890
¶ Service d’attestation
Le Service d’attestation sur l’hôte ESXi est utilisé pour vérifier les logiciels et matériels distants :
- Reçoit un rapport d’attestation de l’agent d’infrastructure de confiance des hôtes ESXi attestés.
- Vérifie qu’un dispositif TPM est présent sur les hôtes ESXi attestés.
- Vérifie la version d’ESXi des hôtes attestés.
- Génère un document signé décrivant l’état binaire et de configuration des hôtes ESXi attestés.
Le Service d’attestation exécute les fonctions suivantes :
- Génère un document signé contenant des assertions décrivant l’état binaire et la configuration des hôtes ESXi distants dans le cluster de confiance.
- Atteste l’état des hôtes ESXi à l’aide d’une puce TPM 2.0 (Trusted Platform Module) pour la mesure et le rapport du logiciel. Le TPM mesure la pile logicielle et les données de configuration, puis les transmet au service d’attestation.
- Vérifie que la signature de mesure logicielle peut être attribuée à une clé d’approbation TPM (EK) préalablement configurée et approuvée.
- S’assure que la mesure logicielle correspond à l’une des images ESXi autorisées précédemment.
- Signe un jeton SAML qu’il émet à l’hôte ESXi, fournissant des assertions sur l’identité, la validité et la configuration de cet hôte ESXi.
¶ Confiance du Service d’attestation
Le Service d’attestation ne sait pas à quoi faire confiance.
Un administrateur de l’autorité de confiance (Trust Authority Administrator) doit configurer les éléments suivants :
- Quelles versions d’ESXi sont considérées comme fiables.
- Quels fabricants d’appareils TPM sont dignes de confiance.
- (Facultatif) Quels appareils TPM spécifiques doivent être considérés comme fiables.
¶ Service de fournisseur de clés (Key Provider Service)
Le Service de fournisseur de clés (kmxd) fournit une méthode pour encapsuler les sources de clés de chiffrement :
- Le service prend en charge les serveurs de clés conformes à KMIP (Key Management Interoperability Protocol).
- Des protocoles supplémentaires pourront être ajoutés à l’avenir.
- Le service autorise l’accès aux clés de chiffrement uniquement si un client présente un rapport d’attestation valide.
Avec le Service de fournisseur de clés, les hôtes vCenter et ESXi n’ont pas besoin d’utiliser directement des identifiants de serveur de gestion de clés (KMS).
Dans vSphere Trust Authority, un hôte ESXi peut accéder à une clé de chiffrement en s’authentifiant auprès du Service de fournisseur de clés, plutôt qu’auprès de vCenter (comme c’était le cas dans vSphere 6.7).
Pour que le Service de fournisseur de clés se connecte à un KMS, l’administrateur de l’autorité de confiance doit configurer une relation de confiance.
Pour la plupart des serveurs conformes au protocole d’interopérabilité de gestion des clés (KMIP), cette configuration se fait en créant des certificats client et serveur pour établir la confiance.
¶ Agent d’infrastructure de confiance (Trusted Infrastructure Agent)
L’agent d’infrastructure de confiance communique avec le service de fournisseur de clés de confiance (Trusted Key Provider Service) et le service d’attestation (Attestation Service) :
- L’agent d’infrastructure de confiance récupère les clés de chiffrement auprès du service de fournisseur de clés de confiance.
- L’agent ne peut recevoir des clés de chiffrement que si l’hôte ESXi réussit l’attestation.
- L’hôte ESXi ne reçoit pas de clés de chiffrement depuis vCenter lorsqu’il utilise un fournisseur de clés de confiance.
¶ Flux de travail de vSphere Trust Authority
Dans le flux de travail de vSphere Trust Authority, un administrateur de l’autorité de confiance effectue les tâches suivantes :
- Exporte l’identité des hôtes à attester
- Active les services d’hôtes de confiance sur un cluster d’autorité de confiance
- Importe l’identité des hôtes à attester dans le cluster d’autorité de confiance
- Configure un fournisseur de clés de confiance
- Exporte l’identité du cluster d’autorité de confiance
- Importe l’identité du cluster d’autorité de confiance dans le cluster à attester
- Configure le cluster d’autorité de confiance comme fournisseur de clés pour le cluster à attester
¶ Topologies vCenter
Le cluster vSphere Trust Authority doit résider dans un inventaire vCenter différent de celui des clusters de confiance (attestés).
L’hôte ESXi hébergeant le cluster vSphere Trust Authority doit être isolé de l’inventaire vCenter qu’il gère.
Les clusters attestés peuvent participer au même domaine Single Sign-On (SSO) en utilisant le mode Enhanced Linked Mode.
¶ Activation de vSphere Trust Authority
Dans vSphere 7 et versions ultérieures, vous activez vSphere Trust Authority principalement via vSphere PowerCLI :
- vSphere PowerCLI 12.0 et versions ultérieures fournissent un nouvel ensemble de commandes (cmdlets) PowerCLI dédiées à vSphere Trust Authority.
- L’utilisateur exécutant ces cmdlets doit être membre du groupe SSO TrustedAdmins.
- Une interface graphique est prévue pour une version ultérieure.
¶ À propos du chiffrement des machines virtuelles avec vSphere Trust Authority
L’expérience utilisateur concernant le chiffrement des machines virtuelles ne change pas lorsqu’il est utilisé avec vSphere Trust Authority :
- Vous pouvez chiffrer une machine virtuelle (VM) en appliquant une stratégie de stockage de chiffrement.
- Un cluster attesté utilise un fournisseur de clés de confiance (trusted key provider).
- Vous pouvez mélanger un fournisseur de clés de confiance et un fournisseur de clés standard dans le même environnement vSphere.
- Lorsque vous ajoutez un périphérique TPM virtuel à une machine virtuelle, les fichiers du répertoire principal de la VM sont chiffrés avec le fournisseur de clés de confiance.
Les disques virtuels ne sont pas chiffrés par défaut, mais ils peuvent l’être si vous appliquez une stratégie de stockage de chiffrement à la VM.
¶ Chiffrement de VM avec un fournisseur de clés de confiance
Une machine virtuelle chiffrée avec un fournisseur de clés de confiance (Trusted Key Provider) possède une icône légèrement différente de celle d’une VM chiffrée avec un fournisseur de clés standard.
Elle présente également les caractéristiques suivantes :
- Elle ne peut s’exécuter que sur des hôtes ESXi attestés auprès du cluster vSphere Trust Authority.
- Elle ne peut pas être migrée vers un hôte ESXi qui n’est pas attesté auprès du même cluster vSphere Trust Authority.
Une machine virtuelle chiffrée avec un fournisseur de clés standard peut être migrée vers un hôte ESXi attesté,
mais elle continue à utiliser le fournisseur de clés standard.
¶ Identification des fournisseurs de clés de chiffrement de VM
Dans le client vSphere, le résumé de la machine virtuelle (VM summary) indique le type de fournisseur de clés utilisé pour le chiffrement.
La commande suivante : crypto-util dictionary describe /<path>/<vm>.vmx ne précise pas si la machine virtuelle est chiffrée avec un fournisseur de clés standard ou de confiance.
Cependant, le nom du fournisseur de clés apparaît dans la sortie de la commande, ce qui permet d’établir une corrélation.
¶ Migration d’une VM chiffrée avec un fournisseur de clés de confiance
Une machine virtuelle (VM) chiffrée avec un Trusted Key Provider (fournisseur de clés de confiance) ne peut pas être migrée vers un hôte ESXi qui n’est pas attesté contre le même cluster vSphere Trust Authority.
Le vSphere Client affiche un problème de compatibilité indiquant que l’hôte de destination n’est pas approuvé ni attesté.
¶ Lab 20 : Configuration de vCenter pour fonctionner avec un KMS externe
Ajoutez un serveur de gestion des clés (KMS) à votre vCenter depuis le vSphere Client :
- Configurez un KMS dans vCenter.
- Établissez une relation de confiance entre le KMS et vCenter.
Retrouvez le lien du Lab en cliquant ici : Lab 20 : Accéder à l'environnement de lab
¶ Lab 21 : Création d’une machine virtuelle chiffrée
Chiffrez une nouvelle machine virtuelle à l’aide d’un fournisseur de clés standard :
- Déployez une machine virtuelle chiffrée.
- Confirmez que la machine virtuelle est chiffrée avec un fournisseur de clés standard.
Retrouvez le lien du Lab en cliquant ici : Lab 21 : Accéder à l'environnement de lab
¶ Revue des objectifs d’apprentissage
- Décrire vSphere Trust Authority
- Énumérer les cas d’utilisation de vSphere Trust Authority
- Expliquer l’architecture générale de vSphere Trust Authority
¶ Points clés
- vSphere vMotion chiffré est disponible pour toutes les machines virtuelles, qu’elles soient chiffrées ou non.
- Si vous utilisez le chiffrement de VM et que l’hôte ESXi tombe en panne, le core dump (vidage mémoire) résultant est chiffré afin de protéger les données du client.
- Pour sécuriser la communication entre le serveur KMIP (KMS) et le client KMIP (vCenter), une relation de confiance doit être établie.
- Le chiffrement des VM ne peut pas fonctionner sans vCenter, car vCenter communique avec le KMS et gère les clés utilisées pour le chiffrement.
- Pour activer vSphere Trust Authority, vous devez ajouter un utilisateur au groupe vSphere TrustedAdmins.
Chapitre précédent : 8 - Sécurité et contrôle d'accès vSphere