Compartilhamento e colaboração

Neste documento, você conhecerá cenários comuns de compartilhamento e colaboração de dados. Ele inclui como configurar as políticas de gerenciamento de identidade e acesso (IAM) de projetos e intervalos e as listas de controle de acesso (ACLs) de objetos para implementar os cenários.

Armazenamento e manutenção de dados particulares

Neste cenário, a analista de marketing de uma empresa quer usar o Cloud Storage para fazer backup de previsões de receita e dados de projeção de vendas confidenciais. Os dados só podem ser acessados pela analista de marketing. O departamento de TI da empresa supervisiona e gerencia a conta do Cloud Storage da empresa. Suas principais responsabilidades de gerenciamento incluem criar e compartilhar buckets para que vários departamentos da empresa tenham acesso ao Cloud Storage.

Para atender às necessidades de confidencialidade e privacidade da analista de marketing, as permissões de bucket e objeto precisam assegurar que a equipe de TI possa fazer a manutenção do bucket em que as planilhas estão armazenadas com a garantia de que essa equipe não conseguirá visualizar/fazer o download dos dados armazenados no bucket. Para isso, basta criar um bucket chamado finance-marketing e conceder os seguintes papéis para os recursos listados aos participantes especificados:

Papel	Recurso	Principal	Descrição
Proprietário do bucket legado do Storage	O bucket finance-marketing	Equipe de TI	Com o papel Proprietário do bucket legado do Storage, a equipe de TI pode executar tarefas comuns de gerenciamento de buckets, como excluir objetos e alterar a política do IAM no bucket. Também é possível listar o conteúdo do bucket finance-marketing, mas não visualizar ou fazer o download de qualquer conteúdo.
Criador de objeto do Storage	O bucket finance-marketing	Analista de marketing	Com o papel Criador de objeto do Storage, a analista de marketing pode fazer upload de objetos para o bucket. Ao fazer isso, ela se torna a proprietária do objeto, podendo visualizá-lo, atualizá-lo e excluí-lo.

Com esses papéis somente a analista de marketing poderá visualizar/fazer o download dos objetos que ela adicionar ao bucket. No entanto, ela pode conceder acesso a outros usuários alterando as ACLs do objeto. A equipe de TI ainda pode listar o conteúdo do bucket finance-marketing e pode excluir e substituir os arquivos armazenados no bucket em caso de necessidade.

Cuidado: como a equipe de TI tem permissão para gerenciar o bucket, ela pode conceder a si mesma ou a outros a permissão para exibir objetos no bucket. Para atenuar isso, é possível visualizar os registros de auditoria para rastrear as alterações feitas nas permissões de intervalos e projetos.

Implementar esse cenário

Suas ações

Execute as ações a seguir para implementar o cenário:

1. Crie um bucket com o nome finance-marketing. Para instruções passo a passo, consulte Como criar um bucket.

2. Atribua a cada membro da equipe de TI o papel Proprietário do bucket legado do Storage para o bucket. Veja instruções passo a passo em Como adicionar um participante a uma política no nível do bucket.

Ações da equipe de TI

A equipe de TI precisa realizar as seguintes ações para implementar o cenário:

1. Atribua à analista de marketing o papel Criador de objeto do Storage para o bucket. Veja instruções passo a passo em Como adicionar um participante a uma política no nível do bucket.

Caixa de depósito do fornecedor

Neste exemplo, uma construtora trabalha com várias firmas de arquitetura que fornecem planos de construção de diversos projetos. A construtora quer configurar uma caixa de depósito para as firmas fornecedoras, de modo que elas possam fazer o upload de planos de arquitetura em diversos marcos do projeto. A caixa de depósito precisa assegurar a privacidade dos clientes da construtora, o que significa que ela não pode permitir que os fornecedores vejam o trabalho uns dos outros. Para isso, basta criar um bucket separado para cada firma de arquitetura e conceder os seguintes papéis para os recursos listados aos participantes especificados:

Papel	Recurso	Principal	Descrição
Proprietário	Projeto geral	Gerente da construtora	Com o papel de Proprietário no nível do projeto, a gerente da construtora pode criar buckets para cada fornecedor.
Leitor de objetos do Storage	Projeto geral	Gerente da construtora	O Visualizador de objeto do Storage permite que a gerente da construtora faça o download dos objetos enviados pelos fornecedores.
Proprietário do bucket legado do Storage	Cada bucket de fornecedores	Gerente da construtora	O papel Proprietário do bucket legado do Storage permite que a gerente da construtora faça uma lista do conteúdo de cada bucket, além de excluir objetos ao final de cada etapa do projeto.
Administrador de objetos do Storage	Cada bucket de fornecedores	Fornecedor associado ao bucket	Com o papel Administrador de objetos do Storage cada fornecedor tem controle total sobre os objetos nos próprios buckets, incluindo a capacidade de fazer upload de objetos, listar objetos no bloco e controlar quem tem acesso a cada objeto. Isso não permite que eles alterem ou exibam metadados, como papéis no bucket como um todo, nem permite listar ou exibir outros buckets do projeto, preservando a privacidade entre fornecedores.

Implementar esse cenário

Suas ações

Execute as ações a seguir para implementar o cenário:

1. Atribua o papel de gerente da construtora ao Proprietário do projeto, bem como o papel Visualizador de objeto do Storage do projeto. Para instruções passo a passo, consulte Conceder um único papel.

Ações da gerente da construtora

A gerente da construtora precisa realizar as seguintes ações para implementar o cenário:

1. Criar um bucket separado para cada fornecedor. Para instruções passo a passo, consulte Como criar um bucket.

   Como a gerente da construtora tem o papel de Proprietário, ela recebe automaticamente o papel Proprietário do bucket legado do Storage para cada bucket que cria.

2. Atribua a cada fornecedor o papel Administrador de objetos do Storage para o respectivo bucket. Veja instruções passo a passo em Como adicionar um participante a uma política no nível do bucket.

3. Se algum fornecedor quiser usar o Console do Google Cloud, forneça um link para o bucket, que tem o seguinte formato:

   https://console.cloud.google.com/storage/browser/BUCKET_NAME

   em que BUCKET_NAME é o nome do bucket do fornecedor.

Ações do fornecedor

Cada fornecedor realiza as seguintes ações para implementar o cenário:

1. Fazer o upload de objetos no bucket atribuído. A maneira mais fácil de fazer isso é usando do Console do Google Cloud. Outros métodos, como a Google Cloud CLI, exigem mais configuração antes que possam ser usados. Para instruções passo a passo, consulte Como fazer upload de um objeto.

   Observação: com base nas permissões definidas neste cenário, os fornecedores precisam fazer login usando um dos e-mails associados ao bucket atribuído a eles.

Downloads em navegadores autenticados

Neste cenário, um cliente quer disponibilizar a indivíduos arquivos específicos para download simples em navegadores. Isso é possível com o uso da autenticação baseada em cookies do Cloud Storage. Para fazer o download de objetos, os usuários precisam se autenticar fazendo login em uma conta válida, que inclui o Google Workspace, o Cloud Identity, o Gmail e a federação de identidade de colaboradores. Os seguintes usuários autenticados podem fazer o download do objeto:

• Usuários com a permissão READ ou FULL_CONTROL que constem na lista de controle de acesso (ACL) do objeto

• Usuários com a permissão storage.objects.get na política do Identity and Access Management (IAM) referente ao bucket ou projeto que contém o objeto

Todos os outros usuários recebem um erro 403 Forbidden (access denied).

Para usar esse recurso, conceda a um usuário permissão de acesso à um objeto e forneça a ele um URL especial para o objeto. Assim que o usuário clicar no URL, o Cloud Storage vai solicitar que ele faça login na conta (se ainda não estiver conectado) e download do objeto vai ser feito.

Implementar esse cenário

É possível implementar a autenticação baseada em cookies em quatro etapas simples:

1. Crie um bucket. Para instruções passo a passo, consulte Como criar um bucket.

   Supondo que o bucket será criado em um projeto seu, você automaticamente receberá as permissões que permitem fazer upload de objetos para o bucket e alterar quem tem acesso a ele.

   Observação: caso você já tenha um bucket que queira usar, lembre-se de que, neste cenário, você está disponibilizando conteúdo sigiloso nesse bucket. Recomendamos verificar se os usuários anônimos não têm papéis no nível do projeto ou do bucket que deem acesso aos objetos.

2. Faça o upload do objeto que você quer compartilhar. Para instruções passo a passo, consulte Como fazer upload de um objeto.

   Quando faz upload de um objeto, você se torna proprietário desse objeto, o que significa que pode modificar as ACLs do objeto.

3. Conceda aos usuários acesso ao objeto. Isso pode ser feito de duas maneiras:

   1. Modifique a política e IAM do bucket para dar a cada usuário desejado o papel Leitor de objetos do Storage, que se aplica a todos os objetos no bucket. Veja instruções passo a passo em Como adicionar um participante a uma política no nível do bucket.

   2. Modifique as ACLs do objeto para que cada usuário apontado receba a permissão READ para o objeto individual. Para instruções passo a passo, consulte Como definir ACLs.

4. Forneça aos usuários um URL especial para o objeto.

   Para fazer o download, navegadores autenticados acessam o Cloud Storage por meio de um endpoint com URL específico. Use o seguinte URL:

   https://storage.cloud.google.com/BUCKET_NAME/OBJECT_NAME

   Em que:

   • BUCKET_NAME é o nome do bucket que contém o objeto desejado. Por exemplo, my-bucket.
   • OBJECT_NAME é o nome do objeto desejado. Por exemplo, pets/dog.png.

   Como somente os usuários com as permissões adequadas da ACL ou do IAM podem visualizá-lo, não importa como você disponibilizará esse URL. É possível enviá-lo diretamente ou postá-lo em uma página da Web.

Usar um grupo para controlar o acesso

Neste cenário, você quer disponibilizar objetos pessoas específicas, como usuários convidados a testar softwares novos. Além disso, você quer convidar muitos usuários, sem definir permissões individualmente. Ao mesmo tempo, você não quer tornar os objetos públicos e enviar links de acesso aos clientes convidados, porque há o risco de os links serem enviados para usuários que não foram convidados.

Uma maneira de resolver esse cenário é usando os Grupos do Google. É possível criar um grupo e adicionar a ele somente usuários convidados. Então, você pode dar acesso aos objetos para o grupo como um todo:

Papel	Recurso	Principal	Descrição
Leitor de objetos do Storage	Seu bucket	Grupo do Google	Com o papel Leitor de objetos do Storage para o bucket, o Grupo do Google permite que qualquer cliente que faça parte do Grupo do Google visualize objetos no bucket. Ninguém fora do grupo tem acesso a esses objetos.

Observação: ao usar grupos para gerenciar o acesso a seus recursos, lembre-se das políticas e limites de grupos que determinam quantos membros podem estar no grupo. Caso seja necessário convidar mais usuários do que o permitido para um grupo, crie um serviço que autentique usuários e os redirecione para um URL assinado por uma conta de serviço. Para mais informações, consulte URLs assinados (autenticação de string de consulta).

Implementar esse cenário

1. Crie um grupo do Google e adicione os clientes a ele. Para instruções passo a passo, consulte Criar um grupo.

2. Crie um bucket. Para instruções passo a passo, consulte Como criar um bucket.

3. Faça o upload dos objetos no bucket. Para instruções passo a passo, consulte Como fazer upload de um objeto.

4. Conceda acesso aos objetos para o grupo do Google.

   • É possível usar o papel storage.objectViewer do IAM para permitir a visualização de todos os objetos do bucket. Veja instruções passo a passo em Como adicionar um participante a uma política no nível do bucket.

   • Caso queira dar acesso a apenas alguns dos objetos do bucket, defina a ACL do Reader nesses objetos individuais. Para instruções passo a passo, consulte Como definir ACLs.

5. Compartilhe o endpoint de solicitação apropriado com o grupo para que ele saiba onde acessar os objetos.

   Por exemplo, ao usar o console do Google Cloud, o URL https://console.cloud.google.com/storage/browser/BUCKET_NAME leva você à lista de objetos do bucket BUCKET_NAME.

Usar pastas gerenciadas para controlar o acesso

Nesse cenário, você tem vários clientes, cada um deles proprietário de um site exclusivo com imagens personalizadas. Você quer que os clientes possam fazer upload de imagens apenas para o site deles, mas não para outros sites. Quando um cliente cancela a conta, você quer desativar o acesso público às imagens no site, mas evitar excluir as imagens caso o cliente queira reativar a conta.

Uma maneira de lidar com esse cenário é usando pastas gerenciadas. É possível criar várias pastas gerenciadas em um bucket e usar o IAM para controlar o acesso a pastas gerenciadas individuais de clientes e usuários finais.

Implementar esse cenário

1. Crie um bucket.

2. Crie uma pasta gerenciada no bucket do site de cada cliente.

3. Para cada pasta gerenciada, defina uma política do IAM que conceda a um cliente o papel de Usuário do objeto de armazenamento (roles/storage.objectUser). Assim, o cliente poderá fazer upload de objetos para a pasta gerenciada e remover objetos da pasta gerenciada.

4. Para todas as pastas gerenciadas, defina uma política do IAM que conceda o papel Leitor de objetos do Storage (roles/storage.objectViewer) ao allUsers principal. Assim, os objetos de imagem na pasta pastas podem ser visíveis para o público.

   Como alternativa, é possível conceder um papel personalizado que concede a allUsers a permissão storage.objects.get do IAM.

5. Quando um cliente cancela a conta, remova a política do IAM que concede a ele o papel de Usuário do objeto de armazenamento (roles/storage.objectUser) para a pasta gerenciada associada. Para desativar o acesso público aos objetos dentro dessa pasta gerenciada, remova a política do IAM que concede o papel de Leitor de objetos do Storage (roles/storage.objectViewer) a allUsers.