Avantages du chiffrement géré par le client

Le chiffrement géré par le client présente plusieurs avantages par rapport au chiffrement géré par l' IBM.

Vous contrôlez vos clés :

• Comme vous utilisez des clés gérées par le client, vous contrôlez le chiffrement de vos volumes d’ Block Storage for VPC, de vos partages de fichiers et de vos images personnalisées.
• Vous autorisez le service IBM VPC à utiliser vos clés racine pour chiffrer vos données. Vous pouvez révoquer l'accès à tout moment pour n'importe quelle raison.
• Vos données sont protégées pendant leur transfert du système de stockage vers l'hyperviseur et l'hôte dans le VPC, et au repos dans Block Storage for VPC et File Storage for VPC.

Chiffrement des volumes d'amorçage et de données :

• Vos données Block Storage for VPC sont toujours chiffrées avec vos propres clés au repos et en mouvement.
• Chaque volume d'amorçage et de données est chiffré au repos avec une clé de chiffrement principale unique. Si la clé est compromise, aucun autre volume d' Block Storage for VPC s n'est affecté, car la clé compromise ne protège qu'un seul volume.
• Les volumes de démarrage principaux créés à partir d’images d’ Linux s ou de Windows sont chiffrés par défaut à l’aide du chiffrement géré par l’ IBM. Si vous créez une instance à partir d'une image standard et que vous spécifiez un chiffrement géré par le client pour les volumes de données, les données écrites sur ces volumes sont protégées par ce chiffrement géré par le client.
• Vous contrôlez le nombre et l'utilisation des clés racine pour appliquer le chiffrement d'enveloppe au niveau du volume. Par exemple, vous pouvez choisir de chiffrer votre volume d'amorçage avec une clé racine et les volumes de données avec une clé racine différente.
• Les instantanés créés à partir de volumes de démarrage et de données héritent du chiffrement géré par le client du volume source.

Chiffrement des partages de fichiers :

• Les données de partage de fichiers sont toujours chiffrées avec vos propres clés au repos.

• Vous contrôlez le nombre et l'utilisation des clés racine à utiliser pour le chiffrement d'enveloppe au niveau des partages de fichiers. En d'autres termes, vous pouvez choisir de chiffrer tous vos partages de fichiers avec la même clé racine ou chaque partage de fichiers avec des clés différentes. Vous pouvez également chiffrer certains partages de fichiers avec une clé racine et d'autres avec des clés racines différentes. Vous disposez d'une flexibilité complète pour implémenter l'utilisation de vos clés racine en fonction de vos besoins individuels en matière de sécurité.

• Gérez les clés racine de vos partages de fichiers en effectuant la rotation des clés, ou en désactivant ou en supprimant des clés. Vous pouvez restaurer les clés supprimées dans les 30 jours suivant leur suppression.

Chiffrement de vos images personnalisées :

• Vous pouvez chiffrer manuellement une image en créant une copie chiffrée à l'aide de QEMU.
• Vous pouvez créer des images personnalisées chiffrées à partir de volumes d'amorçage chiffrés. Pour plus d'informations, voir A propos des images personnalisées chiffrées.

Excellentes performances :

• Le chiffrement géré par le client utilise le chiffrement par hyperviseur sur l’infrastructure VPC, ce qui offre d’excellentes performances d’E/ Block Storage for VPC s chiffrées pour vos instances de serveurs virtuels.
• Grâce à l'infrastructure VPC, vous pouvez créer et démarrer 1 000 instances dotées de volumes de démarrage chiffrés gérés par le client en quelques minutes.
• L'hyperviseur gérant le chiffrement et le déchiffrement, le système d'exploitation invité n'a pas besoin de modifier les données. Le système d'exploitation invité ne sait pas que le chiffrement est effectué.

Rotation des clés et suivi des audits :

• Vous pouvez effectuer manuellement la rotation de vos clés racines via l'API ou l'interface de ligne de commande (CLI), ou configurer une politique de rotation pour que vos clés soient renouvelées automatiquement. La rotation des clés remplace le matériel cryptographique d'origine de la clé racine et génère un nouveau matériel. Pour plus d'informations, voir Rotation des clés des ressources VPC.

• Le chiffrement géré par le client fournit des journaux d'audit relatifs à l'utilisation de la clé racine. Les événements sont générés et collectés automatiquement sur IBM Cloud Logs.

Technologie de chiffrement VPC IBM Cloud

Le chiffrement est géré par la technologie d'hyperviseur d' IBM Cloud VPC pour vos instances. Cette fonctionnalité offre un niveau de sécurité supérieur à celui des solutions qui ne proposent qu'un chiffrement au repos au niveau des nœuds de stockage. Les données sont toujours chiffrées à l'aide d'un chiffrement d'enveloppe au sein de l' IBM Cloud.

Les images stockées et personnalisées utilisent le format de fichier QCOW2 (QEMU Copy On Write Version 2). Le format de chiffrement LUKS sécurise les fichiers au format QCOW2. IBM Cloud utilise la suite de chiffrement AES-256 et les options de mode de chiffrement XTS avec LUKS. Cette combinaison offre un niveau de sécurité bien supérieur à celui de l'AES-CBC, ainsi qu'une meilleure gestion des phrases de passe pour la rotation des clés, et propose des options de remplacement des clés si celles-ci sont compromises.

Au total, quatre clés protègent vos données :

• Une clé gérée parIBM chiffre vos données dans le système de stockage dorsal. Le chiffrement géré par IBMsur le système de stockage est toujours appliqué, même lorsque vous utilisez le chiffrement géré par le client. Cette clé protège vos données en transit et au repos.

  Le chiffrement de la liaison réseau entre votre charge de travail située en dehors d' IBM Cloud et une charge de travail située au sein d' IBM Cloud relève de votre responsabilité. Pour plus d'informations, voir Chiffrement dans Contrôle de sécurité et de conformité.

• Une clé de chiffrement de données (DEK) chiffre les données dans le fichier QCOW2 et sécurise les clusters de données par blocs sur le disque virtuel. Le DEK est géré par la technologie open source QEMU et généré automatiquement lors de la création d'un fichier « QCOW2 ».

  Pour les volumes d' Block Storage for VPC s créés à partir d'images de base, le DEK est généré par QEMU s'exécutant sur des hyperviseurs KVM fournis par l' IBM. Pour les volumes Block Storage for VPC créés à partir d'images personnalisées, il est généré par QEMU qui s'exécute sur votre nœud sur site. La clé DEK (AES-256) est chiffrée avec une phrase passe LUKS et stockée sous sa forme chiffrée dans le fichier QCOW2.

• Une phrase de passe LUKS (également appelée clé de chiffrement) permet de chiffrer et de déchiffrer la DEK. Cette clé est gérée par l'infrastructure VPC de génération 2 et est chiffrée par votre clé racine. Il est stocké en tant que métadonnées associées au volume Block Storage for VPC qui contient le fichier QCOW2.

• Une clé racine client qui chiffre les phrases passe de volume, de partage et d'image personnalisée avec le chiffrement d'enveloppe, qui crée une clé DEK ou WDEK encapsulée. Les clés racines sont gérées par le client à partir d'instances KMS, puis stockées et gérées en toute sécurité au sein de l'instance KMS. La clé racine désencapsule (déchiffre) également la clé WDEK, pour que vous puissiez accéder à vos données chiffrées.

Services de gestion de clés pris en charge

Key Protect est le service de gestion de clés préféré pour le chiffrement géré par le client dans VPC. Il est disponible en deux options de déploiement :

Choisir entre Standard et Dédié :

• Utiliser Standard pour la plupart des charges de travail qui nécessitent un chiffrement géré par le client avec une infrastructure partagée rentable.
• Utilisez Dedicated pour les industries hautement réglementées, les données sensibles qui nécessitent une sécurité maximale, ou lorsque vous avez besoin d'un contrôle total sur la racine de confiance.

Pour plus d'informations sur les différences et le moment d'utiliser chaque option, voir About Standard and Dedicated Key Protect.

Vous pouvez voir Key Protect Standard décrit comme BYOK (Bring Your Own Key) et Key Protect Dedicated comme KYOK (Keep Your Own Key).

Chiffrement d'enveloppe

Les clés racine servent de clés d'encapsulage de clé et sont une composante importante du chiffrement d'enveloppe. Avec le chiffrement de l'enveloppe, les clés racine chiffrent les mots de passe composés LUKS (également appelées clés de chiffrement de données) qui, à leur tour, protègent les clés de chiffrement de données (DEK) qui chiffrent vos données sur le disque virtuel.

Le service KMS stocke votre clé et la rend disponible lors du chiffrement de volumes et d'images personnalisées. Vous gérez également vos clés dans le service KMS.

Une clé de chiffrement principale unique est attribuée aux volumes de stockage en bloc et aux partages de fichiers. Cette clé unique est générée par l'hyperviseur hôte de l'instance. Cette clé est chiffrée par une phrase passe et encapsulée (chiffrée) par la clé racine, pour créer une clé DEK ou WDEK encapsulée. La clé WDEK est stockée sous forme de métadonnées avec le volume ou l'image et n'est pas disponible dans les interfaces VPC.

Les images personnalisées sont chiffrées à l'aide de votre propre phrase de passe LUKS, que vous créez à l'aide de QEMU. Une fois l'image chiffrée, vous chiffrer la phrase de passe à l'aide de votre clé racine stockée dans le KMS.

Pour plus d’informations sur le chiffrement d’enveloppe, consultez Key Protect- Protéger les données grâce au chiffrement d’enveloppe.

Considérations régionales et interrégionales sur les clés racine

Lorsque vous utilisez le chiffrement géré par le client pour les volumes, les partages de fichiers et les images personnalisées, vous pouvez conserver vos clés racines dans la même région que vos ressources ou dans une autre région (inter-régional).

Les clés interrégionales offrent une plus grande disponibilité des clés avec le compromis d'un temps d'attente légèrement supérieur. Vous pouvez créer et gérer des clés racine dans une région et les appliquer aux ressources d'une autre région. Les clés interrégionales sont disponibles dans toutes les régions.

Pour des performances optimales et plus de sécurité, utilisez des clés racine qui se trouvent dans la même région que vos ressources chiffrées. Le service régional utilise des points d'extrémité privés dans plusieurs zones de disponibilité. Si une zone spécifique n'est pas disponible, vous pouvez continuer à accéder à vos clés racines et à vos ressources chiffrées depuis une autre zone.

Lorsque vous utilisez des clés racine qui se trouvent dans la même région ou dans des régions différentes, l'intégralité du trafic réseau est dirigé vers un point d'extrémité privé. En d'autres termes, vos clés chiffrent et déchiffrent les ressources sur un réseau privé inaccessible depuis Internet. Pour plus d'informations sur les points de terminaison privés, consultez la section Accès sécurisé aux services à l'aide des points de terminaison de service. Vous pouvez consulter la liste des points de terminaison privés dans la console en accédant à Liste des ressources > Sécurité, puis en cliquant sur une instance d' Key Protect. Dans le menu de gauche, sélectionnez Endpoints.

Mise en place d'un chiffrement géré par le client

Pour mettre en place un chiffrement géré par le client pour vos ressources VPC, vous devez provisionner un service de gestion des clés, créer ou importer des clés racine et autoriser l'accès au service. Pour des instructions détaillées sur la configuration et les conditions préalables, voir Planification du cryptage des données.

Une fois l'installation terminée, vous pouvez gérer vos clés en les désactivant, en les activant, en les faisant pivoter ou en les supprimant selon vos besoins. Pour plus d'informations, voir Gestion du cryptage des données.

Diagrammes de flux de la spécification du chiffrement géré par le client des volumes

Vous pouvez spécifier le chiffrement géré par le client lorsque vous créez des volumes Block Storage for VPC lors de la mise à disposition d'instance. Vous pouvez également le spécifier lors de la création d'un volume autonome.

La figure 1 illustre la procédure de création d'un volume de données avec le chiffrement géré par le client lors de la mise à disposition des instances. Le volume est automatiquement associé à l'instance.

La figure 2 illustre la procédure permettant de créer un volume autonome et de l'associer ultérieurement à une instance.

A propos des images personnalisées chiffrées

Vous pouvez créer une image personnalisée QCOW2 qui satisfait la configuration requise pour l'infrastructure IBM Cloud VPC et la chiffrer à l'aide de votre propre phrase passe LUKS et de votre propre clé racine. Une fois que vous avez chiffré l'image personnalisée avec votre propre phrase passe, téléchargez-la dans IBM Cloud Object Storage.

Pour importer une image personnalisée chiffrée vers l' IBM Cloud VPC e, commencez par configurer une instance du service de gestion des clés (KMS). Dans l'instance KMS, créez une clé racine pour encapsuler (chiffrer) la phrase de passe. L'encapsulation de la phrase passe génère une clé DEK encapsulée (WDEK). Cette clé WDEK protège la phrase passe lors de l'importation, afin que vos données soient sécurisées. La phrase de passe est stockée sous forme chiffrée dans le service d'images et n'est déchiffrée que lors du démarrage d'un serveur virtuel utilisant l'image chiffrée.

Une fois les autorisations IAM requises mises en place, vous pouvez importer l'image chiffrée depuis IBM Cloud Object Storage. Vous importez l'image dans le VPC et spécifiez le nom de ressource cloud (CRN) de votre clé racine stockée dans le KMS. Vous spécifiez également le texte chiffré de votre clé WDEK, qui correspond à la phrase passe que vous utilisez pour chiffrer votre image, encapsulée par la clé racine.

Lorsque vous effectuez une importation via l'API ou l'interface utilisateur, vous fournissez un seul fichier d'image de démarrage QCOW2 dont la taille peut varier de 10 Go à 250 Go. Ce fichier est privé et accessible uniquement par le titulaire du compte dans lequel il est importé. La région dans laquelle vous importez l'image chiffrée est celle dans laquelle vous créez des instances de serveur virtuel à partir de cette image. L'image chiffrée est affichée avec les autres images personnalisées que vous êtes autorisé à utiliser. Dans la console, une icône en forme de cadenas à côté du nom indique qu'il s'agit d'une image personnalisée chiffrée.

Si vous importez une image chiffrée dont la taille de disque virtuel n'est pas exactement de 100 Go et que vous l'utilisez pour mettre à disposition une instance, puis que vous tentez de créer une image personnalisée à partir du volume d'amorçage de cette instance, l'appel POST /images va renvoyer une erreur.

Lorsque vous provisionnez une instance de serveur virtuel à partir de l'image chiffrée, aucune autre information relative au chiffrement n'est nécessaire. La clé de chiffrement de données encapsulée (WDEK) et la clé racine sont stockées sous forme de métadonnées avec l'image. La clé WDEK permet d'accéder à l'image chiffrée au démarrage d'une instance de serveur virtuel qui utilise l'image chiffrée.

Lors de la mise à disposition, les données du volume d'amorçage de l'instance sont également chiffrées à l'aide de la clé racine que l'image personnalisée utilise avec la phrase passe générée. Vous pouvez également fournir une autre clé racine pour le volume d'amorçage.

Une fois l'instance de serveur virtuel créée, vous pouvez consulter l'image personnalisée et voir le CRN de la clé racine. Vous pouvez également faire tourner la clé racine et être averti par le KMS lorsque votre image chiffrée WDEK est automatiquement réemballée (rechiffrée).

Tout volume secondaire que vous créez et que vous joignez à partir de l'image personnalisée chiffrée utilise une phrase de passe différente de celle de l'image personnalisée de base. Vous pouvez, si vous le souhaitez, fournir une clé racine différente pour les volumes secondaires créés lors du provisionnement de l'instance.

Pour plus d'informations sur la création d'images personnalisées, voir Création d'une image personnalisée chiffrée. Consultez également les informations relatives à la création d'une image personnaliséeLinux et d'une image personnalisée Windows.

Diagramme de flux de la spécification du chiffrement géré par le client des images personnalisées

La figure 3 illustre la procédure de chiffrement des images personnalisées à l'aide de vos propres clés de chiffrement.