Como criar um Data Masking em Lakehouse no Microsoft Fabric

Este tutorial mostra como aplicar Data Masking em tabelas de um Lakehouse no Microsoft Fabric para proteger colunas sensíveis (ex.: números de cartão, NIF, e-mails) sem alterar a fonte. É útil para cumprir requisitos de segurança, permitir relatórios seguros e reduzir a exposição de dados em ambientes de desenvolvimento e produção.

Pré-requisitos

• Conta com acesso a um workspace no Microsoft Fabric e permissões para gerir Lakehouse.
• Um Lakehouse com pelo menos uma Delta Table contendo colunas sensíveis.
• Permissões para criar Views e gerir permissões (GRANT/REVOKE) no Lakehouse.
• Conhecimentos básicos de SQL/Spark SQL e conceitos de segurança de dados.

Passo 1: Identificar colunas sensíveis e criar uma tabela de exemplo

Comece por identificar que colunas precisam de masking. Para testar, crie uma tabela de exemplo no Lakehouse com dados sensíveis. Aqui usamos Spark SQL no Notebook ou no Query Editor do Lakehouse.

CREATE OR REPLACE TABLE default.customers_mask_test (
  id INT,
  name STRING,
  email STRING,
  nif STRING,
  card_number STRING
);

INSERT INTO default.customers_mask_test VALUES
(1, 'Ana Silva', 'ana.silva@example.com', '123456789', '4111111111111111'),
(2, 'Carlos Pereira', 'carlos.p@example.com', '987654321', '5500000000000004');

Passo 2: Conceito — porquê usar Views para Data Masking

Uma abordagem comum no Fabric é criar Views que aplicam funções de masking (substring, regexp_replace, CASE) em colunas sensíveis. Mantém a tabela original intacta e permite conceder permissões diferentes à View e à tabela. Esta técnica é simples e compatível com ferramentas como Power BI e Warehouse.

Passo 3: Criar uma View com regras de Masking

Crie uma View que substitui partes sensíveis por caracteres mascarados. Exemplo: mostrar apenas os 4 últimos dígitos do cartão, ocultar parte do NIF e do e-mail.

CREATE OR REPLACE VIEW default.vw_customers_masked AS
SELECT
  id,
  name,
  -- email: mostrar apenas domínio e primeira letra
  CONCAT(SUBSTRING(email, 1, 1), '***@', SPLIT(email, '@')[1]) AS email,
  -- nif: manter últimos 2 dígitos
  CONCAT(REPEAT('*', LENGTH(nif)-2), SUBSTRING(nif, -2)) AS nif,
  -- card_number: mostrar apenas últimos 4 dígitos
  CONCAT(REPEAT('*', LENGTH(card_number)-4), SUBSTRING(card_number, -4)) AS card_number
FROM default.customers_mask_test;

Passo 4: Testar a View e comparar com a tabela original

Execute queries na View e na tabela original para confirmar o masking. Verifique se a View retorna dados mascarados e se a tabela original continua completa (apenas para administradores).

-- Ver dados originais (apenas para quem tem permissão)
SELECT * FROM default.customers_mask_test;

-- Ver dados mascarados (para utilizadores finais)
SELECT * FROM default.vw_customers_masked;

Passo 5: Gerir permissões — expor apenas a View aos utilizadores

Para garantir que utilizadores finais só veem dados mascarados, revogue o acesso directo à tabela e conceda SELECT apenas na View. Use comandos SQL de controlo de acesso no Lakehouse.

-- Revogar acesso directo à tabela
REVOKE SELECT ON default.customers_mask_test FROM public;

-- Conceder apenas acesso à View a um grupo/role
GRANT SELECT ON default.vw_customers_masked TO analytics_readers;

Passo 6: Automatizar regras com funções reutilizáveis (opcional)

Se tiver várias tabelas, crie funções SQL para reutilizar a lógica de masking e manter consistência.

CREATE OR REPLACE FUNCTION default.mask_email(e STRING) RETURNS STRING
RETURN CONCAT(SUBSTRING(e,1,1),'***@', SPLIT(e,'@')[1]);

CREATE OR REPLACE VIEW default.vw_customers_masked2 AS
SELECT id, name, default.mask_email(email) AS email,
       CONCAT(REPEAT('*', LENGTH(nif)-2), SUBSTRING(nif,-2)) AS nif,
       CONCAT(REPEAT('*', LENGTH(card_number)-4), SUBSTRING(card_number,-4)) AS card_number
FROM default.customers_mask_test;

Verificar o resultado

Confirme que utilizadores no role analytics_readers veem apenas a View e que os dados aparecem mascarados. Os administradores com acesso à tabela original devem confirmar que os dados completos permanecem na tabela base. Teste também a integração: ligue um relatório Power BI ao Lakehouse usando a View e verifique se os relatórios exibem dados mascarados.

Conclusão

Aplicar Data Masking via Views no Lakehouse do Microsoft Fabric é uma solução simples e eficaz para proteger colunas sensíveis sem duplicar dados nem alterar a fonte. Próximos passos: implementar masking dinâmico por role, integrar com grupos do Azure AD e auditar acessos. Dica: teste o masking em ambientes de desenvolvimento antes de aplicar em produção e pergunte: que colunas na sua organização precisam de masking primeiro?