Bonnes pratiques pour l'utilisation des clés CMEK

Cette page présente 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, destiné aux architectes cloud et aux équipes de sécurité, décrit bonnes pratiques et décisions à prendre lors de la conception de votre CMEK de l'architecture.

Ce guide suppose que vous connaissez déjà Cloud Key Management Service (Cloud KMS) et que vous avez lu la présentation détaillée de Cloud KMS.

Décisions préliminaires

Les recommandations de cette page s'adressent aux clients qui utilisent des clés CMEK pour chiffrer leurs données. Si vous ne savez pas si vous devez utiliser des CMEK créées automatiquement dans le cadre de votre stratégie de sécurité, cette section fournit une ligne directrice pour ces décisions préliminaires.

Décider d'utiliser CMEK

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

  • 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 des règles concernant les emplacements 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épart ou pour remédier aux événements de sécurité (crypto-destruction).

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

  • Enregistrez l'accès administratif et aux données 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 par défaut au repos avec des clés gérées par Google est adapté à votre cas d'utilisation. Si vous choisissez d'utiliser uniquement le chiffrement par défaut, vous pouvez empêcher en lisant ce guide.

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

Ce guide présente 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 de provisionner vous-même des clés. C'est le choix recommandé si les clés créées par Autokey répondent à toutes vos exigences.

Autokey provisionne des clés 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 la clé créée par Autokey, un service Cloud KMS l'administrateur peut modifier la période de rotation par défaut.

  • Séparation des tâches :
    • Le compte de service du service reçoit automatiquement des 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éé 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 n'ont pas accès les autorisations de chiffrement et de déchiffrement.
    • Les développeurs Autokey ne peuvent demander que la création et l'attribution de clés. Ils ne peuvent ni afficher, ni gérer les clés.
  • Spécificité de la clé ou granularité : la granularité des clés créées par Autokey varie selon le type de ressource. Pour des informations spécifiques aux services sur la précision des clés, consultez la page Services compatibles.

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

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

  • État de la version de clé:clés nouvellement créées demandées à l'aide d'Autokey sont créées en tant que version de clé primaire à l'état activé.
  • Nom du trousseau:toutes les clés créées par Autokey sont créées dans un trousseau de clés nommé autokey dans le projet Autokey dans le bucket l'emplacement. 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 ce nom. convention: PROJECT_NUMBER-SERVICE_SHORT_NAME-RANDOM_HEX
  • Exportation de clés:comme toutes les clés Cloud KMS, les clés créées par Impossible d'exporter Autokey.
  • Suivi des clés:comme toutes les clés Cloud KMS utilisées dans les CMEK des services compatibles avec le suivi des clés, les clés créés par Autokey sont suivis 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, par exemple un niveau de protection autre que HSM ou des services 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 clés que vous utiliserez et comment elles sont gérées. Ces décisions ont une incidence sur vos coûts, vos coûts opérationnels et la facilité d'implémentation de fonctionnalités telles que le chiffrement destructeur.

Les sections suivantes présentent les 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 faciliter la séparation des tâches.

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

  • Chaque dossier d'environnement comporte un projet de clé Cloud KMS géré séparément des projets d'application.
  • Les trousseaux de clés et les clés Cloud KMS sont provisionnés Projet de clé Cloud KMS. Ces clés servent à chiffrer les ressources dans les projets d'application.
  • Les stratégies IAM (Identity and Access Management) 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é Cloud KMS n'est pas le même que celui qui utilise les clés de chiffrement dans les projets d'application.

Structure de dossier et de projet Cloud KMS recommandée

Si vous utilisez Cloud KMS Autokey, chaque dossier pour lequel Autokey est 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 de déploiement Ressources Google Cloud chiffrées avec CMEK.

  • Les ressources régionales et zonales doivent utiliser un trousseau de clés et une clé CMEK dans la même région en tant que ressource ou à l'emplacement global. Régional unique et zonal les ressources ne peuvent pas utiliser un trousseau de clés multirégional autre que global.
  • Ressources multirégionales (telles qu'un ensemble de données BigQuery dans la région us multirégional) doivent utiliser un trousseau de clés et une clé CMEK dans le même emplacement multirégional ou birégional. 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 CMEK dans l'emplacement global.

L'application de clés régionales fait partie d'une stratégie de régionalisation des données. Par de clés et de trousseaux 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 la page Mettre en œuvre des exigences de souveraineté et de résidence des données.

Pour les charges de travail nécessitant une haute disponibilité ou des fonctionnalités de reprise après sinistre répartis sur plusieurs sites, il est de votre responsabilité d'évaluer charge de travail 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 à partir de us-central1 ne peut pas être recréé dans us-central2 dans un scénario de reprise après sinistre où us-central1 est indisponible. Pour limiter les risques liés à ce scénario, vous pouvez planifier le chiffrement ressource avec des clés global.

Pour en savoir plus, consultez la section Choisir le meilleur type de lieu.

Si vous utilisez Cloud KMS Autokey, les trousseaux sont créés pour vous dans le même l'emplacement des ressources que vous protégez.

Choisir une stratégie de précision clé

La précision désigne l'échelle et le champ d'application de l'utilisation prévue de chaque clé. Par exemple, une clé qui protège plusieurs ressources est considérée comme moins précise qu'une clé qui ne protège qu'une seule ressource.

Les clés Cloud KMS provisionnées manuellement pour les CMEK doivent être provisionnées 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 précises pour des ressources individuelles ou créer des clés moins précises à réutiliser entre les ressources, plus largement.

Bien qu'il n'existe pas de modèle universellement correct, considérez les points suivants les compromis de différents modèles:

Clés avec un niveau de précision élevé (une clé pour chaque utilisateur, par exemple) ressource

  • Contrôle accru pour désactiver des versions de clé en toute sécurité:désactivez ou détruisez un version de clé utilisée pour un champ d'application restreint présente moins de risques d'affecter 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 compromis par rapport à l’utilisation de clés à faible précision.
  • Coût:l'utilisation de clés précises nécessite de maintenir des versions de clé plus actives. par rapport à une stratégie qui utilise des clés avec une précision moindre. En effet, Les tarifs de Cloud KMS sont basés sur le nombre d'instances versions de clé, le choix d'une plus grande précision des clés entraîne des coûts plus élevés.
  • Coûts opérationnels : l'utilisation de clés très précises peut nécessiter des efforts administratifs 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 des agents de service afin qu'ils ne puissent utiliser que les clés appropriées. Si vous avez besoin avec une précision élevée, Autokey peut être un bon choix pour automatiser le provisionnement. Pour en savoir plus sur la clé Autokey pour chaque service, consultez Services compatibles

Clés de faible précision : par exemple, une clé pour chaque application, pour chaque région et pour chaque environnement

  • Désactivation sécurisée des versions de clé : la désactivation ou la destruction d'une version de clé utilisée pour une portée étendue nécessite plus de précautions que la désactivation ou la destruction d'une clé très précise. Vous devez vous assurer que toutes les ressources chiffrées par cette version de clé sont rechiffres 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 granularité peut augmenter l'impact potentiel d'une clé compromise par rapport à l'utilisation de clés à haute granularité.
  • Coût : l'utilisation de clés moins précises nécessite de créer moins de versions de clé, et les tarifs de Cloud KMS sont basés sur le nombre de versions de clé actives.
  • Coûts opérationnels:vous pouvez définir et pré-provisionner un nombre connu ce qui réduit les efforts nécessaires 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 est de votre responsabilité de sélectionner la protection approprié pour chaque clé, en fonction vos exigences pour les données et les charges de travail chiffrées avec une clé CMEK. Les questions suivantes peuvent vous aider dans votre évaluation :

  1. Avez-vous besoin des fonctionnalités CMEK ? Vous pouvez examiner les fonctionnalités consultez la section Choisir d'utiliser ou non des clés CMEK sur cette page.

  2. Avez-vous besoin que le matériel de clé reste dans la limite d'un module matériel de sécurité (HSM) ?

    • Si c'est le cas, passez à la question suivante.
    • Si ce n'est pas le cas, nous vous recommandons d'utiliser des clés CMEK avec des clés.

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

    • Dans ce cas, nous vous recommandons d'utiliser CMEK avec Cloud External Key Manager.
    • Si ce n'est pas le cas, nous vous recommandons d'utiliser Cloud HSM (clés intégrées au matériel).

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 du matériel de clé généré par Google dans la mesure du possible

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

Lorsque vous créez une clé, vous devez soit autoriser Cloud KMS à générer le ou importer manuellement le matériel de clé généré en dehors de Google Cloud. Lorsque c'est possible, nous vous recommandons générée. Cette option n'expose pas le matériel brut de la clé en dehors Cloud KMS et crée automatiquement des versions basées sur la clé de votre choix. Si vous avez besoin de pouvoir importer votre propre matériel de clé, nous vous recommandons d'évaluer les considérations opérationnelles et les risques suivants liés à l'approche BYOK (Bring Your Own Key) :

  • Pouvez-vous implémenter une automatisation pour importer de manière cohérente les nouvelles versions de clé ? Cela inclut à la fois les paramètres Cloud KMS pour limiter 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é. Qu'est-ce que l'impact si votre automatisation ne parvient pas à créer une nouvelle version de clé au niveau l'heure prévue ?
  • Comment comptez-vous stocker ou mettre sous séquestre de manière sécurisée le matériel de clé d'origine ?
  • Comment atténuer le risque de votre processus d'importation de clés provoquant la fuite de données le matériel de clé ?
  • 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 le matériel de clé justifie-t-il l'augmentation les coûts opérationnels et les risques ?

Choisir l'objectif et l'algorithme de clé adaptés à vos besoins

Lorsque vous créez une clé, vous devez sélectionner l'objectif et l'algorithme sous-jacent la clé. Pour les cas d'utilisation de la CMEK, seules les clés avec l'objectif ENCRYPT_DECRYPT symétrique peuvent être utilisées. Cet objectif de clé utilise toujours l'algorithme GOOGLE_SYMMETRIC_ENCRYPTION, qui utilise 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 s'appliquent automatiquement.

Pour d'autres cas d'utilisation, tels que le chiffrement côté client, consultez les objectifs et algorithmes 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 adaptée à vos besoins. La fréquence de rotation des clés dépend des exigences de vos charges de travail en fonction de leur sensibilité ou de leur conformité. Par exemple, la rotation des clés peut être requise au moins une fois par an pour répondre à certaines normes de conformité, ou vous pouvez choisir une période de rotation plus fréquente pour les charges de travail hautement sensibles.

Après la rotation d'une clé symétrique, la nouvelle version est définie comme clé primaire et est utilisé pour toutes les nouvelles demandes afin de protéger les informations. L'ancienne clé versions restent disponibles et peuvent être utilisées pour déchiffrer les données précédemment chiffrées protégées par cette version. Lors de la rotation d'une clé, les données chiffrées 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 le même ce qui permet de réduire les risques et les conséquences ou compromis.

Si vous utilisez Autokey, les clés sont créées à l'aide d'une rotation des clés par défaut sur une période 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 la 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 une autorisation pour gérer les CMEK, appliquez le 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. À la place, et attribuez-lui des rôles Cloud KMS prédéfinis les risques d'incidents de sécurité liés à des accès privilégiés.

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 recherche de failles de Security Command Center pour l'IAM.

Planifier la séparation des tâches

Gérez 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 l'officier cryptographique qui active et gère les services d'un système de gestion de clés cryptographiques et l'utilisateur qui utilise ces clés pour chiffrer ou déchiffrer des ressources.

Quand vous utilisez des CMEK pour gérer le chiffrement au repos avec des services Google Cloud, le rôle IAM permettant d'utiliser les clés de chiffrement est attribué au service l'agent du service Google Cloud, et non l'individu utilisateur. Par exemple, pour créer des objets dans un bucket Cloud Storage chiffré, user n'a besoin que du rôle IAM roles/storage.objectCreator, et l'agent de service Cloud Storage dans le 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 répertorie les rôles IAM qui sont généralement associées à quelle fonction:

Rôle IAM Description Désignation NIST SP 800-152
roles/cloudkms.admin Fournit l'accès aux ressources Cloud KMS, à l'exception de l'accès aux des types de ressources restreints et des opérations cryptographiques. Responsable du chiffrement
roles/cloudkms.cryptoKeyEncrypterDecrypter Permet d'utiliser les ressources Cloud KMS pour les opérations encrypt et decrypt uniquement. Utilisateur du système de gestion de 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 de Security Command pour Cloud KMS

Appliquer les CMEK de manière cohérente

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

Appliquer des privilèges de projet

Nous vous recommandons de protéger les projets avec des droits d'accès pour éviter toute suppression accidentelle. Lorsqu'un lien de projet est appliqué, le projet de clé Cloud KMS ne peut pas être supprimé tant que le lien n'est pas supprimé.

Exiger des clés CMEK

Nous vous recommandons d'appliquer l'utilisation des CMEK dans votre environnement à l'aide de les contraintes liées aux 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 la désactivation des clés avant destruction

Nous vous recommandons de désactiver les versions de clé avant de programmer leur destruction. Cela permet de vérifier que la clé n'est pas utilisée activement et constitue une étape importante pour déterminer s'il est possible de détruire une version de clé. Données et les ressources protégées par des CMEK ne sont pas accessibles après la clé a été désactivée ou détruite. Une version de clé à l'état "Désactivée" ne peut pas être utilisée, mais pourra être réactivée ultérieurement, si nécessaire.

Nous vous recommandons d'utiliser la contrainte de règle d'administration constraints/cloudkms.disableBeforeDestroy pour exiger qu'une clé ait été désactivée avant de pouvoir planifier sa destruction.

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

Nous vous recommandons de définir une durée minimale pour la destruction programmée. Clé la destruction est une opération irréversible qui peut entraîner une perte de données. Par par défaut, Cloud KMS applique un délai de destruction programmée de 30 jours (parfois appelée période de suppression réversible) avant que le matériel de la clé ne soit définitivement supprimé détruit. Cela laisse le temps de restaurer une clé en cas d'incident de destruction. Toutefois, une personne disposant du rôle Administrateur Cloud KMS peut créer une clé dont la durée de destruction planifiée est aussi courte que 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 pendant la création de clés.

Pour s'assurer que toutes les clés créées respectent un minimum de destruction programmée nous vous recommandons de configurer la contrainte de règle d'administration constraints/cloudkms.minimumDestroyScheduledDurations avec une période d'attente 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 avec une durée de suppression programmée inférieure à la valeur spécifiée dans la stratégie.

Appliquer les niveaux de protection autorisés pour les 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.

Utiliser constraints/cloudkms.allowedProtectionLevels pour faire en sorte que les nouvelles clés, versions de clé et jobs d'importation doivent utiliser la protection que vous autorisez.

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

Google Cloud propose différents contrôles de détection pour les clés CMEK. Les éléments suivants : qui expliquent comment activer et utiliser ces commandes pertinentes pour Cloud KMS.

Activer et agréger la journalisation d'audit

Nous vous recommandons d'agréger les journaux d'audit des activités des administrateurs Cloud KMS (ainsi que les journaux d'activités des administrateurs 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 toutes les activités liées à la création ou à la modification de ressources Cloud KMS en même temps. Pour obtenir des conseils sur la configuration de 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 clés CMEK, des volumes de journaux importants et ont un impact sur vos coûts, car chaque opération, qui utilise des CMEK créera des journaux d'accès aux données. Avant d'activer l'accès aux données des journaux, nous vous recommandons de définir un cas d'utilisation clair pour les journaux supplémentaires d'évaluer l'augmentation des coûts de journalisation.

Surveiller l'utilisation des clés

Vous pouvez consulter l'utilisation des clés avec l'API Inventory Cloud KMS pour vous aider à identifier les ressources Google Cloud de votre organisation dépendant des clés Cloud KMS et protégées par celles-ci. Ce tableau de bord peut être utilisé pour surveiller l'état, l'utilisation et la disponibilité de vos versions de clés et des ressources correspondantes qu'elles protègent. Le tableau de bord identifie également les données qui sont inaccessibles en raison d'une clé désactivée ou détruite, afin que vous puissiez prendre des mesures par exemple en supprimant définitivement les données inaccessibles ou en réactivant la clé.

Vous pouvez également utiliser Cloud Monitoring avec Cloud KMS pour définir des alertes pour des événements critiques tels que la programmation de la destruction d'une clé. Cloud Monitoring vous permet de déterminer pourquoi 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 des événements que vous considérez comme importants et vérifiez régulièrement l'utilisation de la clé tableau de bord.

Activer les résultats de failles de Security Command Center pour 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é

Les différents frameworks de conformité ont des exigences différentes en termes de chiffrement la gestion des clés. Un framework de conformité décrit généralement les principes et les objectifs généraux de la gestion des clés de chiffrement, mais n'indique pas de manière prescriptive le produit ou la configuration spécifique qui permet de respecter la conformité. Il est de votre responsabilité de comprendre les exigences de votre framework de conformité et de déterminer comment vos contrôles, y compris la gestion des clés, peuvent répondre à ces exigences.

Pour savoir comment les services Google Cloud peuvent répondre aux exigences 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:

Thème Tâche
Déterminer si vous souhaitez utiliser des clés CMEK Utilisez les CMEK si vous avez besoin de l'une des fonctionnalités 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é centralisé pour chaque environnement. Ne pas créer Ressources Cloud KMS dans le même projet les ressources protégées par les clés.
Trousseaux de clés Cloud KMS Créez des trousseaus de clés Cloud KMS pour chaque emplacement où vous souhaitez protéger des ressources Google Cloud.
Précision des clés Choisissez un modèle de précision des clés qui : ou utiliser Autokey pour provisionner automatiquement les clés avec la précision 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ériels (HSM) détenus par Google. Choisir de clés logicielles si vous n'avez pas besoin de Cloud HSM 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 code généré par Google le matériel de clé lorsque cela est possible. Si vous utilisez le matériel de clé importé, à implémenter une automatisation et des procédures pour atténuer les risques.
Objectif de la clé et algorithme Toutes les clés CMEK doivent utiliser la clé symétrique ENCRYPT_DECRYPT l'objectif et l'algorithme GOOGLE_SYMMETRIC_ENCRYPTION.
Période de rotation Utilisez la rotation automatique des clés pour assurer la rotation de vos clés programmation. Choisissez et appliquez une période de rotation qui répond à vos besoins, idéalement pas moins d'une fois par an. Utilisez une rotation plus fréquente des clés pour des charges de travail sensibles.
Moindre privilège Accordez les rôles prédéfinis les plus limités qui autorisent vos comptes principaux pour accomplir leurs tâches. N'utilisez pas de rôles de base.
Séparation des tâches Maintenir des autorisations distinctes pour les principaux administrateurs et comptes principaux qui utilisent des clés.
Liens de projet Utiliser des privilèges de projet pour empêcher la suppression accidentelle de votre clé projets.
Exiger des CMEK Utilisez la contrainte constraints/gcp.restrictNonCmekServices.
Exiger la désactivation des clés avant leur destruction Utilisez la contrainte constraints/cloudkms.disableBeforeDestroy.
Exiger une durée programmée pour la destruction minimale Utilisez les constraints/cloudkms.minimumDestroyScheduledDurations d'une contrainte.
Appliquer les niveaux de protection autorisés pour les CMEK Utilisez la contrainte constraints/cloudkms.allowedProtectionLevels.
Activer et agréger les journaux d'audit Agrégation des journaux d'audit des activités administratives pour toutes les ressources de votre organisation. Demandez-vous si vous souhaitez activer à l'aide de clés.
Surveiller l'utilisation des clés Utilisez l'API Inventory de Cloud KMS ou la console Google Cloud pour comprendre l'utilisation des clés. Vous pouvez aussi utiliser Cloud Monitoring pour définir des alertes des 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é que vous devez respecter.

Étape suivante

  • Découvrez comment Cloud KMS Autokey réduit vos d'utiliser les CMEK de manière cohérente.