Gestão de identidade e de acesso

Utilização

Esta página oferece uma vista geral da gestão de identidade e de acesso (IAM) e da respetiva utilização para controlar o acesso aos recursos de contentores, pastas geridas e objetos no Cloud Storage.

Vista geral

O IAM permite-lhe controlar quem tem acesso aos recursos no seu Google Cloud projeto. Os recursos incluem contentores do Cloud Storage, as pastas geridas nos contentores e os objetos armazenados nos contentores, bem como outras Google Cloud entidades, como instâncias do Compute Engine.

Os diretores são o "quem" do IAM. Os principais podem ser utilizadores individuais, grupos, domínios ou até mesmo o público em geral. Os principais recebem funções, que lhes dão a capacidade de realizar ações no Cloud Storage, bem como Google Cloud de forma mais geral. Cada função é uma coleção de uma ou mais autorizações. As autorizações são as unidades básicas do IAM: cada autorização permite-lhe realizar uma determinada ação.

Por exemplo, a autorização storage.objects.create permite-lhe criar objetos. Esta autorização encontra-se em funções como Storage Object Creator (roles/storage.objectCreator), que concede as autorizações úteis para criar objetos num contentor, e Storage Object Admin (roles/storage.objectAdmin), que concede uma vasta gama de autorizações para trabalhar com objetos.

O conjunto de funções IAM que define num recurso chama-se uma política de IAM. O acesso concedido por estas funções aplica-se ao recurso no qual a política está definida e a todos os recursos contidos nesse recurso. Por exemplo, pode definir uma política de IAM num contentor que dá a um utilizador controlo administrativo desse contentor e dos respetivos objetos. Também pode definir uma política de IAM no projeto geral que dê a outro utilizador a capacidade de ver objetos em qualquer contentor nesse projeto.

Se tiver um Google Cloud recurso da organização, também pode usar as políticas de recusa da IAM para recusar o acesso a recursos. Quando uma política de recusa está associada a um recurso, o principal na política não pode usar a autorização especificada para aceder ao recurso ou a qualquer sub-recurso no mesmo, independentemente das funções que lhe são concedidas. As políticas de negação substituem quaisquer políticas de permissão do IAM.

Autorizações

As autorizações permitem que os principais realizem ações específicas em contentores, pastas geridas ou objetos no Cloud Storage. Por exemplo, a autorização storage.buckets.list permite que um principal liste os contentores no seu projeto. Não concede autorizações diretamente aos principais. Em vez disso, concede funções, que têm uma ou mais autorizações incluídas.

Para uma lista de referência das autorizações de IAM que se aplicam ao Cloud Storage, consulte o artigo Autorizações de IAM para o Cloud Storage.

Funções

As funções são um conjunto de uma ou mais autorizações. Por exemplo, a função Storage Object Viewer (roles/storage.objectViewer) contém as autorizações storage.objects.get e storage.objects.list. Concede funções a diretores, o que lhes permite realizar ações nos contentores, nas pastas geridas e nos objetos no seu projeto.

Para uma lista de referência das funções de IAM que se aplicam ao Cloud Storage, consulte o artigo Funções de IAM para o Cloud Storage.

Conceder funções ao nível do projeto, do contentor ou da pasta gerida

Pode conceder funções a principais ao nível do projeto, do contentor ou da pasta gerida. As autorizações concedidas por essas funções aplicam-se de forma cumulativa em toda a hierarquia de recursos. Pode conceder funções em diferentes níveis da hierarquia de recursos para ter maior detalhe no seu modelo de autorizações.

Por exemplo, suponhamos que quer conceder a um utilizador autorização para ler objetos em qualquer contentor num projeto, mas criar objetos apenas no contentor A. Para o conseguir, pode atribuir ao utilizador a função de leitor de objetos de armazenamento (roles/storage.objectViewer) para o projeto, o que lhe permite ler qualquer objeto armazenado em qualquer contentor no seu projeto, e a função de criador de objetos de armazenamento (roles/storage.objectCreator) para o contentor A, o que lhe permite criar objetos apenas nesse contentor.

Algumas funções podem ser usadas em todos os níveis da hierarquia de recursos. Quando usadas ao nível do projeto, as autorizações que contêm aplicam-se a todos os contentores, pastas e objetos no projeto. Quando usadas ao nível do contentor, as autorizações aplicam-se apenas a um contentor específico e às pastas e aos objetos no respetivo interior. Seguem-se exemplos de funções deste tipo: função de administrador do armazenamento (roles/storage.admin), função de visualizador de objetos de armazenamento (roles/storage.objectViewer) e função de criador de objetos de armazenamento (roles/storage.objectCreator).

Algumas funções só podem ser aplicadas num nível. Por exemplo, só pode aplicar a função Storage Legacy Object Owner (roles/storage.legacyObjectOwner) ao nível do contentor ou da pasta gerida. As funções do IAM que lhe permitem controlar as políticas de recusa do IAM só podem ser aplicadas ao nível da organização.

Relação com as LCAs

Além da IAM, os seus contentores e objetos podem usar um sistema de controlo de acesso antigo denominado listas de controlo de acesso (LCAs) se a funcionalidade de acesso uniforme ao nível do contentor não estiver ativada para o seu contentor. Geralmente, deve evitar usar LCAs e ativar o acesso uniforme ao nível do contentor para o seu contentor. Esta secção aborda o que deve ter em atenção se permitir a utilização de ACLs para um contentor e os objetos no mesmo.

As funções IAM do contentor antigo funcionam em conjunto com as ACLs do contentor: quando adiciona ou remove uma função do contentor antigo, as ACLs associadas ao contentor refletem as suas alterações. Da mesma forma, a alteração de uma LCA específica do contentor atualiza a função de IAM do contentor antigo correspondente para o contentor.

Função de contentor antigo LCA equivalente
Leitor do contentor antigo de armazenamento (roles/storage.legacyBucketReader) Leitor de contentores
Escritor de contentor antigo de armazenamento (roles/storage.legacyBucketWriter) Escritor de contentores
Proprietário do contentor antigo do armazenamento (roles/storage.legacyBucketOwner) Proprietário do contentor

Todas as outras funções de IAM ao nível do contentor, incluindo as funções de IAM de objetos antigos, funcionam independentemente das ACLs. Da mesma forma, todas as funções do IAM ao nível do projeto funcionam independentemente das ACLs. Por exemplo, se atribuir a um utilizador a função de leitor de objetos de armazenamento (roles/storage.objectViewer), as ACLs permanecem inalteradas.

Uma vez que as ACLs de objetos funcionam independentemente das funções de IAM, não aparecem na hierarquia das políticas de IAM. Quando avaliar quem tem acesso a um dos seus objetos, certifique-se de que verifica as ACLs do objeto, além de verificar as políticas de IAM ao nível do projeto e do contentor.

Políticas de negação de IAM vs. ACLs

As políticas de negação do IAM aplicam-se ao acesso concedido pelas ACLs. Por exemplo, se criar uma política de recusa que recuse a um principal a autorização storage.objects.get num projeto, o principal não pode ver objetos nesse projeto, mesmo que lhe seja concedida a autorização READER a objetos individuais.

Autorização de IAM para alterar LCAs

Pode usar o IAM para conceder aos responsáveis a autorização necessária para alterar as LCAs em objetos. As seguintes autorizações storage.buckets em conjunto permitem que os utilizadores trabalhem com LCAs de contentores e LCAs de objetos predefinidas: .get, .getIamPolicy, .setIamPolicy e .update.

Da mesma forma, as seguintes autorizações storage.objects permitem que os utilizadores trabalhem com LCAs de objetos: .get, .getIamPolicy, .setIamPolicy e .update.

Funções personalizadas

Embora o IAM tenha muitas funções predefinidas que abrangem exemplos de utilização comuns, pode querer definir as suas próprias funções que contenham conjuntos de autorizações que especifica. Para tal, o IAM oferece funções personalizadas.

Tipos de diretores

Existem vários tipos diferentes de responsáveis. Por exemplo, Google Cloud as contas representam um tipo geral, enquanto allAuthenticatedUsers e allUsers são dois tipos especializados. Para ver uma lista dos tipos de principais no IAM, consulte Identificadores principais. Para mais informações sobre os principais em geral, consulte os principais do IAM.

Valores de conveniência

O Cloud Storage suporta valores de conveniência, que são um conjunto especial de diretores que podem ser aplicados especificamente às suas políticas de IAM de contentores. Geralmente, deve evitar usar valores de conveniência em ambientes de produção, porque exigem a concessão de funções básicas, uma prática desaconselhada em ambientes de produção.

Um valor de conveniência é um identificador de duas partes que consiste num papel básico e num ID do projeto:

  • projectOwner:PROJECT_ID
  • projectEditor:PROJECT_ID
  • projectViewer:PROJECT_ID

Um valor de conveniência funciona como uma ponte entre os responsáveis a quem foi concedida a função básica e uma função IAM: a função IAM concedida ao valor de conveniência é, na prática, também concedida a todos os responsáveis da função básica especificada para o ID do projeto especificado.

Por exemplo, suponhamos que jane@example.com e john@example.com têm a função básica de leitor (roles/viewer) para um projeto denominado my-example-project e que tem um contentor nesse projeto denominado my-bucket. Se conceder a função de criador de objetos do Storage (roles/storage.objectCreator) para my-bucket ao valor de conveniência projectViewer:my-example-project, tanto jane@example.com como john@example.com obtêm as autorizações associadas à função de criador de objetos do Storage para my-bucket.

Pode conceder e revogar o acesso a valores de conveniência para os seus contentores, mas tenha em atenção que o Cloud Storage os aplica automaticamente em determinadas circunstâncias. Consulte o comportamento modificável para funções básicas no Cloud Storage para mais informações.

Condições

As condições de IAM permitem-lhe definir condições que controlam a forma como as autorizações são concedidas ou recusadas aos principais. O Cloud Storage suporta os seguintes tipos de atributos de condição:

  • resource.name: conceda ou recuse o acesso a contentores e objetos com base no nome do contentor ou do objeto. Também pode usar resource.type para conceder acesso a contentores ou objetos, mas fazê-lo é maioritariamente redundante com a utilização de resource.name. A condição de exemplo seguinte aplica uma definição de IAM a todos os objetos com o mesmo prefixo: 

    resource.name.startsWith('projects/_/buckets/BUCKET_NAME/objects/OBJECT_PREFIX')

  • Data/hora: defina uma data de validade para a autorização. 

    request.time < timestamp('2019-01-01T00:00:00Z')

Estas expressões condicionais são declarações lógicas que usam um subconjunto do Idioma de expressão comum (IEC). Especifica condições nas associações de funções da política de IAM de um contentor.

Tenha em atenção estas restrições:

  • Tem de ativar o acesso uniforme ao nível do contentor num contentor antes de adicionar condições ao nível do contentor. Embora as condições sejam permitidas ao nível do projeto, deve migrar todos os contentores no projeto para o acesso de nível de contentor uniforme para impedir que as ACLs do Cloud Storage substituam as condições do IAM ao nível do projeto. Pode aplicar uma restrição de acesso de nível de contentor uniforme para ativar o acesso de nível de contentor uniforme para todos os novos contentores no seu projeto.
  • Quando usar a API JSON para chamar getIamPolicy e setIamPolicy em contentores com condições, tem de definir a versão da política de IAM como 3.
  • Uma vez que a autorização storage.objects.list é concedida ao nível do contentor, não pode usar o atributo de condição resource.name para restringir o acesso à listagem de objetos a um subconjunto de objetos no contentor.
  • As condições expiradas permanecem na sua política de IAM até as remover.

Utilização com ferramentas do Cloud Storage

Embora as autorizações do IAM não possam ser definidas através da API XML, os utilizadores com autorizações do IAM podem continuar a usar a API XML, bem como qualquer outra ferramenta para aceder ao Cloud Storage.

Para referências sobre que autorizações de IAM permitem aos utilizadores realizar ações com diferentes ferramentas do Cloud Storage, consulte as referências de IAM para o Cloud Storage.

O que se segue?