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 Cloud de Confiance . 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 part du principe que vous connaissez déjà Cloud Key Management Service (Cloud KMS) et les clés de chiffrement gérées par le client.

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 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 Cloud de Confiance.

• 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 Cloud de Confiance 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 Cloud de Confiance
• Centre de ressources pour la conformité

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 Cloud de Confiance. 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 Cloud de Confiance ?

• 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 projetCloud de Confiance 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.

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".
• 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.
• 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. Toutefois, l'application de la séparation des tâches peut nécessiter une configuration plus minutieuse.
• Les développeurs ont besoin de privilèges Cloud KMS élevés sur le projet de ressources pour pouvoir créer et gérer des clés.

Appliquer la séparation des tâches

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.	Chiffreur/Déchiffreur de CryptoKeys Cloud KMS (roles/cloudkms.cryptoKeyEncrypterDecrypter)	Chiffrez et déchiffrez les données à l'aide de la clé.

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.

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

Vous devez créer des trousseaux de clés Cloud KMS aux emplacements où vous prévoyez de déployer Cloud de Confiance des ressources chiffrées avec 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 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 Cloud de Confiance.

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.

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 Cloud de Confiance .
• 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.

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. * Si vous souhaitez que votre matériel de clé soit stocké en dehors de Cloud de Confiance, utilisez des clés Cloud EKM. Nous vous recommandons le niveau de protection EXTERNAL_VPC pour une meilleure disponibilité. * Si vous n'êtes pas tenu de stocker votre matériel clé en dehors de Cloud de Confiance, nous vous recommandons d'utiliser 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 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.

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

Cloud de Confiance 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.

Récapitulatif des bonnes pratiques

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

Sujet	Tâche
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 Cloud de Confianceproté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 Cloud de Confiance.
Précision des clés	Choisissez un modèle de granularité des clés qui répond à vos besoins en termes de tolérance au risque, de coût et de charge opérationnelle.
Niveau de protection	Choisissez Cloud EKM si votre matériel de clé doit être stocké en dehors de Cloud de Confiance ou si vous avez besoin d'une certification FIPS 140-2 de niveau 2 ou 3. Sinon, choisissez les clés logicielles. Consultez les conseils pour sélectionner un niveau de protection.
Matériel de clé	Pour le matériel de clé hébergé sur Cloud de Confiance, utilisez le matériel de clé généré par Cloud de Confiancesi 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.
Évaluer les exigences de conformité	Examinez votre architecture Cloud KMS et comparez-la aux exigences de conformité auxquelles vous devez vous conformer.