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 oferece controle de acesso em todo o Google Cloud.
- O IAM tem mais controle sobre quais ações os usuários podem executar.
- As permissões do IAM concedidas a recursos pais, como projetos, são herdadas por recursos filhos, como buckets e objetos, o que permite gerenciar o acesso aos recursos com mais facilidade.
- As permissões do IAM podem ser aplicadas a pastas gerenciadas, ao contrário das ACLs.
- As ACLs não podem ser usadas exclusivamente para controlar o acesso aos recursos, porque não é possível definir ACLs no projeto geral ou em outros recursos pais.
Usar o IAM exclusivamente e permitir o acesso uniforme no nível do bucket permite usar outros recursos de segurança do Google Cloud, como compartilhamento restrito de domínios, federação de identidade de força de trabalho e Condições do IAM.
É provável que você queira usar ACLs nos seguintes casos:
- você precisa personalizar o acesso a objetos individuais em um bucket. As ACLs podem ser definidas para objetos individuais, enquanto as permissões do IAM s podem ser concedidas no nível do bucket ou superior.
- você está usando exclusivamente a API XML ou requer interoperabilidade com o Amazon S3.
O IAM e as ACLs funcionam em conjunto para conceder acesso a buckets e objetos, o que significa que o usuário só precisa da permissão relevante de um desses sistemas para acessar um bucket ou objeto.
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 deallUsers
.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 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. |
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 | 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 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/my-user@example.com |
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 entidadeUser
, ao usar o console do Google Cloud, ele é rotulado como um tipo de entidadePublic
.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 entidadeUser
, ao usar o console do Google Cloud, ele é rotulado como um tipo de entidadePublic
.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: gs-announce@googlegroups.com. 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 comoeditors-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.
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
eREADER
. Os escopos equivalentes da API XML sãoFULL_CONTROL
,WRITE
eREAD
.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ãoREADER
. É 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ãoOWNER
. 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ãoREADER
.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ãoREADER
. 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õesREADER
eWRITER
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 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 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 aOWNER
, o Cloud Storage automaticamente elevará a permissão paraOWNER
.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ãoWRITER
ouOWNER
, 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.
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ãoOWNER
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.
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.