Visão geral do IAM

Nesta página, descrevemos como funciona o sistema do Identity and Access Management (IAM) do Google Cloud e como usá-lo para gerenciar o acesso no Google Cloud.

O IAM é uma ferramenta para gerenciar a autorização detalhada do Google Cloud. Em outras palavras, ele permite controlar quem pode fazer o quê em quais recursos.

Acesso em Google Cloud

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

Conceder permissões a alguém no IAM envolve os três componentes a seguir:

  • Principal: a identidade da pessoa ou do sistema a que você quer conceder permissões.
  • Papel: o conjunto de permissões que você quer conceder ao principal.
  • Recurso: o recurso Google Cloud que você quer permitir que o principal acesse.

Para conceder permissão ao principal para acessar o recurso, atribua a ele a função no recurso. Você concede esses papéis usando uma política de permissão.

As seções a seguir descrevem esses conceitos em mais detalhes.

Principais

No Google Cloud , você controla o acesso para principais. Os principais representam uma ou mais identidades autenticadas no Google Cloud.

No passado, os principais eram chamados de membros. Algumas APIs ainda usam esse termo.

Há vários tipos de principais no IAM, mas eles podem ser divididos em duas categorias gerais:

  • Usuários humanos: alguns tipos de principais do IAM representam usuários humanos. Você usa esses tipos principais para gerenciar o acesso dos funcionários aos recursos do Google Cloud .

    Os tipos principais que representam usuários humanos incluem contas do Google, grupos do Google e identidades federadas em pools de identidade de colaboradores.

  • Cargas de trabalho: alguns tipos de principais do IAM representam cargas de trabalho. Você usa esses tipos principais ao gerenciar o acesso dos recursos Google Cloud das suas cargas de trabalho.

    Os tipos principais que representam cargas de trabalho incluem contas de serviço e identidades federadas em um pool de Identidade da carga de trabalho.

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

Permissões e papéis

Com as permissões, você determina quais operações são permitidas em um recurso. No IAM, as permissões geralmente são representadas no formato service.resource.verb. Muitas vezes, as permissões têm correspondência de um para um com os métodos da API REST. Por exemplo, a permissão resourcemanager.projects.list permite listar projetos do Resource Manager.

Não é possível conceder permissões diretamente a um principal. Em vez disso, você concede permissões aos principais atribuindo papéis.

Papéis são coleções de permissões. Ao conceder um papel a um principal, você dá a ele todas as permissões desse papel.

Há três tipos de papéis:

  • Papéis predefinidos: papéis gerenciados pelos serviços do Google Cloud . Esses papéis contêm as permissões necessárias para realizar tarefas comuns em cada serviço. Por exemplo, o papel Publicador do Pub/Sub (roles/pubsub.publisher) permite publicar mensagens em um tópico do Pub/Sub.

  • Papéis personalizados: papéis criados por você que contêm apenas as permissões especificadas. Você tem controle total sobre as permissões nesses papéis. No entanto, elas têm uma carga de manutenção maior do que as funções predefinidas, e há um limite para o número de funções personalizadas que você pode ter no projeto e na organização.

  • Papéis básicos: papéis altamente permissivos que oferecem acesso amplo aos serviços do Google Cloud . Esses papéis podem ser úteis para fins de teste, mas não devem ser usados em ambientes de produção.

Para mais informações sobre papéis e permissões, consulte Papéis e permissões.

Recursos

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

No IAM, você concede papéis em um recurso. Conceder a um principal um papel em um recurso significa que ele pode usar as permissões desse papel para acessar o recurso.

É possível conceder papéis em um subconjunto de recursos do Google Cloud . Para uma lista completa de recursos em que é possível conceder papéis, consulte Tipos de recursos que aceitam políticas de permissão.

Google Cloud também tem vários recursos de contêiner, incluindo projetos, pastas e organizações. Conceder um papel a um principal em um recurso de contêiner dá ao principal acesso ao recurso de contêiner e aos recursos nesse contêiner. Com esse recurso, é possível usar uma única concessão de papel para dar a um principal acesso a vários recursos, incluindo aqueles em que não é possível conceder papéis diretamente. Para mais informações, consulte Herança de políticas nesta página.

Permitir políticas

Você concede papéis aos principais usando políticas de permissão. No passado, essas políticas eram chamadas de políticas do IAM.

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

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

Uma política de permissão com duas vinculações de papéis. As vinculações de papel associam principais específicos a papéis específicos.

Cada política de permissão contém uma lista de vinculações de papéis que associam papéis do IAM aos principais que recebem esses papéis.

Quando um principal autenticado tenta acessar um recurso, o IAM verifica a política de permissão do recurso para determinar se o principal tem as permissões necessárias. Se o principal estiver em uma vinculação de papel que inclua um papel com as permissões necessárias, ele poderá acessar o recurso.

Para ver exemplos de políticas de permissão e saber mais sobre a estrutura delas, consulte Noções básicas sobre políticas de permissão.

Herança de políticas

Google Cloud tem recursos de contêiner, como projetos, pastas e organizações, que permitem organizar os recursos em uma hierarquia pai-filho. Essa hierarquia é chamada de hierarquia de recursos.

A hierarquia de recursos Google Cloud tem a seguinte estrutura:

  • A organização é o nó raiz na hierarquia.
  • As pastas são filhos 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 a seguir é um exemplo de uma hierarquia de recursos do Google Cloud :

Hierarquia para recursos do IAM.

Se você definir uma política de permissão em um recurso de contêiner, ela também será aplicada a todos os recursos nesse contêiner. Esse conceito é chamado de herança de políticas, porque os recursos descendentes herdam as políticas de permissão dos recursos ancestrais.

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

  • É possível usar uma única vinculação de função para conceder acesso a vários recursos. Se você quiser dar a um principal acesso a todos os recursos em um contêiner, conceda a ele uma função no contêiner em vez de nos recursos dele.

    Por exemplo, se você quiser permitir que o administrador de segurança gerencie as políticas de permissão para todos os recursos da organização, conceda a ele o papel de Administrador de segurança (roles/iam.securityAdmin) na organização.

  • Você pode conceder acesso a recursos que não têm políticas de permissão próprias. Nem todos os recursos aceitam políticas de permissão, mas todos herdam políticas de permissão dos ancestrais. Para dar a uma principal acesso a um recurso que não pode ter uma política de permissão própria, conceda a ela um papel em um dos ancestrais do recurso.

    Por exemplo, imagine que você quer dar a alguém permissão para gravar registros em um bucket de registros. Os buckets de registros não têm políticas de permissão próprias. Para conceder a alguém essa permissão, atribua a função de gravador de bucket de registros (roles/logging.bucketWriter) no projeto que contém o bucket de registros.

  • Para entender quem pode acessar um recurso, também é necessário conferir todas as políticas de permissão que afetam o recurso. Para conferir uma lista completa dos principais que têm acesso ao recurso, consulte a política de permissão do recurso e as políticas de permissão dos ancestrais dele. A união de todas essas políticas é chamada de política de permissão efetiva.

Para mais informações sobre a herança de políticas de permissão, consulte Como usar a hierarquia de recursos para controle de acesso.

Controle de acesso avançado

Além das políticas de permissão, o IAM oferece os seguintes mecanismos de controle de acesso para ajudar você a refinar quem tem acesso a quais recursos:

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

    • Políticas de negação: impedem que os principais usem determinadas permissões, mesmo que tenham recebido um papel com a permissã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 pode acessar. Os principais não podem acessar recursos para os quais não estão qualificados, mesmo que tenham recebido uma função no recurso.

    Para saber mais sobre essas políticas, consulte Tipos de política.

  • Condições do IAM: com as condições do IAM, é possível definir e aplicar o controle de acesso condicional baseado em atributos. É possível usar condições em vários tipos de políticas. Por exemplo, é possível adicionar uma condição a uma vinculação de função em uma política de permissão para garantir que a função só seja concedida se a condição for atendida.

    É possível gravar condições com base em atributos como o recurso na solicitação e o horário da solicitação.

    Para saber mais sobre as condições do IAM, consulte Visão geral das condições do IAM.

  • Privileged Access Manager (PAM): com o PAM, é possível permitir que os principais solicitem e recebam acesso temporário e auditável aos recursos. Por exemplo, é possível exigir que os principais solicitem acesso sempre que quiserem visualizar um recurso sensível, em vez de conceder a eles um papel do IAM de forma permanente.

    Também é possível configurar se os principais precisam fornecer justificativas ou receber aprovações ao solicitar acesso.

    Para saber mais sobre o Privileged Access Manager, consulte a visão geral do Privileged Access Manager.

Modelo de consistência para a API IAM

A API IAM 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. Além disso, as alterações feitas podem demorar um pouco para afetar as verificações de acesso.

Esse modelo de consistência afeta 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 têm consistência posterior e pode levar algum tempo para que a nova conta de serviço se torne visível para solicitações de leitura.

A seguir

Faça um teste

Se você começou a usar o Google Cloudagora, 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