Cómo crear un Data Masking en Lakehouse en Microsoft Fabric

João Barros 01 de November de 2026 4 min de lectura

Este tutorial muestra cómo aplicar Data Masking en tablas de un Lakehouse en Microsoft Fabric para proteger columnas sensibles (p. ej.: números de tarjeta, NIF, correos electrónicos) sin alterar la fuente. Es útil para cumplir requisitos de seguridad, permitir informes seguros y reducir la exposición de datos en entornos de desarrollo y producción.

Prerequisitos

Cuenta con acceso a un workspace en Microsoft Fabric y permisos para gestionar Lakehouse.
Un Lakehouse con al menos una Delta Table que contenga columnas sensibles.
Permisos para crear Views y gestionar permisos (GRANT/REVOKE) en el Lakehouse.
Conocimientos básicos de SQL/Spark SQL y conceptos de seguridad de datos.

Paso 1: Identificar columnas sensibles y crear una tabla de ejemplo

Empiece por identificar qué columnas necesitan masking. Para probar, cree una tabla de ejemplo en el Lakehouse con datos sensibles. Aquí usamos Spark SQL en el Notebook o en el Query Editor del 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');

Paso 2: Concepto — por qué usar Views para Data Masking

Un enfoque común en Fabric es crear Views que aplican funciones de masking (substring, regexp_replace, CASE) en columnas sensibles. Mantiene la tabla original intacta y permite conceder permisos diferentes a la View y a la tabla. Esta técnica es sencilla y compatible con herramientas como Power BI y Warehouse.

Paso 3: Crear una View con reglas de Masking

Crear una View que sustituya partes sensibles por caracteres enmascarados. Ejemplo: mostrar solo los 4 últimos dígitos de la tarjeta, ocultar parte del NIF y del correo electrónico.

CREATE OR REPLACE VIEW default.vw_customers_masked AS
SELECT
  id,
  name,
  -- email: mostrar solo dominio y primera letra
  CONCAT(SUBSTRING(email, 1, 1), '***@', SPLIT(email, '@')[1]) AS email,
  -- nif: mantener últimos 2 dígitos
  CONCAT(REPEAT('*', LENGTH(nif)-2), SUBSTRING(nif, -2)) AS nif,
  -- card_number: mostrar solo últimos 4 dígitos
  CONCAT(REPEAT('*', LENGTH(card_number)-4), SUBSTRING(card_number, -4)) AS card_number
FROM default.customers_mask_test;

Paso 4: Probar la View y comparar con la tabla original

Ejecute queries en la View y en la tabla original para confirmar el masking. Verifique que la View devuelve datos enmascarados y que la tabla original continúa completa (solo para administradores).

-- Ver datos originales (solo para quien tenga permiso)
SELECT * FROM default.customers_mask_test;

-- Ver datos enmascarados (para usuarios finales)
SELECT * FROM default.vw_customers_masked;

Paso 5: Gestionar permisos — exponer solo la View a los usuarios

Para garantizar que los usuarios finales solo vean datos enmascarados, revoque el acceso directo a la tabla y conceda SELECT únicamente en la View. Use comandos SQL de control de acceso en el Lakehouse.

-- Revocar acceso directo a la tabla
REVOKE SELECT ON default.customers_mask_test FROM public;

-- Conceder solo acceso a la View a un grupo/role
GRANT SELECT ON default.vw_customers_masked TO analytics_readers;

Paso 6: Automatizar reglas con funciones reutilizables (opcional)

Si tiene varias tablas, cree funciones SQL para reutilizar la lógica de masking y mantener consistencia.

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 el resultado

Confirme que los usuarios en el role analytics_readers ven solo la View y que los datos aparecen enmascarados. Los administradores con acceso a la tabla original deben confirmar que los datos completos permanecen en la tabla base. Pruebe también la integración: conecte un informe Power BI al Lakehouse usando la View y verifique que los informes muestren datos enmascarados.

Conclusión

Aplicar Data Masking vía Views en el Lakehouse de Microsoft Fabric es una solución sencilla y eficaz para proteger columnas sensibles sin duplicar datos ni alterar la fuente. Próximos pasos: implementar masking dinámico por role, integrar con grupos de Azure AD y auditar accesos. Consejo: pruebe el masking en entornos de desarrollo antes de aplicarlo en producción y pregúntese: ¿qué columnas en su organización necesitan masking primero?