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 Key Management Service, this could be an action such as using a key to access and decrypt
data which 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 Identity and Access Management 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 designate an Organization Admin granted at the organization-level.
Unlike an owner, an Organization Admin can't manage or use keys directly.
They are restricted to setting IAM policies, which restrict who
can manage and use keys. Using an organization-level node, you can further
restrict permissions for projects in your organization.
- (not recommended) If you must continue to use the
owner role, ensure that
it is granted to a different principal in your-key-project than the
principal who is the owner of your-project. The owner can still use
keys, but only in a single project.
Except as otherwise noted, the content of this page is licensed under the Creative Commons Attribution 4.0 License, and code samples are licensed under the Apache 2.0 License. For details, see the Google Developers Site Policies. Java is a registered trademark of Oracle and/or its affiliates.
Last updated 2025-08-07 UTC.
[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Missing the information I need","missingTheInformationINeed","thumb-down"],["Too complicated / too many steps","tooComplicatedTooManySteps","thumb-down"],["Out of date","outOfDate","thumb-down"],["Samples / code issue","samplesCodeIssue","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2025-08-07 UTC."],[],[],null,["# Separation of duties\n\n*Separation of duties* is the concept of ensuring that one individual does not\nhave all necessary permissions to be able to complete a malicious action. In\nCloud Key Management Service, this could be an action such as using a key to access and decrypt\ndata which that user should not normally have access to.\n\nSeparation of duties is a business control typically used in larger\norganizations, meant to help avoid security or privacy incidents and errors.\nIt is considered best practice.\n\nFor further guidance, see our [documentation on using Identity and Access Management securely](/iam/docs/using-iam-securely).\n\nSetting up Cloud KMS in a separate project\n------------------------------------------\n\nCloud KMS could be run in an existing project, for example `your-project`, and\nthis might be sensible if the data being encrypted with keys in Cloud KMS is\nstored in the same project.\n\nHowever, any user with `owner` access on that project is then also able to\nmanage (and perform cryptographic operations with)\nkeys in Cloud KMS in that project. This is because the keys themselves are owned\nby the\nproject, of which the user is an `owner`.\n\nInstead, to allow for a separation of duties, you could run Cloud KMS in its\nown project, for example `your-key-project`. Then, depending on the strictness\nof your separation requirements, you could either:\n\n- (**recommended** ) Create `your-key-project` without an `owner` at the project level, and designate an Organization Admin [granted at the organization-level](/resource-manager/docs/quickstart#grant_roles_at_the_organization_level). Unlike an `owner`, an Organization Admin can't manage or use keys directly. They are restricted to setting IAM policies, which restrict who can manage and use keys. Using an organization-level node, you can further restrict permissions for projects in your organization.\n- (not recommended) If you must continue to use the `owner` role, ensure that it is granted to a different principal in `your-key-project` than the principal who is the `owner` of `your-project`. The `owner` can still use keys, but only in a single project."]]
