Perguntas frequentes

Saiba mais sobre problemas comuns ao usar o Cloud Identity and Access Management.

Sobre o Google Cloud Identity and Access Management

O que é o Google Cloud Identity and Access Management (Cloud IAM)?

O Cloud IAM permite criar e gerenciar permissões para recursos do Google Cloud. Ele unifica o controle de acesso dos serviços do Google Cloud em um único sistema e apresenta um conjunto consistente de operações. Para mais conceitos, leia a Visão geral do IAM.

Por que preciso do Cloud IAM?

Com o Cloud IAM, adote o princípio de segurança de privilégios mínimos para conceder apenas o acesso necessário aos seus recursos e impedir o acesso a outros. Com o Cloud IAM, atenda às cláusulas de conformidade relacionadas à separação das obrigações.

Quais dos serviços do Google Cloud são compatíveis com o Cloud IAM?

Todos os serviços do Google Cloud usam o Cloud IAM para garantir que somente identidades autorizadas possam acessá-los. Além disso, alguns serviços fornecem papéis IAM específicos ou são compatíveis com a concessão de acesso ao recurso. Para mais informações sobre o suporte do IAM, consulte a visão geral.

Como dar os primeiros passos no Cloud IAM?

Para começar a usar o Cloud IAM, leia Guia de início rápido do IAM.

Posso usar as políticas do Cloud IAM para gerenciar autenticação e autorização dos meus aplicativos?

Use o IAM para gerenciar a autorização para recursos do Google Cloud. Para gerenciar autenticação do usuário, utilize os métodos convencionais, por exemplo, LDAP, Grupos do Google etc. Com o IAM, conceda acesso a uma Conta do Google, uma conta de serviço, um grupo do Google, um Cloud Identity ou um domínio do G Suite.

Papéis e políticas

Qual é a relação entre um papel e uma política?

Com as permissões, você determina quais operações são permitidas em um recurso. No IAM, as permissões são representadas no formato <serviço>.<recurso>.<verbo>, por exemplo, compute.instances.get. Um papel é um conjunto de permissões. Não é possível atribuir diretamente uma permissão ao usuário. Em vez disso, atribua um papel. Quando você faz isso, concede ao usuário todas as permissões contidas no papel.

O IAM permite controlar quem (usuários) tem qual permissão (papéis) para quais recursos. Basta definir as políticas. Uma política de IAM em um recurso é a lista completa de papéis concedidos aos membros do recurso.

Para mais informações sobre permissões, papéis e políticas, leia Visão geral do IAM.

Qual é a diferença entre papéis primitivos e predefinidos?

Papéis primários são os legados de proprietário, editor e visualizador. Com os papéis predefinidos do IAM, você tem acesso mais granular do que com os papéis primários. Sempre que possível, conceda papéis predefinidos às identidades para restringir o acesso somente aos recursos necessários.

Quando usar papéis primários?

Use papéis primários nos seguintes cenários:

  • Quando o serviço do Google Cloud não fornece um papel predefinido. Consulte a disponibilidade na tabela de papéis predefinidos.

  • Quando quiser conceder permissões mais amplas a um projeto. Isso geralmente é necessário em ambientes de desenvolvimento ou teste.

  • Quando for necessário permitir que um membro modifique permissões de um projeto, você concederá a ele o papel de proprietário, porque somente os proprietários têm permissão para conceder acesso a outros usuários de projetos.

  • A equipe com que você trabalha é pequena, e as permissões granulares não são necessárias.

Posso definir meus papéis personalizados?

Sim, consulte o artigo sobre Papéis personalizados.

Como descobrir quais papéis são concedidos a um recurso?

É possível descobrir quais papéis são concedidos em um recurso usando o Console do Cloud, o método getIamPolicy() ou a ferramenta de linha de comando gcloud. Saiba mais.

Como é uma política do Cloud IAM?

Uma política do IAM é representada por um objeto de política que consiste em uma lista de vinculações. Uma vinculação associa uma lista de membros a um papel. Isso pode ser representado em código, conforme mostrado neste exemplo de snippet de código:

{
      "bindings": [
       {
         "role": "roles/owner",
         "members": [
           "user:alice@example.com",
           "group:admins@example.com",
           "domain:google.com",
           "serviceAccount:my-other-app@appspot.gserviceaccount.com"]
          },
          {
            "role": "roles/compute.networkViewer",
            "members": ["user:bob@example.com"]
          }
        ]
    }
    

A política de exemplo acima atribui o papel de proprietário a alice@example.com, admins@example.com, google.com e my-other-app@appspot.gserviceaccount.com e o papel de Leitor de rede a bob@example.com.

Como criar e gerenciar políticas do Cloud IAM?

É possível criar e gerenciar políticas do IAM usando o Console do Google Cloud, a ferramenta gcloud e os métodos do IAM. Saiba mais.

Como encontrar a política do Cloud IAM do projeto?

É possível descobrir a política de IAM de um projeto usando o Console do Cloud, o método project.getIamPolicy() ou a ferramenta gcloud. Saiba mais.

Como encontrar a política da organização?

É possível encontrar a política no nível da organização usando o Console do Cloud, o método organization.getIamPolicy() ou a ferramenta gcloud. Para instruções sobre como encontrar políticas da organização, consulte Controle de acesso para organizações.

Como atualizar uma política?

É possível atualizar uma política usando o Console do Cloud, a API REST ou a ferramenta gcloud. Saiba mais.

Há limites para quantos membros posso incluir em uma política?

Sim, o número de membros em uma política é limitado. Consulte os detalhes em Cotas e limites para o Cloud IAM.

Como solucionar problemas das políticas?

Use o método testIamPermissions() para verificar qual das permissões fornecidas o autor da chamada tem para o recurso fornecido. Nesse método, um nome de recurso e um conjunto de permissões são utilizados como parâmetros e o subconjunto de permissões do autor da chamada é retornado.

É possível validar o efeito de um papel do IAM. Por exemplo, um usuário não pode acessar a página do Console do Cloud para a qual ele não recebeu acesso. Se um usuário só tem o papel de visualizador de registros, ele recebe a seguinte mensagem de erro quando tenta entrar na página do App Engine:

Você não tem permissões para executar a ação no recurso selecionado.

Identidades

A quais identidades posso atribuir os papéis do Cloud IAM?

O Cloud IAM permite que você conceda acesso aos seguintes tipos de identidades:

  • conta do Google
  • conta de serviço
  • grupo do Google
  • domínio do G Suite ou Cloud Identity

Posso usar Grupos do Google com o Cloud IAM?

Normalmente, sim. Uma exceção é o papel do proprietário. Um Grupo pode receber o papel de proprietário do projeto se ambos fizerem parte da mesma organização. Projetos sem uma organização não podem ter Grupos como proprietários, nem é possível atribuir Grupos como proprietários para projetos em diferentes organizações.

Sempre que possível, atribua papéis aos Grupos do Google em vez de concedê-los a usuários individuais. É mais fácil adicionar e remover membros de um Grupo do Google em vez de atualizar várias políticas do Cloud IAM para adicionar ou remover usuários. Se você precisa atribuir vários papéis para permitir uma tarefa específica, crie um Grupo do Google, atribua papéis e adicione usuários ou outros Grupos a ele.

Cada política do Cloud IAM pode conter até 250 Grupos do Google.

Posso usar o Cloud IAM para criar e gerenciar usuários?

Não. Use o Cloud Identity ou o G Suite para criar e gerenciar usuários. Isso também pode ser feito por meio dos seus métodos atuais como o LDAP ou os Grupos do Google. Se o método que você usa é o LDAP, é necessário utilizar o Google Cloud Directory Sync para sincronizar os dados do domínio do Google. Independentemente do método, vincule os usuários a um papel em uma política do IAM, de preferência com os Grupos do Google, para permitir que eles acessem os recursos.

Como desativar o acesso de um usuário aos recursos do Cloud IAM?

Se você concedeu o papel do IAM ao usuário por meio de um Grupo do Google, remover o usuário do Grupo fará com que ele perca o acesso. Se você não usou um Grupo, revise suas políticas para identificar o acesso concedido ao usuário individual, remova-o e atualize a política. Usar Grupos do Google para conceder acesso é mais fácil, porque você não terá de atualizar todas as políticas para revogar os direitos de acesso de um usuário individual. Saiba mais

Por que um usuário não pode acessar os recursos logo após a concessão da permissão ou continuar acessando os recursos após a remoção dela?

Em geral, leva menos de 60 segundos para que o acesso de um membro seja concedido ou revogado. No entanto, em determinadas circunstâncias, pode levar até sete minutos para que essas alterações se propaguem pelo sistema.

Como conceder permissões a recursos no projeto para alguém que não seja membro da organização?

Usando os Grupos do Google, adicione um usuário que não pertence à sua organização a um deles e vincule esse Grupo ao papel. Note que os Grupos do Google não têm credenciais de login e não é possível utilizá-los para estabelecer identidade e fazer uma solicitação para acessar um recurso.

Além disso, é possível também adicionar diretamente o usuário a uma política do IAM, mesmo que ele não faça parte da sua organização. Entretanto, verifique com seu administrador se isso é compatível com a política da empresa.

Como restringir quem pode acessar minhas instâncias?

Para restringir quem tem acesso às suas instâncias, use Grupos do Google para vincular identidades a papéis. Essa vinculação é usada como parte de uma política aplicada ao projeto em que as instâncias são inicializadas. Se um usuário identificado pela Conta do Google, como seu-usuário@seudomínio.com, não é membro do Grupo vinculado à política do IAM, ele não tem acesso ao recurso em que a política é aplicada.

Como usar a autenticação multifator (MFA, na sigla em inglês) com o Cloud IAM?

Quando usuários individuais usam a MFA, os métodos com os quais eles se autenticam são seguidos. Isso significa que o próprio sistema de identidade precisa ser compatível com a MFA. Para as contas do G Suite, isso precisa ser ativado pelo próprio usuário. Para as credenciais gerenciadas do G Suite, a MFA pode ser ativada com as ferramentas do G Suite.

Como uma conta de serviço é diferente de um usuário que usa o Cloud IAM?

Uma conta de serviço é uma conta especial do Google que pode ser usada por aplicativos para acessar os serviços do Google de modo programático. Essa conta pertence ao aplicativo ou a uma Máquina Virtual (VM, na sigla em inglês) em vez de pertencer a um usuário individual final. O aplicativo usa a conta de serviço para chamar a API de um serviço do Google. Assim, os usuários não são diretamente envolvidos.

Contas de serviço

Qual é o número máximo de contas de serviço que um projeto pode ter?

Por padrão, é possível criar até 100 contas de serviço em um projeto. Se você precisar criar contas de serviço adicionais em um projeto, poderá solicitar um aumento de cota.

Como revezar as chaves da conta de serviço ao usar o Cloud IAM?

As chaves gerenciadas pelo GCP são trocadas diariamente. Para revezar as chaves gerenciadas pelo usuário, use a API de conta de serviço de IAM para revezar automaticamente as chaves da conta de serviço. Para fazer isso, crie uma nova chave, alterne os aplicativos para que usem essa chave e exclua a chave antiga. Use os métodos serviceAccount.keys().create() e serviceAccount.keys().delete() para automatizar a rotação.

Como controlar quem pode criar uma conta de serviço no projeto?

Os papéis de proprietário e editor têm permissões para criar contas de serviço em um projeto. Para conceder a um usuário permissão para criar uma conta de serviço, atribua a ele o papel de proprietário ou editor.

Posso criar uma conta de serviço em uma organização?

Atualmente, só é possível criar contas de serviço em um projeto, não diretamente em uma organização. No entanto, quando você concede permissões IAM no nível da organização, elas são herdadas pelos projetos abaixo dessa organização e, consequentemente, pelas contas de serviço abaixo dos projetos.

Eu tenho uma equipe dedicada que gerencia regras de rede e firewall. Como manter essa separação de obrigações para que as equipes de desenvolvimento possam gerenciar instâncias, mas não fazer alterações na rede ou no firewall?

Primeiro, conceda o papel Administrador de redes do Compute no nível da organização ou do projeto aos administradores de rede. Em seguida, conceda o papel Administrador de instâncias do Compute aos desenvolvedores. Essa separação de tarefas permite que os desenvolvedores realizem ações nas instâncias ao mesmo tempo em que impedem que os desenvolvedores façam alterações nos recursos de rede associados ao projeto.

Preciso garantir que as equipes da organização não acessem as instâncias umas das outras. Como fazer isso?

Crie dois projetos, um para cada equipe. Em seguida, crie políticas separadas para cada projeto a fim de controlar quais equipes podem acessar o projeto e as instâncias contidas nele. Uma abordagem alternativa é usar contas de serviço com papéis diferentes.

Posso alterar a conta de serviço que uso para lançar a instância?

Sim, mas não é possível alterar a conta de serviço de uma instância do Compute Engine em execução. É preciso parar a instância temporariamente. Com a instância parada, atribua uma nova conta de serviço e, em seguida, reinicie a instância. Para mais informações, consulte a documentação do Compute Engine.

Em quais cenários eu usaria o papel Agente da conta de serviço?

O papel Agente da conta de serviço ficou obsoleto. Caso precise executar as operações como conta de serviço, use o papel Usuário da conta de serviço.

Em quais cenários eu usaria o papel Usuário da conta de serviço?

O Usuário da conta de serviço dá permissões para executar operações como a conta do serviço. Quando concedida com o papel compute.instanceAdmin, o papel iam.serviceAccountUser oferece aos usuários a capacidade de criar e gerenciar instâncias do Compute Engine que usam uma conta de serviço. Os usuários que são serviceAccountUsers de uma conta de serviço podem acessar todos os recursos a que essa conta tem acesso.

Auditoria

Como fazer auditoria das minhas políticas do Cloud IAM?

Use os registros de auditoria do Cloud para fazer auditorias regulares das alterações na política do Cloud IAM. Dependendo do tipo de registro de auditoria, eles são retidos por 30 dias (registros de acesso a dados) ou 400 dias (registros de atividades do administrador e de eventos do sistema).

O que é gravado nos registros de auditoria?

Os registros de auditoria da Atividade de administração contêm uma entrada para cada chamada de API ou ação administrativa que modifique a configuração ou os metadados de um serviço ou projeto. Os registros de auditoria de Acesso aos dados contêm uma entrada para os seguintes eventos:

  • Chamadas de API ou ações administrativas de leitura da configuração ou dos metadados de um serviço ou projeto.

  • Chamadas de API ou ações administrativas de criação, modificação ou leitura de dados fornecidos pelo usuário e gerenciados por um serviço, como dados armazenados em um serviço de banco de dados.

  • O método setIamPolicy() em nível de projeto é registrado.

  • As contas de serviço e as chaves das contas de serviço são registradas.

Como controlar quem tem acesso aos meus registros de auditoria?

É possível restringir o acesso aos registros usando papéis do Cloud Logging.

Como manter meus registros de auditoria?

Entradas individuais de registro de auditoria são mantidas por um período específico e depois excluídas. A política de cota do Cloud Logging explica por quanto tempo as entradas de registro são retidas. Para manter suas entradas de registro além dos limites da política de cota, exporte seus registros do Cloud Logging para um intervalo do Cloud Storage ou para o BigQuery.