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 membros autenticados. Uma política do IAM define e aplica quais papéis são concedidos a quais membros, e essa política é anexada a um recurso. Quando um membro 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.

Arquitetura do IAM.

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

  • Membro. Um membro 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 do Cloud Identity que pode acessar um recurso. A identidade de um membro é 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 vincula um ou mais membros a um papel. Quando você quiser definir quem (membro) 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 membros, como userid@gmail.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 membros. Os membros 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

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 membros 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.

allAuthenticatedUsers

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.

allUsers

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

Quando um membro 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 saber como conceder um papel ao usuário, consulte Como conceder, alterar e revogar o acesso. Para informações sobre os papéis predefinidos do IAM disponíveis, consulte Noções básicas sobre papéis. Para informações sobre papéis personalizados, consulte Noções básicas sobre papéis personalizados e Como criar e gerenciar papéis personalizados.

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. Um Binding vincula uma lista de members a um role.

  • role: o papel que você quer conceder ao membro. 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 uma ou mais identidades, conforme descrito na seção Conceitos relacionados à identidade neste documento. Cada tipo de membro é identificado com um prefixo, como uma Conta do Google (user: ), conta de serviço (serviceAccount: ), Grupo do Google (group: ), um domínio do Google Workspace ou do Cloud Identity (domain:). No snippet de código de exemplo a seguir, o papel storage.objectAdmin é concedido aos membros a seguir pelo uso do 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.

A seguir