(+351) 21 24 10006  ·  info@bconcepts.pt
Carnaxide, Lisboa

PL-300: como implementar segurança por linha (RLS) em Power BI

João Barros 04 de October de 2026 4 min de leitura

Vou ensinar como implementar Row-Level Security (RLS) em Power BI — uma competência do domínio "Gerir e proteger os recursos do Power BI" do exame PL-300. RLS é essencial para limitar os dados visíveis por cada utilizador e é frequentemente avaliado tanto em cenários práticos do exame como em implementações empresariais.

O que precisas de saber

Row-Level Security (RLS) permite que restrinjas quais as linhas de uma tabela que cada utilizador (ou grupo) pode ver num relatório ou conjunto de dados. Existem dois modos principais:

  • Static RLS: defines funções com regras estáticas (ex.: [Country] = "Portugal") no modelo e depois atribuis utilizadores ou grupos a essas funções no serviço Power BI.
  • Dynamic RLS: a regra depende da identidade do utilizador no momento (por exemplo, compara [UserEmail] com USERPRINCIPALNAME()). Permite gerir permissões sem mapear explicitamente cada utilizador a uma função.

Exemplo simples: tens uma tabela Sales com coluna Region. Queres que o utilizador apenas veja vendas da sua região. Em Static RLS crias uma função RegionFilter com a expressão [Region] = "North". Em Dynamic RLS, usas uma tabela que mapeia utilizadores às regiões e filtras com USERPRINCIPALNAME().

Como funciona (passo-a-passo)

Segue este processo prático para implementar RLS numa solução típica:

  1. Preparar o modelo: garante que tens uma chave que liga a tabela de factos (ex.: Sales) à dimensão que contém a delegação das permissões (ex.: Users ou Regions). Ex.: Sales[RegionID] relaciona com Regions[RegionID].

  2. Criar uma tabela de mapeamento (para Dynamic RLS): cria uma tabela Users com colunas [UserPrincipalName] e [RegionID]. Podes mantê-la dentro do modelo ou trazer de uma fonte.

  3. Definir a função RLS no Power BI Desktop:

    Modeling > Manage roles > Create > Role name: RegionRole -- Se for Static: Regions[RegionName] = "North"  -- Se for Dynamic: Regions[RegionID] IN VALUES(Users[RegionID])

    A expressão no gestor de funções é uma DAX que resulta em verdadeiro para as linhas permitidas.

  4. Testar a função no Desktop: usa View as Roles (Modeling > View as) para simular um utilizador ou função. Para dynamic RLS usa a opção "Other user" e insere o e-mail para testar a filtragem com USERPRINCIPALNAME().

  5. Publicar e atribuir utilizadores no serviço Power BI: publica o relatório para um workspace no serviço. Em Datasets > Security seleciona a role que criaste e adiciona utilizadores ou grupos (Azure AD) para Static RLS. Para Dynamic RLS não adicionas mapeamentos aqui: a regra usa a identidade do utilizador quando acede.

  6. Testar no serviço: usa a opção "Test as role" se disponível, ou pede a um utilizador real com as credenciais apropriadas para validar a experiência no relatório publicado.

Na prática: exemplo DAX para Dynamic RLS

Um padrão comum é comparar o e-mail do utilizador com a tabela de mapeamento. Exemplo de expressão numa role:

-- Role: RegionalAccess CONTAINS(   Users,   Users[UserPrincipalName],   USERPRINCIPALNAME(),   Users[RegionID],   Regions[RegionID] )

Uma alternativa mais simples (quando a relação está definida entre Users e Regions):

Users[UserPrincipalName] = USERPRINCIPALNAME()

Esta última assume que, através da relação, filtra todas as linhas da dimensão Regions e, por consequência, as linhas de Sales relacionadas.

Erros comuns

  • Assumir que RLS funciona sem relações correctas: se não houver uma relação entre a tabela de mapeamento e a tabela de factos, a filtragem não se propaga.
  • Usar USERPRINCIPALNAME() no Desktop sem testar adequadamente: no Desktop o valor pode ser o teu utilizador; usa "View as" e a opção "Other user" para simular outros utilizadores.
  • Adicionar utilizadores ao workspace em vez de à função (confusão): dar acesso ao workspace não substitui RLS — pode dar acesso a relatórios, mas os dados ainda são filtrados por RLS se estiver configurada.

Como praticar

Pratica criando tanto static como dynamic RLS em modelos de exemplo. Usa conjuntos de dados com dimensão de utilizadores e relações claras. Para preparação para o exame, faz o Practice Assessment OFICIAL e gratuito da Microsoft e consulta a study guide oficial (também gratuita) — estes recursos ajudam a perceber o que o exame mede sem fornecer perguntas reais.

Em resumo

  • RLS limita linha a linha o que cada utilizador vê; há Static e Dynamic RLS.
  • Dynamic RLS usa funções DAX como USERPRINCIPALNAME() e uma tabela de mapeamento para evitar gerir listas de utilizadores manualmente.
  • Relações correctas no modelo são essenciais para que o RLS se propague às tabelas de factos.
  • Testa sempre no Desktop (View as) e no serviço Power BI; no serviço atribui utilizadores às roles para Static RLS.