Cloud Identity and Access Management

Acessar os exemplos

Nesta página, você encontra uma visão geral sobre o Cloud Identity and Access Management (Cloud IAM) e sobre como usá-lo no controle de acesso a buckets e objetos no Cloud Storage. Para saber mais sobre outras formas de controlar o acesso a buckets 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

O Cloud Identity and Access Management (Cloud IAM) permite controlar quem tem acesso aos recursos do projeto do Google Cloud. Esses recursos abrangem os buckets 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 buckets do projeto. Quando a política é aplicada a um bucket único, ela define as ações que os usuários podem executar nesse bucket específico e nos objetos dele.

Por exemplo, crie para um dos seus buckets uma política do Cloud IAM que forneça ao usuário controle administrativo sobre esse bucket. 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 bucket 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 permite criar objetos. Ela é encontrada em papéis como o de criador de objetos do Storage, em que é a única permissão, e o de Administrador de objetos do Storage, em que muitas permissões são agrupadas. Se você atribuir o papel de criador de objetos do Storage a um membro em um bucket específico, ele terá a possibilidade de criar objetos apenas nesse bucket. Se você der a outro membro o papel de Administrador de objetos do Storage nesse bucket, ele terá a possibilidade de fazer outras tarefas, como excluir objetos, mas apenas dentro desse bucket. Se a esses dois usuários forem atribuídos somente esses papéis, eles não terão conhecimento de outros buckets no projeto. Se você conceder a um terceiro membro o papel de Administrador de objetos do Storage, e fizer isso para o projeto e não apenas em um único bucket, ele terá acesso a qualquer objeto em qualquer bucket do projeto.

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

Cuidado: para o controle de acesso detalhado de objetos individuais, o Cloud Storage usa ACLs. As ACLs do objeto não aparecem na hierarquia das políticas do Cloud IAM. Ao avaliar quem tem acesso a um de seus objetos, lembre-se de verificar as ACLs do objeto e as políticas do Cloud IAM no nível do bucket e do projeto.

Permissões

Com as permissões, os membros podem executar ações específicas em buckets ou objetos no Cloud Storage. Por exemplo, a permissão storage.buckets.list possibilita ao membro listar os buckets 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. Por exemplo, o papel de visualizador de objetos do Storage contém as permissões storage.objects.get e storage.objects.list. Você atribui papéis aos membros, o que permite que eles realizem ações nos buckets e nos 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 bucket

A concessão de papéis no nível do bucket 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 a um usuário a permissão para ler objetos em qualquer bucket, mas para criar objetos apenas em um bucket específico. Para isso, conceda ao usuário o papel de visualizador de objetos do Storage no nível do projeto, permitindo que ele leia qualquer objeto armazenado em qualquer bucket no projeto. Depois, conceda o de criador de objetos do Storage no nível do bucket para um bucket específico, permitindo que ele crie objetos somente nesse intervalo.

É possível usar alguns papéis nos níveis do projeto e do bucket. Quando usados no nível do projeto, as permissões que eles têm se aplicam a todos os buckets e objetos no projeto. No nível do bucket, as permissões se aplicam apenas a um bucket específico e aos objetos nele contidos. Administrador do Storage, visualizador de objetos do Storage e criador de objetos do Storage são exemplos desses papéis.

Determinados papéis podem ser aplicados apenas a um nível. Por exemplo, só é possível aplicar o papel de visualizador no nível do projeto, enquanto o papel de proprietário de objeto legado do Storage só pode ser aplicado no nível do bucket.

Cuidado: a definição de políticas do Cloud IAM no nível do bucket e para envolvidos no projeto possibilita o acesso potencial de usuários aos objetos anteriormente não acessíveis. Antes de definir as políticas, as avalie cuidadosamente.

Observação: ao visualizar a política do Cloud IAM de um projeto, não é possível ver as políticas do Cloud IAM que existem para buckets individuais. Ao visualizar a política do Cloud IAM de um bucket individual usando o Console do Google Cloud, você verá permissões para envolvidos no projeto que se aplicam a esse bucket. No entanto, outras ferramentas do Cloud Storage, como a gsutil e as bibliotecas de cliente, retornam apenas a política do bucket e não incluem informações herdadas da política do nível para envolvidos no projeto. Lembre-se de consultar as políticas do projeto e do bucket ao avaliar os níveis de acesso dos membros.

Relação com as ACLs

Os papéis do Cloud IAM para bucket legado funcionam em conjunto com as ACLs do bucket: quando um papel do bucket 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 bucket atualiza o papel do bucket legado correspondente.

Papel do bucket legado	ACL equivalente
Leitor de bucket legado do Storage	Leitor de bucket
Gravador de bucket legado do Storage	Gravador de bucket
Proprietário de bucket legado do Storage	Proprietário de bucket

Todos os outros papéis do Cloud IAM no nível do bucket 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 bucket para conceder acesso amplo a todos os objetos em um bucket, além de utilizar ACLs de objeto detalhadas para personalizar o acesso a objetos específicos nesse bucket.

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 bucket 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 bucket 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 com essa permissão para o projeto especificado receberão o papel que você selecionou. Por exemplo, digamos que você queira dar o papel de criador de objetos do Storage em um de seus buckets a todos os membros que têm o papel de visualizador no projeto my-example-project. Para isso, conceda ao membro projectViewer:my-example-project o papel de criador de objetos do Storage para esse bucket.

Condições

As condições do Cloud IAM permitem definir condições que controlam como as permissões serão concedidas aos membros. O Cloud Storage é compatível com os seguintes tipos de atributos de condição:

• resource.name: conceda acesso a buckets e objetos com base no nome de cada um. Também é possível usar resource.type para conceder acesso a buckets ou objetos, mas fazer isso é praticamente a mesma coisa que usar resource.name. O exemplo de condição a seguir aplica uma configuração do Cloud IAM em todos os objetos com o mesmo prefixo:

  resource.name.startsWith('projects/_/buckets/[BUCKET_NAME]/objects/[OBJEC
  T_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.

Observação: também é possível usar aspas duplas nas expressões condicionais, mas é preciso fazer o escape adequado quando estiver usando comandos gcloud e solicitações HTTP/REST para atualizar uma política condicional. Por exemplo, request.time < timestamp(\"2019-01-01T00:00:00Z\").

Lembre-se destas restrições:

• É necessário ativar o acesso uniforme no nível do bucket antes de adicionar condições desse nível. Embora as condições sejam permitidas no nível do projeto, é preciso migrar todos os buckets no projeto para acesso uniforme no nível do bucket para evitar que as ACLs do Cloud Storage modifiquem as condições do Cloud IAM no nível do projeto. É possível aplicar uma restrição de acesso uniforme no nível do bucket para ativar acesso uniforme no nível do bucket a todos os novos buckets no projeto.
• O comando gsutil iam ch não funciona com políticas que contenham condições. Para modificar uma política com condições, use gsutil iam get para recuperar a política do bucket relevante, editá-la localmente e, em seguida, usar gsutil iam set para aplicá-la novamente ao bucket.
• 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 buckets 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 bucket ou objeto acessível a outros usuários, saiba com quem você quer compartilhar o bucket 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 buckets 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 acessos.

  O princípio do menor privilégio é uma diretriz de segurança para conceder acessos a seus recursos. Ao conceder acesso com base no princípio do menor privilégio, você dá a um usuário apenas o acesso necessário para realizar a tarefa atribuída. Por exemplo, se você quiser compartilhar arquivos com alguém, conceda a essa pessoa o papel storage.objectReader, em vez do papel storage.admin.

• Evite conceder papéis com a permissão setIamPolicy a 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 buckets.

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

• Compreenda os papéis primários de visualizador, editor e proprietário no Cloud Storage.

  Os papéis primários de visualizador/editor/proprietário concedem efetivamente o acesso que os nomes deles sugerem no Cloud Storage. No entanto, fazem isso indiretamente, por meio de outros acessos fornecidos nos níveis do bucket e do objeto, usando tipos de membros exclusivos do Cloud Storage. Embora o acesso seja adicionado por padrão, é possível revogá-lo.

  Por exemplo, o papel de visualizador permite aos membros listar buckets, mas não visualizar buckets ou objetos. No entanto:

  • Os membros com o papel de visualizador normalmente recebem o papel leitor de intervalo legado do Storage e as permissões dele para cada bucket no projeto. Isso ocorre porque, quando você cria um novo bucket, o comportamento padrão do Cloud Storage é conceder o papel de leitor de bucket legado do Storage no novo bucket ao papel primário de visualizador. Consequentemente, todos os membros que tiverem o papel primário devisualizador no projeto também terão o de leitor de bucket legado do Storage no novo bucket. Esse comportamento permite que membros com o papel de visualizador visualizem buckets.

  • Os buckets têm uma ACL de objeto padrão de projectPrivate, o que significa que os objetos adicionados ao bucket recebem, por padrão, a ACL projectPrivate. Essa ACL permite que os membros com o papel de visualizador visualizem objetos.

  Da mesma forma, os papéis primários de editor e proprietário têm, por si mesmos, acesso limitado ao Cloud Storage. Porém, os membros que tiverem esses papéis recebem o de proprietário de bucket legado do Storage para novos buckets, bem como propriedade de objetos por meio da ACL projectPrivate.

  Como alguns acessos a buckets e objetos não são inerentes aos papéis primários de visualizador/editor/proprietário, é possível revogar o acesso que os membros talvez esperem ter de outra forma.

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

  Quando ninguém tem permissão para ler um bucket ou objeto, ele fica inacessível. Isso acontece em um bucket quando todas as permissões do Cloud IAM nele são removidas. No objeto, isso ocorre quando o proprietário dele sai de um projeto, e não há políticas do Cloud IAM no nível do bucket ou do projeto que concedam acesso aos objetos. Em ambos os casos, é possível recuperar o acesso atribuindo um papel apropriado, como o de administrador do Storage, a si mesmo ou a outro membro no nível do projeto. Fazer isso dá acesso a todos os buckets e objetos no projeto. Portanto, revogue o papel assim que tiver redefinido o acesso ao bucket ou objeto afetado.

• Delegue o controle administrativo de seus buckets.

  Por padrão, os membros com o papel de proprietário no nível do projeto são as únicas entidades que têm o papel de proprietário de bucket legado do Storage em um bucket recém-criado. É necessário haver ao menos dois membros com o papel de proprietário para que um membro da equipe saia do grupo. Os buckets poderão ser gerenciados pelos outros membros.

A seguir

• Saiba como usar o Cloud IAM com o Cloud Storage.
• Revise a tabela de referência do Cloud IAM para o Cloud Storage.