Restringir o acesso aos dados do 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 de modelo usando expressões de filtro DAX (Data Analysis Expressions).
Nota
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.
Gorjeta
É 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 função configurada seria adequada para um usuário administrador que tem permissão para visualizar 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 SQL Server Management Studio (SSMS) ou uma ferramenta de terceiros, como o Editor de Tabela.
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 os princípios de design do esquema em estrela para produzir um modelo que inclua tabelas de dimensões e fatos. É comum configurar o Power BI para impor regras que filtram tabelas de dimensão, permitindo que as relações de modelo propaguem eficientemente esses filtros 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 compreendendo uma única tabela de fatos chamada Sales. As outras tabelas são tabelas de dimensão que suportam a análise de medidas de vendas por data, território de vendas, cliente, revendedor, pedido, produto e vendedor. Observe as relações de modelo conectando todas as tabelas. Essas relações propagam filtros (direta ou indiretamente) para a tabela Sales .
Este design de modelo suporta exemplos apresentados nesta unidade.
Definir regras
As expressões de regra são avaliadas dentro do contexto de linha. 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.
Gorjeta
Para saber mais sobre o contexto de linha, trabalhe no módulo Adicionar tabelas e colunas calculadas aos modelos do Power BI Desktop. Embora este módulo descreva a adição de cálculos de modelo, ele inclui uma unidade que introduz e descreve o contexto da linha.
Você pode definir regras que são estáticas ou dinâmicas.
Regras estáticas
As regras estáticas usam expressões DAX que se referem a constantes.
Considere a seguinte regra aplicada à tabela Região que restringe o acesso aos dados às vendas do Centro-Oeste.
'Region'[Region] = "Midwest"
As etapas a seguir explicam como o Power BI impõe a regra. Isso:
Filtra a tabela Região , resultando em uma linha visível (para Centro-Oeste).
Usa a relação de modelo para propagar o filtro da tabela Região para a tabela Estado , resultando em 14 linhas visíveis (a região Centro-Oeste compreende 14 estados).
Usa a relação de modelo para propagar o filtro da tabela Estado para a 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 da tabela. Considere a seguinte regra aplicada à tabela Detalhes de vendas (não representada no diagrama de modelo).
FALSE()
Essa regra garante que os usuários não possam acessar nenhum dado da tabela. Pode ser útil quando os vendedores podem ver 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á-los quando precisar criar apenas alguns deles, como pode ser o caso da Adventure Works, onde há apenas seis regiões dos EUA. No entanto, esteja ciente das desvantagens: a criação de regras estáticas pode envolver um esforço significativo para criar e configurar. 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ê adicionar novas regras no futuro, considere criar regras dinâmicas.
Regras dinâmicas
As regras dinâmicas usam funções DAX específicas que retornam valores ambientais (em oposição a 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. As 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.
Nota
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 UPN (Nome Principal do Usuário) 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 principal do usuário.
Considere um design de modelo revisado que agora inclua 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 Region propaga filtros da tabela AppUser.
A regra a seguir aplicada à tabela AppUser restringe o acesso aos dados à(s) região(ões) do usuário autenticado.
'AppUser'[UserName] = USERPRINCIPALNAME()
A definição de regras dinâmicas é simples e eficaz quando uma tabela modelo armazena valores de nome de usuário. Eles permitem que você imponha um design de RLS orientado 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 simplesmente funciona.
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 de os usuários acessarem o conteúdo do Power BI. O mapeamento de funções envolve a atribuição de 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.
Gorjeta
Sempre que 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ções normalmente é feito no serviço do Power BI. Para modelos do Azure Analysis Services ou do SQL Server Analysis Services, o mapeamento de funções normalmente é feito no SSMS.
Para obter mais informações sobre como configurar a RLS, consulte:
Usar logon único (SSO) para fontes do DirectQuery
Quando seu modelo de dados tem tabelas DirectQuery e sua fonte de dados oferece suporte a 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 honram 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 do Power BI. O banco de dados impõe RLS para controlar o acesso a linhas em várias tabelas de 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 sua identidade 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 RLS do Banco de Dados SQL do Azure, consulte Segurança em nível de linha.
Nota
Tabelas calculadas e colunas calculadas que fazem referência a uma tabela DirectQuery de uma fonte de dados com autenticação SSO não são suportadas no serviço Power BI.
Para obter mais informações sobre fontes de dados que oferecem suporte a SSO, consulte Logon único (SSO) para fontes DirectQuery.