Diretrizes de RLS (Segurança em Nível de Linha) no Power BI Desktop

Este artigo destina-se aos modeladores de dados que trabalham com o Power BI Desktop. Ele descreve boas práticas de design para impor a RLS em seus modelos de dados.

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

Observação

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

Além disso, ele não aborda a aplicação de RLS em conexões dinâmicas a 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 com SSO (logon único), 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, procure 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 porque um usuário de relatório pode ser mapeado para várias funções, seja diretamente usando sua conta de usuário ou indiretamente pela associação de grupo de segurança. Os mapeamentos de função múltipla podem gerar resultados inesperados.

Quando um usuário de relatório é atribuído a várias funções, os filtros de RLS se tornam aditivos. Isso significa que os usuários de relatório podem ver linhas de 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 SQL Server (e outros modelos de permissão), o princípio "quando negado, sempre negado" não se aplica.

Considere um modelo com duas funções: A primeira função, denominada Workers, restringe o acesso a todas as linhas da tabela Payroll por meio da seguinte expressão de regra:

FALSE()

Observação

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

Contudo, uma segunda função, denominada Managers, permite o acesso a todas as linhas da tabela Payroll por meio da seguinte expressão de regra:

TRUE()

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

Otimizar a RLS

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

• Entender o esquema em estrela e a importância para o Power BI
• Todos os artigos sobre diretrizes de relações encontrados na Documentação de diretrizes do Power BI

Em geral, costuma ser mais eficiente impor filtros de RLS em tabelas de tipo de dimensão, e não em tabelas de tipo de fato. E é preciso haver relações bem projetadas a fim de garantir que os filtros de RLS se propaguem para outras tabelas de modelo. Os filtros RLS só se propagam por meio de relacionamentos ativos. Portanto, evite usar a função DAX LOOKUPVALUE quando as relações de modelo puderem obter o mesmo resultado.

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

Medir impacto da RLS

É possível medir o impacto no desempenho dos filtros de RLS no Power BI Desktop usando o Performance Analyzer. Primeiro, determine as durações das consultas de visuais de 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 as durações das consultas.

Configurar mapeamentos de função

Depois de publicado no Power BI, você deve mapear membros para funções de modelo semânticas (anteriormente conhecidas como conjunto de dados) . Somente proprietários do modelo semântico ou administradores de workspace podem adicionar membros a funções. Para obter mais informações, confira RLS (Segurança em Nível de Linha) com o Power BI (Gerenciar a 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. Ele envolve o gerenciamento de associações de grupo de segurança no Microsoft Entra ID (anteriormente conhecido como Azure Active Directory). Possivelmente, ele delega a tarefa aos seus administradores de rede.

Validar funções

Teste cada função para garantir que ela filtre o modelo corretamente. É possível fazer isso 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 DAX USERNAME, teste os valores esperados e inesperados. Ao inserir conteúdo do Power BI – especificamente usando o cenário inserir para os seus clientes – a lógica do aplicativo pode passar qualquer valor como um nome de usuário de identidade eficaz. Sempre que possível, garanta que valores acidentais ou mal-intencionados resultem em filtros que não retornam linhas.

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

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 "Worker", retornam todas as linhas da tabela. Portanto, um valor acidental, como "Wrker", retorna de forma não intencional todas as linhas da tabela. Desse modo, é mais seguro escrever uma expressão que testa cada valor esperado. Na expressão de regra aprimorada a seguir, um valor inesperado fará com que a tabela não retorne nenhuma linha.

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

Criar RLS parcial

Às vezes, os cálculos precisam de valores que não são restritos por filtros de RLS. Por exemplo, um relatório pode precisar exibir uma proporção de receita obtida para a região de vendas do usuário de 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 de modelo de resumo é consultada para recuperar a receita de "todas as regiões" e não é restrita por nenhum filtro de RLS.

Vejamos como você pode implementar esse requisito de design. Primeiro, considere o seguinte design de modelo:

O modelo consiste em quatro tabelas:

• A tabela Salesperson armazena uma linha por vendedor. Ela inclui a coluna EmailAddress, que armazena o endereço de email para cada vendedor. Essa tabela fica oculta.
• A tabela Sales armazena uma linha por pedido. Ela inclui a medida Revenue % All Region, que é projetada para retornar uma proporção de receita obtida pela região do usuário de relatório em relação à receita obtida por todas as regiões.
• A tabela Date armazena uma linha por data e permite filtrar e agrupar ano e mês.
• SalesRevenueSummary é uma tabela calculada. Ela armazena a receita total para cada data de pedido. Essa tabela fica oculta.

A seguinte expressão define a tabela calculada SalesRevenueSummary:

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

Observação

Uma tabela de agregação pode atingir o mesmo requisito de design.

A seguinte regra de RLS é aplicada à tabela Salesperson:

[EmailAddress] = USERNAME()

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

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

A seguinte expressão define a medida Revenue % All Region:

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

Observação

Tome cuidado para evitar a divulgação de fatos confidenciais. Caso haja apenas duas regiões nesse exemplo, é possível que um usuário de relatório calcule a receita da outra região.

Quando evitar o uso de RLS

Às vezes, faz sentido evitar o uso de RLS. 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 específico de usuários do relatório, que tem as mesmas permissões de dados. Em seguida, crie um workspace por público e atribua permissões de acesso ao workspace 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 workspaces 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 workspace. Eles têm apenas valores de parâmetro de conjunto de dados diferentes. Os vendedores recebem acesso a apenas um dos workspaces (ou aplicativos publicados).

Há várias vantagens quando a RLS é evitada:

• Desempenho de consulta aprimorado: isso pode resultar em uma melhoria do desempenho devido a menos filtros.
• Modelos menores: embora isso resulte em mais modelos, eles têm um tamanho menor. Modelos menores podem melhorar a capacidade de resposta da atualização de dados e de consulta, especialmente se o recurso de hospedagem enfrentar pressão sobre os recursos. Além disso, é mais fácil manter tamanhos de modelo abaixo dos limites impostos pela sua capacidade. Por fim, é mais fácil balancear as cargas de trabalho entre diferentes capacidades, pois você pode criar workspaces em – ou movê-los para – diferentes capacidades.
• Recursos adicionais: recursos do Power BI que não funcionam com a RLS, como Publicar na Web, podem ser usados.

No entanto, há desvantagens quando a RLS é evitada:

• Vários workspaces: é necessário um workspace para cada público de usuários de relatório. Se os aplicativos forem publicados, isso também significará que há um aplicativo por público de usuários de relatório.
• Duplicação de conteúdo: é preciso criar relatórios e dashboards em cada workspace. Isso requer mais esforço e tempo de configuração e manutenção.
• Usuários com privilégios elevados: os usuários com privilégios elevados, 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 diferentes workspaces ou aplicativos).

Solucionar problemas de RLS

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

• Existem relações incorretas entre tabelas de modelo, em termos de mapeamentos de coluna e direções de filtro. Lembre-se de que os filtros RLS só se propagam por meio de relacionamentos ativos.
• A propriedade de relação Aplicar filtro de segurança em ambas as direções não está definida corretamente. Para saber mais, confira Diretrizes de relações bidirecionais.
• As tabelas não contêm dados.
• Valores incorretos foram carregados nas tabelas.
• O usuário está mapeado para várias funções.
• O modelo inclui tabelas de agregação, e as regras de RLS não filtram consistentemente as agregações e os detalhes. Para obter mais informações, confira Usar agregações no Power BI Desktop (RLS para agregações).

Quando um usuário específico não consegue ver dados, pode ser porque seu UPN não está armazenado ou foi inserido da forma incorreta. Isso pode ocorrer abruptamente porque sua conta de usuário foi alterada como resultado de uma alteração de nome.

Dica

Para fins de teste, adicione uma medida que retorne a função DAX USERNAME. Você pode nomeá-la 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.

Criadores e consumidores com apenas permissão de Leitura no conjunto de dados só poderão exibir os dados que têm permissão para ver (com base no mapeamento de função de RLS).

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

Conteúdo relacionado

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

• Segurança no nível da linha (RLS) com Power BI
• Restringir o acesso a dados com a RLS (Segurança em Nível de Linha) no Power BI Desktop
• Modelar relações no Power BI Desktop
• Planejamento da implementação do Power BI: planejamento de segurança do consumidor de relatório
• Perguntas? Experimente perguntar à Comunidade do Power BI
• Sugestões? Contribuir com ideias para aprimorar o Power BI