DP-700: implementar segurança de dados em tabelas do Fabric

Vou explicar como implementar segurança de dados em tabelas do Microsoft Fabric — em particular, Row-Level Security (RLS) e Column-Level Security (CLS). Esta competência é relevante para o exame DP-700 porque demonstra controlo de acesso e protecção de dados numa solução de analytics, e é essencial na prática para cumprir requisitos de privacidade e segregação de acesso.

O que precisas de saber

Segurança a nível de dados significa restringir o que cada utilizador pode ver em dados analíticos. As duas abordagens complementares mais comuns em Fabric são:

• Row-Level Security (RLS): limita as linhas visíveis numa tabela com base em regras (por exemplo, só ver clientes do seu próprio território).
• Column-Level Security (CLS): oculta colunas sensíveis (por exemplo, números de cartão de crédito) a determinados papéis ou utilizadores.

Exemplo simples: uma tabela Sales com colunas (SaleID, SalesPersonID, Amount, Cost) e uma dimensão Users com (UserID, Role, Region). Pretendemos que um representante veja apenas vendas da sua Region (RLS) e que apenas gestores vejam a coluna Cost (CLS).

Como funciona

Num ambiente Fabric (OneLake / Lakehouse / Tables), há duas opções gerais para aplicar estas seguranças:

• Aplicar políticas de segurança no próprio objecto tabelar (usando definições de segurança ou filtros no serviço de tabelas).
• Aplicar segurança na camada de exposição (por exemplo, numa view SQL que filtra linhas e remove colunas, ou no Power BI com RLS, embora seja preferível aplicar no ponto central dos dados para consistência).

Workflow típico para RLS em SQL/Views:

-- Exemplo conceptual de view com RLS baseado em função/claim do utilizador
CREATE VIEW vw_Sales AS
SELECT s.SaleID, s.SalesPersonID, s.Amount, s.Cost
FROM Sales s
JOIN Users u ON s.SalesPersonID = u.UserID
WHERE u.Region = CURRENT_USER_REGION();

Nota: em ambientes geridos, as funções e claims de identidade podem ser extraídas do Azure AD; em muitos cenários usas funções ou chaves de ligação entre a identidade e os dados.

Na prática (passo a passo)

Passo 1 — Modela uma tabela de dimensão de utilizadores/segurança: cada utilizador ou papel deve ter atributos necessários (Role, Region, AllowedColumns).

Users(UserID, UserName, Role, Region, AllowedColumns)

Passo 2 — Implementa RLS usando uma view ou política incorporada:

1. Se o teu ambiente suportar políticas built-in de tabela, define a política RLS associada a uma função/claim.
2. Se não, cria views parametrizadas que usam a identidade do utilizador (ou uma função que resolva a sua Region) para filtrar linhas.

Passo 3 — Implementa CLS minimizando a superfície exposta:

• Cria vistas sem as colunas sensíveis para papéis não autorizados.
• Atribui permissões apenas sobre estas vistas, não sobre a tabela base.

-- View para utilizadores gerais (coluna Cost removida)
CREATE VIEW vw_Sales_Public AS
SELECT SaleID, SalesPersonID, Amount
FROM Sales;

-- View para gestores (acesso total)
CREATE VIEW vw_Sales_Managers AS
SELECT SaleID, SalesPersonID, Amount, Cost
FROM Sales;

Passo 4 — Atribui permissões apropriadas (Azure AD, roles no SQL/Workspace): garante que os utilizadores não têm acesso directo à tabela base.

Erros comuns

1) Conceder permissões à tabela base: dar SELECT directo à tabela anula todas as vistas e políticas; concede sempre apenas sobre as vistas ou usa políticas implementadas no motor.

2) Assumir que RLS substitui encriptação: RLS filtra visibilidade, mas dados sensíveis podem precisar de encriptação em repouso/e em trânsito e masking dinâmico conforme requisitos de compliance.

3) Gestão de performance negligenciada: views com joins complexos ou funções de resolução de identidade em cada linha podem degradar a performance — testa e optimiza com índices/partições quando aplicável.

Como praticar

Configura um lab em Fabric/Workspace com uma tabela de Sales e uma tabela Users. Experimenta implementar RLS usando views e, se suportado pelo teu ambiente, políticas nativas de tabela. Testa com contas de utilizador diferentes (utiliza grupos do Azure AD) e valida que cada utilizador vê apenas o esperado.

Para preparar o exame, usa o Practice Assessment OFICIAL e gratuito da Microsoft e a study guide oficial (ambos gratuitos). Estes recursos ajudam-te a confirmar quais as áreas medidas e a praticar com questões de exemplo aprovadas pela Microsoft.

Em resumo

• RLS limita linhas visíveis por utilizador; CLS restringe colunas sensíveis — ambos são complementares.
• Implementa segurança idealmente no ponto central (tabela/política ou views controladas), não apenas na camada de reporte.
• Evita dar acesso directo à tabela base; usa vistas ou políticas e gere permissões via Azure AD/roles.
• Testa a performance e considera medidas adicionais (masking, encriptação) conforme requisitos de compliance.