Cloud Identity and Access Management

Nesta página, você encontra uma visão geral sobre o Cloud Identity and Access Management (Cloud IAM) e seu uso no controle de acesso a intervalos e objetos no Cloud Storage. Para saber como configurar e gerenciar as permissões do Cloud IAM de intervalos e projetos do Cloud Storage, consulte Como usar permissões do Cloud IAM. Para saber quais são as outras formas de controlar o acesso aos intervalos e objetos, consulte Visão geral do controle de acesso.

Nesta página, você verá os aspectos do Cloud IAM que são relevantes para o Cloud Storage. Para uma discussão detalhada sobre o Cloud IAM e os recursos em geral, consulte Cloud Identity and Access Management. Veja, especificamente, a seção Como gerenciar políticas do Cloud IAM.

Visão geral

Com o Cloud Identity and Access Management (Cloud IAM), você controla quem tem acesso aos recursos do projeto do Google Cloud. Esses recursos abrangem os intervalos do Cloud Storage e os objetos armazenados neles, além de outras entidades do Google Cloud como instâncias do Compute Engine.

O conjunto de regras de acesso aplicado a um recurso é chamado de política do Cloud IAM. Ela define as ações que os usuários podem executar em todos os objetos ou intervalos do projeto. Quando a política é aplicada a um intervalo único, ela define as ações que os usuários podem executar nesse intervalo específico e nos objetos dele.

Por exemplo, crie para um dos seus intervalos uma política do Cloud IAM que forneça ao usuário controle administrativo sobre esse intervalo. Além disso, é possível adicionar outro usuário à política do Cloud IAM em todo o projeto que possibilite a ele ver objetos em qualquer intervalo do projeto.

Os membros são o "quem" do Cloud IAM. Podem ser usuários individuais, grupos, domínios ou até mesmo o público em geral. A eles são atribuídos papéis que permitem a execução de ações no Cloud Storage e no Google Cloud, de maneira geral. Cada papel se baseia em um conjunto de uma ou mais permissões. Elas são as unidades básicas do Cloud IAM. Com cada permissão, é possível executar uma determinada ação.

Por exemplo, a permissão storage.objects.create possibilita a criação de objetos. Essa permissão é encontrada em papéis como roles/storage.objectCreator, em que é a única permissão, e roles/storage.objectAdmin, em que muitas permissões são agrupadas. Se você atribuir o papel roles/storage.objectCreator a um membro para um intervalo específico, ele só poderá criar objetos nesse intervalo. Se você atribuir o papel roles/storage.objectAdmin a outro membro, ele poderá executar outras tarefas, como excluir objetos, mas apenas dentro desse mesmo intervalo. Se esses dois usuários só receberem esses papéis, eles não terão conhecimento de outros intervalos no projeto. Se o papel roles/storage.objectAdmin for atribuído a um terceiro membro, mas em razão do seu projeto e não de apenas um intervalo, ele terá acesso a qualquer objeto em qualquer intervalo desse projeto.

Ao usar o Cloud IAM com o Cloud Storage, é fácil limitar as permissões de um membro sem a necessidade de modificar a permissão de cada intervalo ou objeto individualmente.

Permissões

Com as permissões, os membros podem executar ações específicas em intervalos ou objetos no Cloud Storage. Por exemplo, a permissão storage.buckets.list possibilita ao membro listar os intervalos no projeto. Não é possível conceder, diretamente, permissões aos membros. Em vez disso, você atribui a cada um deles um papel, que tem uma ou mais permissões próprias.

Para ver uma lista de referência das permissões do Cloud IAM aplicáveis ao Cloud Storage, consulte Permissões do Cloud IAM para o Cloud Storage.

Papéis

Papéis são um conjunto de uma ou mais permissões. O roles/storage.objectViewer, por exemplo, inclui as permissões storage.objects.get e storage.objects.list. Você atribui papéis aos membros, e isso permite que eles realizem ações nos intervalos e objetos do projeto.

Para ver uma lista de referência dos papéis do Cloud IAM aplicáveis ao Cloud Storage, consulte Papéis do Cloud IAM para o Cloud Storage.

Comparação entre os papéis para envolvidos no projeto e no nível do intervalo

A concessão de papéis no nível do intervalo não afeta os papéis concedidos no nível do projeto e vice-versa. Use esses dois níveis de granularidade para personalizar suas permissões. Por exemplo, digamos que você queira dar permissão ao usuário para ler objetos em qualquer intervalo, mas para criar objetos somente em um intervalo específico. Para isso, forneça ao usuário o roles/storage.objectViewer no nível do projeto, permitindo que ele leia qualquer objeto armazenado em qualquer intervalo no projeto. Forneça também o papel roles/storage.objectCreator no nível do intervalo para um intervalo específico, permitindo que o usuário crie objetos apenas nele.

Alguns papéis podem ser usados nos níveis de projeto e de intervalo. Quando usados no nível do projeto, as permissões que eles têm se aplicam a todos os intervalos e objetos do projeto. No nível de intervalo, as permissões se aplicam apenas a um intervalo específico e aos objetos nele contidos. Alguns exemplos desses papéis são roles/storage.admin, roles/storage.objectViewer e roles/storage.objectCreator.

Alguns papéis só podem ser aplicados a um nível. Por exemplo, só é possível aplicar o papel Viewer no nível do projeto, enquanto o papel roles/storage.legacyObjectOwner só pode ser aplicado no nível do intervalo.

Relação com as ACLs

Os papéis do Cloud IAM para intervalo legado funcionam em conjunto com as ACLs do intervalo: quando um papel do intervalo legado é adicionado ou removido, as ACLs associadas a ele refletem essas alterações. Da mesma forma, a alteração de uma ACL específica de um intervalo atualiza o papel do intervalo legado correspondente.

Papel do intervalo legado ACL equivalente
roles/storage.legacyBucketReader Leitor do intervalo
roles/storage.legacyBucketWriter Escritor do intervalo
roles/storage.legacyBucketOwner Proprietário do intervalo

Todos os outros papéis do Cloud IAM no nível do intervalo ou do projeto funcionam independentemente das ACLs. Por exemplo, se você fornecer a um usuário o papel Visualizador de objetos do Storage, as ACLs não serão alteradas. Isso significa que é possível usar papéis do Cloud IAM no nível do intervalo para conceder acesso amplo a todos os objetos em um intervalo, além de utilizar ACLs de objeto detalhadas para personalizar o acesso a objetos específicos nesse intervalo.

Permissão do Cloud IAM para alterar as ACLs

Use o Cloud IAM para conceder aos membros a permissão necessária para alterar as ACLs nos objetos. Juntas, as seguintes permissões de storage.buckets permitem que os usuários trabalhem com ACLs de intervalo e ACLs de objeto padrão: .get, .getIamPolicy, .setIamPolicy e .update.

Da mesma forma, as seguintes permissões de storage.objects juntas permitem que os usuários trabalhem com ACLs de objeto: .get, .getIamPolicy, .setIamPolicy e .update.

Papéis personalizados

O Cloud IAM tem muitos papéis predefinidos que incluem casos de uso comum. No entanto, é possível definir os próprios papéis e especificar as permissões contidas nos pacotes. Para isso, o Cloud IAM oferece papéis personalizados.

Tipos de membros

Há vários tipos diferentes de membros. As Contas do Google e os Grupos do Google, por exemplo, representam dois tipos gerais, enquanto o allAuthenticatedUsers e o allUsers representam dois tipos especializados. Se quiser conferir uma lista de tipos comuns de membros no Cloud IAM, consulte Conceitos relacionados à identidade. Além dos tipos listados, o Cloud IAM é compatível com os seguintes tipos de membros, que podem ser aplicados especificamente às políticas do Cloud IAM do intervalo do Cloud Storage:

  • projectOwner:[PROJECT_ID]
  • projectEditor:[PROJECT_ID]
  • projectViewer:[PROJECT_ID]

Em que [PROJECT_ID] é o ID de um projeto específico.

Ao conceder um papel a um dos tipos de membros acima, todos os membros que tiverem essa permissão para o projeto especificado recebem o papel que você selecionou. Por exemplo, digamos que você queira dar a todos os membros que tenham o papel de Viewer no projeto my-example-project, o papel roles/storage.objectCreator para um de seus intervalos. Nesse caso, será preciso fornecer ao membro projectViewer:my-example-project o papel roles/storage.objectCreator para esse intervalo.

Condições

Condições do Cloud IAM permite que você defina condições que controlam como as permissões são concedidas aos membros. O Cloud Storage aceita dois tipos de atributos de condição:

  • Nome do recurso: concede acesso a intervalos e objetos com o prefixo especificado. 
    resource.type == resource.name.startsWith('projects/_/buckets/[BUCKET_NAME]/objects/[OBJECT_PREFIX]')
  • Data/hora: define uma data de validade para a permissão. 
    request.time < timestamp('2019-01-01T00:00:00Z')

Essas expressões condicionais são instruções lógicas que usam um subconjunto do Common Expression Language (CEL). Especifique condições nas vinculações de papéis da política do Cloud IAM de um intervalo.

Lembre-se destas restrições:

  • É preciso ativar o acesso uniforme no nível do intervalo antes de adicionar condições nesse nível. Embora as condições sejam permitidas para envolvidos no projeto, é preciso migrar todos os intervalos do projeto para um acesso uniforme no nível do intervalo para evitar que as ACLs do Cloud Storage substituam as condições do Cloud IAM no projeto. Também é possível definir uma política da organização para permitir acesso uniforme no nível do intervalo a todos os novos intervalos do projeto.
  • O comando gsutil iam ch não funciona com políticas que contêm condições. Para modificar uma política com condições, use gsutil iam get para recuperar a política do intervalo relevante, editá-la localmente e, em seguida, usar gsutil iam set para aplicá-la novamente ao intervalo.
  • A gsutil precisa estar na versão 4.38 ou superior para usar as condições.
  • Ao usar a API JSON para chamar getIamPolicy e setIamPolicy em intervalos com condições, é preciso definir a versão da política do Cloud IAM para 3.
  • As condições expiradas permanecerão em sua política do Cloud IAM até que você as remova.

Como usar com as ferramentas do Cloud Storage

Não é possível definir as permissões do Cloud IAM com a API XML. No entanto, os usuários que têm permissões do Cloud IAM ainda podem usar essa API e qualquer outra ferramenta para acessar o Cloud Storage.

Se quiser saber quais permissões do Cloud IAM os usuários podem usar para executar ações com as diferentes ferramentas do Cloud Storage, consulte Cloud IAM com o Console do Cloud, Cloud IAM com gsutil, Cloud IAM com JSON e Cloud IAM com XML.

Práticas recomendadas

O Cloud IAM, como qualquer outra configuração administrativa, exige que o gerenciamento ativo seja eficaz. Antes de criar um intervalo ou objeto acessível a outros usuários, saiba com quem você quer compartilhar o intervalo ou objeto e quais os papéis que serão atribuídos a essas pessoas. Ao longo do tempo, as mudanças no gerenciamento de projetos, nos padrões de uso e na propriedade organizacional podem exigir que você modifique as configurações do Cloud IAM em intervalos e projetos, especialmente se gerenciar o Cloud Storage em uma grande organização ou para um grande grupo de usuários. Ao avaliar e planejar as configurações de controle de acesso, lembre-se destas práticas recomendadas:

  • Use o princípio do menor privilégio ao conceder acesso.

    Esse princípio é uma diretriz de segurança para concessão de privilégios ou direitos. Com base nele, conceda o privilégio mínimo necessário para que um usuário execute a tarefa que lhe foi atribuída. Se quiser compartilhar um arquivo com alguém, por exemplo, conceda a essa pessoa o papel storage.objectReader e não o papel storage.admin.

  • Evite conceder papéis com a permissão setIamPolicy para desconhecidos.

    Com a permissão setIamPolicy, o usuário consegue alterar permissões e assumir o controle dos dados. Por isso, use papéis com a permissão setIamPolicy somente quando quiser delegar o controle administrativo de objetos e intervalos.

  • Tenha cuidado com o modo como concede permissões a usuários anônimos.

    Os tipos de membros allUsers e allAuthenticatedUsers só devem ser usados se for admissível que qualquer pessoa na Internet possa ler e analisar seus dados. Embora esses escopos sejam úteis para algumas aplicações e cenários, não é recomendável conceder a todos os usuários determinadas permissões, como setIamPolicy, update, create ou delete.

  • Entenda os papéis do projeto Viewer/Editor/Owner no Cloud Storage

    Os papéis para envolvidos no projeto Viewer/Editor/Owner concedem o acesso que seus títulos sugerem no Cloud Storage. No entanto, fazem isso indiretamente por meio de outro acesso fornecido nos níveis do intervalo e do objeto, usando tipos de membros exclusivos do Cloud Storage. É possível revogar o acesso quando ele é adicionado por padrão.

    Por exemplo, o papel Viewer, por si só, apenas concede ao membro a permissão storage.buckets.list, mas os novos intervalos, por padrão, concedem o papel roles/storage.legacyBucketReader a todos os membros com o papel no projeto. É esse papel do intervalo que permite a um Viewer visualizar um intervalo. Além disso, o intervalo tem uma ACL de objeto padrão de projectPrivate, que significa que os objetos adicionados ao intervalo herdam, por padrão, a ACL de projectPrivate. É essa ACL que permite a um Viewer visualizar o objeto.

    Da mesma forma, os papéis do projeto Editor e Owner têm acesso limitado ao Cloud Storage, mas os membros que têm esses papéis herdam roles/storage.legacyBucketOwner para novos intervalos e propriedade de objetos por meio da ACL projectPrivate.

    Observe que, como alguns acessos ao intervalo e ao objeto não são inerentes aos papéis do projeto Viewer/Editor/Owner, é possível revogar o acesso que os membros esperavam ter.

  • Evite definir permissões que resultem em intervalos e objetos inacessíveis.

    Quando ninguém tem permissão para ler um intervalo ou objeto, ele fica inacessível. Isso acontece em um intervalo quando todas as permissões do Cloud IAM nele são removidas. No objeto, isso ocorre quando o proprietário dele abandona um projeto, e não há políticas do Cloud IAM no nível do intervalo ou projeto que conceda acesso aos objetos. Em qualquer um dos casos, é possível recuperar o acesso ao atribuir um papel adequado a si mesmo ou a outro membro no nível do projeto, como o de roles/storage.admin. Observe que isso dá acesso a todos os intervalos e objetos no projeto. Portanto, revogue o papel assim que tiver redefinido o acesso ao intervalo ou objeto afetado.

  • Delegue o controle administrativo de seus intervalos.

    Por padrão, os membros com o papel Owner no nível do projeto são as únicas entidades que têm o papel roles/legacyBucketOwner em um intervalo recém-criado. Tenha sempre dois membros, pelo menos, com o papel Owner. Assim, se alguém da equipe sair do grupo, seus intervalos ainda poderão ser gerenciados por outros membros.

A seguir