À propos des clés de chiffrement gérées par le client (CMEK)

Ce document explique comment utiliser des clés de chiffrement gérées par le client (CMEK) dans Cloud Key Management Service (Cloud KMS) pour vos instances Memorystore pour Valkey. Le document décrit également les données chiffrées dans le stockage persistant et le comportement de vos instances lors des événements clés du cycle de vie.

Le chiffrement CMEK vous permet de contrôler les clés cryptographiques qui protègent vos données stockées. En gérant vos propres clés dans Cloud KMS, vous contrôlez mieux l'accès aux clés, leur rotation et leur utilisation, ce qui vous aide à répondre aux exigences strictes de conformité et réglementaires.

L'implémentation de CMEK fournit une couche de sécurité et de contrôle supplémentaire pour vos données persistantes, telles que les sauvegardes et les fichiers de persistance. Vous ne pouvez activer CMEK que sur de nouvelles instances. Vous ne pouvez pas appliquer de CMEK aux instances existantes.

À qui s'adresse CMEK ?

La fonctionnalité CMEK est destinée aux organisations qui traitent des données sensibles ou réglementées et qui doivent contrôler leurs propres clés de chiffrement. Pour savoir si vous devez utiliser CMEK pour chiffrer ces données, consultez Choisir où utiliser CMEK.

Chiffrement géré par le client

Les clés CMEK vous permettent d'utiliser vos clés cryptographiques pour protéger les données stockées dans les instances Memorystore pour Valkey. Pour chiffrer ces données, Memorystore pour Valkey utilise des clés de chiffrement des données (DEK) gérées par Google et des clés de chiffrement de clés (KEK) gérées par le client.

Vous pouvez choisir parmi les niveaux de chiffrement suivants :

  • Chiffrement des DEK : les DEK chiffrent les données dans Memorystore pour Valkey.
  • Chiffrement KEK : les KEK chiffrent les DEK.

Memorystore pour Valkey utilise des KEK pour chiffrer les DEK, et des DEK pour chiffrer les données stockées. Si vous utilisez CMEK, vous pouvez gérer les KEK qui chiffrent les DEK dans votre instance.

Le schéma suivant montre comment une instance utilise CMEK pour chiffrer les données. Les données importées dans l'infrastructure de stockage de Google sont divisées en fragments, et chacun d'eux est chiffré avec sa propre clé DEK. Cloud KMS fournit la KEK pour chiffrer les DEK, et l'infrastructure de stockage de Google distribue à la fois les blocs de données chiffrés et les DEK chiffrées dans le système.

Les données sont importées dans l'infrastructure de stockage de Google et divisées en fragments. Chaque fragment est chiffré avec sa propre clé DEK. Les DEK sont ensuite chiffrées à l'aide d'une KEK récupérée depuis Cloud KMS. Les fragments chiffrés et les DEK chiffrées sont répartis sur l'infrastructure de stockage.

Le schéma suivant montre comment Memorystore pour Valkey déchiffre les données chiffrées avec CMEK. Pour accéder à ces données chiffrées, Memorystore for Valkey envoie une requête à Cloud KMS, qui gère la KEK, afin de déchiffrer la DEK. Cloud KMS renvoie ensuite la clé DEK déchiffrée, que l'instance utilise pour déchiffrer les données stockées.

Fragment de données chiffré avec la clé DEK et stocké avec la clé DEK chiffrée. Une requête de déchiffrement de la DEK est envoyée à Cloud KMS, qui stocke la KEK. Cloud KMS renvoie la DEK déchiffrée.

Quelles données sont chiffrées à l'aide de clés CMEK ?

Le chiffrement CMEK chiffre les types de données client suivants stockés dans un espace de stockage persistant :

  • Sauvegardes : elles vous permettent de récupérer vos données à un moment précis, ainsi que de les exporter et de les analyser. Les sauvegardes sont également utiles pour les scénarios de reprise après sinistre, de migration de données, de partage de données et de conformité.
  • Persistance : Memorystore pour Valkey est compatible avec deux types de persistance :
    • Persistance RDB : enregistrez des instantanés de vos données dans un espace de stockage durable.
    • Persistance AOF : stockez les données de manière durable en enregistrant chaque commande d'écriture dans un fichier journal appelé fichier AOF (Append-Only File). En cas de défaillance ou de redémarrage du système, le serveur relit les commandes du fichier AOF de manière séquentielle pour restaurer vos données.
  • Métadonnées liées aux fonctionnalités de sécurité, comme l'authentification de base basée sur des jetons et le chiffrement en transit. Pour en savoir plus, consultez Sécuriser l'accès à vos instances à l'aide de l'authentification de base par jeton et À propos du chiffrement en transit.

Composants CMEK

Les sections suivantes décrivent les exigences et les comportements des comptes de service, des clés cryptographiques, des versions de clé et des règles d'administration qui composent votre architecture CMEK.

Comptes de service

Pour créer une instance compatible avec CMEK, vous devez attribuer le rôle roles/cloudkms.cryptoKeyEncrypterDecrypter au compte de service Memorystore pour Valkey qui utilise le format suivant :

service-PROJECT_NUMBER@gcp-sa-memorystore.iam.gserviceaccount.com

Cette autorisation permet au compte de service de demander l'accès aux clés à Cloud KMS.

Clés

Dans Cloud KMS, vous devez créer un trousseau de clés, puis une clé cryptographique qui utilise un algorithme de chiffrement symétrique. Lorsque vous créez une instance Memorystore pour Valkey, vous sélectionnez cette clé pour chiffrer l'instance. Vous pouvez créer un projet pour vos clés et vos instances, ou des projets différents pour chacune d'elles.

CMEK est disponible dans tous les emplacements d'instances Memorystore pour Valkey. Vous devez créer le trousseau de clés et la clé dans la même région que celle où vous souhaitez créer l'instance. Pour une instance multirégionale, vous devez définir le trousseau de clés et la clé sur le même emplacement que l'instance. Si les régions ou les emplacements ne correspondent pas, une requête de création de l'instance échoue.

Pour l'ID de ressource de la clé, CMEK utilise le format suivant :

projects/CMEK_ENABLED_PROJECT/locations/REGION/keyRings/KEY_RING_NAME/cryptoKeys/KEY_NAME

Pour savoir comment trouver les ID de ressources des clés existantes, consultez Obtenir un ID de ressource Cloud KMS.

Clés externes

Dans le cadre de votre stratégie CMEK, vous pouvez utiliser des clés externes. Pour ce faire, utilisez Cloud External Key Manager (Cloud EKM) afin de chiffrer les données dans Google Cloud à l'aide de clés externes que vous gérez.

Lorsque vous utilisez une clé Cloud EKM, Google n'a aucun contrôle sur la disponibilité de vos clés gérées en externe. Si une clé n'est pas disponible lorsque vous créez votre instance, Memorystore for Valkey ne crée pas l'instance. De plus, si la clé externe devient indisponible à un moment donné après la création de l'instance, Memorystore for Valkey désactive les sauvegardes et la persistance, mais les opérations de mise en cache en mémoire régulières continuent de diffuser le trafic.

Pour en savoir plus sur l'utilisation des clés externes, consultez la section Remarques.

Versions de clé

Cloud KMS stocke le matériel de clé cryptographique que vous utilisez pour chiffrer et déchiffrer vos données dans une version de clé. Une même clé peut contenir plusieurs versions de clé. Chaque fois que vous faites pivoter une clé, vous créez une version de clé.

Les sections suivantes décrivent le comportement de vos instances et de leurs données protégées lors d'événements clés du cycle de vie, tels que la désactivation, la destruction, la rotation, l'activation ou la restauration de versions de clés. Les sections expliquent également l'impact de la révocation de l'accès à une clé Cloud KMS ou de son remplacement, et fournissent des conseils sur le rechiffrement manuel des données.

Désactiver ou détruire une version de clé CMEK

Vous pouvez être amené à rendre définitivement inaccessibles des données chiffrées avec CMEK, par exemple lorsque vous corrigez une fuite de données. Pour détruire les données de manière très fiable (également appelée déchiquetage cryptographique), vous devez détruire la version de la clé. Pour en savoir plus sur la destruction de versions de clés, consultez Détruire et restaurer des versions de clé.

Si vous désactivez ou détruisez la version principale de votre clé, les conditions suivantes s'appliquent aux sauvegardes et à la persistance.

Sauvegardes

Lorsque vous détruisez la version de votre clé primaire, les restrictions suivantes s'appliquent aux sauvegardes de votre instance :

  • Vous ne pouvez pas créer de sauvegardes à la demande ni automatiques. Toutefois, si vous activez une version de clé plus ancienne, vous pouvez accéder à toutes les sauvegardes que vous avez créées à l'aide de cette version de clé.
  • Vous ne pouvez pas mettre à jour ni réactiver les sauvegardes automatiques tant que vous n'avez pas activé ou restauré la version de clé primaire. Pour en savoir plus, consultez Activer ou restaurer la version de clé CMEK principale.
Persistance

Lorsque vous détruisez la version de votre clé primaire, les restrictions suivantes s'appliquent à la persistance de votre instance :

  • Si vous configurez votre instance pour qu'elle utilise la persistance, Memorystore for Valkey la désactive lorsque la version de clé devient indisponible. L'utilisation de la persistance ne vous est plus facturée.
  • Memorystore for Valkey n'enregistre pas les nouvelles données dans un stockage persistant à l'aide de la clé CMEK.
  • Memorystore pour Valkey ne peut pas lire les données existantes présentes dans le stockage persistant.
  • Vous ne pouvez pas mettre à jour ni réactiver la persistance tant que vous n'avez pas activé ou restauré la version de clé primaire.

Si vous activez votre version principale de clé, mais que vous désactivez ou détruisez une ancienne version de clé, les conditions suivantes s'appliquent aux sauvegardes et à la persistance :

  • Vous pouvez créer des sauvegardes. Toutefois, si une sauvegarde est chiffrée avec une ancienne version de clé désactivée ou détruite, elle reste inaccessible.
  • Si vous activez la persistance, elle reste activée. Si l'ancienne version de clé utilisée dans la persistance est désactivée ou détruite, Memorystore pour Valkey effectue une mise à jour semblable à celle utilisée lors de la maintenance et rechiffre les données avec la version principale de la clé.

Révoquer l'accès à une clé Cloud KMS

Si vous révoquez l'accès à une clé Cloud KMS active en désactivant la clé ou en supprimant les autorisations IAM pour la clé, Memorystore pour Valkey donne la priorité à la disponibilité du cache principal. Les opérations de mise en cache en mémoire régulières continuent de diffuser du trafic.

Toutefois, les sauvegardes et la persistance sont désactivées. Memorystore pour Valkey cesse immédiatement d'écrire de nouvelles données sur le disque et ne lit pas les données du disque chiffré par le client dans la mémoire.

Rotation de la version principale de la clé CMEK

Si vous faites tourner votre version de clé principale et que vous en créez une autre, les conditions suivantes s'appliquent aux sauvegardes et à la persistance :

  • La dernière version principale de votre clé CMEK chiffre les nouvelles sauvegardes.
  • Aucun rechiffrement n'est effectué pour les sauvegardes existantes.
  • Pour la persistance, les nœuds n'effectuent aucune action. Les nœuds continuent d'utiliser l'ancienne version de la clé jusqu'au prochain événement de maintenance.

Rechiffrer manuellement les données protégées par une clé CMEK

Memorystore pour Valkey ne permet pas de réencrypter les données stockées à la demande. Vous ne pouvez pas déclencher manuellement un processus pour utiliser une nouvelle version de clé afin de rechiffrer les sauvegardes existantes ou les fichiers de persistance actifs. Toutefois, vous pouvez utiliser la nouvelle version de la clé pour chiffrer les données nouvellement écrites.

Si vous effectuez la rotation d'une clé et que vous devez forcer une instance à utiliser la nouvelle version de clé, les conditions suivantes s'appliquent aux sauvegardes et à la persistance :

Sauvegardes

Vous ne pouvez pas rechiffrer les sauvegardes existantes. Si la conformité exige que toutes les données soient chiffrées avec la clé la plus récente, créez une sauvegarde qui utilise cette clé, puis supprimez manuellement les sauvegardes existantes. Vous pouvez également exporter cette sauvegarde vers un bucket Cloud Storage afin d'utiliser la clé de chiffrement Cloud Storage.

Persistance

Pour forcer l'instance à utiliser une nouvelle clé Cloud KMS, vous pouvez exécuter une maintenance simulée sur l'instance. Une fois cette opération terminée, Memorystore pour Valkey peut écrire des données de persistance à l'aide de la version mise à jour de la clé primaire.

Remplacer une clé Cloud KMS protégée

Si vous remplacez une clé Cloud KMS protégée par une autre clé ou une nouvelle version de clé primaire, Memorystore pour Valkey n'applique cette modification qu'aux opérations futures.

Le remplacement d'une clé protégée a les conséquences suivantes sur vos ressources :

  • Sauvegardes : toutes les sauvegardes ultérieures sont chiffrées à l'aide de la nouvelle clé. Les sauvegardes existantes conservent leurs clés d'origine.
  • Persistance : la nouvelle clé est utilisée lors du prochain redémarrage de l'instance ou lors du prochain événement de maintenance.
  • Cache principal : le remplacement de cette clé n'a aucun impact. Les CMEK ne chiffrent pas les données en mémoire, car elles ne sont pas considérées comme des données stockées.

Activer ou restaurer la version de clé CMEK principale

Si vous activez ou restaurez la version principale de votre clé, les conditions suivantes s'appliquent aux sauvegardes et à la persistance :

  • Vous pouvez à nouveau créer des sauvegardes à la demande et automatiques.
  • Memorystore for Valkey effectue une mise à jour semblable à celle utilisée lors de la maintenance et réactive la persistance.

Contraintes liées aux règles d'administration

Memorystore pour Valkey est compatible avec les contraintes de règles d'administration pour CMEK. En utilisant ces contraintes, vous pouvez appliquer la protection CMEK à vos instances et limiter les clés Cloud KMS que vous pouvez utiliser pour cette protection.

Vous pouvez configurer les contraintes de règles d'administration suivantes :

  • constraints/gcp.restrictNonCmekServices : utilisez cette contrainte pour appliquer la protection CMEK à vos instances. Si l'API Memorystore pour Valkey figure dans la liste des services Deny de cette contrainte, vous ne pouvez pas créer d'instances non protégées par CMEK.
  • constraints/gcp.restrictCmekCryptoKeyProjects : utilisez cette contrainte pour limiter les clés Cloud KMS que vous pouvez utiliser pour la protection CMEK. Si vous configurez cette contrainte, les instances qui utilisent le chiffrement CMEK doivent utiliser une clé provenant d'un projet, d'un dossier ou d'une organisation autorisés.

Pour en savoir plus sur les contraintes liées aux règles d'administration CMEK que Google gère pour Memorystore pour Valkey, consultez Contraintes liées aux règles d'administration.

Tarifs

Memorystore pour Valkey facture une instance CMEK comme n'importe quelle autre instance. Il n'y a pas de frais supplémentaires. Pour en savoir plus, consultez la page Tarifs de Memorystore pour Valkey.

Vous utilisez l'API Cloud KMS pour gérer les CMEK. Lorsque vous créez une instance Memorystore pour Valkey avec CMEK, Memorystore utilise la clé de manière périodique pour chiffrer les données.

Cloud KMS vous facture le coût de la clé, ainsi que les opérations de chiffrement et de déchiffrement lorsque Memorystore pour Valkey utilise la clé. Pour en savoir plus, consultez la page Tarifs de Cloud KMS.

Limites

Les limites suivantes s'appliquent lorsque vous utilisez CMEK avec Memorystore for Valkey :

  • Vous ne pouvez pas activer CMEK sur une instance Memorystore pour Valkey existante.
  • La clé, le trousseau de clés et l'instance doivent se trouver dans la même région.
  • Vous devez utiliser l'algorithme de chiffrement symétrique pour votre clé.
  • Les taux de chiffrement et de déchiffrement de Cloud KMS sont soumis à un quota.

Étapes suivantes