Segurança ao nível da linha (RLS) com o Power BI

A segurança ao nível das linhas (RLS) restringe o acesso a dados para utilizadores específicos. Os filtros restringem os dados ao nível da linha, e defines filtros dentro dos papéis. No serviço do Power BI, os usuários com acesso a um espaço de trabalho têm acesso a modelos semânticos nesse espaço de trabalho. A RLS apenas restringe o acesso a dados para usuários com permissões de visualizador . Não se aplica a administradores, membros ou colaboradores.

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

1. Define papéis e regras no Power BI Desktop usando expressões de filtro DAX.
2. Publicar o modelo semântico e reportar à serviço Power BI.
3. Adicionar membros a funções no serviço Power BI.
4. Valide usando a funcionalidade Testar como função para confirmar que a filtragem de dados funciona como esperado.

Pode configurar RLS para modelos semânticos importados no Power BI Desktop ou no serviço Power BI. Você também pode configurar RLS em modelos semânticos que estão usando DirectQuery, como o SQL Server. Para conexões em tempo real 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 ao vivo.

Definir funções e regras no Power BI Desktop

Você pode definir funções e regras no Power BI Desktop. Com este editor, pode-se alternar entre a interface suspensa padrão e uma interface DAX. Ao publicar no Power BI, você também publica as definições de função.

Para definir funções de segurança:

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

   Nota

   Não é possível definir funções no Power BI Desktop para conexões em tempo real do Analysis Services. Você precisa fazer isso dentro do modelo do Analysis Services.

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

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

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

   Nota

   Não é possível definir uma função com uma vírgula, por exemplo London,ParisRole.

5. Em Selecionar tabelas, selecione a tabela à qual pretende aplicar um filtro de segurança ao nível da 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.

   Nota

   Nem todos os filtros de segurança de nível de linha suportados 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 Mudar para o editor DAX para alternar para usar o editor DAX para definir sua função. As expressões DAX retornam um valor de true ou false. Por exemplo: [Entity ID] = “Value”. O editor DAX está completo com preenchimento automático para fórmulas (intellisense). Você pode 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.

   Nota

   Você pode usar username() dentro desta expressão. Lembre-se de que username() tem o formato de DOMAIN\username no Power BI Desktop. No serviço do Power BI e no Servidor de Relatório do Power BI, ele está no formato UPN (Nome Principal do Usuário) do usuário. Além disso, nesta caixa de expressão, use vírgulas para separar argumentos de função DAX, mesmo se você estiver usando uma localidade que normalmente usa 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 definida 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.

   Nota

   Nesta caixa de expressão, use vírgulas para separar argumentos de função DAX, mesmo se você estiver usando uma localidade que normalmente usa separadores de ponto-e-vírgula, como francês ou alemão.

9. Selecione Guardar.

Não é possível atribuir usuários a uma função no Power BI Desktop. Você os atribui 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 filtros DAX

Os exemplos seguintes mostram expressões comuns de filtro DAX que pode usar ao definir papéis 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 utilizador autenticado:

  [UserEmail] = USERPRINCIPALNAME()
  

• RLS dinâmico com NOME de UTILIZADOR — Restringe dados com base no domínio e nome de utilizador do utilizador:

  [UserDomain] = USERNAME()
  

• RLS Dinâmico com CUSTOMDATA — Restringe dados com base numa string personalizada passada pela aplicação de embedding:

  [AppRole] = CUSTOMDATA()
  

  Nota

  CUSTOMDATA() é usado principalmente em cenários embutidos onde a aplicação passa uma cadeia de identidade efetiva personalizada através da API Power BI REST.

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

Filtragem cruzada bidirecional

Por padrão, a filtragem de segurança em nível de linha usa filtros unidirecionais, quer as relações estejam definidas como direção única ou bidirecional.

Você pode habilitar manualmente a filtragem cruzada bidirecional com segurança em nível de linha selecionando a relação e marcando a caixa de seleção Aplicar filtro de segurança em ambas as direções . Selecione esta opção quando também tiver implementado a segurança dinâmica em nível de linha no nível do servidor, onde a segurança em nível de linha é baseada em nome de usuário ou ID de login. Se uma tabela participar em múltiplas relações bidirecionais, só pode selecionar esta opção para uma dessas relações.

Para obter mais informações, consulte Filtragem cruzada bidirecional usando DirectQuery no Power BI e o artigo técnico Protegendo o Modelo Semântico de BI Tabular.

Gerencie a segurança em seu modelo

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

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

   

2. Selecione Segurança.

   

A segurança leva-o para a página Segurança do Role-Level, onde adiciona membros a uma função que criou. Utilizadores com funções de Contribuidor ou superiores no espaço de trabalho veem a opção Segurança e podem atribuir uma função aos utilizadores. A posse semântica do modelo ou a permissão de construção também podem ser necessárias, dependendo do cenário.

Gerir a adesão à função

Adicionar membros

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

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

• Grupo de Distribuição
• Grupo com suporte a email
• Grupo de Segurança Microsoft Entra

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

Você pode remover membros selecionando o X ao lado do nome deles.

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

Pode validar que a função que definiu funciona corretamente no serviço Power BI testando a função.

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

Quando o relatório carregar, verifique o seguinte:

• O relatório mostra apenas linhas de dados que correspondem à expressão de filtro definida no papel.
• Os visuais, tabelas e gráficos refletem os dados filtrados, não o conjunto de dados completo.
• Se utilizar RLS dinâmico, os dados correspondem à 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 visualizando como. Aqui você vê detalhes importantes de permissões referentes ao indivíduo ou função que está sendo testado. Para obter mais informações sobre como as permissões interagem com a RLS, consulte Experiência do usuário da RLS.

Teste outros relatórios conectados ao modelo semântico selecionando Visualização no cabeçalho da página. Você só pode testar relatórios localizados no mesmo espaço de trabalho que seu modelo semântico.

Para voltar à visualização normal, selecione Voltar à Segurança Row-Level.

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

Você pode aproveitar as funções DAX username() ou userprincipalname() em seu conjunto de dados. Você pode usá-los em 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() retornará um usuário no formato DOMAIN\User e userprincipalname() retornará um usuário no formato de user@contoso.com.

No serviço do Power BI, username() e userprincipalname() retornarão o UPN (Nome Principal do Usuário) do usuário. Isso se parece com um endereço de e-mail.

Usando RLS com espaços de trabalho no Power BI

Se você publicar seu relatório do Power BI Desktop em um espaço de trabalho no serviço do Power BI, as funções RLS serão aplicadas aos membros atribuídos à função Visualizador no espaço de trabalho. Mesmo que os Visualizadores recebam permissões de compilação para o modelo semântico, a RLS ainda se aplica. Por exemplo, se os visualizadores com permissões de compilação usarem Analisar no Excel, sua exibição dos dados será restrita pela RLS. Os membros do espaço de trabalho atribuídos como Administrador, Membro ou Contribuidor têm permissão de edição para o modelo semântico e, portanto, o RLS não se aplica a eles. Se quiser que a RLS se aplique a pessoas em um espaço de trabalho, você só poderá atribuir a elas a função de Visualizador . Leia mais sobre funções em espaços de trabalho.

Considerações para utilizadores externos (convidados B2B)

Se partilhar Power BI conteúdo com utilizadores externos através de Microsoft Entra B2B, é importante perceber como o RLS interage com as identidades dos utilizadores convidados.

Resolução UPN para convidados B2B

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

Esta distinção é importante para o RLS dinâmico. Se a sua tabela de mapeamento de utilizador armazenar um formato de identificador diferente do USERPRINCIPALNAME() que devolve, a expressão do filtro não corresponde, e o utilizador convidado pode não ver dados ou dados incorretos.

Comportamento de USERNAME() para convidados B2B

A USERNAME() função DAX devolve o identificador de domínio\nome de utilizador do utilizador. Para utilizadores convidados B2B, esta função normalmente devolve o UPN do tenant principal do convidado (por exemplo, user@partner.com) em vez de um formato domínio\nome de utilizador. Como USERNAME() e USERPRINCIPALNAME() frequentemente 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, tanto para utilizadores internos quanto para externos.

Resolução de problemas: Convidado externo não vê dados

Se um utilizador convidado B2B vir um relatório vazio ou receber uma mensagem de "sem dados", siga estes passos:

1. Verifique o formato UPN devolvido - Crie uma medida de teste usando USERPRINCIPALNAME() e mostre-a num visual de cartão. Peça ao utilizador convidado ver o relatório para ver o valor real devolvido.
2. Verifique a tabela de mapeamento do utilizador - Confirme que a tabela contém uma linha com um valor que corresponde exatamente ao USERPRINCIPALNAME() que retorna para esse convidado.
3. Verifique a sensibilidade a maiúsculas - as comparações de strings DAX são insensíveis a maiúsculas por defeito, mas verifique se a sua fonte de dados não introduziu valores sensíveis a maiúsculas.
4. Revise as definições de acesso entre inquilinos - Se a sua organização usar políticas de acesso entre inquilinos, estas podem afetar qual o formato UPN apresentado a Power BI.
5. Teste com o utilizador convidado real - A funcionalidade Testar como papel usa a sua própria identidade. Valida sempre com a conta real de convidado externo. Para mais informações sobre partilha de conteúdo Power BI com utilizadores externos, veja Distribuir conteúdo Power BI a utilizadores convidados externos com Microsoft Entra B2B.

Considerações e limitações

Você pode ver as limitações atuais para segurança em nível de linha em modelos de nuvem aqui:

• Se você definiu anteriormente funções e regras no serviço do Power BI, deverá recriá-las no Power BI Desktop.
• Você pode definir RLS somente nos modelos semânticos criados com o Power BI Desktop. Se quiser habilitar a RLS para modelos semânticos criados com o Excel, você deve converter seus arquivos em arquivos do Power BI Desktop (PBIX) primeiro. Mais informações.
• As entidades de serviço não podem ser adicionadas a uma função RLS. Assim, a RLS não é aplicada para aplicações que utilizam um principal de serviço como a identidade efetiva final.
• Somente conexões Import e DirectQuery são suportadas. As conexões em tempo real com o Analysis Services são tratadas no modelo local.
• Com o RLS ativado, usar a função USERELATIONSHIP() nas consultas e medidas DAX pode causar erros inesperados. Para contornar este problema, redesenhe as suas expressões DAX para evitar USERELATIONSHIP() e use relações ao nível do modelo ou outros padrões DAX em vez disso.
• O recurso Testar como função/Exibir como função não funciona para modelos DirectQuery com logon único (SSO) habilitado.
• O recurso Testar como função/exibição como função mostra apenas relatórios do espaço de trabalho de modelos semânticos.
• O recurso Testar como função/Exibir como função não funciona para relatórios paginados.

Lembre-se de que, se um relatório do Power BI fizer referência a uma linha com RLS configurada, a mesma mensagem será exibida como para um campo excluído ou inexistente. Para esses usuários, parece que o relatório está quebrado.

FAQ

Pergunta: E se eu tiver criado anteriormente funções e regras para um conjunto de dados no serviço do Power BI? Eles ainda funcionam se eu não fizer nada?
Resposta: Não, os elementos visuais não serão renderizados corretamente. Tem de recriar as funções e regras no Power BI Desktop e, em seguida, publicar 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 para o Power BI Desktop. Se você estiver usando uma conexão ao vivo, não poderá configurar a RLS no serviço do Power BI. Você define RLS no modelo local do Analysis Services.

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

Pergunta: A RLS permite-me ocultar dados detalhados, mas dá acesso a dados resumidos em elementos 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 estas funções e a RLS?
Resposta: A resposta depende se você está importando dados ou usando o DirectQuery. Se estiver a importar dados para o conjunto de dados do Power BI, as funções de segurança na origem de dados não são utilizadas. Nesse caso, você deve definir RLS para impor regras de segurança para usuários que se conectam no 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 à fonte de dados subjacente, que aplica 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 os dados de ambas as funções.

Conteúdos relacionados

• Restringir o acesso a dados com segurança em nível de linha (RLS) para o Power BI Desktop
• Planejamento de implementação do Power BI: Relatar o planejamento de segurança do consumidor
• RLS para cenários incorporados para ISVs
• Distribuir conteúdo Power BI a utilizadores convidados externos com Microsoft Entra B2B

Perguntas? Tente perguntar à Comunidade do Power BI. Sugestões? Contribua com ideias para melhorar o Power BI