Suivez les meilleures pratiques de chiffrement des machines virtuelles pour éviter les problèmes ultérieurement, par exemple, lorsque vous générez un bundle vm-support.
Meilleures pratiques générales
Suivez les meilleures pratiques générales suivantes pour éviter les problèmes.
- Ne chiffrez pas une machine virtuelle vCenter Server Appliance.
- Si votre hôte ESXi échoue, récupérez le bundle de support dès que possible. La clé de l'hôte doit être disponible pour générer un bundle de support qui utilise un mot de passe, ou pour déchiffrer un vidage de mémoire. Si l'hôte est redémarré, il est possible que sa clé change. En pareil cas, vous ne pouvez plus générer un bundle de support avec un mot de passe ni déchiffrer les vidages de mémoire dans le bundle de support avec la clé de l'hôte.
- Gérez les noms de cluster du serveur de gestion des clés avec précaution. Si le nom de cluster du serveur de gestion des clés change pour un serveur de gestion des clés déjà utilisé, une machine virtuelle chiffrée à l'aide des clés de ce serveur prend un état verrouillé pendant la mise sous tension ou l'enregistrement. Dans ce cas, supprimez le serveur de gestion des clés à partir de vCenter Server et ajoutez-le avec le nom de cluster que vous avez utilisé au départ.
- Ne modifiez pas les fichiers VMX et les fichiers descripteurs VMDK. Ces fichiers contiennent le bundle de chiffrement. Il est possible que vos modifications rendent la machine virtuelle irrécupérable et que le problème de récupération ne puisse pas être résolu.
- Le processus de chiffrement chiffre les données sur l'hôte avant qu'elles soient écrites dans le stockage. Les fonctionnalités de stockage centralisé comme la déduplication et la compression peuvent ne pas être performantes pour les machines virtuelles chiffrées. Lorsque vous utilisez le chiffrement des machines virtuelles vSphere, envisagez d'effectuer des compromis de stockage.
- Le chiffrement nécessite une utilisation importante du CPU. AES-NI améliore de manière significative les performances du chiffrement. Activez AES-NI dans votre BIOS.
Meilleures pratiques pour les vidages de mémoire chiffrés
Suivez ces meilleures pratiques pour éviter les problèmes lorsque vous voulez examiner un vidage de mémoire dans le cadre du diagnostic d'un incident.
- Établissez une stratégie concernant les vidages de mémoire. Les vidages de mémoire sont chiffrés, car ils peuvent contenir des informations sensibles telles que des clés. Si vous déchiffrez un vidage de mémoire, prenez en compte ses informations sensibles. Les vidages de mémoire ESXi peuvent contenir des clés de l'hôte ESXi des machines virtuelles qui s'y trouvent. Envisagez de modifier la cl de l'hôte et de rechiffrer les machines virtuelles chiffrées après avoir déchiffré un vidage de mémoire. Vous pouvez effectuer ces deux tâches à l'aide de vSphere API.
Reportez-vous à Chiffrement de machines virtuelles vSphere et vidages mémoire pour plus de détails.
- Utilisez toujours un mot de passe lorsque vous collectez un bundle vm-support. Vous pouvez spécifier le mot de passe lorsque vous générez le bundle de support à partir de vSphere Client ou à l'aide de la commande vm-support.
Le mot de passe rechiffre les vidages de mémoire utilisant des clés internes de façon à utiliser les clés reposant sur le mot de passe. Vous pouvez utiliser ultérieurement le mot de passe pour déchiffrer les vidages de mémoire chiffrés susceptibles d'être intégrés dans le bundle de support. Les vidages de mémoire et les journaux non chiffrés ne sont pas affectés par l'utilisation de l'option de mot de passe.
- Le mot de passe que vous spécifiez pendant la création du bundle vm-support n'est pas conservé dans les composants vSphere. Vous êtes responsable du suivi des mots de passe pour les bundles de support.
- Avant de modifier la clé de l'hôte, générez un bundle vm-support avec un mot de passe. Vous pourrez ultérieurement utiliser le mot de passe pour accéder à tous les vidages de mémoire susceptibles d'avoir été chiffrés avec l'ancienne clé de l'hôte.
Meilleures pratiques de gestion du cycle de vie des clés
- Vous êtes responsable de la mise en place de stratégies garantissant la disponibilité du serveur de gestion des clés.
Si le serveur de gestion des clés n'est pas disponible, il est impossible d'effectuer les opérations liées aux machines virtuelles nécessitant que vCenter Server demande la clé auprès du serveur de gestion des clés. Cela signifie que l'exécution des machines virtuelles se poursuit et que vous pouvez les mettre sous tension, les mettre hors tension et les reconfigurer. Toutefois, vous ne pouvez pas les déplacer vers un hôte qui ne dispose pas des informations concernant la clé.
La plupart des solutions KMS incluent des fonctionnalités de haute disponibilité. Vous pouvez utiliser vSphere Client ou l'API pour spécifier un cluster KMS et les serveurs KMS associés.
- Vous êtes responsable du suivi des clés et de l'application de corrections sur les clés de machines virtuelles existantes ne sont pas à l'état Active.
Le standard KMIP définit les états suivants pour les clés.
- Pré-active
- Active
- Désactivée
- Compromise
- Détruite
- Détruite compromise
Le chiffrement des machines virtuelles vSphere utilise uniquement les clés à l'état Active pour la chiffrement. Si une clé est à l'état Pré-active, le chiffrement des machines virtuelles vSphere l'active. Si l'état de la clé est Désactivée, Compromise, Détruite ou Détruite compromise, cela signifie que vous ne pouvez pas chiffrer la machine virtuelle ou le disque virtuel présentant cet état.
Pour les clés ayant un autre état, les machines virtuelles qui les utilisent continuent de fonctionner. La réussite d'une opération de clonage ou de migration varie selon que la clé est déjà dans l'hôte ou non.- Si la clé est dans l'hôte de destination, l'opération réussit même si la clé n'est pas à l'état Active sur le serveur de gestion des clés.
- Si les clés requises de la machine virtuelle et du disque virtuel ne sont pas dans l'hôte de destination, vCenter Server doit extraire les clés du serveur de gestion des clés. Si l'état de la clé est Désactivée, Compromise, Détruite ou Détruite compromise, vCenter Server affiche une erreur et l'opération échoue.
Une opération de clonage ou de migration réussit si la clé est déjà dans l'hôte. L'opération échoue si vCenter Server doit extraire les clés du serveur de gestion des clés.
Si une clé n'est pas à l'état Active, effectuez une opération de rechiffrement à l'aide de l'API. Reportez-vous au Guide de programmation de vSphere Web Services SDK.
Meilleures pratiques en matière de sauvegarde et de restauration
- Toutes les architectures de sauvegarde ne sont pas prises en charge. Reportez-vous à la section Interopérabilité du chiffrement des machines virtuelles.
- Configurez des stratégies pour les opérations de restauration. Étant donné que les sauvegardes sont toujours en texte clair, envisagez de chiffrer les machines virtuelles juste après la restauration. Vous pouvez spécifier que la machine virtuelle est chiffrée dans le cadre de l'opération de restauration. Si possible, chiffrez la machine virtuelle dans le cadre de l'opération de restauration pour éviter toute exposition des informations sensibles. Pour modifier la stratégie de chiffrement pour les disques associés à la machine virtuelle, modifiez la stratégie de stockage du disque.
- Étant donné que les fichiers de base de machine virtuelle sont chiffrés, assurez-vous que les clés de chiffrement sont disponibles au moment de la restauration.
Meilleures pratiques en matière de performances
- Les performances du chiffrement dépendent du CPU et de la vitesse du stockage.
- Le chiffrement de machines virtuelles existantes prend plus de temps que le chiffrement d'un machine virtuelle lors de sa création. Si possible, chiffrez une machine virtuelle au moment de la créer.
Meilleures pratiques en matière de stratégie de stockage
Pour plus de détails sur la personnalisation des stratégies de stockage, reportez-vous à la documentation Stockage vSphere.
