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 Cloud de Confiance . Ce guide s'adresse aux architectes cloud et aux équipes de sécurité. Il présente les bonnes pratiques et les décisions que vous devez prendre lorsque vous concevez votre architecture CMEK.

Ce guide part du principe que vous connaissez déjà Cloud Key Management Service (Cloud KMS) et les clés de chiffrement gérées par le client.

Décider d'utiliser ou non CMEK

Nous vous recommandons d'utiliser CMEK pour chiffrer les données au repos dans les services Cloud de Confiancesi 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 Cloud de Confiance.

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

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

  • Créez et utilisez des clés propres à un client, 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 par défaut au repos avec Google Cloud-powered 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.

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 le chiffrement et la suppression des données.

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

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

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 utilisées pour les 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 vous recommandons la stratégie de précision 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 Cloud de Confiance .

Cette recommandation n'est peut-être pas la stratégie de granularité 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.

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 pour une stratégie qui utilise des clés moins précises. Une granularité de clé plus élevée nécessite un plus grand nombre de versions de clé actives, ce qui entraîne des coûts supplémentaires.
  • Frais opérationnels : 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.

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é. 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 de moins de versions de clé, ce qui entraîne des coûts moins élevés.
  • Frais opérationnels : vous pouvez définir et préprovisionner 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.

    • Si c'est le cas, passez à la question suivante.
    • Dans le cas contraire, nous vous recommandons d'utiliser le chiffrement par défaut S3NS .
  2. Avez-vous besoin d'une certification FIPS 140-2 de niveau 2 ou 3, ou que le matériel de clé soit stocké en dehors de Cloud de Confiance ?

Utiliser le matériel de clé généré par Cloud de Confiancesi 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 Cloud de Confiance. 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é brute a été conservé en dehors de Cloud de Confiance ?
  • L'avantage d'importer vous-même le matériel de clé justifie-t-il l'augmentation de la charge opérationnelle et du risque ?

Choisir 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 demandes de protection des informations. Les anciennes versions de clé restent disponibles pour déchiffrer les données précédemment chiffrées et protégé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.

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

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 de la cryptographie 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 Cloud de Confiance , le rôle IAM permettant d'utiliser les clés de chiffrement est attribué à l'agent de service du service Cloud de Confiance , 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.s3ns-system.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 restreints. 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

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 leur suppression ou 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 de 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 la destruction.

Pour vous assurer que toutes les clés créées respectent une durée minimale de destruction planifié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 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

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

É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 Cloud de Confiance peuvent vous aider à répondre aux exigences des différents cadres de conformité, consultez la ressource suivante :

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.
Projets de clés Cloud KMS Utilisez un projet de clés centralisé pour chaque environnement. Ne créez pas de ressources Cloud KMS dans le même projet que les ressources Cloud de Confianceprotégées par les clés.
Trousseaux de clés Cloud KMS Créez des trousseaux de clés Cloud KMS pour chaque emplacement où vous souhaitez protéger les ressources Cloud de Confiance.
Précision des clés Choisissez un modèle de granularité des clés qui répond à vos besoins en termes de tolérance au risque, de coût et de charge opérationnelle.
Niveau de protection Choisissez Cloud EKM si votre matériel de clé doit être stocké en dehors de Cloud de Confiance ou si vous avez besoin d'une certification FIPS 140-2 de niveau 2 ou 3. Sinon, choisissez les clés logicielles. Consultez les conseils pour sélectionner un niveau de protection.
Matériel de clé Pour le matériel de clé hébergé sur Cloud de Confiance, utilisez le matériel de clé généré par Cloud de Confiance, 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 CMEK Utilisez la contrainte constraints/cloudkms.allowedProtectionLevels.
Activer et agréger la journalisation d'audit Agrège les journaux d'audit des activités d'administration pour toutes les ressources de votre organisation. Déterminez si vous souhaitez activer la journalisation des opérations à l'aide de clés.
Évaluer les exigences de conformité Examinez votre architecture Cloud KMS et comparez-la aux exigences de conformité auxquelles vous devez vous conformer.