OneLake Security no Microsoft Fabric

Passo a passo resumido para configurar RLS — Row-Level Security usando o OneLake Security em uma tabela de um Lakehouse no Microsoft Fabric.

O objetivo é permitir que um usuário visualize apenas parte dos dados de uma tabela, sem precisar ter acesso ao workspace inteiro.

O OneLake Security permite aplicar segurança diretamente sobre os dados armazenados no OneLake, usando funções de acesso. Essas funções podem conceder acesso a pastas ou tabelas específicas e também aplicar regras mais finas, como RLS e CLS. A Microsoft descreve esse recurso como uma forma de aplicar controle de acesso baseado em funções aos dados armazenados no OneLake, determinando o que cada usuário pode ver nas experiências do Fabric.

O usuário não precisa ter acesso ao workspace.

Para esse cenário, o ideal é que ele tenha apenas acesso de leitura pelo OneLake Security no Lakehouse.

Isso ajuda a evitar permissões amplas demais e garante que a regra de RLS seja respeitada.

Cenário

Imagine uma tabela corporativa de chamados com dados de várias áreas:

chamados.chamados_corporativo

Essa tabela pode ter registros de TI, Cofres, Diferença de numerário e outras categorias. Nem todo usuário deve enxergar todos os registros.

Sem uma camada de segurança no dado, uma pessoa poderia consumir a informação por outro caminho, por exemplo:

NotebookSQL EndpointModelo semântico Direct LakeLakehouse

Por isso, a segurança precisa estar mais próxima da origem do dado, não apenas no relatório final.

A regra aplicada foi:

SELECT *

FROM chamados.chamados_corporativo

WHERE filtro_apoio_chamados IN ('Cofres', 'Diferença numerário')

Se o usuário estiver recebendo acesso pela função DefaultReader, ele pode acabar visualizando mais dados do que deveria.

Para um teste correto de RLS, remova o acesso amplo pelo DefaultReader e deixe o usuário apenas na função customizada.

Ajustar o SQL Analytics Endpoint

Na aba Segurança, clique em Visualizar modo de acesso a dados

Clique em Configurações do modo de acesso a dados

Altere para:

Usar a segurança do OneLake para tabelas

Modo de acesso à identidade do usuário

Esse modo equivale ao User identity.

Depois que o modo é alterado para User identity, as permissões de tabela passam a ser controladas pelo OneLake Security.

Ou seja, para tabelas, evite controlar o acesso via comandos SQL como GRANT SELECT

No meu caso, o usuário só deveria visualizar registros onde:

filtro_apoio_chamados = Cofres

filtro_apoio_chamados = Diferença numerário

Para compartilhar com o usuário

No lakehouse, clique nos três pontinhos... e depois em compartilhar

Insira o e-mail do usuário e permissão de leitura (primeira opção).

O que é RLS?

RLS significa Row-Level Security, ou segurança em nível de linha.

Ela controla quais linhas da tabela o usuário pode visualizar. No OneLake Security, é possível criar uma função e definir uma regra SQL para filtrar as linhas permitidas para os membros daquela função. Quando um usuário consulta a tabela, a regra é avaliada e apenas as linhas permitidas são retornadas.

Exemplo prático:

SELECT *FROM chamados.chamados_corporativoWHERE filtro_apoio_chamados = 'Cofres'   OR filtro_apoio_chamados = 'Diferença numerário'

Nesse exemplo, o usuário só verá chamados classificados como:

CofresDiferença numerário

Mesmo que a tabela tenha milhares de chamados de outras áreas, eles não aparecem para esse usuário.

O que é CLS?

CLS significa Column-Level Security, ou segurança em nível de coluna.

Ela controla quais colunas da tabela o usuário pode visualizar. Ou seja, mesmo que o usuário tenha acesso à tabela, algumas colunas podem ser ocultadas. Segundo a documentação da Microsoft, o CLS permite dar acesso apenas a um subconjunto de colunas de uma tabela Delta-Parquet; as colunas removidas da lista não ficam visíveis para os usuários.

Exemplo prático:

Uma tabela de chamados pode ter colunas como:

nome_usuariodesc_chamado_usuariovalor_apurado_periodovalor_pendente_credito

Se determinada área não puder visualizar dados sensíveis ou financeiros, usamos CLS para ocultar essas colunas, mantendo acesso apenas ao que é necessário.

Diferença entre RLS e CLS

Tipo de segurança	Controla o quê?	Exemplo
RLS	Linhas	Usuário vê apenas chamados de Cofres
CLS	Colunas	Usuário não vê colunas financeiras ou sensíveis
RLS + CLS	Linhas e colunas	Usuário vê apenas chamados de Cofres e sem dados financeiros

Exemplo no nosso cenário de chamados

No projeto de chamados, criamos uma estrutura no Lakehouse com camadas separadas:

silver.chamados_halosilver.chamados_cherwellchamados.chamados_corporativo

A tabela final de consumo é:

chamados.chamados_corporativo

Ela recebe dados do HALO e do Cherwell. Para controlar o acesso por área, usamos a coluna:

filtro_apoio_chamados

A regra para usuários da área de Cofres/Diferença de numerário pode ser:

SELECT *FROM chamados.chamados_corporativoWHERE filtro_apoio_chamados = 'Cofres'   OR filtro_apoio_chamados = 'Diferença numerário'

Assim, o usuário continua acessando a tabela corporativa, mas enxerga apenas os registros permitidos pela regra.

Atenção: segurança só na view pode não ser suficiente

Criar uma view filtrada pode ajudar, mas não resolve tudo se o usuário tiver acesso direto ao Lakehouse ou às tabelas de origem. O OneLake Security ajuda justamente porque a regra fica aplicada no nível do dado, e não apenas no objeto SQL final.

A Microsoft também informa que, para SQL Analytics Endpoint com OneLake Security, RLS, CLS e segurança em nível de objeto são definidos na experiência do OneLake, e que permissões SQL como GRANT e REVOKE em tabelas são ignoradas nesse contexto.

Boas práticas

O ideal é não dar acesso amplo ao Lakehouse para usuários finais. Eles devem acessar apenas o necessário.

Boas práticas:

1. Criar tabela final de consumo.2. Aplicar OneLake Security nessa tabela.3. Usar RLS para filtrar linhas.4. Usar CLS para ocultar colunas sensíveis.5. Testar com usuário Viewer.6. Evitar dar acesso direto às tabelas silver ou arquivos Files.

Conclusão

O OneLake Security é uma camada importante para governança no Microsoft Fabric. Ele permite proteger os dados diretamente no OneLake, independentemente do caminho usado para consulta.

A RLS responde à pergunta:

Quais linhas esse usuário pode ver?

A CLS responde à pergunta:

Quais colunas esse usuário pode ver?

No cenário de chamados, usamos RLS para permitir que determinados usuários vejam apenas registros em que:

filtro_apoio_chamados = Cofresoufiltro_apoio_chamados = Diferença numerário

Com isso, a segurança fica mais consistente, mais próxima do dado e menos dependente apenas do relatório ou da view final.