Présentation des clés de chiffrement gérées par le client (CMEK, Customer Managed Encryption Keys)

Cette page décrit le fonctionnement des clés de chiffrement gérées par le client (CMEK, Customer Managed Encryption Keys) avec Cloud SQL. Pour utiliser cette fonctionnalité immédiatement, consultez la section Utiliser des clés de chiffrement gérées par le client (CMEK).

La fonctionnalité CMEK est-elle adaptée à mes besoins ?

Les clés de chiffrement gérées par le client sont destinées aux organisations qui traitent des données sensibles ou réglementées pour lesquelles elles doivent gérer leurs propres clés de chiffrement.

Chiffrement géré par Google et chiffrement géré par le client

La fonctionnalité CMEK vous permet d'utiliser vos propres clés de chiffrement pour les données au repos dans Cloud SQL. Après l'ajout des clés de chiffrement gérées par le client, Cloud SQL utilise votre clé pour accéder aux données à chaque appel d'API.

Les clés de chiffrement des données (DEK, Data Encryption Key) et les clés de chiffrement de clé (KEK, Key Encryption Key) gérées par Google permettent de chiffrer Cloud SQL. Il existe deux niveaux de chiffrement :

  1. La clé DEK chiffre les données.
  2. La clé KEK chiffre la clé DEK.

L'instance Cloud SQL stocke la clé DEK chiffrée ainsi que les données chiffrées sur le disque persistant, et Google gère la clé KEK Google. Avec les clés de chiffrement gérées par le client, vous créez une clé qui encapsule la clé KEK Google. Les clés de chiffrement gérées par le client vous permettent de créer, de révoquer et de supprimer la clé KEK.

Les clés de chiffrement gérées par le client sont stockées dans un service géré appelé Cloud Key Management Service (Cloud KMS).

Les schémas ci-dessous montrent le fonctionnement du chiffrement des données au repos dans une instance Cloud SQL en cas d'utilisation du chiffrement Google par défaut et en cas d'utilisation des clés de chiffrement gérées par le client.

Sans CMEK

Les données sont importées dans Google puis divisées en fragments, et chacun d'entre eux est chiffré avec une clé de chiffrement des données unique. Les clés de chiffrement des données sont encapsulées à l'aide d'une clé de chiffrement de clé. Avec le chiffrement Google par défaut, la clé de chiffrement de clé est extraite du keystore interne de Google. Les fragments chiffrés ainsi que les clés de chiffrement encapsulées sont distribués sur l'ensemble de l'infrastructure de stockage de Google.

Avec CMEK

Les données sont importées dans Google puis divisées en fragments, et chacun d'entre eux est chiffré avec une clé de chiffrement des données unique. Les clés de chiffrement des données sont encapsulées à l'aide d'une clé de chiffrement de clé. Avec CMEK via Cloud KMS, la clé de chiffrement de clé est extraite de Cloud KMS. Les fragments chiffrés ainsi que les clés de chiffrement encapsulées sont distribués sur l'ensemble de l'infrastructure de stockage de Google.

Lors du déchiffrement des données encapsulées avec des clés de chiffrement gérées par le client, Cloud SQL utilise la clé KEK pour déchiffrer la clé DEK, puis il utilise la clé DEK non chiffrée pour déchiffrer les données au repos.

Fragment de données chiffré avec la clé DEK et stocké avec la clé DEK encapsulée Une requête de désencapsulation de la clé DEK est envoyée au stockage KMS, qui stocke la clé KEK non exportable. Le stockage KMS renvoie la clé DEK désencapsulée.

Quand Cloud SQL interagit-il avec les clés CMEK ?

Opération Remarques
Création d'une instance Lors de la création de l'instance, vous configurez celle-ci de sorte qu'elle utilise des clés de chiffrement gérées par le client.
Création d'une sauvegarde Lors des sauvegardes d'une instance pour laquelle CMEK est activé, les clés de chiffrement gérées par le client chiffrent les données utilisateur, telles que les requêtes utilisateur et les réponses à ces requêtes. Les sauvegardes d'une instance activée avec CMEK héritent de son chiffrement avec la même clé Cloud KMS que l'instance source.
Restauration d'une instance Lors des restaurations d'une instance pour laquelle CMEK est activé, Cloud SQL utilise la clé pour accéder aux données de l'instance de sauvegarde en cours de restauration. Lors d'une restauration sur une autre instance, l'instance cible peut utiliser une clé différente pour le chiffrement.
Création d'une instance dupliquée Les instances dupliquées avec accès en lecture d'une instance pour laquelle CMEK est activé héritent du chiffrement CMEK avec la même clé Cloud KMS que l'instance principale.
Création de clones Les clones d'une instance pour laquelle CMEK est activé héritent du chiffrement CMEK avec la même clé Cloud KMS que l'instance source.
Mise à jour d'une instance Lors de la mise à jour d'une instance pour laquelle CMEK est activé, Cloud SQL vérifie la clé CMEK.

Quels emplacements acceptent les instances Cloud SQL utilisant CMEK ?

CMEK est disponible dans tous les emplacements d'instances de Cloud SQL.

Comprendre les comptes de service

Lorsque CMEK est activé sur vos instances Cloud SQL, vous devez utiliser un compte de service pour demander un accès par clé à partir de Cloud KMS.

Pour utiliser une clé de chiffrement gérée par le client sur un projet, vous devez disposer d'un compte de service et accorder à cette clé l'accès à ce compte. Le compte de service doit être créé dans le projet et visible dans toutes les régions.

Si vous utilisez la console pour créer une instance, Cloud SQL crée automatiquement le compte de service lorsque vous choisissez l'option Clé gérée par le client (si un compte de service n'existe pas déjà). Lorsque Cloud SQL crée automatiquement le compte de service, vous n'avez pas besoin d'autorisations particulières sur votre compte utilisateur.

Comprendre les clés

Dans Cloud KMS, vous devez créer un trousseau avec une clé de chiffrement, et y associer un emplacement. Lorsque vous créez une instance Cloud SQL, vous sélectionnez cette clé pour chiffrer l'instance.

Lorsque vous créez des instances Cloud SQL qui utilisent des clés de chiffrement gérées par le client, vous devez connaître l'ID et la région de ces clés. Vous devez placer les nouvelles instances Cloud SQL dans la région où se trouve la clé de chiffrement gérée par le client associée à l'instance. Vous pouvez créer un projet unique pour les clés et les instances Cloud SQL, ou un projet distinct pour chaque élément.

Les clés de chiffrement gérées par le client utilisent le format suivant :

projects/[CMEK_ENABLED_PROJECT]/locations/[REGION]/keyRings/[RING_NAME]/cryptoKeys/[KEYNAME]

Lorsque vous désactivez la version de clé, Cloud SQL suspend les instances chiffrées avec cette version. Lorsque vous réactivez la version de clé, Cloud SQL réactive les instances chiffrées avec cette version.

Lorsque vous effectuez une rotation de clés, les instances chiffrées avec l'une de ces clés ne sont pas chiffrées une nouvelle fois avec la nouvelle version de clé primaire.

Comment rendre les données chiffrées par CMEK définitivement inaccessibles ?

Vous pouvez être amené à détruire définitivement des données chiffrées avec CMEK. Cette opération implique de supprimer la version correspondante de la clé de chiffrement gérée par le client. Vous ne pouvez pas détruire le trousseau ou la clé, mais vous pouvez supprimer les versions de la clé.

Comment exporter et importer des données depuis et vers une instance utilisant CMEK ?

Si vous souhaitez que vos données restent chiffrées avec une clé gérée par le client lors d'une exportation ou d'une importation, vous devez définir cette clé sur le bucket Cloud Storage avant d'exporter des données. Il n'existe pas d'exigences ni de restrictions particulières concernant l'importation de données vers une nouvelle instance lorsque ces données étaient précédemment stockées sur une instance utilisant une clé de chiffrement gérée par le client.

Restrictions

Les restrictions suivantes s'appliquent en cas d'utilisation de clés de chiffrement gérées par le client :

  • Vous ne pouvez pas activer les clés de chiffrement gérées par le client sur une instance existante.
  • Vous ne pouvez pas alterner les versions de clé sur les instances existantes.
  • Vous ne pouvez pas attribuer une version de clé différente à une instance dupliquée.
  • Vous ne pouvez pas attribuer une version de clé différente à un clone.
  • Vous ne pouvez pas utiliser des clés de chiffrement gérées par le client pour chiffrer les éléments suivants :
    • Serveurs externes (instances primaires externes et instances dupliquées externes)
    • Métadonnées d'instance, telles que l'ID d'instance, la version de la base de données, le type de machine, les options, le planning des sauvegardes, etc.
  • Vous ne pouvez pas utiliser de clés de chiffrement gérées par le client pour chiffrer les données utilisateur en transit, telles que les requêtes utilisateur et les réponses à ces requêtes.

Étapes suivantes