RLS (segurança em nível de linha) com o Power BI

A RLS (segurança em nível de linha) restringe o acesso a dados para usuários específicos. Os filtros restringem os dados no nível da linha e você define filtros dentro das funções. No serviço do Power BI, usuários com acesso a um workspace têm acesso a modelos semânticos nesse workspace. A RLS restringe o acesso a dados apenas para usuários com permissões de Visualizador. Ela não se aplica a Administradores, Membros nem Colaboradores.

Para implementar o RLS, siga este fluxo de trabalho de alto nível:

1. Define funções e regras no Power BI Desktop usando expressões de filtro DAX.
2. Publish o modelo semântico e o relatório para o serviço do Power BI.
3. Adicionar membros a funções no serviço Power BI.
4. Valide usando o recurso Testar como função para confirmar se a filtragem de dados funciona conforme o esperado.

Você pode configurar o RLS para modelos semânticos importados no Power BI Desktop ou no serviço do Power BI. Você também pode configurar RLS em modelos semânticos que estão usando DirectQuery, assim como o SQL Server. Para conexões dinâmicas do Analysis Services ou do Azure Analysis Services, você configura a segurança em nível de linha no modelo, não no Power BI. A opção de segurança não aparece para modelos semânticos de conexão dinâmica.

Observação

Este artigo aborda a RLS para modelos semânticos Power BI especificamente. Para obter segurança de dados em outros itens do Fabric, consulte Segurança no Microsoft Fabric.

Observação

Para modelos semânticos do Direct Lake em Microsoft Fabric, há suporte para RLS. No entanto, se uma consulta DAX voltar ao modo DirectQuery devido a recursos sem suporte, os filtros RLS ainda serão aplicados, mas as características de desempenho poderão ser alteradas. Monitore o comportamento de fallback de consulta no aplicativo de métricas de capacidade Fabric.

Definir funções e regras no Power BI Desktop

É possível definir funções e regras no Power BI Desktop. Com esse editor, você pode alternar entre usar a interface suspensa padrão e uma interface DAX. Quando publica no Power BI, você também publica as definições de função.

Para definir funções de segurança:

1. Importe os dados para o relatório do Power BI Desktop ou configure uma conexão do DirectQuery.

   Observação

   Você não pode definir funções no Power BI Desktop para conexões dinâmicas do Analysis Services. Você precisa fazer isso no modelo do Analysis Services.

2. Na guia Modelagem , selecione Gerenciar Funções.

3. Na janela Gerenciar funções, selecione Novo para criar uma função.

4. Em Funções, forneça um nome para a função e selecione Enter.

   Observação

   Você não pode definir uma função com uma vírgula, por exemplo London,ParisRole.

5. Em Selecionar tabelas, selecione a tabela à qual você deseja aplicar um filtro de segurança em nível de linha.

6. Em Filtrar dados, use o editor padrão para definir suas funções. As expressões criadas retornam um valor verdadeiro ou falso. Um filtro DAX avalia TRUE/FALSE para cada linha. Somente as linhas que retornam TRUE são visíveis Todo o resto é completamente removido.

   Observação

   Nem todos os filtros de segurança em nível de linha com suporte no Power BI podem ser definidos usando o editor padrão. As limitações incluem expressões que hoje só podem ser definidas usando DAX, incluindo regras dinâmicas, como username() ou userprincipalname(). Para definir funções usando esses filtros, alterne para usar o editor DAX.

7. Opcionalmente, selecione Alternar para o editor DAX para alternar usando o editor DAX para definir sua função. Expressões DAX retornam um valor de verdadeiro ou falso. Por exemplo: [Entity ID] = “Value”. O editor DAX é completo, com preenchimento automático para fórmulas (intellisense). É possível selecionar a marca de seleção acima da caixa de expressão para validar a expressão e o botão X acima da caixa de expressão para reverter as alterações.

   Observação

   Você pode usar o nome de usuário() nessa expressão. Lembre-se de que o nome de usuário() tem o formato DOMAIN\username no Power BI Desktop. Dentro do serviço do Power BI e do Servidor de Relatórios do Power BI, ele está no formato do nome UPN do usuário. Além disso, nessa caixa de expressão, use vírgulas para separar os argumentos da função DAX, mesmo se você estiver usando um local que normalmente utiliza separadores de ponto e vírgula, como francês ou alemão.

8. Você pode voltar para o editor padrão selecionando Alternar para o editor padrão. Todas as alterações feitas em qualquer interface do editor persistem ao alternar interfaces quando possível. Ao definir uma função usando o editor DAX que não pode ser definido no editor padrão, se você tentar alternar para o editor padrão, será solicitado um aviso de que a troca de editores pode resultar na perda de algumas informações. Para manter essas informações, selecione Cancelar e continue editando apenas essa função no editor DAX.

   Observação

   Nessa caixa de expressão, use vírgulas para separar os argumentos da função DAX, mesmo se você estiver usando um local que normalmente utiliza separadores de ponto e vírgula, como francês ou alemão.

9. Selecione Salvar.

Não é possível atribuir usuários a uma função no Power BI Desktop. Você pode atribuí-los no serviço do Power BI. Você pode habilitar a segurança dinâmica no Power BI Desktop usando as funções DAX username() ou userprincipalname() e tendo as relações adequadas configuradas.

Padrões comuns de filtro DAX

Os exemplos a seguir mostram expressões de filtro DAX comuns que você pode usar ao definir funções RLS:

• RLS estático – restringe os dados a um valor fixo:

  [Region] = "West"
  

• RLS dinâmico com UPN ΓÇö Restringe dados com base no endereço de email do usuário conectado:

  [UserEmail] = USERPRINCIPALNAME()
  

• RLS dinâmico com USERNAME ΓÇö Restringe os dados com base no domínio e no nome de usuário do usuário:

  [UserDomain] = USERNAME()
  

• RLS dinâmico com CUSTOMDATA ΓÇö Restringe os dados com base em uma cadeia de caracteres personalizada passada pelo aplicativo de incorporação:

  [AppRole] = CUSTOMDATA()
  

  Observação

  CUSTOMDATA() é usado principalmente em cenários embutidos em que o aplicativo passa uma string de identidade efetiva personalizada por meio da API REST do Power BI.

O RLS dinâmico é a abordagem mais comum porque permite que uma única definição de função filtre dados de forma diferente para cada usuário, com base em uma tabela de mapeamento de usuário em seu modelo de dados.

Exemplo: Filtrando dados de vendas por região

Suponha que você tenha uma Sales tabela com colunas Regione ProductAmount. Você deseja restringir os usuários atribuídos à função "Oeste" para que eles vejam apenas as linhas em que a região é "Oeste".

No campo de filtro DAX para a função "Oeste", insira a seguinte expressão:

[Region] = "West"

Antes de filtrar (todos os dados):

Região	Product	Valor
Oeste	Widget A	500
Leste	Widget B	300
Oeste	Widget C	450
Sul	Widget A	200
Leste	Widget C	375

Após a filtragem (exibição para usuários de função "Oeste):

Região	Product	Valor
Oeste	Widget A	500
Oeste	Widget C	450

A expressão DAX atua como um filtro de linha que avalia cada linha na tabela. Somente as linhas em que a Region coluna é igual a "Oeste" são visíveis para os usuários atribuídos a essa função.

Dica

Use o recurso View como função (descrito em Validando a função no serviço do Power BI) para validar se o filtro retorna as linhas esperadas antes de publicar o relatório.

Por padrão, a filtragem de segurança no nível da linha usa filtros unidirecionais, estejam as relações definidas como unidirecionais ou bidirecionais. Habilite manualmente a filtragem cruzada bidirecional com a segurança no nível da linha selecionando a relação e marcando a caixa de seleção Aplicar filtro de segurança em ambas as direções. Observe que se uma tabela fizer parte de vários relacionamentos bidirecionais, você só poderá selecionar essa opção para um desses relacionamentos. Selecione essa opção quando também tiver implementado a segurança dinâmica no nível da linha no nível do servidor, em que a segurança no nível da linha se baseia no nome de usuário ou na ID de logon.

Para obter mais informações, consulte Filtragem cruzada bidirecional usando o DirectQuery no Power BI e o artigo técnico Protegendo o modelo semântico tabular do BI.

Filtragem cruzada bidirecional

Por padrão, a filtragem de segurança no nível da linha usa filtros unidirecionais, estejam as relações definidas como unidirecionais ou bidirecionais.

Habilite manualmente a filtragem cruzada bidirecional com a segurança no nível da linha selecionando a relação e marcando a caixa de seleção Aplicar filtro de segurança em ambas as direções. Selecione essa opção quando também tiver implementado a segurança dinâmica no nível da linha no nível do servidor, em que a segurança no nível da linha se baseia no nome de usuário ou na ID de logon. Se uma tabela participar de várias relações bidirecionais, você só poderá selecionar essa opção para uma dessas relações.

Cuidado

Habilitar a filtragem de segurança bidirecional pode afetar negativamente o desempenho da consulta, especialmente em modelos com muitas relações ou grandes conjuntos de dados. Teste minuciosamente antes de implantar em produção.

Para obter mais informações, consulte Filtragem cruzada bidirecional usando o DirectQuery no Power BI e o artigo técnico Protegendo o modelo semântico tabular do BI.

Gerenciar a segurança no seu modelo

Para gerenciar a segurança no seu modelo semântico, abra o espaço de trabalho em que você salvou o modelo semântico no serviço do Fabric e execute as seguintes etapas:

1. No Fabric, selecione o menu Mais opções para um modelo semântico. Esse menu aparece quando você passa o mouse sobre um nome de modelo semântico.

   

2. Selecione Segurança.

   

Segurança leva você para a página Segurança em Nível de Função, onde você adiciona membros a uma função que você criou. Usuários com Colaborador ou funções superiores no workspace veem a opção Segurança e podem atribuir usuários a uma função. A propriedade do modelo semântico ou a permissão build também podem ser necessárias dependendo do cenário.

Observação

Você só pode gerenciar a segurança em modelos que têm funções de segurança em nível de linha já definidas no Power BI Desktop ou ao editar seu modelo de dados no serviço do Power BI. Se o modelo ainda não tiver funções definidas, você não poderá gerenciar a segurança no serviço do Power BI.

Gerenciar associação de função

Adicionar membros

No serviço do Power BI, adicione um membro à função digitando o endereço de email, o nome do usuário ou o grupo de segurança. Não é possível adicionar Grupos criados no Power BI. Você pode adicionar membros externos à sua organização. Para obter diretrizes sobre como o RLS funciona com usuários convidados B2B externos, consulte Considerações para usuários externos (convidados B2B).

Você pode usar os grupos a seguir para configurar a segurança em nível de linha.

• Grupo de distribuição
• Grupo habilitado para email
• Grupo de Segurança do Microsoft Entra — Se o grupo de segurança contiver usuários convidados B2B externos, consulte Considerações para usuários externos (convidados B2B) para conhecer as limitações conhecidas.

Importante

Microsoft 365 grupos não têm suporte e não podem ser adicionados a nenhuma função. Somente os tipos de grupo listados acima têm suporte para associação de funções de RLS.

Você pode ver quantos membros fazem parte da função pelo número entre parênteses ao lado do nome da função ou ao lado de Membros.

Remover membros

É possível remover membros selecionando o X ao lado do nome.

Validando a função no serviço do Power BI

Você pode validar que a função definida funciona corretamente no serviço do Power BI testando a função.

1. Selecione Mais opções (...) ao lado da função.
2. Selecionar Teste como função.

Observação

Os painéis não estão disponíveis para testes usando a opção Testar como função. Você será redirecionado para o relatório que foi publicado do Power BI Desktop com esse modelo semântico, se houver.

Quando o relatório for carregado, verifique o seguinte:

• O relatório exibe apenas linhas de dados que correspondem à expressão de filtro definida na função.
• Visuais, tabelas e gráficos refletem os dados filtrados, não o conjunto de dados completo.
• Se você usar RLS dinâmico, os dados corresponderão à identidade mostrada no cabeçalho Agora visualizando como.

No cabeçalho da página, a função que está sendo aplicada é mostrada. Teste outras funções, uma combinação de funções ou uma pessoa específica selecionando Agora exibindo como. Aqui você verá detalhes de permissões importantes referentes ao indivíduo ou à função que está sendo testada. Para obter mais informações sobre como as permissões interagem com o RLS, consulte Experiência do usuário do RLS.

Teste outros relatórios conectados ao modelo semântico selecionando Exibição no cabeçalho da página. Você só pode testar relatórios localizados no mesmo workspace onde está o seu modelo semântico.

Para retornar à exibição normal, selecione Voltar à Segurança de Nível de Linha.

Observação

O recurso Testar como função não funciona para modelos DirectQuery com SSO (logon único) habilitado. Além disso, nem todos os aspectos de um relatório podem ser validados no recurso de teste como função, incluindo visualizações de perguntas e respostas, visualizações de insights rápidos e Copilot.

Dica

Se Testar como função não mostrar os resultados esperados, tente o seguinte:

• Verifique se a sintaxe da expressão de filtro DAX está correta e referencia os nomes de coluna corretos.
• Verifique se você selecionou a função correta a ser testada.
• Para RLS dinâmico, confirme se a tabela de mapeamento de usuário contém valores correspondentes para USERPRINCIPALNAME() ou USERNAME().
• Para modelos DirectQuery com SSO habilitado, não há suporte para testar como função. Em vez disso, faça login como um usuário com a função de Visualizador para validar a filtragem de dados.

Usar a função DAX username() ou userprincipalname()

Você pode tirar proveito das funções DAX username() ou userprincipalname() dentro de seu conjunto de dados. Você pode usá-las dentro de expressões no Power BI Desktop. Quando você publicar seu modelo, ele será usado no serviço do Power BI.

No Power BI Desktop, username() retorna um usuário no formato DOMÍNIO\Usuário e userprincipalname() retorna um usuário no formato user@contoso.com.

No serviço do Power BI, username() e userprincipalname() retornam o nome UPN do usuário. Isso se parece com um endereço de email.

Usar o RLS com workspaces no Power BI

Se você publicar seu relatório do Power BI Desktop em um workspace no serviço do Power BI, as funções de RLS serão aplicadas aos membros a quem foi atribuída a função de Espectador no workspace. Mesmo que os Visualizadores recebam permissões de build para o modelo semântico, o RLS ainda se aplica. Por exemplo, se Visualizadores com permissões de Build usarem Analisar no Excel, a exibição dos dados será protegida pela RLS. Os membros do workspace atribuídos a Administrador, Membro ou Colaborador têm permissão de edição para o modelo semântico e, portanto, o RLS não se aplica a eles. Se desejar que a RLS se aplique a pessoas em um workspace, você pode apenas atribuir-lhes a função de Espectador. Saiba mais sobre funções nos workspaces.

Considerações para usuários externos (convidados B2B)

Se você compartilhar Power BI conteúdo com usuários externos por meio de Microsoft Entra B2B, esteja ciente das seguintes considerações sobre o RLS.

Grupos de segurança do Entra com membros externos

Grupos de segurança do Microsoft Entra que contêm usuários convidados externos B2B podem não funcionar como esperado quando usados para associação a funções de RLS. Em algumas configurações , especialmente quando o usuário externo tem uma conta de tipo convidado (em vez de uma conta do tipo membro) , a associação de grupo do convidado não é avaliada corretamente pelo serviço do Power BI ao impor filtros RLS.

Solução alternativa recomendada: Em vez de adicionar usuários externos a funções RLS por meio de grupos de segurança do Entra, adicione-os diretamente à função por endereço de email. O endereço de e-mail é associado à conta B2B do usuário. Isso garante que sua identidade seja corretamente associada quando os filtros de RLS forem aplicados. Para obter mais informações, consulte Gerenciar Associação de Função.

Para organizações com muitos usuários externos, considere usar RLS USERPRINCIPALNAME() dinâmico em vez de associação de função baseada em grupo. Essa abordagem avalia individualmente a identidade de cada usuário e evita totalmente o problema de resolução de associação de grupo.

Importante

Se você usa atualmente grupos de segurança do Microsoft Entra para associação a funções de RLS e esses grupos incluem usuários convidados B2B, verifique se os usuários convidados veem os dados filtrados corretos. Caso contrário, adicione os usuários externos diretamente à função de RLS usando o endereço de email.

Observação

O escopo exato dessa limitação pode variar dependendo da configuração do Microsoft Entra ID e do tipo de convite de convidado B2B usado. Sempre teste com contas de usuário convidado reais antes de depender do RLS baseado em grupo para acesso externo.

Para obter mais informações sobre como compartilhar conteúdo com usuários externos, consulte Distribute Power BI conteúdo para usuários convidados externos com Microsoft Entra B2B.

Se o problema persistir após a aplicação da solução alternativa, consulte Solução de problemas: o convidado externo não verá dados para etapas de diagnóstico adicionais.

Resolução UPN para convidados B2B

Quando um usuário convidado B2B externo acessa um relatório Power BI, a função DAX USERPRINCIPALNAME() normalmente retorna um identificador semelhante a um email (por exemplo, user@partner.com). Em algumas configurações, ele pode retornar um UPN convidado no #EXT# formato (por exemplo, user_partner.com#EXT#@yourtenant.onmicrosoft.com).

Essa distinção é importante para rls dinâmicos. Se a tabela de mapeamento de usuário armazenar um formato de identificador diferente do que USERPRINCIPALNAME() retorna, a expressão de filtro não corresponderá e o usuário convidado poderá não ver dados ou dados incorretos.

Comportamento de USERNAME() para convidados do setor empresarial

A USERNAME() função DAX retorna o identificador de domínio\nome de usuário do usuário. Para usuários convidados B2B, essa função normalmente retorna um identificador no estilo UPN, semelhante a USERPRINCIPALNAME(), dependendo da configuração (por exemplo, user@partner.com), em vez de um formato domínio\nome de usuário. Como USERNAME() e USERPRINCIPALNAME() geralmente retornam o mesmo valor para convidados B2B, a maioria das implementações usa USERPRINCIPALNAME() para consistência.

Dica

Se o RLS dinâmico existente usar USERNAME(), verifique qual valor ele retorna para usuários convidados em seu ambiente antes de compartilhar conteúdo externamente. Você pode verificar adicionando um visual de cartão que exiba USERNAME() em um relatório de teste. Abordagem recomendada: Armazene e use consistentemente o mesmo formato de identificador em sua tabela de mapeamento de usuário que o valor retornado por USERPRINCIPALNAME(). Na maioria dos casos, o uso de endereços de email simplifica o gerenciamento:

[UserEmail] = USERPRINCIPALNAME()

Onde a UserEmail coluna contém endereços de email, como user@partner.com para usuários internos e externos.

Observação

O valor retornado por USERPRINCIPALNAME() é o identificador de entrada (UPN) do usuário, não necessariamente seu endereço de email. Para a maioria dos usuários, eles são iguais, mas podem ser diferentes (por exemplo, quando o email de um usuário é um alias). Ao criar sua tabela de mapeamento de usuário, use o valor retornado por USERPRINCIPALNAME() em vez do atributo mail de Microsoft Entra ID.

Importante

Se você usar RLS dinâmico com USERPRINCIPALNAME(), sempre teste com usuários convidados externos reais. O recurso Testar como papel usa sua própria identidade e não expõe problemas de resolução de UPN do usuário externo.

Observação

O comportamento de resolução UPN para usuários convidados B2B pode variar dependendo da configuração do Microsoft Entra ID, como configurações de acesso entre inquilinos e tipo de usuário convidado. Sempre valide o comportamento em seu ambiente específico.

Solução de problemas: o convidado externo não vê dados

Se um usuário convidado B2B vir um relatório vazio ou receber uma mensagem "sem dados", siga estas etapas:

1. Verifique o formato UPN retornado – Crie uma medida de teste usando-a USERPRINCIPALNAME() e exiba-a em um visual de cartão. Fazer com que o usuário convidado exiba o relatório para ver o valor real retornado.
2. Verifique a tabela de mapeamento de usuário – Confirme se a tabela de mapeamento contém uma linha com um valor que corresponde exatamente ao que USERPRINCIPALNAME() retorna para esse convidado.
3. Verifique a sensibilidade a maiúsculas e minúsculas - as comparações de cadeias de caracteres DAX não diferenciam maiúsculas de minúsculas por padrão, mas confirme se a sua fonte de dados não introduziu valores sensíveis a maiúsculas e minúsculas.
4. Revisar configurações de acesso entre locatários - Se sua organização usar políticas de acesso entre locatários, elas poderão afetar qual formato UPN é apresentado ao Power BI.
5. Teste com o usuário convidado real – o recurso Testar como papel usa sua própria identidade. Sempre valide com a conta de convidado externa real.
6. Verificar a atribuição de função – se um usuário convidado vir mais dados do que o esperado, confirme se eles estão atribuídos a uma função RLS. Os usuários que não são atribuídos a nenhuma função RLS normalmente não veem dados (resultados vazios), porque o RLS é imposto, mas nenhuma função correspondente é aplicada. Um filtro DAX avalia TRUE/FALSE para cada linha. Somente as linhas que retornam TRUE são visíveis. Todo o resto é completamente removido.

Para obter mais informações sobre como compartilhar Power BI conteúdo com usuários externos, consulte Distribute Power BI conteúdo para usuários convidados externos com Microsoft Entra B2B.

Considerações e limitações

Veja as limitações atuais da segurança no nível da linha nos modelos de nuvem aqui:

• Se você definiu funções e regras anteriormente no serviço do Power BI, deverá criá-las novamente no Power BI Desktop.
• Você pode definir a RLS somente nos modelos semânticos criados com o Power BI Desktop. Se desejar habilitar a RLS para modelos semânticos criados com o Excel, deverá primeiro converter os arquivos em arquivos PBIX (Power BI Desktop). Saiba mais.
• Entidades de serviço não podem ser adicionadas a uma função RLS. Assim, o RLS não é aplicado a aplicativos que usam um principal de serviço como identidade efetiva final.
• Há suporte apenas para conexões de Importação e DirectQuery. A conexão dinâmica com o Analysis Services são gerenciadas no modelo local.
• Com o RLS habilitado, usar a função USERELATIONSHIP() em consultas e medidas DAX pode causar erros inesperados. Para contornar esse problema, reprojete suas expressões DAX para evitar USERELATIONSHIP() e use relações no nível do modelo ou outros padrões DAX.
• O recurso Testar como função/Exibir como função não funciona para modelos do DirectQuery com o SSO (logon único) habilitado.
• O recurso Testar como função/Exibir como função mostra apenas relatórios do workspace de modelos semânticos.
• O recurso Testar como função/Exibir como função não funciona para relatórios paginados.
• A identidade baseada em token funciona apenas para modelos DirectQuery em uma capacidade conectada a um Banco de Dados SQL do Azure configurado para permitir a autenticação do Microsoft Entra. Para obter mais informações, consulte Inserir um relatório com identidade baseada em token
• O parâmetro 'IdentityBlob' é um token de acesso OAuth 2.0 para SQL do Azure e só tem suporte para conjuntos de dados com uma conexão DirectQuery com SQL do Azure. O mecanismo em si é específico do Azure SQL: o blob is um token de acesso do Microsoft Entra com escopo em https://database.windows.net/.default. Não existe um mecanismo equivalente de passagem de token para outras fontes de dados na incorporação em que o aplicativo é o proprietário dos dados. Para obter mais informações, consulte a referência da API REST para GenerateToken.

Considerações e limitações para RLS dinâmico

Quando você usa RLS (segurança dinâmica em nível de linha) com funções DAX como USERPRINCIPALNAME(), USERNAME()ou CUSTOMDATA(), esteja ciente das considerações a seguir.

Cenários B2B entre locatários

Em cenários B2B, USERPRINCIPALNAME() retorna a identidade conforme determinada pelo serviço do Power BI, que pode variar dependendo da configuração do locatário. Ele pode aparecer como:

• O endereço de email do usuário externo (user@partner.com) ou
• Um valor resolvido pelo locatário, como user_partner.com#EXT#@tenant.onmicrosoft.com

O formato exato não é garantido e deve ser validado em seu ambiente.

Se a tabela de mapeamento de usuário armazenar identificadores em um formato diferente do que USERPRINCIPALNAME() retorna para usuários convidados, a expressão de filtro RLS não corresponderá e o convidado não verá dados ou dados incorretos. Sempre verifique o valor exato retornado por USERPRINCIPALNAME() para usuários externos em seu ambiente.

Dica

Crie uma medida de teste usando USERPRINCIPALNAME() e exiba-a em um visual de cartão. Faça com que usuários convidados externos exibam o relatório para confirmar se o valor retornado corresponde à tabela de mapeamento de usuário. Esse teste simples pode evitar horas depurando valores de identidade incompatíveis.

Testar como limitações de função com RLS dinâmico

O recurso Testar como função no serviço do Power BI utiliza sua própria identidade ao avaliar expressões dinâmicas de RLS. Isso significa que USERPRINCIPALNAME() retorna o UPN, não o do usuário que você está tentando simular. Você não pode usar o Teste como função para ver o que um usuário convidado ou entidade de serviço B2B específico veria.

O teste como função simula a associação de função, mas não replica totalmente o contexto de autenticação de outro usuário, especialmente para convidados B2B ou cenários inseridos.

Para validar o RLS dinâmico para usuários externos, entre como o usuário convidado real e exiba o relatório diretamente. Essa é a única maneira de confirmar que USERPRINCIPALNAME() retorna o valor esperado e que os filtros RLS correspondem corretamente para esse usuário.

Cenários de incorporação com entidades de serviço

Quando um relatório é acessado por meio de um aplicativo inserido que se autentica com uma entidade de serviço e USERPRINCIPALNAME()USERNAME() retorna a ID do aplicativo da entidade de serviço ou uma cadeia de caracteres vazia, não a identidade de um usuário final.

Essas funções não retornam a identidade do usuário final e, portanto, não podem ser usadas para filtragem por usuário individual em cenários de incorporação com entidade de serviço. Isso significa que filtros RLS dinâmicos com base nessas funções não filtram dados por usuário em cenários inseridos.

Para aplicar RLS por usuário em cenários incorporados, use o recurso identidade efetiva da API REST do Power BI. Passe o objeto EffectiveIdentity com o nome de usuário e as funções apropriados ao gerar um token de incorporação. Se suas regras de RLS usarem CUSTOMDATA(), passe a string de dados personalizada usando EffectiveIdentity.CustomData.

Para obter mais informações, consulte RLS para cenários inseridos para ISVs.

Importante

Ao incorporar com uma entidade de serviço, sempre teste com tokens de incorporação reais que incluam EffectiveIdentity para verificar se os filtros de RLS são aplicados corretamente. O recurso Testar como função no serviço do Power BI não simula fluxos de autenticação incorporados.

Tenha em mente que, se um relatório do Power BI fizer referência a uma linha com o RLS configurado, a mesma mensagem será exibida como para um campo excluído ou não existente. Para esses usuários, parece que o relatório está quebrado.

perguntas frequentes

Pergunta: e se eu já tiver criado funções e regras para um conjunto de dados no serviço do Power BI? Elas ainda funcionarão se eu não fizer nada?
Resposta: não, os visuais não serão renderizados corretamente. Você precisará recriar as funções e regras no Power BI Desktop e, em seguida, publicá-las no serviço do Power BI.

Pergunta: Posso criar essas funções para fontes de dados do Analysis Services?
Resposta: sim, se você importou os dados no Power BI Desktop. Se você estiver usando uma conexão dinâmica, não poderá configurar a RLS no serviço do Power BI. Defina a RLS no modelo do Analysis Services local.

Pergunta: Posso usar a RLS para limitar as colunas ou as medidas acessíveis por meus usuários?
Resposta: Não, se um usuário tiver acesso a uma linha específica de dados, ele poderá ver todas as colunas de dados dessa linha. Para restringir o acesso a colunas e metadados de coluna, considere usar a segurança no nível do objeto.

Pergunta: A RLS permite ocultar dados detalhados, mas conceder acesso aos dados resumidos nos visuais?
Resposta: não, você protege linhas individuais de dados, mas os usuários sempre podem ver os detalhes ou os dados resumidos.

Pergunta: minha fonte de dados já tem funções de segurança definidas (por exemplo, funções do SQL Server ou funções do SAP BW). Qual é a relação entre essas funções e o RLS?
Resposta: a resposta depende de você estar importando dados ou usando o DirectQuery. Se você estiver importando dados para o conjunto de dados do Power BI, as funções de segurança em sua fonte de dados não serão usadas. Nesse caso, você deve definir a RLS para impor regras de segurança para usuários que se conectam ao Power BI. Se você estiver usando o DirectQuery, as funções de segurança em sua fonte de dados serão usadas. Quando um usuário abre um relatório, o Power BI envia uma consulta para a fonte de dados subjacente, que aplica as regras de segurança aos dados com base nas credenciais do usuário.

Pergunta: um usuário pode pertencer a mais de uma função?
Resposta: um usuário pode pertencer a várias funções e as funções são aditivas. Por exemplo, se um usuário pertencer às funções "Vendas" e "Marketing", ele poderá ver dados dessas duas funções.

Conteúdo relacionado

• Restringir o acesso a dados com a RLS (Segurança em Nível de Linha) no Power BI Desktop
• Planejamento da implementação do Power BI: planejamento de segurança do consumidor de relatório
• RLS para cenários inseridos para ISVs
• Distribute Power BI conteúdo para usuários convidados externos com Microsoft Entra B2B

Perguntas? Tente perguntar à Comunidade do Power BI Sugestões? Contribuir com ideias para aprimorar o Power BI