Separation of duties is the concept of ensuring that one principal does not have all necessary permissions required to complete a malicious action. In Cloud Key Management Service, this could be an action such as using a key to access and decrypt data which that user has no valid reason to access.
Separation of duties is a business control typically used in larger organizations, meant to help avoid security or privacy incidents and errors. It is considered best practice.
In Cloud KMS, separation of duties requires a strict distinction between the following roles:
- Key administrators: Principals who are authorized to manage key lifecycles including creation, deletion, rotation, and state changes—for example, users with the Cloud KMS Admin role.
- Key user: Principals who are authorized to use keys including encryption, decryption, signing, or signature verification—for example, users with the Cloud KMS CryptoKey Encrypter/Decrypter role.
When you use Cloud KMS keys for customer-managed encryption keys, we recommend that the service account is the only principal authorized to use the key for encryption and decryption. For more information about how CMEK integrations handle resource access, see CMEK-integrated services handle resource access.
To prevent a bypass of separation of duties, don't grant principals broad basic
roles like Owner (roles/owner), which contains both administrative and
cryptographic permissions. You can use the Encryption metrics dashboard
(Preview) to help identify keys that don't adhere to the
recommendations for separation of duties. For more information, see View
encryption metrics.
For more information about how to use IAM roles safely, see Use IAM securely.
Key management models
Cloud KMS supports two primary models for enforcing separation of duties: centralized key management and delegated key management. These key management models can be used separately or in combination. For example, an organization might choose to use a centralized key management model for production environments and use a dedicated key management model for lower environments used for development and testing.
The following table compares centralized and delegated key management models and helps you decide which is best for your needs.
| Area | Centralized (folder-level) | Delegated (project-level) |
|---|---|---|
| Key location | Stored in a dedicated key project, usually per folder. | Stored in the same project as the resource that the key protects. |
| Separation method | Project boundaries: Keys and the resources they protect are in different projects. | Separate roles: Strict IAM role separation so that no principal can both manage and use a key. |
| Business culture | Ideal for highly regulated organizations with dedicated central security or crypto teams. | Ideal for organizations that prioritize developer agility and decentralized authority. |
| Primary drivers | High isolation and centralized oversight. | Simplified quota management and reduced operational toil. |
Delegated key management
The delegated or "same-project" key management model is recommended for organizations that prioritize developer agility and aim to reduce the "loop" between central security teams and developers.
In the delegated model, your CMEKs and other keys are stored in the same project as the resources they protect. Enforcing separation of duties in delegated key management requires keeping IAM roles strictly separated.
You can enable Autokey for projects (Preview) on a project or folder to allow automated key creation using the delegated key management model. For more information, see Enable Autokey for delegated key management.
Centralized key management
The centralized or "dedicated-project" key management model is recommended for organizations with centralized security teams or those that require strict isolation of key material from application environments.
In the centralized model, your CMEKs and other keys are stored in dedicated key projects, kept separate from the resources they protect. Usually, this means that each folder has its own dedicated key project to contain keys that protect resources throughout the folder. This dedicated key project is managed by a central security team, who have key administration permissions in the key project but are restricted from accessing projects that contain the resources protected by those keys.
You can enable Autokey on a folder to allow automated key creation using the centralized key management model. For more information, see Set up Autokey for centralized key management.
Automating and monitoring compliance
Google Cloud provides the following tools to automate and monitor your security boundaries:
- Cloud KMS Autokey: Autokey supports both centralized and delegated (Preview) models of key management. For both, it automates separation of duties by automatically granting the key usage role to the required service agent—not to the person requesting the key. Autokey is designed to support infrastructure-as-code pipelines that don't need elevated privileges for key creation.
- Security Command Center: Monitor for KMS Role Separation findings to detect any principal, including a Project Owner or a Google service account, that possesses both administrative and cryptographic permissions on a single key.
CMEK encryption metrics: Use the dashboard to verify alignment with separation of duties practices across the organization.