Bonnes pratiques pour l'utilisation des CMEK

Cette page présente les bonnes pratiques à suivre pour configurer le chiffrement au repos à l'aide de 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 décrit les bonnes pratiques et les décisions que vous devez prendre lors de la conception de votre architecture CMEK.

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 clés CMEK créées manuellement ou automatiquement dans le cadre de votre stratégie de sécurité, cette section vous fournit des conseils pour ces décisions préliminaires.

Décider d'utiliser CMEK

Nous vous recommandons d'utiliser CMEK pour chiffrer les données au repos dans les services 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 de n'utiliser que 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 présente les bonnes pratiques à suivre pour les décisions que vous devez prendre lorsque vous provisionnez vous-même des clés 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 les 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 qu'une clé a été créée par Autokey, un administrateur Cloud KMS peut modifier la période de rotation à partir de la valeur 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éé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 d'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é de la clé ou granularité:la granularité des clés créées par Autokey varie selon le type de ressource. Pour en savoir plus sur la granularité des clés spécifique à un service, consultez la section 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 CMEK dans des emplacements où Cloud HSM n'est pas disponible, vous devez créer votre CMEK manuellement.

• État de la version de clé:les clés créées à l'aide d'Autokey sont créées en tant que version de clé principale et sont activées.
• Nom du trousseau 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é.
• Nom des clés:les clés créées par Autokey suivent cette convention d'attribution de nom: 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 intégrés CMEK compatibles avec 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 par 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 clés 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 manière dont 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 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 faciliter la séparation des tâches.

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

• Chaque dossier d'environnement comporte 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 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.

Si vous utilisez Autokey Cloud KMS, 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 ressources Google Cloud chiffrées avec CMEK.

• Les ressources régionales et zonales doivent utiliser un trousseau de clés et un 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 (telles qu'un ensemble de données BigQuery dans la région multirégionale us) doivent utiliser un trousseau de clés et un 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 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 appliquant 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 la page Mettre en œuvre des exigences de souveraineté et de résidence des données.

Pour les charges de travail qui nécessitent une haute disponibilité ou des fonctionnalités de reprise après sinistre dans plusieurs emplacements, il vous incombe d'évaluer si votre charge de travail est résiliente en cas de non-disponibilité 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 atténuer le risque de ce scénario, vous pouvez planifier 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 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 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 pour les ressources de manière plus générale.

Bien qu'il n'existe pas de modèle universellement correct, tenez compte des compromis suivants entre les différents modèles:

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

• Contrôle plus strict pour désactiver en toute sécurité les versions de clé:la désactivation ou la destruction d'une version de clé utilisée pour un champ d'application restreint présente un risque moindre 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 à faible granularité.
• Coût:l'utilisation de clés précises nécessite de gérer davantage de versions de clés actives par rapport à une stratégie qui utilise 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.
• 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 de clés à forte granularité, Autokey peut être un bon choix pour automatiser le provisionnement. Pour en savoir plus sur la granularité des clés Autokey pour chaque service, consultez la section Services compatibles.

Clés à faible granularité : 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.
• Surcharge opérationnelle:vous pouvez définir et préprovisionner un nombre connu de clés, avec moins d'efforts pour assurer 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 dans la section Décider d'utiliser CMEK de cette page.

   • Si c'est le cas, passez à la question suivante.
   • Si ce n'est pas le cas, nous vous recommandons d'utiliser le chiffrement par défaut de Google.

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

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

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.
   • Dans le cas contraire, nous vous recommandons d'utiliser CMEK avec Cloud HSM (clés avec support 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 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 de nouvelles versions de clé en fonction de la période de rotation de clé que vous choisissez. 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é. Quel est l'impact si votre automatisation ne parvient pas à créer une nouvelle version de clé au moment prévu ?
• Comment comptez-vous stocker ou mettre en séquestre de manière sécurisée le matériel de clé d'origine ?
• Comment pouvez-vous atténuer le risque que votre processus d'importation de clés fuite le matériel de clé brut ?
• 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 des coûts opérationnels et des risques ?

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

Lorsque vous créez une clé, vous devez sélectionner son objectif et son algorithme sous-jacent. 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 paramètres sont automatiquement appliqués.

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 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é, ou vous pouvez choisir une période de rotation plus fréquente pour les charges de travail hautement sensibles.

Après avoir effectué la rotation d'une clé symétrique, la nouvelle version est marquée comme version de clé 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 chiffrées précédemment protégées par 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 permet de réduire le risque et les conséquences d'une compromission de clé.

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

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 détection des 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é cryptographique et l'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 des 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 [e-mail]) 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 un accès aux ressources Cloud KMS, à l'exception des types de ressources et des opérations cryptographiques soumis à des restrictions.	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 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 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 les liens 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 de CMEK à l'ensemble de 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 programmée pour la destruction minimale

Nous vous recommandons de définir une durée minimale de destruction planifiée. La destruction de clé est une opération irréversible pouvant entraîner une perte de données. Par défaut, Cloud KMS utilise une durée de destruction programmée (parfois appelée période de suppression réversible) de 30 jours avant que le matériel de la clé ne soit détruit de manière irrécupérable. Cela permet de disposer d'un certain temps pour 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é 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 destruction planifié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 les 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 restore avant la fin de la période de destruction programmée.

Pour vous assurer que toutes les clés créées respectent une durée minimale de destruction 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 votre durée préférée. 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 l'ensemble de votre environnement à l'aide de contraintes de règles d'administration.

Utilisez constraints/cloudkms.allowedProtectionLevels pour exiger que les nouvelles clés, versions de clé et tâches d'importation doivent utiliser les niveaux de 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 sections suivantes 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 la section 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ée 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 consulter l'utilisation des clés avec l'API d'inventaire Cloud KMS pour vous aider à identifier les ressources Google Cloud de votre organisation qui dépendent de clés Cloud KMS et qui sont protégées par elles. 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 inaccessibles en raison d'une clé désactivée ou détruite afin que vous puissiez prendre des mesures telles que purger les données inaccessibles ou réactiver la clé.

Vous pouvez également utiliser Cloud Monitoring avec Cloud KMS pour définir des alertes pour les événements critiques, tels que 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 les événements que vous jugez importants et d'examiner régulièrement le tableau de bord des principaux usages.

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é

Les différents frameworks 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 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 vous aider à respecter les exigences de différents frameworks de conformité, consultez les ressources suivantes:

• Ressources sur la conformité cloud et les réglementations

• Guide d'implémentation du programme FedRAMP sur Google Cloud

• Conformité avec la norme de sécurité des données PCI

• Protéger les données de santé sur Google Cloud

Récapitulatif des bonnes pratiques

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

Thème	Tâche
Décider d'utiliser 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é centralisé pour chaque environnement. Ne créez pas de ressources Cloud KMS dans le même projet que les ressources Google Cloud que les clés protègent.
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 granularité des clés qui répond à vos besoins, ou utilisez Autokey pour provisionner automatiquement des 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ériels (HSM) détenus par Google. 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 lorsque cela est possible. Si vous utilisez du matériel de clé importé, implémentez des procédures et des automatisations pour atténuer 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 qu'elles sont remplacé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. Utilisez une rotation des clés plus fréquente pour les charges de travail sensibles.
Moindre privilège	Accordez les rôles prédéfinis les plus limités qui permettent à vos comptes principaux d'effectuer leurs tâches. N'utilisez pas de rôles de base.
Séparation des tâches	Gérez des autorisations distinctes pour les administrateurs de clés et les principaux qui utilisent des clés.
Liens 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 programmée pour la destruction minimale	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égation des journaux d'audit des activités administratives 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 d'inventaire Cloud KMS ou la console Google Cloud pour comprendre l'utilisation des clés. Vous pouvez également utiliser Cloud Monitoring pour définir des alertes pour des opérations sensibles, comme 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 les efforts nécessaires pour utiliser le chiffrement CMEK de manière cohérente.