Esta página descreve como funciona o sistema de gerenciamento de identidade e acesso (IAM) do Google Cloud e como usá-lo para gerenciar o acesso em Google Cloud.
O IAM é uma ferramenta para gerenciar a autorização detalhada para Google Cloud. Em outras palavras, ele permite que você controle quem pode fazer o quê em quais recursos.
Acesso em Google Cloud
Todas as ações em Google Cloud exigem determinadas permissões. Quando alguém tenta realizar uma ação em Google Cloud, como 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 tiverem, o IAM vai impedir que eles realizem a ação.
Conceder permissões a alguém no IAM envolve os três seguintes componentes:
- Princípio: 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 que você quer permitir que o princípio acesse.
Para conceder a permissão de acesso ao principal, conceda 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
Em Google Cloud , você controla o acesso para principais. Os principais representam uma ou mais identidades que foram autenticadas para Google Cloud.
No passado, os administradores 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 principais do IAM representam usuários humanos. Você usa esses tipos principais para gerenciar o acesso dos funcionários aos recursosGoogle Cloud .
Os tipos principais que representam usuários humanos incluem contas do Google, grupos do Google e identidades federadas em pools de identidade da força de trabalho.
Cargas de trabalho: alguns tipos principais do IAM representam cargas de trabalho. Você usa esses tipos principais ao gerenciar os recursos de acesso Google Cloud das 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 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 geralmente são representadas no formato
service.resource.verb. Muitas vezes,
as permissões correspondem de um para um aos 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 concedendo 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 contidas nesse 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 de Editor do Pub/Sub (
roles/pubsub.publisher) dá 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 especificadas. Você tem controle total sobre as permissões nessas funções. 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 amplo acesso a serviçosGoogle Cloud . Essas funções podem ser úteis para fins de teste, mas não devem ser usadas 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 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 Google Cloud recursos. Para conferir 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 uma função 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 função 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 que é anexado a um recurso Google Cloud.
O diagrama a seguir mostra como uma política de permissão é estruturada:
Cada política de permissão contém uma lista de vinculações de papel que associam papéis do IAM aos principais que receberam 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 conferir 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 seus 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 hierarquia de recursos Google Cloud :
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 ancestral.
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 conceder a um principal acesso a todos os recursos em um contêiner, conceda a ele um papel no contêiner em vez de nos recursos no contêiner.
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.É possível conceder acesso a recursos que não têm 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 a um principal acesso a um recurso que não pode ter a própria política de permissão, conceda a ele um papel em um dos antepassados do recurso.
Por exemplo, imagine que você quer conceder a alguém a permissão para gravar registros em um bucket de registros. Os buckets de registro não têm políticas de permissão próprias. Para conceder essa permissão a alguém, conceda a função de escritor de bucket de registros (
roles/logging.bucketWriter) no projeto que contém o bucket.Para entender quem pode acessar um recurso, você também precisa conferir todas as políticas de permissão que afetam o recurso. Para conferir uma lista completa dos princípios que têm acesso ao recurso, você precisa conferir 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 Como usar a hierarquia de recursos para controle de acesso.
Controle de acesso avançado
Além de permitir políticas, o IAM oferece os seguintes mecanismos de controle de acesso para ajudar a refinar quem tem acesso a quais recursos:
Outros tipos de políticas: o IAM oferece os seguintes tipos de políticas, além das políticas de permissão:
Políticas de negação: impedem que os principais usem determinadas permissões, mesmo que tenham recebido uma função 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 participantes não podem acessar recursos que não estão qualificados para acesso, mesmo que tenham recebido um papel no recurso.
Para saber mais sobre essas políticas, consulte Tipos de políticas.
Condições do IAM: permitem definir e aplicar o controle de acesso condicional e 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 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 o horário da solicitação.
Para saber mais sobre as condições do IAM, consulte Visão geral das condições do IAM.
Gerenciador de acesso privilegiado (PAM): com o Privileged Access Manager, é possível permitir que os participantes solicitem e recebam acesso temporário e auditável aos recursos. Por exemplo, você pode exigir que os administradores solicitem acesso sempre que querem acessar um recurso sensível em vez de conceder permanentemente a eles um papel do IAM.
Também é possível configurar se os administradores precisam fornecer justificações ou receber aprovações quando solicitam acesso.
Para saber mais sobre o Privileged Access Manager, consulte 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
- Para saber como configurar identidades para Google Cloud, consulte Gerenciamento de identidade para Google Cloud.
- Para ver instruções sobre como conceder, mudar e revogar papéis do IAM aos principais, consulte Gerenciar o acesso a projetos, pastas e organizações.
- Para uma lista de papéis do IAM disponíveis, consulte Papéis predefinidos.
- Para ajuda sobre como escolher os papéis predefinidos mais apropriados, leia Escolher papéis predefinidos.
- Para mais informações sobre os tipos de política disponíveis no IAM, consulte Tipos de política.
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