Dans Cloud KMS, les ressources sont organisées hiérarchiquement. Cette hiérarchie vous aide à gérer et accorder l'accès aux ressources selon différents niveaux de précision. Les clés sont contenues dans des trousseaux de clés, et les trousseaux de clés existent au sein d'un projet. Des connexions EKM existent également au sein d'un projet. Les projets peuvent être organisés en dossiers ou en organisations.
Cette rubrique fournit des détails supplémentaires sur la hiérarchie des ressources dans Cloud KMS. Pour en savoir plus sur les ressources Google Cloud en général, consultez la section Hiérarchie des ressources.
Hiérarchie des ressources
Le champ d'application d'un rôle IAM varie en fonction du niveau de la hiérarchie des ressources auquel le rôle a accès. Ce tableau présente les capacités effectives accordées par le rôle Chiffreur de clés cryptographiques Cloud KMS (roles/cloudkms.cryptoKeyEncrypter
) à différents niveaux de la hiérarchie.
Vous pouvez gérer l'accès aux clés ou aux trousseaux de clés, mais pas aux versions de clé individuelles.
Hiérarchie des ressources | Capacité |
---|---|
Organisation | Chiffrer à l'aide de toutes les clés de tous les projets de l'organisation |
Dossier | Chiffrer à l'aide de toutes les clés de tous les projets du dossier |
Projet | Chiffrer à l'aide de toutes les clés du projet |
Trousseau de clés | Chiffrer à l'aide de toutes les clés du trousseau de clés |
Clé | Chiffrer uniquement à l'aide de cette clé |
Principes de sécurité
Cloud IAM permet d'appliquer les principes de sécurité interdépendants de la séparation des tâches et du moindre privilège :
Lorsque vous appliquez le principe de séparation des tâches, aucun membre ne dispose de tous les accès nécessaires pour remplir une fonction métier critique. Par exemple, un employé de banque ne peut retirer des fonds d'un compte que si le titulaire du compte est physiquement présent et lance la transaction.
Lorsque vous appliquez le principe du moindre privilège, un membre ne dispose que du niveau d'accès minimal requis pour remplir ses fonctions spécifiques. Par exemple, un employé de banque n'a pas automatiquement la capacité d'approuver un prêt client.
Rôles prédéfinis
IAM fournit des rôles prédéfinis qui permettent d'accorder l'accès pour chaque type de ressources Google Cloud. Si aucun rôle prédéfini ne répond à vos besoins, vous pouvez créer un rôle personnalisé.
IAM propose les rôles prédéfinis suivants pour Cloud KMS :
Role | Permissions |
---|---|
Cloud KMS Admin( Provides access to Cloud KMS resources, except for access to restricted resource types and cryptographic operations. Lowest-level resources where you can grant this role:
|
|
Cloud KMS Autokey Admin( Enables management of AutokeyConfig. |
|
Cloud KMS Autokey User( Grants ability to use KeyHandle resources. |
|
Cloud KMS CryptoKey Decrypter( Provides ability to use Cloud KMS resources for decrypt operations only. Lowest-level resources where you can grant this role:
|
|
Cloud KMS CryptoKey Decrypter Via Delegation( Enables Decrypt operations via other Google Cloud services |
|
Cloud KMS CryptoKey Encrypter( Provides ability to use Cloud KMS resources for encrypt operations only. Lowest-level resources where you can grant this role:
|
|
Cloud KMS CryptoKey Encrypter/Decrypter( Provides ability to use Cloud KMS resources for encrypt and decrypt operations only. Lowest-level resources where you can grant this role:
|
|
Cloud KMS CryptoKey Encrypter/Decrypter Via Delegation( Enables Encrypt and Decrypt operations via other Google Cloud services |
|
Cloud KMS CryptoKey Encrypter Via Delegation( Enables Encrypt operations via other Google Cloud services |
|
Cloud KMS Crypto Operator( Enables all Crypto Operations. |
|
Cloud KMS EkmConnections Admin( Enables management of EkmConnections. |
|
Cloud KMS Expert Raw AES-CBC Key Manager( Enables raw AES-CBC keys management. |
|
Cloud KMS Expert Raw AES-CTR Key Manager( Enables raw AES-CTR keys management. |
|
Cloud KMS Expert Raw PKCS#1 Key Manager( Enables raw PKCS#1 keys management. |
|
Cloud KMS Importer( Enables ImportCryptoKeyVersion, CreateImportJob, ListImportJobs, and GetImportJob operations |
|
Cloud KMS Protected Resources Viewer( Enables viewing protected resources. |
|
Cloud KMS CryptoKey Public Key Viewer( Enables GetPublicKey operations |
|
Cloud KMS CryptoKey Signer( Enables Sign operations |
|
Cloud KMS CryptoKey Signer/Verifier( Enables Sign, Verify, and GetPublicKey operations |
|
Cloud KMS CryptoKey Verifier( Enables Verify and GetPublicKey operations |
|
Cloud KMS Viewer( Enables Get and List operations. |
|
Rôles personnalisés
En plus des rôles prédéfinis, vous pouvez créer des rôles personnalisés. Les rôles personnalisés vous permettent d'appliquer le principe du moindre privilège en accordant au rôle les autorisations minimales requises pour effectuer une tâche donnée.
Un rôle personnalisé inclut une ou plusieurs des autorisations listées dans la documentation de référence IAM.
Les autorisations associées à l'API Cloud Key Management Service commencent par la chaîne cloudkms
.
Pour en savoir plus, consultez la section Niveaux de compatibilité des autorisations dans les rôles personnalisés.
Pour en savoir plus sur les autorisations requises pour appeler une méthode API Cloud Key Management Service spécifique, consultez la documentation de référence de l'API de cette méthode.
Consignes générales pour la gestion des accès dans Cloud KMS
Nous vous recommandons d'éviter d'utiliser des rôles de base à l'échelle du projet, tels que owner
, editor
et viewer
. Ces rôles ne séparent pas la capacité de gestion des clés de la capacité à utiliser les clés pour les opérations de chiffrement, et ne sont pas recommandés pour les environnements de production. Utilisez plutôt des rôles prédéfinis ou créez des rôles personnalisés qui reflètent les besoins de votre entreprise.
Les exemples suivants illustrent quelques bonnes consignes de sécurité :
Pour une organisation de grande taille ou complexe, vous pouvez adopter une approche semblable à celle-ci :
- Attribuez aux membres de votre équipe de sécurité informatique le rôle d'administrateur Cloud KMS (
roles/cloudkms.admin
) sur tous les projets. Si différents membres de l'équipe gèrent différents aspects du cycle de vie d'une clé, vous pouvez leur attribuer un rôle plus précis, tel que le rôle "Importateur Cloud KMS" (roles/cloudkms.importer
). - Attribuez le rôle "Chiffreur/Déchiffreur Cloud KMS" (
roles/cloudkms.cryptoKeyEncrypterDecrypter
) aux utilisateurs ou aux applications qui lisent ou écrivent des données chiffrées. - Attribuez le rôle "Lecteur de clés publiques Cloud KMS" (
roles/cloudkms.publicKeyViewer
) aux utilisateurs ou aux applications qui ont besoin d'afficher la partie publique d'une clé utilisée pour le chiffrement asymétrique. - Créez des rôles prédéfinis correspondant aux besoins de votre entreprise. Par exemple, le même utilisateur peut avoir besoin de surveiller les quotas d'un projet et d'afficher les données de journal.
- Attribuez aux membres de votre équipe de sécurité informatique le rôle d'administrateur Cloud KMS (
Pour une petite organisation ayant des exigences de sécurité simples, vous pouvez choisir d'adopter une approche plus simple en attribuant un rôle étendu tel que Administrateur de l'organisation (
roles/resourcemanager.organizationAdmin
). Toutefois, cette approche pourrait ne pas suivre l'évolution de vos besoins.Envisagez d'héberger vos clés dans un projet Google Cloud distinct des données protégées par ces clés. Un utilisateur disposant d'un rôle de base ou hautement privilégié dans un projet, tel que
editor
, ne peut pas utiliser ce rôle pour obtenir un accès non autorisé aux clés d'un autre projet.Évitez d'attribuer le rôle
owner
à un membre. Sans le rôleowner
, aucun membre du projet ne peut créer une clé et l'utiliser pour déchiffrer des données ou pour les signer, sauf si chacune de ces autorisations est accordée à ce membre. Pour accorder un accès administrateur étendu sans autoriser le chiffrement ou le déchiffrement, attribuez plutôt le rôle d'administrateur Cloud KMS (roles/cloudkms.admin
).Pour limiter l'accès aux données chiffrées, telles que les données client, vous pouvez limiter l'accès des membres qui peuvent accéder à la clé et de ceux qui peuvent utiliser la clé pour le déchiffrement. Si nécessaire, vous pouvez créer des rôles personnalisés précis pour répondre aux besoins de votre entreprise.
Vérifier les autorisations
Pour chaque type d'objet Cloud KMS pour lequel vous pouvez définir des autorisations IAM précises, cet objet dispose d'une méthode testIamPermissions
.
La méthode testIamPermissions
renvoie l'ensemble des autorisations accordées à l'appelant pour cet objet.
- Pour les trousseaux de clés, vous pouvez appeler la méthode
cloudkms.keyRings.testIamPermissions
. - Pour les clés, vous pouvez appeler la méthode
cloudkms.cryptoKeys.testIamPermissions
. - Pour les tâches d'importation de clé, vous pouvez appeler la méthode
cloudkms.keyRings.importJobs.testIamPermissions
. - Pour les connexions EKM, vous pouvez appeler la méthode
cloudkms.ekmConnections.testIamPermissions
.
Vous ne pouvez pas définir d'autorisations IAM sur une version de clé. Le type d'objet CryptoKeyVersion
ne dispose donc pas de cette méthode.
La méthode testIamPermissions
d'un objet renvoie une réponse TestIamPermissionsResponse
.
Pour obtenir des exemples d'appels de méthodes testIamPermissions
, consultez la documentation sur les autorisations de test dans la documentation IAM.
Étapes suivantes
- Découvrez comment IAM centralise la gestion des autorisations et des niveaux d'accès pour les ressources Google Cloud.
- Découvrez les différents types d'objets Cloud KMS.