Por que o seu RLS do Power BI funciona no Desktop, mas vaza no Fabric

By Mirko Peters · 2026-08-11

Automatically translated with AI from the original post. Read the English original

Titelbild: Why Your Power BI RLS Works in Desktop But Leaks in Fabric

Bem-vindo de volta ao blog de engenharia de dados e analytics! Se você alguma vez criou um dashboard impressionante, validou o seu Row-Level Security localmente no Power BI Desktop, publicou na nuvem e depois entrou em pânico quando um usuário padrão acessou informações que não deveria ver, você definitivamente não está sozinho. A arquitetura de segurança em ambientes modernos de analytics é notoriamente complicada. Ao migrar do desenvolvimento local para plataformas em escala de nuvem, como o Microsoft Fabric, premissas que mantinham seus dados seguros no seu notebook podem simplesmente deixar de valer.

Neste post, vamos aprofundar por que o seu RLS do Power BI pode estar vazando após a implantação, como o mapeamento de identidades difere entre os ambientes e como você pode implementar padrões de segurança robustos e nativos da nuvem. Vamos desvendar a arquitetura por trás da segurança de dados corporativos.

Conceitos fundamentais (o modelo mental)

Antes de escrever uma única linha de Data Analysis Expressions, ou DAX, você precisa estabelecer o modelo mental correto para segurança. Muitos desenvolvedores tratam o Row-Level Security como um simples recurso de marcar uma caixa ou uma configuração administrativa rápida no fim do projeto. Na realidade, a segurança é um sistema interconectado.

Segurança com foco no modelo: Os relacionamentos e as direções de filtro determinam como o RLS se propaga. Se o seu modelo de dados tiver relacionamentos quebrados ou caminhos muitos-para-muitos inesperados, os filtros de segurança não vão chegar corretamente às suas tabelas de fatos.
Design de funções: Poucas funções, criadas com propósito específico, são melhores do que muitas funções sobrepostas e desorganizadas. Criar uma centena de funções estáticas para usuários individuais rapidamente se transformará em um pesadelo administrativo.
Contexto dinâmico: A segurança precisa responder a quem está visualizando o relatório e a com o que essa pessoa está relacionada na organização como um todo.
Realidade da nuvem: A resolução de identidades e as configurações do locatário no Fabric podem mudar radicalmente o comportamento em comparação com a sua máquina local. Entender como a nuvem mapeia a identidade do seu usuário é obrigatório.

Criando filtros confiáveis (padrões DAX)

Escrever expressões DAX seguras para as suas funções é a base do isolamento eficaz de dados. Dependendo da estrutura organizacional e da escala da sua empresa, você provavelmente vai escolher entre padrões de filtragem estáticos e dinâmicos.

RLS estático (públicos simples e fixos)

Exemplo na DimRegion:
DimRegion[Region] = "US"

RLS dinâmico por meio de tabela ponte (recomendado)

Tabelas: Users (UPN, UserKey), UserRegion (UserKey, RegionKey), DimRegion (RegionKey, Region)
Filtro da função em Users:
Users[UPN] = USERPRINCIPALNAME()
Opcionalmente, restrinja a DimRegion usando um relacionamento de Users > UserRegion > DimRegion.

Evite

Segurança baseada em colunas calculadas, que é avaliada no momento da atualização dos dados, e não dinamicamente de acordo com o contexto de cada usuário.
USERNAME() no Fabric (use sempre USERPRINCIPALNAME(); teste minuciosamente os formatos de e-mail e os sufixos de UPN).
Codificar diretamente e-mails individuais ou domínios dentro das suas expressões de filtro.

Padrões dinâmicos úteis

Modelos multilocatário: mapeie o TenantId da sua tabela central Users diretamente para as tabelas de fatos e dimensões.
Hierarquias: armazene os vínculos gestor-subordinado, materialize uma tabela de acesso e filtre por todos os descendentes estruturais do visualizador atual.

Design de funções e relacionamentos

A forma do seu modelo de dados define os limites de segurança. Use filtros de direção única sempre que possível, para evitar caminhos muitos-para-muitos ambíguos que possam contornar sem querer as restrições de segurança. Crie dimensões de segurança dedicadas, como tabelas ponte entre usuário e acesso, em vez de incorporar lógica de negócio complexa diretamente nas suas tabelas de fatos. Prefira sempre algumas funções reutilizáveis combinadas com filtros dinâmicos a dezenas de funções estáticas.

Atribuições sem surpresas (usuários e grupos)

Gerenciar atribuições de forma eficiente é fundamental para a saúde operacional de longo prazo. Sempre mapeie suas funções para grupos do Azure AD, e não para contas de usuários individuais, para garantir que o sistema escale sem problemas à medida que os funcionários mudam de equipe. Evite membros desatualizados agendando revisões trimestrais de acesso com os proprietários dos grupos. Fique atento a sobreposições de associações de grupo, pois usuários que pertencem a vários grupos de segurança podem ampliar, sem perceber, o acesso aos dados.

Desktop vs. Fabric: o que muda após a publicação

É aqui que acontece a maioria dos vazamentos de segurança. No Power BI Desktop, você trabalha em um ambiente local controlado. Depois que você publica no Microsoft Fabric, a nuvem assume o gerenciamento de identidade. O USERPRINCIPALNAME() retorna o endereço de e-mail da nuvem no Fabric, enquanto as visualizações prévias no Desktop podem se comportar de forma diferente, dependendo das credenciais locais. Além disso, o proprietário do conjunto de dados, as credenciais de atualização, as configurações do workspace e a latência de sincronização dos grupos no Azure AD podem alterar o que um usuário pode ver de fato.

Testes que realmente detectam vazamentos

Nunca confie apenas no recurso "Exibir como" do Power BI Desktop para validar a segurança de produção. Ele é útil para verificações rápidas, mas você precisa testar no Fabric. Valide com grupos de segurança reais e contas de usuários reais em um workspace de não produção. Teste cada função nas páginas principais dos relatórios e nos visuais sensíveis. Considere automatizar verificações pontuais por meio dos endpoints XMLA ou de ferramentas de automação, exportando pequenos conjuntos de resultados para contas de teste conhecidas.

Governança e operações

Manter a segurança ao longo do tempo exige uma governança rigorosa. Catalogue suas funções, documente seus filtros DAX, liste as tabelas afetadas e registre os públicos-alvo pretendidos. Imponha controle de mudanças por meio de pull requests que exijam evidências de testes de RLS antes de mesclar atualizações do modelo. Defina contratos de dados claros, especificando quais dimensões e fatos devem participar do RLS. Execute recertificações trimestrais de associação a grupos e monitore seus relatórios de alto risco em busca de anomalias.

Padrões comuns de falha (e correções)

Se você encontrar problemas, verifique estes padrões comuns de falha:

Funciona no Desktop, vaza no Fabric: causado pelo uso de USERNAME() ou por formatos de identidade incompatíveis. Correção: padronize o uso de USERPRINCIPALNAME() e alinhe os valores de Users[UPN].
O usuário vê dados demais: causado por um caminho muitos-para-muitos que contorna a segurança. Correção: introduza uma dimensão de segurança e restrinja os relacionamentos.
Acesso de equipe antiga persiste: causado por associações desatualizadas a grupos do Azure AD. Correção: automatize os fluxos de recertificação e os processos de remoção.
Coluna calculada usada para identidade: não gera efeito por usuário. Correção: mova a lógica para o DAX de filtro de função sobre as tabelas do modelo.

Checklist de início rápido (esta semana)

Adicione uma tabela Users indexada por USERPRINCIPALNAME() e relacione-a às suas tabelas de acesso.
Converta filtros fixos em filtros dinâmicos baseados em tabelas, sempre que fizer sentido.
Substitua qualquer lógica com USERNAME() por USERPRINCIPALNAME() e teste novamente no Fabric.
Mapeie as funções para grupos do AAD e agende uma revisão de acesso com os proprietários dos grupos.
Publique em um workspace de teste, valide com usuários reais e corrija quaisquer lacunas de identidade.
Documente suas funções, o DAX e as tabelas no README do modelo.

Recursos de SEO sugeridos

Slug da URL: power-bi-row-level-security-architecture
Meta título: Segurança em Nível de Linha no Power BI: arquitetura, padrões DAX e governança pronta para a nuvem
Meta descrição: Vá além da caixa de seleção do RLS. Aprenda padrões DAX dinâmicos, design de funções, mapeamento com o Azure AD e testes específicos do Fabric para manter dados sensíveis realmente seguros.
Palavras-chave: Power BI, Row-Level Security, RLS, USERPRINCIPALNAME, grupos do Azure AD, Fabric, RLS dinâmico, governança de dados

Conclusão

A segurança em nível de linha não é um recurso que você configura uma vez e esquece. Ela é um sistema vivo, formado por modelos de dados, relacionamentos, fórmulas DAX, mapeamento de identidades e configurações de governança na nuvem. Ao abandonar funções estáticas e frágeis, adotar tabelas-ponte dinâmicas e robustas e testar rigorosamente dentro do Microsoft Fabric, você garante que seus dados continuem seguros, não importa como sua organização cresça e mude.

Para se aprofundar ainda mais neste tema e ouvir estratégias práticas de implementação, não deixe de conferir nosso episódio de podcast relacionado: Implement Power BI Row-Level Security in Microsoft Fabric. Não se limite a bloquear seus dados — crie uma arquitetura de segurança resiliente que se adapte à medida que sua organização evolui!