Como fazer proteção RLS no meu relatório?

Já ouviu falar em RLS? Aprenda a configurar o seu relatório do Power BI para dar acessos restritos aos utilizadores, de acordo com as necessidades de cada um.

O RLS é a sigla para Rows Level Security, ou seja, é um recurso disponível no Power BI que trata da segurança ao nível de linha. Esta segurança pode ser utilizada para restringir o acesso ao relatório. É como se o Power BI criasse alguns filtros internamente para acedermos somente ao que nos é interessante ou desejado.

“Dai a César o que é de César”. Quando criamos um relatório, sabemos que algumas informações são mais específicas para cada setor da organização, ou mesmo são sigilosas, e não podem ser repassadas a qualquer pessoa.
Imagine o seguinte cenário: uma empresa que presta serviços de contabilidade e detém informações contabilísticas de cem outras pequenas e médias empresas. O analista de dados dessa empresa não precisa criar 100 relatórios de balancetes diferentes, ou seja, um para cada empresa. Não é necessário. Basta criar apenas um e utilizar os recursos do Power BI, tais como: filtros, funções e RLS, e dar acessos diferentes aos gestores de cada empresa. Esses só conseguirão visualizar as informações da respetiva organização. A empresa ABC não terá acesso ao balancete da empresa AAA e vice-versa.

Num outro cenário, imagine que estamos a criar um relatório para uma empresa e queremos dar acessos diferenciados aos gestores, de modo que, os diretores financeiros tenham acesso a todos os dados (acesso full), os gestores responsáveis pela construção, apenas veem as informações desse segmento, assim como o gestor de jardinagem, só vê essas informações, bem como os gestores do segmento ‘pedra’ só veem informações relacionadas com a ‘pedra’.

Criámos uma demostração para simular este último cenário e utilizar o RLS.

Com o relatório desejado aberto no Power BI Desktop, vamos aceder ao friso de Modelação e clicar na opção “gerir funções”. É nesta opção que vamos criar as regras do RLS.

1. Modelação > Segurança > Gerir Funções > Criar > ‘Dar o nome à função com as regras pretendidas’ > Guardar

Ao abrir ‘Gerir funções’ aparecem duas colunas e um quadrado. A primeira coluna serve para darmos o nome das funções. Enquanto que a segunda coluna serve para selecionarmos em qual tabela queremos aplicar o filtro. E consequentemente, a expressão DAX que utilizamos, serve para inserirmos um filtro de tabela.

No nosso caso, criamos 5 funções:

All : [BU] = "CONSTRUÇÃO" || [BU] = "GARDENA" || [BU] = "PEDRA" || [BU] = "FÁBRICA" || [BU] = "OUTROS"
Construção: [BU] = "CONSTRUÇÃO"
Gardena: [BU] = "GARDENA"
Gardena e Construção: [BU] = "GARDENA" || [BU] = "CONSTRUÇÃO"
Pedra: [BU] = "PEDRA"

A vermelho colocamos a expressão DAX que filtra a tabela ‘Master Clientes’ e atua na coluna ‘BU’.

Ao finalizar a criação das funções que farão as limitações, conseguimos testar para verificar se as regras ficaram bem feitas.

2. Modelação > Segurança > Ver como > ‘Testar se deu certo’

Podemos marcar cada uma das funções e validar se está a filtrar corretamente. Quando, por exemplo, marcamos a opção ‘Gardena e Construção’ e damos ‘OK’, o Power BI mostra o relatório com os filtros desta função.

3. Salvar e Publicar relatório

4. No Power BI Service > Workspace > Conjunto de dados > ‘Nome do relatório’ … > Segurança

5. Atribuir e-mails dos utilizadores. É neste passo que registamos os e-mails dos utilizadores que receberão acesso ao relatório e a cada uma das funções que criamos.

Ou seja, no caso da imagem acima, demos acesso apenas a 4 gestores de jardinagem (Gardena) que terão acessos restritos a esse tema.

No entanto, ainda é preciso partilhar o relatório com esses colaboradores. O que fizemos até aqui foi a criação de funções que restringem (RLS). Agora sim vamos partilhar.

6. Relatório aberto > Partilhar relatório > Enviar e-mails para permissão de acesso

7. Inserir os e-mails para acesso > Verificar se é o caso de desmarcar as opções ‘Permitir aos destinatários partilhar o relatório’ e ‘Permitir que os destinatários criem novos relatórios com os conjuntos de dados subjacentes’. Em geral , eu diria que SIM, para desmarcar. Por uma questão de precaução e segurança.