Visão geral

Nesta página, você encontra os conceitos básicos do Google Cloud Identity and Access Management.

O Google Cloud Platform (GCP) oferece o Cloud IAM, que permite gerenciar o controle de acesso por meio da definição de quem (membros) tem qual acesso (papel) a qual recurso.

IAM

Com o Cloud IAM, você pode conceder maior acesso granular a recursos específicos do GCP e evitar acesso indesejado a outros. Com o Cloud IAM, é possível adotar o princípio de segurança de privilégio mínimo, de modo que você conceda apenas o acesso necessário aos recursos.

O Cloud IAM também funciona com o Cloud Identity-Aware Proxy (Cloud IAP) para garantir o acesso aos aplicativos. Para saber mais sobre o Cloud IAP, consulte a Visão geral do Cloud Identity-Aware Proxy.

No Cloud IAM, você concede acesso a membros. Eles podem ser dos seguintes tipos:

  • Conta do Google
  • conta de serviço
  • grupo do Google
  • domínio do G Suite
  • 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 GCP. Um endereço de e-mail associado a uma Conta do Google, como um endereço do gmail.com, pode ser uma identidade. Os novos usuários podem se inscrever na página de inscrição da Conta do Google.

Conta de serviço

Uma conta de serviço é uma conta que pertence ao aplicativo, não a um usuário final individual. Quando você executa um código hospedado no GCP, especifica a conta em que o código será executado. Para representar os diferentes componentes lógicos do aplicativo, crie quantas contas de serviço forem necessárias. Consulte a documentação de Contas de serviço do Console do Google Cloud Platform para mais informações.

Grupo do Google

Um grupo do Google é uma coleção nomeada de Contas do Google e contas de serviço. Todo grupo tem um endereço de e-mail exclusivo associado a ele. Para encontrar esse e-mail, clique em Sobre na página inicial do grupo. Para mais informações, consulte a página inicial dos grupos do Google.

Os grupos do Google são um modo prático de aplicar uma política de acesso a uma coleção de usuários. Em vez de gerenciar o acesso de cada usuário ou conta de serviço, conceda e altere os controles de acesso de um grupo inteiro de uma só vez. Além disso, adicione e remova membros de um grupo do Google com facilidade em vez de atualizar uma política do Cloud IAM para adicionar ou remover usuários.

Observe que os grupos do Google não têm credenciais de login e não é possível usá-los a fim de estabelecer a identidade para solicitar o acesso a um recurso.

Domínio do G Suite

Um domínio do G Suite representa um grupo virtual com todos os membros de uma organização. Os clientes do G Suite podem associar as contas de e-mail a um nome de domínio da Internet. Assim, cada conta fica com o formato nomedeusuario@seudominio.com. Qualquer nome de domínio de Internet associado a uma conta do G Suite pode ser usado para especificar uma identidade.

Assim como ocorre com os grupos, não é possível utilizar os domínios para estabelecer a identidade, mas o gerenciamento das permissões torna-se mais prático.

Domínio do Cloud Identity

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

allAuthenticatedUsers

Esse identificador especial representa qualquer pessoa autenticada com uma Conta do Google ou uma conta de serviço.

allUsers

Esse identificador especial representa qualquer pessoa na Internet, com ou sem uma conta do Google. Observe que algumas APIs exigem autenticação de qualquer usuário que acessa o serviço e, nesses casos, allUsers apenas implicará autorização para todos os usuários autenticados.

Depois que o membro que fez uma solicitação é autenticado no Google, uma decisão de autorização é tomada no Cloud IAM para definir se esse membro tem permissão para executar uma operação em um recurso.

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

Recurso

Você pode conceder acesso aos usuários para um recurso do GCP. Alguns exemplos de recursos são: projetos, instâncias do Compute Engine e intervalos do Cloud Storage.

Permissões

Com as permissões, você determina quais operações são permitidas em um recurso. No Cloud IAM, as permissões são representadas no formato <service>.<resource>.<verb>, por exemplo, pubsub.subscriptions.consume.

Geralmente, a correspondência entre as permissões e os métodos REST é de 1:1. Ou seja, cada serviço do GCP tem um conjunto de permissões associado para cada método REST que ele expõe. O autor da chamada precisa dessas permissões para chamar o método. Por exemplo, quem chama Publisher.Publish() precisa da permissão pubsub.topics.publish.

Papéis

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.

Mapeamento de permissão de função

Há três tipos de papel no Cloud IAM:

  • Papéis primitivos: os papéis disponíveis anteriormente no Console do Google Cloud Platform continuam funcionando. São eles: Proprietário, Editor e Visualizador.

  • Papéis predefinidos: são papéis do Cloud IAM com controle de acesso mais granular do que os primitivos. Por exemplo, o papel predefinido de Editor fornece acesso apenas a mensagens de publicação para um tópico do Cloud Pub/Sub.

  • Papéis personalizados: são papéis que você cria para configurar permissões que atendam às necessidades da sua organização, quando isso não é possível com os predefinidos.

Para mais informações sobre os papéis do Cloud IAM específicos, consulte Como entender os papéis.

Política

Para conceder papéis a usuários, crie uma política do Cloud IAM, uma coleção de instruções que define quem tem qual tipo de acesso. Essa política é anexada a um recurso e, sempre que ele é acessado, o controle de acesso é aplicado.

Política de IAM

A política do Cloud IAM é representada pelo objeto Policy. Uma Policy consiste de uma lista de vinculações. Uma Binding vincula uma lista de members a um role.

O role é o papel a ser atribuído ao usuário. Esse role é especificado no formato roles/<name of the role>. Por exemplo, roles/owner, roles/editor e roles/viewer.

O snippet de código a seguir mostra a estrutura de uma política do Cloud IAM. Nessa política, o papel de owner é atribuído a alice@example.com, admins@example.com, google.com e my-other-app@appspot.gserviceaccount.com, e o papel de viewer a bob@example.com.

{
  "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/viewer",
     "members": ["user:bob@example.com"]
   }
   ]
}

Cloud IAM e Policy APIs

O Cloud IAM fornece um conjunto padrão de métodos que você pode usar para criar e gerenciar políticas de controle de acesso nos recursos do GCP. Esses métodos são expostos pelos serviços compatíveis com o Cloud IAM. Por exemplo, os métodos do Cloud IAM são expostos pelas Resource Manager, Cloud Pub/Sub e Genomics APIs.

Os métodos do Cloud IAM são:

  • setIamPolicy(): permite configurar políticas nos recursos;
  • getIamPolicy(): permite receber uma política previamente configurada;
  • testIamPermissions(): permite testar se o autor da chamada tem as permissões específicas para um recurso.

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

Hierarquia de políticas

Os recursos do GCP são organizados hierarquicamente. Nele, o node da Organização é o node da raiz da hierarquia, os projetos são os filhos da Organização e os outros recursos são os filhos dos projetos. Cada recurso tem um pai.

O diagrama a seguir é um exemplo de uma hierarquia de recursos do GCP:

Hierarquia de recursos

É possível definir uma política controle de acesso do Cloud 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 do pai. Se uma política é definida para envolvidos na organização, ela é herdada automaticamente por todos os projetos filhos. Se essa política é definida para envolvidos no projeto, é herdada por todos os recursos filhos. A política efetiva de um recurso é a união da política definida para o recurso com a herdada do pai dele.

Essa herança é transitiva, ou seja, os recursos herdam as políticas do projeto, que herda as políticas da organização. Isso significa que as políticas para envolvidos na organização também são aplicadas ao nível do recurso.

Por exemplo, no diagrama acima, topic_a é um recurso do Cloud Pub/Sub que fica sob o projeto example-test. Se você conceder o papel de editor a micah@gmail.com para example-test e conceder o papel de publicador a song@gmail.com para topic_a, efetivamente concederá o papel de editor a micah@gmail.com e o de publicador a song@gmail.com para topic_a.

A hierarquia da política do Cloud IAM segue o mesmo caminho que a hierarquia do recurso do GCP. Se você alterar a hierarquia do recurso, a da política também será modificada. Por exemplo, quando um projeto é movido para uma organização, a política do Cloud IAM desse projeto herda a política da organização.

As políticas filho não restringem o acesso ao pai. Por exemplo, mesmo que você conceda a um usuário o papel de editor de um projeto e o de visualizador de um recurso filho, esse usuário ainda manterá o papel de editor do recurso filho.

Compatibilidade do Cloud IAM com serviços do GCP

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

Antes do Cloud IAM, você só conseguia conceder os papéis de Proprietário, Editor ou Visualizador. Com esses papéis, o acesso concedido a um projeto é muito amplo e não permite a separação das tarefas. Agora, os papéis adicionais oferecidos nos serviços do GCP têm controle de acesso mais detalhado do que os de Proprietário, Editor e Visualizador. Por exemplo, no Google Compute Engine, há papéis como Administrador de instâncias e Administrador de rede. No App Engine, são oferecidos papéis como Administrador de app e Administrador de serviço. Esses papéis predefinidos estão disponíveis além dos papéis legados de Proprietário, Editor e Visualizador.

Os produtos a seguir oferecem papéis predefinidos do Cloud IAM:

Para uma lista completa de papéis predefinidos, consulte Como entender os papéis.

Alguns papéis podem ser concedidos aos usuários para que eles acessem os recursos em uma granularidade menor do que para envolvidos no projeto. Por exemplo, você pode criar uma política de controle de acesso do Cloud IAM que conceda o papel do Assinante a um usuário para um tópico particular do Cloud Pub/Sub. Para mais informações sobre quais papéis podem ser concedidos em quais recursos, consulte Como entender os papéis.

Próximas etapas

Esta página foi útil? Conte sua opinião sobre:

Enviar comentários sobre…

Documentação do Cloud Identity and Access Management