Implementar segurança em nível de linha

Concluído(a)

A RLS (segurança em nível de linha) restringe quais linhas de dados os usuários individuais podem ver ao consultar um modelo semântico. Você define a RLS criando funções que contêm expressões de filtro DAX. Quando um usuário é atribuído a uma função, Power BI avalia a expressão de filtro para cada linha e retorna apenas as linhas em que a expressão é avaliada como TRUE.

Sem funções, qualquer usuário com acesso de consulta ao modelo semântico vê todos os dados. O RLS aplica-se a todos os caminhos de consumo: relatórios Power BI, relatórios paginados, chat Copilot e agentes de dados Fabric. Isso significa que sua configuração de segurança protege os dados consistentemente, independentemente de como os usuários os acessam.

Entender como o RLS funciona com esquemas de estrela

O RLS funciona melhor com designs de esquema de estrela em que as tabelas de dimensão se relacionam com tabelas de fatos por meio de relações de modelo. Você cria expressões de filtro em tabelas de dimensão e Power BI propaga esses filtros para tabelas de fatos por meio das relações. Essa abordagem é mais eficiente do que filtrar tabelas de fatos diretamente porque as tabelas de dimensão normalmente contêm muito menos linhas.

Por exemplo, considere um modelo com uma tabela de dimensões Region e uma tabela de fatos Sales. Quando você aplica um filtro RLS à tabela Region para "Centro-Oeste", Power BI segue estas etapas:

1. Filtra a tabela Região , resultando em uma linha visível (para o Centro-Oeste).
2. Usa a relação de modelo para propagar o filtro para tabelas de dimensão relacionadas, como Estado, resultando apenas nos estados que pertencem à região Centro-Oeste.
3. Propaga o filtro para a tabela de fatos Sales por meio de seus relacionamentos, resultando apenas nos registros de vendas dos estados do Centro-Oeste.

Essa propagação de filtro significa que você só precisa gravar um filtro em uma tabela de dimensão. As relações de modelo lidam com o restante, filtrando todas as tabelas relacionadas automaticamente.

Dica

Filtrar tabelas de dimensão, não tabelas de fatos. As relações de modelo propagam filtros de dimensão para tabelas de fatos com eficiência, o que proporciona um desempenho de consulta mais rápido.

Criar funções de segurança

Você cria funções na área de trabalho Power BI na guia Modeling selecionando funções Manage. Você também pode criar e gerenciar funções na experiência de modelagem web do Fabric. Cada função tem um nome exclusivo e uma ou mais expressões de filtro DAX aplicadas a tabelas específicas.

Para criar uma função no Power BI Desktop:

1. Na guia Modelagem , selecione Gerenciar funções.
2. Selecione Novo para criar uma função.
3. Nomeie a função (por exemplo, "Vendas Regionais").
4. Selecione a tabela que você deseja filtrar.
5. Insira uma expressão de filtro DAX. Você pode usar a interface suspensa padrão para filtros simples ou pode optar por alternar para o editor DAX para expressões que utilizam funções como USERPRINCIPALNAME().
6. Clique em Salvar.

Uma função sem regras fornece acesso a todas as linhas em todas as tabelas. Essa configuração é útil para funções de administrador que precisam de acesso irrestrito a dados. Você também pode criar uma função com a expressão FALSE() para bloquear o acesso a todas as linhas em uma tabela específica. Isso é útil quando os usuários devem ver dados agregados, mas não registros em nível de detalhes.

Usar segurança dinâmica com USERPRINCIPALNAME()

A segurança dinâmica é a abordagem recomendada para a maioria dos cenários. Em vez de criar funções separadas para cada usuário ou grupo, você cria uma única função com uma expressão DAX que avalia a identidade do usuário conectado.

A USERPRINCIPALNAME() função retorna o endereço de email do usuário autenticado em user@domain.com formato. Você usa essa função para corresponder o usuário atual com uma coluna em seu modelo de dados.

-- Filter the Salesperson table to the current user
[SalesPersonEmail] = USERPRINCIPALNAME()

Essa expressão filtra a tabela de dimensões Salesperson para a linha que corresponde ao usuário conectado. Como a tabela Vendedor está relacionada à tabela de fatos Vendas , somente os dados de vendas desse usuário estão visíveis.

Escalas de segurança dinâmicas porque adicionar ou remover usuários é uma alteração de dados em vez de uma alteração de modelo. Você não precisa criar novas funções ou republicar o modelo semântico quando os membros da equipe forem alterados.

Considere uma organização com 50 vendedores em cinco regiões. Com o RLS estático, você precisaria de cinco funções separadas, uma por região. Com o RLS dinâmico, você cria uma função e uma expressão de filtro. Os dados determinam quais linhas cada usuário vê.

Implementar o padrão de tabela de segurança

Para cenários de autorização mais complexos, crie uma tabela dedicada que mapeie os usuários para partições de dados, como regiões, departamentos ou centros de custo. Neste exemplo, a AppUser tabela se une a uma tabela de dimensão no modelo e o filtro RLS faz referência à AppUser tabela.

-- Filter through the AppUser table that maps users to regions
CONTAINS(
    AppUser,
    AppUser[UserName], USERPRINCIPALNAME(),
    AppUser[Region], [Region]
)

Esse padrão mapeia cada usuário para uma ou mais regiões na AppUser tabela. Quando um usuário entra, Power BI avalia a CONTAINS função em relação à AppUser tabela e retorna apenas as linhas correspondentes às regiões atribuídas.

O padrão de tabela appUser oferece várias vantagens:

• Gerenciamento centralizado. Todos os mapeamentos de usuário para dados estão em uma tabela.
• Atribuições de vários valores. Um único usuário pode mapear para várias regiões ou departamentos.
• Atualizações controladas por dados. A alteração do acesso requer a atualização dos dados da tabela appUser, não a definição do modelo.

Para implementar esse padrão, adicione a tabela AppUser ao seu modelo e crie uma relação entre a AppUser tabela e a tabela de dimensões relevante. Em seguida, crie uma função com a CONTAINS expressão de filtro. Ao atualizar os dados, todas as alterações na tabela AppUser entrarão em vigor imediatamente sem republicar o modelo.

Entender regras RLS estáticas

As regras estáticas usam expressões DAX que se referem a valores constantes em vez de identidade do usuário. Por exemplo, você pode criar uma regra que restrinja uma função somente à região Centro-Oeste:

-- Static filter: only Midwest data is visible
[Region] = "Midwest"

Regras estáticas são simples de criar e entender. Eles funcionam bem quando você tem um número pequeno e fixo de partições de dados que raramente mudam. No entanto, eles não são escaláveis. Cada nova região ou partição de dados requer uma nova função ou uma regra atualizada e você precisa republicar o modelo semântico para que as alterações entrem em vigor.

Note

As regras dinâmicas com USERPRINCIPALNAME() são a abordagem recomendada para a maioria dos modelos de produção. Use regras estáticas apenas para cenários pequenos e fixos em que é improvável que o número de partições cresça.

Comparar USERNAME() e USERPRINCIPALNAME()

Ambas as funções retornam a identidade do usuário conectado, mas diferem no formato:

Função	Power BI Desktop	serviço do Power BI
USERNAME()	DOMAIN\username	user@domain.com
USERPRINCIPALNAME()	user@domain.com	user@domain.com

USERNAME() retorna formatos diferentes dependendo do ambiente. USERPRINCIPALNAME() sempre gera o formato do nome principal do usuário. Use USERPRINCIPALNAME() para consistência ao testar no Desktop e implantar no serviço.

Note

RLS estáticos: Para cenários pequenos e fixos, você pode codificar filtros como [Region] = "West". As regras estáticas são simples, mas não escalonam. Cada nova região requer uma nova função ou atualização de regra. As regras dinâmicas com USERPRINCIPALNAME() são a abordagem recomendada para a maioria dos modelos de produção.

Considere o DirectQuery com logon único

Quando a fonte de dados do DirectQuery dá suporte ao SSO (logon único), o banco de dados de origem pode impor sua própria segurança em nível de linha. Power BI passa a identidade do usuário para a fonte de dados e o banco de dados avalia a segurança com base nessa identidade. Nesse caso, você não precisa definir funções RLS no modelo semântico.

Note

Quando você usa o SSO com o DirectQuery, a fonte de dados controla a imposição de segurança. Para obter detalhes, consulte Segurança no nível de linha com Power BI.

Otimizar o desempenho do RLS

Expressões de filtro DAX complexas podem afetar a velocidade da consulta. Siga estas práticas para manter as consultas rápidas:

• Filtrar tabelas de dimensão. As relações propagam filtros para tabelas de fatos com mais eficiência do que a filtragem direta da tabela de fatos.
• Evite LOOKUPVALUE. Em vez disso, use relações de modelo para propagar filtros.
• Teste com dados realistas. Um filtro que tem um bom desempenho em um pequeno conjunto de dados pode ficar mais lento com os dados em escala de produção.
• Meça o impacto da RLS. Use Performance Analyzer no Power BI Desktop para comparar as durações da consulta com e sem o RLS imposto.

Dica

Use Copilot para gerar expressões de filtro DAX para funções RLS. Por exemplo, peça a Copilot para criar um filtro de tabela de segurança usando USERPRINCIPALNAME() para seu modelo de dados específico.