Cette page a été traduite par l'API Cloud Translation.
Switch to English

Présentation détaillée de Cloud Key Management Service

Auteurs : Sonal Shah, Il-Sung Lee, Walter Poupore, Hunter Freyer, Honna Segel, Dwight Worley

Remerciements : Adrian Sears, John Randolph, Tim Dierks, Chris Rezek, Stanley McKenzie, Kevin Plybon, David Hale, Sergey Simakov, David U. Lee, Carrie McDaniel, Anton Chuvakin, Dave Tonisson

Dernière mise à jour : avril 2020

1. Introduction

Google Cloud part du principe fondamental que les clients Google Cloud sont propriétaires de leurs données et doivent contrôler leur utilisation.

Lorsque vous stockez des données avec Google Cloud, celles-ci sont par défaut chiffrées au repos. Lorsque vous utilisez notre plate-forme Cloud Key Management Service (Cloud KMS), vous pouvez mieux contrôler le chiffrement de vos données au repos et la gestion de vos clés de chiffrement.

La plate-forme Cloud KMS permet aux clients Google Cloud de gérer des clés cryptographiques dans un service cloud central pour une utilisation directe ou une utilisation par d'autres ressources et applications cloud. Pour la source des clés, Cloud KMS fournit les options suivantes :

  • Le backend du logiciel Cloud KMS vous permet de chiffrer librement vos données à l'aide d'une clé symétrique ou asymétrique que vous contrôlez (Cloud KMS).
  • Si vous avez besoin d'une clé matérielle, vous pouvez faire appel à Cloud HSM pour vous assurer que vos clés symétriques et asymétriques ne sont utilisées que dans les modules de sécurité matériels (HSM, Hardware Security Module) certifiés FIPS 140-2 de niveau 3.
  • Cloud KMS vous permet d'importer vos propres clés cryptographiques si vous devez utiliser des clés que vous générez vous-même.
  • Vous pouvez choisir d'utiliser des clés générées par Cloud KMS avec d'autres services Google Cloud. Ces clés sont appelées clés de chiffrement gérées par le client (CMEK, Customer-Managed Encryption Key). La fonctionnalité CMEK vous permet de générer, d'utiliser, d'alterner et de détruire des clés de chiffrement servant à protéger les données d'autres services Google Cloud.
  • À l'aide de Cloud External Key Manager (Cloud EKM), vous pouvez créer et gérer des clés dans un gestionnaire de clés externe à Google Cloud, puis configurer la plate-forme Cloud KMS pour utiliser les clés externes permettant de protéger vos données au repos. Vous pouvez utiliser des clés de chiffrement gérées par le client avec une clé Cloud EKM. Cloud EKM dépasse actuellement le cadre de ce livre blanc.

Google accepte également les clés de chiffrement fournies par le client (CSEK, Customer-Supplied Encryption Key) pour Compute Engine et Cloud Storage. Les données sont déchiffrées et chiffrées à l'aide d'une clé fournie dans l'appel d'API. La fonctionnalité CSEK dépasse le cadre de cet article. Pour en savoir plus, consultez la documentation en ligne.

"Schéma du portefeuille KMS"

Avec Cloud KMS, Google a pour objectif de fournir une solution évolutive, fiable et performante, dotée de nombreuses options que vous pouvez contrôler sur une plate-forme simple à utiliser. La conception de Cloud KMS repose sur cinq piliers :

  • Contrôle client : Cloud KMS vous permet de gérer les clés de chiffrement logicielles et matérielles, ou de fournir vos propres clés.
  • Contrôle des accès et surveillance : à l'aide de Cloud KMS, vous pouvez gérer les autorisations sur des clés individuelles et surveiller l'utilisation de ces dernières.
  • Régionalité : Cloud KMS offre une régionalisation prête à l'emploi. Le service est configuré pour créer, stocker et traiter des clés logicielles uniquement dans la région Google Cloud que vous sélectionnez.
  • Durabilité : Cloud KMS répond aux normes de durabilité les plus strictes de Google Cloud. Pour éviter toute corruption des données et vérifier qu'elles peuvent être déchiffrées, Cloud KMS analyse et sauvegarde régulièrement l'intégralité du matériel et des métadonnées de clés.
  • Sécurité : Cloud KMS offre une protection renforcée contre les accès non autorisés aux clés et est entièrement intégré aux contrôles Identity and Access Management (IAM) et Cloud Audit Logging.

Cet article explique les rouages internes de la plate-forme Cloud KMS tels qu'ils apparaissent dans la version de disponibilité générale (DG). Ces options vous aident à protéger les clés et autres données sensibles que vous stockez dans Google Cloud. Cet article s'adresse aux responsables techniques qui ont besoin d'informations détaillées sur l'architecture, l'infrastructure et les fonctionnalités de Cloud KMS. Dans cet article, nous partons du principe que vous avez déjà acquis les connaissances de base sur les concepts de chiffrement et les architectures cloud.

2. Concepts de chiffrement et gestion des clés Google

Cette section explique certains termes et définitions en lien avec la gestion des clés, dans le contexte de l'infrastructure multicouche de gestion des clés de Google.

2.1. Clés, versions de clés et trousseaux de clés

Cette section décrit les clés, les versions de clés et le regroupement de clés en trousseaux. Le schéma suivant illustre les regroupements de clés. Les définitions associées se trouvent à la suite du schéma.

"Schéma des regroupements de clés".

  • Clé : objet nommé représentant une clé cryptographique utilisée dans un but spécifique. Le matériel de clé (les bits utilisés pour les opérations de chiffrement) peut changer au fil du temps à mesure que vous créez des versions de clé.

    L'objectif de clé et les autres attributs de la clé sont connectés et gérés à l'aide de la clé. Ainsi, la clé est l'objet le plus important pour comprendre l'utilisation de KMS.

    Cloud KMS est compatible avec les clés asymétriques et les clés symétriques. Une clé symétrique est utilisée pour le chiffrement symétrique afin de protéger certains corpus de données, par exemple à l'aide de l'algorithme AES-256 en mode GCM pour chiffrer un bloc de texte brut. Une clé asymétrique peut être utilisée pour le chiffrement asymétrique ou pour créer des signatures numériques. Les objectifs et algorithmes acceptés sont décrits dans la documentation Cloud KMS.

  • Trousseau de clés : regroupement de clés à des fins d'organisation. Un trousseau de clés appartient à un projet Google Cloud et se trouve dans un emplacement spécifique. Les clés héritent des stratégies IAM du trousseau de clés qui les contient. Le regroupement de clés avec des autorisations associées dans un trousseau vous permet d'accorder, de révoquer ou de modifier des autorisations sur ces clés au niveau du trousseau, sans avoir besoin de traiter chaque clé individuellement. Les trousseaux offrent une certaine commodité et permettent une classification, mais si le regroupement de clés en trousseaux ne vous est pas utile, vous pouvez gérer les autorisations directement sur les clés.

    Pour éviter des conflits au niveau des noms de ressources, il est impossible de supprimer un trousseau de clés. Les trousseaux de clés et les clés n'engendrent aucun coût facturable et ne sont soumis à aucune limite de quota. Par conséquent, leur existence prolongée n'a aucune incidence sur les coûts ni sur les limites de production. Pour en savoir plus sur la suppression de clés et du matériel de clé, consultez la section sur la suppression plus loin dans cet article.

  • Métadonnées de clés : noms de ressources, propriétés des ressources KMS telles que les stratégies IAM, le type de clé, la taille de la clé, l'état de la clé et toutes les données dérivées des informations précédentes. Les métadonnées de clés peuvent être gérées différemment du matériel de clé.

  • Version de clé : correspond au matériel associé à une clé à un moment donné. La version de clé correspond à la ressource qui contient le matériel réel de la clé. Les versions sont numérotées dans l'ordre en commençant par "1". La rotation crée une autre version de la clé avec un autre matériel de clé. La même clé logique peut avoir plusieurs versions au fil du temps, ce qui limite l'utilisation d'une seule version. Les clés symétriques possèdent toujours une version principale. Cette version est utilisée par défaut pour le chiffrement. Lorsque Cloud KMS effectue un déchiffrement à l'aide de clés symétriques, il identifie automatiquement la version de clé nécessaire pour réaliser le déchiffrement.

2.2. Hiérarchie des clés

Le schéma suivant illustre la hiérarchie des clés du service interne de gestion des clés de Google. Cloud KMS exploite le KMS interne de Google dans la mesure où les clés chiffrées par Cloud KMS sont aussi encapsulées par Google KMS. Cloud KMS utilise la même racine de confiance que Google KMS. Les définitions associées se trouvent à la suite du schéma.

"Schéma de la hiérarchie interne des clés"

  • Clé de chiffrement des données (DEK, Data Encryption Key) : clé permettant de chiffrer des données.
  • Clé de chiffrement de clé (KEK, Key Encryption Key) : clé servant à chiffrer ou encapsuler une clé de chiffrement des données. Toutes les options de la plate-forme Cloud KMS (logiciels, matériel et backends externes) vous permettent de contrôler la clé de chiffrement de clé.
  • Clé principale KMS : clé utilisée pour chiffrer les clés KEK. Cette clé est distribuée en mémoire. La clé principale KMS est sauvegardée sur des périphériques matériels. Elle est responsable du chiffrement de vos clés.
  • Root KMS : service interne de gestion des clés de Google.

2.3. Opérations

  • Projet : les ressources Cloud KMS appartiennent à un projet Google Cloud, comme toutes les autres ressources Google Cloud. Vous pouvez héberger des données dans un projet différent de celui dans lequel se trouvent vos clés Cloud KMS. Cette fonctionnalité est compatible avec la bonne pratique de séparation des tâches entre les administrateurs de clés et les administrateurs de données.
  • Emplacement : dans un projet, les ressources Cloud KMS sont créées dans un emplacement. Pour plus d'informations, consultez la page Zones géographiques et régions.

3. Présentation de la plate-forme Cloud KMS

La plate-forme Cloud KMS accepte plusieurs algorithmes cryptographiques, et fournit des méthodes de chiffrement et de signature numérique à l'aide de clés matérielles et logicielles. La plate-forme Cloud KMS est intégrée à Identity and Access Management (IAM) et Cloud Audit Logging, ce qui vous permet de gérer les autorisations sur des clés individuelles et de surveiller leur utilisation.

"Schéma de l'architecture Cloud KMS"

Le schéma ci-dessus montre les principaux composants de la plate-forme Cloud KMS. Les administrateurs accèdent aux services de gestion des clés à l'aide de Google Cloud Console ou de l'outil de ligne de commande gcloud, ou via des applications mettant en œuvre les API REST ou gRPC. Les applications accèdent aux services de gestion des clés à l'aide d'une API REST ou gRPC. Les applications peuvent utiliser les services Google qui sont activés pour utiliser des clés de chiffrement gérées par le client (CMEK). La fonctionnalité CMEK utilise à son tour l'API Cloud KMS. L'API Cloud KMS vous permet d'utiliser des clés logicielles (Cloud KMS) ou matérielles (Cloud HSM). Les clés logicielles et matérielles tirent parti des protections de sauvegarde redondantes de Google.

Avec la plate-forme Cloud KMS, vous pouvez choisir un niveau de protection lors de la création d'une clé pour déterminer quel backend de clé crée cette clé et effectue toutes les opérations de chiffrement futures sur celle-ci. La plate-forme Cloud KMS fournit deux backends (à l'exception de Cloud EKM) qui sont exposés dans l'API Cloud KMS en tant que niveaux de protection SOFTWARE et HSM. Le niveau de protection SOFTWARE s'applique aux clés pouvant être désencapsulées par un module de sécurité logiciel qui effectue des opérations de chiffrement. Le niveau de protection HSM s'applique aux clés ne pouvant être désencapsulées que par les modules de sécurité matériels qui effectuent toutes les opérations de chiffrement avec celles-ci.

Google Cloud est compatible avec le chiffrement CMEK pour plusieurs services, y compris Cloud Storage, BigQuery et Compute Engine. La fonctionnalité CMEK vous permet d'utiliser la plate-forme Cloud KMS pour gérer les clés de chiffrement que ces services utilisent afin de protéger vos données.

Les opérations de chiffrement Cloud KMS sont effectuées par les modules certifiés FIPS 140-2. Les clés dotées du niveau de protection SOFTWARE et les opérations de chiffrement associées sont conformes au niveau 1 de la certification FIPS 140-2. Les clés dotées du niveau de protection HSM et les opérations de chiffrement associées sont conformes au niveau 3 de la certification FIPS 140-2.

3.1. Environnement et dépendances

Cette section fournit des détails concernant l'infrastructure Google sur laquelle la plate-forme Cloud KMS s'exécute et les protocoles de communication que l'infrastructure utilise.

3.1.1. Tâches Borg Cloud KMS

Les éléments de la plate-forme Cloud KMS sont exécutés en tant que tâches de production Borg. Borg est le gestionnaire de cluster à grande échelle de Google pour la gestion des tâches de diffusion de l'API et des tâches par lot. Pour en savoir plus sur la sécurité de notre infrastructure physique et de production, consultez le document Présentation de la sécurité sur l'infrastructure de Google.

3.1.1.1. Tâches de diffusion de l'API Cloud KMS

Les tâches de diffusion de l'API Cloud KMS sont des tâches de production Borg qui traitent les requêtes des clients pour gérer et utiliser leurs clés. Ces tâches de diffusion s'exécutent dans chaque région Google Cloud où Cloud KMS est disponible. Chaque tâche est associée à une seule région et est configurée pour accéder uniquement aux données des systèmes situés géographiquement dans la région Google Cloud associée. Pour en savoir plus sur la résidence des clés, consultez la section Régionalité plus loin dans cet article.

3.1.1.2. Tâches par lot Cloud KMS

La plate-forme Cloud KMS gère également un certain nombre de tâches par lot qui sont exécutées en tant que tâches de production Borg selon différents plannings. Les tâches par lot sont spécifiques à une région et ne regroupent que les données provenant de la région Google Cloud associée et s'exécutant dans celle-ci. Les tâches effectuées sont les suivantes :

  • Comptage des clés actives pour la facturation client.
  • Regroupement des ressources de l'API publique de tampon de protocole de Cloud KMS et transfert des métadonnées vers l'inventaire des éléments cloud. Dans ce contexte, les ressources correspondent à toute ressource gérée par Cloud KMS, par exemple les clés et les trousseaux de clés.
  • Regroupement de toutes les ressources et informations sur les rapports pour les analyses commerciales.
  • Création d'instantanés de données pour une haute disponibilité.
  • Vérification que toutes les données stockées dans le datastore sous-jacent ne sont pas corrompues.
  • Rechiffrement du matériel de clé client lors de la rotation de la clé principale KMS.
3.1.1.3. Créateur d'instantanés de clé Cloud KMS

Pour maintenir une haute disponibilité, la plate-forme Cloud KMS gère un datastore redondant dans chaque instance d'un service partagé hébergeant les tâches du serveur d'API Cloud KMS. Chaque service déploie sa propre instance du service de création d'instantanés. Cette redondance rend les services hautement indépendants, de sorte qu'une défaillance dans une zone a un effet limité sur les autres zones. Lorsque la tâche de l'API Cloud KMS doit effectuer une opération de chiffrement, elle interroge le datastore principal ainsi que les tâches locales de création d'instantanés en parallèle. L'API Cloud KMS utilise ensuite la tâche qui termine en premier la requête. Pour éviter tout retard dans le pipeline d'instantanés pouvant entraîner la diffusion de données trop obsolètes, le serveur d'API n'utilise pas les résultats des tâches de création d'instantanés si les données remontent à plus de deux heures. Les instantanés sont créés en tant que résultats d'une tâche par lot qui s'exécute en continu pour chaque région. Les instantanés se trouvent dans la région cloud associée au matériel de la clé.

3.1.2. Communications client-serveur

Google exploite le système Application Layer Transport Security (ALTS) pour assurer la sécurité des communications client-serveur (chiffrement en transit) utilisant le mécanisme d'appel de procédure à distance (RPC) de Google. ALTS fournit les éléments suivants :

  • Un protocole d'authentification peer-to-peer pour les applications
  • Un protocole de chiffrement des enregistrements
  • Une API qui expose l'utilisateur authentifié pour l'autorisation

Les protocoles de handshake et de chiffrement des enregistrements d'ALTS sont similaires aux protocoles de handshake et d'enregistrement de Transport Layer Security (TLS). Le système ALTS fait différents compromis pour optimiser l'environnement de production de Google, et est entièrement intégré à l'ensemble de la pile matérielle et logicielle de production. Pour en savoir plus, consultez la section Environnement opérationnel de la plate-forme Cloud KMS plus loin dans cet article.

4. Détails d'architecture de la plate-forme Cloud KMS

Cette section aborde les détails d'architecture, en commençant par la sécurité du matériel de clé et la protection du datastore. Elle détaille ensuite les options pour la source du matériel de clé :

Cette section décrit également les options pour les clés de chiffrement gérées par le client (CMEK).

Pour obtenir une vue dynamique de l'utilisation des structures architecturales présentées jusqu'ici, lisez les sections décrivant le cycle de vie d'une requête Cloud KMS et expliquant la destruction du matériel de clé.

4.1. Sécurité du matériel de clé

Dans Cloud KMS, le matériel de clé est toujours chiffré au repos et en transit. Le matériel de clé n'est déchiffré que dans les cas suivants :

  • Lorsque le client l'utilise.
  • Lorsque la clé interne de Google servant à protéger le matériel de clé client subit une rotation ou une vérification d'intégrité.

Les requêtes client adressées à Cloud KMS sont chiffrées en transit à l'aide de TLS entre le client et Google Front End (GFE). Le système Application Layer Transport Security (ALTS), décrit précédemment dans la section sur les communications client-serveur, est utilisé pour le chiffrement entre les tâches Cloud KMS et les backends dans différents centres de données. ALTS et le chiffrement en transit sont décrits plus en détail dans la section Cycle de vie d'une requête Cloud KMS plus loin dans cet article.

L'authentification se produit entre toutes les tâches KMS, à l'intérieur et entre les centres de données Google.

La stratégie de Google consiste à s'assurer que les tâches n'utilisent que le code source qui a été compilé, testé et examiné de manière vérifiable. L'autorisation binaire pour Borg (BAB, Binary Authorization for Borg) applique cette stratégie au niveau opérationnel et est décrite plus en détail dans cette documentation sur la sécurité.

Les tâches de l'API Cloud KMS peuvent accéder aux métadonnées de clés (par exemple, la stratégie IAM ou la période de rotation). Un employé de Google pouvant justifier d'une raison professionnelle valide et documentée (telle qu'un bug ou un problème client) peut également accéder aux métadonnées de clés. Les accès sont consignés en interne et les journaux relatifs aux données soumises à Access Transparency sont également disponibles pour les clients éligibles.

Cependant, le matériel de clé n'est pas accessible par les tâches de l'API Cloud KMS, et il n'est pas possible de l'exporter ni de l'afficher via l'interface API ou une autre interface utilisateur. Aucun employé de Google n'a accès au matériel de clé client non chiffré. Le matériel de clé est également chiffré à l'aide d'une clé principale dans Root KMS, qui n'est pas accessible directement par quiconque.

4.2. Protection du datastore

Cette section décrit comment les données de clé sont protégées par Google KMS.

4.2.1. Clés principales

Cloud KMS utilise une clé principale pour encapsuler toutes les clés client au repos. Chaque serveur Cloud KMS récupère au démarrage une copie de la clé principale en tant que dépendance forte et extrait une nouvelle copie de celle-ci chaque jour. La clé principale est rechiffrée régulièrement.

4.2.2. Règles de rotation

La rotation des clés fait partie des bonnes pratiques généralement acceptées pour la gestion du matériel de clé. Une règle de rotation existe pour les clés servant à protéger les datastores Cloud KMS. Une règle de rotation des clés est également appliquée aux clés principales KMS internes de Google qui encapsulent les clés Cloud KMS. Le texte chiffré de la clé principale KMS est planifié pour une durée de 90 jours maximum avec une clé client mise en cache au maximum pendant une journée. Cloud KMS actualise les clés principales dans les tâches KMS toutes les 24 heures et rechiffre toutes les clés client chaque mois.

4.2.3. Résidence des données

Les données sous-jacentes à chaque datastore Cloud KMS demeurent exclusivement dans la région Google Cloud à laquelle elles sont associées. Cela s'applique également aux zones multirégionales, par exemple la zone multirégionale us. Pour en savoir plus sur la résidence des données, consultez la section Régionalité plus loin dans cet article.

4.3. Disponibilité de la clé après sa création

Cloud KMS permet d'utiliser une clé immédiatement après la validation de la transaction ayant créé la clé par le datastore Cloud KMS et la confirmation de sa création par la couche de stockage.

4.4. Backend du logiciel Cloud KMS : niveau de protection SOFTWARE

Le niveau de protection SOFTWARE s'applique aux clés dont les opérations de chiffrement sont effectuées dans un logiciel. Cette section décrit en détail comment ce niveau de protection est mis en œuvre.

4.4.1. Mises en œuvre algorithmiques

Pour les clés logicielles, Cloud KMS utilise le module BoringCrypto (BCM) au sein de la mise en œuvre BoringSSL de Google pour toutes les tâches de chiffrement associées. Le module BCM est certifié FIPS 140-2. Le binaire Cloud KMS est basé sur les primitives cryptographiques de ce module, certifiées FIPS 140-2 de niveau 1. Les algorithmes les plus récents couverts par ce module sont répertoriés dans notre page de documentation, et comprennent les opérations de chiffrement, de déchiffrement et de signature avec les clés cryptographiques symétriques AES256-GSM et les clés cryptographiques asymétriques RSA 2048, RSA 3072, RSA 4096, EC P256 et EC P384.

4.4.2. Génération de nombres aléatoires et entropie

Lors de la génération de clés de chiffrement, Cloud KMS utilise BoringSSL. La certification FIPS 140-2 nécessite l'utilisation de ses propres générateurs de nombres pseudo-aléatoires (PRNG, PseudoRandom Number Generator), également appelés DRBG. Dans BoringCrypto, Cloud KMS utilise exclusivement le mécanisme CTR-DRBG avec AES-256. Cela fournit un résultat pour RAND_bytes, l'interface principale par laquelle le reste du système obtient des données aléatoires. Ce PRNG puise dans le générateur de nombres aléatoires (GNA) du noyau Linux, qui lui-même puise dans plusieurs sources d'entropie indépendantes. Cela inclut les événements entropiques de l'environnement de centre de données, tels que les mesures ultraprécises des accès disques et les temps d'arrivée entre les paquets, ainsi que les instructions RDRAND d'Intel, lorsqu'elles sont disponibles. Pour en savoir plus sur le comportement du générateur de nombres aléatoires pour BoringSSL (mode conforme à la norme FIPS), reportez-vous à la conception de GNA.

4.5. Backend HSM Cloud KMS : niveau de protection HARDWARE

Le service Cloud HSM fournit des clés avec support matériel à Cloud KMS. Il offre aux clients la possibilité de gérer et d'utiliser des clés cryptographiques protégées par des modules de sécurité matériels (HSM) entièrement gérés dans les centres de données Google. Le service est hautement disponible et réalise un autoscaling horizontal. Les clés sont liées de manière cryptographique à la région KMS dans laquelle le trousseau a été défini. Avec Cloud HSM, les clés que vous créez et utilisez ne peuvent pas être matérialisées en dehors du cluster de HSM appartenant à la région spécifiée au moment de la création des clés. Grâce à Cloud HSM, vous pouvez attester de manière vérifiable que vos clés cryptographiques ont été créées et utilisées exclusivement dans un dispositif matériel. Aucune modification d'application n'est requise pour les clients Cloud KMS existants qui souhaitent utiliser Cloud HSM : les services Cloud HSM sont accessibles à l'aide des mêmes API et bibliothèques clientes que celles du backend du logiciel Cloud KMS.

Cloud HSM utilise des HSM certifiés FIPS 140-2 de niveau 3 et toujours exécutés en mode FIPS. La norme FIPS spécifie les algorithmes cryptographiques et la génération de nombres aléatoires utilisés par les HSM.

4.5.1. HSM Cavium

La carte PCIe de HSM Cavium est certifiée par le fournisseur comme étant conforme à la norme FIPS 140-2 de niveau 3. Le certificat actuel est disponible sur demande.

4.5.2. Hiérarchie des clés HSM

Dans le schéma suivant, Cloud KMS figure dans la moitié supérieure du schéma. Cloud HSM encapsule les clés client, puis Cloud KMS encapsule les clés HSM transmises au datastore de Google.

"Schéma de la hiérarchie des clés HSM"

Cloud HSM dispose d'une clé (non illustrée) qui contrôle la migration du matériel au sein du domaine administratif Cloud HSM. Une région peut posséder plusieurs domaines administratifs HSM.

La clé racine HSM présente deux caractéristiques :

  1. Elle est générée sur un HSM et ne quitte jamais les limites bien définies des HSM pendant toute sa durée de vie. Elle peut être répliquée sur d'autres HSM ou sur des HSM de sauvegarde.
  2. Elle peut être utilisée comme clé de chiffrement de clé pour encapsuler directement ou indirectement les clés client utilisées par les HSM.

Les clés client encapsulées par des clés racine HSM peuvent être utilisées sur les HSM, mais ces derniers ne renvoient jamais le texte brut des clés client. Les HSM n'utilisent les clés client que pour les opérations.

4.5.3. Protection du datastore

Les HSM ne sont pas utilisés comme espace de stockage permanent des clés. Ils ne stockent les clés que lorsqu'elles sont utilisées. Comme l'espace de stockage HSM est limité, les clés HSM sont chiffrées et stockées dans le datastore de clés Cloud KMS. Ce sujet est décrit en détail dans la section Backend du datastore plus loin dans cet article.

4.5.4. Règles de rotation

Plusieurs types de clés sont impliqués dans la stratégie de protection des clés de Cloud HSM. Les clients effectuent la rotation de leurs propres clés et s'appuient sur Cloud KMS pour effectuer une rotation des clés HSM.

4.5.5. Processus de provisionnement et de gestion

Le provisionnement des HSM est effectué dans un atelier doté de nombreuses protections physiques et logiques, dont des contrôles d'autorisation impliquant plusieurs parties pour éviter qu'une seule personne ne compromette le processus.

Voici les règles invariantes de Cloud HSM au niveau du système :

  1. Les clés client ne peuvent pas être extraites en texte brut.
  2. Les clés client ne peuvent pas être déplacées en dehors de la région d'origine.
  3. Toutes les modifications de configuration apportées aux HSM provisionnés sont protégées par plusieurs mesures de sécurité.
  4. Les opérations administratives sont consignées, conformément à la séparation des tâches entre les administrateurs Cloud HSM et les administrateurs de journalisation.
  5. Les HSM sont conçus de manière à être protégés contre toute falsification (par exemple, des modifications matérielles ou logicielles malveillantes ou l'extraction non autorisée de secrets) tout au long de leur cycle de vie opérationnel.

4.5.6. Micrologiciel contrôlé par le fournisseur

Le micrologiciel HSM est signé numériquement par le fournisseur HSM. Google ne peut pas créer ni mettre à jour le micrologiciel HSM. Tous les micrologiciels du fournisseur sont signés, y compris le micrologiciel de développement utilisé pour les tests.

4.5.7. Régionalité

Les clés client sont attribuées à des régions géographiques spécifiques en raison de leur association à une clé racine HSM particulière. Par exemple, une clé créée spécifiquement dans la région us-west1 ne peut pas migrer vers la région us-east1 ou une zone multirégionale us. De même, une clé créée dans la zone multirégionale us ne peut pas migrer vers ou depuis la région us-west1.

4.6. Cloud KMS : importation de clés

Vous pouvez choisir d'importer vos propres clés dans votre environnement cloud. Par exemple, vous pouvez être soumis à des exigences réglementaires requérant que les clés servant à chiffrer vos données cloud soient générées d'une manière spécifique ou dans un environnement particulier. Cloud KMS vous permet d'importer vos propres clés cryptographiques que vous avez créées sur site ou dans un gestionnaire de clés externe. L'importation de clés vous permet d'importer ces clés et de respecter ces réglementations. Vous pouvez également importer des clés asymétriques pour étendre vos fonctionnalités de signature au cloud.

Dans le cadre de l'importation de clés, Cloud KMS génère une clé d'encapsulation correspondant à une paire de clés publique/privée, à l'aide de l'une des méthodes d'importation compatibles. Le chiffrement du matériel de clé avec cette clé d'encapsulation protège le matériel de clé en transit.

Cette clé d'encapsulation publique Cloud KMS permet de chiffrer, sur le client, la clé à importer. La clé privée correspondant à cette clé publique est stockée dans Google Cloud et permet de la désencapsuler une fois qu'elle atteint le projet Google Cloud. La méthode d'importation que vous choisissez détermine l'algorithme utilisé pour créer la clé d'encapsulation. Une fois le matériel de la clé encapsulé, vous pouvez l'importer dans une nouvelle clé ou version de clé sur Cloud KMS.

Les clés importées peuvent être utilisées avec le niveau de protection HSM ou SOFTWARE.

Pour Cloud HSM, la portion de clé privée de la clé d'encapsulation est disponible uniquement dans Cloud HSM. Le fait de limiter la portion de clé privée à Cloud HSM empêche Google de désencapsuler le matériel de clé en dehors de Cloud HSM.

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

Par défaut, Google Cloud chiffre toutes les données client stockées au repos, et Google gère les clés servant au chiffrement. Pour certains produits Google Cloud, les clients peuvent plutôt utiliser Cloud KMS pour gérer les clés servant au chiffrement. La fonctionnalité CMEK peut être utilisée à la fois pour les clés logicielles et matérielles. Cloud KMS permet au client de contrôler de nombreux aspects des clés (tels que la création, l'activation/la désactivation, la rotation et la destruction des clés) et de gérer les autorisations IAM appropriées. Cloud KMS inclut plusieurs rôles IAM prédéfinis qui disposent de droits et de limites spécifiques, et qui peuvent être accordés à des utilisateurs et des comptes de service spécifiques afin d'appliquer une séparation des tâches recommandée.

Les articles suivants fournissent des détails sur les produits intégrés à la plate-forme Cloud KMS compatibles avec la fonctionnalité CMEK :

L'impact de la rotation des clés sur la version de clé utilisée dépend de la façon dont un produit met en œuvre la fonctionnalité CMEK. En général, la rotation de la clé Cloud KMS ne rechiffre pas les données dans le service CMEK associé. Par exemple, BigQuery n'effectue pas une rotation automatique d'une clé de chiffrement de table lorsque la clé Cloud KMS associée à la table effectue également une rotation. Les tables BigQuery existantes continuent à utiliser la version de clé avec laquelle elles ont été créées. Les nouvelles tables BigQuery utilisent la version de clé actuelle. Pour en savoir plus, consultez la documentation de chaque produit.

Consultez cette documentation pour obtenir la liste complète des intégrations CMEK et des services compatibles avec cette fonctionnalité. Google continue d'investir dans l'intégration CMEK pour d'autres produits Google Cloud.

4.8. Cycle de vie d'une requête Cloud KMS

Pour obtenir une vue dynamique de l'utilisation des structures architecturales présentées jusqu'ici, lisez cette section qui décrit le cycle de vie d'une requête Cloud KMS, ainsi que la suivante qui explique la destruction du matériel de clé.

"Schéma du cycle de vie des requêtes KMS"

Les étapes de ce cycle de vie sont les suivantes :

  1. Un client, ou une tâche exécutée pour le compte d'un client, envoie une requête au service Cloud KMS : https://cloudkms.googleapis.com. Le serveur DNS convertit cette adresse en adresse IP Anycast de Google Front End (GFE).
  2. Le GFE fournit l'hébergement IP public de son nom DNS public, la protection contre les attaques par déni de service (DoS, Denial of Service) et la terminaison TLS. Lorsque le client envoie sa requête, celle-ci est généralement acheminée vers un GFE situé à proximité, quelle que soit la zone ciblée par la requête. Les GFE gèrent la négociation TLS et, à l'aide de l'URL et des paramètres de la requête, déterminent quel équilibreur de charge logiciel global (GSLB, Global Software Load Balancer) achemine la requête.
  3. Il existe une cible GSLB distincte pour chaque région Cloud KMS. Si la requête arrive à Google dans us-east1 et qu'elle est destinée à us-west1, elle est acheminée entre les centres de données us-east1 et us-west1. Toutes les communications entre les centres de données sont chiffrées en transit à l'aide du système ALTS, qui authentifie mutuellement les tâches GFE et Cloud KMS.
  4. Lorsque la requête atteint la tâche Cloud KMS, elle est d'abord traitée par un framework qui gère une grande partie du travail commun à tous les services Google Cloud. Ce framework authentifie l'utilisateur et procède à diverses vérifications portant sur les éléments suivants :
    • Le client dispose d'un identifiant valide et peut être authentifié.
    • L'API Cloud KMS est activée dans le projet Google Cloud, et celui-ci dispose d'un compte de facturation valide.
    • Le quota est suffisant pour exécuter la requête.
    • Le client est autorisé à utiliser la région Google Cloud concernée.
    • La requête ne sera pas rejetée par VPC Service Controls.
  5. Une fois ces vérifications effectuées, le framework transmet la requête et l'identifiant à Cloud KMS. Cloud KMS analyse la requête pour déterminer les ressources concernées par la demande d'accès, puis vérifie auprès de IAM si l'appelant est autorisé à effectuer la requête. IAM indique également à Cloud KMS si l'occurrence de la requête doit être écrite dans les journaux d'audit.
  6. Une fois la requête authentifiée et autorisée, Cloud KMS appelle ses backends de datastore dans la région pour récupérer la ressource demandée. Une fois récupéré, le matériel de clé client est déchiffré pour permettre son utilisation.
  7. À l'aide du matériel de clé, Cloud KMS effectue ensuite l'opération de chiffrement, en transférant la version encapsulée de la clé au backend du logiciel Cloud KMS ou à Cloud HSM, en fonction du niveau de protection de la clé.
  8. Une fois l'opération de chiffrement terminée, la réponse est renvoyée au client via le même type de canal GFE-KMS que la requête.
  9. Lorsque la réponse est renvoyée, Cloud KMS déclenche également certains événements de manière asynchrone :
    • Les journaux d'audit et de requêtes sont remplis et mis en file d'attente en vue de leur écriture.
    • Des rapports sont envoyés à des fins de facturation et de gestion des quotas.
    • Si la requête a mis à jour les métadonnées d'une ressource, la modification est envoyée à l'inventaire des éléments cloud via des tâches de mise à jour par lot.

4.9. Destruction du matériel de clé

La suppression de données sur Google Cloud est décrite dans ce livre blanc. Le matériel de clé étant considéré comme des données client, l'approche décrite dans le livre blanc s'applique à Cloud KMS. En outre, comme Google ne partage jamais le matériel de clé en dehors de Cloud KMS, il est détruit à la demande lorsque la période d'attente de 24 heures avant la suppression est terminée et que les sauvegardes sont arrivées à expiration. Ce processus n'est pas garanti pour les copies de clés importées situées hors du contrôle de Cloud KMS.

Bien que le matériel de clé soit détruit comme décrit ci-dessus, les clés et les trousseaux ne peuvent pas être supprimés. Les versions de clé ne peuvent pas non plus être supprimées, mais il est possible de détruire le matériel de la version de clé pour empêcher toute autre utilisation des ressources. Les trousseaux de clés et les clés n'engendrent aucun coût facturable et ne sont soumis à aucune limite de quota. Par conséquent, leur existence prolongée n'a aucune incidence sur les coûts ni sur les limites de production.

Une fois sa destruction programmée, une version de clé n'est plus disponible pour les opérations de chiffrement. Au cours de la période de 24 heures, l'utilisateur peut restaurer la version de clé afin qu'elle ne soit pas détruite.

5. Environnement opérationnel de la plate-forme Cloud KMS

L'environnement opérationnel de la plate-forme Cloud KMS comprend des règles de stockage et de sécurité des données, des restrictions d'accès et des stratégies d'atténuation des risques conçues pour optimiser la fiabilité, la durabilité et la disponibilité tout en protégeant le matériel de clé. Cette section décrit la structure opérationnelle du service, les responsabilités des membres de l'équipe en charge des opérations, les mécanismes d'authentification, ainsi que les protocoles d'audit et de journalisation. La discussion qui suit concerne à la fois les fonctionnalités des clés matérielles et logicielles.

5.1. Ingénieurs logiciel, ingénieurs en fiabilité des sites et opérateurs système

Les ingénieurs logiciel sont chargés de collaborer avec d'autres parties prenantes telles que les responsables produit et les ingénieurs en fiabilité des sites (SRE, Site Reliability Engineer) pour concevoir le système, ainsi que rédiger une grande partie du code et des tests pour le service Cloud KMS. Le code inclut la tâche principale qui traite les requêtes de clients, ainsi que les tâches secondaires pour des activités telles que la réplication de données et la facturation. Les SRE peuvent également rédiger du code. Cependant, les tâches des ingénieurs logiciel et des SRE sont séparées. Les SRE sont principalement responsables de la maintenance de l'environnement de production pour les tâches Cloud KMS. Les SRE évaluent et atteignent la fiabilité grâce aux tâches d'ingénierie et aux opérations.

Les opérateurs système sont chargés du processus de compilation et de déploiement, de la surveillance, de l'alerte et de la planification des capacités pour Cloud KMS. Ils sont en première ligne pour traiter les problèmes des clients et les pannes de Cloud KMS. Par exemple, les opérateurs système se servent d'outils et de fonctions d'automatisation pour réduire le travail effectué manuellement sur les systèmes afin de pouvoir concentrer leurs efforts sur des tâches qui apportent de la valeur sur le long terme.

5.2. Régionalité des ressources Cloud KMS

Vous pouvez créer des ressources Cloud KMS dans l'un des quatre types d'emplacements Google Cloud :

  • Zones régionales : une zone régionale se compose de zones géographiques spécifiques, comme l'État de l'Iowa.
  • Zones birégionales : une zone birégionalese compose de zones situées dans deux lieux géographiques spécifiques, tels que les États de l'Iowa et de la Caroline du Sud.
  • Zones multirégionales : une zone multirégionale comprend des régions qui s'étendent sur une zone géographique générale, comme les États-Unis.
  • Emplacement global L'emplacement global comprend des zones réparties dans le monde entier. Lorsque vous créez vos ressources Cloud KMS dans l'emplacement global, elles sont disponibles dans des zones du monde entier.

Les emplacements représentent les zones géographiques où sont traitées les requêtes adressées à Cloud KMS concernant une ressource donnée et où sont stockées les clés cryptographiques correspondantes.

Pour en savoir plus sur les emplacements Cloud KMS disponibles, consultez la documentation Cloud KMS.

5.2.1. Régions et centres de données cloud

Une région Google Cloud contient un centre de données spécifique ou un ensemble spécifique de centres de données, déterminé par sa désignation en tant que zone régionale unique, zone birégionale, zone multirégionale ou emplacement global. Pour en savoir plus sur les régions Google Cloud, consultez la page Emplacements Google Cloud.

Chaque centre de données contient des racks de machines pour le calcul, la mise en réseau ou le stockage de données. Ces machines exécutent l'infrastructure Borg de Google.

Les centres de données Google ont des exigences strictes en termes de sécurité physique. Les personnes qui souhaitent pénétrer dans un espace physique pouvant contenir des données utilisateur doivent se soumettre à des contrôles d'accès avec lecteurs de badge et/ou scanners d'iris pour s'authentifier. Les portes ne doivent pas rester ouvertes pour laisser entrer plusieurs personnes. Chaque personne doit s'authentifier individuellement. Personne n'est autorisé à entrer dans ces zones ni à en sortir avec des sacs, à moins d'utiliser des sacs transparents explicitement autorisés après avoir été inspectés par le personnel de sécurité. Une autorisation spéciale est requise pour laisser entrer ou sortir tout appareil électronique pouvant transmettre ou enregistrer des données.

5.2.2. Régionalité

Certains secteurs exigent que les clés cryptographiques se trouvent dans un emplacement spécifique. Comme indiqué ci-dessus dans la section Régionalité des ressources Cloud KMS, Cloud KMS propose quatre types de zones régionales pour vous aider à répondre à ces exigences.

Pour les zones régionales uniques, birégionales ou multirégionales, Cloud KMS crée, stocke et traite vos clés logicielles et matérielles et votre matériel de clé client uniquement dans ces zones. Les systèmes de stockage et de traitement des données utilisés par Cloud KMS sont configurés pour n'utiliser que les ressources de la région Google Cloud associée au matériel de clé. Le matériel de clé créé dans des zones birégionales ou multirégionales ne quitte pas les limites des zones sélectionnées.

Pour la région globale, aucune régionalité spécifique n'est garantie.

Cloud KMS ne garantit pas la résidence des métadonnées de clés, des journaux d'utilisation ou du matériel de clé en transit. Les métadonnées de clés incluent les noms de ressources, les propriétés des ressources Cloud KMS, telles que le type de clé, la taille de la clé, l'état de la clé, les stratégies IAM et toutes les données dérivées des métadonnées.

Lorsque vous utilisez la fonctionnalité CMEK, les restrictions géographiques Cloud KMS suivantes s'appliquent à vos clés, quelles que soient les zones personnalisées, birégionales ou multirégionales choisies dans d'autres produits Google Cloud que vous souhaitez utiliser avec CMEK :

  • Pour une région spécifique : étant donné que la région d'une clé KMS gérée par le client doit toujours correspondre à la région de la ressource qu'elle protège dans un service Google Cloud donné, les restrictions de résidence pour les clés et ressources d'une zone régionale unique sont garanties être compatibles et appliquées.
  • Pour les zones birégionales ou multirégionales : les utilisateurs peuvent sélectionner des zones multirégionales mises en corrélation et définies par Google pour leurs clés et leurs ressources Google Cloud afin de garantir la conformité de la résidence. Pour garantir cette résidence géographique, assurez-vous que vos régions dans les autres produits correspondent à la zone régionale Cloud KMS choisie.

Le tableau suivant récapitule les informations sur la résidence du matériel de clé pour Cloud KMS.

Résidence des données Cloud KMS Au repos, en cours d'utilisation
(zone régionale unique)
Au repos, en cours d'utilisation
(zone birégionale/multirégionale)
Matériel de la clé logicielle Résident Résident dans les régions constituant la zone birégionale/multirégionale.
Matériel de la clé matérielle (HSM) Résident Résident dans les régions constituant la zone birégionale/multirégionale.

5.2.3. Surveillance des régions

Les services internes de surveillance des données de Google surveillent activement la résidence des clés. Cloud KMS envoie des alertes aux membres de l'équipe SRE s'il détecte de mauvaises configurations accidentelles, ou si le matériel de clé quitte les limites de sa région configurée, est stocké dans la mauvaise région ou est accessible depuis la mauvaise région.

5.3. Authentification et autorisation

Cloud KMS accepte divers mécanismes d'authentification, tels que OAuth2, JWT et ALTS. Quel que soit le mécanisme, Cloud KMS résout les identifiants fournis pour identifier l'entité principale (entité authentifiée et autorisant la requête), et appelle IAM pour déterminer si l'entité principale est autorisée à effectuer la requête et si un journal d'audit est écrit.

Cloud KMS utilise une version interne de l'API Service Control publique pour de nombreux aspects de la gestion des services. Avant de traiter une requête, une tâche Cloud KMS envoie une requête de vérification à l'API Service Control, qui applique de nombreux contrôles communs à tous les services Google Cloud, tels que les suivants :

  • Vérifier si le client a activé l'API Cloud KMS et dispose d'un compte de facturation actif.
  • Vérifier si le client n'a pas dépassé son quota et signaler l'utilisation du quota.
  • Appliquer VPC Service Controls.
  • Vérifier si le client figure dans la liste d'autorisation pour les régions de cloud privé applicables.

5.4. Journalisation

Trois types de journaux sont associés à Cloud KMS : les journaux Cloud Audit Logging, les journaux Access Transparency et les journaux de requêtes internes.

5.4.1. Journaux Cloud Audit Logging

Cloud KMS enregistre l'activité des clients dans les journaux Cloud Audit Logging. Les clients peuvent afficher ces journaux dans Cloud Console. Toutes les activités d'administration, telles que la création ou la destruction d'une clé, sont enregistrées dans ces journaux. Les clients peuvent également choisir d'activer la journalisation pour toutes les autres actions qui utilisent une clé, par exemple pour chiffrer ou déchiffrer des données. Les clients contrôlent la durée pendant laquelle ils souhaitent conserver les journaux, ainsi que les personnes autorisées à les consulter.

5.4.2. Journaux Access Transparency

Les clients éligibles peuvent éventuellement choisir d'activer les journaux Access Transparency, qui répertorient les actions réalisées par les employés de Google au sein de votre organisation Google Cloud. Les journaux Access Transparency, ainsi que les journaux Cloud Audit Logging, peuvent vous aider à déterminer qui a fait quoi, où et quand.

Vous pouvez intégrer les journaux Access Transparency à vos outils de gestion des informations et des événements de sécurité (SIEM, Security Information and Event Management) existants afin d'automatiser les contrôles que vous souhaitez effectuer sur ces actions. Ces journaux sont disponibles dans Cloud Console avec vos journaux Cloud Audit Logging.

Les entrées de journal Access Transparency incluent les types d'informations suivants :

  • La ressource et l'action affectées
  • Le moment où l'action a été effectuée.
  • Le motif de l'action. Par exemple, il peut s'agir d'une assistance demandée par le client (avec un numéro de dossier), d'une assistance demandée par Google, de demandes de données reçues de tiers et de demandes de vérification initiées par Google.
  • Des informations concernant les personnes agissant sur les données (par exemple, la position géographique d'un membre du personnel de Google)

5.4.3. Journaux de requêtes internes

Les journaux de requêtes conservent un enregistrement pour chaque requête envoyée à la plate-forme Cloud KMS. Cet enregistrement contient des détails sur le type de requête (tel que la méthode ou le protocole de l'API) et la ressource faisant l'objet d'un accès (par exemple, le nom de la ressource, l'algorithme de la clé ou le niveau de protection de la clé). Ces journaux ne stockent pas le texte brut, le texte chiffré ou le matériel de clé du client. Avant d'ajouter de nouveaux types de données à ces journaux, une équipe chargée de contrôler la confidentialité des dossiers doit approuver les modifications apportées aux données consignées.

Les entrées de journal sont définitivement supprimées lorsque la valeur TTL (Time To Live) configurée a expiré.

Les SRE et les ingénieurs Cloud KMS d'astreinte peuvent accéder aux journaux de requêtes. L'accès aux journaux et tout accès aux données client par une personne nécessitent une justification professionnelle valide et documentée. À quelques exceptions près, tout accès aux données par une personne est consigné dans les journaux Access Transparency et accessible aux clients éligibles.

5.5. Backend du datastore

Le datastore Cloud KMS bénéficie d'une disponibilité, d'une durabilité et d'une protection élevées.

Disponibilité : Cloud KMS utilise le datastore interne de Google, qui est hautement disponible et compatible avec un certain nombre de systèmes critiques de Google.

Durabilité : Cloud KMS utilise le chiffrement authentifié pour stocker le matériel de clé client dans le datastore. En outre, toutes les métadonnées sont authentifiées à l'aide d'un code d'authentification de message (HMAC, Hash-based Message Authentication Code) pour s'assurer qu'elles n'ont pas été modifiées ou corrompues au repos. Une tâche par lot analyse toutes les heures l'intégralité du matériel et des métadonnées de clés, et vérifie que les codes HMAC sont valides et que le matériel de clé peut être déchiffré. Si des données sont corrompues, les ingénieurs Cloud KMS sont immédiatement avertis afin de pouvoir prendre les mesures nécessaires.

Cloud KMS utilise plusieurs types de sauvegardes pour le datastore :

  • Par défaut, le datastore conserve un historique des modifications de chaque ligne pendant plusieurs heures. En cas d'urgence, cette durée de vie peut être étendue afin de donner plus de temps pour résoudre les problèmes.
  • Le datastore enregistre toutes les heures un instantané. L'instantané peut être validé et utilisé pour la restauration, si nécessaire. Ces instantanés sont conservés pendant quatre jours.
  • Chaque jour, une sauvegarde complète est copiée sur le disque et sur une bande.

L'équipe Cloud KMS dispose de procédures documentées de restauration des sauvegardes en cas d'urgence.

Résidence : les sauvegardes du datastore Cloud KMS sont résidentes dans la région Google Cloud à laquelle elles sont associées. Ces sauvegardes sont toutes chiffrées au repos. L'accès aux données dans les sauvegardes est contrôlé par des justifications d'accès (telles que le numéro de dossier de votre demande d'assistance Google), et l'accès aux données par une personne est consigné dans les journaux Access Transparency.

Protection : au niveau de la couche d'application Cloud KMS, le matériel de clé client est chiffré avant d'être stocké. Les ingénieurs du datastore n'ont pas accès au matériel de clé client en texte brut. De plus, le datastore chiffre toutes les données qu'il gère avant d'écrire dans un espace de stockage permanent. Par conséquent, l'accès aux couches de stockage sous-jacentes, y compris les disques ou les bandes, ne permet pas d'accéder aux données Cloud KMS chiffrées sans avoir accès aux clés de chiffrement du datastore, qui sont stockées dans le KMS interne de Google.

6. Documentation complémentaire

Pour en savoir plus, consultez les ressources suivantes :

Livres blancs :

Autre documentation :