Configurando a impersonificação de usuários

O processo de impersonalização

1. Criação de Service Account com Impersonificação

1.1. Criação da Service Account

1. No Google Cloud Console, acesse a seção IAM & Admin > Service Accounts.

2. Crie uma nova SA dedicada para execução das queries.

3. Anote o e-mail da SA criada (ex.: [email protected]).

4. No cadastro da SA, expanda a seção Configurações Avançadas e copie o Cliend ID que será exibido dentro do Domain-wide Delegation. Esta infomação será usada no passo seguinte.

---

1.2. Ativação do Domain-Wide Delegation

Para permitir que a Service Account atue em nome dos usuários finais:

1. Acesse o Google Workspace Admin Console. Você pode realizar o acesso clicando na opção View Google Workspace Admin Console do passo anterior.

2. No menu lateral vá em Segurança > Controle de Dadoes e Acesso > Controles de API.

   • 
3. Na seção Domain wide delegation clique em Gerenciar delegação de todo o domínio.

   • 
4. Adicione um novo cliente OAuth:

   • ID do cliente: Cole o Client ID da SA do passo 1.4.

   • Escopos de API: Inclua os escopos necessários:

     https://www.googleapis.com/auth/bigquery
     https://www.googleapis.com/auth/cloud-platform

   • 
5. Clique em Authorize para salvar as alterações.

Com isso, a Service Account pode ser usada para personificar usuários do domínio e garantir que as permissões sejam aplicadas de acordo com os e-mails cadastrados na tabela de segurança.

---

1.3. Concessão de Permissões à SA no Projeto Alvo

Garanta que a SA possua os papéis mínimos necessários no BigQuery:

• Nível IAM:

  • bigquery.jobs.create

  • bigquery.readsessions.create

  • bigquery.readsessions.getData

• Nível do Dataset (Leitura):

  • bigquery.datasets.get

  • bigquery.jobs.create

  • bigquery.tables.get

  • bigquery.tables.getData

  • bigquery.tables.list

---

2. Cadastro de Usuários no Projeto Alvo

2.1. Cadastro dos Usuários no Workspace

Garanta que todos os usuários que terão acesso aos dados estejam devidamente cadastrados no Workspace onde a SA com Domain Wide foi cadastradas.

Garanta também que o e-mail de cadastro dos usuários é o mesmo que será usado na tapa 3.

2.2. Permissões de Usuários no BigQuery

Mesmo utilizando impersonificação e tabela de segurança, é necessário que os usuários finais possuam permissões de acesso ao BigQuery dentro do projeto.

Cada usuário deve ter, no mínimo:

• roles/bigquery.user – permite executar queries.

• bigquery.jobs.create

• bigquery.readsessions.create

• bigquery.readsessions.getData

• Permissões herdadas de dataset/tabelas, caso a organização aplique controles adicionais de IAM em nível de recurso.

Importante:

• Se o usuário não tiver permissão de acesso ao BigQuery no projeto, a personificação não funcionará.

• A tabela de segurança restringe quais linhas o usuário pode ver, mas não substitui a necessidade de permissão básica de acesso ao serviço.

---

2.3. Cadastro da Tabela de Permissões

O BigQuery permite até 400 RAPs por tabela.

Para contornar essa limitação:

• Aplicamos subqueries em cada RAP, usando a tabela de permissões.

• Assim, podemos filtrar até 399 campos diferentes.

• Mantemos 1 RAP reservada para a política de full access (quando o usuário precisa visualizar todos os dados sem restrições).

Lembre-se que após criar RAPs em uma tabela, apenas usuários que estão contemplados por elas conseguem acessar os dados. Com isso, SEMPRE crie uma RAP de full access para quem for pertinente.

CREATE OR REPLACE ROW ACCESS POLICY full_access_policy
ON `projeto.dataset.tabela_vendas`
GRANT TO ("user:[email protected]")
FILTER USING (
  TRUE
  )
);

Crie uma tabela dedicada para armazenar permissões por usuário.

A coluna principal (usuário) precisa conter os mesmos emails que estão cadastrados para os usuários do workspace.

Exemplo de schema:

usuario	loja_id	regional_id	categoria_id
[email protected]	101	NULL	A
[email protected]	NULL	55	B
[email protected]	202	NULL	C

Essa tabela será utilizada nas subqueries dentro das RAPs para verificar permissões de acesso.

---

2.4. Criação das Row Access Policies

Com base na tabela de segurança, criamos as RAPs utilizando subqueries.

Exemplo de RAP em tabela_vendas:

CREATE OR REPLACE ROW ACCESS POLICY loja_policy
ON `projeto.dataset.tabela_vendas`
GRANT TO ("allAuthenticatedUsers")
FILTER USING (
  loja_id IN (
    SELECT loja_id
    FROM `project.dataset.tabela_permissionamento`
    WHERE usuario = SESSION_USER()
  )
);

Esse padrão pode ser replicado para cada campo que precisa de filtro: loja_id, regional_id, categoria_id, etc.

Ao configurar os GRANTS, podemos informar os seguintes valores:

• user:{email do usuário do GCP}

• group:{grupo de email do GCP}

• domain:{Domínio do GCP}

• serviceAccount:{email da service account}

• allAuthenticathedUsers

Para exemplos de como como configurar as grants, acesse a documentação oficial do GCP

---

3. Exemplos de Testes

Após configurar as RAPs e a tabela de segurança, é possível realizar testes de personificação para validar os acessos.

Para os testes, podemos utilizar o seguinte snippet de código em Python, variando apenas o valor passado na linha 11

from google.oauth2 import service_account
from google.cloud import bigquery

# Carrega a chave da SA
creds = service_account.Credentials.from_service_account_file(
    filename="caminha_para_sua_sa.json",
    scopes=["https://www.googleapis.com/auth/bigquery"]
)

# Impersona um usuário específico
impersonated_creds = creds.with_subject("email_do_usuario")

# Agora você usa impersonated_creds no cliente BigQuery
client = bigquery.Client(
    credentials=impersonated_creds, 
    project="seu_project_id"
    )

query = """
    SELECT 
    * 
    FROM `project.dataset.tabela_vendas`
    """
for row in client.query(query):
    print(row) 

Teste 1 – Usuário com acesso limitado a loja

impersonated_creds = creds.with_subject("[email protected]")

Consulta:

SELECT *
FROM `projeto.dataset.tabela_vendas`

✅ Retorna apenas registros da loja 101.

---

Teste 2 – Usuário com acesso a regional

impersonated_creds = creds.with_subject("[email protected]")

Consulta:

SELECT *
FROM `projeto.dataset.tabela_vendas`

✅ Retorna apenas registros da regional 55.

---

Teste 3 – Usuário sem acesso

impersonated_creds = creds.with_subject("[email protected]")

Consulta:

SELECT *
FROM `projeto.dataset.tabela_vendas`

❌ Retorna zero resultados, pois o usuário não consta na tabela de permissões.

---

Teste 4 – Usuário com acesso total (full access)

impersonated_creds = creds.with_subject("[email protected]")

Consulta:

SELECT *
FROM `projeto.dataset.tabela_vendas`

✅ Retorna todos os registros, respeitando a RAP de full access.