Vista geral da IAM

Esta página descreve como funciona o sistema de gestão de identidade e de acesso (IAM) do Google Cloude como pode usá-lo para gerir o acesso no Google Cloud.

O IAM é uma ferramenta para gerir a autorização detalhada para o Google Cloud. Por outras palavras, permite-lhe controlar quem pode fazer o quê em que recursos.

Acesso em Google Cloud

Todas as ações no Google Cloud requerem determinadas autorizações. Quando alguém tenta realizar uma ação no Google Cloud, por exemplo, criar uma instância de VM ou ver um conjunto de dados, o IAM verifica primeiro se tem as autorizações necessárias. Caso contrário, a IAM impede que realizem a ação.

Conceder autorizações a alguém no IAM envolve os seguintes três componentes:

  • Principal: a identidade da pessoa ou do sistema ao qual quer conceder autorizações
  • Função: o conjunto de autorizações que quer conceder ao principal
  • Recurso: o recurso Google Cloud ao qual quer permitir o acesso ao principal

Para conceder ao principal autorização para aceder ao recurso, atribui-lhe a função no recurso. Concede estas funções através de uma política de permissão.

As secções seguintes descrevem estes conceitos mais detalhadamente.

Diretores

No Google Cloud , controla o acesso para diretores. Os principais representam uma ou mais identidades que foram autenticadas em Google Cloud.

Anteriormente, os diretores eram denominados membros. Algumas APIs continuam a usar esse termo.

Existem vários tipos de responsáveis no IAM, mas podem ser divididos em duas categorias gerais:

  • Utilizadores humanos: alguns tipos de principais da IAM representam utilizadores humanos. Usa estes tipos principais para gerir o acesso dos seus funcionários aos Google Cloud recursos.

    Os tipos principais que representam utilizadores humanos incluem Contas Google, grupos Google e identidades federadas em conjuntos de identidades da força de trabalho.

  • Cargas de trabalho: alguns tipos de principais da IAM representam cargas de trabalho. Use estes tipos de principais quando gerir o acesso dos seus recursos de cargas de trabalho.Google Cloud

    Os tipos de principais que representam cargas de trabalho incluem contas de serviço e identidades federadas num Workload Identity Pool.

Para mais informações sobre os principais, consulte Principais do IAM.

Autorizações e funções

As autorizações determinam que operações são permitidas num recurso. No IAM, as autorizações são normalmente representadas no formato service.resource.verb. Muitas vezes, as autorizações correspondem individualmente aos métodos da API REST. Por exemplo, a autorização resourcemanager.projects.list permite-lhe listar projetos do Resource Manager.

Não pode conceder autorizações diretamente a um principal. Em alternativa, concede autorizações aos principais atribuindo-lhes funções.

As funções são conjuntos de autorizações. Quando atribui uma função a um principal, concede a esse principal todas as autorizações nessa função.

Existem três tipos de funções:

  • Funções predefinidas: funções geridas pelos serviços Google Cloud . Estas funções contêm as autorizações necessárias para realizar tarefas comuns para cada serviço específico. Por exemplo, a função de publicador do Pub/Sub (roles/pubsub.publisher) dá acesso à publicação de mensagens num tópico do Pub/Sub.

  • Funções personalizadas: funções que cria e que contêm apenas as autorizações que especifica. Tem controlo total sobre as autorizações nestas funções. No entanto, têm um encargo de manutenção mais elevado do que as funções predefinidas e existe um limite para o número de funções personalizadas que pode ter no seu projeto e na sua organização.

  • Funções básicas: funções altamente permissivas que oferecem um amplo acesso aos Google Cloud serviços. Estas funções podem ser úteis para fins de teste, mas não devem ser usadas em ambientes de produção.

Para mais informações acerca das funções e autorizações, consulte o artigo Funções e autorizações.

Recursos

A maioria Google Cloud dos serviços tem os seus próprios recursos. Por exemplo, o Compute Engine tem recursos como instâncias, discos e sub-redes.

No IAM, concede funções num recurso. Conceder a um principal uma função num recurso significa que o principal pode usar as autorizações nessa função para aceder ao recurso.

Pode conceder funções num subconjunto de Google Cloud recursos. Para ver uma lista completa dos recursos aos quais pode conceder funções, consulte o artigo Tipos de recursos que aceitam políticas de permissão.

Google Cloud também tem vários recursos de contentores, incluindo projetos, pastas e organizações. Conceder a um principal uma função num recurso de contentor dá ao principal acesso ao recurso de contentor e aos recursos nesse contentor. Esta funcionalidade permite-lhe usar uma única concessão de função para conceder a um principal acesso a vários recursos, incluindo recursos nos quais não pode conceder funções diretamente. Para mais informações, consulte a secção Herança de políticas nesta página.

Políticas de permissão

Concede funções a responsáveis através de políticas de permissão. Anteriormente, estas políticas eram denominadas políticas de IAM.

Uma política de permissão é um objeto YAML ou JSON anexado a um recurso Google Cloud.

O diagrama seguinte mostra a estrutura de uma política de permissão:

Uma política de permissão com duas associações de funções. As associações de funções associam principais específicos a funções específicas.

Cada política de autorização contém uma lista de associações de funções que associam funções de IAM aos responsáveis aos quais essas funções são concedidas.

Quando um principal autenticado tenta aceder a um recurso, o IAM verifica a política de autorização do recurso para determinar se o principal tem as autorizações necessárias. Se o principal estiver numa associação de funções que inclua uma função com as autorizações necessárias, tem autorização para aceder ao recurso.

Para ver exemplos de políticas de autorização e saber mais sobre a respetiva estrutura, consulte o artigo Compreender as políticas de autorização.

Herança de políticas

Google Cloud tem recursos de contentores, como projetos, pastas e organizações, que lhe permitem organizar os seus recursos numa hierarquia principal-secundária. Esta hierarquia é denominada hierarquia de recursos.

A hierarquia de recursos Google Cloud tem a seguinte estrutura:

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

O diagrama seguinte é um exemplo de uma Google Cloud hierarquia de recursos:

Hierarquia para recursos de IAM.

Se definir uma política de autorização num recurso de contentor, a política de autorização também se aplica a todos os recursos nesse contentor. Este conceito é denominado herança de políticas, porque os recursos descendentes herdam efetivamente as políticas de autorização dos recursos ascendentes.

A herança de políticas tem as seguintes implicações:

  • Pode usar uma única associação de funções para conceder acesso a vários recursos. Se quiser conceder a um principal acesso a todos os recursos num contentor, conceda-lhe uma função no contentor em vez de nos recursos no contentor.

    Por exemplo, se quiser permitir que o seu administrador de segurança faça a gestão das políticas de permissão para todos os recursos na sua organização, pode conceder-lhe a função de administrador de segurança (roles/iam.securityAdmin) na organização.

  • Pode conceder acesso a recursos que não têm as suas próprias políticas de permissão. Nem todos os recursos aceitam políticas de permissão, mas todos os recursos herdam políticas de permissão dos respetivos antecessores. Para conceder a um principal acesso a um recurso que não pode ter a sua própria política de autorização, conceda-lhe uma função num dos antecessores do recurso.

    Por exemplo, imagine que quer conceder a alguém autorização para escrever registos num contentor de registos. Os contentores de registos não têm as suas próprias políticas de autorização, pelo que, para conceder esta autorização a alguém, pode, em alternativa, conceder-lhe a função de escritor do contentor de registos (roles/logging.bucketWriter) no projeto que contém o contentor de registos.

  • Para saber quem pode aceder a um recurso, também tem de ver todas as políticas de autorização que afetam o recurso. Para obter uma lista completa dos principais que têm acesso ao recurso, tem de ver a política de autorização do recurso e as políticas de autorização dos antecessores do recurso. A união de todas estas políticas é denominada política de autorização em vigor.

Para mais informações acerca da herança de políticas para políticas de autorização, consulte o artigo Usar a hierarquia de recursos para controlo de acesso.

Controlo de acesso avançado

Além das políticas de autorização, o IAM fornece os seguintes mecanismos de controlo de acesso para ajudar a refinar quem tem acesso a que recursos:

  • Tipos de políticas adicionais: o IAM oferece os seguintes tipos de políticas, além das políticas de permissão:

    • Políticas de negação: as políticas de negação impedem que os principais usem determinadas autorizações, mesmo que lhes seja concedida uma função com a autorização.

    • Políticas de limite de acesso principal (PAB): as políticas de limite de acesso principal definem e aplicam os recursos que um principal é elegível para aceder. Os principais não podem aceder a recursos aos quais não são elegíveis para aceder, mesmo que lhes tenha sido concedida uma função no recurso.

    Para saber mais acerca destas políticas, consulte o artigo Tipos de políticas.

  • Condições da IAM: as condições da IAM permitem-lhe definir e aplicar o controlo de acesso condicional baseado em atributos. Pode usar condições em vários tipos de políticas. Por exemplo, pode adicionar uma condição a uma associação de funções numa política de autorização para garantir que a função só é concedida se a condição for cumprida.

    Pode escrever condições com base em atributos como o recurso no pedido e a hora do pedido.

    Para saber mais sobre as condições do IAM, consulte a vista geral das condições do IAM.

  • Gestor de acesso privilegiado (PAM): com o Gestor de acesso privilegiado, pode permitir que os principais peçam e recebam acesso temporário e auditável aos recursos. Por exemplo, pode exigir que os principais peçam acesso sempre que pretendam ver um recurso sensível, em vez de lhes conceder permanentemente uma função de IAM.

    Também pode configurar se os principais têm de fornecer justificações ou receber aprovações quando pedem acesso.

    Para saber mais sobre o Gestor de acesso privilegiado, consulte a vista geral do Gestor de acesso privilegiado.

Modelo de consistência para a API IAM

A API IAM é eventualmente consistente. Por outras palavras, se escrever dados com a API IAM e, em seguida, ler imediatamente esses dados, a operação de leitura pode devolver uma versão mais antiga dos dados. Além disso, as alterações que fizer podem demorar algum tempo a afetar as verificações de acesso.

Este modelo de consistência afeta o funcionamento da API IAM. Por exemplo, se criar uma conta de serviço e, de seguida, fizer referência a essa conta de serviço noutro pedido, a API IAM pode indicar que não foi possível encontrar a conta de serviço. Este comportamento ocorre porque as operações são eventualmente consistentes. Pode demorar algum tempo até que a nova conta de serviço fique visível para pedidos de leitura.

O que se segue?

Experimente

Se for um novo utilizador do Google Cloud, crie uma conta para avaliar o desempenho dos nossos produtos em cenários reais. Os novos clientes também recebem 300 USD em créditos gratuitos para executar, testar e implementar cargas de trabalho.

Comece gratuitamente