Gerenciamento de identidade e acesso

Acessar exemplos

Nesta página fornecemos uma visão geral do Gerenciamento de identidade e acesso (IAM, na sigla em inglês) e o respectivo uso com o 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, falaremos sobre os aspectos do IAM que são relevantes para o Cloud Storage. Para ver informações detalhadas sobre o IAM e seus recursos gerais, consulte Gerenciamento de identidade e acesso. Consulte especificamente a seção Como gerenciar políticas do IAM.

Visão geral

Com o IAM, é possível 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 de IAM. Uma política de IAM aplicada ao projeto define as ações que os usuários podem executar em todos os objetos ou buckets do projeto. Quando aplicada a um bucket único, essa política define as ações que os usuários podem ter nesse bucket específico e nos objetos dele.

Crie uma política de IAM para um dos buckets, dando a um usuário o controle administrativo desse bucket. Enquanto isso, adicione outro usuário a uma política de IAM que abranja todo o projeto e permita que esse usuário visualize objetos em qualquer bucket do projeto.

Os membros são o "quem" do 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. As permissões são as unidades básicas do IAM: cada uma possibilita executar 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 IAM com o Cloud Storage, é 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 listas de controle de acesso (ACLs). As ACLs de objeto não aparecem na hierarquia das políticas de IAM. Ao avaliar quem tem acesso a um de seus objetos, lembre-se de verificar as ACLs para o objeto, além de verificar as políticas de IAM no nível do projeto e do bucket.

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 de IAM que se aplicam ao Cloud Storage, consulte Permissões do 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 a lista de referência dos papéis de IAM que se aplicam ao Cloud Storage, consulte Papéis do IAM para o Cloud Storage.

Papéis no nível do projeto x papéis 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.

Alguns papéis só podem ser aplicados a um nível. Só é possível aplicar o papel Proprietário do objeto legado do Storage no nível do bucket.

Cuidado: a configuração de políticas de IAM nos níveis de projeto e bucket tem o potencial de permitir que os usuários tenham acesso a objetos anteriormente não acessíveis. Avalie cuidadosamente suas políticas antes de defini-las.

Observação: ao visualizar a política de IAM de um projeto, não será possível ver as políticas de IAM que existem para buckets individuais. Se você visualizar a política de IAM de um bucket individual usando o Console do Google Cloud, verá permissões no nível do projeto que se aplicam a esse bucket. No entanto, outras ferramentas do Cloud Storage, como gsutil e as Bibliotecas de cliente, apenas retornam a política do bucket e não incluem informações herdadas do política 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 de IAM de bucket legado funcionam acoplados às ACLs do bucket: quando você adiciona ou remove um papel do bucket legado, essas alterações são refletidas nas ACLs associadas a ele. Da mesma forma, a alteração de uma ACL específica do bucket atualiza o papel do IAM 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

Os outros papéis de IAM, tanto no nível de bucket quanto no nível 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 os papéis de IAM no nível de bucket para conceder acesso amplo a todos os objetos de um bucket e usar as ACLs de objeto para personalizar o acesso a objetos específicos do bucket.

Permissão do IAM para alteração de ACLs

Use o IAM para conceder aos membros a permissão necessária para alterar ACLs em 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 IAM tem muitos papéis predefinidos que abrangem casos de uso comum, mas nada impede que você defina seus papéis e especifique as permissões contidas nos pacotes. Para isso, o 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. Para conseguir uma lista de tipos de membros típicos no IAM, consulte Conceitos relacionados à identidade.

Valores de conveniência

O Cloud Storage é compatível com valores de conveniência, que são um conjunto especial de membros que podem ser aplicados especificamente às políticas de bucket do IAM. Em geral, evite usar valores de conveniência em ambientes de produção, porque eles exigem que os membros recebam papéis básicos, uma prática não recomendada em ambientes de produção.

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

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

Um valor de conveniência atua como uma ponte entre os membros que receberam o papel básico e um papel do IAM. O papel do IAM concedido ao valor de conveniência também é, na prática, concedido a todos os membros do papel básico especificado no ID do projeto especificado.

Por exemplo, digamos que [e-mail] e [e-mail] tenham o papel básico de Leitor para um projeto chamado my-example-project e digamos que você tem um bucket nesse projeto chamado my-bucket. Se você conceder o papel Criador de objetos do Storage para my-bucket ao valor de conveniência projectViewer:my-example-project, tanto [e-mail] quanto [e-mail] receberão as permissões associadas a Criador de objetos do Storage para my-bucket.

É possível conceder e revogar o acesso aos valores de conveniência dos buckets, mas observe que o Cloud Storage os aplica automaticamente em determinadas circunstâncias. Consulte Comportamento modificável para papéis básicos no Cloud Storage para mais informações.

Condições

Condições de IAM permitem que você defina condições que controlam como as permissões sã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 IAM a todos os objetos com o mesmo prefixo:

  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 papel da política de IAM de um bucket.

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 para envolvidos no projeto, é preciso migrar todos os buckets do projeto para um acesso uniforme no nível do bucket para evitar que as ACLs do Cloud Storage substituam as condições do IAM para envolvidos no 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, você precisa definir a versão da política de IAM para 3.
• Como a permissão storage.objects.list é concedida no nível do bucket, não é possível usar o atributo da condição resource.name para restringir o acesso à listagem de objetos para um subconjunto de objetos no bucket. Os usuários sem a permissão storage.objects.list no nível do bucket podem ter funcionalidades prejudicadas para o Console e a gsutil.
• As condições expiradas permanecem na política de IAM até que você as remova.

Como usar com as ferramentas do Cloud Storage

Ainda que as permissões do IAM não possam ser definidas por meio da API XML, os usuários que tiverem recebido permissões do IAM ainda poderão usar a API XML e qualquer outra ferramenta para acessar o Cloud Storage.

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

Práticas recomendadas

O 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. As mudanças no gerenciamento de projetos, nos padrões de uso e na propriedade organizacional podem exigir que você modifique as configurações de IAM em buckets e projetos, especialmente se gerenciar o Cloud Storage em uma 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.

  O princípio de privilégio mínimo é uma diretriz de segurança para conceder acesso a seus recursos. Ao conceder acesso com base no princípio do privilégio mínimo, 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.

• 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 pode acontecer em um bucket quando todas as permissões de IAM no bucket forem removidas. Isso pode ocorrer com um objeto quando o proprietário dele abandona um projeto e não há políticas de IAM de bucket ou para envolvidos no projeto que conceda 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.

  Verifique se os buckets e recursos ainda podem ser gerenciados por outros membros da equipe caso um indivíduo com acesso administrativo saia do grupo. Duas maneiras comuns para fazer isso são as seguintes:

  • Atribua o papel Administrador do Storage do projeto a um grupo, em vez de a um indivíduo.

  • Atribua o papel Administrador do Storage do projeto a pelo menos dois indivíduos.

A seguir

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