Visão geral

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

O Google Cloud Platform (GCP) oferece o Cloud IAM, que permite gerenciar o controle de acesso definindo a identidade de cada acesso (papel) para cada recurso.

IAM

Com o Cloud IAM, é possível conceder acesso detalhado a determinados recursos do GCP e evitar o acesso desnecessário a outros. É possível adotar o princípio de segurança de privilégio mínimo com o Cloud IAM, de modo que você conceda apenas o acesso necessário aos recursos.

No Cloud 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 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. Qualquer endereço de e-mail associado a uma conta do Google é uma identidade, incluindo 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

Conta de serviço é uma conta que pertence ao aplicativo, e 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. 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. 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 de todas as contas do Google criadas na conta do G Suite de uma organização. Os domínios dele representam o nome de domínio da Internet da organização, como example.com e ao adicionar um usuário ao domínio do G Suite, 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 G Suite 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 G Suite, porque representa um grupo virtual de todos os membros em uma organização. Entretanto, os usuários de domínio do Cloud Identity não têm acesso aos aplicativos e recursos do G Suite. Para mais informações, consulte as informações Sobre o Cloud Identity.

allAuthenticatedUsers

O valor allAuthenticatedUsers é um identificador especial que representa todas as contas de serviço e todos os usuários da Internet que realizaram a autenticação com uma Conta do Google. Esse identificador inclui contas que não estão conectadas a um domínio do G Suite ou do Cloud Identity, como contas pessoais do Gmail. Os usuários não autenticados, como visitantes anônimos, não estã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 Cloud IAM verifica a política do Cloud IAM 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

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

Alguns serviços, como o Compute Engine e o Cloud Storage, podem conceder permissões do Cloud IAM em uma granularidade melhor que a do nível do projeto. Por exemplo, é possível conceder o papel de Administrador do Storage (roles/storage.admin) a um usuário em um determinado intervalo do Cloud Storage, ou conceder o papel de Administrador da Instância do Compute (roles/compute.instanceAdmin) a um usuário em uma instância específica do Compute Engine.

Em outros casos, você pode conceder permissões do Cloud 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 intervalos do Cloud Storage em um projeto, conceda acesso ao projeto e não a cada intervalo 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 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, o autor da chamada do Publisher.Publish() precisa da permissão do pubsub.topics.publish.

Você não concede permissões aos usuários diretamente. Em vez disso, precisa atribuir a eles um papel que contém uma ou mais permissões.

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 continuarão funcionando. São os papéis de Proprietário, Editor e Leitor.

  • Papéis predefinidos: são papéis do Cloud IAM com controle de acesso mais granular do que os primitivos. Por exemplo, com o papel predefinido de Editor do Pub/Sub (roles/pubsub.publisher) é possível acessar apenas para publicar mensagens em um tópico do Cloud 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 atribuir um papel ao usuário, consulte Como conceder, alterar e revogar acesso. Para informações sobre os papéis predefinidos específicos do Cloud IAM, 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

Para conceder papéis a usuários, crie uma política do Cloud IAM que é 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

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

role é o papel que você quer atribuir ao membro. Esse role é especificado no formato roles/<name of the role>. Por exemplo, roles/storage.objectAdmin, roles/storage.objectCreator e roles/storage.objectViewer.

members contém uma lista de uma ou mais identidades, conforme descrito na seção acima, Conceitos relacionados à identidade. Cada tipo de membro é identificado com um prefixo, como uma conta do Google, (user:), conta de serviço, (serviceAccount:), grupo do Google (group:) ou um domínio de identidade do G Suite ou Cloud, (domain:). No snippet de exemplo abaixo, o papel storage.objectAdmin é atribuído aos membros abaixo usando o prefixo apropriado: user:alice@example.com, serviceAccount:my-other-app@appspot.gserviceaccount.com, group:admins@example.com e domain:google.com. O papel objectViewer é atribuído ao user:bob@example.com.

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

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

Cloud IAM e APIs de política

O Cloud IAM fornece um conjunto de métodos usados para criar e gerenciar políticas de controle de acesso nos recursos do GCP. Estes 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 Cloud Genomics APIs, apenas para citar algumas.

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 da raiz da hierarquia, os projetos são os filhos da organização e os outros recursos são os descendentes dos projetos. Cada recurso tem um pai. Para mais informações, consulte o tópico Hierarquia de Recursos do Resource Manager.

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

Hierarquia de recursos

É possível configurar uma política 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. Quando uma política é configurada no nível da organização, ela é herdada automaticamente por todos os projetos filhos e, quando configurada para envolvidos no projeto, é herdada por todos os recursos filhos. A política efetiva para um recurso é a união do conjunto de políticas nesse recurso e a política herdada a partir 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 acima, topic_a é um recurso do Cloud Pub/Sub que reside no projeto example-prod. Ao conceder o papel de editor a micah@gmail.com para example-prod e o papel de editor a song@gmail.com para topic_a, você efetivamente concede o papel de editor de topic_a a micah@gmail.com e o papel de editor a song@gmail.com.

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 concedido em um nível superior. 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.

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 e Visualizador. Esses papéis dão amplo acesso a um projeto e não permitem a separação granular de tarefas. Agora, os outros papéis oferecidos nos serviços do GCP têm controle de acesso mais específico do que os de Proprietário, Editor e Visualizador. Por exemplo, no Compute Engine são oferecidos papéis como Administrador de instâncias e Administrador de rede. No App Engine, há 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 papéis predefinidos estão disponíveis para a maioria dos serviços do GCP. Para detalhes, consulte a lista de todos os papéis predefinidos. Caso seja necessário maior controle sobre as permissões, considere 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 Cloud IAM que conceda a um usuário o papel de Assinante em um determinado tópico do Cloud 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

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

Enviar comentários sobre…

Documentação do Cloud IAM