No exame da Microsoft o termo “row-level security” aparece em apenas um tópico:
- implement row-level security roles
No entanto, pelos relatos que já li pela internet a fora, RLS é um dos principais assuntos do Exame DA-100, por isso é muito importante entender RLS e como ele funciona.
O que é RLS?
RLS, ou Row Level Security, ou row-level security, significa exatamente o que o termo quer dizer “segurança a nível de linha“. Então quando você estiver pensando em RLS imagina que você tem uma tabela de Excel com todos registros de VENDAS feitos nesse ano, e nessa tabela tem uma coluna chamada “permissão” e aí nessa coluna permissão você tem algumas linhas escrito “gerente”, outras com “supervisor” outras com “vendedor”.
Se você filtrar essa coluna e escolher GERENTE, você só vai conseguir ver as linhas das VENDAS cuja permissão seja GERENTE, certo? Então, RLS funciona exatamente dessa forma. Ele filtra seu modelo de dados a nível de linha.
Tá, mas e se eu quiser que meu RLS além de filtrar as linhas da coluna permissão como GERENTE, ele também esconda algumas COLUNAS dessa minha tabela? Tem como? Não, isso RLS não faz, porque como foi dito, é segurança a nível de LINHA, colunas não são linhas, né isso?
RLS também não faz segurança de objetos no seu modelo de dados, como tabelas, colunas ou measures. Só linha!
Nessa imagem abaixo eu tento ilustrar como RLS funciona, um filtro, moleza?
Claro, implementar RLS pode ser bastante complicado e pode exigir funções DAX complexas a depender da regra de negócio da sua organização, mas independente da regra, seja ela o quão complexa for, no final das contas RLS não passa de um filtro no seu modelo de dados.
Modelo de Dados no Power BI
Pra você entender como RLS funciona e se aplica no Power BI você precisa entender basicamente duas coisas:
- Filtros: Como filtros se propagam pelo modelo de dados
- Table Expansion: Como o Power BI realiza um negócio chamado Table Expansion nos seus relacionamentos
Filtros: Para entender como filtros funcionam e são propagados, dá uma lida no post de anterior, onde eu falo de Cross-Filter, aqui. Nesse post tem um monte de informação e links pra você revisar praticamente tudo sobre cross-filter.
Mas resumindo é o seguinte, o filtro se propaga na direção da setinha. Na imagem abaixo, por exemplo, a tabela DATA filtra FactInternetSales e filta DimCustomer, enquanto que DimCustomer filtra FactInternetSales e FactInternetSales filtra DimCustomer, porém DimCustomer não filtra DATA e FactInternetSales também não filtra DATA. Ou seja, se eu aplicar um RLS em DATA ele vai se propagar até DimCustomer, porém, se eu criar um RLS em DimCustomer ele não vai filtrar DATA.
Table Expansion: sabe no Power Query quando vc faz um MERGE entre duas tabelas e daí aparece aquela coluna extra que tu pode clicar nela e EXPANDIR pra aparecer mais colunas? Então, Table Expansion é exatamente isso, só que ocorre automaticamente no seu modelo de dados no Power BI quando você tem relacionamentos entre tabelas. Mas esse assunto é bastante extenso… Table Expansion funciona de formas diferentes se você tiver um relacionamento 1:N ou N:N ou 1:1, ou se é uma weak relationship, enfim, dá uma lida nesse assunto.
Entender Table Expansion é importante porque se você está filtrando alguma informação, precisa entender como que suas tabelas estão sendo “mergeadas” pra entender qual vai ser o resultado do seu filtro.
O gif animado abaixo explica bem, tenha um pouco de paciência e assista ele umas 2x que você vai entender.
Mas perceba que o seguinte, nessa tabelona criada no gif (e que eu coloquei um print abaixo) a tabela expandida tem uma porrada de colunas, e qual delas você estaria usando pra aplicar seu RLS? Imagina que você esteja aplicando RLS na coluna de COR = Yellow. Qual seria o resultado esperado?
Bem, você claramente iria ver 3 registros, mas e o último registro? E esse registro BLANK? Será que você também quer ver isso? Então considere esse raciocínio quando estiver definindo suas funções em RLS.
Como Implementar RLS?
Como nós já sabemos, RLS é um filtro numa coluna de uma tabela que se propaga pelo modelo de dados considerando os relacionamentos, seus direcionamentos e table expansion.
Portanto, pra implementar RLS eu preciso conhecer meu modelo de dados e escolher a tabela e coluna certa que filtrando a informação que eu quero vai resultar na informação desejada.
Exemplo 1 – RLS Estático
Aqui no meu trabalho eu tenho uma tabela fato de DEMANDAS, que são trabalhos que fazemos e essas demandas tem uma área responsável e um valor. E eu não posso deixar com que outras áreas vejam as demandas umas das outras, por questões de dinheiro mesmo. Um cara não pode saber que a área dele vende 100 mil enquanto a do outro vende 20 mil, porque senão vai dar problema, sabe como são seres humanos…
Então nosso modelo é o seguinte:
DEMANDA é nossa fato, que é filtrada por AREA. Se eu preciso que cada time, ou cada AREA, veja apenas suas próprias DEMANDAS, basta que eu crie um RLS para o time do RH dizendo que AREA = “RH”, e depois ir lá no Power BI Service e associar todas pessoas do RH nessa ROLE ( ou associar um grupo de email do RH nessa role, seria mais fácil).
Pra criar a ROLE foi assim:
A imagem ficou meio feiosa, mas é só clicar em Manage Roles, ali no menu de Modeling > Manage Roles, daí na janela que se abre você cria uma nova role, eu dei o nome de RH.
A parte difícil é saber onde fazer o filtro. Eu fiz em AREA e disse que [AREA] = “RH”, mas você concorda que eu poderia ter feito o mesmo filtro em DEMANDAS, já que lá também tenho como facilmente identificar todos registros para RH?! (spoiler: SIM)
Depois da ROLE criada, é só publicar o report no Power BI Service e associar as pessoas ou grupos nessa role. Atenção: associar não significa compartilhar. Não é porque você adicionou a pessoa na ROLE do RLS que ela passa automaticamente a ter acesso ao report, vc ainda precisa compartilhar o report ou dashboard com ela.
No Power BI Service, vá até seu dataset > security.
Perceba que já tem 2 pessoas nessa ROLE, a Adele e o Grady, e estou pra adicionar a Johanna. Depois de adicionar quem eu quero, dá pra clicar nos 3 pontinhos e selecionar Test as Role, pra você ver o resultado.
E aí está nosso resultado, RH filtrado com sucesso.
Esse mesmo teste de Role, que mostrei nessa última imagem, também pode ser feito no Power BI Desktop. Você vai em Modeling > View as > e escolhe a role ali.
Exemplo 2 – RLS Dinâmico
RLS dinâmico é quando você não precisa ficar tratando as regras manualmente, ou seja, no exemplo 1, se você criar uma área nova, vai precisar criar manualmente uma ROLE nova no Power BI Desktop e depois associar as pessoas ou grupos manualmente lá no Power BI Service.
Com RLS Dinâmico isso não precisa mais, você cria seu modelo de dados certinho e cria a ROLE de acordo com seu modelo de dados, de forma que ele se auto-regule.
Pensa assim, se ao invés de AREA eu tivesse USUARIOS? Sendo que cada usuário pertence a uma área, e cada usuário pode ver o resultado da sua área. Como resolver isso?
Primeiro vamos precisar da tabela de usuários e os emails que usam pra se logar no Power BI Service, porque são esses emails que vão ser passados no RLS. Depois é só relacionar essa tabela de usuários com nossa fato demanda e pronto. Esse modelo tem diferentes forma de resolver, mas eu vou desenhar assim:
Usuários perpetuam o filtro para AREA até chegar em DEMANDAS. (eu poderia associar USARIOS diretamente com DEMANDAS, também daria certo)
NOTA: Por padrão, o relacionamento entre USUARIOS e AREA é de N:1 com direção saindo do 1 para o N, ou seja, de AREA -> USUARIOS, só que com uma direção nesse sentido o meu filtro saindo de USUARIOS nunca chegaria em DEMANDAS. Por isso, nesse caso, precisei manualmente alterar a relação pra direcionamento BOTH e também ativar o “apply security filter in both directions”.
Agora é só criar a ROLE, mas antes deixa eu te mostrar os dados das tabelas. Perceba que cada usuário pertence somente a uma AREA.
Agora a ROLE:
O que essa ROLE está dizendo é que, o usuário logado será passado como filtro na tabela USUARIOS, na coluna EMAIL. Testando com meu usuário:
Funcionou certinho. Agora é só ir no Power BI Service e dar acesso a todos usuários nessa ROLE, porque a regra dela na verdade acontece de acordo com nosso modelo de dados, onde ele vai olhar o usuário logado, vai ver a qual AREA aquela pessoa pertence e então vai filtrar o dataset de acordo com essa regra.
E se o o usuário estiver em duas áreas?
Se o usuário estiver em duas áreas ele precisa ver todas as linhas das suas áreas dele. Certo? Pensando nisso fiz uma modificação simples no arquivo de usuários, eu repeti a linha do meu usuário e adicione pra ele uma nova AREA. Agora nosso amigo Pradeep participa da área de RH e também da área de FINANCA.
Mantendo o modelo como está, sem fazer nada, eu vou apenas atualizar o relatório, e vamos fazer o teste com o Pradeep pra ver o resultado… Passando o Pradeep como usuário na nossa ROLES agora é possível ver todas as linhas relacionadas as áreas a qual ele possui.
Claro, essa não é a forma mais elegante de tratar usuários pertecentes a várias áreas, poderíamos criar uma bridge table pra tratar isso, transformando nosso relacionamento entre USUARIOS e AREA um relacionamento N:N.
Exemplo 3 – RLS Dinâmico com N:N
Pra criar esse exemplo eu modifiquei um pouco nosso modelo de dados. Perceba na imagem abaixo que eu removi da tabela de usuários a AREA e no lugar eu criei uma nova tabela, que chamei de USERxAREA onde relacionei os usuários e quais áreas eles possuem.
Veja que o PEDRO está nas três areas, e mais um monte de gente em pelo menos 1 ou mais áreas.
E nossos relacionamentos, como que ficam? Por padrão, ao criar uma bridge table é assim que seu modelo vai ficar. A gente chama essa relacão entre USUARIOS, USERxAREA e AREA De one many many one, ou 1 * * 1, ou 1 N N 1.
Só que você já sabe que, se eu fizer um RLS na tabela de USUARIOS, esse filtro só vai se perpetuar até USERxAREA e vai morrer ali. Do jeito que meus relacionamentos estão definidos o meu RLS não se perpetua até a tabela de DEMANDAS.
Pra resolver esse problema, eu preciso mudar a direção do cross-filter entre USERxAREA e AREA para BOTH e marcar a caixinha lá do “apply security filter in both directions”.
Se eu fizer isso, minha RLS, que é baseada na tabela USUARIOS, vai conseguir ser perpetuada pelos relacionamentos até chegar em DEMANDAS e filtrar.
Fazendo o teste com nosso amigo Pradeep:
Deu certinho!
Existem milhares de outros pontos a serem tratados sobre RLS, dá uma olhada no site do RADACAD, é o cara que mais fala sobre esse assunto, e é um sujeito conceituado.
Pontos de Atenção do RLS
- RLS só se aplica a linhas, não se aplica a medidas, colunas ou tabelas.
- RLS se aplica a modelos de IMPORT.
- RLS se aplica a modelos de DirectQuery.
- Se você estiver usando DirectQuery, as roles de segurança da sua fonte de dados serão usadas. Quando um usuário abre um relatório, o Power BI envia uma consulta à fonte de dados subjacente, que aplica regras de segurança aos dados com base nas credenciais do usuário.
- Se você já tem roles de segurança e está usando DirectQuery, essas roles são repassadas para o Power BI, que aplica regras de segurança aos dados com base nas credenciais do usuário.
- RLS funciona com Analysis Services modelo Import.
- RLS no Analysis Services com Live Connection vem do modelo definido dentro do AA, você não seta isso no Power BI.
- No Power BI Service, membros que tenham permissão de EDIT numa workspace não são afetados pelo RLS, mesmo se você colocou o email dele lá.
- No Power BI Service, apenas membros com permissão de VIEWER sofrem as regras impostas pelo RLS (ou seja, rapazeada que tem acesso tipo MEMBER ou CONTRIBUTOR não sofrem as regras das RLS).
- Você não pode atribuir usuários a uma ROLE no Power BI Desktop. Você os atribui no Power BI Service.
- No Power BI Desktop você contrói as ROLES, mas é no Power BI Service que você relaciona as pessoas, ou grupos de emails, nessas ROLES.
- RLS usa filtros unidirecionais, independentemente de os relacionamentos serem configurados para direção única ou bidirecional.
- Se você tem um relacionamento bidirecional e precisa que o RLS funcione nele, você precisa obrigatoriamente habilitar o checkbox “apply security filter in both directions”.
- Quando o Power BI se conecta usando logon único (SSO), o Analysis Services impõe RLS (a menos que a conta tenha privilégios de administrador).
- Evite associar o mesmo membro a mais de um grupo. Procure sempre criar um único ROLE pra cada tipo de pessoa ou grupo de pessoas.
- Quando um usuário de relatório é atribuído a várias ROLES, os filtros de RLS se tornam aditivos. Isso significa que os usuários do relatório podem ver as linhas da tabela que representam a união desses filtros.
- O RLS funciona aplicando filtros automaticamente a cada consulta DAX, e esses filtros podem ter um impacto negativo no desempenho da consulta.
- Se você já tem Roles de segurança no seu banco de dados, mas está usando modelo import, essas roles não são transmitidas para o Power BI.
Referências
https://docs.microsoft.com/en-us/learn/modules/row-level-security-power-bi/
https://docs.microsoft.com/en-us/power-bi/create-reports/desktop-rls
https://docs.microsoft.com/en-us/power-bi/guidance/rls-guidance
https://docs.microsoft.com/en-us/power-bi/admin/service-admin-rls
https://aprendapowerbi.com.br/guia-definitivo-seguranca-de-linha-rls-de-colunas-e-de-paginas/
https://docs.microsoft.com/en-us/power-bi/transform-model/desktop-bidirectional-filtering
https://www.youtube.com/watch?v=dGpX8-4adkY – Microsoft Power BI: Unleash row level security patterns in Power BI – THR3015
https://www.youtube.com/watch?v=9wN33rTaiB4 – Power BI Row-Level Security And Where To Filter
https://www.youtube.com/watch?v=MxU_FYSSnYU – What is Row-Level Security (RLS) in Power BI???
https://www.youtube.com/watch?v=oxYQ2GGefrs – Can you use GROUPS with Power BI Row-Level Security (RLS)???
https://www.youtube.com/watch?v=rs1Uy1jVPow – [POWER BI] Segurança em Nível de Linha (RLS) – Parte 1
https://www.youtube.com/watch?v=3I90P_bxblI – Como fazer RLS no Power BI?
Pedro Carvalho 
2 thoughts on “Power BI Row-Level Security (RLS)”