Restringir o acesso a dados de modelo do Power BI
Como modelador de dados, você configura a 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 do modelo usando expressões de filtro DAX (Data Analysis Expressions).
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 inclua 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 com 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 Tabular Editor.
Para entender melhor como a RLS restringe o acesso aos dados, assista à imagem animada a seguir.
Aplicar princípios de design de esquema em estrela
Recomendamos que você aplique princípios de design de esquema em estrela para produzir um modelo composto por tabelas de dimensões e fatos. É comum configurar o Power BI para impor regras que filtram tabelas de dimensões, permitindo que as relações de modelo propaguem esses filtros com eficiência para tabelas de fatos.
A imagem a seguir é o diagrama 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 Sales. As outras tabelas são tabelas de dimensões 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 do modelo conectando todas as tabelas. Essas relações propagam filtros (direta ou indiretamente) para a tabela Sales.
Esse design de modelo dá suporte aos exemplos apresentados nesta unidade.
Definindo regras
As expressões de regras são avaliadas dentro do contexto de linha. O contexto de linha significa que a expressão é avaliada para cada linha usando os valores de coluna 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 que sejam 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 aos dados de vendas do Meio-oeste.
'Region'[Region] = "Midwest"
As etapas a seguir explicam como o Power BI impõe a regra. It:
Filtra a tabela Região, resultando em uma linha visível (para Meio-oeste).
Usa a relação do modelo para propagar o filtro da tabela Região para a tabela Estado, resultando em 14 linhas visíveis (a região Meio-oeste é composta por 14 estados).
Usa a relação do modelo para propagar o filtro da tabela Estado para a tabela Vendas, resultando em milhares de linhas visíveis (os fatos das vendas para os estados que pertencem à região Meio-oeste).
A regra estática mais simples que você pode criar restringe o acesso a todas as linhas da tabela. Considere a regra a seguir aplicada à tabela Sales Details (não ilustrada no diagrama do modelo).
FALSE()
Essa regra garante que os usuários não possam acessar nenhum dado da tabela. Ela pode ser útil quando os vendedores têm permissão para ver resultados de vendas agregados (da tabela Sales), mas não detalhes no nível de pedido.
A definição de 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, observe as desvantagens: a configuração de regras estáticas pode envolver esforços significativos de criação e configuração. Também exigiria que você atualizasse e republicasse o conjunto de dados quando novas regiões fossem integradas.
Se houver muitas regras para configurar e você prevê que novas regras serão adicionadas no futuro, considere usar 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 e 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 DOMÍNIO\nome de usuário quando usada no Power BI Desktop. No entanto, quando usada no serviço do Power BI, ela retorna o formato do nome UPN do 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 UPN.
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 do modelo com a tabela Region propaga filtros da tabela AppUser.
A regra a seguir aplicada à tabela AppUser restringe o acesso aos dados das regiões do usuário autenticado.
'AppUser'[UserName] = USERPRINCIPALNAME()
A definição de regras dinâmicas é simples e eficaz quando uma tabela de modelo armazena valores de nome de usuário. Elas permitem que você imponha um design de RLS controlado por dados. Por exemplo, quando vendedores são adicionados ou removidos da tabela AppUser (ou são atribuídos a regiões diferentes), essa abordagem de design funciona.
Validar funções
Quando você cria 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 que você veja o relatório quando diferentes funções são impostas e valores de nome de usuário diferentes são passados.
Configurar mapeamentos de função
Os mapeamentos de função devem ser configurados antes que os usuários acessem o conteúdo do Power BI. O mapeamento de função envolve atribuir objetos de segurança do Microsoft Entra a funções. Os objetos de segurança podem ser contas de usuário ou grupos de segurança.
Dica
Quando possível, é uma boa prática mapear as funções para os grupos de segurança. Dessa forma, haverá menos mapeamentos e você poderá delegar o gerenciamento de associação de grupo aos administradores da rede.
Para modelos desenvolvidos do 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 a configuração da RLS, confira:
Usar o SSO (logon único) para fontes do DirectQuery
Quando o modelo de dados tem tabelas do DirectQuery e a fonte de dados deles dá suporte ao SSO, a fonte de dados pode impor permissões de dados. Assim, o banco de dados impõe a RLS e os conjuntos de dados e relatórios do Power BI respeitam a segurança da fonte de dados.
Considere que a 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 impõe a RLS para controlar o acesso a linhas em várias tabelas do banco de dados. Você pode criar um modelo 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 a identidade deles para a fonte de dados. Em seguida, a fonte de dados impõe a RLS com base na identidade do consumidor do relatório.
Para obter informações sobre a RLS do Banco de Dados SQL do Azure, confira Segurança em nível de linha.
Observação
Tabelas e colunas calculadas que fazem referência a uma tabela DirectQuery de uma fonte de dados com autenticação SSO não têm suporte 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.