La fonctionnalité de clé automatique Cloud KMS simplifie la création et l'utilisation des clés de chiffrement gérées par le client (CMEK) en automatisant le provisionnement et l'attribution. Avec Autokey, les trousseaux de clés et les clés sont générés à la demande. Les comptes de service qui utilisent les clés pour chiffrer et déchiffrer les ressources sont créés et se voient attribuer des rôles IAM (Identity and Access Management) si nécessaire. Les administrateurs Cloud KMS conservent un contrôle et une visibilité complets sur les clés créées par Autokey, sans qu'il soit nécessaire de planifier et de créer chaque ressource à l'avance. 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.
L'utilisation de clés générées par la fonction de clé automatique peut vous aider à vous conformer aux normes du secteur et aux pratiques recommandées en matière de sécurité des données, y compris le niveau de protection Cloud HSM multitenant, la séparation des tâches, la rotation des clés, l'emplacement et la spécificité des clés. La fonctionnalité de clé automatique crée des clés qui suivent les consignes générales et celles spécifiques au type de ressource pour les servicesCloud de Confiance qui s'intègrent à Cloud KMS Autokey. Une fois créées, les clés demandées à l'aide d'Autokey fonctionnent de la même manière que les autres clés Cloud HSM avec les mêmes paramètres.
Autokey peut également simplifier l'utilisation de Terraform pour la gestion des clés, en supprimant la nécessité d'exécuter l'infrastructure en tant que code avec des droits d'accès élevés pour la création de clés.
Vous pouvez utiliser Autokey avec le stockage des clés dans un projet dédié (anciennement appelé gestion centralisée des clés) ou avec le stockage des clés dans le même projet (anciennement appelé gestion déléguée des clés). Pour utiliser Autokey avec le stockage de clés dans un projet dédié, vous devez disposer d'une ressource d'organisation contenant une ressource de dossier. Lorsque vous utilisez le stockage de clés dans un projet dédié, vous activez Autokey pour les projets d'un dossier. Les clés créées par Autokey sont alors créées dans le projet de clés désigné pour ce dossier. Lorsque vous utilisez le stockage des clés dans le même projet, vous activez Autokey sur un dossier ou un projet pour permettre à Autokey de créer des clés dans le même projet que les ressources qu'elles protègent.
Pour en savoir plus sur les ressources d'organisation et de dossier, consultez Hiérarchie des ressources.
Cloud KMS Autokey est disponible dans tous les emplacements Cloud de Confiance où Cloud HSM est disponible. Pour en savoir plus sur les emplacements Cloud KMS, consultez Emplacements Cloud KMS. L'utilisation d'Autokey Cloud KMS n'entraîne aucun coût supplémentaire. Les clés créées à l'aide d'Autokey sont facturées au même prix que les autres clés Cloud HSM. Pour en savoir plus sur les tarifs, consultez Tarifs de Cloud Key Management Service.
Fonctionnement d'Autokey
Cette section explique le fonctionnement de Cloud KMS Autokey. Les rôles utilisateur suivants participent à ce processus :
- Administrateur
- L'administrateur est un utilisateur responsable de la gestion de la sécurité au niveau du dossier ou de l'organisation.nk
- Développeur Autokey
- Le développeur Autokey est un utilisateur responsable de la création de ressources à l'aide de Cloud KMS Autokey.
- Administrateur Cloud KMS
- L'administrateur Cloud KMS est un utilisateur responsable de la gestion des ressources Cloud KMS. Ce rôle a moins de responsabilités lorsqu'il utilise Autokey que lorsqu'il utilise des clés créées manuellement.
Les agents de service suivants participent également à ce processus :
- Agent de service Cloud KMS
- Agent de service pour Cloud KMS dans un projet de clé donné. La fonctionnalité de clé automatique dépend de cet agent de service qui dispose de droits d'accès élevés pour créer des clés et des trousseaux de clés Cloud KMS, et pour définir une règle IAM sur les clés, en accordant des autorisations de chiffrement et de déchiffrement pour chaque agent de service de ressource.
- Agent de service de ressources
- L'agent de service pour un service donné dans un projet de ressources donné. Cet agent de service doit disposer des autorisations de chiffrement et de déchiffrement pour toute clé Cloud KMS avant de pouvoir l'utiliser pour la protection CMEK d'une ressource. Autokey crée l'agent de service de ressources si nécessaire et lui accorde les autorisations nécessaires pour utiliser la clé Cloud KMS.
L'administrateur active Cloud KMS Autokey
Pour activer Autokey, choisissez l'un des chemins suivants en fonction du modèle de stockage de clés choisi :
- Stockage des clés dans un projet dédié : activez le stockage des clés dans un projet dédié pour un dossier. Vous désignez un projet de clé dédié pour contenir les clés qui protègent les ressources créées dans d'autres projets du dossier.
- Stockage des clés dans le même projet : activez le stockage des clés dans le même projet pour des projets individuels ou pour tous les projets d'un dossier afin de créer des clés dans le même projet que les ressources qu'elles protègent.
Activer le stockage des clés dans un projet dédié
Avant de pouvoir utiliser Autokey avec le stockage de clés dans un projet dédié dans un dossier, un administrateur doit effectuer les tâches de configuration ponctuelles suivantes :
Activez Autokey avec le stockage de clés dans un projet dédié au niveau du dossier, puis identifiez le projet Cloud KMS qui contiendra les ressources Autokey pour ce dossier.
Créez l'agent de service Cloud KMS, puis accordez-lui les droits de création et d'attribution de clés.
Une fois cette configuration terminée, les développeurs qui peuvent créer des ressources compatibles avec Autokey dans n'importe quel projet de ce dossier peuvent désormais déclencher la création de clés Multi-tenant Cloud HSM à la demande. Pour obtenir des instructions de configuration complètes pour Cloud KMS Autokey, consultez Activer Cloud KMS Autokey.
Activer Autokey avec le stockage des clés dans le même projet
Avant de pouvoir utiliser Autokey avec le stockage de clés dans le même projet, un administrateur doit effectuer les tâches de configuration ponctuelles suivantes :
- Activez Autokey avec le stockage des clés dans le même projet sur un projet ou un dossier.
- Activez l'API Cloud KMS sur ce projet ou sur les projets du dossier.
Lorsque vous activez Autokey avec le stockage des clés dans le même projet, l'agent de service Cloud KMS est créé pour vous si nécessaire. Vous n'avez pas besoin de créer manuellement l'agent de service. Tout utilisateur disposant des autorisations nécessaires pour créer une ressource compatible avec Autokey peut demander une nouvelle clé à la demande. Pour obtenir des instructions de configuration complètes pour Cloud KMS Autokey, consultez Activer Cloud KMS Autokey.
Les développeurs Autokey utilisent Cloud KMS Autokey
Une fois Autokey activé pour un projet, les développeurs Autokey peuvent créer des ressources protégées à l'aide de clés créées pour eux à la demande. Cela s'applique à la fois aux projets d'un dossier dans lequel Autokey avec stockage des clés dans un projet dédié est activé et aux projets dans lesquels Autokey avec stockage des clés dans le même projet est activé. Les détails du processus de création de ressources dépendent de la ressource que vous créez, mais le processus suit ce flux :
Le développeur Autokey commence à créer une ressource dans un serviceCloud de Confiance compatible. Lors de la création de la ressource, le développeur demande une nouvelle clé à l'agent de service Autokey.
L'agent de service Autokey reçoit la demande du développeur et effectue les étapes suivantes :
- Crée un trousseau de clés dans le projet à l'emplacement sélectionné, sauf si ce trousseau de clés existe déjà.
- Créez une clé dans le trousseau de clés avec la précision appropriée pour le type de ressource, sauf si une telle clé existe déjà.
- Créez le compte de service par projet et par service, sauf s'il existe déjà.
- Accordez au compte de service par projet et par service les autorisations de chiffrement et de déchiffrement sur la clé.
- Fournissez les informations clés au développeur pour qu'il puisse terminer de créer la ressource.
Une fois que l'agent du service Autokey a renvoyé les détails de la clé, le développeur peut immédiatement terminer de créer la ressource protégée.
Cloud KMS Autokey crée des clés qui possèdent les attributs décrits dans la section suivante. Ce flux de création de clés préserve la séparation des tâches. L'administrateur Cloud KMS conserve une visibilité et un contrôle complets sur les clés créées par la clé automatique.
Pour commencer à utiliser Autokey après l'avoir activé, consultez Créer des ressources protégées à l'aide de Cloud KMS Autokey.
À propos des clés créées par Autokey
Les clés créées par Cloud KMS Autokey présentent les attributs suivants :
- 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. Ils ne peuvent 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 en savoir plus sur la précision des clés pour chaque service, consultez Services compatibles sur cette page.
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. 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é. Le trousseau de clésautokeyest créé dans le projet de clé désigné si vous utilisez le stockage des clés dans un projet dédié, ou dans le projet de ressource si vous utilisez le stockage des clés dans le même projet. - 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 CMEK et le suivi des clés, les clés créées par Autokey sont suivies dans le tableau de bord Cloud KMS.
Contrôler l'utilisation d'Autokey
Vous pouvez contrôler l'utilisation d'Autokey dans votre organisation à l'aide des commandes suivantes :
- Configuration d'Autokey : vous activez Autokey sur les dossiers ou projets où vous souhaitez l'utiliser. Les configurations Autokey sont héritées par les ressources enfants, mais elles peuvent être remplacées par des configurations définies à un niveau inférieur. Par exemple, la configuration Autokey définie sur un projet prévaut sur la configuration du dossier parent. Vous pouvez ainsi contrôler Autokey de manière ascendante. Pour en savoir plus sur l'activation et la désactivation d'Autokey, consultez Activer Cloud KMS Autokey.
- IAM : vous contrôlez qui peut créer et mettre à jour les configurations Autokey, et qui peut créer des ressources protégées à l'aide d'Autokey en utilisant des attributions de rôle IAM et des règles de refus. Ces contrôles IAM peuvent être définis au niveau de l'organisation, d'un dossier ou d'un projet. Les attributions de rôles IAM permettent aux comptes principaux d'effectuer les actions autorisées par leur rôle. Les stratégies de refus IAM bloquent les autorisations individuelles, même si elles sont incluses dans un rôle accordé au compte principal. Les règles de refus IAM définies sur une ressource parente ne peuvent pas être remplacées par des règles plus permissives définies à un niveau inférieur. Cela vous permet de contrôler de haut en bas qui peut activer et utiliser Autokey. Pour en savoir plus sur l'utilisation des règles de refus IAM pour contrôler l'utilisation d'Autokey dans votre organisation, consultez Utiliser des règles de refus IAM pour contrôler Autokey.
- Règle d'administration : vous contrôlez où et comment Autokey peut être configuré à l'aide de contraintes de règles d'administration personnalisées. Vous pouvez appliquer des contraintes de règles d'administration au niveau d'une organisation, d'un dossier ou d'un projet. Les ressources enfants héritent des règles d'administration, mais elles peuvent être remplacées par des règles appliquées à un niveau inférieur. Pour en savoir plus sur l'utilisation de contraintes de règles d'administration personnalisées pour contrôler l'utilisation d'Autokey dans votre organisation, consultez Utiliser des contraintes de règles d'administration personnalisées pour contrôler Autokey .
Services compatibles
Le tableau suivant répertorie les services compatibles avec Cloud KMS Autokey :
| Service | Ressources protégées | Précision des clés |
|---|---|---|
| AlloyDB pour PostgreSQL |
L'intégration entre AlloyDB pour PostgreSQL et Cloud KMS Autokey n'est disponible que pour les ressources créées à l'aide de Terraform ou de l'API REST. |
Une clé par ressource |
| Apigee |
L'intégration entre Apigee et Cloud KMS Autokey n'est disponible que pour les ressources créées à l'aide de Terraform ou de l'API REST. |
Une clé par ressource |
| Hub d'API Apigee |
L'intégration entre le hub d'API Apigee et Cloud KMS Autokey n'est disponible que pour les ressources créées à l'aide de Terraform ou de l'API REST. |
Une clé par ressource |
| Artifact Registry |
Autokey crée des clés lors de la création du dépôt, qui sont utilisées pour tous les artefacts stockés. |
Une clé par ressource |
| BigQuery |
Autokey crée des clés par défaut pour les ensembles de données. Les tables, les modèles, les requêtes et les tables temporaires d'un ensemble de données utilisent la clé par défaut de l'ensemble de données. Autokey ne crée pas de clés pour les ressources BigQuery autres que les ensembles de données. Pour protéger les ressources qui ne font pas partie d'un ensemble de données, vous devez créer vos propres clés par défaut au niveau du projet ou de l'organisation. |
Une clé par ressource |
| Bigtable |
Autokey crée des clés pour les clusters. Autokey ne crée pas de clés pour les ressources Bigtable autres que les clusters. L'intégration entre Bigtable et Cloud KMS Autokey n'est disponible que pour les ressources créées à l'aide de Terraform ou du Google Cloud SDK. |
Une clé par cluster |
| Cloud Run |
|
Une clé par emplacement dans un projet |
| Cloud SQL |
Autokey ne crée pas de clés pour les ressources L'intégration entre Cloud SQL et Cloud KMS Autokey n'est disponible que pour les ressources créées à l'aide de Terraform ou de l'API REST. |
Une clé par ressource |
| Cloud Storage |
Les objets d'un bucket de stockage utilisent la clé par défaut du bucket. Autokey ne crée pas de clés pour les ressources |
Une clé par bucket |
| Compute Engine |
Les instantanés utilisent la clé du disque dont vous créez un instantané.
Autokey ne crée pas de clés pour les ressources |
Une clé par ressource |
| Google Kubernetes Engine |
L'intégration entre Google Kubernetes Engine et Cloud KMS Autokey n'est disponible que pour les ressources créées à l'aide de Terraform ou de l'API REST. |
Une clé par cluster |
| Dataflow |
|
Une clé par ressource |
| Service géré pour Apache Airflow |
L'intégration entre le service géré pour Apache Airflow et Cloud KMS Autokey n'est disponible que pour les ressources créées à l'aide de Terraform ou de l'API REST. |
Une clé par ressource |
| Managed Service pour Apache Spark |
|
Pour les ressources Cluster, SessionTemplate et WorkflowTemplate : une clé par ressource Pour les ressources de lot et de session : Une clé par emplacement dans un projet |
| Memorystore pour Redis |
L'intégration entre Memorystore pour Redis et Cloud KMS Autokey n'est disponible que pour les ressources créées à l'aide de Terraform ou de l'API REST. |
Une clé par ressource |
| Pub/Sub |
|
Une clé par ressource |
| Secret Manager |
L'intégration entre Secret Manager et Cloud KMS Autokey n'est disponible que pour les ressources créées à l'aide de Terraform ou de l'API REST. |
Une clé par emplacement dans un projet |
| Secure Source Manager |
|
Une clé par ressource |
| Spanner |
L'intégration entre Spanner et Cloud KMS Autokey n'est disponible que pour les ressources créées à l'aide de Terraform ou de l'API REST. |
Une clé par ressource |
| Filestore |
|
Une clé par ressource |
Limites
- gcloud CLI n'est pas disponible pour les ressources Autokey.
- Les identifiants de clé ne figurent pas dans l'inventaire des éléments cloud.
Étapes suivantes
- Pour commencer à utiliser Cloud KMS Autokey, un administrateur doit activer Cloud KMS Autokey.
- Pour utiliser Cloud KMS Autokey après l'avoir activé, un développeur peut créer des ressources protégées par des CMEK à l'aide d'Autokey.
- Découvrez les bonnes pratiques concernant les CMEK.