Segurança por linha no Power BI: cada gerente vê só a sua área

Em resumo

• A segurança por linha (em inglês, row-level security, daí a sigla RLS) filtra as linhas de um modelo semântico conforme quem abre o relatório, o que permite publicar um único painel para a diretoria e para cada gerente de agência, sem duplicar nada.
• No Power BI Desktop, define-se uma função com filtro DAX na tabela de agências, apoiado numa tabela que liga cada login à sua agência e lido com USERPRINCIPALNAME(); no serviço, os grupos de segurança do Entra ID entram na função pela página Segurança do modelo semântico.
• Administrador, membro e colaborador do workspace não são filtrados e veem todas as linhas, então quem só consome o relatório precisa ter o papel de Visualizador.
• Grupos do Microsoft 365 não são aceitos nas funções, de modo que a TI controla o acesso por grupos de segurança do Entra ID, enquanto a agência de cada gerente fica na tabela de mapeamento.
• O teste com Exibir como antes de publicar, repetido no serviço e com um usuário real no papel de Visualizador, é o que pega o login diferente do e-mail e o filtro que soma agências sem querer.

Como configurar segurança por linha no Power BI para que cada gerente veja só a sua agência?

Crie no Power BI Desktop uma função com um filtro DAX na tabela de agências, que compara o login de quem abre o relatório (USERPRINCIPALNAME()) com uma tabela de mapeamento de usuário para agência, publique o modelo e inclua grupos de segurança do Entra ID nessa função, na página Segurança do modelo semântico, no serviço. Depois disso, quem só consome o relatório deve ficar como Visualizador do workspace, porque administrador, membro e colaborador não são filtrados e enxergam todas as linhas.

A documentação da Microsoft sobre segurança por linha em modelos semânticos do Power BI descreve esse mesmo fluxo em quatro etapas (definir funções no Desktop, publicar, incluir membros no serviço e validar) e registra a regra que mais surpreende quem implanta: o filtro só restringe dados para quem tem permissão de Visualizador. O compartilhamento do relatório em si, com link, aplicativo e permissões de leitura, já foi tratado no post sobre compartilhamento e permissões de 13 de outubro de 2025, e aqui entra só o que muda quando existe segurança por linha.

Pense numa cooperativa de crédito com dezenas de agências, em que o painel de carteira (saldo, inadimplência, concessões do mês) nasceu para a diretoria e, algumas semanas depois, cada gerente pediu o seu, só com a própria agência. A saída habitual da TI é exportar uma cópia do relatório por agência, o que funciona até a primeira correção de cálculo, porque aí é preciso refazer dezenas de cópias, e quando uma agência nova abre ninguém lembra de criar mais uma. Com a segurança por linha passa a existir um relatório, um modelo e uma regra, e o que muda de gerente para gerente é apenas o grupo a que ele pertence e a linha dele na tabela de mapeamento.

Pré-requisitos e quando não usar

• Power BI Desktop atualizado e um modelo em Import ou em DirectQuery; modelos Direct Lake também aceitam a segurança por linha, segundo a documentação de RLS do Power BI.
• Papel de Colaborador ou superior no workspace para ver a opção Segurança do modelo semântico; dependendo do cenário, também pode ser exigido ser o proprietário do modelo ou ter a permissão Build, conforme a mesma documentação.
• Permissão no Entra ID para criar e administrar grupos de segurança, ou alguém da TI que faça isso a pedido.
• Licença adequada para quem consome o relatório, que depende do tipo de capacidade do workspace; o quadro está em licenças do Microsoft Fabric e vale conferir antes de convidar os gerentes.
• Uma lista confiável de quem gerencia qual agência, mantida por quem já a mantém hoje, seja o cadastro de agências do sistema de crédito, seja uma lista no SharePoint.

Esta técnica não serve quando o que precisa ser escondido é uma coluna inteira, como o rating interno do associado, porque a segurança por linha remove linhas e não colunas, e nesse caso o recurso certo é a segurança em nível de objeto. Também não se aplica a modelo que chega por conexão ao vivo com o Analysis Services ou o Azure Analysis Services, porque nesse caso a opção de segurança nem aparece no Power BI e a regra precisa ser definida no modelo de origem, como informa a documentação.

Passo a passo

A ordem importa porque cada etapa depende da anterior: sem a função não existe página Segurança no serviço, sem o teste o erro só aparece na mão do gerente, e sem a revisão dos papéis do workspace o filtro inteiro pode ser contornado sem que ninguém perceba.

O último passo é o que mais falha: o filtro só vale para quem é Visualizador, e quem edita o workspace vê tudo.

Passo 1: crie a função e o filtro DAX no Desktop

No Power BI Desktop, abra a guia Modelagem, clique em Gerenciar funções e em Nova, e dê um nome à função, como "Gerente de agência". O nome não pode ter vírgula, e vale evitar acentos e espaços se o modelo for ser consultado por outras ferramentas. Em "Selecionar tabelas", escolha a tabela de agências, a dimensão que o resto do modelo usa para filtrar carteira, contratos e inadimplência, e alterne para o editor DAX, porque regras dinâmicas só podem ser escritas ali.

Para entender o mecanismo, comece com o filtro mais simples, que fixa uma agência. A expressão devolve verdadeiro ou falso para cada linha da tabela, e só as linhas verdadeiras ficam visíveis, de modo que o restante é removido do ponto de vista de quem está na função.

[CodAgencia] = "0012"

O filtro vai na dimensão, e não nas tabelas de fatos, porque o relacionamento já propaga a restrição da agência para a carteira e para os contratos, e porque assim existe um único lugar a conferir. Por padrão, a segurança por linha só propaga o filtro no sentido do relacionamento, mesmo que o relacionamento esteja marcado como bidirecional, e a caixa para aplicar o filtro de segurança nos dois sentidos (em inglês, "Apply security filter in both directions") só deve ser marcada quando o desenho do modelo realmente exigir, porque a própria Microsoft avisa que isso pode piorar o desempenho das consultas. Outro detalhe de quem usa Windows em português: no editor DAX, os argumentos das funções se separam com vírgula, mesmo que a configuração regional use ponto e vírgula.

Passo 2: troque o filtro fixo pelo dinâmico, com tabela de mapeamento

O filtro fixo exige uma função por agência e, na prática, um grupo por agência, então abrir uma agência nova significa voltar ao Desktop, criar a função, republicar e pedir outro grupo à TI. O filtro dinâmico resolve isso com uma única função, porque o filtro consulta quem está logado e procura a agência dele numa tabela de dados, e a troca de gerente passa a ser uma linha alterada nessa tabela, sem republicar o modelo.

O filtro mora na dimensão Agência e consulta o mapa pelo login; a função Diretoria não tem filtro e por isso vê tudo.

Crie a tabela MapaAcesso com duas colunas, Login e CodAgencia, com uma linha por par usuário e agência, de modo que um gerente que responde por duas agências aparece em duas linhas. Mantenha essa tabela sem relacionamento com o restante do modelo, e carregue-a de uma fonte que a cooperativa já atualiza, como uma lista do SharePoint ou uma tabela do sistema de crédito, para que ela acompanhe a atualização agendada do modelo. Depois, substitua o filtro da função "Gerente de agência" por esta expressão na tabela de agências.

[CodAgencia] IN CALCULATETABLE(
    VALUES(MapaAcesso[CodAgencia]),
    MapaAcesso[Login] = USERPRINCIPALNAME()
)

A coluna Login precisa guardar exatamente o valor que USERPRINCIPALNAME() devolve, e não o endereço de e-mail copiado do cadastro, porque a Microsoft deixa claro que a função devolve o identificador de entrada do usuário, que costuma ser igual ao e-mail mas pode diferir, por exemplo quando o e-mail é um alias, o que está descrito na documentação de RLS. Prefira USERPRINCIPALNAME() a USERNAME(), já que no Desktop a segunda devolve o formato DOMÍNIO\usuário e no serviço devolve o UPN, e essa diferença de formato é uma fonte fácil de erro. Para ver o que a função devolve no seu ambiente, crie uma medida temporária e exiba-a num cartão, em qualquer página que depois será apagada.

MeuLogin = USERPRINCIPALNAME()

Crie agora a segunda função, "Diretoria", sem nenhum filtro em nenhuma tabela, que é o que faz quem está nela ver todas as agências. Ocultar a tabela de mapeamento na visão de relatório ajuda a organizar o modelo, mas não é segurança, porque quem tem permissão Build ainda consegue consultá-la, e por isso ela deve conter só login e código da agência.

Passo 3: teste com Exibir como antes de publicar

Na guia Modelagem, clique em Exibir como, marque a função "Gerente de agência", marque também a opção de outro usuário e digite o login de um gerente que esteja na tabela de mapeamento. O relatório deve mostrar apenas a carteira daquela agência, e os totais dos cartões precisam bater com o que o próprio gerente conhece, o que é a conferência mais valiosa porque quem valida entende o número.

Repita com a função "Diretoria", com um gerente que cobre duas agências e com um login que não está no mapa, que deve ver o relatório vazio. Esse último caso é o que protege a cooperativa, porque mostra que o esquecimento de uma linha na tabela resulta em tela em branco e não em carteira alheia. Lembre que alguns recursos não são validados por esse tipo de teste, como a visual de perguntas e respostas, os insights rápidos e o Copilot, segundo a documentação.

Passo 4: publique e inclua os grupos na página Segurança

Publique pelo Desktop num workspace e abra esse workspace no serviço do Power BI. Passe o mouse sobre o modelo semântico, abra o menu de mais opções e escolha Segurança, que leva à página de segurança por linha, onde aparecem as funções criadas no Desktop. Se o modelo não tiver funções definidas, a página não existe, e isso explica a opção sumida quando alguém publica o arquivo errado.

Selecione "Gerente de agência" e digite o nome de um grupo de segurança do Entra ID, por exemplo SG-PBI-Carteira-Gerentes, e faça o mesmo com SG-PBI-Carteira-Diretoria na função "Diretoria". Grupos de distribuição e grupos habilitados para e-mail também são aceitos, mas grupos do Microsoft 365 não são, e grupos criados dentro do Power BI também não, como afirma a documentação de gerenciar membros de funções. Usar grupo de segurança é o que mantém o acesso na mão da TI, porque entrada e saída de gerente viram alteração de grupo no Entra ID, que a TI já controla, enquanto a agência de cada um fica na tabela de mapeamento, que a área dona do cadastro mantém.

Passo 5: revise quem tem qual papel no workspace

No workspace, abra Gerenciar acesso e leia a lista com atenção, porque este é o furo principal. Como a Microsoft descreve na documentação de papéis em workspaces e na página de RLS, quem é Administrador, Membro ou Colaborador tem permissão de edição sobre o modelo, e por isso a segurança por linha não se aplica a essas pessoas, que enxergam todas as linhas independentemente do que você configurou no Passo 4.

Em muita cooperativa, o gerente entra como Membro "para facilitar" no dia da publicação, e a regra inteira deixa de valer sem nenhum aviso, porque o relatório abre normalmente e mostra números plausíveis, só que de todas as agências. A correção é dar aos grupos de gerentes e de diretoria o papel de Visualizador e deixar os papéis de edição para a equipe de BI, e um arranjo que ajuda é separar o workspace de desenvolvimento, onde a equipe edita, do workspace de consumo, onde só existem Visualizadores. Um Visualizador com permissão Build continua filtrado, inclusive quando usa Analisar no Excel, de modo que dar essa permissão a um gerente não abre a porta.

Como validar que deu certo

No serviço, volte à página Segurança, abra o menu da função e escolha Testar como função, que abre o relatório publicado com a função aplicada e permite alternar entre funções e combinações de funções. O teste do serviço complementa o do Desktop, mas não substitui a confirmação final com uma conta real: peça a um gerente, ou use uma conta de teste com o papel de Visualizador, para abrir o relatório e informar o que vê. A tabela abaixo reúne o que esperar em cada caso.

Erros comuns e o que fazer

O painel abre em branco para parte do time. A causa quase sempre é o login do mapa diferente do valor que USERPRINCIPALNAME() devolve, por exemplo porque o mapa foi montado com e-mails e o UPN de alguns usuários é outro, o que costuma acontecer com quem mudou de nome ou tem alias. Exiba a medida MeuLogin para uma pessoa afetada, compare com a linha dela no mapa e corrija a tabela em vez de mexer na regra.

O gerente vê todas as agências. Confira o papel dele no workspace antes de olhar o DAX, porque Administrador, Membro e Colaborador não são filtrados, e confira também se ele pertence, direta ou indiretamente, ao grupo da função "Diretoria". Quando uma pessoa está em mais de uma função, o acesso que ela recebe é a soma dos filtros das funções, e o resultado é sempre o mais amplo, o que costuma ser observado em testes com combinações de funções.

O gerente vê mais de uma agência. Se o mapa tem duas linhas para ele, o comportamento está correto, e se não tem, procure um segundo grupo que ele integre e que esteja ligado a outra função. A forma de evitar o problema é nomear os grupos com o nome da função e revisar a participação deles de tempos em tempos.

O Entra ID não deixa adicionar o grupo. Grupos do Microsoft 365 não são aceitos nas funções, então crie um grupo de segurança com os mesmos membros e use esse. Se o grupo de segurança tiver convidados externos (B2B), a Microsoft informa que a avaliação pode falhar em algumas configurações, e a alternativa documentada é adicionar o convidado direto na função, pelo e-mail, e testar com a conta real dele, porque o teste com a sua própria identidade não revela o problema.

A opção Segurança não aparece no menu do modelo. Ou o modelo foi publicado sem funções, ou é uma conexão ao vivo com o Analysis Services, ou a sua permissão no workspace é inferior a Colaborador. Verifique nessa ordem, porque a primeira causa é a mais frequente.

O relatório fica lento depois da segurança. Em geral é filtro nas tabelas de fatos em vez da dimensão, ou a caixa de filtro de segurança bidirecional marcada sem necessidade, e a documentação alerta para o efeito no desempenho em modelos com muitos relacionamentos. Volte o filtro para a dimensão, desmarque o sentido duplo e teste de novo, e lembre também que o uso de USERELATIONSHIP() em medidas pode causar erros inesperados quando há segurança por linha, de modo que vale redesenhar essas medidas.

O que levar para quem aprova

Depois de pronto, a TI mantém um único relatório e um único modelo para a diretoria e para todas as agências, e o acesso passa a ser concedido por grupos de segurança do Entra ID, que ela já administra, enquanto a atribuição de agência fica numa tabela de mapeamento mantida pela área dona do cadastro. A segurança por linha é um recurso do próprio modelo semântico, então o custo de licença é o de quem consome o relatório, conforme a capacidade do workspace, e o esforço de sustentação se resume a manter o mapa atualizado e a revisar, a cada mudança de equipe, os papéis do workspace. O risco fica sob controle porque a regra é testada antes de publicar, porque só a equipe de BI tem papel de edição, e porque o erro típico (esquecer uma linha no mapa) resulta em tela vazia e não em carteira alheia exposta.

Se ajudar na conversa com quem aprova, a Trinapse pode compartilhar um checklist de revisão de papéis do workspace e um modelo da tabela de mapeamento, já usados em projetos com cooperativas de crédito.