> ## Documentation Index
> Fetch the complete documentation index at: https://docs.strattum.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Gestão de acesso

> Como o controle de quem vê o quê funciona na plataforma, e o que acontece com fontes como BigQuery e Databricks onde o ACL da origem não propaga.

O controle de acesso da plataforma vive na própria plataforma, não é herdado da fonte de dados. Isso vale para qualquer origem e é o ponto que responde a pergunta sobre BigQuery e Databricks mais adiante.

***

## Como funciona

Quando um dado é ingerido, ele passa a viver no Data Catalog do cliente (object storage + DuckDB) e o acesso a ele é governado pela plataforma em três camadas:

> **Identidade (Zitadel)**
>
> O identity provider da instalação. Cada usuário e serviço autentica por aqui. É onde os papéis (roles) são atribuídos.

> **Papéis e permissões (RBAC)**
>
> O acesso a cada dataset é concedido por papel. As políticas ficam em YAML versionado no Workspace Git, com histórico e revisão por Pull Request.

> **Mascaramento de PII**
>
> Campos com dado pessoal (CPF, email, telefone) podem ser marcados para aparecer mascarados a papéis sem permissão. O valor real só é visível a quem tem o papel autorizado.

> **Row-level security**
>
> Políticas por linha filtram quais registros um papel enxerga dentro de um mesmo dataset.

Cada consulta a um dataset fica registrada no audit trail. Uma auditoria consegue demonstrar que um dado foi acessado apenas por serviços e papéis autorizados.

***

## E se for um BigQuery ou Databricks? O ACL não propaga

Está correto: o ACL da fonte não propaga na ingestão. Quando você conecta um BigQuery ou Databricks, as permissões de linha e coluna que existem lá **não** viajam junto com os dados. Isso não é uma limitação da plataforma, é como qualquer ingestão funciona: o dado sai da fonte e o controle de acesso da fonte fica na fonte.

A plataforma resolve isso re-estabelecendo o controle na própria camada dela. O acesso ao dado ingerido é definido pelo RBAC, pelo mascaramento de PII e pelas políticas de row-level security descritas acima, aplicados sobre o Data Catalog do cliente. Ou seja: você não depende do ACL do BigQuery/Databricks para governar quem vê o quê dentro da plataforma, porque a governança é refeita aqui.

Na prática, o desenho de acesso é o mesmo independente da fonte ser um Postgres, um BigQuery ou um Databricks. Você mapeia, uma vez, quais papéis enxergam quais datasets, quais campos são PII e quais linhas cada papel vê.

> [!NOTE]
>
> Espelhar automaticamente o ACL da fonte para a plataforma não faz parte do fluxo padrão. Se a exigência for reproduzir exatamente a matriz de permissões de um BigQuery ou Databricks, isso é um mapeamento explícito nas políticas do Catalog. No Databricks federado, os grants do Unity Catalog já viram acesso por tabela; veja [Databricks](https://docs.strattum.ai/data-pipelines/connectors/databricks.md). 

***

## Próximos passos

> **[Data Catalog](https://docs.strattum.ai/data-catalog/overview.md)**
>
> Governança, campos PII e políticas de acesso por dataset.

> **[BYOC e acessos do time](https://docs.strattum.ai/faq/byoc.md)**
>
> O que o time da Strattum acessa e o que fica restrito à conta do cliente.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.