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 recursos como buckets e objetos no Cloud Storage.

• Para aprender outras formas de controlar o acesso no Cloud Storage, consulte Visão geral do controle de acesso.

• Para ver informações detalhadas sobre o IAM e seus recursos gerais, consulte Gerenciamento de identidade e acesso.

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.

Os Principais são o "quem" do IAM. Eles podem ser usuários individuais, grupos, domínios ou até mesmo o público em geral. Os Principais recebem papéis que permitem executar 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. Essa permissão é encontrada em papéis como Storage Object Creator, que concede permissões úteis para criar objetos em um bucket, e Storage Object Admin, que concede diversas permissões para trabalhar com objetos.

A coleção de papéis do IAM que você define em um recurso é chamada de política do IAM. O acesso concedido por esses papéis se aplica ao recurso em que a política está definida e aos recursos contidos nesse recurso. Por exemplo, é possível definir uma política do IAM em um bucket que dê ao usuário controle administrativo desse bucket e dos respectivos objetos. Também é possível definir uma política do IAM no projeto geral que dê a outro usuário a capacidade de visualizar objetos em qualquer bucket dentro do projeto.

Também é possível usar políticas de negação do IAM para negar acesso a recursos. Quando uma política de negação é anexada a um recurso, o principal da política não pode usar a permissão especificada para acessar o recurso ou qualquer sub-recurso dentro dele, independentemente dos papéis concedidos. As políticas de negação substituem qualquer política de permissão do IAM.

Cuidado: é possível definir políticas do IAM em buckets e projetos que controlam o acesso a objetos dentro delas, mas não é possível definir políticas do IAM diretamente em objetos individuais. 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 Principais 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. Você não concede permissões aos Principais diretamente. Em vez disso, você concede papéis que têm 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 Leitor de objetos do Storage contém as permissões storage.objects.get e storage.objects.list. Você concede papéis aos Principais, o que permite que eles realizem ações nos buckets e nos objetos do seu 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 Leitor 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, Leitor 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. Os papéis do IAM que permitem controlar as políticas de negação de IAM só podem ser aplicados no nível da organização.

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

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

Todos os outros papéis do IAM no nível do bucket, incluindo os do IAM de objeto legado, funcionam independentemente das ACLs. Da mesma forma, todos os papéis do IAM para envolvidos no projeto funcionam de forma independente das ACLs. Por exemplo, se você fornecer a um usuário o papel Visualizador do objeto de armazenamento, 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.

Importante: as políticas do IAM não podem ser definidas em objetos individuais, mas algumas ferramentas fazem com que pareça ser possível. Por exemplo, o gsutil permitirá usar o comando iam em objetos se você especificar um papel de objeto legado no comando. Ao fazer isso, a gsutil converte o papel do IAM para a ACL equivalente e a aplica a cada um dos objetos relevantes.

Políticas de negação de IAM x ACLs

As políticas de negação do IAM se aplicam ao acesso concedido pelas ACLs. Por exemplo, se você criar uma política de negação que nega um principal a permissão storage.objects.get em um projeto, o principal não pode ver objetos nesse projeto, mesmo que receba a permissão READER para objetos individuais.

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

Use o IAM para conceder aos Principais 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 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 principais

Há vários tipos diferentes de Principais. 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 principais 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 a concessão de 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 Principais 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 Principais 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

As Condições do IAM permitem definir condições que controlam como as permissões são concedidas ou negadas para os participantes. O Cloud Storage é compatível com os seguintes tipos de atributos de condição:

• resource.name: conceda ou negue acesso a buckets e objetos com base no bucket ou no nome do objeto. 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.

A seguir

• Como usar o IAM com Cloud Storage.
• Revise a tabela de referência do IAM para Cloud Storage.
• Saiba mais sobre as práticas recomendadas para o uso do IAM.
• Gerencie as políticas do IAM para todos os recursos do Google Cloud.