À 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 clusters dans Memorystore for Redis Cluster. Le document décrit également les données chiffrées dans le stockage persistant et le comportement de vos clusters 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 les nouveaux clusters. Vous ne pouvez pas appliquer CMEK aux clusters existants.

À 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 CMEK vous permettent d'utiliser vos clés cryptographiques pour protéger les données stockées dans les clusters. Pour chiffrer ces données, Memorystore pour Redis Cluster utilise des clés de chiffrement des données (DEK) gérées par Google et des clés de chiffrement de clé (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 for Redis Cluster.
  • Chiffrement KEK : les KEK chiffrent les DEK.

Memorystore pour Redis Cluster 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 de votre cluster.

Le schéma suivant montre comment un cluster 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 Redis Cluster déchiffre les données chiffrées avec CMEK. Pour accéder à ces données chiffrées, Memorystore for Redis Cluster envoie une requête à Cloud KMS, qui gère la KEK, afin de déchiffrer la DEK. Cloud KMS renvoie ensuite la DEK déchiffrée, que le cluster 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 for Redis Cluster est compatible avec deux types de persistance :
    • Persistance RDB : la fonctionnalité de base de données Redis (RDB) protège vos données en enregistrant des instantanés de vos données dans un espace de stockage durable.
    • Persistance AOF : cette fonctionnalité privilégie la durabilité des données. Il stocke les données de manière durable en enregistrant chaque commande d'écriture dans un fichier journal appelé fichier en mode Ajout uniquement (AOF). 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 clusters à 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 un cluster compatible avec CMEK, vous devez attribuer le rôle roles/cloudkms.cryptoKeyEncrypterDecrypter au compte de service Memorystore pour Redis Cluster qui utilise le format suivant :

service-PROJECT_NUMBER@cloud-redis.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 un cluster, vous sélectionnez cette clé pour le chiffrer. Vous pouvez créer un projet pour vos clés et vos clusters, ou des projets différents pour chacun d'eux.

Le chiffrement CMEK est disponible dans tous les emplacements de cluster. 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 le cluster. Pour un cluster multirégional, vous devez définir le trousseau de clés et la clé sur le même emplacement que le cluster. Si les régions ou les emplacements ne correspondent pas, une requête de création du cluster é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 cluster, Memorystore for Redis Cluster ne le crée pas. De plus, si la clé externe devient indisponible à un moment donné après la création du cluster, Memorystore for Redis Cluster 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 clusters 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 des 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 principale de votre clé, les restrictions suivantes s'appliquent aux sauvegardes de votre cluster :

  • 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 cluster :

  • Si vous configurez votre cluster pour qu'il utilise la persistance, Memorystore pour Redis Cluster la désactive lorsque la version de clé devient indisponible. L'utilisation de la persistance ne vous est plus facturée.
  • Memorystore pour Redis Cluster n'enregistre pas les nouvelles données dans un stockage persistant à l'aide de CMEK.
  • Memorystore for Redis Cluster 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 Redis Cluster 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 la désactivant ou en supprimant les autorisations IAM pour cette clé, Memorystore for Redis Cluster privilégie 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 Redis Cluster arrête 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 for Redis Cluster 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 un cluster à 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 le cluster à utiliser une nouvelle clé Cloud KMS, vous pouvez exécuter une maintenance simulée sur le cluster. Une fois cette opération terminée, Memorystore pour Redis Cluster peut écrire des données de persistance à l'aide de la version principale mise à jour de la clé.

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 Redis Cluster 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 la prochaine fois que le cluster redémarre ou qu'un événement de maintenance se produit.
  • 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 pour Redis Cluster 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 for Redis Cluster est compatible avec les contraintes de règles d'administration pour les clés CMEK. En utilisant ces contraintes, vous pouvez appliquer la protection CMEK à vos clusters 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 clusters. Si l'API Memorystore pour Redis Cluster figure dans la liste des services Deny de cette contrainte, vous ne pouvez pas créer de clusters non protégés 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 clusters qui utilisent le chiffrement CMEK doivent utiliser une clé provenant d'un projet, d'un dossier ou d'une organisation autorisés.

Comme Memorystore for Redis Cluster et Memorystore pour Redis partagent le même point de terminaison (redis.googleapis.com), vous ne pouvez pas appliquer CMEK aux clusters indépendamment des instances Memorystore pour Redis.

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

Tarifs

Memorystore for Redis Cluster facture un cluster CMEK comme n'importe quel autre cluster. Il n'y a pas de frais supplémentaires. Pour en savoir plus, consultez la page Tarifs de Memorystore pour Redis Cluster.

Vous utilisez l'API Cloud KMS pour gérer les CMEK. Lorsque vous créez un cluster avec des CMEK, Memorystore utilise la clé périodiquement 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 Redis Cluster 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 Redis Cluster :

  • Vous ne pouvez pas activer CMEK sur un cluster existant.
  • La clé, le trousseau de clés et le cluster 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