DP-700: implementar seguridad de datos en tablas de Fabric

Voy a explicar cómo implementar seguridad de datos en tablas de Microsoft Fabric — en particular, Row-Level Security (RLS) y Column-Level Security (CLS). Esta competencia es relevante para el examen DP-700 porque demuestra control de acceso y protección de datos en una solución de analytics, y es esencial en la práctica para cumplir requisitos de privacidad y segregación de acceso.

Qué necesitas saber

Seguridad a nivel de datos significa restringir lo que cada usuario puede ver en datos analíticos. Los dos enfoques complementarios más comunes en Fabric son:

• Row-Level Security (RLS): limita las filas visibles en una tabla en función de reglas (por ejemplo, solo ver clientes de su propio territorio).
• Column-Level Security (CLS): oculta columnas sensibles (por ejemplo, números de tarjeta de crédito) a determinados roles o usuarios.

Ejemplo simple: una tabla Sales con columnas (SaleID, SalesPersonID, Amount, Cost) y una dimensión Users con (UserID, Role, Region). Pretendemos que un representante vea solo ventas de su Region (RLS) y que solo los managers vean la columna Cost (CLS).

Cómo funciona

En un entorno Fabric (OneLake / Lakehouse / Tables), hay dos opciones generales para aplicar estas seguridades:

• Aplicar políticas de seguridad en el propio objeto tabular (usando definiciones de seguridad o filtros en el servicio de tablas).
• Aplicar seguridad en la capa de exposición (por ejemplo, en una view SQL que filtra filas y elimina columnas, o en Power BI con RLS, aunque es preferible aplicar en el punto central de los datos para consistencia).

Flujo típico para RLS en 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: en entornos gestionados, las funciones y claims de identidad pueden extraerse de Azure AD; en muchos escenarios usas funciones o llaves de enlace entre la identidad y los datos.

En la práctica (paso a paso)

Paso 1 — Modela una tabla de dimensión de usuarios/seguridad: cada usuario o rol debe tener atributos necesarios (Role, Region, AllowedColumns).

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

Paso 2 — Implementa RLS usando una view o política incorporada:

1. Si tu entorno soporta políticas built-in de tabla, define la política RLS asociada a un rol/claim.
2. Si no, crea views parametrizadas que usan la identidad del usuario (o una función que resuelva su Region) para filtrar filas.

Paso 3 — Implementa CLS minimizando la superficie expuesta:

• Crea vistas sin las columnas sensibles para roles no autorizados.
• Asigna permisos solo sobre estas vistas, no sobre la tabla 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;

Paso 4 — Asigna permisos apropiados (Azure AD, roles en SQL/Workspace): asegura que los usuarios no tienen acceso directo a la tabla base.

Errores comunes

1) Conceder permisos a la tabla base: dar SELECT directo a la tabla anula todas las vistas y políticas; concede siempre solo sobre las vistas o usa políticas implementadas en el motor.

2) Asumir que RLS sustituye el cifrado: RLS filtra visibilidad, pero los datos sensibles pueden necesitar cifrado en reposo/y en tránsito y masking dinámico según requisitos de compliance.

3) Gestión de rendimiento descuidada: views con joins complejos o funciones de resolución de identidad en cada fila pueden degradar el rendimiento — prueba y optimiza con índices/particiones cuando proceda.

Cómo practicar

Configura un lab en Fabric/Workspace con una tabla de Sales y una tabla Users. Experimenta implementar RLS usando views y, si lo soporta tu entorno, políticas nativas de tabla. Prueba con cuentas de usuario diferentes (usa grupos de Azure AD) y valida que cada usuario ve solo lo esperado.

Para preparar el examen, usa el Practice Assessment OFICIAL y gratuito de Microsoft y la study guide oficial (ambos gratuitos). Estos recursos te ayudan a confirmar qué áreas se miden y a practicar con preguntas de ejemplo aprobadas por Microsoft.

En resumen

• RLS limita las filas visibles por usuario; CLS restringe columnas sensibles — ambos son complementarios.
• Implementa seguridad idealmente en el punto central (tabla/política o views controladas), no solo en la capa de reporte.
• Evita dar acceso directo a la tabla base; usa vistas o políticas y gestiona permisos vía Azure AD/roles.
• Prueba el rendimiento y considera medidas adicionales (masking, cifrado) según requisitos de compliance.