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

Ce contenu a été mis à jour pour la dernière fois en juillet 2023, et correspond à l'état des connaissances à sa date de rédaction. Les règles et les systèmes de sécurité de Google peuvent changer par la suite, car nous améliorons continuellement la protection de nos clients.

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 la 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.

Le tableau suivant décrit les différents types de clés Google Cloud.

Type de clé	Gestion des clés	Partage des clés	Rotation automatique	Tarifs
Clé de chiffrement par défaut	Ces clés sont gérées uniquement par Google.	Les données de plusieurs clients peuvent utiliser la même clé de chiffrement de clé (KEK).	Oui, consultez la section Chiffrement au repos par défaut.	Gratuit.
Clés Cloud KMS	Ces clés sont contrôlées par le client.	Spécifique à un client.	Oui pour le chiffrement symétrique et non pour les clés asymétriques. Consultez la page Rotation des clés.	Consultez les tarifs de Cloud Key Management Service.

Ce document se concentre sur le fonctionnement interne de la plate-forme Cloud KMS. Ces options vous aident à protéger les clés et autres données confidentielles que vous stockez dans Google Cloud. Ce document 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 ce document, nous partons du principe que vous avez déjà acquis les connaissances de base sur les concepts de chiffrement et les architectures cloud.

Piliers de conception de Cloud 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. La conception de Cloud KMS repose sur les cinq piliers suivants:

• Contrôle client: Cloud KMS vous permet de contrôler vos propres clés logicielles et matérielles pour le chiffrement et la signature. Ce pilier inclut la compatibilité avec les clés BYOK (Bring Your Own Key) et HYOK (Hold Your Own Key).
• Contrôle des accès et surveillance: avec 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 uniquement dans l'emplacement Google Cloud que vous sélectionnez.
• Sauvegardes : 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.

Sources et options de gestion pour les matériels de clés

La plate-forme Cloud KMS vous permet de gérer les clés cryptographiques dans un service cloud central pour une utilisation directe ou pour d'autres ressources et applications cloud.

Le schéma suivant montre le portefeuille de clés Google Cloud, organisées entre le matériel de clé contrôlé par Google et celui contrôlé par le client.

Les options présentées dans le schéma précédent sont les suivantes:

• Chiffrement par défaut : Toutes les données stockées par Google sont chiffrées au niveau de la couche de stockage à l'aide de l'algorithme AES (Advanced Encryption Standard) AES-256. Nous générons et gérons les clés pour le chiffrement par défaut, et les clients n'ont pas accès aux clés ni au contrôle de la rotation et de la gestion des clés. Les clés de chiffrement par défaut peuvent être partagées entre les clients. Pour en savoir plus, consultez la page Chiffrement au repos par défaut.

• Cloud KMS avec des clés générées par logiciel: avec Cloud KMS, vous pouvez contrôler les clés générées par Google. Le backend du logiciel Cloud KMS vous permet de chiffrer ou de signer vos données à l'aide d'une clé symétrique ou asymétrique que vous contrôlez.

• Cloud KMS avec des clés générées par le matériel (Cloud HSM): en utilisant Cloud KMS avec le backend Cloud HSM, vous pouvez posséder les clés qui sont générés et stockées dans des modules de sécurité matériels (HSM) détenus et gérés par Google. Si vous avez besoin d'une clé protégée par du matériel, vous pouvez utiliser le backend Cloud HSM pour vous assurer que vos clés symétriques et asymétriques ne sont utilisées que dans des HSM validés FIPS 140-2, niveau 3.

• Cloud KMS avec importation de clés: pour répondre aux exigences de BYOK, vous pouvez importer vos propres clés cryptographiques que vous générez vous-même. Vous pouvez utiliser et gérer ces clés en dehors de Google Cloud, et utiliser le matériel de clé dans Cloud KMS pour chiffrer ou signer les données que vous stockez dans Google Cloud.

• Cloud KMS avec gestionnaire de clés externe (Cloud EKM) : pour répondre aux exigences HYOK, vous pouvez créer et contrôler des clés stockées dans un gestionnaire de clés externe à Google Cloud. Vous configurez ensuite la plate-forme Cloud KMS pour qu'elle utilise les clés externes afin de protéger vos données au repos. Vous pouvez utiliser ces clés de chiffrement avec une clé Cloud EKM. Pour en savoir plus sur la gestion des clés externes et sur Cloud EKM, consultez la page Architectures de référence pour un déploiement fiable des services Cloud EKM.

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 qui contribuent à protéger les données d'autres services Google Cloud.

Concepts de chiffrement et gestion des clés Google

Cette section définit certains termes liés à la gestion des clés dans le contexte de l'infrastructure multicouche de gestion des clés de Google.

Trousseaux de clés, clés et versions de clé

Le schéma suivant illustre les regroupements de clés et montre les trousseaux de clés ainsi que les clés avec une seule version principale et plusieurs versions précédentes.

Les concepts clés illustrés dans le schéma précédent sont les suivants:

• 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é. Vous pouvez attribuer des stratégies d'autorisation IAM au niveau de la clé dans la hiérarchie des ressources.

  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 créer ou valider des signatures MAC, ou pour le chiffrement symétrique afin de protéger certains corpus de données. Par exemple, vous pouvez utiliser 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 ou pour la signature asymétrique. Pour plus d'informations, consultez la section Objectifs et algorithmes compatibles.

• 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 d'autorisation de leur trousseau. 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. Les tags vous permettent d'autoriser ou de refuser des règles de manière conditionnelle selon qu'une ressource possède un tag spécifique ou non. Vous pouvez appliquer des tags au niveau du trousseau de clés dans la hiérarchie des ressources.

  Pour éviter les conflits au niveau des noms de ressources, vous ne pouvez pas supprimer un trousseau ou une clé. 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.

• Métadonnées de clés: noms de ressources, propriétés des ressources KMS telles que les stratégies d'autorisation, le type de clé, la taille de la clé, l'état de la clé et toutes les données dérivées des clés et des trousseaux de clés

• Version de clé : le matériel de clé correspondant 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 la version "1". La rotation d'une clé 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 signifie que vos données sont chiffrées à l'aide de différentes versions de clé. Les clés symétriques possèdent une version principale. Par défaut, la version principale est utilisée 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.

Hiérarchie des clés logicielles

Le schéma suivant illustre la hiérarchie des clés pour Cloud KMS et le keystore interne de Google. Cloud KMS utilise Keystore, le service de gestion de clés interne de Google, pour encapsuler les clés chiffrées par Cloud KMS. Le chiffrement encapsulé consiste à chiffrer une clé à l'aide d'une autre clé afin de la stocker ou de l'envoyer en toute sécurité sur un canal non approuvé. Cloud KMS utilise la même racine de confiance que Keystore.

La hiérarchie des clés présentée dans le schéma précédent est la suivante:

1. Une clé de chiffrement des données (DEK) chiffre les fragments de données.
2. Les clés de chiffrement de clé (KEK) permettent de chiffrer ou d'encapsuler la DEK. Toutes les options de la plate-forme Cloud KMS (logiciels, matériel et backends externes) vous permettent de contrôler la KEK. Les KEK sont stockées dans Cloud KMS.
3. Une clé principale KMS chiffre la clé KEK. La clé principale KMS est stockée dans Keystore. Il existe une clé principale KMS distincte dans Keystore pour chaque emplacement Cloud KMS. Les KEK de Cloud KMS sont protégées par la clé principale KMS de l'emplacement. Chaque serveur Cloud KMS récupère au démarrage une copie de la clé principale KMS en tant que dépendance forte et extrait une nouvelle copie de celle-ci chaque jour. La clé principale KMS est rechiffrée régulièrement.
4. La clé principale KMS est protégée par la clé principale Keystore de Keystore.
5. La clé principale Keystore est protégée par la clé principale Root Keystore.

Pour en savoir plus sur Keystore, consultez la section Gestion des clés dans l'article sur le chiffrement au repos.

Contraintes opérationnelles de clés

Cloud KMS fonctionne dans les limites suivantes:

• 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. Pour respecter la bonne pratique de séparation des tâches entre les administrateurs de clés et les administrateurs de données, vous pouvez supprimer le rôle de propriétaire du projet de clé.
• Emplacement : dans un projet, les ressources Cloud KMS sont créées dans un emplacement. Pour en savoir plus sur les emplacements, consultez la page Zones géographiques et régions.
• Cohérence: Cloud KMS propage les opérations sur les clés, les trousseaux de clés et les versions de clés à l'aide d'une cohérence forte ou d'une cohérence à terme. Pour en savoir plus, consultez la page Cohérence des ressources Cloud KMS.

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 de secours externes, matérielles et logicielles. La plate-forme Cloud KMS est intégrée à Identity and Access Management (IAM) et Cloud Audit Logs, ce qui vous permet de gérer les autorisations sur des clés individuelles et de surveiller leur utilisation.

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 Cloud Console ou de Google Cloud CLI.

• Les applications accèdent aux services de gestion des clés en mettant en œuvre l'API REST, gRPC ou les bibliothèques clientes. Les applications peuvent utiliser les services Google qui sont activés pour utiliser les CMEK. Le chiffrement CMEK utilise à son tour l'API Cloud Key Management Service. Si votre application utilise PKCS #11, vous pouvez l'intégrer à Cloud KMS à l'aide de la bibliothèque pour PKCS #11.

• L'API Cloud KMS vous permet d'utiliser des clés logicielles, matérielles ou des clés externes. Les clés logicielles et matérielles utilisent les protections de sauvegarde redondantes de Google.

• Si vous utilisez des clés matérielles, les HSM certifiés FIPS 140-2 de niveau 3 dans Google Cloud stockent les clés. Pour en savoir plus sur notre certification, consultez la page Certificat n° 4399.

• Cloud KMS utilise le datastore interne de Google pour stocker le matériel de clé client chiffré. Ce datastore est hautement disponible et compatible avec de nombreux systèmes critiques de Google. Consultez la page Protection Datastore.

• À intervalles réguliers, le système de sauvegarde indépendant sauvegarde l'intégralité du datastore dans un espace de stockage en ligne et d'archives. Cette sauvegarde permet à Cloud KMS d'atteindre ses objectifs de durabilité. Consultez la page Protection Datastore.

Certification FIPS 140-2

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. Ces opérations de cryptographie utilisent BoringCrypto, une bibliothèque de cryptographie Open Source gérée par Google. 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.

Dépendances de l'infrastructure Google

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 conception de la sécurité sur l'infrastructure de Google.

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. Les tâches de diffusion de l'API Cloud KMS traitent également les actions différées des requêtes des clients, telles que la rotation des clés selon le calendrier, la création de clés asymétriques et l'importation de 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.

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 :

• Décompte des clés actives pour la facturation client.
• Regroupez les ressources de l'API publique de tampon de protocole pour Cloud KMS et transférez les 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.
• Données d'instantané pour la 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.

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 du service partagé qui héberge les tâches du serveur d'API Cloud KMS. Chaque service partagé 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. Si le datastore principal est lent ou indisponible, la réponse peut être diffusée à partir d'un instantané, à condition que celui-ci ne date pas de 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é.

Communications client-serveur

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

Pour en savoir plus, consultez la page Authentification, intégrité et chiffrement de service à service.

Architecture de la plate-forme Cloud KMS

Cette section décrit les détails d'architecture concernant la sécurité du matériel de clé et la protection du datastore.

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 utilisée pour protéger le matériel de clé client est en cours de rotation ou de 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).

L'authentification se produit entre toutes les tâches Cloud 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) applique cette stratégie au niveau opérationnel.

Les tâches de l'API Cloud KMS peuvent accéder aux métadonnées de clés (par exemple, la stratégie d'autorisation 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. Ces événements d'accès sont consignés en interne, et les journaux concernant les données couvertes par Access Transparency sont également disponibles pour les clients éligibles.

Le matériel de clé déchiffré ne peut pas être exporté ni affiché, que ce soit 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 Keystore, qui n'est pas accessible directement par quiconque. Sur un HSM, le matériel de clé n'est jamais accessible dans un état déchiffré par les tâches de l'API Cloud KMS.

Protection 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 basé sur le hachage (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 quatre jours. 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 dans l'espace de stockage d'archives.

L'équipe Cloud KMS dispose de procédures documentées de restauration des sauvegardes afin de limiter la perte de données en cas d'urgence côté service.

Sauvegardes. 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 ayant accès au 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 le stockage d'archives, n'autorise même pas l'accès aux données Cloud KMS chiffrées sans avoir accès aux clés de chiffrement du datastore, qui sont stockées dans Keystore.

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 Keystore qui encapsulent les clés principales 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 KMS dans les tâches KMS toutes les 24 heures et rechiffre toutes les clés client chaque mois.

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 emplacements multirégionaux, par exemple l'emplacement multirégional us.

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.

Backend de clé

Lorsque vous créez une clé avec Cloud KMS, vous pouvez choisir un niveau de protection pour déterminer quel backend de clé crée la clé et effectue toutes les opérations de chiffrement futures sur cette clé. Les backends sont exposés dans l'API Cloud KMS avec les niveaux de protection suivants:

• 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.
• HSM: s'applique aux clés ne pouvant être désencapsulées que par les HSM qui effectuent toutes les opérations de chiffrement avec celles-ci.
• EXTERNAL ou EXTERNAL-VPC: s'appliquent au gestionnaire de clés externe (EKM). EXTERNAL-VPC vous permet de connecter l'EKM à Google Cloud via un réseau VPC.

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.

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 la section Objectifs et algorithmes des clés, et comprennent les opérations de chiffrement, de déchiffrement et de signature avec les clés cryptographiques symétriques AES256-GCM et les clés cryptographiques asymétriques RSA 2048, RSA 3072, RSA 4096, EC P256 et EC P384.

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), consultez la page Conception de RNG.

Backend Cloud HSM: niveau de protection HARDWARE

Cloud HSM fournit des clés avec support matériel à Cloud KMS. Il vous permet d'utiliser des clés cryptographiques protégées par des HSM entièrement gérés et certifiés FIPS 140-2 de niveau 3 dans les centres de données Google. Comme Cloud KMS, Cloud HSM offre une disponibilité élevée et une évolutivité élastique. Aucune modification d'application n'est requise pour les clients Cloud KMS existants, car ils peuvent accéder au backend Cloud HSM à l'aide des mêmes API et bibliothèques clientes que Cloud KMS. Pour en savoir plus sur le backend Cloud HSM, consultez la section Architecture Cloud HSM.

Cloud EKM: niveau de protection EXTERNE

Cloud EKM vous permet de chiffrer les données à l'aide de clés de chiffrement hors cloud qui restent sous votre contrôle.

Les clés dotées des niveaux de protection EXTERNAL et EXTERNAL_VPC sont stockées et gérées dans un système de gestion des clés externe. Pour plus d'informations, consultez la section Architectures de référence pour un déploiement fiable des services Cloud EKM.

Importation des clés

Vous pouvez importer vos propres clés que vous avez créées sur site ou dans un EKM 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. L'importation de clés vous permet d'importer ces clés et de respecter les obligations réglementaires. Pour étendre vos fonctionnalités de signature au cloud, vous pouvez également importer des clés asymétriques.

Dans le cadre de l'importation de clés, Cloud KMS génère une clé d'encapsulation publique 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.

Vous utilisez la clé d'encapsulation publique pour chiffrer la clé à importer sur le client. La clé privée correspondant à la clé publique est stockée dans Google Cloud et permet de décapsuler la clé publique 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.

Vous pouvez utiliser des clés importé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.

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, vous pouvez plutôt utiliser Cloud KMS pour gérer les clés servant au chiffrement. La fonctionnalité CMEK peut être utilisée pour les clés externes, logicielles et matérielles. Cloud KMS vous permet 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 qui leurs sont associées. Pour appliquer une séparation des tâches recommandée, 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.

La rotation de la clé Cloud KMS ne rechiffre pas les données dans le service CMEK associé. À la place, les ressources nouvellement créées sont chiffrées à l'aide de la nouvelle version de clé, ce qui signifie que différentes versions d'une clé protègent différents sous-ensembles de données. Par exemple, BigQuery n'aligne pas automatiquement la rotation d'une clé de chiffrement de table lorsque la clé Cloud KMS associée à cette table alterne. 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.

Les règles d'administration CMEK permettent de mieux contrôler l'utilisation de CMEK dans vos projets. Ces règles vous permettent de contrôler à la fois les services et les projets qui contiennent des clés autorisées pour les CMEK.

Google Cloud est compatible avec le chiffrement CMEK pour plusieurs services, y compris Cloud Storage, BigQuery et Compute Engine. Pour obtenir la liste complète des intégrations CMEK et des services compatibles avec les CMEK, consultez la section Intégrations de CMEK. Google continue d'investir dans l'intégration CMEK pour d'autres produits Google Cloud.

Cycle de vie d'une requête Cloud KMS

Cette section décrit le cycle de vie d'une requête Cloud KMS, ainsi qu'une explication sur la destruction du matériel de clé. Le schéma suivant montre un client demandant l'accès aux instances de service Cloud KMS dans us-east1 et us-west1, et le mode de routage des requêtes à l'aide de Google Front End (GFE).

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 le 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, 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 n'est pas refusé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 la ressource récupérée, 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, au backend Cloud HSM ou au backend Cloud EKM, selon la 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.

Intégrité des données de bout en bout

Cloud KMS vous permet de calculer des sommes de contrôle pour les clés et le matériel de clé afin de vous assurer qu'ils ne sont pas corrompus. Ces sommes de contrôle vous protègent contre la perte de données pouvant être due à la corruption matérielle ou logicielle. Les bibliothèques d'aide vous permettent de vérifier l'intégrité des clés. Vous pouvez utiliser des bibliothèques d'aide pour vérifier l'intégrité des clés en fournissant des sommes de contrôle à Cloud KMS, qui sont validées par le serveur. De plus, ces bibliothèques vous permettent de recevoir des sommes de contrôle pour vérifier les données de réponse sur le client.

L'intégrité des données de bout en bout vous aide à protéger votre environnement contre les menaces suivantes:

• Corruption pendant le transit comme dans la pile entre le moment où les données sont envoyées et où elles sont protégées par TLS.
• Problèmes liés aux proxys intermédiaires entre votre point de terminaison et KMS (par exemple, pour les requêtes entrantes).
• Opérations de chiffrement incorrectes, corruption de mémoire de la machine ou corruption de HSM dans l'architecture Cloud KMS.
• Corruption lors de la communication avec un EKM externe.

Pour plus d'informations, consultez la section Vérifier l'intégrité des données de bout en bout.

Destruction du matériel de clé

Le matériel de clé étant considéré comme des données client, l'approche décrite dans la section Suppression des données sur Google Cloud s'applique également à Cloud KMS. Le matériel de la clé est détruit à la demande, lorsque la période Destruction programmée est terminée et que les sauvegardes expirent. Le matériel de clé toujours présent dans les sauvegardes (une fois la période de destruction programmée terminée) ne peut être utilisé que pour la reprise après sinistre régionale et non pour la restauration de clés individuelles. Ce processus n'est pas garanti pour les copies de clés importées situées hors du contrôle de Cloud KMS.

Par défaut, les clés dans Cloud KMS demeurent 30 jours à l'état Destruction programmée (Supprimée de façon réversible) avant que le matériel de la clé ne soit logiquement supprimé du système. Vous pouvez modifier cette durée. Pour plus d'informations, consultez la section Durée variable de l'état "Destruction programmée".

Bien que le matériel de clé soit détruit, 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 que la destruction d'une version de clé est programmée, elle n'est plus disponible pour les opérations de chiffrement. Pendant la période de suppression en attente, vous pouvez restaurer la version de clé afin qu'elle ne soit pas détruite.

Si vous supprimez une clé importée par erreur, vous pouvez la réimporter. Pour en savoir plus, consultez la section Réimporter une clé détruite.

Pour éviter de supprimer accidentellement une clé, tenez compte des bonnes pratiques suivantes:

• Créez un rôle KMS personnalisé qui n'inclut pas l'autorisation cloudkms.cryptoKeyVersions.destroy.
• Définissez le champ destroy_scheduled_duration sur une période plus longue.

• Surveillez et ajoutez des alertes pour les événements de destruction de clés. Par exemple, créez le filtre Cloud Logging suivant:

    resource.type="cloudkms_cryptokeyversion"
    protoPayload.methodName="DestroyCryptoKeyVersion"
  

• Créez des processus qui désactivent la clé pendant quelques jours avant la suppression de la clé.

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. Cette section s'applique à la fois aux fonctionnalités de clé matérielle et logicielle.

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.

Les tâches des opérateurs système sont définies dans les procédures opérationnelles standards. Les opérateurs système n'accèdent pas au matériel de clé client lors de leurs tâches.

Régionalité des ressources Cloud KMS

Pour vous aider à répondre aux exigences de résidence clés, vous pouvez créer des ressources Cloud KMS dans l'un des quatre types d'emplacements Google Cloud:

• Un emplacement régional se compose de zones géographiques spécifiques, comme l'État de l'Iowa.
• Un emplacement birégionalse 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.
• Un emplacement multirégional comprend des zones réparties sur une zone géographique générale, comme les États-Unis.
• 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 page Emplacements Cloud KMS.

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 scanners d'iris pour s'authentifier. Les portes ne restent pas ouvertes pour laisser entrer plusieurs personnes. Chacun 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.

Résidence des clés

Certains secteurs exigent que les clés cryptographiques se trouvent dans un emplacement spécifique. Cloud KMS dispose de conditions d'emplacement des données avec garantie de résidence des données. Comme indiqué ci-dessus dans la section Régionalité des ressources Cloud KMS, Cloud KMS propose quatre types d'emplacements régionaux pour vous aider à répondre à ces exigences.

Pour les emplacements régionaux uniques, birégionaux ou multirégionaux, Cloud KMS crée, stocke et traite vos clés logicielles et matérielles et votre matériel de clé client uniquement dans ces emplacements. 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 emplacements birégionaux ou multirégionaux ne quitte pas les limites des emplacements sélectionnés.

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 emplacements personnalisés, birégionaux ou multirégionaux choisis dans d'autres produits Google Cloud compatibles 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 emplacements multirégionaux définis 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 à l'emplacement régional Cloud KMS choisi.

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

Type de région	Au repos, en cours d'utilisation
Région unique	Résident
Birégional ou multirégional	Résident dans les régions constituant la zone birégionale/multirégionale.

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.

Haute disponibilité

Cloud KMS peut vous aider à simplifier vos exigences de disponibilité en fonction des régions que vous sélectionnez. Plus l'emplacement est précis, plus vous devez créer de redondance. Pour les applications présentant des niveaux de disponibilité plus élevés, utilisez des emplacements multirégionaux plutôt que d'essayer de créer votre propre système de réplication de clés. Vous devez équilibrer les capacités de redondance intégrées en fonction de vos besoins de régionalisation des données.

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 vous avez activé l'API Cloud KMS et si vous disposez d'un compte de facturation actif.
• Vérifier si vous n'avez pas dépassé votre quota et signaler son utilisation.
• Appliquer VPC Service Controls.
• Vérifiez si vous êtes sur la liste d'autorisation pour les régions de cloud privé applicables.

Gestion des quotas

Cloud KMS impose des limites d'utilisation, appelées quotas, pour les requêtes adressées au service. Cloud KMS contient les quotas suivants:

• Quotas de requêtes de chiffrement pour des opérations telles que le chiffrement, le déchiffrement ou la signature.
• Quotas de requêtes de lecture pour des opérations telles que l'obtention de métadonnées de clés ou l'obtention d'une stratégie IAM.
• Quotas de requêtes d'écriture pour des opérations telles que la création d'une clé ou la définition d'une stratégie IAM

Ces quotas sont imputés au projet associé à l'appelant. Ces quotas sont également globaux, ce qui signifie qu'ils sont appliqués à l'utilisation KMS de l'appelant dans toutes les régions et les emplacements multirégionaux. Ces quotas sont évalués pour tous les niveaux de protection.

Cloud HSM et Cloud EKM comportent des quotas supplémentaires pour les opérations de chiffrement. Ces quotas doivent être satisfaits en plus du quota de requêtes de chiffrement. Les quotas Cloud HSM et Cloud EKM sont imputés au projet où réside la clé, et les quotas sont appliqués pour chaque emplacement.

Prenons les exemples suivants :

• Appeler le déchiffrement avec une clé logicielle dansasia-northeast1 nécessite une unité de quota de requêtes de chiffrement (global).
• La création d'une clé HSM dans us-central1 nécessite une unité de quota de requêtes d'écriture et aucun quota HSM.
• Pour appeler le chiffrement avec une clé EKM dans europe, vous devez disposer d'une unité de quota de requêtes cryptographiques (global) et d'une unité de quota de requêtes KMS externes dans europe.

Pour en savoir plus sur le type de quotas disponibles, consultez la page Quotas sur l'utilisation des ressources Cloud KMS. Vous pouvez afficher votre limite de quota dans la console Cloud. Les limites de quotas initiales sont des limites souples que vous pouvez demander d'ajuster en fonction des besoins de votre charge de travail.

Journalisation

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

Cloud Audit Logs

Cloud KMS enregistre votre activité dans des journaux Cloud Audit Logs. Les clients peuvent afficher ces journaux dans la console Cloud. 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. Vous contrôlez la durée pendant laquelle vous souhaitez conserver les journaux et les personnes autorisées à les afficher.

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 Logs, 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 la console Cloud avec vos journaux Cloud Audit Logs.

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).

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.

Surveillance

Cloud KMS s'intègre à Cloud Monitoring. Cette intégration vous permet de surveiller, de créer des tableaux de bord et de créer des alertes sur de nombreuses opérations Cloud KMS. Par exemple, vous pouvez surveiller la destruction programmée de clés ou surveiller et ajuster les quotas Cloud KMS lorsque les opérations de chiffrement dépassent un seuil que vous avez défini. Pour plus d'informations sur les métriques Cloud KMS disponibles, consultez la page Utiliser Cloud Monitoring avec Cloud KMS.

De plus, Security Command Center intègre des détecteurs de failles KMS. Ces détecteurs permettent de s'assurer que vos projets qui incluent des clés respectent les bonnes pratiques recommandées. Pour en savoir plus sur le détecteur de failles KMS, consultez la page Résultats de failles pour Cloud KMS.

Étapes suivantes

• Pour en savoir plus sur Cloud KMS, consultez les ressources suivantes :
  • Documentation Cloud KMS
  • Documentation Cloud HSM
• Pour en savoir plus sur l'utilisation de vos propres clés de chiffrement dans Google Cloud, consultez la page Clés de chiffrement gérées par le client (CMEK).
• Découvrez comment Google se prépare à un monde post-quantique.
• Pour en savoir plus sur la sécurité de l'infrastructure Google, consultez la page Présentation de la sécurité sur l'infrastructure de Google.
• Des informations générales sur la sécurité dans Google Cloud sont disponibles dans la section "Sécurité" du site Web de Google Cloud.