Mantenha tudo organizado com as coleções
Salve e categorize o conteúdo com base nas suas preferências.
Separação de deveres é o conceito de garantir que um indivíduo não terá todas as permissões necessárias para concluir uma ação mal-intencionada. No Cloud Key Management Service, essa pode ser uma ação, como usar uma chave para acessar e descriptografar dados aos quais esse usuário normalmente não pode ter acesso.
A separação de deveres é um controle comercial tipicamente usado em organizações maiores, destinado a evitar incidentes e erros de segurança ou privacidade.
É considerada uma prática recomendada.
Como configurar o Cloud KMS em um projeto separado
O Cloud KMS pode ser executado em um projeto existente, por exemplo, your-project. Isso pode ser útil se os dados criptografados com chaves no Cloud KMS forem armazenados no mesmo projeto.
No entanto, qualquer usuário com acesso owner nesse projeto também poderá gerenciar (e realizar operações criptográficas com) chaves no Cloud KMS nesse projeto. Isso ocorre porque as próprias chaves pertencem ao projeto, do qual o usuário é um owner.
Em vez disso, para permitir a separação de tarefas, execute o Cloud KMS no próprio projeto, por exemplo, your-key-project. Dependendo do rigor dos requisitos de separação, seria possível:
(recomendado) Crie your-key-project sem um owner no nível do projeto e atribua um Administrador da organização concedido no nível da organização.
Ao contrário de um owner, um Administrador da organização não pode gerenciar ou usar chaves diretamente.
Elas estão restritas às configurações de políticas do IAM, que restringem quem
pode gerenciar e usar chaves. Use um nó de nível de organização para restringir
ainda mais as permissões para projetos na organização.
(não recomendado) Se você precisar continuar usando o papel owner, verifique se ele foi concedido a um principal diferente em your-key-project do que o principal, que é o owner de your-project (em inglês) O owner ainda pode usar chaves,
mas apenas em um único projeto.
[[["Fácil de entender","easyToUnderstand","thumb-up"],["Meu problema foi resolvido","solvedMyProblem","thumb-up"],["Outro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Informações incorretas ou exemplo de código","incorrectInformationOrSampleCode","thumb-down"],["Não contém as informações/amostras de que eu preciso","missingTheInformationSamplesINeed","thumb-down"],["Problema na tradução","translationIssue","thumb-down"],["Outro","otherDown","thumb-down"]],["Última atualização 2025-08-18 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."]]
