À 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 pour 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 des CMEK pour chiffrer ces données, consultez Déterminer si vous devez utiliser des CMEK.

Chiffrement géré par le client

Le chiffrement CMEK vous permet 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'entre eux est chiffré avec sa propre clé DEK. Cloud KMS fournit la clé KEK pour chiffrer les clés DEK, et l'infrastructure de stockage de Google distribue à la fois les blocs de données chiffrés et les clés 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 extraite de 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 pour Redis Cluster envoie une requête à Cloud KMS, qui gère la clé KEK, afin de déchiffrer la clé 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 CMEK ?

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

  • Sauvegardes : les sauvegardes vous permettent de récupérer vos données à un moment précis, mais aussi de les exporter et de les analyser. Les sauvegardes sont également utiles pour la reprise après sinistre, la migration de données, le partage de données et les scénarios 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 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é telles que 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, 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 unique pour vos clés et vos clusters, ou un projet distinct pour chacun d'eux.

CMEK est disponible dans tous les emplacements de cluster. Vous devez créer le trousseau 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 aucune clé n'est 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 plus d'informations sur l'utilisation des clés externes, consultez la section Points à prendre en compte.

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. Chaque fois que vous effectuez une rotation de 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é. 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 des données chiffrées avec CMEK définitivement inaccessibles, par exemple lorsque vous corrigez une fuite de données. Pour détruire les données de manière hautement sécurisée (également appelée déchiquetage cryptographique), vous devez détruire la version de la clé. Pour en savoir plus sur la destruction des versions de clé, 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 ancienne version de clé, 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 principale de votre clé, 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 la 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 le stockage persistant à l'aide de la clé CMEK.
  • Memorystore pour 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 de clé principale, 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 version de clé plus ancienne qui est 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 de clé principale.

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 associées, 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 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 en mémoire.

Rotation de la version principale de la clé CMEK

Si vous effectuez une rotation de 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 de clé primaire de votre CMEK chiffre les nouvelles sauvegardes.
  • Les sauvegardes existantes ne sont pas rechiffrées.
  • Pour la persistance, les nœuds n'effectuent aucune action. Les nœuds continuent d'utiliser l'ancienne version de clé jusqu'au prochain événement de maintenance.

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

Memorystore pour Redis Cluster n'est pas compatible avec le rechiffrement à la demande des données stockées. Vous ne pouvez pas déclencher manuellement un processus pour utiliser une nouvelle version de clé afin de réencrypter 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 une rotation de 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 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 Redis Cluster n'applique cette modification qu'aux opérations futures.

Le remplacement d'une clé protégée a les effets suivants 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 du cluster 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 principale de la clé CMEK

Si vous activez ou restaurez votre version de clé principale, 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 pour Redis Cluster est compatible avec les contraintes de règles d'administration pour les 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.

Étant donné que Memorystore pour 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 Memorystore pour Redis Cluster, consultez Contraintes liées aux règles d'administration.

Tarifs

Memorystore pour Redis Cluster facture un cluster compatible 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 CMEK. Lorsque vous créez un cluster avec 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 des clés CMEK avec Memorystore pour 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