Listas de controle de acesso (ACLs)

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

Será que você precisa usar listas de controle de acesso?

Na maioria dos casos, o 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 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 o trabalho necessário com microgerenciamento.

O que é uma lista de controle de acesso?

Uma Access Control List (ACL) é 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 define quais ações podem ser executadas. Por exemplo, ler ou gravar.

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

Por exemplo, suponha que você quer que qualquer pessoa possa acessar objetos de um intervalo específico, mas também quer que seu colaborador possa adicionar ou remover objetos do intervalo. Nesse caso, sua ACL teria duas entradas:

  • Em uma entrada, você daria permissão READER para o escopo allUsers.

  • Na outra entrada, você daria 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 para 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 ACL do intervalo ou objeto e determina se permite ou rejeita a solicitação de acesso. Se a ACL permitir que o usuário realize a operação solicitada, a solicitação de acesso será concedida. Se a ACL não permitir que o usuário realize a operação solicitada, a solicitação de acesso não será concedida e será exibido um erro 403 Forbidden.

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 o que pode ser feito com 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, excluindo 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 Dá ao usuário as permissões READER e WRITER para o 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 intervalos são criados, a ACL project-private predefinida é aplicada a eles. Os intervalos são sempre propriedade do grupo project-owners. Quando é feito o upload de objetos, a ACL project-private predefinida é aplicada a eles. Os objetos são sempre de propriedade do solicitante original, que fez o upload do objeto.

1Não é possível alterar as seguintes propriedades de metadados do intervalo: acl, cors, defaultObjectAcl, lifecycle, logging, versioning e website.

Nesta página, geralmente nos referimos às permissões como READER, WRITER e OWNER, que é a maneira como são especificadas na API JSON e no Console do Google Cloud Platform. Se você estiver usando a API XML, as permissões equivalentes serão READ, WRITE e FULL_CONTROL, respectivamente. Quando a autenticação do OAuth 2.0 é usada para autenticar ferramentas e aplicativos (ou seja, conceder a eles permissão) para acessar a API do Google Cloud Storage em seu nome, o acesso é restrito pelo escopo do OAuth devstorage.read_only, devstorage.read_write e devstorage.full_control. 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 conforme 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 esse endereço de e-mail, clique em Sobre na página inicial do grupo do Google. Consulte a página inicial do Grupos do Google para saber mais.

    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 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 do grupo 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. Assim, cada conta fica no 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 de Conta do Google:

    Este identificador de escopo especial representa qualquer pessoa autenticada com uma Conta do Google. O identificador de escopo especial para todos os proprietários de Conta do Google é allAuthenticatedUsers.

  • Identificador especial para todos os usuários:

    Este 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 Platform, a API JSON ou o gsutil, é possível 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 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 uma permissão READ e uma permissão WRITE para um intervalo resulta em erro. Em vez disso, é necessário conceder ao usuário a permissão WRITE, que também concede ao usuário a permissão READ.

ACLs predefinidas

Uma ACL predefinida ou "automática" é um apelido para um conjunto de entradas específicas de ACL 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 permissão do proprietário (ACL predefinida private), ou tornar um objeto disponível para leitura pública (ACL predefinida publicRead).

A tabela abaixo lista as ACLs predefinidas que podem ser usadas e mostra quais entradas de ACL são aplicadas a cada ACL predefinida. Ao usar a tabela abaixo, lembre-se destas observações:

  • 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 intervalo ou ao proprietário do objeto a permissão OWNER para um 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 concede 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 projetos 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 de objeto padrão para esse 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 o objeto sem autenticação. Quando aplicada a um intervalo, 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 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 aos intervalos. Quando é aplicada a um intervalo, qualquer pessoa na Internet pode listar, criar, substituir e excluir objetos sem autenticação.

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

* Por padrão, objetos disponíveis para leitura pública têm um cabeçalho Cache-Control que permite que eles sejam armazenados em cache por 3.600 segundos. Se você precisar garantir que as atualizações se tornem visíveis imediatamente, defina os metadados de Cache-Control para os objetos como Cache-Control:private, max-age=0, no-transform.

ACLs padrão

Quando intervalos são criados ou quando é feito o upload de objetos, se uma ACL não for atribuída a eles explicitamente, eles receberão a ACL padrão. O processo para alterar a ACL padrão de um objeto é descrito em Como alterar as ACLs de objeto padrão. Quando a ACL padrão é alterada, não há alterações nas ACLs de objetos que já existem no intervalo ou de intervalos que já existem no projeto.

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 for criado um intervalo com a respectiva ACL padrão (ou seja, se não for especificada uma ACL predefinida ao criar o intervalo), a ACL projectPrivate predefinida será aplicada a ele. A ACL projectPrivate concede mais permissões aos membros da equipe do projeto com base nos papéis deles. Essas outras permissões são definidas da seguinte maneira:

  • Leitores de projeto

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

  • Editores de projeto

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

  • Proprietários de projeto

    A ACL projectPrivate concede as permissões OWNER aos proprietários do projeto. Os proprietários do projeto também podem executar todas as tarefas que os 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 projeto na página inicial do Console do Google Cloud Platform.

ACLs padrão de objetos

Por padrão, qualquer pessoa que tenha permissão OWNER ou WRITER para um intervalo pode carregar objetos nesse intervalo. Ao fazer o upload de um objeto, é possível fornecer uma ACL predefinida ou não especificar uma 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 e essa ACL é aplicada a todos os objetos desse intervalo que não tenham uma ACL predefinida ou uma ACL especificada na solicitação (somente API JSON). O valor inicial da ACL padrão de objetos é projectPrivate para 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. Veja o que isso quer dizer:

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

    • O proprietário do objeto recebe a permissão OWNER para o objeto. Caso seja atribuída ao proprietário qualquer permissão abaixo da de OWNER, o Cloud Storage automaticamente elevará a permissão para OWNER.

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

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

  • Uploads anônimos

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

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

Práticas recomendadas

Assim como qualquer outra configuração administrativa, as ACLs exigem gerenciamento ativo para serem efetivas. 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 seus intervalos e objetos.

    O princípio do menor privilégio é uma diretriz de segurança para concessão de privilégios ou direitos. Ou seja, é necessário conceder ao usuário o privilégio mínimo necessário para que execute a tarefa atribuída a ele. Por exemplo, para compartilhar um arquivo com alguém, conceda a essa pessoa a permissão READER e nã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 de objetos e intervalos.

  • Tenha cuidado com o modo como concede permissões a usuários anônimos.

    Os escopos allUsers e allAuthenticatedUsers só serão usados quando for aceitável que qualquer pessoa da Internet leia e analise seus dados. Embora esses escopos sejam úteis para alguns aplicativos e cenários, geralmente 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, sempre use as ACLs bucket-owner-read ou bucket-owner-full- control quando fizer upload de objetos em 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 a 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 da ACL do provedor de armazenamento correspondente.

    Para mais informações sobre o uso da API XML para acesso interoperável ao 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 nova ACL a um intervalo ou objeto, certifique-se de que o proprietário do intervalo ou objeto não seja alterado na nova ACL.

  • O proprietário do intervalo ou objeto sempre tem a permissão OWNER para o 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 o upload do objeto tenha sido feito por um usuário anônimo.

    Quando uma nova ACL é aplicada a um intervalo ou objeto, o Cloud Storage 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 criada no Cloud Storage, a propriedade do intervalo e do objeto é permanente. 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 está realizando a substituição (e, portanto, recebendo a propriedade do objeto) precisa ter a permissão WRITER ou OWNER no intervalo em que está sendo feito o upload do objeto.

Esta página foi útil? Conte sua opinião sobre:

Enviar comentários sobre…

Precisa de ajuda? Acesse nossa página de suporte.