Gerenciamento de identidade e acesso

Acessar os 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.

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.

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.

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. Além dos tipos listados, o IAM é compatível com os seguintes tipos de membros, que podem ser aplicados especificamente às políticas de IAM de 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

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) (em inglês). Especifique condições nas vinculações de papel da política de IAM de um bucket.

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

    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.

  • Conheça os papéis básicos de Leitor, Editor e Proprietário no Cloud Storage

    Os papéis básicos de Visualizador, Editor e Proprietário concedem efetivamente o acesso que os nomes deles sugerem no Cloud Storage. No entanto, isso é feito 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 de Leitor de bucket legado do Storage e as permissões dele para cada bucket do projeto. Isso ocorre porque, ao criar um novo bucket, o comportamento padrão do Cloud Storage é conceder ao papel básico de Visualizador o papel de Leitor de bucket legado do Storage para o novo bucket. Consequentemente, todos os membros com o papel básico de Visualizador no projeto também terão o leitor de bucket legado do Storage ou o 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 básicos de Editor e Proprietário têm, por si mesmos, acesso limitado ao Cloud Storage. No entanto, os membros que tiverem esses papéis recebem o de Proprietário de bucket legado do Storage para novos buckets, além da propriedade de objetos por meio da ACL projectPrivate.

    Observe que alguns acessos ao bucket e ao objeto não são inerentes aos papéis básicos de Visualizador, Editor ou Proprietário. Dessa forma, é possível revogar o acesso que os membros esperariam que esses papéis tivessem.

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

    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