Visão geral do IAM

Esta página descreve como Cloud de Confiance by S3NS's funciona o sistema do Identity and Access Management (IAM) e como usá-lo para gerenciar o acesso em Cloud de Confiance.

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

Acesso no Cloud de Confiance

Todas as ações no Cloud de Confiance exigem determinadas permissões. Quando alguém tenta realizar uma ação no Cloud de Confiance—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 Cloud de Confiance 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 Cloud de Confiance 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 Cloud de Confiance , você controla o acesso para principais. Os principais representam uma ou mais identidades autenticadas no Cloud de Confiance.

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 Cloud de Confiance recursos.

    Por exemplo, as identidades federadas em pools de identidade de colaboradores representam usuários humanos.

  • 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 Cloud de Confiance 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 Cloud de Confiance 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 Cloud de Confiance 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 Cloud de Confiance 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 Cloud de Confiance 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.

Cloud de Confiance 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 Cloud de Confiance recurso.

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

Cloud de Confiance 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 Cloud de Confiance 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 Cloud de Confiance 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:

  • 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. Para saber mais sobre políticas de negação, consulte Políticas de negação.

  • 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.

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