Architecture Cloud HSM

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

Pour vous aider à respecter les réglementations de l'entreprise et en matière de conformité, Cloud HSM vous permet de générer vos clés de chiffrement et d'effectuer des opérations de cryptographie dans des modules de sécurité matériels (HSM) certifiés FIPS 140-2 de niveau 3.

Ce document décrit l'architecture de Cloud HSM, y compris la manière dont le matériel est géré et les clés certifiées et créées.

Présentation

Les opérations de chiffrement incluent le chiffrement des données au repos, la protection des clés privées pour Certificate Authority Service et la protection des clés de chiffrement des données afin qu'elles puissent être stockées avec les données chiffrées. Cloud HSM utilise les HSM Marvell LiquidSecurity (modèles CNL3560-NFBE-2.0-G et CNL3560-NFBE-3.0-G) avec les versions du micrologiciel 3.4 build 09. Pour en savoir plus sur notre certification, consultez la page Certificat n° 4399.

Cloud HSM est entièrement géré afin que vous puissiez protéger vos charges de travail sans subir les coûts opérationnels liés à la gestion d'un cluster HSM. Le service offre les avantages suivants :

Disponibilité mondiale
Une API cohérente et unifiée
Scaling automatique en fonction de votre utilisation
Gestion centralisée et conformité réglementaire

Cloud HSM est disponible dans toutes les régions Google Cloud du monde entier, y compris dans des zones multirégionales plus étendues. Lorsque vous activez Cloud HSM, vous pouvez créer et utiliser des clés basées sur HSM pour protéger vos données, y compris celles que vous stockez dans d'autres services Google Cloud, tels que BigQuery, Cloud Storage, et Persistent Disk.

Étant donné que Cloud HSM et le matériel HSM sont gérés par Google, vous n'avez pas besoin de gérer les clés basées sur HSM en production. Lorsque vous utilisez Cloud HSM, vos données sont strictement isolées des autres locataires et services dans Google Cloud. L'API du plan de données Cloud HSM, qui fait partie de l'API Cloud Key Management Service, vous permet de gérer automatiquement les clés basées sur HSM.

Cloud HSM accepte les clés de chiffrement gérées par le client (CMEK, Customer-Managed Encryption Key) basées sur HSM, partout où les clés CMEK sont disponibles dans Google Cloud. Par exemple, vous pouvez chiffrer des données dans des buckets Cloud Storage ou des tables Cloud SQL à l'aide d'une clé Cloud HSM que vous gérez.

Gestion de Cloud HSM

Dans Cloud HSM, les clusters des HSM sont gérés par les ingénieurs en fiabilité des sites (SRE) et les techniciens de Google qui travaillent dans chaque centre de données Google Cloud. Google gère la sécurité physique, la sécurité logique, l'infrastructure, la planification de la capacité, l'expansion géographique et la planification de la reprise après sinistre pour les centres de données dans Cloud HSM.

Abstraction du matériel HSM

En règle générale, les applications communiquent directement avec les HSM à l'aide de PKCS#11 et d'une API de gestion des clusters. Cela nécessite de gérer un code spécialisé pour les charges de travail qui utilisent ou gèrent des clés basées sur HSM.

Cloud HSM élimine la communication du HSM en envoyant par proxy les requêtes de clés basées sur HSM via l'API Cloud Key Management Service. L'abstraction réduit le besoin de code propre à HSM. Cloud HSM hérite d'une intégration étroite à Cloud KMS.

L'intégration étroite avec Cloud KMS offre des avantages considérables en matière de sécurité. L'API Cloud Key Management Service réduit considérablement l'étendue de l'interface HSM, ce qui réduit les risques en cas de violation de la sécurité du client. Par exemple, un pirate informatique ne serait pas en mesure d'effacer l'intégralité des HSM. Par défaut, les tentatives de destruction de clés individuelles sont atténuées via une période de sécurité de 24 heures. Vous pouvez définir la règle d'administration constraints/cloudkms.minimumDestroyScheduledDuration pour appliquer une durée minimale avant la destruction programmée des nouvelles clés ou les règles d'administration constraints/cloudkms.disableBeforeDestroy pour supprimer les versions de clé uniquement lorsqu'elles sont désactivées. Pour en savoir plus, consultez la page Contrôler la destruction d'une version de clé.

Vous pouvez contrôler l'accès aux ressources HSM à l'aide d'IAM (Identity and Access Management). Une configuration IAM est moins susceptible de rencontrer des erreurs de configuration et des bugs qu'une solution HSM personnalisée.

Schéma de l'architecture Cloud HSM.

Séparation géographique stricte, volontaire

Dans Cloud HSM, vous pouvez choisir de rendre les clés disponibles à l'échelle mondiale ou d'appliquer des restrictions géographiques strictes sur les clés qui en ont besoin.

Les HSM sont souvent divisés en partitions, de sorte qu'un seul appareil physique peut fonctionner comme plusieurs appareils logiques. Vous pouvez utiliser des partitions pour réduire les coûts de déploiement lorsque vous devez séparer l'administration et les clés HSM.

Chaque emplacement régional Cloud HSM est associé à une clé d'encapsulation distincte. La clé d'encapsulation est clonée sur une partition dans chaque HSM de l'emplacement, mais ne quitte jamais le HSM à l'emplacement. Cela permet aux HSM d'une même région de diffuser le même ensemble de clés client et garantit que les HSM situés en dehors de la région ne peuvent pas diffuser ces clés.

Cloud HSM crée également des emplacements multirégionaux à l'aide de clés d'encapsulation. Toutes les clés client d'un emplacement multirégional sont encapsulées à l'aide d'une clé d'encapsulation présente sur une partition, dans tous les emplacements qui constituent l'emplacement multirégional. Le service utilise le même matériel pour les emplacements multirégionaux, mais fournit la même isolation forte entre les régions et les emplacements multirégionaux.

Schéma de la zone géographique Cloud HSM

Le schéma de régionalisation nécessite que les clés d'encapsulation ne soient répliquées que sur les partitions appropriées. Chaque modification de configuration doit être approuvée par plusieurs membres de l'équipe Cloud HSM avant d'être active. Les techniciens de centre de données ne peuvent pas accéder à une configuration HSM, à un environnement d'exécution ni à un stockage sur le terrain.

Gestion centralisée

Dans un centre de données traditionnel qui héberge des HSM, la gestion des HSM et de leurs ressources est complètement distincte de la gestion des autres ressources cryptographiques. Cloud HSM est étroitement intégré à Google Cloud, ce qui vous permet de gérer de manière transparente vos ressources Cloud HSM. Par exemple, vous pouvez gérer les éléments suivants :

Vous gérez vos ressources basées sur HSM en même temps que les autres clés dans Cloud KMS et les clés gérées en externe dans Cloud External Key Manager (Cloud EKM).
Vous gérez l'accès aux ressources basées sur HSM dans IAM.
Les rapports de coûts liés aux opérations de chiffrement utilisant des clés basées sur HSM sont indiqués dans Cloud Billing.
Vous pouvez utiliser les clés sauvegardées par HSM de manière transparente dans tous les services Google Cloud qui acceptent le chiffrement des ressources à l'aide de CMEK. Les intégrations de CMEK nécessitent que la clé CMEK et les données qu'elle chiffre se trouvent dans des emplacements géographiques compatibles. En raison de la restriction géographique stricte des clés Cloud HSM, l'ensemble du chiffrement et du déchiffrement des données CMEK est également limité géographiquement.
Les opérations administratives sur les ressources basées sur HSM sont toujours consignées au niveau de la couche API dans les journaux d'audit Cloud. Vous pouvez également choisir d'activer la journalisation des accès aux données. Pour plus d'informations, consultez la page Informations sur les journaux d'audit Cloud KMS.
Google s'associe directement au fabricant du HSM pour garantir la mise à jour du matériel et des logiciels sur chaque HSM, ainsi que pour rechercher et résoudre les problèmes en temps réel. En cas d'exploitation nulle sur le HSM, Google peut désactiver de manière sélective les chemins de code concernés sur les clusters HSM concernés jusqu'à ce que l'exploitation soit corrigée.

Expérience développeur et utilisateur

Comme Google est responsable de la gestion du HSM, Cloud HSM offre des avantages considérables aux développeurs et aux utilisateurs finaux.

HSM à l'échelle de Google

Lorsque vous utilisez du matériel existant sur site ou dans des centres de données, celui-ci est susceptible de brider les performances ou de devenir un point de défaillance unique. Cloud HSM est conçu pour résister fortement aux charges de travail imprévisibles et aux défaillances matérielles. Le backend Cloud HSM utilise un pool de HSM dans chaque région pour garantir la haute disponibilité et l'évolutivité. Ce pool de HSM permet également à Cloud HSM de fournir un débit élevé. Pour en savoir plus, consultez la page Surveiller et ajuster les quotas Cloud KMS.

Toutes les clés client sont stockées sous forme encapsulée avec une clé d'encapsulation régionale dans la base de données Cloud KMS et ne peuvent être désencapsulées que par un HSM de la région lors d'une opération de chiffrement. L'encapsulation présente les avantages suivants :

La durabilité d'une clé n'est pas liée à un HSM ou à un sous-ensemble de HSM spécifique d'une région.
Chaque client Cloud HSM bénéficie de l'évolutivité et de la disponibilité complètes des clusters Cloud HSM diffusant ses clés.
Cloud HSM peut gérer un ensemble de clés beaucoup plus volumineux capable d'être stocké sur un HSM.
L'ajout ou le remplacement d'un HSM est rapide et sécurisé.

Conception d'API unifiée

Cloud HSM et Cloud KMS partagent une API de gestion et de plan de données commune. Les détails internes de la communication avec un HSM sont extraits de l'appelant.

Par conséquent, aucun changement de code n'est requis pour mettre à jour une application existante qui utilise des clés logicielles dans Cloud KMS afin d'être compatibles avec les clés sauvegardées par HSM. Au lieu de cela, vous mettez à jour le nom de ressource de la clé à utiliser.

Compatibilité avec PKCS#11

Vous pouvez utiliser l'API Cloud Key Management Service pour connecter vos applications existantes à Cloud HSM afin de gérer les clés cryptographiques. La bibliothèque PKCS#11 vous permet d'utiliser des clés HSM pour signer vos binaires et diffuser des sessions Web TLS.

Sécurité et conformité réglementaire

Cloud HSM est certifié conforme à de nombreuses réglementations, telles que FedRAMP High, C5:2020 et OSPAR. De plus, Cloud HSM peut vous aider à appliquer la conformité réglementaire pour vos charges de travail dans le cloud.

Attestation de clé cryptographique

Chaque fois que vous générez ou importez une clé Cloud HSM, le HSM génère une instruction d'attestation signée avec une clé de signature associée à la partition. L'instruction contient des informations sur les attributs de votre clé. La clé de signature est sauvegardée par des chaînes de certificats racines à la fois dans Google et dans le fabricant du HSM. Vous pouvez télécharger l'instruction d'attestation et les certificats pour vérifier l'authenticité de l'instruction et valider les propriétés de la clé et du HSM qui l'a générée ou importée.

La chaîne de certificats vous permet de vérifier les affirmations suivantes :

Le matériel et le micrologiciel HSM sont authentiques.
La partition HSM et HSM sont gérés par Google.
Le HSM est en mode de fonctionnement FIPS.

Le contenu de l'instruction d'attestation vous permet de vérifier les éléments suivants :

La clé n'est pas extraite.
La clé a été générée pour votre CryptoKeyVersion.
La clé publique d'une paire de clés asymétriques correspond à une clé privée basée sur HSM.
Le matériel de clé d'une clé symétrique importée correspond à la valeur que vous avez encapsulée.

Importer des clés directement dans les HSM en toute sécurité

Vous pouvez importer en toute sécurité des clés existantes dans Cloud HSM pour conserver une sauvegarde de votre matériel de clé en dehors de Google Cloud, ou pour simplifier la migration de certaines charges de travail vers Google Cloud. Le processus d'importation de clé ne permet pas à Google d'accéder directement au matériel de clé non encapsulé. Cloud HSM fournit une instruction d'attestation pour la clé d'encapsulation générée par HSM afin de vérifier qu'aucun accès n'a eu lieu.

Comme l'importation de clés est susceptible de créer un risque de sécurité et de conformité en permettant aux utilisateurs d'importer des clés provenant de sources inconnues, des rôles IAM distincts permettent de contrôler avec précision les utilisateurs autorisés à importer des clés dans un projet. Les clés importées peuvent être caractérisées par la déclaration d'attestation générée par le HSM lors de l'importation.

Pour en savoir plus, consultez la page Importer une clé dans Cloud Key Management Service.

Procédures de sécurité strictes pour protéger le matériel HSM

Conformément à la norme FIPS 140-2 de niveau 3, les appareils HSM disposent de mécanismes intégrés qui vous aident à vous protéger et à fournir des preuves de falsification physique.

En plus des garanties fournies par le matériel HSM lui-même, l'infrastructure de Cloud HSM est gérée conformément à la conception de la sécurité dans l'infrastructure Google.

Des procédures documentées et contrôlables protègent l'intégrité de chaque HSM pendant le provisionnement, le déploiement et la production :

Toutes les configurations HSM doivent être validées par plusieurs ingénieurs SRE de Cloud HSM avant de pouvoir être déployées dans un centre de données.
Une fois qu'un HSM a été mis en service, la modification de la configuration ne peut être lancée et vérifiée que par plusieurs ingénieurs SRE de Cloud HSM.
Un HSM ne peut recevoir que des micrologiciels signés par le fabricant du HSM.
Le matériel HSM n'est pas directement exposé à un réseau.
Les serveurs qui hébergent du matériel HSM ne peuvent pas exécuter de processus non autorisés.

Les tâches des opérateurs système sont définies dans les procédures opérationnelles standards. Les opérateurs système ne peuvent pas accéder au matériel de clé client, l'utiliser ni l'extraire dans le cadre de leurs tâches.

Isolation des services et des locataires

L'architecture Cloud HSM garantit que les HSM sont protégés contre les interférences malveillantes ou involontaires avec d'autres services ou locataires.

Un HSM qui fait partie de cette architecture n'accepte que les requêtes de Cloud HSM, et le service Cloud HSM n'accepte que les requêtes de Cloud KMS. Cloud KMS impose aux appelants de disposer des autorisations IAM appropriées sur les clés qu'ils tentent d'utiliser. Les requêtes non autorisées n'atteignent pas les HSM.

Les clés basées sur HSM sont également soumises à des quotas pour les opérations de chiffrement. Ces quotas protègent votre capacité à exécuter vos charges de travail en évitant les tentatives accidentelles ou malveillantes de surcharge du service. Les quotas par défaut, 3 000 RPM pour les opérations de chiffrement asymétriques et 30 000 RPM pour les opérations de chiffrement symétriques, sont basés sur les modèles d'utilisation observés. Les quotas sont nettement inférieurs à la capacité de service et peuvent être augmentés à la demande.

Flux de requêtes

Cette section explique comment les points forts de l'architecture ci-dessus s'appliquent dans la pratique, en affichant les étapes correspondant aux différents types de requêtes. Ces flux mettent l'accent sur les parties liées à Cloud HSM. Pour en savoir plus sur les étapes communes à toutes les clés, consultez la présentation détaillée de Cloud Key Management Service.

Créer des clés

Lorsque vous créez une clé basée sur HSM, l'API Cloud Key Management Service ne crée pas le matériel de clé, mais demande à HSM de le faire.

Un HSM ne peut créer des clés que dans les emplacements avec lesquels il est compatible. Chaque partition d'un HSM contient une clé d'encapsulation correspondant à un emplacement Cloud KMS. La clé d'encapsulation est partagée entre toutes les partitions compatibles avec l'emplacement Cloud KMS. Le processus de création de clé se présente comme suit :

Le service Google Front End (GFE) achemine la requête de création de clé vers un serveur Cloud KMS à l'emplacement correspondant à la requête.
L'API Cloud Key Management Service vérifie l'identité de l'appelant, s'il dispose de l'autorisation nécessaire pour créer des clés dans le projet et s'il détient un quota de requêtes d'écriture suffisant.
L'API Cloud Key Management Service transmet la requête à Cloud HSM.
Cloud HSM communique directement avec le HSM. Le HSM :
1. Crée la clé et l'encapsule avec la clé d'encapsulation spécifique à l'emplacement.
2. Crée l'instruction d'attestation pour la clé et la signe avec la clé de signature de partition.
Une fois que Cloud HSM a renvoyé la clé encapsulée et l'attestation à Cloud KMS, l'API Cloud Key Management Service encapsule la clé encapsulée par HSM en fonction de la hiérarchie des clés Cloud KMS puis l'écrit dans le projet.

Cette conception garantit que la clé ne peut pas être désencapsulée ou utilisée en dehors d'un HSM, qu'elle ne peut pas être extraite du HSM et qu'elle n'existe dans son état désencapsulé que dans les emplacements spécifiés.

Le schéma suivant montre les différences lors de la création de clés Cloud HSM et de clés logicielles dans Cloud KMS.

Schéma de création de clés HSM

Opérations de chiffrement

Lorsque vous effectuez une opération de chiffrement dans Cloud KMS, vous n'avez pas besoin de savoir si vous utilisez une clé logicielle ou une clé basée sur HSM. Lorsque l'API Cloud Key Management Service détecte qu'une opération implique une clé basée sur HSM, elle transfère la requête à un HSM situé au même emplacement. Pour effectuer une opération de chiffrement, procédez comme suit :

Le GFE achemine la requête vers un serveur Cloud KMS à l'emplacement approprié. L'API Cloud Key Management Service vérifie l'identité de l'appelant, s'il dispose de l'autorisation nécessaire pour accéder à la clé et effectuer l'opération, et le quota du projet pour les opérations de chiffrement.
L'API Cloud Key Management Service récupère la clé encapsulée du datastore et déchiffre un niveau de chiffrement à l'aide de la clé principale Cloud KMS. La clé est toujours encapsulée avec la clé d'encapsulation HSM pour l'emplacement KMS.
L'API Cloud Key Management Service détecte que le niveau de protection est HSM et envoie la clé partiellement désencapsulée, ainsi que les entrées à l'opération de chiffrement, à Cloud HSM.
Cloud HSM communique directement avec le HSM. Le HSM effectue les opérations suivantes :
1. Vérifie que la clé encapsulée et ses attributs n'ont pas été modifiés.
2. Désencapsule la clé et la charge dans l'espace de stockage HSM.
3. Effectue l'opération de chiffrement et renvoie le résultat.
L'API Cloud Key Management Service renvoie le résultat à l'appelant.

Les opérations de chiffrement utilisant des clés basées sur HSM sont effectuées entièrement dans un HSM à l'emplacement configuré, et seul le résultat est visible par l'appelant.

Ce schéma montre la différence entre la création de clés Cloud HSM et de clés logicielles dans Cloud KMS.

Schéma des opérations de chiffrement HSM

Intégrations de CMEK

L'utilisation combinée de CMEK et de Cloud HSM vous permet de protéger vos données dans certains services Google Cloud à l'aide de clés HSM. Pour configurer un service avec CMEK de manière à utiliser des clés Cloud HSM, il vous suffit de choisir une clé dotée d'un niveau de protection HSM lorsque vous suivez les instructions spécifiques au service.

Lorsqu'un appelant lit ou écrit des données dans un service avec CMEK, il n'a pas besoin d'autorisation directe pour utiliser la clé et n'a pas besoin de savoir si la clé est stockée dans un HSM.

Le flux pour une opération CMEK est très semblable à celui d'une opération de chiffrement normale, avec les exceptions suivantes :

La requête du service avec CMEK est lancée au sein du réseau de Google et n'a pas besoin de transiter par le serveur GFE.
L'API Cloud Key Management Service vérifie que le compte de service du service avec CMEK dispose des autorisations appropriées pour utiliser la clé. L'API Cloud Key Management Service ne valide pas les autorisations sur l'utilisateur final du service avec CMEK.

Cloud HSM est le service de gestion des clés matérielles de Google Cloud. Il offre un certain nombre d'avantages distincts aux utilisateurs qui cherchent à protéger leurs données au repos avec des clés HSM. Le service a été conçu selon les principes d'un accès verrouillé aux API aux HSM, d'une évolutivité sans effort et d'une régionalisation étroite des clés.

Cloud HSM offre la compatibilité CMEK avec les services les plus importants et la présence de Cloud HSM dans toutes les régions Google Cloud (y compris les régions multirégionales et mondiales). Ce service est conçu pour vous permettre de protéger facilement vos données sensibles, où qu'elles se trouvent, grâce à une clé protégée par des appareils FIPS 140-2 de niveau 3.

Étapes suivantes

Pour en savoir plus, consultez les ressources suivantes :