DP-700: como implementar políticas de acesso row-level em Fabric

Vou ensinar como implementar Row-Level Security (RLS) em tabelas do Microsoft Fabric. Esta competência é importante para o exame DP-700 porque demonstra controlo de acesso a dados em ambientes analytics, e na prática protege registos sensíveis garantindo que utilizadores veem apenas o que lhes é permitido.

O que precisas de saber

Row-Level Security (RLS) limita as linhas que um utilizador pode consultar numa tabela, com base na sua identidade ou em regras. Em Fabric (por exemplo em tabelas de Power BI ou em tabelas Delta numa workspace de Data Warehouse/Table), RLS pode ser aplicada através de roles e filtros que usam colunas como UserID, DepartmentID ou atributos de sessão.

Exemplo conceptual: tens uma tabela Sales com uma coluna Region. Se um analista pertence só à região "North", RLS assegura que as suas queries só retornam linhas onde Region = 'North'.

Como funciona

Em termos gerais, existem três componentes em RLS:

• Identidade do utilizador: autenticada via Azure AD.
• Definição da regra: um filtro que expressa quais as linhas visíveis.
• Aplicação do filtro: mecanismo que injeta o filtro nas queries a tempo de execução.

Nas implementações comuns em Fabric podes usar duas abordagens principais:

• RLS nativa no modelo Power BI (roles com DAX) — aplicável quando o modelo está a servir relatórios Power BI dentro de Fabric ou Power BI Service.
• RLS ao nível da tabela/Delta com políticas de segurança em OneLake / Data Warehouse (usando permissões do SQL endpoint ou object-level policies) — aplicável para cenários onde múltiplas ferramentas acedem às tabelas.

Na prática

Vou descrever um exemplo prático com duas opções: (A) RLS em modelo Power BI usando DAX roles; (B) RLS em tabelas geridas usando a coluna de segurança e filtros no SQL endpoint. Os passos são simplificados e didáticos.

A — RLS no modelo Power BI (DAX roles)

1. Prepara a tabela: garante uma coluna que identifique a pertença, ex.: UserEmail ou RegionID.
2. No Power BI Desktop (ou no Model Designer em Fabric), cria um role: Model > Manage Roles.
3. Definir a expressão DAX para o role. Exemplo para filtrar por email do utilizador atual:

   [UserEmail] = USERPRINCIPALNAME()

4. Testa o role usando View As Roles para simular diferentes utilizadores.
5. Publica o modelo para Fabric/Power BI Service. No serviço, atribui utilizadores aos roles se necessário (ou usa a expressão dinâmica USERPRINCIPALNAME para evitar atribuições manuais).

B — RLS ao nível de tabelas/SQL endpoint

1. Inclui uma coluna de controlo, ex.: AllowedDepartmentID, e mantém uma tabela de mapping UserDepartment(UserPrincipalName, DepartmentID).
2. Cria uma view segura que junta os dados com o mapping e aplica filtro. Exemplo em SQL do SQL endpoint:

   CREATE VIEW v_Sales_Secure AS
   SELECT s.*
   FROM Sales s
   JOIN UserDepartment u ON s.DepartmentID = u.DepartmentID
   WHERE u.UserPrincipalName = ORIGINAL_LOGIN();

   Nota: a função que retorna o utilizador pode variar conforme o endpoint; em ambientes Fabric/SQL usa-se a função adequada para a identidade do utilizador.
3. Concede acesso dos utilizadores apenas à view v_Sales_Secure e nega acesso direto à tabela Sales.
4. Configura roles/privilege no workspace para que aplicações e utilizadores consultem apenas a view.

Boas práticas

• Preferir filtros dinâmicos (ex.: USERPRINCIPALNAME()) para evitar gestão manual de roles.
• Manter mappings de identidade atualizados (integração com Azure AD simplifica isto).
• Testar RLS com contas reais ou ferramentas de simulação.

Erros comuns

• Assumir que RLS substitui permissões de objecto: RLS filtra linhas, mas ainda precisas de garantir que utilizadores não podem aceder a tabelas brutas diretamente.
• Usar colunas com valores NULL para controlar acesso sem tratamento adequado — NULL pode tornar os filtros ineficazes e abrir fugas de dados.
• Depender apenas de atribuições manuais de roles em vez de expressões dinâmicas; a gestão escala mal em organizações grandes.

Como praticar

Pratica implementando ambos os métodos num ambiente Fabric trial ou numa subscrição de treino. Cria datasets com colunas de controlo e testa com diferentes identidades.

Para preparar o exame, usa o Practice Assessment OFICIAL da Microsoft (é gratuito) e consulta a Study Guide oficial (gratuita) para DP-700 — estes recursos ajudam-te a validar conhecimentos sem recorrer a material proibido.

Em resumo

• RLS controla que linhas cada utilizador pode ver — essencial para proteger dados sensíveis em analytics.
• Pode ser implementado no modelo Power BI (DAX roles) ou ao nível da tabela/SQL endpoint (views seguras e mapeamentos).
• Testa sempre com identidades reais e evita configurações que permitam acesso direto às tabelas subjacentes.
• Usa os recursos oficiais da Microsoft (Practice Assessment e Study Guide) para praticar de forma correcta e gratuita.