RLS no Power BI: como implementar segurança por linha na prática

RLS Power BI é o que decide se um modelo serve muitos públicos ou vira um relatório por pessoa#

RLS Power BI, Row-Level Security, é o mecanismo que restringe quais linhas de dado cada usuário enxerga dentro do mesmo relatório, sem exigir uma cópia do modelo para cada perfil de acesso. O gerente de uma filial abre o mesmo dashboard que o diretor regional, vê os mesmos visuais, as mesmas medidas, mas só os números da sua própria unidade. É um dos controles mais usados em ambientes corporativos de Power BI e, ao mesmo tempo, um dos mais mal implementados: regra testada só uma vez, filtro que não propaga como deveria, relacionamento bidirecional que abre uma brecha silenciosa.

Este artigo cobre RLS na prática: estático x dinâmico, funções (roles) e filtros DAX, modelagem de tabela de segurança, comportamento em Import, DirectQuery e composto, riscos em relacionamentos bidirecionais, Object-Level Security, teste antes de publicar, apps e workspaces, e os erros que mais fazem RLS vazar dado. Para o modelo de dados por trás disso, veja também modelagem DAX e boas práticas em Power BI.

RLS estático e RLS dinâmico resolvem problemas diferentes, e confundir os dois é o erro mais comum#

RLS estático fixa o valor do filtro dentro da própria função: a role "Sudeste" filtra [Regiao] = "Sudeste", ponto final. Funciona bem com poucos grupos, estáveis, e atribuição manual de usuário a role no workspace. O problema é manutenção: todo usuário novo, ou toda mudança de região, exige voltar ao Power BI Service e reatribuir role, o que não escala em empresas com dezenas ou centenas de usuários.

RLS dinâmico resolve o gargalo filtrando com base em quem está logado, usando USERPRINCIPALNAME() ou USERNAME() combinado com uma tabela de segurança que relaciona login a que dado o usuário pode ver. Uma única role serve todo mundo, o filtro se ajusta para cada pessoa. USERPRINCIPALNAME() retorna o e-mail completo autenticado no Power BI Service e é a opção recomendada com Microsoft Entra ID. USERNAME() pode retornar formato de domínio local, gerando inconsistência entre Desktop e Service, por isso USERPRINCIPALNAME() é a escolha mais segura na maioria dos cenários.

Critério	RLS estático	RLS dinâmico
Como o filtro é definido	Valor fixo escrito na regra da role	Calculado em tempo real com base no usuário logado
Função DAX típica	Comparação direta, [Regiao] = "Sudeste"	USERPRINCIPALNAME(), USERNAME(), LOOKUPVALUE
Manutenção quando usuário muda	Manual, reatribuir role no workspace	Automática, basta atualizar a tabela de segurança
Escala para muitos usuários	Ruim, uma role por grupo, atribuição manual	Boa, uma role serve todos os usuários do modelo
Depende de tabela de segurança	Não necessariamente	Sim, quase sempre
Cenário ideal	Poucos grupos fixos, pouca rotatividade	Muitos usuários, hierarquia, alta rotatividade de acesso

Na prática, modelos corporativos maduros usam RLS dinâmico como padrão e reservam o estático para casos pontuais, como um relatório de diretoria com dois ou três perfis que raramente mudam.

Funções (roles) e filtros DAX são o mecanismo por trás de toda regra de RLS#

Toda regra de RLS vive dentro de uma função (role), criada em Power BI Desktop na aba de modelagem, em "Gerenciar funções". Cada função tem um nome e uma ou mais expressões DAX aplicadas a tabelas do modelo. A expressão precisa retornar verdadeiro ou falso por linha: se verdadeiro, a linha aparece para quem está atribuído àquela função; se falso, some de qualquer visual e de qualquer medida, sem exceção.

O ponto que gera confusão é onde aplicar o filtro. Funciona direto na tabela fato, mas em modelo estrela o mais comum é aplicar na dimensão e deixar o motor propagar o filtro pela relação até a fato, como qualquer segmentação de visual faria. A mesma disciplina de relacionamento e cardinalidade que sustenta boas medidas DAX sustenta RLS: modelo mal relacionado propaga filtro de forma imprevisível.

-- Regra dinâmica aplicada na tabela de dimensão Cliente
[EmailGestor] = USERPRINCIPALNAME()

Funções podem combinar múltiplas condições e usar FILTER para lógica mais elaborada. O cuidado é não transformar a regra em medida disfarçada, cheia de IF aninhado: quanto mais simples e mais próxima da tabela de segurança, mais fácil auditar depois.

Modelagem para RLS exige uma tabela de segurança bem desenhada, não filtro espalhado#

O padrão recomendado é criar uma tabela de segurança dedicada, separada das tabelas de negócio, com pelo menos duas colunas: identificador do usuário (e-mail) e o valor que ele pode acessar (região, cliente, unidade). Essa tabela se relaciona com a dimensão correspondente por um relacionamento de um-para-muitos, direção única, como qualquer outra dimensão do modelo estrela.

-- Regra aplicada na própria tabela de segurança
'Seguranca'[Email] = USERPRINCIPALNAME()

Com a regra em Seguranca e o relacionamento ativo com Dim_Regiao, o filtro se propaga naturalmente: o motor filtra Seguranca para a linha do usuário logado, isso filtra as regiões associadas em Dim_Regiao, e isso filtra a fato. Nenhuma medida precisa saber que RLS existe.

Duas vantagens dessa abordagem sobre escrever a regra direto na fato ou na dimensão de negócio:

• A tabela de segurança pode viver fora do Power BI, num data warehouse ou planilha governada, atualizada por quem administra acesso, sem republicar o .pbix a cada mudança de usuário.
• Um usuário pode ter múltiplas linhas de acesso na tabela de segurança, o que resolve com naturalidade gestores que respondem por mais de uma unidade, sem lógica DAX extra.

Para hierarquias com vários níveis, a tabela de segurança guarda a relação usuário-nó, e a regra usa PATH ou uma tabela de fechamento transitivo para resolver "vejo meu nível e tudo abaixo" sem reescrever a regra a cada mudança de estrutura.

RLS se comporta diferente em Import, DirectQuery e modelos compostos#

Em Import, o filtro é resolvido inteiramente pelo VertiPaq, em memória, depois que o dado já foi carregado, rápido e sem depender da fonte saber nada sobre segurança de linha. É o cenário mais simples de implementar e depurar.

Em DirectQuery, a regra é traduzida para a consulta enviada à fonte a cada interação, geralmente como cláusula no WHERE do SQL gerado. Dois cuidados são obrigatórios: performance, porque regra pesada (com LOOKUPVALUE complexo) é reenviada à fonte a cada consulta, não só no refresh; e permissão, o usuário de serviço da conexão precisa ler todos os dados na fonte, porque quem restringe a visão é o RLS do Power BI, não a permissão do banco.

Em modelo composto (mistura de Import e DirectQuery, ou múltiplas fontes DirectQuery), RLS exige atenção redobrada: tabelas em modos diferentes podem se comportar de forma distinta na propagação de filtro. A recomendação é sempre validar RLS direto no Power BI Service depois de publicar, sem confiar só no comportamento visto em Desktop.

Relacionamentos bidirecionais herdam RLS de um jeito que pode vazar dado sem ninguém perceber#

Relacionamento bidirecional propaga filtro nas duas direções: da dimensão para a fato, e da fato de volta para a dimensão. Parece conveniente para resolver um filtro cruzado pontual, mas em modelos com RLS é uma das causas mais comuns de vazamento silencioso de dado.

Cenário típico: RLS filtra Dim_Cliente para os clientes de um vendedor. Se existe relacionamento bidirecional entre Fato_Vendas e Produtos, e o usuário filtra por produto num visual, esse filtro pode se propagar de volta e alterar o que aparece em Dim_Cliente de um jeito não previsto na regra original, expondo combinação de dados que a RLS deveria bloquear. O mesmo risco existe em muitos-para-muitos, onde a falta de integridade referencial torna o filtro mais difícil de prever.

A regra prática, já válida para modelagem em geral, fica mais crítica com RLS no modelo: direção única por padrão, bidirecional só com justificativa documentada, e nesses casos, teste explícito de RLS depois de ativar o cruzamento, comparando o que cada perfil deveria ver com o que o relatório de fato mostra.

OLS esconde colunas e tabelas inteiras, RLS sozinho não faz isso#

RLS restringe linhas. Se o objetivo é impedir que um perfil veja uma coluna inteira, como salário, margem de custo ou CPF, mesmo tendo acesso ao restante do relatório, o controle certo é Object-Level Security, OLS. Diferente de RLS, o Power BI Desktop não tem interface nativa para OLS: é preciso usar ferramenta externa, tipicamente o Tabular Editor conectado ao modelo, para definir permissão de leitura por objeto (coluna, tabela ou medida) por função.

OLS aplicado corretamente esconde a coluna de qualquer lista de campos, visual ou consulta DAX feita por quem está naquela função, incluindo Analyze in Excel ou API. É diferente de ocultar a coluna na visualização, que é cosmético, o campo continua acessível por quem sabe procurar; OLS bloqueia no nível do motor.

Combinar RLS e OLS é comum em RH e financeiro: RLS garante que o gestor veja só o time dele, OLS garante que a coluna de salário fique invisível para quem não tem permissão. É a combinação que evita multiplicar relatórios por perfil, princípio que também sustenta governança de dados aplicada a Power BI.

Testar a função antes de publicar não é opcional: use Exibir como#

Power BI Desktop tem o recurso Exibir como função ("View as Roles"), na aba de modelagem, que simula o modelo com uma ou mais funções ativas, mostrando exatamente o que aquele perfil veria. É possível simular com uma role específica, combinar mais de uma, ou testar com um e-mail no lugar de USERPRINCIPALNAME(), útil para validar RLS dinâmico sem logar com outra conta.

O erro comum é testar uma vez, no dia da publicação, e nunca mais. RLS precisa ser testado de novo a cada mudança no modelo: coluna nova na tabela de segurança, relacionamento alterado, medida que usa ALL ou REMOVEFILTERS de forma mais ampla do que deveria. Teste no Desktop cobre a lógica da regra, mas não substitui teste no Power BI Service depois de publicar, porque é lá que entram variáveis reais: workspace, papel do usuário, app, comportamento efetivo do DirectQuery contra a fonte de produção. A rotina recomendada é simples: a cada mudança de modelo, rodar Exibir como para os perfis críticos antes de promover para produção.

RLS dentro de apps e workspaces exige atenção ao papel do usuário, não só à regra DAX#

RLS só é aplicado a usuários com papel de Visualizador no workspace, ou a quem acessa via app publicado com atribuição de função. Membros, Colaboradores e Administradores do workspace, por padrão, veem o modelo sem restrição de RLS, porque esses papéis têm permissão de edição, e o Power BI assume que quem edita precisa ver o dado completo.

Essa é uma das causas mais comuns de "RLS não está funcionando": o teste foi feito com conta de Colaborador, então a regra nunca foi aplicada. A forma correta de testar é com conta de Visualizador, idealmente via app publicado, como o usuário final vai consumir.

Ao publicar via app, é preciso atribuir explicitamente qual função de RLS cada grupo recebe, associando grupos de segurança do Microsoft Entra ID a funções do modelo. Sem essa atribuição, o usuário do app fica sem função associada, e o padrão costuma ser não ver nenhuma linha, erro que aparece como "relatório vazio" e é fácil confundir com problema de dado.

Erros comuns de RLS e a correção prática#

Erro comum	Por que acontece	Correção
Admin/Membro "não vê" a RLS funcionando	Papéis de edição ignoram RLS por padrão	Testar sempre com conta Visualizador ou via app, nunca com conta que edita o modelo
RLS "vaza" dado entre perfis	Relacionamento bidirecional ou N:N sem controle propaga filtro de volta	Direção única por padrão, revisar todo bidirecional em modelo com RLS ativo
Relatório aparece vazio para o usuário do app	Nenhuma função de RLS atribuída ao grupo do app	Atribuir explicitamente cada grupo de segurança a uma função ao publicar o app
Performance ruim em DirectQuery com RLS	Regra complexa reenviada à fonte a cada consulta	Simplificar a expressão, indexar a coluna filtrada na origem
USERNAME() retorna valor inconsistente	Formato de login varia entre Desktop, Service e tipo de autenticação	Usar USERPRINCIPALNAME() como padrão em ambientes com Microsoft Entra ID
Regra testada só na publicação inicial	Falta de rotina de revalidação após mudança no modelo	Reexecutar Exibir como a cada mudança de modelo, relacionamento ou tabela de segurança
Coluna sensível visível mesmo com RLS ativo	RLS restringe linha, não coluna	Aplicar OLS via Tabular Editor para a coluna específica

RLS Power BI é minimização de acesso, e minimização de acesso é obrigação da LGPD#

RLS não é só conveniência para não duplicar relatório, é a implementação técnica de um princípio central da LGPD: minimização, a ideia de que uma pessoa só acessa o dado pessoal estritamente necessário para sua função. Relatório de vendas com CPF ou contrato de cliente, aberto sem RLS para todo o time comercial, é exposição além do necessário, mesmo sem má intenção de ninguém, e é exatamente o tipo de falha que gera risco de autuação.

O mesmo vale para OLS em relação a dado sensível em coluna, como saúde, dado bancário ou informação de menores. Tratamos esse cruzamento entre controle técnico e exigência legal com mais profundidade em governança de dados, Power BI e LGPD. Vale reforçar: RLS bem implementado reduz risco jurídico, mas não substitui processo, quem administra a tabela de segurança e quem revisa acesso continua sendo decisão organizacional, não só configuração técnica.

Perguntas frequentes#

RLS estático e RLS dinâmico podem coexistir no mesmo modelo? Sim. É comum ter uma função dinâmica para a maior parte dos usuários, com USERPRINCIPALNAME() e tabela de segurança, e uma ou duas funções estáticas para casos pontuais, como acesso total da diretoria.

RLS funciona em licença Pro, ou só em Premium? RLS funciona em qualquer licenciamento, incluindo Pro. O que muda entre licenças é capacidade e recursos de governança mais avançados, não a disponibilidade de RLS.

OLS Power BI exige alguma licença especial? Não exige licença diferente, mas exige ferramenta externa, como o Tabular Editor, porque o Power BI Desktop não tem interface nativa para permissão por objeto do modelo.

RLS protege o dado quando alguém exporta o relatório para Excel? RLS restringe o que o usuário vê antes de exportar, então o Excel exportado só contém as linhas que ele já podia ver. Para proteger o arquivo exportado em si, o controle certo é sensitivity label, não RLS.

Por que meu teste com Exibir como funcionou, mas o usuário real não vê a restrição? Verifique o papel dele no workspace primeiro. Se é Membro, Colaborador ou Administrador, RLS não se aplica por padrão, independentemente de a regra estar correta.

RLS deixa o Power BI mais lento? Em Import bem modelado, o impacto costuma ser pequeno. Em DirectQuery, pode ser real se a regra for complexa, porque é reenviada à fonte a cada consulta, esse é o cenário que mais exige cuidado.

RLS bem feito é modelagem, não configuração de última hora#

Segurança por linha que funciona não nasce de marcar uma caixinha depois que o relatório já está pronto. Nasce de decisão de modelagem desde o início: tabela de segurança dedicada, relacionamento direcionado corretamente, RLS dinâmico como padrão, OLS onde há coluna sensível, e rotina real de teste com Exibir como antes de publicar. Ignorar isso não economiza tempo, só transfere o custo para o dia em que um vazamento de acesso aparece em produção.

Se sua empresa tem relatórios com dado sensível circulando sem controle de linha ou coluna, ou se RLS já existe mas nunca foi testado com rigor, vale rever o modelo antes que isso vire incidente. Conheça como estruturamos segurança e modelagem dentro dos serviços de Power BI da Fynx e fale com a gente para um diagnóstico da sua implementação atual de RLS.