Diretrizes de segurança em nível de linha (RLS) no Power BI Desktop

Este artigo destina-se a você como um modelador de dados que trabalha com o Power BI Desktop. Ele descreve boas práticas de design para impor a segurança em níveis de linha (RLS) em seus modelos de dados.

É importante entender as linhas da tabela de filtros RLS. Eles não podem ser configurados para restringir o acesso a objetos de modelo, incluindo tabelas, colunas ou medidas.

Nota

Este artigo não descreve a RLS ou como configurá-la. Para obter mais informações, consulte Restringir o acesso a dados com segurança em nível de linha (RLS) para o Power BI Desktop.

Além disso, ele não cobre a imposição de RLS em conexões em tempo real para modelos hospedados externamente com o Azure Analysis Services ou o SQL Server Analysis Services. Nesses casos, a RLS é imposta pelo Analysis Services. Quando o Power BI se conecta usando o logon único (SSO), o Analysis Services impõe a RLS (a menos que a conta tenha privilégios de administrador).

Criar funções

É possível criar várias funções. Quando você estiver considerando as necessidades de permissão para um único usuário de relatório, esforce-se para criar uma única função que conceda todas essas permissões, em vez de um design em que um usuário de relatório será membro de várias funções. Isso ocorre porque um usuário de relatório pode mapear para várias funções, diretamente usando sua conta de usuário ou indiretamente pela associação ao grupo de segurança. Vários mapeamentos de funções podem resultar em resultados inesperados.

Quando um usuário de relatório é atribuído a várias funções, os filtros RLS tornam-se aditivos. Isso significa que os usuários do relatório podem ver as linhas da tabela que representam a união desses filtros. Além disso, em alguns cenários, não é possível garantir que um usuário de relatório não veja linhas em uma tabela. Portanto, ao contrário das permissões aplicadas a objetos de banco de dados do SQL Server (e outros modelos de permissão), o princípio "uma vez negado sempre negado" não se aplica.

Considere um modelo com duas funções: A primeira função, chamada Trabalhadores, restringe o acesso a todas as linhas da tabela de folha de pagamento usando a seguinte expressão de regra:

FALSE()

Nota

Uma regra não retornará nenhuma linha de tabela quando sua expressão for avaliada como FALSE.

No entanto, uma segunda função, chamada Gerentes, permite o acesso a todas as linhas da tabela de folha de pagamento usando a seguinte expressão de regra:

TRUE()

Cuidado: se um usuário de relatório mapear para ambas as funções, ele verá todas as linhas da tabela de folha de pagamento .

Otimizar RLS

A RLS funciona aplicando filtros automaticamente a cada consulta DAX, e esses filtros podem ter um impacto negativo no desempenho da consulta. Assim, RLS eficiente se resume a um bom design de modelo. É importante seguir as diretrizes de design do modelo, conforme discutido nos seguintes artigos:

• Compreender o esquema em estrela e a importância para o Power BI
• Todos os artigos de orientação de relacionamento encontrados na documentação de orientação do Power BI

Em geral, muitas vezes é mais eficiente aplicar filtros RLS em tabelas de tipo de dimensão, e não em tabelas de tipo de fato. E confie em relacionamentos bem projetados para garantir que os filtros RLS se propaguem para outras tabelas de modelos. Os filtros RLS propagam-se apenas através de relações ativas. Portanto, evite usar a função LOOKUPVALUE DAX quando as relações de modelo podem alcançar o mesmo resultado.

Sempre que os filtros RLS forem impostos em tabelas DirectQuery e houver relações com outras tabelas DirectQuery, certifique-se de otimizar o banco de dados de origem. Pode envolver a criação de índices apropriados ou o uso de colunas computadas persistentes. Para obter mais informações, consulte Diretrizes de modelo do DirectQuery no Power BI Desktop.

Meça o impacto da SPI

É possível medir o impacto no desempenho dos filtros RLS no Power BI Desktop usando o Performance Analyzer. Primeiro, determine as durações da consulta visual do relatório quando a RLS não for imposta. Em seguida, use o comando Exibir como na guia da faixa de opções Modelagem para impor a RLS e determinar e comparar durações de consulta.

Configurar mapeamentos de função

Depois de publicado no Power BI, você deve mapear membros para funções de modelo semântico (anteriormente conhecido como conjunto de dados). Somente proprietários de modelos semânticos ou administradores de espaço de trabalho podem adicionar membros a funções. Para obter mais informações, consulte Segurança em nível de linha (RLS) com o Power BI (Gerenciar segurança em seu modelo).

Os membros podem ser contas de usuário, grupos de segurança, grupos de distribuição ou grupos habilitados para email. Sempre que possível, recomendamos mapear grupos de segurança para funções de modelo semântico. Envolve o gerenciamento de associações de grupos de segurança no Microsoft Entra ID (anteriormente conhecido como Azure Ative Directory). Possivelmente, ele delega a tarefa aos administradores de rede.

Validar funções

Teste cada função para garantir que filtra o modelo corretamente. Isso é feito facilmente usando o comando Exibir como na guia da faixa de opções Modelagem .

Quando o modelo tiver regras dinâmicas usando a função USERNAME DAX, certifique-se de testar os valores esperados e inesperados . Ao incorporar conteúdo do Power BI, especificamente usando o cenário de incorporação para seus clientes, a lógica do aplicativo pode passar qualquer valor como um nome de usuário de identidade eficaz. Sempre que possível, certifique-se de que valores acidentais ou mal-intencionados resultem em filtros que não retornem linhas.

Considere um exemplo usando o Power BI incorporado, em que o aplicativo passa a função de trabalho do usuário como o nome de usuário efetivo: é "Gerente" ou "Trabalhador". Os gerentes podem ver todas as linhas, mas os trabalhadores só podem ver linhas em que o valor da coluna Tipo é "Interno".

A seguinte expressão de regra é definida:

IF(
    USERNAME() = "Worker",
    [Type] = "Internal",
    TRUE()
)

O problema com essa expressão de regra é que todos os valores, exceto "Trabalhador", retornam todas as linhas da tabela. Assim, um valor acidental, como "Wrker", retorna involuntariamente todas as linhas da tabela. Portanto, é mais seguro escrever uma expressão que teste para cada valor esperado. Na expressão de regra aprimorada a seguir, um valor inesperado resulta na tabela sem retornando linhas.

IF(
    USERNAME() = "Worker",
    [Type] = "Internal",
    IF(
        USERNAME() = "Manager",
        TRUE(),
        FALSE()
    )
)

Projetar RLS parcial

Às vezes, os cálculos precisam de valores que não sejam restringidos por filtros RLS. Por exemplo, um relatório pode precisar exibir uma proporção da receita obtida para a região de vendas do usuário do relatório sobre toda a receita obtida.

Embora não seja possível que uma expressão DAX substitua a RLS — na verdade, ela não pode nem mesmo determinar que a RLS é imposta — você pode usar uma tabela de modelo de resumo. A tabela do modelo de resumo é consultada para recuperar receita para "todas as regiões" e não é restringida por nenhum filtro RLS.

Vamos ver como você poderia implementar esse requisito de design. Primeiro, considere o seguinte design de modelo:

O modelo é composto por quatro tabelas:

• A tabela Vendedor armazena uma linha por vendedor. Inclui a coluna EmailAddress , que armazena o endereço de e-mail de cada vendedor. Esta tabela está oculta.
• A tabela Vendas armazena uma linha por pedido. Inclui a medida % de receita de todas as regiões , que foi projetada para retornar uma proporção entre a receita obtida pela região do usuário do relatório e a receita obtida por todas as regiões.
• A tabela Data armazena uma linha por data e permite filtrar e agrupar ano e mês.
• O SalesRevenueSummary é uma tabela calculada. Ele armazena a receita total para cada data de pedido. Esta tabela está oculta.

A expressão a seguir define a tabela calculada SalesRevenueSummary :

SalesRevenueSummary =
SUMMARIZECOLUMNS(
    Sales[OrderDate],
    "RevenueAllRegion", SUM(Sales[Revenue])
)

Nota

Uma tabela de agregação poderia atingir o mesmo requisito de conceção.

A seguinte regra RLS é aplicada à tabela Vendedor :

[EmailAddress] = USERNAME()

Cada uma das três relações de modelo é descrita na tabela a seguir:

Relação	Description
	Há uma relação muitos-para-muitos entre o Vendedor e as tabelas de Vendas. A regra RLS filtra a coluna EmailAddress da tabela Salesperson oculta usando a função USERNAME DAX. O valor da coluna Região (para o usuário do relatório) se propaga para a tabela Sales .
	Há uma relação um-para-muitos entre as tabelas Data e Vendas .
	Há uma relação um-para-muitos entre as tabelas Date e SalesRevenueSummary .

A expressão a seguir define a medida % de receita de todas as regiões :

Revenue % All Region =
DIVIDE(
    SUM(Sales[Revenue]),
    SUM(SalesRevenueSummary[RevenueAllRegion])
)

Nota

Tome cuidado para evitar a divulgação de fatos sensíveis. Se houver apenas duas regiões neste exemplo, será possível para um usuário de relatório calcular a receita para a outra região.

Quando evitar o uso de SPI

Às vezes, faz sentido evitar o uso de SPI. Se você tiver apenas algumas regras RLS simplistas que aplicam filtros estáticos, considere publicar vários modelos semânticos. Nenhum dos modelos semânticos define funções porque cada modelo semântico contém dados para um público de usuário de relatório específico, que tem as mesmas permissões de dados. Em seguida, crie um espaço de trabalho por público e atribua permissões de acesso ao espaço de trabalho ou aplicativo.

Por exemplo, uma empresa que tem apenas duas regiões de vendas decide publicar um modelo semântico para cada região de vendas em espaços de trabalho diferentes. Os modelos semânticos não impõem RLS. No entanto, eles usam parâmetros de consulta para filtrar os dados de origem. Dessa forma, o mesmo modelo é publicado em cada espaço de trabalho — eles apenas têm valores de parâmetros de modelo semânticos diferentes. Os vendedores recebem acesso a apenas um dos espaços de trabalho (ou aplicativos publicados).

Existem várias vantagens associadas a evitar a SPI:

• Melhor desempenho da consulta: pode resultar em melhor desempenho devido a menos filtros.
• Modelos menores: embora resulte em mais modelos, eles são menores em tamanho. Modelos menores podem melhorar a capacidade de resposta de consulta e atualização de dados, especialmente se a capacidade de hospedagem sofrer pressão sobre os recursos. Além disso, é mais fácil manter os tamanhos dos modelos abaixo dos limites de tamanho impostos pela sua capacidade. Por fim, é mais fácil equilibrar cargas de trabalho entre diferentes capacidades, porque você pode criar espaços de trabalho em diferentes capacidades ou movê-las para.
• Recursos adicionais: os recursos do Power BI que não funcionam com RLS, como Publicar na Web, podem ser usados.

No entanto, existem desvantagens associadas a evitar a SPI:

• Vários espaços de trabalho: um espaço de trabalho é necessário para cada público de usuário de relatório. Se os aplicativos forem publicados, isso também significa que há um aplicativo por público de usuário de relatório.
• Duplicação de conteúdo: relatórios e painéis devem ser criados em cada espaço de trabalho. Requer mais esforço e tempo para configurar e manter.
• Usuários de alto privilégio: os usuários de alto privilégio, que pertencem a vários públicos de usuários de relatório, não podem ver uma exibição consolidada dos dados. Eles precisarão abrir vários relatórios (de espaços de trabalho ou aplicativos diferentes).

Resolução de problemas de RLS

Se a RLS produzir resultados inesperados, verifique os seguintes problemas:

• Existem relações incorretas entre tabelas de modelos, em termos de mapeamentos de colunas e direções de filtro. Tenha em mente que os filtros RLS só se propagam através de relações ativas.
• A propriedade de relacionamento Aplicar filtro de segurança em ambas as direções não está definida corretamente. Para obter mais informações, consulte Diretrizes de relacionamento bidirecional.
• As tabelas não contêm dados.
• Valores incorretos são carregados em tabelas.
• O usuário é mapeado para várias funções.
• O modelo inclui tabelas de agregação e as regras RLS não filtram consistentemente agregações e detalhes. Para obter mais informações, consulte Usar agregações no Power BI Desktop (RLS para agregações).

Quando um usuário específico não consegue ver nenhum dado, pode ser porque seu UPN não está armazenado ou foi inserido incorretamente. Isso pode acontecer abruptamente porque sua conta de usuário mudou como resultado de uma mudança de nome.

Gorjeta

Para fins de teste, adicione uma medida que retorna a função USERNAME DAX. Você pode nomeá-lo algo como "Quem sou eu". Em seguida, adicione a medida a um visual de cartão em um relatório e publique-a no Power BI.

Os criadores e consumidores com apenas permissão de Ler no modelo semântico só poderão visualizar os dados que têm permissão para ver (com base no mapeamento de funções RLS).

Quando um usuário exibe um relatório em um espaço de trabalho ou em um aplicativo, a RLS pode ou não ser imposta, dependendo de suas permissões de modelo semântico. Por esse motivo, é fundamental que os consumidores e criadores de conteúdo só possuam permissão de Ler no modelo semântico subjacente quando a RLS deve ser imposta. Para obter detalhes sobre as regras de permissões que determinam se a RLS é imposta, consulte o artigo Relatar planejamento de segurança do consumidor.

Conteúdos relacionados

Para obter mais informações relacionadas a este artigo, confira os seguintes recursos:

• Segurança ao nível da linha (RLS) com o Power BI
• Restringir o acesso a dados com segurança em nível de linha (RLS) para o Power BI Desktop
• Relações de modelo no Power BI Desktop
• Planejamento de implementação do Power BI: Relatar o planejamento de segurança do consumidor
• Perguntas? Tente perguntar à Comunidade do Power BI
• Sugestões? Contribua com ideias para melhorar o Power BI