Restringir o acesso aos dados do modelo do Power BI
Como um modelador de dados, você configura o RLS criando uma ou mais funções. Uma função tem um nome exclusivo no modelo e geralmente inclui uma ou mais regras. As regras impõem filtros em tabelas de modelo usando expressões de filtro DAX (Expressões de Análise de Dados).
Observação
Por padrão, um modelo de dados não tem funções. Um modelo de dados sem funções significa que os usuários (que têm permissão para consultar o modelo de dados) têm acesso a todos os dados do modelo.
Dica
É possível definir uma função que não inclui regras. Nesse caso, a função fornece acesso a todas as linhas de todas as tabelas de modelo. Essa configuração de função seria adequada para um usuário administrador que tem permissão para exibir todos os dados.
Você pode criar, validar e gerenciar funções no Power BI Desktop. Para modelos do Azure Analysis Services ou do SQL Server Analysis Services, você pode criar, validar e gerenciar funções usando o SSDT (SQL Server Data Tools).
Você também pode criar e gerenciar funções usando o SSMS (SQL Server Management Studio) ou usando uma ferramenta de terceiros, como o Editor de Tabelas.
Para entender melhor como o RLS restringe o acesso aos dados, assista à imagem animada a seguir.
Aplicar princípios de projeto de esquema de estrela
Recomendamos que você aplique os princípios de design do esquema em estrela para produzir um modelo composto por tabelas de dimensão e fatos. É comum configurar o Power BI para impor regras que filtram tabelas de dimensão, permitindo que as relações de modelo propagam esses filtros com eficiência para tabelas de fatos.
A imagem a seguir é o diagrama de modelo do modelo de dados de análise de vendas da Adventure Works. Ele mostra um design de esquema em estrela composto por uma única tabela de fatos chamada Vendas. As outras tabelas são tabelas de dimensão que dão suporte à análise de medidas de vendas por data, território de vendas, cliente, revendedor, pedido, produto e vendedor. Observe as relações de modelo que conectam todas as tabelas. Essas relações propagam filtros (direta ou indiretamente) para a tabela Vendas.
Esse design de modelo dá suporte a exemplos apresentados nesta unidade.
Definindo regras
As expressões de regras são avaliadas dentro do contexto de linha. Contexto de linha significa que a expressão é avaliada para cada linha usando os valores das colunas dessa linha. Quando a expressão retorna TRUE, o usuário pode "ver" a linha.
Dica
Para saber mais sobre o contexto de linha, confira o módulo Adicionar tabelas e colunas calculadas a modelos do Power BI Desktop. Embora este módulo descreva a adição de cálculos de modelo, ele inclui uma unidade que apresenta e descreve o contexto de linha.
Você pode definir regras estáticas ou dinâmicas.
Regras estáticas
As regras estáticas usam expressões DAX que se referem a constantes.
Considere a regra a seguir aplicada à tabela Região que restringe o acesso a dados às vendas do Centro-Oeste.
'Region'[Region] = "Midwest"
As etapas a seguir explicam como o Power BI impõe a regra. TI:
Filtra a tabela Região , resultando em uma linha visível (para o Centro-Oeste).
Usa a relação de modelo para propagar o filtro de tabela Região para a tabela Estado , resultando em 14 linhas visíveis (a região Centro-Oeste compreende 14 estados).
Utiliza a relação do modelo para propagar o filtro da tabela Estado na tabela Vendas, resultando em milhares de linhas visíveis (os fatos de vendas para os estados que pertencem à região Centro-Oeste).
A regra estática mais simples que você pode criar restringe o acesso a todas as linhas de tabela. Considere a regra a seguir aplicada à tabela Detalhes de Vendas (não ilustrada no diagrama do modelo).
FALSE()
Essa regra garante que os usuários não possam acessar nenhum dado de tabela. Pode ser útil quando os vendedores têm permissão para ver os resultados de vendas agregados (da tabela Vendas ), mas não detalhes no nível do pedido.
Definir regras estáticas é simples e eficaz. Considere usá-las quando precisar criar apenas algumas delas, como pode ser o caso da Adventure Works, em que há apenas seis regiões dos EUA. No entanto, esteja ciente das desvantagens: a configuração de regras estáticas pode envolver esforços significativos para criar e configurar. Também exigiria que você atualizasse e republice o conjunto de dados quando novas regiões forem integradas.
Se houver muitas regras para configurar e você prever a adição de novas regras no futuro, considere a criação de regras dinâmicas.
Regras dinâmicas
As regras dinâmicas usam funções DAX específicas que retornam valores ambientais (em vez de constantes). Os valores ambientais são retornados de três funções DAX específicas:
USERNAME ou USERPRINCIPALNAME – retorna o usuário autenticado do Power BI como um valor de texto.
CUSTOMDATA – Retorna a propriedade CustomData passada na cadeia de conexão. Ferramentas de relatório que não são do Power BI que se conectam ao conjunto de dados usando uma cadeia de conexão podem definir essa propriedade, como o Microsoft Excel.
Observação
Lembre-se de que a função USERNAME retorna o usuário no formato DOMAIN\username quando usado no Power BI Desktop. No entanto, quando usado no serviço do Power BI, ele retorna o formato do User Principal Name (UPN), nome principal de usuário, como username@adventureworks.com. Como alternativa, você pode usar a função USERPRINCIPALNAME, que sempre retorna o usuário no formato de nome principal do usuário.
Considere um design de modelo revisado que agora inclui a tabela AppUser (oculta). Cada linha da tabela AppUser descreve um nome de usuário e uma região. Uma relação de modelo com a tabela Região propaga filtros da tabela AppUser .
A regra a seguir aplicada à tabela AppUser restringe o acesso de dados às regiões do usuário autenticado.
'AppUser'[UserName] = USERPRINCIPALNAME()
Definir regras dinâmicas é simples e eficaz quando uma tabela de modelo armazena valores de nome de usuário. Eles permitem que você imponha um design RLS controlado por dados. Por exemplo, quando os vendedores são adicionados ou removidos da tabela AppUser (ou são atribuídos a regiões diferentes), essa abordagem de design funciona apenas.
Validar funções
Ao criar funções, é importante testá-las para garantir que elas apliquem os filtros corretos. Para modelos de dados criados no Power BI Desktop, há a função Exibir como, que permite ver o relatório quando diferentes funções são impostas e diferentes valores de nome de usuário são passados.
Configurar mapeamentos de função
Os mapeamentos de função devem ser configurados antes dos usuários acessarem o conteúdo do Power BI. O mapeamento de função envolve atribuir objetos de segurança do Microsoft Entra a funções. Objetos de segurança podem ser contas de usuário ou grupos de segurança.
Dica
Quando possível, é uma boa prática mapear funções para grupos de segurança. Dessa forma, haverá menos mapeamentos e você poderá delegar o gerenciamento de associação de grupo aos administradores de rede.
Para modelos desenvolvidos pelo Power BI Desktop, o mapeamento de função normalmente é feito no serviço do Power BI. Para modelos do Azure Analysis Services ou do SQL Server Analysis Services, o mapeamento de função normalmente é feito no SSMS.
Para obter mais informações sobre como configurar o RLS, consulte:
Usar o SSO (logon único) para fontes do DirectQuery
Quando seu modelo de dados tem tabelas DirectQuery e sua fonte de dados dá suporte ao SSO, a fonte de dados pode impor permissões de dados. Dessa forma, o banco de dados impõe RLS e os conjuntos de dados e relatórios do Power BI respeitam a segurança da fonte de dados.
Considere que o Adventure Works tem um Banco de Dados SQL do Azure para suas operações de vendas que reside no mesmo locatário que o Power BI. O banco de dados aplica a segurança em nível de linha (RLS) para controlar o acesso às linhas em várias tabelas de banco de dados. Você pode criar um modelo do DirectQuery que se conecta a esse banco de dados sem funções e publicá-lo no serviço do Power BI. Ao definir as credenciais da fonte de dados no serviço do Power BI, você habilita o SSO. Quando os consumidores de relatório abrem relatórios do Power BI, o Power BI passa sua identidade para a fonte de dados. Em seguida, a fonte de dados aplica RLS com base na identidade do usuário do relatório.
Para obter informações sobre o RLS do Banco de Dados SQL do Azure, consulte a segurança em nível de linha.
Observação
Não há suporte para tabelas calculadas e colunas calculadas que fazem referência a uma tabela DirectQuery de uma fonte de dados com autenticação SSO no serviço do Power BI.
Para obter mais informações sobre fontes de dados que dão suporte ao SSO, consulte SSO (logon único) para fontes do DirectQuery.