Bonnes pratiques pour l'utilisation des CMEK

Cette page décrit les bonnes pratiques à suivre 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.

Décisions préliminaires

Les recommandations de cette page sont destinées aux clients qui utilisent des CMEK pour chiffrer leurs données. Si vous ne savez pas si vous devez utiliser des CMEK créées manuellement ou automatiquement dans votre stratégie de sécurité, cette section vous aidera à prendre ces décisions préliminaires.

Décider d'utiliser ou non CMEK

Nous vous recommandons d'utiliser CMEK pour chiffrer les données au repos dans les services Google Cloudsi vous avez besoin de l'une des fonctionnalités suivantes :

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

  • Contrôlez et gérez vos clés de chiffrement, y compris leur emplacement, leur niveau de protection, leur création, contrôle des accès, leur rotation, leur utilisation et leur 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, ce qui établit 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 les réglementations actuelles ou futures qui exigent l'un de ces objectifs.

Si vous n'avez pas besoin de ces fonctionnalités, évaluez si le chiffrement au repos par défaut avecGoogle-owned and managed keys convient à votre cas d'utilisation. Si vous choisissez d'utiliser uniquement le chiffrement par défaut, vous pouvez arrêter de lire ce guide.

Choisir la création manuelle ou automatique de clés

Ce guide décrit les bonnes pratiques à suivre pour les décisions que vous devez prendre lorsque vous provisionnez vous-même des CMEK. Cloud KMS Autokey prend certaines de ces décisions à votre place et automatise de nombreuses recommandations de ce guide. L'utilisation d'Autokey est plus simple que le provisionnement manuel des clés. Il s'agit de l'option recommandée si les clés créées par Autokey répondent à toutes vos exigences.

Autokey provisionne les CMEK pour vous. Les clés CMEK provisionnées par Autokey présentent les caractéristiques suivantes :

  • Niveau de protection : HSM.
  • Algorithme : AES-256 GCM.

  • Période de rotation : un an.

    Une fois qu'une clé a été créée par Autokey, un administrateur Cloud KMS peut modifier la période de rotation par rapport à la valeur par défaut.

  • Séparation des tâches :
    • Le compte de service du service se voit automatiquement accorder les autorisations de chiffrement et de déchiffrement sur la clé.
    • Les autorisations d'administrateur Cloud KMS s'appliquent comme d'habitude aux clés créées par Autokey. Les administrateurs Cloud KMS peuvent afficher, mettre à jour, activer ou désactiver, et détruire les clés créées par Autokey. Les administrateurs Cloud KMS ne disposent pas des autorisations de chiffrement et de déchiffrement.
    • Les développeurs Autokey ne peuvent demander que la création et l'attribution de clés. Il ne peut pas afficher ni gérer les clés.
  • Spécificité ou granularité des clés : les clés créées par Autokey ont une granularité qui varie selon le type de ressource. Pour obtenir des informations spécifiques aux services sur la précision des clés, consultez Services compatibles.

  • Emplacement : Autokey crée des clés au même emplacement que la ressource à protéger.

    Si vous devez créer des ressources protégées par des clés CMEK dans des emplacements où Cloud HSM n'est pas disponible, vous devez créer vos CMEK manuellement.

  • État de la version de clé : les clés nouvellement créées demandées à l'aide d'Autokey sont créées en tant que version de clé primaire à l'état activé.
  • Nommage des trousseaux de clés : toutes les clés créées par Autokey sont créées dans un trousseau de clés appelé autokey dans le projet Autokey à l'emplacement sélectionné. Les trousseaux de clés de votre projet Autokey sont créés lorsqu'un développeur Autokey demande la première clé dans un emplacement donné.
  • Nommage des clés : les clés créées par Autokey suivent la convention de nommage suivante : PROJECT_NUMBER-SERVICE_SHORT_NAME-RANDOM_HEX
  • Exportation de clés : comme toutes les clés Cloud KMS, les clés créées par Autokey ne peuvent pas être exportées.
  • Suivi des clés : comme toutes les clés Cloud KMS utilisées dans les services compatibles avec les CMEK et le suivi des clés, les clés créées par Autokey sont suivies dans le tableau de bord Cloud KMS.

Si vous avez des exigences qui ne peuvent pas être satisfaites avec les clés créées par Autokey, comme un niveau de protection autre que HSM ou des services qui ne sont pas compatibles avec Autokey, nous vous recommandons d'utiliser des CMEK créées manuellement plutôt qu'Autokey.

Concevoir votre architecture CMEK

Lorsque vous concevez une architecture CMEK, vous devez tenir compte de la configuration des clés que vous utiliserez et de la façon dont elles seront gérées. Ces décisions ont une incidence sur vos coûts, vos frais généraux opérationnels et la facilité d'implémentation de fonctionnalités telles que la suppression cryptographique.

Les sections suivantes présentent des recommandations pour chaque choix de conception.

Utiliser un projet de clé CMEK centralisé pour chaque environnement

Nous vous recommandons d'utiliser un projet de clé CMEK centralisé pour chaque dossier d'environnement. Ne créez pas de ressources chiffrées avec CMEK dans le même projet que celui dans lequel vous gérez les clés Cloud KMS. Cette approche permet d'éviter le partage de clés de chiffrement entre les environnements et de séparer les tâches.

Le schéma suivant illustre ces concepts dans la conception recommandée :

  • Chaque dossier d'environnement possède un projet de clé Cloud KMS géré séparément des projets d'application.
  • Les trousseaux et les clés Cloud KMS sont provisionnés dans le projet de clé Cloud KMS. Ces clés sont utilisées pour chiffrer les ressources dans les projets d'application.
  • Les stratégies Identity and Access Management (IAM) sont appliquées aux projets ou aux dossiers pour permettre la séparation des tâches. Le principal qui gère les clés Cloud KMS dans le projet de clés Cloud KMS n'est pas le même que celui qui utilise les clés de chiffrement dans les projets d'application.

Structure recommandée pour les dossiers et projets Cloud KMS

Si vous utilisez Cloud KMS Autokey, chaque dossier pour lequel Autokey est activé doit disposer d'un projet de clé Cloud KMS dédié.

Créer des trousseaux de clés Cloud KMS pour chaque emplacement

Vous devez créer des trousseaux de clés Cloud KMS dans les emplacements où vous déployez des ressourcesGoogle Cloud chiffrées avec CMEK.

  • Les ressources régionales et zonales doivent utiliser un trousseau de clés et CMEK dans la même région que la ressource ou à l'emplacement global. Les ressources régionales et zonales ne peuvent pas utiliser un 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é CMEK dans la même région multirégionale ou birégionale. Les ressources multirégionales ne peuvent pas utiliser de trousseau de clés régional.
  • Les ressources globales doivent utiliser un trousseau de clés et une clé CMEK dans l'emplacement global.

L'application des clés régionales fait partie d'une stratégie de régionalisation des données. 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 les charges de travail qui nécessitent des capacités de haute disponibilité ou de reprise après sinistre dans plusieurs régions, il vous incombe d'évaluer si votre charge de travail est résiliente en cas d'indisponibilité de Cloud KMS dans une région donnée. Par exemple, un disque persistant Compute Engine chiffré avec une clé Cloud KMS de la région A ne peut pas être recréé dans la région B en cas de reprise après sinistre où la région A n'est pas disponible. Pour atténuer le risque lié à ce scénario, vous pouvez prévoir le chiffrement d'une ressource avec des clés global.

Pour en savoir plus, consultez Choisir le meilleur type d'emplacement.

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.

Les clés Cloud KMS provisionnées manuellement pour CMEK doivent être provisionnées à l'avance avant de créer une ressource qui sera chiffrée avec la clé, comme un disque persistant Compute Engine. Vous pouvez choisir de créer des clés très précises pour des ressources individuelles ou des clés moins précises à réutiliser plus largement entre les ressources.

En général, nous recommandons la stratégie de granularité suivante :

  • Chaque clé protège les ressources d'un seul emplacement, par exemple us-central1.
  • Chaque clé protège les ressources d'un seul service ou produit (BigQuery, par exemple).
  • Chaque clé protège les ressources d'un seul projet Google Cloud .

Cette recommandation n'est peut-être pas la stratégie de précision idéale pour votre organisation. 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.

Si vous souhaitez suivre une autre stratégie de précision, tenez compte des compromis suivants entre les différents modèles :

Clés à haute précision : par exemple, une clé pour chaque ressource individuelle

  • Plus de contrôle pour désactiver les versions de clé de manière sécurisée : la désactivation ou la destruction d'une version de clé utilisée pour une portée limitée présente moins de risques d'affecter d'autres ressources que la désactivation ou la destruction d'une clé partagée. Cela signifie également que l'utilisation de clés très précises permet de réduire l'impact potentiel d'une clé compromise par rapport à l'utilisation de clés peu précises.
  • Coût : l'utilisation de clés précises nécessite de maintenir plus de versions de clés actives que si vous utilisiez une stratégie avec des clés moins précises. Étant donné que les tarifs de Cloud KMS sont basés sur le nombre de versions de clé actives, choisir une granularité de clé plus élevée entraîne des coûts plus élevés.
  • Surcharge opérationnelle : l'utilisation de clés très précises peut nécessiter un effort administratif ou des outils d'automatisation supplémentaires pour provisionner un grand nombre de ressources Cloud KMS et gérer les contrôles d'accès pour les agents de service afin qu'ils ne puissent utiliser que les clés appropriées. Si vous avez besoin de clés très précises, Autokey peut être un bon choix pour automatiser le provisionnement. Pour en savoir plus sur la précision des clés Autokey pour chaque service, consultez Services compatibles.

Clés à faible granularité : par exemple, une clé pour chaque application, pour chaque région et pour chaque environnement :

  • Désactiver des versions de clé de manière sécurisée nécessite de la prudence : désactiver ou détruire une version de clé utilisée pour un champ d'application étendu nécessite plus de prudence que désactiver ou détruire une clé très précise. Vous devez vous assurer que toutes les ressources chiffrées par cette version de clé sont rechiffrées de manière sécurisée avec une nouvelle version de clé avant de désactiver l'ancienne version de clé. Pour de nombreux types de ressources, vous pouvez afficher l'utilisation des clés pour identifier où une clé a été utilisée. Cela signifie également que l'utilisation de clés à faible niveau de précision peut augmenter l'impact potentiel d'une clé compromise par rapport à l'utilisation de clés à haut niveau de précision.
  • Coût : l'utilisation de clés moins précises nécessite la création d'un nombre moins important de versions de clé. Or, les tarifs de Cloud KMS sont basés sur le nombre de versions de clé actives.
  • Frais opérationnels : vous pouvez définir et provisionner à l'avance un nombre connu de clés, ce qui nécessite moins d'efforts pour garantir des contrôles d'accès approprié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 besoin de l'une des fonctionnalités CMEK ? Vous pouvez consulter les fonctionnalités listées sur la page Déterminer si vous devez utiliser CMEK.

  2. 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, passez à la question suivante.
    • Si ce n'est pas le cas, nous vous recommandons d'utiliser CMEK avec des clés logicielles.

  3. Souhaitez-vous que le matériel de clé soit stocké en dehors de Google Cloud ?

Autokey n'est compatible qu'avec le niveau de protection HSM. Si vous avez besoin d'autres niveaux de protection, vous devez provisionner les clés vous-même.

Utiliser le matériel de clé généré par Google Cloud, si possible

Cette section ne s'applique pas aux clés Cloud EKM.

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é généré en dehors de Google Cloud. Dans la mesure du possible, nous vous recommandons de choisir l'option générée. Cette option n'expose pas le matériel de clé brut en dehors de Cloud KMS et crée automatiquement des versions de clé en fonction de la période de rotation de clé que vous choisissez. Si vous avez besoin d'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 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 pouvez-vous atténuer le risque de fuite du contenu brut de la clé lors de l'importation de clés ?
  • Quel serait l'impact de la réimportation d'une clé précédemment détruite, car le matériel de clé brut 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 la bonne finalité et le bon algorithme de clé en fonction de vos besoins

Lorsque vous créez une clé, vous devez sélectionner son objectif et son algorithme sous-jacent. Pour les cas d'utilisation CMEK, seules les clés avec l'objectif symétrique ENCRYPT_DECRYPT peuvent être utilisées. Cette finalité de clé utilise toujours l'algorithme GOOGLE_SYMMETRIC_ENCRYPTION, qui emploie des clés AES-256 (Advanced Encryption Standard, 256 bits) en mode GCM (Galois Counter Mode), complétées avec des métadonnées internes de Cloud KMS. Lorsque vous utilisez Autokey, ces paramètres sont automatiquement appliqués pour vous.

Pour d'autres cas d'utilisation, comme le chiffrement côté client, consultez les algorithmes et objectifs de clé disponibles pour choisir l'option la plus adaptée à votre cas d'utilisation.

Choisir une période de rotation

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 fonction de la sensibilité ou de la 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.

Après la rotation d'une clé symétrique, la nouvelle version est marquée comme version principale et est utilisée pour toutes les nouvelles requêtes visant à protéger les informations. Les anciennes versions de clé restent disponibles pour déchiffrer les données précédemment chiffrées avec cette version. Lors de la rotation d'une clé, les données chiffrées avec les versions de clé précédentes ne sont pas automatiquement rechiffrées.

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.

Si vous utilisez Autokey, les clés sont créées avec une période de rotation des clés par défaut d'un an. Vous pouvez modifier la période de rotation des clés après leur création.

Appliquer des contrôles d'accès appropriés

Nous vous recommandons de tenir compte des principes du moindre privilège et de séparation des tâches lorsque vous planifiez les contrôles d'accès. Les sections suivantes présentent ces recommandations.

Appliquer le principe du moindre privilège

Lorsque vous attribuez des autorisations pour gérer les CMEK, tenez compte du principe du moindre privilège et n'accordez que les autorisations minimales nécessaires pour effectuer une tâche. Nous vous recommandons vivement d'éviter d'utiliser des rôles de base. Attribuez plutôt 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é.

Les cas de non-respect de ce principe et les problèmes associés peuvent être détectés automatiquement par les résultats de Security Command Center concernant les failles de sécurité pour IAM.

Planifier la séparation des tâches

Maintenez des identités et des autorisations distinctes pour les personnes qui administrent vos clés de chiffrement et celles qui les utilisent. La norme NIST SP 800-152 définit une séparation des tâches entre le responsable du chiffrement qui active et gère les services d'un système de gestion de clé cryptographique, et un utilisateur qui utilise ces clés pour chiffrer ou déchiffrer des ressources.

Lorsque vous utilisez CMEK pour gérer le chiffrement au repos avec les services Google Cloud , le rôle IAM permettant d'utiliser les clés de chiffrement est attribué à l'agent de service du service Google Cloud , et non à l'utilisateur individuel. Par exemple, pour créer des objets dans un bucket Cloud Storage chiffré, un utilisateur n'a besoin que du rôle IAM roles/storage.objectCreator, et l'agent de service Cloud Storage du même projet (comme service-PROJECT_NUMBER@gs-project-accounts.iam.gserviceaccount.com) a besoin du rôle IAM roles/cloudkms.cryptoKeyEncrypterDecrypter.

Le tableau suivant indique les rôles IAM généralement associés à chaque fonction :

Rôle IAM Description Désignation NIST SP 800-152
roles/cloudkms.admin Fournit l'accès aux ressources Cloud KMS, à l'exception des types de ressources et des opérations de chiffrement soumis à restriction. Responsable du chiffrement
roles/cloudkms.cryptoKeyEncrypterDecrypter Permet d'utiliser les ressources Cloud KMS pour les opérations encrypt et decrypt seulement. Utilisateur du système de gestion des clés cryptographiques
roles/cloudkms.viewer Active les opérations get et list. Administrateur audit
Les cas de non-respect de ce principe et les problèmes associés peuvent être détectés automatiquement par les résultats de failles Security Command Center pour Cloud KMS.

Appliquer les CMEK de manière cohérente

Les sections suivantes décrivent des contrôles supplémentaires permettant de réduire les risques tels que l'utilisation incohérente des clés, ou la suppression ou la destruction accidentelles.

Appliquer les privilèges de projet

Nous vous recommandons de protéger les projets à l'aide de privilèges pour éviter toute suppression accidentelle. Lorsqu'un privilège de projet est appliqué, la suppression du projet de clé Cloud KMS est bloquée jusqu'à ce que le privilège soit supprimé.

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. 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éversible. Cela vous laisse le temps de restaurer une clé en cas de destruction accidentelle. Toutefois, il est possible qu'une personne disposant du rôle Administrateur Cloud KMS crée une clé avec une durée de destruction planifiée de seulement 24 heures, ce qui peut ne pas vous laisser suffisamment de temps pour détecter un problème et restaurer la clé. La durée Programmé pour destruction 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 cryptographiques 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ée pour destruction.

Pour vous assurer que toutes les clés créées respectent une durée minimale de suppression programmée, 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 de manière cohérente vos exigences concernant les niveaux de protection des clés 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

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

Activer et agréger la journalisation d'audit

Nous vous recommandons d'agréger les journaux d'audit des activités d'administration Cloud KMS (ainsi que les journaux d'audit des activités d'administration pour tous les services) 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 des 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 enregistrer 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.

Surveiller l'utilisation des clés

Vous pouvez afficher l'utilisation des clés avec l'API Cloud KMS Inventory pour vous aider à identifier les ressources Google Cloud de votre organisation qui dépendent des clés Cloud KMS et 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é et des ressources correspondantes 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é.

Vous pouvez utiliser Cloud Monitoring avec Cloud KMS pour configurer des alertes pour les événements critiques, comme la programmation de la destruction d'une clé. Cloud Monitoring vous permet de trier les raisons pour lesquelles une telle opération a été effectuée et de déclencher un processus en aval facultatif pour restaurer la clé si nécessaire.

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.

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.

Évaluer vos exigences de conformité

Différents cadres de conformité ont des exigences différentes en matière de chiffrement et de gestion des clés. Un framework 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 répondre à ces exigences.

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

Récapitulatif des bonnes pratiques

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

Sujet Tâche
Décider d'utiliser ou non CMEK Utilisez CMEK si vous avez besoin de l'une des fonctionnalités activées par CMEK.
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 la clé automatique 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 si votre matériel de clé peut être hébergé sur des modules de sécurité matérielle (HSM) appartenant à 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 Cloud, si 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 alternées selon un 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 des 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 de l'analyse 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.