Listas de controle de acesso (ACLs)

Acessar os exemplos

Nesta página, você encontra uma visão geral das Access Control Lists (ACLs). Para aprender outras formas de controlar o acesso a buckets e objetos, consulte Visão geral do controle de acesso.

Você precisa usar listas de controle de acesso?

Na maioria dos casos, o Identity and Access Management (IAM) é o método recomendado para controlar o acesso a recursos. O IAM e as ACLs funcionam juntos para conceder acesso a buckets e objetos: um usuário só precisa da permissão do IAM ou de uma ACL para acessar um bucket ou objeto.

As ACLs podem ser usadas para personalizar o acesso a objetos individuais de um bucket, porque as permissões do IAM se aplicam a todos os objetos de um bucket. No entanto, ainda é necessário usar o IAM para qualquer acesso comum a todos os objetos de um bucket, porque isso reduz o trabalho necessário com microgerenciamento.

.

O que é uma Access Control List?

Uma lista de controle de acesso (ACL, na sigla em inglês) é um mecanismo que pode ser usado para definir quem tem acesso a buckets e objetos, além do nível de acesso dessas pessoas. No Cloud Storage, ACLs são usadas com buckets e objetos individuais. Cada ACL é composta por uma ou mais entradas. Uma entrada permite que um usuário (ou grupo) específico execute determinadas ações. Cada entrada tem duas informações:

  • Uma permissão que define quais ações podem ser executadas. Por exemplo, ler ou gravar.

  • Um escopo, às vezes chamado de beneficiário, que define quem pode executar as ações especificadas. Por exemplo, um determinado usuário ou grupo de usuários.

Por exemplo, imagine que você tem um bucket e quer que qualquer pessoa seja capaz de acessar os objetos nele. No entanto, também quer que um colaborador consiga adicionar ou remover objetos desse bucket. Nesse caso, sua ACL teria duas entradas:

  • Em uma entrada, você precisaria conceder a permissão READER ao escopo de allUsers.

  • Na outra entrada, você daria a permissão WRITER ao escopo do seu colaborador. Há várias maneiras de especificar essa pessoa, como informar o e-mail dela.

É possível criar no máximo 100 entradas na ACL de um bucket ou objeto. Quando o escopo de entrada for um grupo ou domínio, ele contará como uma entrada da ACL, independentemente de quantos usuários estiverem nesse grupo ou domínio.

Quando um usuário solicita acesso a um bucket ou objeto, o sistema do Cloud Storage lê a respectiva ACL e determina se a solicitação de acesso será permitida ou rejeitada. Se a ACL conceder ao usuário permissão para a operação solicitada, a solicitação será permitida. Caso contrário, a solicitação falhará e um erro 403 Forbidden será retornado.

Ainda que seja possível usar as ACLs para gerenciar a maioria das ações que envolvem buckets e objetos, a capacidade de criar um bucket depende da permissão de projeto adequada.

Permissões

As permissões descrevem quais operações podem ser realizadas em um determinado objeto ou bucket.

O Cloud Storage permite atribuir as seguintes permissões concêntricas a buckets e objetos, conforme mostrado na tabela a seguir:

buckets Objetos
READER Permite que o usuário liste o conteúdo de um intervalo. Também permite que o usuário leia metadados do bucket, exceto ACLs. Permite que o usuário faça o download dos dados de um objeto.
WRITER Permite que o usuário liste, crie, substitua e exclua objetos de um bucket 1. N/A. Não é possível aplicar essa permissão a objetos.
OWNER Concede ao usuário as permissões READER e WRITER no bucket. Também permite que o usuário leia e grave metadados do bucket, incluindo ACLs. Dá acesso de READER ao usuário. Também permite que o usuário leia e grave metadados de objetos, incluindo ACLs.
Padrão Quando os buckets são criados, a ACL project-private predefinida é aplicada a eles. Os buckets sempre são de propriedade do grupo project-owners. Quando é feito o upload de objetos, a ACL project-private predefinida é aplicada a eles. Os objetos sempre são de propriedade do solicitante original, que fez o upload do objeto.

1Não é possível alterar estas propriedades de metadados de bucket: acl, cors, defaultObjectAcl, lifecycle, logging, versioning e website.

Nesta página, geralmente nos referimos às permissões como READER, WRITER e OWNER, que são como elas são especificadas na API JSON e no Console do Google Cloud. Se você estiver usando a API XML, as permissões equivalentes serão READ, WRITE e FULL_CONTROL, respectivamente. E quando a autenticação do OAuth 2.0 é usada para autenticar ferramentas e aplicativos (conceder permissão a eles) para que acessem a API do Google Cloud Storage em seu nome, o acesso é restrito por devstorage.read_only, devstorage.read_write e devstorage.full_control do escopo do OAuth. A tabela a seguir resume a terminologia mais frequente sobre permissões:

API JSON API XML Escopo do OAuth2
READER READ https://www.googleapis.com/auth/devstorage.read_only
WRITER WRITE https://www.googleapis.com/auth/devstorage.read_write
OWNER FULL_CONTROL https://www.googleapis.com/auth/devstorage.full_control

Escopos

Os escopos especificam quem tem uma determinada permissão.

Uma ACL é composta por uma ou mais entradas. Cada entrada concede permissões a um escopo. É possível especificar o escopo da ACL usando qualquer uma das seguintes entidades:

Escopo ("beneficiário") Tipos de entidade Exemplo
Endereço de e-mail da Conta do Google Usuário collaborator@gmail.com
Endereço de e-mail do Grupo do Google Grupo work-group@googlegroups.com
Valores de conveniência de projetos Projeto owners-123456789012
Domínio do G Suite Domínio USERNAME@YOUR_DOMAIN.com
Domínio do Cloud Identity Domínio USERNAME@YOUR_DOMAIN.com
Identificador especial para todos os proprietários de Conta do Google Usuário allAuthenticatedUsers
Identificador especial para todos os usuários Usuário allUsers
  • Endereço de e-mail da Conta do Google:

    Todo usuário que tem uma Conta do Google precisa ter um endereço de e-mail exclusivo associado a essa conta. É possível especificar um escopo usando qualquer endereço de e-mail associado a uma Conta do Google, como um endereço "gmail.com".

    O Cloud Storage lembra os endereços de e-mail conforme são fornecidos nas ACLs até que as entradas sejam removidas ou substituídas. Se um usuário alterar os endereços de e-mail, será necessário atualizar as entradas da ACL para que elas reflitam essas alterações.

  • Endereço de e-mail do Grupo do Google:

    Todo Grupo do Google tem um endereço de e-mail exclusivo associado a ele. Por exemplo, o grupo Cloud Storage Announce tem o seguinte endereço de e-mail: gs-announce@googlegroups.com. Para descobrir esses endereços de e-mail, clique em Sobre na página inicial de cada Grupo do Google. Consulte a página inicial dos Grupos do Google para mais informações.

    Assim como os endereços de e-mail da Conta do Google, o Cloud Storage lembra os endereços de e-mail do grupo conforme são fornecidos nas ACLs até que as entradas sejam removidas. Você não precisa se preocupar em atualizar os endereços de e-mail dos Grupos do Google, porque eles são permanentes e não há probabilidade de mudanças.

  • Valores de conveniência de projetos:

    Os valores de conveniência owners-PROJECT_NUMBER, editors-PROJECT_NUMBER e viewers-PROJECT_NUMBER representam as listas de proprietários, editores e leitores do projeto que tem o número de projeto PROJECT_NUMBER.

  • G Suite ou Cloud Identity:

    Os clientes do G Suite e do Cloud Identity podem associar as contas de e-mail deles a um nome de domínio da Internet. Com isso, cada conta de e-mail assume a forma USERNAME@YOUR_DOMAIN.com. É possível especificar um escopo usando qualquer nome de domínio da Internet associado ao G Suite ou ao Cloud Identity.

  • Identificador especial para todos os proprietários da conta do Google:

    Esse identificador de escopo especial representa qualquer pessoa autenticada com uma conta do Google. O identificador de escopo especial para todos os proprietários de contas do Google é allAuthenticatedUsers. Embora esse identificador seja um tipo de entidade User, ao usar o Console do Cloud, ele é rotulado como um tipo de entidade Public.

  • Identificador especial para todos os usuários:

    Esse identificador de escopo especial representa qualquer pessoa que esteja na Internet, com ou sem uma conta do Google. O identificador de escopo especial para todos os usuários é allUsers. Embora esse identificador seja um tipo de entidade User, ao usar o Console do Cloud, ele é rotulado como um tipo de entidade Public.

Escopos e permissões concêntricas

Ao especificar ACLs no Cloud Storage, não é necessário listar diversos escopos para conceder várias permissões. O Cloud Storage usa permissões concêntricas. Portanto, quando você concede a permissão WRITER, também concede a permissão READER. Se concede a permissão OWNER também concede as permissões READER e WRITER.

Ao especificar uma ACL usando o Console do Google Cloud, a API JSON ou o gsutil, é possível especificar vários escopos para a mesma entidade. A permissão mais abrangente é o acesso concedido ao escopo. Por exemplo, se você fornecer duas entradas para um usuário, uma com permissão READER e outra com permissão WRITER em um bucket, o usuário terá a permissão WRITER para o bucket.

Na API XML, não é possível fornecer duas entradas de ACL com o mesmo escopo. Por exemplo, conceder a um usuário as permissões READ e WRITE em um bucket resulta em erro. Em vez disso, conceda a permissão WRITE, que também inclui a permissão READ.

ACLs predefinidas

Uma ACL predefinida ou "pré-configurada" é como chamamos um conjunto de entradas de ACL específicas que pode ser usado para aplicar rapidamente muitas entradas de ACL a um bucket ou objeto de uma só vez.

A tabela abaixo lista ACLs predefinidas e mostra quais entradas de ACL são aplicadas a cada ACL predefinida. Ao usar a tabela abaixo, observe o seguinte:

  • O grupo de proprietários de um projeto é proprietário dos buckets desse projeto, enquanto o usuário que cria um objeto é proprietário desse objeto. Se um objeto foi criado por um usuário anônimo, o grupo de proprietários do projeto é proprietário do objeto.

  • Na tabela, são usadas as descrições da API JSON para as permissões OWNER, WRITER e READER. Os escopos equivalentes da API XML são FULL_CONTROL, WRITE e READ.

    API JSON API XML/gsutil Descrição
    private private Concede ao proprietário ou objeto de segmento OWNER permissão para um bucket ou objeto.
    bucketOwnerRead bucket-owner-read Concede ao proprietário do objeto a permissão OWNER e ao proprietário do bucket a permissão READER. É usada somente com objetos.
    bucketOwnerFullControl bucket-owner-full-control Concede aos proprietários do objeto e do bucket a permissão OWNER. É usada somente com objetos.
    projectPrivate project-private Concede permissão à equipe do projeto com base em papéis. Qualquer pessoa que faça parte da equipe tem permissão READER. Proprietários e editores de projeto têm permissão OWNER. Essa é a ACL padrão para buckets recém-criados. Também é a ACL padrão para objetos recém-criados, a menos que a ACL padrão de objetos desse bucket tenha sido alterada.
    authenticatedRead authenticated-read Concede ao proprietário do objeto ou bucket a permissão OWNER e concede a todos que tenham Contas do Google autenticadas a permissão READER.
    publicRead public-read Concede ao proprietário do objeto ou do bucket a permissão OWNER e a todos os usuários autenticados e anônimos a permissão READER. Quando aplicada a um objeto, qualquer pessoa na Internet pode ler esse objeto sem passar pela autenticação. Quando aplicada a um bucket, qualquer pessoa na Internet pode listar objetos sem autenticação.

    *Consulte a observação no final da tabela sobre armazenamento em cache.

    publicReadWrite public-read-write Concede ao proprietário do bucket a permissão OWNER e concede as permissões READER e WRITER a todos os usuários, autenticados e anônimos. Essa ACL se aplica apenas a buckets. Quando aplicada a um bucket, qualquer pessoa na Internet pode listar, criar, substituir e excluir objetos sem passar pela autenticação.

    *Consulte a observação no final da tabela sobre armazenamento em cache.

*Por padrão, objetos disponíveis para leitura pública são exibidos com um cabeçalho Cache-Control, que permite que eles sejam armazenados em cache por 3.600 segundos. Se for necessário garantir que as atualizações se tornem visíveis imediatamente, defina os metadadosCache-Control dos objetos como Cache-Control:private, max-age=0, no-transform.

ACLs padrão

Ao criar buckets ou fazer upload de objetos, não é necessário atribuir explicitamente uma ACL porque eles recebem a ACL padrão. É possível alterar a ACL padrão de um objeto. O processo para fazer isso está descrito em Como alterar ACLs padrão de objetos. Quando a ACL padrão é alterada, as ACLs de objetos que já estão presentes nos buckets do projeto permanecem inalteradas.

ACLs padrão de intervalos

Todos os buckets são propriedade do grupo de proprietários do projeto. Os proprietários do projeto recebem automaticamente a permissão OWNER para todos os buckets do projeto. Quem cria um projeto é automaticamente adicionado como proprietário do projeto.

Se você criar um bucket com a ACL padrão de buckets, ou seja, sem especificar uma ACL predefinida, a ACL predefinida projectPrivate será aplicada a ele. A ACL projectPrivate concede permissões extras aos membros da equipe do projeto com base em papéis. Essas permissões extras são definidas da seguinte maneira:

  • Leitores do projeto

    A ACL projectPrivate concede aos leitores do projeto o acesso READER aos buckets nesse projeto. Todos os membros da equipe do projeto podem listar objetos dentro dos buckets. Todos os membros da equipe de projeto também podem listar buckets dentro de um projeto, independentemente das ACLs do bucket.

  • Editores do projeto

    A ACL projectPrivate concede aos editores do projeto as permissões OWNER para os buckets nesse projeto. Os editores de projeto podem listar o conteúdo de um bucket e criar, substituir ou excluir objetos nele. Os editores de projeto também podem listar, criar e excluir buckets, independentemente das ACLs do bucket.

  • Proprietários do projeto

    A ACL projectPrivate concede aos proprietários do projeto as permissões OWNER. Os proprietários do projeto também podem executar todas as tarefas dos editores do projeto, além de tarefas administrativas, como adicionar e remover membros da equipe ou alterar as informações de faturamento.

Os leitores, editores e proprietários do projeto são identificados pela combinação do papel com o número do projeto associado. Por exemplo, no projeto 867489160491, os editores são identificados como project-editors-867489160491. É possível encontrar o número do seu projeto na página inicial do Console do Google Cloud.

ACLs padrão de objetos

Por padrão, qualquer pessoa que tenha permissão OWNER ou WRITER em um bucket pode fazer upload de objetos nesse bucket. Ao fazer o upload de um objeto, é possível fornecer uma ACL predefinida ou não especificar qualquer ACL. Se não for especificada uma ACL, o Cloud Storage aplicará a ACL padrão de objetos do intervalo ao objeto. Cada bucket tem uma ACL padrão de objetos. Ela é aplicada a todos os objetos enviados para esse bucket que não tenham uma ACL predefinida ou especificada na solicitação (somente API JSON). O valor inicial da ACL padrão de objetos é projectPrivate em todos os intervalos.

As ACLs de objetos são devidamente aplicadas com base na forma como os objetos são enviados:

  • Uploads autenticados

    Por padrão, se você fizer uma solicitação autenticada para upload de um objeto e não especificar qualquer ACL de objeto, você será listado como o proprietário do objeto e a ACL predefinida projectPrivate será aplicada a ele. Isso significa o seguinte:

    • Você (a pessoa que fez o upload do objeto) está listado como o proprietário do objeto. A propriedade do objeto não pode ser alterada modificando as ACLs. A propriedade do objeto só pode ser alterada se ele for substituído.

    • Você, o proprietário do objeto, recebe a permissão OWNER nele. Caso seja atribuída ao proprietário qualquer permissão inferior a OWNER, o Cloud Storage automaticamente elevará a permissão para OWNER.

    • Os grupos de proprietários do projeto e de editores do projeto têm a permissão OWNER no objeto.

    • O grupo de membros da equipe do projeto tem a permissão READER no objeto.

  • Uploads anônimos

    Se um usuário não autenticado (anônimo) fizer upload de um objeto, o que será possível se um bucket conceder ao grupo allUsers a permissão WRITER ou OWNER, as ACLs padrão de buckets serão aplicadas ao objeto, conforme descrito acima.

    Usuários anônimos não podem especificar uma ACL predefinida durante o upload de objetos.

Práticas recomendadas

Assim como qualquer outra configuração administrativa, as ACLs exigem gerenciamento ativo para serem eficazes. Antes de criar um bucket ou objeto acessível a outros usuários, é necessário saber com quem compartilhar o bucket ou objeto e quais os papéis que serão atribuídos a essas pessoas. Com o tempo, as mudanças no gerenciamento de projeto, nos padrões de uso e na propriedade organizacional podem exigir que as configurações da ACL sejam modificadas nos buckets e objetos, especialmente em casos em que é necessário gerenciar buckets e objetos em uma organização de grande porte ou para um grupo grande 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 a buckets e objetos.

    O princípio do menor privilégio é uma diretriz de segurança para concessão de privilégios ou direitos. Com base nesse princípio, conceda o privilégio mínimo necessário para que um usuário execute a tarefa que lhe foi atribuída. Por exemplo, para compartilhar um arquivo com alguém, conceda a essa pessoa a permissão READER e não a permissão OWNER.

  • Evite conceder a permissão OWNER a pessoas que você não conhece.

    A permissão OWNER permite que um usuário altere as ACLs e assuma o controle dos dados. Use a permissão OWNER somente quando quiser delegar o controle administrativo sobre objetos e buckets.

  • Tenha cuidado em como você concede permissões a usuários anônimos.

    Use os escopos allUsers e allAuthenticatedUsers somente quando for aceitável que qualquer pessoa na Internet leia e analise seus dados. Embora esses escopos sejam úteis para alguns aplicativos e cenários, normalmente não é uma boa ideia conceder a permissão OWNER a todos os usuários.

  • Evite configurar ACLs que resultem em objetos inacessíveis.

    Um objeto inacessível é um objeto que não pode ser salvo (lido). Só é possível excluí-lo. Isso pode acontecer quando o proprietário de um objeto sai de um projeto sem conceder a permissão OWNER ou READER para o objeto a mais ninguém. Para evitar esse problema, use as ACLs predefinidas bucket-owner-read ou bucket-owner-full- control quando você ou qualquer outra pessoa fizer o upload de objetos para seus buckets.

  • Delegue o controle administrativo de seus buckets.

    Por padrão, o grupo de proprietários do projeto é a única entidade com a permissão OWNER para um bucket quando ele é criado. É necessário ter sempre pelo menos dois membros no grupo de proprietários de projeto. Assim, se um membro da equipe deixar o grupo, os buckets ainda poderão ser gerenciados pelos outros proprietários do projeto.

  • Esteja ciente do comportamento interoperável do Cloud Storage.

    A API XML permite acesso interoperável com outros serviços de armazenamento, como o Amazon S3. Nesse caso, o identificador de assinaturas determina a sintaxe da ACL. Por exemplo, se a ferramenta ou biblioteca que você estiver usando solicitar que o Cloud Storage recupere ACLs e essa solicitação usar o identificador de assinatura de outro provedor de armazenamento, o Cloud Storage retornará um documento XML que usa a sintaxe da ACL do provedor de armazenamento correspondente. Se a ferramenta ou biblioteca que você estiver usando solicitar que o Cloud Storage aplique ACLs, e essa solicitação usar o identificador de assinatura de outro provedor de armazenamento, o Cloud Storage aguardará o recebimento de um documento XML que usa a sintaxe de ACL do provedor de armazenamento correspondente.

    Para mais informações sobre o uso da API XML para acesso interoperável com o Amazon S3, consulte Como migrar do Amazon S3 para o Google Cloud Storage.

O Cloud Storage ajuda a seguir essas práticas recomendadas impondo algumas regras de modificação de ACLs que impedem que elas sejam configuradas de maneira que os dados fiquem inacessíveis:

  • Não é possível aplicar uma ACL que especifica um proprietário de bucket ou objeto diferente.

    Não é possível alterar a propriedade do objeto modificando as ACLs. Se você aplicar uma ACL nova a um bucket ou objeto, certifique-se de que o proprietário do bucket ou objeto não seja alterado nela.

  • O proprietário do bucket ou objeto sempre tem a permissão OWNER para esse bucket ou objeto.

    O proprietário de um bucket é o grupo de proprietários do projeto, enquanto o proprietário de um objeto é o usuário que fez o upload do objeto ou o grupo de proprietários do projeto, caso esse upload tenha sido feito por um usuário anônimo.

    Quando uma ACL nova é aplicada a um bucket ou objeto, o Cloud Storage respectivamente concede a permissão OWNER ao proprietário do bucket ou objeto, caso as concessões sejam omitidas. Ele não concede ao grupo de proprietários do projeto a permissão OWNER para um objeto, a menos que esse objeto tenha sido criado por um usuário anônimo. Portanto, é necessário incluí-la explicitamente.

Não é possível aplicar ACLs que alterem a propriedade de um bucket ou objeto. Não confunda isso com a permissão OWNER. Uma vez criado no Cloud Storage, um bucket ou objeto terá para sempre o mesmo proprietário. No entanto, é possível alterar efetivamente a propriedade de objetos (mas não de buckets) substituindo-os. A substituição é basicamente uma operação de exclusão seguida imediatamente por uma operação de upload. Durante uma operação de upload, a pessoa que está realizando o upload se torna a proprietária do objeto. Lembre-se de que, para substituir um objeto, a pessoa que realiza a substituição (e, portanto, recebe a propriedade do objeto) precisa ter a permissão WRITER ou OWNER no bucket para o qual o objeto está sendo enviado.

A seguir