Vista geral da IAM

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

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

Acesso em Trusted Cloud

Todas as ações no Trusted Cloud requerem determinadas autorizações. Quando alguém tenta realizar uma ação no Trusted 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 Trusted 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 Trusted Cloud , controla o acesso para diretores. Os principais representam uma ou mais identidades que foram autenticadas em Trusted 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 Trusted Cloud recursos.

    Por exemplo, as identidades federadas nos Workload Identity Pools representam utilizadores humanos.

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

Trusted 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 Trusted Cloud.

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

Trusted 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 Trusted 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 Trusted 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:

  • 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. Para saber mais sobre as políticas de recusa, consulte o artigo Políticas de recusa.

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

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?