DP-600: implementar roles de segurança em modelos semânticos
Vou ensinar como implementar Row-Level Security (RLS) em modelos semânticos no contexto do Power BI/Fabric. Esta competência é essencial no DP-600 porque garante que os utilizadores só veem os dados que lhes dizem respeito — uma exigência frequente em soluções analíticas empresariais. A RLS evita exposições inadvertidas e permite cumprir regras de conformidade internas e externas.
O que precisas de saber
Row-Level Security (RLS) restringe quais as linhas de dados que um utilizador pode aceder num modelo semântico. No Power BI e no Fabric, a RLS é aplicada ao nível do modelo (tabular) através de roles que contêm filtros DAX ou, em alguns cenários, mapeamentos de utilizadores. Existem dois modos principais:
- Static RLS: roles com regras fixas (ex.: Sales[Country] = "Germany"). Útil quando grupos têm restrições imutáveis — por exemplo, uma equipa financeira que só vê dados da Alemanha. É simples de gerir quando o número de roles é reduzido (p.ex. 5-10 regiões).
- Dynamic RLS: usa funções DAX como USERPRINCIPALNAME() para aplicar filtros com base no utilizador que acede. Essencial quando as permissões dependem da identidade do utilizador ou quando tens milhares de utilizadores diferentes. Permite manter apenas algumas roles (ex.: "RLS_Region") e usar um mapeamento para determinar o âmbito do utilizador.
Exemplo simples de filtro DAX para uma role que limita a tabela Sales pelo departamento do utilizador (assumindo uma tabela Users com mapeamento):
Sales[SalesRegion] IN VALUES(Users[Region])Outra expressão dinâmica comum é baseada em USERPRINCIPALNAME():
Users[UserPrincipalName] = USERPRINCIPALNAME()A ideia é ligar o utilizador ao seu âmbito através de relações no modelo ou de expressões DAX que consultam tabelas de mapeamento. Lembra-te também das diferenças entre USERNAME() e USERPRINCIPALNAME() — esta última é mais fiável em ambientes Azure AD.
Na prática
Passos práticos para implementar RLS num modelo semântico no Power BI Desktop / Fabric Model:
Preparar mapeamento de utilizadores: cria uma tabela Users (pode ser importada) com colunas: UserPrincipalName, Region, Department, RoleLevel. Em cenários reais podes ter 10k-50k linhas se o mapeamento for por colaborador. Alternativamente, usa um mapeamento por grupo (Azure AD Group) para reduzir a cardinalidade.
Estabelecer relações: no modelo, liga Users a tabelas fact/dimension relevantes (ex.: Users[Region] → Sales[SalesRegion]). Usa relações de 1:* com direção simples preferível do lado Users para facts. Verifica a direção do filtro (single vs both) porque pode afectar o desempenho e o comportamento dos filtros.
Criar role dinâmica: no Power BI Desktop vai a 'Modeling' → 'Manage Roles' e cria uma nova role, por exemplo "RLS_Region". Para a tabela Users ou diretamente na tabela fact escreve uma expressão DAX usando USERPRINCIPALNAME():
Users[UserPrincipalName] = USERPRINCIPALNAME()ou, se quiseres filtrar por região via relação:
Sales[SalesRegion] IN VALUES(Users[Region])Se trabalhares com UPNs que podem variar entre maiúsculas e minúsculas, normaliza com UPPER() ou LOWER() nas duas partes do mapeamento.
Testar roles localmente: usa a funcionalidade "View as" no Power BI Desktop para simular diferentes utilizadores ou roles. Testa com pelo menos 10 casos: admin, 3 utilizadores típicos, 3 que não têm acesso (devem ver 0 linhas) e 3 com acesso multi-região. Isto valida que os filtros funcionam antes de publicar.
Publicar e atribuir utilizadores: publica para o tenant do Fabric/Power BI Service. No serviço, vai ao dataset ou modelo, abre 'Security' e atribui utilizadores ou grupos Azure AD às roles definidas. Recomenda-se usar grupos Azure AD (reduz a gestão) e evitar adicionar manualmente centenas de utilizadores a uma role.
Auditar e validar: verifica com contas de utilizador reais (ou grupos) e usa logs de auditoria e Usage Metrics para confirmar que os acessos estão correctos. Num ambiente com 5k relatórios, configurar alertas de uso anómalo ajuda a detectar erros de RLS.
Erros comuns
- Assumir que a RLS funciona sem relações correctas: se a tabela Users não estiver relacionada correctamente com a fact table, os filtros não serão aplicados como esperado. Por exemplo, uma relação errada pode resultar em 100% dos dados visíveis em vez de 0%.
- Usar USERPRINCIPALNAME() sem garantir o formato correcto: em ambientes com identidades federadas, o valor de USERPRINCIPALNAME() pode não corresponder exactamente à coluna UserPrincipalName; normaliza maiúsculas/minúsculas e formatos (upn vs email) no mapeamento.
- Testar apenas com admins: administradores veem frequentemente mais dados; testa com contas normais ou usa a funcionalidade "View as" para simular utilizadores reais. Além disso, testa medidas complexas (time intelligence) para garantir que o contexto de filtro não quebra cálculos.
- Negligenciar desempenho: filtros complexos em modelos com milhões de linhas podem reduzir o desempenho. Usa índices no backend quando possível, simplifica expressões DAX e avalia DirectQuery vs Import.
Como praticar
Pratica implementando roles em cenários diferentes: por região, por linha de negócio, e com herança via hierarquias (ex.: país → região → loja). Cria um dataset fictício com tabelas Users (5k linhas), Sales (1M linhas), Product e Region. Implementa uma role dinâmica e outra estática, testa queries e mede tempo de resposta (p.ex. 200 ms vs 2s após aplicar RLS).
Ferramentas úteis: DAX Studio para analisar queries e SQL Profiler para diagnosticar DirectQuery. Para treino oficial, usa o Practice Assessment OFICIAL e gratuito da Microsoft e consulta a study guide gratuita da certificação DP-600 na documentação da Microsoft — ambos são recursos oficiais e gratuitos que recomendo para preparação prática e revisão das skills measured.
Em resumo
- A RLS protege dados ao nível de linhas; pode ser estática ou dinâmica.
- Modelos precisam de tabelas de mapeamento e relações correctas para a RLS funcionar.
- USERPRINCIPALNAME() é a função chave para RLS dinâmica, mas normaliza identidades.
- Testar localmente e no serviço é crucial; usa grupos Azure AD para gerir atribuições em larga escala.