Controle de acesso

Visão geral

O BigQuery usa o Identity and Access Management (IAM) para gerenciar o acesso aos recursos. Os três tipos de recursos disponíveis no BigQuery são organizações, projetos e conjuntos de dados. Na hierarquia de políticas de IAM, conjuntos de dados são recursos filhos de projetos. Tabelas e visualizações são recursos filhos de conjuntos de dados. Eles herdam permissões do respectivo conjunto de dados pai.

Para conceder acesso a um recurso, atribua um ou mais papéis a um usuário, um grupo ou uma conta de serviço. Os papéis de organização e de projeto afetam a capacidade de executar jobs ou gerenciar os recursos do projeto. Por outro lado, os papéis de conjunto de dados afetam a capacidade de acessar ou modificar os dados dentro de um conjunto de dados particular.

O IAM fornece dois tipos de papéis: predefinidos e primários. Quando você atribui papéis predefinidos e primários a um usuário, as permissões concedidas são uma união das permissões de cada papel.

Permissões e papéis

Matriz de comparação de papéis predefinidos

Você pode atribuir os seguintes papéis predefinidos do BigQuery:

Capacidade	dataViewer	dataEditor	dataOwner	metadataViewer	user	jobUser	admin
Listar/receber projetos
Listar tabelas
Receber metadados de tabela
Receber dados da tabela
Criar tabelas
Modificar/excluir tabelas
Receber metadados do conjunto de dados
Criar novos conjuntos de dados
Modificar/excluir conjuntos de dados					Conjuntos de dados autocriados
Criar jobs/consultas
Receber jobs						Jobs autocriados	Qualquer job
Listar jobs					Qualquer job (jobs de outros usuários são editados)		Qualquer job
Cancelar jobs					Jobs autocriados	Jobs autocriados	Qualquer job
Receber/listar consultas salvas
Criar/atualizar/excluir consultas salvas
Criar sessão de leitura com a API BigQuery Storage do BigQuery
Receber transferências
Criar/atualizar/excluir transferências

Permissões do BigQuery

A tabela a seguir descreve as permissões disponíveis no BigQuery.

Permissão	Descrição
bigquery.jobs.create	Criar novos jobs.
bigquery.jobs.listAll	Listar todos os jobs e recuperar metadados em qualquer job enviado por qualquer usuário.*
bigquery.jobs.list	Listar todos os jobs e recuperar metadados em qualquer job enviado por qualquer usuário.* Para trabalhos enviados por outros usuários, detalhes e metadados são editados.
bigquery.jobs.get	Conseguir dados e metadados em qualquer job.*
bigquery.jobs.update	Cancelar qualquer job.*
bigquery.datasets.create	Criar novos conjuntos de dados vazios.
bigquery.datasets.delete	Excluir um conjunto de dados.
bigquery.datasets.get	Receber metadados sobre um conjunto de dados.
bigquery.datasets.update	Atualizar metadados para um conjunto de dados.
bigquery.tables.create	Criar novas tabelas.
bigquery.tables.list	Listar tabelas e metadados em tabelas.
bigquery.tables.delete	Excluir tabelas.
bigquery.tables.get	Receber metadados de tabela. Para receber dados de tabela, você precisa de bigquery.tables.getData.
bigquery.tables.getData	Receber dados da tabela. Para receber metadados de tabela, você precisa de bigquery.tables.get.
bigquery.tables.export	Exportar dados de tabela para fora do BigQuery.
bigquery.tables.update	Atualizar metadados de tabela. Para atualizar dados de tabela, você precisa de bigquery.tables.updateData.
bigquery.tables.updateData	Atualizar dados de tabela. Para atualizar metadados de tabela, você precisa de bigquery.tables.update.
bigquery.transfers.get	Receber metadados de transferência.
bigquery.transfers.update	Criar, atualizar e excluir as transferências.
bigquery.savedqueries.create	Criar consultas salvas.
bigquery.savedqueries.get	Receber metadados em consultas salvas.
bigquery.savedqueries.list	Listar de consultas salvas.
bigquery.savedqueries.update	Atualizar consultas salvas.
bigquery.savedqueries.delete	Excluir consultas salvas.
bigquery.readsessions.create	Crir nova sessão de leitura por meio da API BigQuery Storage do BigQuery.

* Para qualquer job criado, você tem automaticamente o equivalente em permissões de bigquery.jobs.get e bigquery.jobs.update.

Permissões do BigQuery ML

A tabela a seguir descreve as permissões disponíveis no BigQuery ML. Essas permissões estarão disponíveis até o final de abril de 2019, mas elas não entrarão em vigor até 6 de junho de 2019. Os clientes com papéis personalizados precisam migrar para essas permissões até 6 de junho. Os papéis pré-definidos do IAM e os papéis primários não são afetados por essa alteração.

Para mais informações sobre as versões do BigQuery ML, consulte as Notas da versão.

Permissão	Descrição
bigquery.models.list	Lista modelos e metadados em modelos.
bigquery.models.create	Cria novos modelos.
bigquery.models.delete	Exclui modelos.
bigquery.models.getMetadata	Consegue metadados do modelo. Para conseguir dados do modelo, você precisa de bigquery.models.getData.
bigquery.models.getData	Consegue dados do modelo. Para conseguir metadados de modelo, você precisa de bigquery.models.getMetadata.
bigquery.models.updateMetadata	Atualiza os metadados do modelo. Para atualizar os dados do modelo, você precisa de bigquery.models.updateData.
bigquery.models.updateData	Atualiza os dados do modelo. Para atualizar os metadados do modelo, você precisa de bigquery.models.updateMetadata.

Permissões necessárias para métodos

A tabela a seguir lista as permissões que o solicitante precisa ter para chamar cada método:

Método	Permissões necessárias
datasets.delete	bigquery.datasets.delete Se o conjunto de dados pretendido não estiver vazio, você também precisará de bigquery.tables.delete.
datasets.get	bigquery.datasets.get
datasets.insert	bigquery.datasets.create
datasets.list	Usa bigquery.datasets.get para verificar permissões em conjuntos de dados retornados.
datasets.patch	bigquery.datasets.update
datasets.update	bigquery.datasets.update
jobs.cancel	bigquery.jobs.update Você pode cancelar seus próprios jobs sem esta permissão.
jobs.get	bigquery.jobs.get Você pode receber seus próprios jobs sem esta permissão.
jobs.getQueryResults	bigquery.jobs.get Para receber resultados de jobs, você precisa ter permissões bigquery.jobs.get ou ser o proprietário. Além disso, é necessário ser o proprietário da tabela em que os resultados do job estão gravados.
jobs.insert	bigquery.jobs.create para iniciar o job A conclusão do job pode exigir permissões adicionais.
jobs.list	bigquery.jobs.list para mostrar todos os jobs de todos os usuários. Detalhes e metadados são editados no caso de jobs enviados por outros usuários. bigquery.jobs.listAll para mostrar todos os detalhes de todos os jobs de todos os usuários que usam o parâmetro allUsers=true.
jobs.query	bigquery.jobs.create para iniciar o job A conclusão do job pode exigir permissões adicionais.
projects.list	resourcemanager.projects.get
tabledata.insertAll	bigquery.tables.updateData
tabledata.list	bigquery.tables.getData
tables.delete	bigquery.tables.delete
tables.get	bigquery.tables.get
tables.insert	bigquery.tables.create Se o método cria uma visualização, ele também precisa de permissões de bigquery.tables.getData para todas as tabelas referenciadas na visualização.
tables.list	bigquery.tables.list
tables.patch	bigquery.tables.update
tables.update	bigquery.tables.update Se o método atualiza uma visualização, ele também precisa de permissões de bigquery.tables.getData para todas as tabelas referenciadas na visualização. Se a visualização já está autorizada no conjunto de dados, o método também precisa de bigquery.datasets.update em todos os conjuntos de dados associados às tabelas.
projects.transferConfigs.create	bigquery.transfers.update
projects.transferConfigs.get	bigquery.transfers.get
projects.transferConfigs.patch	bigquery.transfers.update

Papéis

A tabela a seguir lista os papéis de IAM da Google BigQuery API com uma lista correspondente de todas as permissões que cada papel inclui. Observe que cada permissão é aplicável a um tipo de recurso específico.

Papel	Inclui as permissões	para o tipo de recurso:
roles/bigquery.metadataViewer	resourcemanager.projects.get	Organização
	resourcemanager.projects.list	Organização
	bigquery.datasets.get	Conjunto de dados
	bigquery.tables.list	Conjunto de dados
	bigquery.tables.get	Conjunto de dados
roles/bigquery.dataViewer	Todos os itens acima, bem como:
	bigquery.tables.getData	Conjunto de dados
	bigquery.tables.export	Conjunto de dados
roles/bigquery.dataEditor	Todos os itens acima, bem como:
	bigquery.datasets.create	Projeto
	bigquery.tables.create	Conjunto de dados
	bigquery.tables.delete	Conjunto de dados
	bigquery.tables.update	Conjunto de dados
	bigquery.tables.updateData	Conjunto de dados
roles/bigquery.dataOwner	Todos os itens acima, bem como:
	bigquery.datasets.delete	Projeto
	bigquery.datasets.update	Conjunto de dados
roles/bigquery.user	resourcemanager.projects.get	Organização
	resourcemanager.projects.list	Organização
	bigquery.jobs.create	Projeto
	bigquery.jobs.list	Projeto
	bigquery.datasets.create	Projeto
	bigquery.datasets.get	Projeto
	bigquery.tables.list	Projeto
	bigquery.transfers.get	Projeto
	bigquery.savedqueries.get	Projeto
	bigquery.savedqueries.list	Projeto
	bigquery.readsessions.create	Projeto
roles/bigquery.jobUser	resourcemanager.projects.get	Organização
	bigquery.jobs.create	Projeto
roles/bigquery.readSessionUser	resourcemanager.projects.get	Organização
	resourcemanager.projects.list	Organização
	bigquery.readsessions.create	Projeto
roles/bigquery.admin	Todas as permissões de outros papéis, bem como:
	bigquery.jobs.get	Projeto
	bigquery.jobs.listAll	Projeto
	bigquery.jobs.update	Projeto
	bigquery.savedqueries.create	Projeto
	bigquery.savedqueries.delete	Projeto
	bigquery.savedqueries.update	Projeto
	bigquery.transfers.update	Projeto

Detalhes de papéis predefinidos

Detalhes de papéis predefinidos
roles/bigquery. user	Permissões para executar jobs, incluindo consultas, dentro do projeto. A maioria dos indivíduos (cientistas/analistas de dados) em uma empresa precisa ter o papel de usuário. Esse papel pode enumerar/cancelar os próprios jobs e enumerar conjuntos de dados dentro de um projeto. Além disso, permite a criação de novos conjuntos de dados dentro do projeto. O criador recebe o papel bigquery.dataOwner para esses novos conjuntos de dados. Lógica: este papel permite a separação do acesso a dados da capacidade de executar o trabalho no projeto, o que é útil quando os membros da equipe consultam dados de vários projetos. A enumeração de conjuntos de dados e de tabelas é incluída como uma maneira de ajudar os usuários a descobrir possíveis fontes de dados. Tipos de recurso: organização projeto
roles/bigquery. jobUser	Permissões para executar jobs, incluindo consultas, dentro do projeto. O papel jobUser pode receber informações sobre os próprios jobs e os cancelar. Lógica: este papel permite a separação do acesso a dados da capacidade de executar o trabalho no projeto, o que é útil quando os membros da equipe consultam dados de vários projetos. Esse papel não permite o acesso a nenhum dado do BigQuery. Se o acesso aos dados for necessário, conceda controles de acesso ao nível do conjunto de dados. Tipos de recurso: organização Projeto
roles/bigquery. readSessionUser	Permissões para criar e usar sessões de leitura no projeto por meio da API BigQuery Storage. Lógica: este papel permite separar o acesso a dados da capacidade de criar sessões de leitura no projeto. Os usuários com a permissão bigquery.readSessionUser não têm acesso aos dados da tabela. Para ler dados, é preciso conceder também permissões bigquery.tables.getData ou fornecer acesso de READER ao conjunto de dados que contém as tabelas. Tipos de recurso: organização projeto
roles/bigquery. dataViewer	Quando aplicado a um conjunto de dados, o dataViewer concede permissões para: ler os metadados do conjunto de dados e listar tabelas nele; ler dados e metadados das tabelas do conjunto de dados. Quando aplicado no nível de um projeto ou uma organização, esse papel também pode enumerar todos os conjuntos de dados no projeto. Porém, são necessários papéis adicionais para permitir a execução de jobs. Por exemplo, um usuário que simplesmente tem permissões bigquery.dataViewer em um conjunto de dados sem nenhuma outra permissão pode apenas listar as tabelas no conjunto de dados e usar as APIs get() para ler o conteúdo das tabelas. Ele não pode consultar os dados sem permissões adicionais. Para ver um exemplo de um usuário com permissões para executar consultas, pense no cenário a seguir: um usuário que tem permissões bigquery.user em projectA e permissões bigquery.dataViewer em projectA:dataset1 e projectB:dataset2 pode executar uma consulta no projectA que usa um ou ambos os conjuntos de dados. Para fontes de dados externas que não estejam armazenadas no BigQuery, podem ser necessárias outras permissões provenientes delas. Lógica: o papel dataViewer destina-se ao acesso de dados somente leitura. O dataViewer pode acessar dados, mas permissões adicionais, como aquelas concedidas pelos papéis bigquery.user ou bigquery.admin, são necessárias para emitir jobs de consulta. O dataViewer não acarreta custos. Tipos de recurso: organização projeto
roles/bigquery. metadataViewer	Quando aplicado na organização ou no nível do projeto, o metadataViewer fornece permissões para: listar todos os conjuntos de dados e ler metadados para todos os conjuntos de dados no projeto; listar todas as tabelas e visualizações e ler metadados para todas as tabelas e exibições no projeto. São necessários papéis adicionais para executar jobs. Lógica: o papel metadataViewer destina-se ao acesso apenas a metadados. O metadataViewer pode acessar o conjunto de dados, a tabela e visualizar metadados, mas para executar jobs de consulta são necessárias permissões adicionais, como as permissões concedidas pelo papel bigquery.user. Tipos de recurso: organização projeto
roles/bigquery. dataEditor	Quando aplicado a um conjunto de dados, o dataEditor concede permissões para: ler os metadados do conjunto de dados e listar tabelas nele; criar, atualizar, receber e excluir as tabelas do conjunto de dados. Quando aplicado no nível de um projeto ou de uma organização, esse papel também pode criar novos conjuntos de dados. Lógica: o papel dataEditor estende o bigquery.dataViewer por meio da emissão de privilégios de criação, atualização e exclusão para as tabelas dentro do conjunto de dados, mas sem a permissão de mutações do próprio conjunto de dados. Tipos de recurso: organização projeto conjunto de dados
roles/bigquery. dataOwner	Quando aplicado a um conjunto de dados, o dataOwner concede permissões para: ler, atualizar e excluir o conjunto de dados; criar, atualizar, receber e excluir as tabelas do conjunto de dados. Quando aplicado no nível de um projeto ou de uma organização, esse papel também pode criar novos conjuntos de dados. Lógica: o papel dataOwner estende bigquery.dataEditor por meio da inclusão da capacidade de modificar e excluir o conjunto de dados de contenção. Tipos de recurso: organização projeto conjunto de dados
roles/bigquery. admin	Permissões para gerenciar todos os recursos dentro do projeto. Pode gerenciar todos os dados e cancelar jobs de outros usuários. Tudo isso é feito dentro do projeto. Lógica: este é o papel de maior nível, com as responsabilidades mais amplas, o superusuário que auxilia os colegas durante a execução das várias análises deles. Tipos de recurso: organização projeto

Papéis personalizados

Além dos papéis predefinidos, o BigQuery também oferece suporte a papéis personalizados. Para mais informações, consulte Como criar e gerenciar papéis personalizados na documentação do Cloud IAM.

Os clientes que usaram papéis personalizados com o BigQuery ML precisam estar atentos às novas permissões que estarão disponíveis para uso com o BigQuery ML a partir de 6 de junho de 2019. Clientes com papéis personalizados precisam migrar para essas permissões até 6 de junho. Para mais informações sobre as versões do BigQuery ML, consulte as Notas da versão.

Permissões incompatíveis

As permissões a seguir só podem ser adicionadas a papéis personalizados no nível da organização. Eles não têm efeito no nível do projeto ou abaixo.

• resourcemanager.projects.list

As permissões a seguir podem ser alteradas de maneiras incompatíveis com versões anteriores e, portanto, não são recomendadas para uso em produção. Elas não estão sujeitas a nenhum SLA ou política de suspensão de uso.

• bigquery.config.get
• bigquery.config.update

Papéis primários do IAM

Os papéis primários do IAM são mapeados diretamente para os papéis legados do projeto de visualizador/editor/proprietário do BigQuery e os papéis do conjunto de dados de leitor/gravador/proprietário.

Transição de papéis primários

Para usuários mais familiarizados com a configuração de autorização legada, o BigQuery expôs uma combinação de papéis primários como as permissões de nível de projeto (leitor, gravador, proprietário).

Para fins de compatibilidade, as permissões legadas de nível por conjunto de dados são mapeadas diretamente para os papéis predefinidos equivalentes delas.

Permissões legadas do BigQuery	Equivalente do IAM
Projeto: pode visualizar	Papel primário: visualizador
Projeto: pode editar	Papel primário: editor
Projeto: é o proprietário	Papel primário: proprietário
Conjunto de dados: LEITOR	bigquery.dataViewer
Conjunto de dados: GRAVADOR	bigquery.dataEditor
Conjunto de dados: PROPRIETÁRIO	bigquery.dataOwner

Papéis primários para projetos

Por padrão, quando um projeto é acessado, também é possível acessar conjuntos de dados dentro dele. O acesso padrão pode ser substituído com base no conjunto de dados. Qualquer usuário com o papel Owner do projeto tem a capacidade de revogar ou alterar qualquer papel do projeto.

Quando um projeto é criado, o BigQuery concede o papel Owner ao usuário que o criou.

Papel primário	Recursos
Viewer	Pode executar um job no projeto. Papéis de conjuntos de dados adicionais são necessários, dependendo do tipo de job. Pode listar e conseguir todos os jobs, bem como atualizar os jobs iniciados para o projeto. Se você criar um conjunto de dados em um projeto que contenha qualquer visualizador, o BigQuery concederá a esses usuários o papel predefinido bigquery.dataViewer para esse novo conjunto.
Editor	Os mesmos que Viewer, além dos seguintes recursos: Pode criar um novo conjunto de dados no projeto. Se você criar um conjunto de dados em um projeto que contenha qualquer editor, o BigQuery concede a esses usuários o papel predefinido bigquery.dataEditor para esse novo conjunto.
Owner	Os mesmos que Editor, além dos seguintes recursos: Pode listar todos os conjuntos de dados do projeto. Pode excluir qualquer conjunto de dados do projeto. Pode listar e receber todos os jobs executados no projeto, incluindo aqueles executados por outros usuários. Se você criar um conjunto de dados, o BigQuery concederá a todos os proprietários do projeto o papel predefinido bigquery.dataOwner para esse novo conjunto. Exceção: quando um usuário executa uma consulta, um conjunto de dados anônimo é criado para armazenar a tabela de resultados em cache. Somente o usuário que executa a consulta recebe acesso OWNER ao conjunto de dados anônimo.

Os papéis primários para projetos são concedidos ou revogados por meio do Console do Google Cloud Platform. É preciso ter acesso Owner ao projeto para conceder ou revogar um novo papel.

Para mais informações sobre como conceder ou revogar o acesso para papéis do projeto, consulte Como gerenciar membros do projeto.

Papéis primários para conjuntos de dados

Os papéis primários para conjuntos de dados têm funções equivalentes às dos papéis predefinidos descritos em Transição de papéis primários.

Os papéis de conjuntos de dados podem ser concedidos aos seguintes tipos de entidades:

Tipo de entidade	API
Usuários únicos, por endereço de e-mail	access.userByEmail
Um Grupo do Google, por endereço de e-mail	access.groupByEmail
Um grupo predefinido, como todos os usuários, ou um grupo de usuários que têm o mesmo papel para o projeto que contém o conjunto de dados	access.specialGroup

Os seguintes papéis primários aplicam-se a conjuntos de dados:

Papel do conjunto de dados	Recursos
READER	Pode ler, consultar, copiar ou exportar tabelas no conjunto de dados. Pode chamar get no conjunto de dados. Pode chamar get e list nas tabelas no conjunto de dados. Pode chamar list nos dados de tabelas no conjunto de dados.
WRITER	Os mesmos que READER, além dos seguintes recursos: Pode editar ou acrescentar dados no conjunto de dados. Pode chamar insert, insertAll, update ou delete. Pode usar tabelas no conjunto de dados como destinos para jobs de carregamento, cópia ou consulta.
OWNER	Os mesmos que WRITER, além dos seguintes recursos: Pode executar update no conjunto de dados. Pode chamar delete no conjunto de dados. Observação: um conjunto de dados precisa ter pelo menos uma entidade com o papel OWNER. Um usuário com o papel OWNER não pode remover o próprio papel OWNER.

Quando você cria um novo conjunto de dados, o BigQuery adiciona o acesso padrão a esse conjunto para as seguintes entidades. Os papéis que você especifica na criação do conjunto de dados substituem os valores padrão.

Entidade	Papel do conjunto de dados
Todos os usuários com acesso Viewer ao projeto	READER
Todos os usuários com acesso Editor ao projeto	WRITER
Todos os usuários com acesso Owner ao projeto	OWNER Exceção: quando um usuário executa uma consulta, um conjunto de dados anônimo é criado para armazenar a tabela de resultados em cache. Somente o usuário que executa a consulta recebe acesso OWNER ao conjunto de dados anônimo.

Os papéis de conjuntos de dados são concedidos ou revogados usando uma das seguintes opções:

• Por meio da BigQuery API, usando a atualização.
• Por meio da IU da Web, clicando na lista suspensa ao lado do nome de um conjunto de dados e, em seguida, em Compartilhar conjunto de dados.
• Por meio da ferramenta de linha de comando `bq`, usando o comando `bq update`. Use o sinalizador `--source` para especificar um arquivo JSON contendo um recurso `dataset` parcial com o conjunto de campos `access`.

Exemplos de cenários

Os exemplos a seguir envolvem um grupo de cientistas de dados que pertencem a um Grupo do Google chamado AnalystGroup.

Acesso de leitura e gravação a dados em um conjunto

CompanyProject é um projeto que inclui dataset1 e dataset2. AnalystGroup1 é um grupo de cientistas de dados que trabalham somente com dataset1, e AnalystGroup2 é um grupo que só trabalha com dataset2. Eles precisam ter acesso total apenas ao conjunto de dados em que trabalham, incluindo para executar consultas nos dados.

Acesso de leitura e gravação a um conjunto de dados
No conjunto de dados CompanyProject:dataset1	Conceda o acesso WRITER ao AnalystGroup1 no dataset1. Esse papel faz o mapeamento no papel predefinido do IAM: bigquery.dataEditor.
No conjunto de dados CompanyProject:dataset2	Conceda o acesso WRITER ao AnalystGroup2 no dataset2. Esse papel faz o mapeamento no papel predefinido do IAM: bigquery.dataEditor.
No projeto CompanyProject	Conceda o acesso bigquery.user ao AnalystGroup1 e ao AnalystGroup2 no CompanyProject.

Com o acesso WRITER no nível do conjunto de dados, os cientistas de dados podem consultar dados nas tabelas do conjunto, mas não realizar consultas de jobs no projeto. Para isso, os grupos de cientistas de dados precisam ter o papel predefinido para envolvidos no projeto: bigquery.user. O papel bigquery.user concede permissões bigquery.jobs.create.

Como alternativa, é possível adicionar os grupos de cientistas de dados ao papel personalizado do IAM para envolvidos no projeto, que concede permissões bigquery.jobs.create.

Acesso total a dados em um projeto

AnalystGroup é um grupo de cientistas de dados que trabalham no BigQuery, e são responsáveis por todas as facetas do uso dele em um projeto chamado CompanyProject. O grupo prefere que todos os membros tenham acesso de leitura e gravação a todos os dados. Outros grupos da organização trabalham com outros produtos do Cloud Platform, mas ninguém mais interage com o BigQuery. O AnalystGroup não usa outros serviços do Cloud Platform.

Acesso total a dados em um projeto
No projeto CompanyProject	Adicione AnalystGroup ao papel predefinido bigquery.admin.

Acesso total em toda a organização

CompanyA é uma organização que quer que uma pessoa específica, denominada Admin1, seja o administrador de todos os dados do BigQuery em todos os projetos. MonitoringServiceAccount é uma conta de serviço responsável por monitorar o tamanho de todas as tabelas em todos os projetos na organização.

Acesso total em toda a organização
Na organização CompanyA	Adicione Admin1 ao papel predefinido bigquery.admin. Adicione MonitoringServiceAccount ao papel predefinido bigquery.dataViewer.

Se a empresa decidir que MonitoringServiceAccount também precisa ajustar as tabelas que excedem um determinado tamanho e remover dados mais antigos do que um período específico, ela também precisará ser adicionada ao papel predefinido bigquery.user.

Acesso de leitura a dados no mesmo projeto

AnalystGroup é um conjunto de cientistas de dados responsáveis por serviços de análise dentro de um projeto chamado CompanyProject. OperationsServiceAccount é uma conta de serviço responsável pelo carregamento de registros de aplicativos no BigQuery por meio de jobs de carregamento em massa para um conjunto de dados CompanyProject:AppLogs específico. Os analistas não estão autorizados a modificar os registros.

Acesso de leitura a dados no mesmo projeto
No projeto CompanyProject	Adiciona OperationsServiceAccount ao papel predefinido bigquery.user. Adiciona AnalystGroup ao papel predefinido bigquery.user.
No conjunto de dados CompanyProject:AppLogs	Adiciona OperationsServiceAccount ao papel predefinido bigquery.dataEditor. Adiciona AnalystGroup ao papel predefinido bigquery.dataViewer.

Acesso de leitura a dados em um projeto diferente

AnalystGroup é um conjunto de cientistas de dados responsáveis por serviços de análise dentro de um projeto chamado CompanyAnalytics. Os dados que eles analisam, no entanto, estão em um projeto separado, chamado CompanyLogs. OperationsServiceAccount é uma conta de serviço responsável pelo carregamento de registros de aplicativos no BigQuery por meio de jobs de carregamento em massa para vários conjuntos de dados no projeto CompanyLogs.

O AnalystGroup só pode ler dados no projeto CompanyLogs e não pode criar armazenamento adicional ou executar jobs de consulta nesse projeto. Em vez disso, os analistas usam o projeto CompanyAnalytics para realizar o trabalho deles e manter a produção dentro do projeto CompanyAnalytics.

Acesso de leitura a dados em um projeto diferente
No projeto CompanyLogs	Adiciona OperationsServiceAccount ao papel predefinido bigquery.admin. Adiciona AnalystGroup ao papel predefinido bigquery.dataViewer.
No projeto CompanyAnalytics	Adiciona AnalystGroup ao papel predefinido bigquery.user.

Manipulação programática de papéis

Você pode usar os seguintes métodos para manipular os papéis predefinidos no nível de conjunto de dados,

projeto e organização de maneira programática.

• Em conjuntos de dados, as operações dataset.insert, dataset.update e dataset.patch permitem configurações de papéis detalhadas em conjuntos de dados individuais por meio do campo de acesso.

• Em configurações no nível da organização e para envolvidos no projeto, use organizations.setIamPolicy e projects.setIamPolicy para adicionar e remover usuários e contas de serviço de papéis do IAM.