> ## Documentation Index
> Fetch the complete documentation index at: https://strattumai.mintlify.site/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:

<CardGroup cols={2}>
  <Card title="Identidade (Zitadel)" icon="fingerprint">
    O identity provider da instalação. Cada usuário e serviço autentica por aqui. É onde os papéis (roles) são atribuídos.
  </Card>

  <Card title="Papéis e permissões (RBAC)" icon="user-lock">
    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.
  </Card>

  <Card title="Mascaramento de PII" icon="eye-slash">
    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.
  </Card>

  <Card title="Row-level security" icon="table-cells">
    Políticas por linha filtram quais registros um papel enxerga dentro de um mesmo dataset.
  </Card>
</CardGroup>

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.&#x20;
</Note>

***

## Próximos passos

<CardGroup cols={2}>
  <Card title="Data Catalog" icon="folder-open" href="/data-catalog/overview">
    Governança, campos PII e políticas de acesso por dataset.
  </Card>

  <Card title="BYOC e acessos do time" icon="server" href="/faq/byoc">
    O que o time da Strattum acessa e o que fica restrito à conta do cliente.
  </Card>
</CardGroup>