Visão geral do IAM

Esta página descreve como Google Cloud's funciona o sistema do Identity and Access Management (IAM) e como usá-lo para gerenciar o acesso em 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 no 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. Se não tiver, o IAM impede que ela realize a ação.

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

  • 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 Google Cloud recurso ao qual você quer permitir o acesso do principal.

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

As políticas de permissão são anexadas diretamente a alguns Google Cloud recursos, que são organizados hierarquicamente. Por exemplo, os projetos contêm recursos específicos do serviço. Isso significa que você pode conceder acesso a um único recurso ou a um contêiner de recursos.

As seções a seguir descrevem esses conceitos com 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 amplas:

  • 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 Google Cloud recursos.

    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 das cargas de trabalho aos Google Cloud recursos.

    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 os 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 são normalmente 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 a eles.

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

Há três tipos de papéis:

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

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

  • Papéis básicos: papéis altamente permissivos que fornecem acesso amplo a Google Cloud serviços. 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 Google Cloud serviços tem os próprios recursos. Por exemplo, o Compute Engine tem recursos como instâncias, discos e sub-redes.

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

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

Google Cloud também tem recursos de contêiner, incluindo projetos, pastas e organizações. Esses recursos de contêiner são organizados hierarquicamente, o que permite que os recursos filhos herdem as políticas dos recursos pai. Isso significa que 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. Esse recurso permite usar uma única concessão de papel para gerenciar o 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 Google Cloud recurso.

O diagrama a seguir mostra como uma política de permissão é estruturada:

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 Google Cloud hierarquia de recursos 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 Google Cloud hierarquia de recursos:

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 papel para conceder acesso a vários recursos. Se você quiser conceder acesso a todos os recursos em um contêiner, conceda um papel no contêiner em vez de nos recursos.

    Por exemplo, se você quiser permitir que o administrador de segurança gerencie 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.

  • É possível conceder acesso a recursos que não têm as 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 ancestrais. Para conceder acesso a um principal a um recurso que não pode ter a própria política de permissão, conceda um papel a um dos ancestrais do recurso.

    Por exemplo, imagine que você quer conceder a alguém permissão para gravar registros em um bucket de registros. Os buckets de registros não têm as próprias políticas de permissão. Portanto, para conceder essa permissão a alguém, conceda o papel 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, você também precisa visualizar todas as políticas de permissão que afetam o recurso. Para receber uma lista completa dos principais que têm acesso ao recurso, é necessário visualizar a política de permissão do recurso e as políticas de permissão dos ancestrais do recurso. 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 Usar a hierarquia de recursos para controle de acesso.

Controle de acesso avançado

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

  • Tipos de política adicionais: o IAM oferece os seguintes tipos de política , 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 permissões, mesmo que recebam um papel com a permissão.

    • Políticas de limite de acesso de principal (PAB): as políticas de limite de acesso de principal definem e aplicam os recursos que um principal pode acessar. Os principais não podem acessar recursos aos quais não são qualificados para acessar, mesmo que tenham recebido um papel no recurso.

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

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

    É possível gravar condições com base em atributos como o recurso na solicitação e a hora 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 Privileged Access Manager, é 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 permanentemente.

    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 Privileged Access Manager visão geral.

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. As mudanças feitas também podem levar algum tempo 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ê é novo no Google Cloud, crie uma conta para avaliar o desempenho dos nossos produtos em cenários reais. Clientes novos também ganham US $300 em créditos para executar, testar e implantar cargas de trabalho.

Comece a usar sem custo financeiro