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.

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.

   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 os 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 do aplicativo de inserçã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.

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.

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.

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

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.

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.

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, é importante entender como o RLS interage com identidades de usuário convidado.

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 o UPN do locatário doméstico do convidado (por exemplo, user@partner.com) em vez do formato de 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.

[UserEmail] = USERPRINCIPALNAME()

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

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. 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.

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