Pratiques recommandées pour utiliser les clés CMEK

Cette page présente les pratiques recommandées pour configurer le chiffrement au repos avec des clés de chiffrement gérées par le client (CMEK) sur vos ressources Google Cloud . Ce guide s'adresse aux architectes cloud et aux équipes de sécurité. Il présente les bonnes pratiques et les décisions que vous devez prendre lorsque vous concevez votre architecture CMEK.

Ce guide suppose que vous connaissez déjà Cloud Key Management Service (Cloud KMS) et les clés de chiffrement gérées par le client, et que vous avez lu l'analyse approfondie de Cloud KMS.

Choisir où utiliser CMEK

Google vous recommande d'utiliser des clés de chiffrement gérées par le client lorsque vous souhaitez créer une limite cryptographique autour de vos données ou de celles de vos clients dans le cloud. Pour en savoir plus, consultez Clés de chiffrement gérées par le client (CMEK).

Vous pouvez utiliser des CMEK créées manuellement ou des clés créées par Autokey dans les services compatibles pour vous aider à atteindre les objectifs suivants :

• Vous possédez vos clés de chiffrement.

• Contrôlez et gérez vos clés de chiffrement, y compris le choix de l'emplacement, le niveau de protection, la création, le contrôle des accès, la rotation, l'utilisation et la destruction.

• Générez du matériel de clé dans Cloud KMS ou importez du matériel de clé géré en dehors de Google Cloud.

• Définissez une règle concernant l'emplacement où vos clés doivent être utilisées.

• Supprimez de manière sélective les données protégées par vos clés en cas de désactivation ou pour corriger des événements de sécurité (crypto-shredding).

• Créez et utilisez des clés propres à un client pour établir une limite cryptographique autour de vos données.

• Enregistrez les accès aux données et les activités d'administration aux clés de chiffrement.

• Respecter une réglementation actuelle ou future qui exige l'un de ces objectifs.

Google vous recommande également de tenir compte des cadres de conformité qui s'appliquent aux besoins de votre entreprise. Différents cadres de conformité ont des exigences différentes en matière de chiffrement et de gestion des clés. Un cadre de conformité décrit généralement les principes et objectifs généraux de la gestion des clés de chiffrement, mais ne prescrit pas le produit ni la configuration spécifiques permettant d'atteindre la conformité. Il vous incombe de comprendre les exigences de votre cadre de conformité et la façon dont vos contrôles, y compris la gestion des clés, peuvent vous aider à les respecter.

Pour savoir comment les services Google Cloud peuvent vous aider à répondre aux exigences de différents cadres de conformité, consultez les ressources suivantes :

• Protéger les données de santé sur Google Cloud
• Centre de ressources pour la conformité
• Conseils d'implémentation FedRAMP sur Google Cloud
• Conformité avec la norme de sécurité des données PCI

Choisir la source de votre matériel de clé

Lorsque vous créez une clé, vous devez autoriser Cloud KMS à générer le matériel de clé pour vous ou importer manuellement le matériel de clé qui a été généré en dehors de Google Cloud. Dans la mesure du possible, nous vous recommandons de choisir de générer le matériel de clé dans Cloud KMS. Cette option ne risque pas d'exposer le matériel de clé brut en dehors de Cloud KMS et crée automatiquement de nouvelles versions de clé en fonction de la période de rotation des clés que vous choisissez. Si vous devez importer votre propre matériel de clé, nous vous recommandons d'évaluer les considérations opérationnelles et les risques suivants liés à l'utilisation de l'approche BYOK (Bring Your Own Key) :

• Pouvez-vous implémenter l'automatisation pour importer systématiquement de nouvelles versions de clé ? Cela inclut à la fois les paramètres Cloud KMS permettant de restreindre les versions de clé à l'importation uniquement et l'automatisation en dehors de Cloud KMS pour générer et importer de manière cohérente le matériel de clé. Quel est l'impact si votre automatisation ne parvient pas à créer une nouvelle version de clé à l'heure prévue ?

• Comment comptez-vous stocker ou mettre sous séquestre le matériel de clé d'origine de manière sécurisée ?

• Comment atténuer le risque de fuite du matériel de clé brute lors de l'importation de votre clé ?

• Quel serait l'impact de la réimportation d'une clé précédemment détruite, car le matériel de clé brute a été conservé en dehors de Google Cloud ?

• L'avantage d'importer vous-même le matériel de clé justifie-t-il l'augmentation de la charge opérationnelle et du risque ?

Choisir vos modèles de gouvernance et de stockage des clés

Lorsque vous concevez votre architecture CMEK, vous devez décider où et comment vos clés seront gérées. Dans l'idéal, vous choisirez un modèle de gouvernance et un modèle de stockage des clés qui sont compatibles. Le modèle de gouvernance et le modèle de stockage que vous choisissez ont une incidence sur les configurations critiques, comme l'application de la séparation des tâches.

Gouvernance des clés

La gouvernance des clés décrit les personnes responsables de la gestion du cycle de vie de vos ressources Cloud KMS et du maintien des mesures de protection pour contrôler l'utilisation de Cloud KMS dans une organisation. Il existe des approches de gouvernance clés qui s'étendent du centralisé au délégué :

• Gouvernance centralisée : une équipe de sécurité ou de plate-forme dédiée est chargée de gérer le cycle de vie de toutes les clés cryptographiques de l'organisation. Ce modèle est souvent choisi par les entreprises très réglementées qui doivent respecter des exigences de conformité strictes.
• Gouvernance déléguée : une équipe de sécurité centrale utilise des garde-fous pour imposer des normes de chiffrement, mais délègue la responsabilité des opérations liées au cycle de vie des clés aux propriétaires d'applications dans leurs projets. Ces garde-fous peuvent inclure des règles d'administration utilisant des contraintes gérées et des contraintes personnalisées, ainsi que des stratégies IAM d'autorisation et de refus. Cela élimine les goulots d'étranglement opérationnels centraux.

Google recommande une gouvernance centralisée des clés pour les organisations soumises à des exigences réglementaires strictes ou qui doivent s'appuyer sur des systèmes de clés externes pour gérer le cycle de vie des clés.

Le stockage des clés

Le stockage de clés décrit l'emplacement où les ressources Cloud KMS sont créées dans une organisation. Il existe deux approches principales pour le stockage des clés : le stockage des clés dans un projet dédié et le stockage des clés dans le même projet.

• Stockage des clés dans un projet dédié : un projet de clés dédié contient des clés utilisées pour plusieurs applications. En général, chaque dossier d'environnement possède son propre projet de clés. Vous pouvez utiliser Autokey avec le stockage des clés dans un projet dédié. Pour en savoir plus sur le modèle de stockage des clés dans un projet dédié, consultez Stockage des clés dans un projet dédié.

• Stockage des clés dans le même projet : les clés sont stockées dans le même projetGoogle Cloud que les ressources qu'elles protègent. On parle parfois de "la clé suit les données". Vous pouvez utiliser Autokey avec le stockage des clés dans le même projet. Pour en savoir plus sur le modèle de stockage des clés dans le même projet, consultez Stockage des clés dans le même projet.

Google recommande la gouvernance distribuée des clés lorsque votre priorité est la vélocité, l'agilité et la responsabilité claire des développeurs.

Aligner la gouvernance et le stockage

La matrice suivante fournit des exemples de combinaisons de ces modèles de gouvernance et de stockage pour répondre aux différents besoins des organisations :

Modèle de gouvernance	Stockage des clés dans un projet dédié	Stockage des clés dans le même projet
Gouvernance centralisée	Approche entièrement centralisée Utilisation recommandée : organisations soumises à des exigences réglementaires strictes qui imposent l'isolation des limites de projet. Impact opérationnel : complexité de configuration élevée. Nécessite une automatisation robuste (comme une "usine à projets") pour éviter les retards opérationnels pour les équipes de développement.	Propriété régie Utilisation recommandée : organisations qui ont besoin d'une supervision centralisée de la sécurité, mais qui souhaitent maximiser la vélocité des développeurs. Impact opérationnel : complexité de configuration faible. La sécurité centralisée applique les règles à l'aide de garde-fous, tandis que les clés sont colocalisées avec les ressources qu'elles protègent pour faciliter la gestion.
Gouvernance déléguée	Déconseillé L'introduction d'une complexité IAM interprojets va à l'encontre de l'objectif de délégation de la gestion des clés aux équipes d'application.	DevOps autonome Utilisation recommandée : organisations décentralisées à grande vitesse avec une forte culture DevOps. Impact opérationnel : complexité de configuration minimale. Les équipes chargées des applications disposent d'une autonomie totale sur les ressources et les clés dans les limites de leur projet.

Utiliser une architecture cohérente dans tous vos environnements

Nous vous recommandons d'utiliser le même modèle de stockage de clés pour une application donnée dans les environnements de développement, de test et de production. Cette cohérence architecturale permet de s'assurer que vos autorisations IAM, vos pipelines de déploiement et vos contrôles de sécurité sont minutieusement testés dans des environnements inférieurs avant d'être déployés en production. Si vous choisissez des architectures différentes pour vos environnements, vous risquez de provoquer une dérive de configuration pouvant entraîner des échecs de déploiement.

Stockage des clés dans un projet dédié

Dans un modèle de stockage des clés dans un projet dédié, toutes les clés d'un dossier d'environnement spécifique (par exemple, "Production") sont stockées dans un projet de clés partagé et centralisé. Les autorisations de gestion des clés sont accordées à une équipe de sécurité partagée, qui gère généralement également les opérations et les garde-fous du cycle de vie des clés, comme les règles d'administration CMEK et les stratégies et attributions de rôles IAM.

Cas d'utilisation

Nous vous recommandons d'utiliser le modèle de stockage des clés dans un projet dédié si votre organisation privilégie un contrôle strict et centralisé des clés de chiffrement, souvent en raison d'exigences réglementaires, ou lorsque les clés sont hébergées sur un HSM externe.

Si votre organisation est soumise à un cadre de conformité qui exige un responsable de la cryptographie ou un administrateur de clés, comme PCI DSS ou BSI C5, ce modèle est un bon choix. En isolant toutes les clés d'une application dans un seul projet de clé dédié, vous pouvez n'accorder le rôle d'administrateur Cloud KMS qu'à un petit groupe audité d'administrateurs de sécurité. Cela peut simplifier les audits de conformité en limitant le nombre de projets dans lesquels les principales règles d'accès à l'administration doivent être examinées.

Remarques

Cette approche peut introduire des complexités IAM interprojets et des goulots d'étranglement potentiels pour les équipes de développement. Pour atténuer ce risque, vous pouvez implémenter le provisionnement automatisé de projets (parfois appelé "Project Factory") afin d'automatiser la création de clés et l'attribution d'autorisations, ou utiliser Cloud KMS Autokey pour activer le provisionnement à la demande qui prend en charge la séparation des tâches, même pour les pipelines d'infrastructure as code (IaC).

Exemple

Le schéma suivant illustre un exemple de hiérarchie de ressources pour un environnement de production utilisant le modèle de stockage de clés dans un projet dédié :

• Le dossier "Prod" contient des dossiers et des projets individuels pour différentes applications, ainsi qu'un dossier "Shared" (Partagé).
• Les projets d'application contiennent différentes ressources, telles que des instances Compute Engine et des buckets Cloud Storage, mais ils ne contiennent aucune clé Cloud KMS.
• Le dossier "Shared" (Partagé) contient des ressources partagées entre les différentes applications.
• Dans le dossier "Partagé", il existe un projet de clé dédié dans lequel l'API Cloud KMS est activée. Ce projet contient toutes les clés utilisées pour protéger les ressources du dossier "Prod". Si vous utilisez Cloud KMS Autokey, c'est dans ce projet de clés dédié qu'Autokey provisionnera les clés.
• Les garde-fous au niveau de l'organisation et des dossiers, tels que les contraintes liées aux règles d'administration et les stratégies IAM, permettent d'appliquer la séparation des tâches et d'autres pratiques.
• Les développeurs peuvent disposer de privilèges élevés, tels que le rôle de Propriétaire du projet, dans un dossier ou un projet d'application individuel, sans leur accorder de privilèges sur le projet clé.

Stockage des clés dans le même projet

Dans ce modèle, les clés sont stockées dans le même projet que les ressources qu'elles protègent. Les garde-fous de gestion des clés sont généralement mis en œuvre par une équipe de sécurité principale, même si les développeurs gèrent le cycle de vie des clés pour leurs propres applications.

Cas d'utilisation

Nous vous recommandons d'utiliser le modèle de stockage des clés dans le même projet si votre priorité est la vélocité, l'agilité et la responsabilité claire des développeurs. La colocalisation des clés avec les ressources qu'elles protègent permet d'aligner la propriété des clés sur celle des données : la clé suit les données. Ce modèle facilite la délégation des responsabilités de gestion des clés aux propriétaires de charges de travail, qui peuvent se charger de l'alignement sur les règles d'administration CMEK et de la gestion des opérations du cycle de vie des clés dans leurs projets.

Remarques

Bien que ce modèle responsabilise les équipes d'application, il nécessite un audit rigoureux des rôles IAM dans chaque projet pour appliquer le principe du moindre privilège. Ce modèle peut accroître la complexité opérationnelle pour les organisations qui implémentent le modèle "apportez votre propre clé" (BYOK) ou qui utilisent des clés Cloud EKM en raison de la charge de coordination entre les systèmes.

Exemple

Le schéma suivant illustre un exemple de hiérarchie de ressources pour un environnement de production utilisant le modèle de stockage de clés dans le même projet :

• Le dossier "Prod" contient des dossiers et des projets individuels pour différentes applications.
• Les projets d'application contiennent différentes ressources, telles que des instances Compute Engine et des buckets Cloud Storage, y compris les clés Cloud KMS qui protègent ces ressources.
• Si vous utilisez Cloud KMS Autokey, Autokey provisionne les clés dans le projet de ressources.
• Les garde-fous au niveau de l'organisation et des dossiers, tels que les contraintes liées aux règles d'administration et les règles IAM, permettent d'appliquer la séparation des tâches et d'autres pratiques. Toutefois, si vous n'utilisez pas Autokey, l'application de la séparation des tâches peut nécessiter une configuration plus minutieuse.
• Si vous n'utilisez pas Autokey, les développeurs ont besoin de privilèges Cloud KMS élevés sur le projet de ressources. Si vous utilisez Autokey, ils n'ont besoin que des rôles spécifiques au service pour les ressources qu'ils souhaitent créer, comme le rôle "Utilisateur BigQuery" ou "Administrateur Compute".

Appliquer la séparation des tâches

Point clé : Aucun compte principal ne doit disposer à la fois de rôles administratifs tels que Administrateur Cloud KMS et de rôles d'utilisation cryptographique tels que Chiffreur/Déchiffreur de clés cryptographiques Cloud KMS sur la même ressource.

Quel que soit votre modèle de stockage, vous devez conserver des principaux et des autorisations distincts pour les personnes qui administrent vos clés de chiffrement et celles qui les utilisent. Pour appliquer le principe du moindre privilège et une séparation stricte des tâches, attribuez des rôles IAM en fonction des responsabilités opérationnelles spécifiques.

Le tableau suivant récapitule la séparation des rôles recommandée pour Cloud KMS :

Responsabilité	Rôle recommandé	Récapitulatif des autorisations
Administration des clés, par exemple, cycle de vie et gouvernance des clés Cela peut inclure des administrateurs humains et des principaux IaC qui ont besoin de privilèges élevés.	Administrateur Cloud KMS (roles/cloudkms.admin)	Créer, alterner, activer, désactiver et détruire des clés et les ressources associées. Gérez les stratégies IAM.
Provisionnement des ressources, par exemple création de ressources protégées par des clés CMEK Cela peut inclure des développeurs humains et des principaux IaC sans privilèges élevés.	Rôles d'administrateur ou d'éditeur spécifiques à un service, tels que les suivants : Utilisateur BigQuery (roles/bigquery.user) Administrateur de Compute (roles/compute.admin)	Sélectionnez des clés lors de la création de ressources.
Utilisation de la clé (chiffrement et déchiffrement, par exemple) N'attribuez ce rôle qu'aux agents de service. Pour les clés utilisées dans les intégrations CMEK, les principaux humains n'ont pas besoin de ces autorisations. Lorsque vous utilisez Autokey, ce rôle est attribué automatiquement à l'agent de service.	Chiffreur/Déchiffreur de CryptoKeys Cloud KMS (roles/cloudkms.cryptoKeyEncrypterDecrypter)	Chiffrez et déchiffrez les données à l'aide de la clé.

Les clés créées à l'aide d'Autokey respectent automatiquement ces principes.

Appliquer le principe du moindre privilège pour les pipelines IaC

De nombreuses organisations automatisent le provisionnement des ressources à l'aide de pipelines d'infrastructure en tant que code (IaC), tels que les runners Terraform. L'architecture de votre stockage de clés a un impact direct sur la stratégie de sécurité de ces pipelines.

Pour automatiser le provisionnement des clés Cloud KMS, vos pipelines IaC doivent disposer de rôles d'administrateur très privilégiés pour générer des clés et modifier les règles IAM. Si un pirate informatique compromet le pipeline IaC, il peut obtenir un contrôle administratif complet sur votre plan de gestion des clés.

• Si vous utilisez le stockage de clés dans un projet dédié, le pipeline nécessite un accès administrateur au projet Cloud KMS central. Si le pipeline est compromis, le plan de gestion des clés de l'ensemble de votre organisation peut être exposé.
• Si vous utilisez le stockage des clés dans le même projet, le pipeline ne nécessite qu'un accès administrateur au projet de ressources. Cela limite l'étendue du risque potentiel à l'application spécifique, mais nécessite toujours de gérer les droits d'accès élevés au sein du projet.

Cloud KMS Autokey permet de limiter ce risque en déléguant le provisionnement des clés à un agent de service sécurisé géré par Google. Vous pouvez ainsi implémenter un pipeline de moindre privilège pour le provisionnement continu des clés :

• Pipelines à faibles privilèges : le pipeline IaC ne nécessite que le rôle Utilisateur Cloud KMS Autokey à faibles privilèges (roles/cloudkms.autokeyUser) pour demander une clé en créant une ressource KeyHandle.
• Provisionnement automatisé : la création de clés et les mises à jour des règles IAM sont gérées en coulisses par l'agent de service Cloud KMS géré par Google.
• Portée limitée des risques : en minimisant les autorisations accordées à votre pipeline, cette conception évite d'accorder à vos pipelines de déploiement des droits d'administrateur de sécurité ou de création de clés élevés, ou la possibilité d'attribuer des rôles d'assistance, ce qui réduit considérablement le risque de compromission d'un pipeline.

Un pipeline IaC qui permet Autokey nécessite un rôle plus permissif, tel que Administrateur Cloud KMS Autokey (roles/cloudkms.autokeyAdmin). Par conséquent, si vous utilisez des pipelines IaC pour gérer l'activation d'Autokey, vous devez également appliquer la séparation des tâches aux comptes principaux IaC individuels.

Choisir d'utiliser Autokey

Une fois que vous avez choisi votre architecture de stockage de clés, vous devez décider comment les clés sont provisionnées. Nous vous recommandons d'automatiser la création de clés à l'aide de Cloud KMS Autokey chaque fois que cela est possible afin de réduire les tâches répétitives et les erreurs de configuration. Autokey est compatible avec les deux modèles de stockage :

• Autokey avec stockage des clés dans le même projet : les développeurs génèrent facilement des clés à la demande dans leurs propres projets, tout en respectant les consignes centrales. Vous pouvez activer Autokey avec le stockage des clés dans le même projet pour chaque projet ou pour tous les projets d'un dossier.
• Autokey avec stockage des clés dans un projet dédié : les développeurs génèrent facilement des clés dans un projet de clés centralisé pour le compte des ressources d'autres projets. Vous activez Autokey avec le stockage des clés dans un projet dédié au niveau du dossier.

Les pratiques recommandées suivantes sont automatisées lorsque vous utilisez Autokey :

• Créez des clés au même emplacement que la ressource qu'elles protégeront.
• Maintenir la séparation des tâches entre les administrateurs de clés et les propriétaires de ressources
• Attribuer des rôles IAM aux nouvelles clés
• Utilisez le niveau de protection HSM.
• Suivre les stratégies de précision recommandées
• Planifier la rotation automatique des clés tous les 365 jours

Comme Cloud KMS Autokey gère le provisionnement et l'attribution continus des clés, l'utilisation d'Autokey réduit une grande partie des frais généraux liés à l'établissement de règles, d'outils et de procédures opérationnelles personnalisés. Bien qu'il simplifie les efforts initiaux et continus, vous devez toujours définir des garde-fous opérationnels et configurer des contrôles de détection et de surveillance pour assurer une gouvernance cohérente dans toute votre organisation.

Conformité et Autokey

De nombreux régimes de conformité exigent que vous conserviez le contrôle de vos clés de chiffrement, indépendamment de votre fournisseur de services cloud.

Déléguer les tâches de routine de provisionnement de clés à Cloud KMS Autokey ne constitue pas une violation de cette norme. Autokey agit strictement comme un moteur d'automatisation qui exécute vos règles prédéfinies. Vous conservez la propriété, l'autorité et le contrôle cryptographique ultimes grâce à trois mécanismes principaux :

• Votre responsable des opérations de chiffrement conserve le contrôle exclusif des clés. Seuls vos administrateurs peuvent désactiver, faire pivoter ou détruire des versions de clé. Le service Autokey ne peut pas effectuer ces actions de cycle de vie.
• Vos administrateurs déterminent précisément où Autokey est activé et quels principaux peuvent demander des clés. Vous pouvez désactiver Autokey ou révoquer les autorisations à n'importe quel niveau de la hiérarchie des ressources à tout moment, ce qui arrête instantanément l'automatisation.
• Chaque clé générée, autorisation attribuée et règle ajustée par Autokey est enregistrée dans Cloud Logging. Les auditeurs disposent ainsi d'une piste d'audit continue et automatisée pour vérifier la conformité.

Au lieu d'affaiblir la gouvernance, la délégation du provisionnement à Autokey renforce la conformité. Il remplace les étapes de configuration manuelles et sujettes aux erreurs par l'application programmatique de la séparation des tâches et de la sécurité des pipelines, ce qui répond aux exigences de contrôle strictes des programmes de conformité tels que NIST SP 800-152 et PCI DSS.

Respecter les pratiques recommandées de gestion des clés

Google recommande des pratiques concernant l'emplacement, le niveau de protection, le calendrier de rotation, la précision et les autorisations des clés. Vous pouvez mettre en œuvre ces pratiques en utilisant l'approche automatisée avec Cloud KMS Autokey ou en les configurant manuellement. Pour savoir dans quelle mesure vos clés respectent ces pratiques, utilisez le tableau de bord des métriques de chiffrement. Vous pouvez détecter les cas de non-respect de la séparation des tâches à l'aide des résultats d'analyse des failles de Security Command Center.

Emplacement de la clé

Lorsque vous utilisez des CMEK manuelles, vous devez créer des trousseaux de clés Cloud KMS dans les emplacements où vous prévoyez de déployer des ressources Google Cloud chiffrées avec des CMEK. Vous devez effectuer cette opération avant de pouvoir créer les clés.

• Les ressources régionales et zonales doivent utiliser un trousseau de clés et une clé dans la même région que la ressource ou dans l'emplacement global. Les ressources monorégionales et zonales ne peuvent pas utiliser de trousseau de clés multirégional autre que global.
• Les ressources multirégionales (comme un ensemble de données BigQuery dans la région multirégionale us) doivent utiliser un trousseau de clés et une clé dans la même région multirégionale. Les ressources multirégionales ne peuvent pas utiliser de clé régionale.
• Les ressources globales doivent utiliser un trousseau de clés et une clé dans l'emplacement global.

Dans la plupart des cas, ces restrictions sont appliquées par le service Google Cloud.

L'application de l'utilisation de clés régionales est un élément d'une stratégie de régionalisation des données efficace. En imposant l'utilisation de trousseaux de clés et de clés dans une région définie, vous imposez également que les ressources doivent correspondre à la région du trousseau de clés. Pour obtenir des conseils sur la résidence des données, consultez Contrôler la résidence des données. Pour en savoir plus, consultez Choisir un emplacement approprié.

Si vous utilisez Cloud KMS Autokey, des trousseaux de clés sont créés pour vous au même emplacement que les ressources que vous protégez.

Choisir une stratégie de granularité des clés

La granularité fait référence à l'échelle et à la portée de l'utilisation prévue de chaque clé. Par exemple, une clé qui protège plusieurs ressources est dite moins précise qu'une clé qui ne protège qu'une seule ressource. Choisir une stratégie de granularité de clé appropriée vous aide à respecter la recommandation du NIST selon laquelle chaque clé doit avoir un objectif spécifique.

En général, nous vous recommandons d'utiliser chaque clé comme suit :

• Utilisé pour un seul projet Google Cloud .
• Utilisé dans un seul emplacement, par exemple us-central1.
• Utilisé dans un seul service ou produit, par exemple BigQuery.
• Utilisé, dans la mesure du possible, pour une seule ressource (par exemple, un seul bucket Cloud Storage).

Pour la plupart des organisations, cette stratégie offre un bon équilibre entre la surcharge liée à la gestion de nombreuses clés très précises et les risques potentiels liés à l'utilisation de clés moins précises partagées entre de nombreux projets, services ou ressources.

Les clés créées avec Cloud KMS Autokey suivent cette recommandation.

En suivant ces consignes de précision, vous pouvez désactiver ou détruire des versions de clés plus facilement et en toute sécurité, et limiter les risques de destruction accidentelle ou malveillante de clés.

Choisir le niveau de protection des clés

Lorsque vous créez une clé, il vous incombe de sélectionner le niveau de protection approprié pour chaque clé en fonction de vos exigences concernant les données et les charges de travail chiffrées avec CMEK. Les questions suivantes peuvent vous aider dans votre évaluation :

1. Avez-vous des exigences spécifiques en termes d'isolation, de résidence ou de réglementation ? Évaluez si votre charge de travail nécessite l'une des caractéristiques de haute sécurité suivantes :

   • Stockage externe : utilisez CMEK manuellement avec Cloud EKM. Nous vous recommandons le niveau de protection EXTERNAL_VPC pour une meilleure disponibilité.
   • Matériel dédié : utilisez CMEK manuellement avec Cloud HSM à locataire unique.

   Sinon, passez à la question suivante.

2. Souhaitez-vous bénéficier d'un provisionnement et d'une gestion du cycle de vie des clés automatisés ?

   • Si c'est le cas, utilisez Cloud KMS Autokey. Autokey crée automatiquement des clés avec le niveau de protection Cloud HSM mutualisé. Même si les clés logicielles vous conviennent, nous vous recommandons d'accepter le niveau de sécurité de référence plus élevé de Cloud HSM pour bénéficier de l'automatisation fournie par Autokey.

   • Si ce n'est pas le cas, passez à la question suivante.

3. Souhaitez-vous que votre matériel de clé reste dans les limites physiques d'un module de sécurité matériel (HSM) ?

   • Si c'est le cas, utilisez Multi-tenant Cloud HSM.
   • Si ce n'est pas le cas, utilisez des clés logicielles.

Choisir une période de rotation

Cloud KMS est compatible avec la rotation des clés automatique des clés symétriques logicielles et intégrées au matériel, comme celles utilisées pour CMEK. Pour les clés logicielles, nous vous recommandons d'utiliser la période de rotation standard de 90 jours. Pour les clés Cloud HSM, nous recommandons la période de rotation standard de 365 jours. Les clés externes doivent être alternées manuellement selon la fréquence choisie.

Nous vous recommandons d'évaluer la période de rotation des clés appropriée à vos besoins. La fréquence de rotation des clés dépend des exigences de vos charges de travail en termes de sensibilité ou de conformité. Par exemple, la rotation des clés peut être requise au moins une fois par an pour répondre à certaines normes de conformité. Vous pouvez également choisir une période de rotation plus fréquente pour les charges de travail très sensibles.

La rotation fréquente des clés permet de limiter le nombre de messages chiffrés avec la même version de clé, ce qui contribue à réduire le risque et les conséquences d'une clé compromise.

Appliquer le principe du moindre privilège

Lorsque vous attribuez des rôles IAM, suivez le principe du moindre privilège. Nous vous recommandons vivement d'éviter d'utiliser des rôles de base tels que propriétaire, éditeur et lecteur. À la place, accordez des rôles Cloud KMS prédéfinis pour atténuer les risques d'incidents de sécurité liés à un accès trop privilégié. Par exemple, si un compte principal n'a besoin que d'importer des éléments de clé, accordez-lui le rôle Importateur Cloud KMS (roles/cloudkms.importer) au lieu du rôle Administrateur Cloud KMS (roles/cloudkms.admin), qui est plus permissif.

Définir des garde-fous opérationnels

Les sections suivantes décrivent les contrôles que vous pouvez mettre en œuvre pour réduire les risques tels que l'utilisation incohérente des clés, ou la suppression ou la destruction accidentelles.

Appliquer les privilèges du projet

Nous vous recommandons de protéger les projets avec des privilèges (aperçu) pour éviter toute suppression accidentelle de vos projets Cloud KMS et des clés qu'ils contiennent. Lorsqu'un privilège de projet est appliqué, le projet ne peut pas être supprimé tant que le privilège n'est pas supprimé. Pour les projets contenant des clés Cloud KMS, cela permet d'éviter une cause possible de suppression accidentelle de clés.

Exiger des clés CMEK

Nous vous recommandons d'appliquer l'utilisation de CMEK dans votre environnement à l'aide de contraintes de règles d'administration.

Utilisez constraints/gcp.restrictNonCmekServices pour bloquer les requêtes de création de certains types de ressources sans spécifier de clé CMEK.

Exiger Cloud KMS Autokey

L'utilisation de Cloud KMS Autokey pour créer toutes vos CMEK vous permet de vous assurer que vos clés sont créées de manière cohérente. Si vous souhaitez appliquer cette cohérence, vous pouvez configurer un dossier pour qu'il exige des CMEK créées par Autokey et qu'il empêche l'utilisation de clés créées manuellement pour les CMEK. Pour savoir comment configurer ces restrictions, consultez Appliquer l'utilisation d'Autokey.

Exiger une durée minimale programmée pour la destruction

Nous vous recommandons de définir une durée minimale pour l'autodestruction. La destruction d'une clé est une opération irréversible qui peut entraîner une perte de données définitive. Par défaut, Cloud KMS utilise une durée Destruction programmée (parfois appelée période de suppression réversible) de 30 jours avant que le matériel de clé ne soit détruit de manière irrécupérable. Cela vous laisse le temps de restaurer une clé en cas de destruction accidentelle. Toutefois, une personne disposant du rôle Administrateur Cloud KMS peut créer une clé avec une durée de destruction planifiée de seulement 24 heures, ce qui peut ne pas être suffisant pour détecter un problème et restaurer la clé. La durée de la destruction programmée ne peut être définie que lors de la création de la clé.

Lorsqu'une clé est programmée pour destruction, elle ne peut pas être utilisée pour des opérations de chiffrement, et toutes les requêtes d'utilisation de la clé échouent. Pendant ce temps, surveillez les journaux d'audit pour vérifier que la clé n'est pas utilisée. Si vous souhaitez réutiliser la clé, vous devez la restaurer avant la fin de la période Programmé pour destruction.

Pour vous assurer que toutes les clés créées respectent une durée de suppression planifiée minimale, nous vous recommandons de configurer la contrainte de règle d'administration constraints/cloudkms.minimumDestroyScheduledDuration avec une durée minimale de 30 jours ou la durée de votre choix. Cette règle d'administration empêche les utilisateurs de créer des clés dont la durée de suppression planifiée est inférieure à la valeur spécifiée dans la règle.

Appliquer les niveaux de protection autorisés pour les clés CMEK

Nous vous recommandons d'appliquer vos exigences concernant les niveaux de protection des clés de manière cohérente dans votre environnement à l'aide de contraintes de règles d'administration.

Utilisez constraints/cloudkms.allowedProtectionLevels pour appliquer les niveaux de protection que vous autorisez aux nouvelles clés, versions de clé et tâches d'importation.

Lorsque vous imposez l'utilisation d'Autokey, toutes les clés seront intégrées au matériel.

Configurer des contrôles de détection pour les CMEK

Google Cloud fournit divers contrôles de détection pour les CMEK. Les sections suivantes expliquent comment activer et utiliser les contrôles pertinents pour Cloud KMS.

Activer et agréger la journalisation d'audit

Nous vous recommandons d'agréger les journaux d'audit de l'activité d'administration Cloud KMS dans un emplacement centralisé pour toutes les ressources de votre organisation. Cela permet à une équipe de sécurité ou à un auditeur d'examiner en une seule fois toutes les activités liées à la création ou à la modification de ressources Cloud KMS. Pour obtenir des conseils sur la configuration des récepteurs de journaux agrégés, consultez Agréger et stocker les journaux de votre organisation.

Vous pouvez également activer les journaux d'accès aux données pour consigner les opérations qui utilisent les clés, y compris les opérations de chiffrement et de déchiffrement. Lorsque vous utilisez des CMEK, cela peut générer un volume de journaux important et avoir un impact sur vos coûts, car chaque opération de chaque service qui utilise des CMEK créera des journaux d'accès aux données. Avant d'activer les journaux d'accès aux données, nous vous recommandons de définir un cas d'utilisation clair pour les journaux supplémentaires et d'évaluer l'augmentation de vos coûts de journalisation.

Activer Security Command Center pour les résultats de failles Cloud KMS

Security Command Center génère des résultats de failles qui mettent en évidence les erreurs de configuration associées à Cloud KMS et à d'autres ressources. Nous vous recommandons d'activer Security Command Center et d'intégrer ces résultats à vos opérations de sécurité existantes. Ces résultats incluent des problèmes tels que des clés Cloud KMS accessibles au public, des projets Cloud KMS avec le rôle owner trop permissif ou des rôles IAM qui ne respectent pas la séparation des tâches.

Surveillance et correction

Nous vous recommandons de vérifier l'utilisation des clés et leur conformité avec les bonnes pratiques. Cela doit être un élément essentiel de votre stratégie de surveillance, car il s'agit d'un contrôle de détection crucial pour identifier les risques et les erreurs de configuration dans votre configuration CMEK. Suivez ces résultats, triez-les en fonction de vos procédures de sécurité et corrigez-les rapidement. Les outils suivants vous aident à identifier les problèmes que vous pouvez résoudre pour améliorer votre posture de sécurité :

• Tableau de bord Métriques de chiffrement : vous pouvez afficher les métriques de chiffrement pour voir quelles ressources sont protégées par une CMEK et dans quelle mesure ces CMEK sont conformes aux pratiques recommandées. Pour identifier les problèmes à résoudre, vous pouvez afficher des listes de ressources qui ne sont pas protégées par une clé CMEK et des listes de clés qui ne sont pas entièrement conformes aux bonnes pratiques.

• Tableau de bord Utilisation des clés : vous pouvez afficher l'utilisation des clés pour vous aider à identifier les ressources Google Cloud de votre organisation qui dépendent des clés Cloud KMS et qui sont protégées par celles-ci. Ce tableau de bord permet de surveiller l'état, l'utilisation et la disponibilité de vos versions de clés, ainsi que des ressources qu'elles protègent. Le tableau de bord identifie également les données inaccessibles en raison d'une clé désactivée ou détruite. Vous pouvez ainsi prendre des mesures telles que la suppression des données inaccessibles ou la réactivation de la clé. Les informations du tableau de bord Utilisation des clés sont également disponibles à l'aide de l'API Cloud KMS Inventory.

Nous vous recommandons d'établir un plan opérationnel pour détecter automatiquement les événements que vous jugez importants et d'examiner régulièrement le tableau de bord sur l'utilisation des clés.

Récapitulatif des bonnes pratiques

Le tableau suivant récapitule les bonnes pratiques recommandées dans ce document :

Sujet	Tâche
Choisir la création manuelle ou automatique de clés	Utilisez Cloud KMS Autokey si les caractéristiques des clés créées par Autokey répondent à vos besoins.
Projets de clés Cloud KMS	Utilisez un projet de clés centralisé pour chaque environnement. Ne créez pas de ressources Cloud KMS dans le même projet que les ressources Google Cloudprotégées par les clés.
Trousseaux de clés Cloud KMS	Créez des trousseaux de clés Cloud KMS pour chaque emplacement où vous souhaitez protéger les ressources Google Cloud.
Précision des clés	Choisissez un schéma de granularité des clés qui répond à vos besoins ou utilisez Autokey pour provisionner automatiquement les clés avec la granularité recommandée pour chaque service.
Niveau de protection	Choisissez Cloud EKM si votre matériel de clé doit être stocké en dehors de Google Cloud. Choisissez Cloud HSM à locataire unique si votre matériel de clé doit être hébergé sur des partitions dédiées sur des modules de sécurité matérielle (HSM) appartenant à Google Cloud. Choisissez Multi-tenant Cloud HSM si votre matériel de clé peut être hébergé sur des clusters de modules de sécurité matériels (HSM) appartenant à Google Cloudet partagés avec d'autres clients Google Cloud . Choisissez des clés logicielles si vos besoins ne nécessitent pas Cloud HSM ni Cloud EKM. Consultez les conseils pour sélectionner un niveau de protection.
Matériel de clé	Pour le matériel de clé hébergé sur Google Cloud, utilisez le matériel de clé généré par Google Cloudsi possible. Si vous utilisez du matériel de clé importé, mettez en œuvre des procédures et une automatisation pour limiter les risques.
Objectif et algorithme de la clé	Toutes les clés CMEK doivent utiliser l'objectif de clé symétrique ENCRYPT_DECRYPT et l'algorithme GOOGLE_SYMMETRIC_ENCRYPTION.
Période de rotation	Utilisez la rotation automatique des clés pour vous assurer que vos clés sont renouvelées selon le calendrier. Choisissez et appliquez une période de rotation qui répond à vos besoins, idéalement au moins une fois par an. Renouvelez plus fréquemment les clés pour les charges de travail sensibles.
Moindre privilège	Attribuez les rôles prédéfinis les plus limités qui permettent à vos comptes principaux d'accomplir leurs tâches. N'utilisez pas de rôles de base.
Séparation des tâches	Maintenez des autorisations distinctes pour les administrateurs de clés et les principaux qui utilisent des clés.
Privilèges de projet	Utilisez les privilèges de projet pour éviter la suppression accidentelle de vos projets clés.
Exiger des CMEK	Utilisez la contrainte constraints/gcp.restrictNonCmekServices.
Exiger une durée minimale programmée pour la destruction	Utilisez la contrainte constraints/cloudkms.minimumDestroyScheduledDuration.
Appliquer les niveaux de protection autorisés pour les clés CMEK	Utilisez la contrainte constraints/cloudkms.allowedProtectionLevels.
Activer et agréger la journalisation d'audit	Agrège les journaux d'audit des activités d'administration pour toutes les ressources de votre organisation. Déterminez si vous souhaitez activer la journalisation des opérations à l'aide de clés.
Surveiller l'utilisation des clés	Utilisez l'API Cloud KMS Inventory ou la console Google Cloud pour comprendre l'utilisation des clés. Vous pouvez également utiliser Cloud Monitoring pour définir des alertes pour les opérations sensibles, comme la programmation de la destruction d'une clé.
Activer Security Command Center pour Cloud KMS	Examinez les résultats des failles et intégrez-les à vos opérations de sécurité.
Évaluer les exigences de conformité	Examinez votre architecture Cloud KMS et comparez-la aux exigences de conformité auxquelles vous devez vous conformer.

Étapes suivantes

• Découvrez comment Cloud KMS Autokey vous permet d'utiliser plus facilement et de manière cohérente les clés CMEK.