Visão geral

Nesta página, descrevemos os conceitos básicos do gerenciamento de identidade e acesso (IAM, na sigla em inglês).

O IAM permite conceder acesso granular a recursos específicos do Google Cloud e ajuda a impedir o acesso a outros recursos. O IAM permite que você adote o princípio de segurança de privilégio mínimo, o que indica que ninguém precisa ter mais permissões do que o realmente necessário.

Como o IAM funciona

Com o IAM, você gerencia o controle de acesso definindo quem (identidade) tem qual acesso (papel) a que recurso. Por exemplo, as instâncias de máquina virtual do Compute Engine, os clusters do Google Kubernetes Engine (GKE) e os buckets do Cloud Storage são todos recursos do Google Cloud. As organizações, pastas e projetos que você usa para organizar seus recursos também são recursos.

No IAM, a permissão para acessar um recurso não é concedida diretamente ao usuário final. Em vez disso, as permissões são agrupadas em papéis, que são concedidos a principais autenticados. No passado, o IAM muitas vezes se referia aos principais como membros. Algumas APIs ainda usam esse termo.

Uma política do IAM define e aplica quais papéis são concedidos a quais principais, e essa política é anexada a um recurso. Quando um principal autenticado tenta acessar um recurso, o IAM verifica a política do recurso para determinar se a ação é permitida.

O diagrama a seguir ilustra o gerenciamento de permissões no IAM.

Este modelo de gerenciamento de acesso tem três partes principais:

  • Principal. Um principal pode ser uma Conta do Google (para usuários finais), uma conta de serviço (para apps e máquinas virtuais), um Grupo do Google ou um domínio do Google Workspace ou Cloud Identity que pode acessar um recurso. A identidade de um principal é um endereço de e-mail associado a um usuário, conta de serviço ou Grupo do Google. Pode ser também um nome de domínio associado aos domínios do Google Workspace ou do Cloud Identity.
  • Papel. Um papel é um conjunto de permissões. Com as permissões, você determina quais operações são permitidas em um recurso. Ao conceder um papel a um membro, você concede todas as permissões contidas nele.
  • Política. A política do IAM é um conjunto de vinculações de papéis que associa um ou mais principais a papéis individuais. Quando você quiser definir quem (principal) tem qual tipo de acesso (papel) em um recurso, crie uma política e anexe-a ao recurso.

No diagrama anterior, por exemplo, a política do IAM vincula principais, como user@example.com, a papéis, como o Administrador do App Engine (roles/appengine.appAdmin). Se a política estiver anexada a um projeto, os membros receberão os papéis especificados no projeto.

No restante desta página, descrevemos esses conceitos em mais detalhes.

No IAM, você concede acesso a principais. As solicitações podem ser dos seguintes tipos:

  • Conta do Google
  • Conta de serviço
  • Grupo do Google
  • Domínio do Google Workspace
  • Domínio do Cloud Identity
  • Todos os usuários autenticados
  • Todos os usuários

Conta do Google

Uma Conta do Google representa um desenvolvedor, um administrador ou qualquer outra pessoa que interaja com o Google Cloud. Qualquer endereço de e-mail associado a uma Conta do Google pode ser uma identidade, incluindo o gmail.com ou outros domínios. A inscrição de novos usuários é feita na página de inscrição da Conta do Google.

Conta de serviço

Uma conta de serviço é uma conta para um aplicativo em vez de um usuário final individual. Quando você executar um código hospedado no Google Cloud, o código será executado como a conta que você especificar. Para representar os diferentes componentes lógicos do aplicativo, crie quantas contas de serviço forem necessárias. Para mais informações sobre como usar uma conta de serviço no aplicativo, consulte Primeiros passos na autenticação.

Grupo do Google

Um Grupo do Google é uma coleção nomeada de Contas do Google e contas de serviço. Cada Grupo do Google tem um endereço de e-mail exclusivo associado ao Grupo. Para encontrar o endereço de e-mail associado a um Grupo do Google, clique em Sobre na página inicial de qualquer Grupo. Consulte a página inicial dos Grupos do Google para mais informações.

Os Grupos do Google são um modo prático de aplicar uma política de acesso a uma coleção de usuários. É possível conceder e alterar controles de acesso para um Grupo inteiro de uma só vez, em vez de conceder ou alterar controles de acesso a cada usuário ou conta de serviço individualmente. Também é possível adicionar e remover principais de um Grupo do Google com facilidade, em vez de atualizar uma política do IAM para adicionar ou remover usuários.

Os Grupos do Google não têm credenciais de login, e não é possível usá-los a fim de estabelecer uma identidade para fazer uma solicitação de acesso a um recurso.

Domínio do Google Workspace

Um domínio do Google Workspace representa um grupo virtual de todas as Contas do Google que foram criadas na conta do Google Workspace de uma organização. Os domínios do Google Workspace representam o nome de domínio da Internet de sua organização (como example.com) e, quando você adiciona um usuário ao seu domínio do Google Workspace, uma nova Conta do Google é criada para o usuário dentro desse grupo virtual (como username@example.com).

De maneira semelhante ao que ocorre nos Grupos do Google, os domínios do Google Workspace não são usados para estabelecer identidade, mas ativam o gerenciamento conveniente de permissões.

Domínio do Cloud Identity

Um domínio do Cloud Identity é semelhante ao do Google Workspace, porque ele representa um grupo virtual de todas as Contas do Google em uma organização. Entretanto, os usuários de domínio do Cloud Identity não têm acesso aos aplicativos e recursos do Google Workspace. Para mais informações, consulte Sobre o Cloud Identity.

Todos os usuários autenticados

O valor allAuthenticatedUsers é um identificador especial que representa todas as contas de serviço e todos os usuários na Internet que se autenticaram com uma Conta do Google. Esse identificador inclui contas que não estão conectadas a um domínio do Google Workspace ou do Cloud Identity, como contas pessoais do Gmail. Os usuários que não forem autenticados, como os visitantes anônimos, não serão incluídos.

Alguns tipos de recurso não são compatíveis com esse tipo de principal.

Todos os usuários

O valor allUsers é um identificador especial que representa qualquer pessoa que esteja na Internet, incluindo usuários autenticados e não autenticados.

Alguns tipos de recurso não são compatíveis com esse tipo de principal.

Quando um principal autenticado tenta acessar um recurso, o IAM verifica a política do recurso para determinar se a ação é permitida.

Veja nesta seção as entidades e os conceitos envolvidos no processo de autorização.

Recurso

Se um usuário precisar acessar um recurso específico do Google Cloud, será possível atribuir um papel a ele. Como exemplos de recursos, citamos projetos, instâncias do Compute Engine e buckets do Cloud Storage.

Alguns serviços oferecem suporte à concessão de permissões do IAM com granularidade melhor do que o nível do projeto. Por exemplo, é possível conceder o papel de Administrador do Storage (roles/storage.admin) a um determinado bucket do Cloud Storage ou conceder o papel de Administrador de instâncias do Compute (roles/compute.instanceAdmin) a um usuário de uma instância específica do Compute Engine.

Em outros casos, é possível conceder permissões do IAM no nível do projeto. As permissões são herdadas por todos os recursos desse projeto. Por exemplo, para conceder acesso a todos os buckets do Cloud Storage em um projeto, conceda acesso ao projeto e não a cada bucket individual. Da mesma forma, para conceder acesso a todas as instâncias do Compute Engine em um projeto, conceda acesso ao projeto e não a cada instância individual.

Para informações sobre quais papéis podem ser concedidos em qual recurso, consulte Como entender os papéis e confira a coluna Recurso menor para detalhes sobre um determinado papel.

Permissões

Com as permissões, você determina quais operações são permitidas em um recurso. No mundo do IAM, as permissões são representadas na forma de service.resource.verb, por exemplo, pubsub.subscriptions.consume.

As permissões geralmente têm correspondência de um para um em relação aos métodos da API REST. Ou seja, cada serviço do Google Cloud tem um conjunto associado de permissões para cada método da API REST que ele expõe. O autor da chamada precisa dessas permissões para chamar o método. Por exemplo, se você usar Pub/Sub e precisar chamar o método topics.publish(), precisará da permissão pubsub.topics.publish para esse tópico.

Você não concede permissões diretamente aos usuários. Em vez disso, identifica papéis que contenham as permissões apropriadas e concede esses papéis ao usuário. Para uma lista de todas as permissões disponíveis e os papéis que as contêm, consulte a referência de permissões.

Papéis

Um papel é um conjunto de permissões. Não é possível conceder uma permissão ao usuário diretamente. Em vez disso, você concede a eles um papel. Quando você faz isso, concede ao usuário todas as permissões contidas no papel.

Mapeamento de permissão de função

Há vários tipos de papel no IAM:

  • Papéis básicos: papéis historicamente disponíveis no Console do Google Cloud. Esses papéis são de Proprietário, Editor e Visualizador.

  • Papéis predefinidos: oferecem um controle de acesso mais preciso que os papéis básicos. Por exemplo, o papel predefinido de Editor do Pub/Sub (roles/pubsub.publisher) fornece acesso somente à publicação de mensagens em um tópico do Pub/Sub.

  • Papéis personalizados: criados para adaptar as permissões às necessidades da organização, quando não são atendidas pelos papéis predefinidos.

Para mais informações sobre papéis, consulte os seguintes recursos:

Política de IAM

É possível conceder papéis aos usuários criando uma política do IAM, que é um conjunto de instruções que define quem tem qual tipo de acesso. Esta política é anexada a um recurso e, sempre que ele é acessado, o controle de acesso é aplicado.

Política do IAM

Uma política do IAM é representada pelo objeto Policy do IAM. Um objeto Policy do IAM consiste em uma lista de vinculações de papéis. Uma vinculação de papel vincula uma lista de principais a um papel.

  • role: o papel que você quer conceder ao principal. role é especificado na forma de roles/service.roleName. Por exemplo, o Cloud Storage fornece os papéis roles/storage.objectAdmin, roles/storage.objectCreator e roles/storage.objectViewer, entre outros.

  • members: uma lista de um ou mais principais, conforme descrito na seção Conceitos relacionados à identidade neste documento. Cada tipo de principal é identificado com um prefixo, como uma Conta do Google (user:), conta de serviço (serviceAccount:), Grupo do Google (group:) ou um domínio do Google Workspace ou do Cloud Identity (domain:). No exemplo de snippet de código a seguir, o papel storage.objectAdmin é concedido aos principais a seguir usando o prefixo apropriado: user:ali@example.com, serviceAccount:my-other-app@appspot.gserviceaccount.com, group:admins@example.com e domain:google.com. O papel objectViewer é concedido a user:maria@example.com.

O snippet de código a seguir mostra a estrutura de uma política do IAM.

{
  "bindings": [
    {
      "role": "roles/storage.objectAdmin",
       "members": [
         "user:ali@example.com",
         "serviceAccount:my-other-app@appspot.gserviceaccount.com",
         "group:admins@example.com",
         "domain:google.com"
       ]
    },
    {
      "role": "roles/storage.objectViewer",
      "members": [
        "user:maria@example.com"
      ]
    }
  ]
}

APIs do IAM e de política

O IAM fornece um conjunto de métodos que podem ser usados para criar e gerenciar políticas de controle de acesso nos recursos do Google Cloud. Esses métodos são expostos pelos serviços compatíveis com o IAM. Por exemplo, os métodos do IAM são expostos pelas APIs Resource Manager, Pub/Sub e Cloud Life Sciences, só para citar algumas.

Os métodos do IAM são:

  • setIamPolicy(): define políticas nos seus recursos.
  • getIamPolicy(): recebe uma política que foi definida anteriormente.
  • testIamPermissions(): testa se o autor da chamada tem as permissões especificadas para um recurso.

Encontre os tópicos de referência da API sobre esses métodos na documentação de cada serviço compatível com o IAM.

Hierarquia de recursos

Os recursos do Google Cloud são organizados hierarquicamente:

  • A organização é o nó raiz na hierarquia.
  • As pastas são filhos da organização.
  • Os projetos são filhos da organização ou de uma pasta.
  • Os recursos de cada serviço são descendentes de projetos.

Cada recurso tem um pai. Para mais informações, consulte a hierarquia de recursos do Resource Manager.

O diagrama a seguir é um exemplo de uma hierarquia de recursos do Google Cloud.

Hierarquia para recursos do IAM.

É possível definir uma política do IAM em qualquer nível da hierarquia de recursos: no nível da organização, da pasta, do projeto ou do recurso. Os recursos herdam as políticas de todos os recursos pai. A política efetiva para um recurso é a união do conjunto de políticas nesse recurso e as políticas herdadas do recurso mais alto na hierarquia.

Essa herança da política é transitiva. Em outras palavras, os recursos herdam as políticas do projeto que, por sua vez, herdam as políticas das pastas e estas herdam as políticas da organização. Portanto, as políticas no nível da organização também se aplicam no nível do recurso.

Por exemplo: no diagrama anterior, topic_a é um recurso do Pub/Sub que pertence ao projeto example-prod. Se você concede o papel de editor a micah@example.com para example-prod e concede o papel de publicador a song@example.com para topic_a, você efetivamente concede o papel de editor de topic_a a micah@example.com e o papel de publicador a song@example.com.

As políticas dos recursos filhos herdam as políticas dos recursos pai. Por exemplo, mesmo que seja concedido a um usuário o papel de editor de um projeto e o de leitor a um recurso filho, esse usuário ainda terá o papel de editor para o recurso filho. Se você alterar a hierarquia de recursos, a herança de políticas também será modificada. Por exemplo, quando um projeto é movido para uma organização, ele herda a política do IAM dessa organização.

Suporte do IAM para serviços do Google Cloud

Com o IAM, todos os métodos de API em todos os serviços do Google Cloud são verificados para garantir que a conta que faz a solicitação de API tenha a permissão apropriada para usar o recurso.

Os serviços do Google Cloud oferecem papéis predefinidos que concedem controle de acesso refinado. Por exemplo, o Compute Engine oferece papéis como administrador de instâncias do Compute e administrador de rede do Compute, e o App Engine oferece papéis como administrador do App Engine e administrador de serviço do App Engine.

Os papéis predefinidos estão disponíveis para a maioria dos serviços do Google Cloud. Para detalhes, consulte a lista de todos os papéis predefinidos. Caso seja necessário maior controle sobre as permissões, verifique se é possível criar um papel personalizado.

É possível conceder aos usuários papéis específicos para acessar recursos com granularidade maior do que a do nível do projeto. Por exemplo, é possível criar uma política de controle de acesso do IAM que conceda a um usuário o papel de assinante para um tópico específico do Pub/Sub. A lista de todos os papéis predefinidos mostra o tipo de recurso de nível mais baixo ou mais detalhado que aceita cada papel.

Modelo de consistência para a API IAM

Quando você lê dados da API IAM, cada leitura tem consistência eventual. Em outras palavras, se você gravar dados com a API IAM e ler imediatamente esses dados, a operação de leitura poderá retornar uma versão mais antiga dos dados. Após um pequeno atraso, é possível ler a nova versão dos dados. Esse atraso normalmente é medido em segundos, não em minutos.

Por outro lado, gravar dados na API IAM é sequencialmente consistente. Em outras palavras, as operações de gravação sempre são processadas na ordem em que foram recebidas.

Esses modelos de consistência afetam o funcionamento da API IAM. Por exemplo, se você criar uma conta de serviço e se referir imediatamente a ela em outra solicitação, a API IAM poderá informar que a conta de serviço não foi encontrada. Esse comportamento ocorre porque as operações de leitura têm consistência eventual e pode levar algum tempo para a nova conta de serviço ficar visível.

Para lidar com esse comportamento, o aplicativo pode repetir a solicitação com espera exponencial truncada.

A seguir

Faça um teste

Se você começou a usar o Google Cloud agora, crie uma conta para avaliar o desempenho dos nossos produtos em situações reais. Clientes novos também recebem US$ 300 em créditos para executar, testar e implantar cargas de trabalho.

Comece a usar gratuitamente