Separation of duties (SoD)
In this tutorial, we will learn and understand about Separation of duties (SoD).
However, 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 also decrypting data which user have no access to. Further, Separation of duties is a business control that works for larger organizations. As this helps to avoid security or privacy incidents and errors.
Setting up Cloud KMS in a separate project
Cloud KMS can 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 keys in Cloud KMS in that project. This is because the projects owns the keys themselves, 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:
- Firstly, (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 restrict to setting IAM policies, which in turn restrict who can manage and use keys. However, using an organization-level node, you can further restrict permissions for projects in your organization.
- Secondly, (not recommended) If you must continue to use the owner role, ensure that it is granted to a different actual member in your-key-project than the member who is the owner of your-project. The owner can still use keys, but only in a single project.
Reference: Google Documentation