Listas de controle de acesso (ACLs)

Uso

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, evite usar ACLs e ative o acesso uniforme no nível do bucket para seus buckets, o que impede o uso de ACLs:

• As ACLs não podem ser usadas exclusivamente para controlar o acesso aos recursos do Google Cloud, porque não é possível definir ACLs no projeto geral ou em recursos fora do Cloud Storage.
• Ativar o acesso uniforme no nível do bucket cria uma interface de controle de acesso mais simples e permite usar outros recursos do Google Cloud. Para mais informações, consulte É recomendável usar o acesso uniforme no nível do bucket?.
• A política da organização de compartilhamento restrito de domínio e as políticas personalizadas da organização não impedem o acesso concedido pelas ACLs, o que pode levar a acesso não intencional.
• Comportamentos e acessos inesperados podem ocorrer ao usar ACLs em projetos que têm condições do IAM definidas no nível do projeto ou acima.

É provável que você queira usar ACLs nos seguintes casos:

• É necessário personalizar o acesso a objetos individuais em um bucket, por exemplo, se você quiser que a pessoa responsável pelo upload de um objeto tenha controle total sobre ele, mas tenha menos acesso a outros objetos no bucket.
• você está usando exclusivamente a API XML ou requer interoperabilidade com o Amazon S3.

O Identity and Access Management (IAM) e as ACLs funcionam em conjunto para conceder acesso a buckets e objetos, o que significa que o usuário precisa da permissão relevante somente de um desses sistemas para acessar um bucket ou objeto. Em geral, as permissões concedidas por políticas do IAM não aparecem nas ACLs, e as permissões concedidas pelas ACLs não aparecem nas políticas do IAM. Consulte mais informações em Relação de IAM com ACLs.

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 create um bucket depende da permissão de projeto adequada.

Permissões

As permissões descrevem o que pode ser feito com 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	Concede a um usuário todo o acesso que é concedido pela permissão READER. Além disso, permite que um usuário crie, substitua e exclua objetos de um bucket, incluindo a criação de objetos usando uploads de várias partes.	N/A. Não é possível aplicar essa permissão a objetos.
OWNER	Concede a um usuário todo o acesso que é concedido pela permissão WRITER. Também permite que o usuário leia e grave metadados do bucket, incluindo ACLs, e trabalhe com tags nele.	Concede a um usuário todo o acesso que é concedido pela permissão READER. 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.

Observação: não é possível conceder permissões distintas de leitura ou gravação para ler ou gravar ACLs ou outros metadados. Para permitir que alguém leia e grave ACLs, é necessário conceder a permissão OWNER.

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.

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
Identificador especial para todas as entidades	Usuário	allUsers
Identificador especial para todas as contas válidas	Usuário	allAuthenticatedUsers
O endereço de e-mail da conta de usuário	Usuário	[e-mail]
Endereço de e-mail do Grupo do Google	Grupo	[e-mail]
Valores de conveniência de projetos	Projeto	owners-123456789012
Domínio do Google Workspace	Domínio	USERNAME@YOUR_DOMAIN.com
Domínio do Cloud Identity	Domínio	USERNAME@YOUR_DOMAIN.com
Identidade única em um pool de identidades de força de trabalho	Principal	//iam.googleapis.com/locations/global/workforcePools/my-pool/subject/[e-mail]
Todas as identidades de força de trabalho em um grupo	PrincipalSet	//iam.googleapis.com/locations/global/workforcePools/my-pool/group/my-group

• Identificador especial para todas as entidades:

  O identificador de escopo especial allUsers representa qualquer entidade na Internet. Embora esse identificador seja um tipo de entidade User, ao usar o console do Google Cloud, ele é rotulado como um tipo de entidade Public.

• Identificador especial para todas as contas válidas:

  O identificador de escopo especial allAuthenticatedUsers representa a maioria das contas autenticadas, incluindo contas de serviço. Para mais informações, consulte a Visão geral do IAM. Embora esse identificador seja um tipo de entidade User, ao usar o console do Google Cloud, ele é rotulado como um tipo de entidade Public.

• O endereço de e-mail da conta de usuário:

  Todo usuário que tem uma conta de usuário 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 de usuário.

  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: [e-mail]. Para descobrir esses endereços de e-mail, clique em Sobre na página inicial de cada Grupo do Google.

  Assim como os endereços de e-mail da conta de usuário, 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 permitem que você conceda acesso em massa aos leitores, editores e proprietários do projeto. Os valores de conveniência combinam um papel de projeto e um número de projeto associado. Por exemplo, no projeto 867489160491, os editores são identificados como editors-867489160491. É possível encontrar o número do seu projeto na página inicial do Console do Google Cloud.

  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.

• Google Workspace ou Cloud Identity:

  Os clientes do Google Workspace e do Cloud Identity podem associar as contas de e-mail 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 Google Workspace ou ao Cloud Identity.

• Identidades da força de trabalho:

  A federação de identidade de colaboradores permite que você use um provedor de identidade externo (IdP) para autenticar e autorizar um grupo de usuários com o IAM. Assim, os usuários podem acessar os serviços do Google Cloud.

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, a maioria das ferramentas permite especificar vários escopos para a mesma entrada. 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, também conhecida como ACL pré-configurada, é um alias para um conjunto de entradas de ACL específicas que pode ser usado para aplicar rapidamente muitas entradas de ACL de uma só vez a um bucket ou objeto.

Cuidado: ao aplicar uma ACL predefinida a um bucket ou objeto antigo, você substituirá completamente a ACL atual pela predefinida. Em alguns casos, essa alteração pode resultar na perda de acesso à ACL do bucket ou objeto. Por exemplo, se você fizer parte do grupo de proprietários do projeto, mas não for o proprietário de um objeto com a ACL projectPrivate, depois que a ACL predefinida publicRead for aplicada a esse objeto, você perderá a permissão OWNER e, portanto, não poderá mais acessar a ACL do objeto. Se isso ocorrer, use o papel do IAM storage.objectAdmin para ter a permissão necessária para atualizar a ACL do objeto e corrigir a alteração.

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/gcloud storage	API XML	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 usuário 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. Importante: definir um bucket como publicReadWrite permite que qualquer pessoa na Internet faça upload de qualquer coisa para seu bucket. Você será responsável por esse conteúdo. *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 metadados Cache-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. Além disso, os proprietários do projeto recebem a permissão OWNER para todos os buckets no projeto que usam uma ACL predefinida.

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.

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 for feita uma solicitação autenticada para fazer upload de um objeto e não forem especificadas as ACLs de objetos, a pessoa que fez o upload será o proprietário do objeto e a ACL predefinida projectPrivate será aplicada ao objeto. Isso significa que:

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

Importante: se você alterar a ACL padrão de objetos em um bucket, a alteração poderá levar um tempo para se propagar, e os novos objetos criados no bucket ainda poderão receber a ACL padrão de objetos antiga por um curto período de tempo (consulte Consistência). Para garantir que os novos objetos criados no bucket recebam a ACL padrão de objetos atualizada, é necessário aguardar pelo menos 30 segundos entre a alteração da ACL e a criação dos objetos.

Comportamento da ACL

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 que o objeto está sendo enviado.

Observação: para desativar todas as características de propriedade de um bucket e dos objetos nele, ative o acesso uniforme no nível do bucket. Isso também remove todo o uso de ACLs no bucket, fazendo com que as políticas do IAM sejam o único sistema de controle de acesso usado pelo bucket.

A seguir

• Saiba como usar ACLs.
• Veja como simplificar seu controle de acesso com o acesso uniforme no nível do bucket.
• Saiba mais sobre as práticas recomendadas para o uso de ACLs.