RLS Power BI: como garantir que cada usuário veja só os seus dados

Toda empresa que distribui relatórios de Power BI chega à mesma pergunta: como mostrar o mesmo painel para a diretoria, para cada gerente regional e para cada vendedor sem que um veja os números do outro? Copiar o relatório para cada público parece rápido, mas multiplica a manutenção e o risco de alguém receber o arquivo errado.

A resposta é a RLS (row-level security, ou segurança em nível de linha). Com ela, um único modelo e um único relatório filtram os dados conforme o usuário que está logado. Para a maioria das empresas, o melhor caminho é a RLS dinâmica, com uma tabela de permissões e a função USERPRINCIPALNAME.

Neste guia você vê como a RLS Power BI funciona, a diferença entre estática e dinâmica, como configurar e testar, o que muda em relatórios embedded, os erros mais comuns e por que vale ter um app para gerenciar quem vê o quê.

O que é RLS no Power BI e como funciona?

A RLS é uma camada de segurança aplicada ao modelo semântico, a parte do Power BI que guarda tabelas, relacionamentos e medidas. Você cria funções (roles) e, para cada uma, escreve uma regra em DAX, a linguagem de fórmulas do Power BI, que diz quais linhas de uma tabela aquela função pode ver. O filtro se propaga pelos relacionamentos: se a função só enxerga a filial de Campinas na tabela de filiais, vendas, metas e estoque também ficam restritos a Campinas.

As funções são criadas no Power BI Desktop, e os usuários ou grupos são atribuídos a elas no serviço do Power BI. Um detalhe importante: a RLS só restringe quem tem permissão de Visualizador. Administradores, membros e colaboradores do workspace enxergam todos os dados, porque podem editar o conteúdo.

RLS estática ou dinâmica: qual escolher?

RLS estática

Na RLS estática, cada função tem um valor fixo na regra, como Região igual a Sul. Funciona bem quando há poucos recortes e eles quase não mudam. O problema aparece no crescimento: 30 filiais viram 30 funções, e cada mudança exige editar e republicar o modelo. Em operações com muitos clientes, filiais ou vendedores, a estática vira manutenção manual.

RLS dinâmica com USERPRINCIPALNAME

Na RLS dinâmica, existe uma única função e uma tabela de permissões que liga o e-mail de cada usuário ao que ele pode ver. A regra usa USERPRINCIPALNAME, função DAX que devolve o nome de login do usuário no Microsoft Entra ID, normalmente o e-mail corporativo. O Power BI compara esse login com a tabela e mantém só as linhas permitidas. Quando alguém muda de área, você altera uma linha na tabela, não o modelo.

Uma tabela de permissões simples costuma ter:

• E-mail do usuário, exatamente como aparece no login.
• Código do recorte permitido: filial, região, centro de custo, carteira de clientes ou país.
• Uma linha por combinação de usuário e recorte, para quem acessa mais de uma filial.
• Um indicador de acesso total para a diretoria, ou uma função separada sem filtro.

Como configurar e testar a RLS dinâmica?

O passo a passo abaixo serve para a maioria dos modelos em modo importação:

1. Crie a tabela de permissões em uma fonte controlada, como um banco de dados, com o e-mail e o código do recorte.
2. Carregue a tabela no modelo e deixe-a oculta. Evite ligá-la ao restante por relacionamento bidirecional.
3. Em Modelagem, Gerenciar funções, crie uma função com filtro na dimensão (por exemplo, Filial) que mantém só os códigos associados ao USERPRINCIPALNAME() na tabela de permissões.
4. Trate as exceções: acesso total para a diretoria e o que acontece com quem não está na tabela. O padrão seguro é não ver nada.
5. Teste no Desktop com Exibir como, simulando usuários reais.
6. Publique e, na opção Segurança do modelo semântico no serviço, adicione usuários ou grupos do Microsoft Entra ID à função.
7. Dê aos consumidores permissão de Visualizador ou distribua o conteúdo por um app do Power BI, para que a RLS seja aplicada.
8. Agende a atualização do modelo: em modo importação, mudanças na tabela de permissões só valem depois do refresh.

Como testar com Exibir como

No Power BI Desktop, a opção Exibir como, na guia Modelagem, permite escolher a função e informar outro usuário, simulando o resultado de USERPRINCIPALNAME. No serviço, o mesmo teste fica na Segurança do modelo semântico, em Testar como função. Monte um roteiro com casos reais: um usuário com uma filial, um com várias, um diretor e um e-mail que não está na tabela. Confira se os totais batem com o esperado. Medidas que usam ALL continuam respeitando a RLS, então um percentual sobre o total mostra o total do que o usuário pode ver, não o da empresa.

Como funciona a RLS em relatórios embedded?

Quando o relatório é incorporado a um portal ou sistema com o Power BI Embedded, há dois cenários. Se os usuários são da sua organização e entram com a conta do Microsoft Entra ID, a RLS funciona como no serviço. Se o relatório é exibido para clientes ou parceiros que não têm conta na sua organização, a aplicação se autentica no Power BI e gera um token de incorporação com uma identidade efetiva: o nome do usuário e as funções que se aplicam a ele.

Nesse caso, USERPRINCIPALNAME devolve o nome enviado pela aplicação, que pode ser um e-mail ou um código de cliente. A regra de ouro é que essa identidade seja definida no servidor, a partir do login do seu sistema, e nunca no navegador. Se você está decidindo entre incorporar o Power BI ou construir um painel próprio, veja quando usar dashboard em HTML/CSS ou Power BI.

RLS e segurança em nível de objeto: qual a diferença?

A RLS restringe linhas; a segurança em nível de objeto (OLS, object-level security) esconde tabelas ou colunas inteiras de determinadas funções. Ela é útil quando o problema não é qual filial a pessoa vê, mas qual informação: custo, margem ou salário, por exemplo. Para quem não tem acesso, a coluna simplesmente não existe no modelo, e visuais que dependem dela mostram erro. A OLS costuma ser configurada com ferramentas externas, como o Tabular Editor, e pode ser combinada com a RLS no mesmo modelo.

Quais são os erros mais comuns com RLS?

• Relacionamentos bidirecionais espalhados pelo modelo. Os filtros de segurança se propagam por caminhos inesperados, podem esconder ou liberar dados indevidamente e deixam o relatório mais lento.
• Uma função por cliente, filial ou pessoa. Dezenas de funções viram manutenção manual e aumentam a chance de alguém cair na função errada.
• Permissões controladas em uma planilha solta. Sem dono, sem histórico e sem validação, um e-mail digitado errado tira o acesso de alguém ou dá acesso a quem não deveria ter.
• Usar filtros de página ou segmentações para esconder dados. Isso não é segurança: o usuário pode mudar o filtro.
• Achar que a RLS vale para todos. Quem é membro, colaborador ou administrador do workspace vê tudo.
• Testar só com o próprio usuário. O caso que vaza costuma ser justamente o que ninguém simulou.

Por que usar um app para gerenciar os acessos?

Com RLS dinâmica, a segurança passa a depender da qualidade da tabela de permissões. Por isso, em vez de uma planilha, vale ter um pequeno aplicativo de cadastro, um CRUD (criar, consultar, alterar e excluir registros), onde a área de negócio concede e revoga acessos sem abrir chamado para a TI.

Um bom app de acessos tem login único com Microsoft Entra ID, lista de recortes vinda do próprio modelo (filiais, países, carteiras), aprovação quando necessário e histórico de quem concedeu o quê e quando, e grava os dados em um banco que o Power BI lê. Foi o caminho na MasterSense: as vendas de 4 países, em 3 idiomas, estão em um único BI no Microsoft Fabric com dados do SAP HANA, e um app de acessos define quem vê o quê. Esse tipo de aplicação faz parte dos nossos sistemas sob medida, e há um cadastro interativo com controle de acesso na nossa galeria de exemplos.

Como a Wolkee ajuda

A Wolkee desenha modelos de Power BI com RLS desde o início: tabela de permissões, regras em DAX, testes por perfil e, quando faz sentido, um app de gestão de acessos integrado ao Microsoft Entra ID. São 9 anos de mercado, mais de 500 entregas e projetos em 8 países, com dashboards e BI para finanças, vendas, operações e contact center.

Se você precisa revisar a segurança dos seus relatórios ou começar um modelo novo, agende um diagnóstico gratuito de 30 minutos. Mostramos um protótipo funcional antes do contrato e respondemos em até 1 dia útil.

Perguntas frequentes

RLS no Power BI exige licença Premium?

Não. A RLS não depende de uma licença específica: ela é definida no Power BI Desktop e aplicada no serviço. O que muda é o acesso ao conteúdo. Em workspaces compartilhados comuns, quem visualiza precisa de licença Pro ou Premium por usuário; em capacidades Premium ou Fabric de porte adequado, usuários com licença gratuita também podem visualizar. Confira as regras vigentes com a Microsoft.

A RLS funciona com DirectQuery?

Sim. A RLS funciona tanto em modo importação quanto em DirectQuery. No DirectQuery, os filtros de segurança são traduzidos para as consultas enviadas à fonte, então o desempenho depende também do banco de dados. Se o relatório usa conexão dinâmica com um modelo do Analysis Services, as funções são definidas nesse modelo, e não no arquivo do Power BI.

Usuários com RLS conseguem exportar dados que não deveriam ver?

Não. A exportação respeita a RLS: o usuário exporta apenas as linhas que pode ver no modelo. O ponto de atenção é outro: se ele tem permissão de edição no workspace, a RLS não se aplica e ele vê e exporta tudo. Também vale revisar, nas configurações do locatário e do relatório, quem pode exportar e em quais formatos.

Qual a diferença entre USERNAME e USERPRINCIPALNAME?

As duas funções identificam o usuário logado, mas podem devolver formatos diferentes. No Power BI Desktop, USERNAME costuma retornar domínio e usuário, enquanto USERPRINCIPALNAME retorna o login no formato de e-mail. No serviço, as duas retornam o nome principal do usuário. Por consistência entre ambientes, a recomendação geral é usar USERPRINCIPALNAME na regra e na tabela de permissões.