Um dos requisitos mais comuns que surgem em projetos de BI está relacionado à segurança da informação. Quando diversos usuários acessam um mesmo relatório, muitas vezes se vê necessário que cada um tenha acesso e veja apenas os dados que o competem.
Por exemplo, uma empresa que tenha filiais em diversos países geralmente tem gestores em cada filial, possivelmente gestores por região ou continente e ainda um gestor global. Estabelece-se aí uma hierarquia para a segurança de informação. O gestor global deve ter acesso a todos os dados de todas as filiais, enquanto o gestor de uma das filiais só consegue enxergar dados sensíveis referentes à sua filial apenas.
Dada essa contextualização, o recurso que nos permite sanar esse requisito é chamado de RLS, ou Row-Level Security, em inglês.
Nesse artigo demonstraremos como configurar RLS para soluções de relatórios consumidos pelo Power BI Service, o portal da Microsoft, de endereço app.powerbi.com. Especificamos isto pois há uma diferença em parte do processo quando falamos de Power BI Embedded.
Primeiramente, precisamos construir uma tabela de usuários no modelo. Abaixo temos um exemplo condizente com a explicação do primeiro parágrafo.
Como, neste exemplo, temos uma hierarquia definida, uma forma de modelar o problema passa por construir uma tabela intermediária (entre ‘Usuário’ e ‘Vendas’) com as relações de macrorregião e região, como pode ser vista abaixo.
Demonstramos abaixo a tabela ‘Vendas’ que construímos.
Em seguida, definimos os relacionamentos adequados, de forma unidirecional, de forma que ‘Usuário’ filtre ‘Região’ que, por sua vez, filtre ‘Vendas’.
Abaixo, demonstramos a criação da regra de RLS.
Primeiro, devemos ir na aba de “Modeling” (Modelagem) e clicar em “Manage Roles” (Gerenciar Funções). Uma janela abrirá, como indicado na figura. Criamos então uma nova Role (Função) que faça com que o modelo identifique qual coluna de qual tabela será considerada ao cruzar com o e-mail do usuário logado no Power BI Service. A função utilizada para isso em DAX é a USERNAME().
Antes de publicar o relatório, podemos testar se a regra está sendo aplicada adequadamente no Power BI Desktop. Ainda na aba de “Modeling” (Modelagem), devemos clicar em “View as” (Exibir como Funções), escolher quais regras de RLS você pretende testar e simular a utilização de um usuário específico.
Ao clicar em “OK”, o relatório já é filtrado corretamente, conforme pode ser verificado na imagem abaixo:
Constatado que a regra está funcionando adequadamente, podemos publicar o relatório, para que possamos fazer a configuração de quais usuários se enquadrarão na regra de RLS criada. Com o relatório já publicado, podemos abrir o portal do Power BI Service no endereço app.powerbi.com.
No workspace em que o relatório foi publicado, passamos a ter mais 2 objetos: o relatório e o dataset que o relatório usa como fonte. Devemos, então, clicar nos três pontinhos ao lado do dataset e, em seguida, em “Security” (Segurança), conforme demonstrado abaixo.
A partir daí iremos para uma outra página, onde adicionaremos usuários ou grupos na nossa regra de RLS.
Após selecionarmos todos os usuários de interesse, devemos clicar em “Save” (Salvar). Tendo feito isso, devemos clicar nos três pontinhos ao lado do nome da regra de RLS e, em seguida, em “Test as Role” (Testar como Função).
Nessa página verificamos que, por estar logado como ravi.quast@hulking-fantastic-ketchup.blogs.prod.stage.rock.works, o relatório já mostra apenas os dados que competem a esse e-mail. Aqui poderíamos testar como seria a visão de um dos outros 4 usuários que foram adicionados à Role RLS Gestor. Para isso, bastaria preencher o campo “Select Person” (Selecione a Pessoa) com o e-mail referente ao usuário de interesse.
Concluímos todas as etapas necessárias para configurarmos a segurança em nível de linha no nosso relatório. Note que como a tabela de Usuários filtra os dados depende de cada aplicação. Caso nossa tabela fato ‘Vendas’ tivesse uma coluna que identificasse os gestores responsáveis por cada vendedor, poderíamos criar uma regra de RLS por meio do ID dos gestores, em vez de usar a macrorregião. Caso tivéssemos, ainda, uma tabela de vendedores, poderíamos filtrar a ‘Vendas’ diretamente pela coluna ‘Vendas’[Vendedor ID]. Neste caso, criaríamos uma Role para que vendedores pudessem acessar o mesmo relatório e analisar apenas os dados das suas próprias vendas.
A título de curiosidade, quando se configura regras de RLS para uma aplicação de Power BI Embedded, pode-se passar qualquer tipo de dado, via código, para a função USERNAME(). Ao criar a Role no Power BI Desktop deve-se envolvê-la com a função VALUE(), caso o valor seja numérico. Para deixar mais claro, pode-se configurar uma regra de RLS com um ID numérico referente a qualquer dado filtrável no relatório. Além disso, tanto em aplicações em que o consumo dos relatórios será por Power BI Service, quanto em aplicações em que isso é feito pelo Power BI Embedded, pode-se criar e utilizar mais de uma Role ao mesmo tempo. Há casos em que queremos aplicar um RLS por ID’s não relacionados diretamente a usuários e casos em que temos, por alguma limitação ou especificidade do modelo, mais de uma tabela de usuários (3 tabelas por exemplo: uma para gestores, uma para clientes e uma para consultores).
Observação
É muito importante ressaltar que os tipos de acesso dados aos usuários de um workspace sobrepõem quaisquer regras de RLS configuradas nos relatórios. Por exemplo, se um usuário tem acesso ao workspace como Administrador, Membro ou Contribuidor, as regras de RLS não vão se aplicar a ele, que conseguirá ver todos os dados presentes no dataset. Isso se dá, pois, todos esses tipos de acesso têm permissão para editar os relatórios. Para que isso não ocorra, é necessário que se crie o aplicativo do workspace e os acessos aos usuários sejam dados ao aplicativo. Caso o usuário precise de acesso também ao workspace, deve-se tomar o cuidado de garantir que seja de Visualizador.
Esperamos que tenha dado uma clareada no processo de configuração de regras de RLS em geral, mais especificamente quando o relatório for ser consumido via Power BI Service.
Aproveite para conferir mais conteúdos sobre Data Analytics!
