Clés de chiffrement gérées par le client (CMEK)

Dans Bigtable, toutes les données au repos sont chiffrées par défaut Chiffrement par défaut de Google Bigtable effectue et gère ce chiffrement sans aucune intervention de votre part.

Si vous avez des exigences réglementaires ou de conformité spécifiques concernant les clés qui protègent vos données, vous pouvez utiliser des clés de chiffrement gérées par le client (CMEK) pour Bigtable. Au lieu de laisser Google gérer les clés de chiffrement qui protègent vos données, votre instance Bigtable est protégée à l'aide d'une clé que vous contrôlez et gérez dans le service Cloud Key Management Service (Cloud KMS).

Cette page décrit le chiffrement CMEK pour Bigtable. Pour plus d'informations sur CMEK en général, y compris quand et pourquoi l'activer, consultez la documentation Cloud KMS. Pour obtenir des instructions sur l'exécution de tâches liées à CMEK avec Bigtable, consultez la section Utiliser CMEK.

Fonctionnalités

  • Sécurité : CMEK fournit le même niveau de sécurité que le chiffrement par défaut de Google, mais offre davantage de contrôle administratif.

  • Contrôle de l'accès aux données : les administrateurs peuvent alterner la clé utilisée pour protéger les données au repos dans Bigtable, en gérer l'accès, et la désactiver ou la détruire.

  • Possibilité de réaliser des audits : toutes les actions effectuées sur vos clés CMEK sont consignées et visibles dans Cloud Logging. Les clés Cloud EKM sont compatibles avec Key Access Justifications, qui ajoute un champ de justification à toutes les requêtes de clé. Avec certains partenaires de gestion de clés externes, vous pouvez approuver ou refuser automatiquement ces demandes, en fonction de leur justification.

  • Performances comparables : les instances Bigtable protégées par la fonctionnalité CMEK offrent des performances comparables à celles des instances Bigtable qui utilisent le chiffrement par défaut de Google.

  • Flexibilité : vous pouvez utiliser la même clé CMEK dans plusieurs projets, instances ou clusters, ou vous pouvez utiliser des clés distinctes, suivant les besoins de votre entreprise.

  • Protection interrégionale : vous pouvez activer les CMEK pour toutes les instances bénéficiant de clusters dans n'importe quelle région où Bigtable est disponible. Chaque cluster est protégé par une clé CMEK située dans la région correspondante à ce cluster.

Tarifs

Cloud KMS facture le coût de la clé ainsi que toutes les opérations cryptographiques effectuées avec cette clé. Pour en savoir plus, consultez la section Tarifs Cloud KMS.

Le coût des opérations vous est facturé lorsque Bigtable demande à la clé Cloud KMS d'effectuer une opération de chiffrement ou de déchiffrement. Chaque demande de chiffrement ou de déchiffrement est envoyée depuis chaque table sur chaque cluster de l'instance. Comme Bigtable utilise le chiffrement encapsulé, ces coûts par table sont généralement faibles, compte tenu du faible nombre d'opérations cryptographiques attendu. Si vous stockez de nombreuses tables dans une instance protégée par une clé CMEK, vos coûts sont plus élevés.

L'utilisation d'instances activées avec CMEK ne génère aucun coût Bigtable supplémentaire.

Éléments protégés par CMEK

Dans une instance protégée par CMEK, Bigtable utilise votre clé CMEK pour protéger vos données au repos. Cela inclut les données de toutes les tables du cluster. Cette protection couvre les données stockées à la fois sur le stockage HD et SSD.

Certaines données sont protégées par le chiffrement par défaut de Google au repos et non par la clé CMEK :

  • Un sous-ensemble de clés de ligne qui marquent les limites de plages et qui sont utilisées pour le routage
  • Les données de débogage, y compris les vidages de mémoire et les journaux opérationnels
  • Les données en transit ou en mémoire
  • Un sous-ensemble de valeurs d'horodatage utilisées pour la récupération de mémoire

Bigtable utilise le chiffrement encapsulé pour les données au repos. La clé CMEK est utilisée en tant que clé de chiffrement de clé (clé KEK) pour chiffrer les autres clés utilisées par Bigtable. Lorsque vous effectuez une rotation de la clé CMEK, Bigtable n'a besoin de rechiffrer que les clés intermédiaires.

Activer CMEK

De manière générale, pour utiliser la fonctionnalité CMEK avec Bigtable, procédez comme suit :

  1. Créez et configurez une clé CMEK dans chaque région où des clusters de votre instance seront situés.
  2. Créez une instance Bigtable en sélectionnant une clé CMEK pour chaque cluster de l'instance. La clé CMEK d'un cluster doit se trouver dans la même région que le cluster.
  3. Planifiez une rotation des clés pour chaque clé.

Les applications qui utilisent Bigtable n'ont pas besoin de spécifier de configuration de clé ou de chiffrement lors de la lecture, de l'écriture ou de la suppression de données. Bigtable peut accéder à la clé en votre nom lorsque vous accordez le rôle Chiffreur/Déchiffreur Cloud KMS à la Agent de service Bigtable.

Pour obtenir des instructions détaillées, consultez la page Utiliser des clés de chiffrement gérées par le client (CMEK).

Vous pouvez utiliser les outils suivants lorsque vous travaillez avec CMEK pour Bigtable.

Vous pouvez également accéder directement à l'API Cloud Bigtable Admin, mais nous vous recommandons Nous vous recommandons de le faire uniquement si vous ne pouvez pas utiliser de client Bigtable qui effectue des appels CMEK à l'API.

Gestion des clés

Les opérations de gestion des clés sont effectuées à l'aide de Cloud KMS. Bigtable ne peut ni détecter, ni exploiter les modifications d'une clé avant que celles-ci ne soient propagées par Cloud KMS. La propagation de certaines opérations, telles que la désactivation ou la destruction d'une clé, peut prendre jusqu'à quatre heures. Les modifications apportées aux autorisations d'une clé se propagent généralement plus rapidement.

Dès qu'une première table est créée dans une instance protégée par une clé CMEK, Bigtable valide la clé pour chaque table de chaque cluster toutes les cinq minutes.

Si Bigtable détecte une clé désactivée, il désactive un cluster à la fois en cascade jusqu'à ce que tous les clusters de l'instance soient désactivés. Entre le moment où le premier cluster signale que la clé a été désactivée ou détruite et la désactivation effective de l'instance, certaines requêtes de données peuvent aboutir alors que d'autres renvoient une erreur. Toutes les opérations de données envoyées à un cluster désactivé renvoient une erreur FAILED_PRECONDITION ou NOT_FOUND.

De plus, étant donné que la réplication Bigtable est cohérente à terme, il est possible qu'un cluster ait confirmé une requête d'écriture, mais qu'il ne l'ait pas encore répliquée sur les autres clusters de l'instance avant sa désactivation.

Le processus Bigtable de désactivation automatique de tous les clusters d'une instance après la désactivation d'une clé peut prendre plusieurs heures. Pour éviter cet état, nous vous recommandons de toujours désactiver toutes les clés d'une instance simultanément.

Lorsqu'un cluster Bigtable est désactivé, les opérations d'administration suivantes sont limitées pour l'ensemble de l'instance :

  • Créer un cluster
  • Supprimer un cluster
  • Créer une table
  • Modifier une famille de colonnes
  • Restaurer une table

Vous pouvez toujours supprimer l'instance, supprimer une table et supprimer une sauvegarde.

Si les appels de Bigtable à Cloud KMS détectent qu'une clé précédemment désactivée a été réactivée, Cloud KMS restaure automatiquement l'accès au cluster Bigtable.

Si une clé Cloud KMS a été détruite, toute instance Bigtable dont le cluster a été chiffré avec cette clé devient définitivement inaccessible.

Traitement de l'état d'indisponibilité d'une clé

Dans de rares cas, par exemple pendant les périodes d'indisponibilité de Cloud KMS, Bigtable peut ne pas être en mesure de récupérer l'état d'une clé à partir de Cloud KMS.

Si un cluster Bigtable est protégé par une clé activée au moment où Bigtable perd initialement la capacité à communiquer avec Cloud KMS, Bigtable continue à accepter les opérations d'instance complètes de la manière la plus optimale possible à l'aide des clés mises en cache dérivées de la clé Cloud KMS pendant une heure au maximum. Cela permet de minimiser l'impact des incidents de ce type sur votre charge de travail.

Au bout d'une heure, si Bigtable ne parvient toujours pas à se connecter à Cloud KMS, il commence à mettre l'instance hors connexion par mesure de protection. Les données de votre instance Bigtable restent inaccessibles jusqu'à ce que l'instance puisse se reconnecter à Cloud KMS et que Cloud KMS réponde que la clé est bien active.

À l'inverse, si un cluster de votre instance Bigtable est protégé par une clé désactivée au moment où Bigtable perd initialement la capacité à communiquer avec Cloud KMS, votre instance reste inaccessible jusqu'à ce qu'elle puisse se reconnecter à Cloud KMS et que vous ayez réactivé votre clé.

Remarques importantes concernant les clés externes

Lorsque vous utilisez une clé Cloud EKM, Google n'a aucun contrôle sur la disponibilité de votre clé gérée en externe dans le système partenaire de gestion des clés externes.

Si la clé gérée en externe n'est pas disponible, Bigtable continue de prendre en charge les opérations de cluster en utilisant une version de clé mise en cache, pendant une heure au maximum.

Au bout d'une heure, si Bigtable ne parvient toujours pas à se connecter à Cloud KMS, il commence à mettre l'instance hors connexion par mesure de protection. Les données de votre instance Bigtable restent inaccessibles jusqu'à ce que l'instance puisse se reconnecter à Cloud KMS et que Cloud KMS réponde en signalant que la clé externe est bien active.

Si vous envisagez d'utiliser une clé externe pour une instance Bigtable comportant des clusters dans plusieurs régions, assurez-vous que votre clé est acceptée dans ces régions. Pour plus d'informations, consultez la section Gestionnaires de clés externes et régions. En outre, vous ne devez pas utiliser une combinaison de clés externes et non externes dans la même instance.

Pour en savoir plus sur l'utilisation de clés externes avec Cloud Key Management Service, consultez la page Cloud External Key Manager (Cloud EKM).

Règles d'administration

Bigtable est compatible avec les contraintes de règles d'administration pour garantir l'utilisation des CMEK dans toute l'organisation. Pour en savoir plus sur l'utilisation des règles d'administration, consultez la section Règles d'administration CMEK.

Sauvegardes

Comme toutes les autres données, une sauvegarde est protégée par la clé CMEK du cluster sur lequel elle est stockée. Les nouvelles tables restaurées à partir d'une sauvegarde sont protégées par la ou les clés CMEK du cluster où elles sont restaurées. Pour en savoir plus sur l'impact des CMEK sur les opérations de sauvegarde et de restauration, consultez la page Sauvegardes. Pour savoir comment créer ou restaurer des sauvegardes, consultez la section Gérer les sauvegardes.

Logging

Vous pouvez auditer les demandes envoyées par Bigtable en votre nom à Cloud KMS dans Cloud Logging, si vous avez activé les journaux d'audit Cloud KMS pour l'API Cloud KMS dans votre projet. Vous pouvez vous attendre à quelques entrées de journal toutes les cinq minutes environ par table dans chaque cluster.

Limites

  • Le chiffrement CMEK ne peut être configuré qu'au niveau du cluster. Vous ne pouvez pas configurer CMEK sur les sauvegardes, les tables ou les profils d'application.

  • La clé CMEK d'un cluster doit se trouver dans la même région que le cluster. Lorsque vous créez un trousseau de clés Cloud KMS, veillez à sélectionner la région correspondant à la configuration zonale que vous prévoyez d'utiliser pour Bigtable.

  • La configuration de chiffrement d'une ressource Bigtable (instance, cluster, table ou sauvegarde) est immuable.

    • Les instances non CMEK ne peuvent pas être converties en vue d'une utilisation avec CMEK.
    • Les instances CMEK ne peuvent pas être converties en vue d'une utilisation avec le chiffrement Google par défaut.
    • Les clusters créés avec une clé CMEK ne peuvent pas être reconfigurées pour utiliser une autre clé.

  • Les ressources Bigtable protégées par une clé CMEK (instances, clusters, tables ou sauvegardes) liées à une clé rendue inaccessible suite à une action déclenchée par l'utilisateur (par exemple, la désactivation ou la destruction d'une clé, ou la révocation du rôle Chiffreur/Déchiffreur) pendant plus de 30 jours consécutifs sont automatiquement supprimées.

  • Si vous réactivez une clé CMEK désactivée afin de restaurer l'accès aux instances Bigtable protégées par cette clé, certaines requêtes de l'API Data peuvent expirer pendant la remise en ligne de vos données.

  • Pendant cinq minutes au plus après la création d'une table dans une instance protégée par une clé CMEK, la version de clé et l'état de clé peuvent être signalés comme inconnus. Cependant, pendant cette période, toutes les données écrites dans la table sont toujours protégées par la clé CMEK.

  • La désactivation ou la suppression d'une seule version au lieu de la totalité des versions d'une clé utilisée par Bigtable peut entraîner un comportement imprévisible. Vous devez toujours désactiver ou supprimer toutes les versions d'une clé CMEK.

Étape suivante