Skip to main content
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ê.
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.

Próximos passos

Data Catalog

Governança, campos PII e políticas de acesso por dataset.

BYOC e acessos do time

O que o time da Strattum acessa e o que fica restrito à conta do cliente.