Listas de controle de acesso (ACLs, na sigla em inglês)

Nesta página, você encontra uma visão geral das listas de controle de acesso (ACLs, na sigla em inglês). Para aprender a definir e gerenciar ACLs, consulte Criar e gerenciar Access Control Lists. Para saber mais sobre outras maneiras de controlar o acesso a intervalos e objetos, leia Visão geral do controle de acesso.

Você precisa usar listas de controle de acesso?

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

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

O que é uma lista de controle de acesso?

Uma lista de controle de acesso (ACL, na sigla em inglês) é um mecanismo que pode ser usado para definir quem tem acesso a intervalos e objetos, além do nível de acesso dessas pessoas. No Cloud Storage, ACLs são usadas com intervalos 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 intervalo 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 intervalo. 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 intervalo 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 intervalo 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 intervalos e objetos, a capacidade de criar um intervalo depende da permissão de projeto adequada.

Permissões

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

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

Intervalos Objetos
READER Permite que o usuário liste o conteúdo de um intervalo. Também permite que o usuário leia metadados do intervalo, 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 intervalo1. N/A. Não é possível aplicar essa permissão a objetos.
OWNER Concede ao usuário as permissões READER e WRITER no intervalo. Também permite que o usuário leia e grave metadados do intervalo, 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 intervalos são criados, a ACL project-private predefinida é aplicada a eles. Os intervalos 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 intervalo: 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 [NOME DE USUÁRIO]@[SEU DOMÍNIO].com
Domínio do Cloud Identity Domínio [NOME DE USUÁRIO]@[SEU DOMÍNIO].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 que constam 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 que constam nas ACLs, até que as entradas sejam removidas ou substituídas. 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. Ao fazer isso, cada conta de e-mail assume o formato [NOME_DE_USUÁRIO]@[SEU_DOMÍNIO].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 da Conta do Google é allAuthenticatedUsers.

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

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 intervalo, o usuário terá a permissão WRITER para o intervalo.

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 intervalo 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 intervalo ou objeto de uma só vez. As ACLs predefinidas são voltadas a cenários comuns, como a revogação de todas as permissões de acesso, exceto a do proprietário (ACL predefinida private), ou tornar um objeto disponível para leitura pública (ACL predefinida publicRead).

A tabela abaixo traz uma lista de ACLs predefinidas que podem ser usadas, além de mostrar 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 intervalos 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 do intervalo ou do objeto a permissão OWNER nesse intervalo ou objeto e remove todas as outras permissões de acesso.
    bucketOwnerRead bucket-owner-read Concede ao proprietário do objeto a permissão OWNER e ao proprietário do intervalo a permissão READER. Todas as outras permissões são removidas. É usada somente com objetos.
    bucketOwnerFullControl bucket-owner-full-control Concede aos proprietários do objeto e do intervalo a permissão OWNER. Todas as outras permissões são removidas. É 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 intervalos recém-criados. Também é a ACL padrão para objetos recém-criados, a menos que a ACL padrão de objetos desse intervalo tenha sido alterada.
    authenticatedRead authenticated-read Concede ao proprietário do objeto ou intervalo a permissão OWNER e concede a todos que tenham Contas do Google autenticadas a permissão READER. Todas as outras permissões são removidas.
    publicRead public-read Concede ao proprietário do objeto ou intervalo a permissão OWNER e concede a permissão READER a todos os usuários, autenticados e anônimos. Quando aplicada a um objeto, qualquer pessoa na Internet pode ler esse objeto sem passar pela autenticação. Quando aplicada a um intervalo, qualquer pessoa na Internet pode listar objetos sem passar pela autenticação.

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

    publicReadWrite public-read-write Concede ao proprietário do intervalo 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 intervalos. Quando aplicada a um intervalo, 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 metadados Cache-Control dos objetos como Cache-Control:private, max-age=0, no-transform.

ACLs padrão

Ao criar intervalos 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 intervalos do projeto permanecem inalteradas.

ACLs padrão de intervalos

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

Se você criar um intervalo com a ACL padrão de intervalos, 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 intervalos nesse projeto. Todos os membros da equipe do projeto podem listar objetos dentro dos intervalos. Todos os membros da equipe de projeto também podem listar intervalos dentro de um projeto, independentemente das ACLs do intervalo.

  • Editores do projeto

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

  • 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 intervalo pode fazer upload de objetos nesse intervalo. 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 intervalo tem uma ACL padrão de objetos. Ela é aplicada a todos os objetos enviados para esse intervalo 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:

    • A pessoa que fez o upload do objeto será listada como o proprietário do objeto. Não será possível alterar a propriedade do objeto 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 intervalo conceder ao grupo allUsers a permissão WRITER ou OWNER, as ACLs padrão de intervalos 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 intervalo ou objeto acessível a outros usuários, é necessário saber com quem compartilhar o intervalo 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 intervalos e objetos, especialmente em casos em que é necessário gerenciar intervalos 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 intervalos 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 intervalos.

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

  • Delegue o controle administrativo de seus intervalos.

    Por padrão, o grupo de proprietários do projeto é a única entidade com a permissão OWNER para um intervalo 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 intervalos 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 intervalo ou objeto diferente.

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

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

    O proprietário de um intervalo é 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 intervalo ou objeto, o Cloud Storage respectivamente concede a permissão OWNER ao proprietário do intervalo 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 intervalo ou objeto. Não confunda isso com a permissão OWNER. Uma vez criado no Cloud Storage, um intervalo ou objeto terá para sempre o mesmo proprietário. No entanto, é possível alterar de fato a propriedade de objetos (mas não de intervalos) 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á solicitando o upload se torna o proprietário do objeto. Lembre-se de que, para substituir um objeto, a pessoa que realiza essa operação e, portanto, torna-se proprietária do objeto, precisa ter a permissão WRITER ou OWNER no intervalo em que esse upload é realizado.