No Cloud KMS, os recursos são organizados em uma hierarquia. Essa hierarquia ajuda você a gerenciar e conceder acesso a recursos em vários níveis de granularidade. As chaves são armazenadas em keyrings que existem em um projeto. As conexões EKM também existem em um projeto. Os projetos podem ser organizados em pastas ou organizações.
Neste tópico, apresentamos mais detalhes sobre a hierarquia de recursos no Cloud KMS. Para saber mais sobre os recursos do Google Cloud em geral, consulte Hierarquia de recursos.
Hierarquia de recursos
O escopo de um papel do IAM muda dependendo do nível da hierarquia de
recursos em que o papel foi concedido. Nesta tabela, mostramos os recursos efetivos
concedidos pelo papel Criptografador do Cloud KMS CryptoKey
(roles/cloudkms.cryptoKeyEncrypter
) em diferentes níveis da hierarquia.
É possível gerenciar o acesso a chaves ou keyrings, mas não a versões de chaves individuais.
Hierarquia de recursos | Capacidade |
---|---|
Organização | Criptografar usando todas as chaves em todos os projetos da organização |
Pasta | Criptografar usando todas as chaves em todos os projetos da pasta |
Projeto | Criptografar usando todas as chaves do projeto |
Keyring | Criptografar usando todas as chaves do keyring |
Chave | Criptografar usando apenas esta chave |
Princípios de segurança
O IAM ajuda a aplicar os princípios de segurança inter-relacionados da separação de deveres e de privilégio mínimo:
Quando você aplica o princípio de separação de deveres, nenhum membro tem todo o acesso necessário para concluir uma função comercial importante. Por exemplo, um caixa de banco só pode retirar fundos de uma conta quando o titular da conta está fisicamente presente e inicia a transação.
Quando você aplica o princípio de privilégio mínimo, um membro tem apenas o nível mínimo de acesso necessário para concluir as funções comerciais específicas dele. Por exemplo, um caixa de banco não recebe automaticamente a capacidade de aprovar um empréstimo para um cliente.
Papéis predefinidos
O IAM oferece papéis predefinidos que concedem acesso a cada tipo de recurso do Google Cloud. Se nenhum papel predefinido atender às suas necessidades, crie um papel personalizado.
O IAM oferece os seguintes papéis predefinidos para o Cloud KMS:
Role | Permissions |
---|---|
Cloud KMS Admin( Provides access to Cloud KMS resources, except for access to restricted resource types and cryptographic operations. Lowest-level resources where you can grant this role:
|
|
Cloud KMS Autokey Admin( Enables management of AutokeyConfig. |
|
Cloud KMS Autokey User( Grants ability to use KeyHandle resources. |
|
Cloud KMS CryptoKey Decrypter( Provides ability to use Cloud KMS resources for decrypt operations only. Lowest-level resources where you can grant this role:
|
|
Cloud KMS CryptoKey Decrypter Via Delegation( Enables Decrypt operations via other Google Cloud services |
|
Cloud KMS CryptoKey Encrypter( Provides ability to use Cloud KMS resources for encrypt operations only. Lowest-level resources where you can grant this role:
|
|
Cloud KMS CryptoKey Encrypter/Decrypter( Provides ability to use Cloud KMS resources for encrypt and decrypt operations only. Lowest-level resources where you can grant this role:
|
|
Cloud KMS CryptoKey Encrypter/Decrypter Via Delegation( Enables Encrypt and Decrypt operations via other Google Cloud services |
|
Cloud KMS CryptoKey Encrypter Via Delegation( Enables Encrypt operations via other Google Cloud services |
|
Cloud KMS Crypto Operator( Enables all Crypto Operations. |
|
Cloud KMS EkmConnections Admin( Enables management of EkmConnections. |
|
Cloud KMS Expert Raw AES-CBC Key Manager( Enables raw AES-CBC keys management. |
|
Cloud KMS Expert Raw AES-CTR Key Manager( Enables raw AES-CTR keys management. |
|
Cloud KMS Expert Raw PKCS#1 Key Manager( Enables raw PKCS#1 keys management. |
|
Cloud KMS Importer( Enables ImportCryptoKeyVersion, CreateImportJob, ListImportJobs, and GetImportJob operations |
|
Cloud KMS Protected Resources Viewer( Enables viewing protected resources. |
|
Cloud KMS CryptoKey Public Key Viewer( Enables GetPublicKey operations |
|
Cloud KMS CryptoKey Signer( Enables Sign operations |
|
Cloud KMS CryptoKey Signer/Verifier( Enables Sign, Verify, and GetPublicKey operations |
|
Cloud KMS CryptoKey Verifier( Enables Verify and GetPublicKey operations |
|
Cloud KMS Viewer( Enables Get and List operations. |
|
Papéis personalizados
Além dos papéis predefinidos, é possível criar papéis personalizados. Os papéis personalizados permitem que você aplique o princípio de privilégio mínimo concedendo ao papel as permissões mínimas necessárias para executar uma determinada tarefa.
Um papel personalizado inclui uma ou mais permissões listadas na
referência do IAM.
As permissões relacionadas à API Cloud Key Management Service começam com a string cloudkms
.
Para mais informações, consulte
Níveis de suporte para permissões em papéis personalizados.
Para mais informações sobre as permissões necessárias para invocar um método específico da API Cloud Key Management Service, consulte a referência da API desse método.
Diretrizes gerais para gerenciar o acesso no Cloud KMS
Evite o uso de papéis básicos em todo o projeto, como owner
,
editor
e viewer
. Esses papéis não separam a capacidade de gerenciar chaves
da capacidade de usá-las para operações criptográficas e não são
recomendados em ambientes de produção. Em vez deles, use os papéis predefinidos ou crie papéis personalizados conforme os requisitos da sua empresa.
Os exemplos a seguir ajudam a ilustrar algumas boas diretrizes de segurança:
Para uma organização grande ou complexa, escolha uma abordagem como esta:
- Conceda aos membros da equipe de segurança de TI o papel Administrador do Cloud KMS
(
roles/cloudkms.admin
) em todos os projetos. Se membros da equipe diferentes cuidam de aspectos distintos do ciclo de vida de uma chave, conceda a eles um papel mais granular, como Importador do Cloud KMS (roles/cloudkms.importer
). - Conceda o papel Criptografador/Descriptografador do Cloud KMS
(
roles/cloudkms.cryptoKeyEncrypterDecrypter
) a usuários ou aplicativos que leem ou gravam dados criptografados. - Conceda o papel Leitor de chave pública do Cloud KMS
(
roles/cloudkms.publicKeyViewer
) a usuários ou aplicativos que precisam visualizar a parte pública de uma chave usada para criptografia assimétrica. - Crie papéis predefinidos que correspondam aos requisitos da sua empresa. Por exemplo, o mesmo usuário pode precisar monitorar as cotas de um projeto e visualizar os dados do registro.
- Conceda aos membros da equipe de segurança de TI o papel Administrador do Cloud KMS
(
Para uma organização de pequeno porte com requisitos de segurança simples, é possível adotar uma abordagem mais simples concedendo um papel amplo, como Administrador da organização (
roles/resourcemanager.organizationAdmin
). No entanto, essa abordagem pode não ser escalonada de acordo com seus requisitos dinâmicos.Considere hospedar suas chaves em um projeto do Google Cloud separado dos dados protegidos por essas chaves. Um usuário com um papel básico ou altamente privilegiado em um projeto, como
editor
, não pode usar esse papel para ter acesso não autorizado às chaves em um projeto diferente.Evite conceder o papel
owner
a qualquer membro. Sem o papelowner
, nenhum membro do projeto pode criar uma chave e usá-la para descriptografar dados ou para assinatura, a menos que cada uma dessas permissões seja concedida ao membro. Para conceder acesso administrativo amplo sem a capacidade de criptografar ou descriptografar, conceda o papel Administrador do Cloud KMS (roles/cloudkms.admin
).Para limitar o acesso a dados criptografados, como dados do cliente, é possível restringir quem pode acessar a chave e quem pode usá-la para descriptografia. Se necessário, crie papéis personalizados granulares para atender aos requisitos da sua empresa.
Como verificar permissões
Para cada tipo de objeto do Cloud KMS em que é possível definir permissões
granulares do IAM, esse objeto tem um método testIamPermissions
.
O método testIamPermissions
retorna o conjunto de permissões que o autor da chamada
recebeu para esse objeto.
- No caso dos keyrings, é possível invocar o
método
cloudkms.keyRings.testIamPermissions
. - No caso das chaves, é possível invocar o
método
cloudkms.cryptoKeys.testIamPermissions
. - No caso dos jobs de importação de chaves, é possível invocar o
método
cloudkms.keyRings.importJobs.testIamPermissions
. - Para conexões EKM,
é possível invocar o método
cloudkms.ekmConnections.testIamPermissions
.
Não é possível definir permissões do IAM em uma versão da chave. Portanto,
o tipo de objeto CryptoKeyVersion
não tem esse método.
O método testIamPermissions
de um objeto retorna
um TestIamPermissionsResponse
.
Para exemplos de como invocar métodos testIamPermissions
, consulte a documentação sobre
permissões de teste na documentação
do IAM.
A seguir
- Saiba como o IAM centraliza o gerenciamento de permissões e escopos de acesso dos recursos do Google Cloud.
- Entenda os diferentes tipos de objetos do Cloud KMS.