Separation of duties

Separation of duties is the concept of ensuring that one individual does not have all necessary permissions to be able to complete a malicious action. In Cloud KMS, this could be an action such as using a key to access and decrypt data that that user should not normally have access to.

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.

For further guidance, see our documentation on using IAM securely.

Setting up Cloud KMS in a separate project

Cloud KMS could be run in an existing project, for example your-project, and this might be sensible if the data being encrypted with keys in Cloud KMS is stored in the same project.

However, any user with owner access on that project is then also able to manage (and perform cryptographic operations with) keys in Cloud KMS in that project. This is because the keys themselves are owned by the project, of which the user is an owner.

Instead, to allow for a separation of duties, you could run Cloud KMS in its own project, for example your-key-project. Then, depending on the strictness of your separation requirements, you could either:

  • (recommended) Create your-key-project without an owner at the project-level, and instead have an Organization Admin granted at the organization-level. This Organization Admin is not like an owner - they are not able to manage or use keys, but they have the permission to Set IAM Policy to restrict who is given permissions for key management and use. Using an organization-level node, you can further restrict permissions for projects in your organization. See the next section for alternative roles to owner for use with Cloud KMS.
  • (not recommended) Grant an owner role for your-key-project to a different user than the owner on your-project, where the keys from Cloud KMS are being used. This user would still have access to all key operations.

Choosing the right IAM roles

For smaller organizations, the primitive roles of owner, editor and viewer likely provide sufficient granularity for key management. In larger organizations where separation of duties is required, the owner role provides excessive access to sensitive security operations, and may not be ideal. In this case, we instead recommend you use predefined roles:

  • For the business owner whose application requires encryption: organization-level Organization Admin.
  • For the user managing Cloud KMS, e.g., a member of an organization's IT security team: Cloud KMS project-level with Admin (cloudkms.admin) or Editor (editor) role.
  • For the user or service using keys for encryption and decryption operations: Cloud KMS project-level service account with Encrypter/Decrypter (cloudkms.cryptoKeyEncrypterDecrypter). If the service only needs to be able to write or only be able to read data, further restrict use with the role of only Encrypter (cloudkms.cryptoKeyEncrypter) or Decrypter (cloudkms.cryptoKeyDecrypter).

Using a separate project for Cloud KMS and these recommended roles, you address several security concerns about separation of duties:

  • Any user who needs a primitive role at the project-level in order to use another Google Cloud service cannot use that authority to access Cloud KMS.
  • No user will need the owner role, which could grant them excessive permissions to use keys. With no owner, no user can both manage and use a key to encrypt or decrypt data directly by default. Note that if data access logs are not enabled, an owner could have potentially unaudited access to use key material.

Send feedback about...

Cloud KMS Documentation