DP-700: cómo implementar políticas de acceso row-level en Fabric

Voy a enseñar cómo implementar Row-Level Security (RLS) en tablas de Microsoft Fabric. Esta competencia es importante para el examen DP-700 porque demuestra control de acceso a datos en entornos analytics, y en la práctica protege registros sensibles garantizando que los usuarios ven solo lo que se les permite.

Qué necesitas saber

Row-Level Security (RLS) limita las filas que un usuario puede consultar en una tabla, en función de su identidad o de reglas. En Fabric (por ejemplo en tablas de Power BI o en tablas Delta en un workspace de Data Warehouse/Table), RLS puede aplicarse mediante roles y filtros que usan columnas como UserID, DepartmentID o atributos de sesión.

Ejemplo conceptual: tienes una tabla Sales con una columna Region. Si un analista pertenece solo a la región "North", RLS asegura que sus queries solo devuelven filas donde Region = 'North'.

Cómo funciona

En términos generales, existen tres componentes en RLS:

• Identidad del usuario: autenticada vía Azure AD.
• Definición de la regla: un filtro que expresa qué filas son visibles.
• Aplicación del filtro: mecanismo que inyecta el filtro en las queries en tiempo de ejecución.

En las implementaciones comunes en Fabric puedes usar dos enfoques principales:

• RLS nativa en el modelo Power BI (roles con DAX) — aplicable cuando el modelo está sirviendo informes Power BI dentro de Fabric o Power BI Service.
• RLS a nivel de tabla/Delta con políticas de seguridad en OneLake / Data Warehouse (usando permisos del SQL endpoint u object-level policies) — aplicable para escenarios donde múltiples herramientas acceden a las tablas.

En la práctica

Voy a describir un ejemplo práctico con dos opciones: (A) RLS en modelo Power BI usando roles DAX; (B) RLS en tablas gestionadas usando la columna de seguridad y filtros en el SQL endpoint. Los pasos son simplificados y didácticos.

A — RLS en el modelo Power BI (roles DAX)

1. Prepara la tabla: garantiza una columna que identifique la pertenencia, ej.: UserEmail o RegionID.
2. En Power BI Desktop (o en el Model Designer en Fabric), crea un role: Model > Manage Roles.
3. Definir la expresión DAX para el role. Ejemplo para filtrar por email del usuario actual:

   [UserEmail] = USERPRINCIPALNAME()

4. Prueba el role usando View As Roles para simular distintos usuarios.
5. Publica el modelo a Fabric/Power BI Service. En el servicio, asigna usuarios a los roles si es necesario (o usa la expresión dinámica USERPRINCIPALNAME para evitar asignaciones manuales).

B — RLS a nivel de tablas/SQL endpoint

1. Incluye una columna de control, ej.: AllowedDepartmentID, y mantiene una tabla de mapping UserDepartment(UserPrincipalName, DepartmentID).
2. Crea una view segura que une los datos con el mapping y aplica el filtro. Ejemplo en SQL del 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: la función que devuelve el usuario puede variar según el endpoint; en entornos Fabric/SQL se usa la función adecuada para la identidad del usuario.
3. Concede acceso de los usuarios solo a la view v_Sales_Secure y niega acceso directo a la tabla Sales.
4. Configura roles/privileges en el workspace para que aplicaciones y usuarios consulten solo la view.

Buenas prácticas

• Preferir filtros dinámicos (ej.: USERPRINCIPALNAME()) para evitar gestión manual de roles.
• Mantener mappings de identidad actualizados (la integración con Azure AD simplifica esto).
• Probar RLS con cuentas reales o herramientas de simulación.

Errores comunes

• Asumir que RLS sustituye permisos de objeto: RLS filtra filas, pero todavía necesitas garantizar que los usuarios no puedan acceder a tablas en bruto directamente.
• Usar columnas con valores NULL para controlar acceso sin un tratamiento adecuado — NULL puede hacer que los filtros sean ineficaces y abrir fugas de datos.
• Depender únicamente de asignaciones manuales de roles en lugar de expresiones dinámicas; la gestión escala mal en organizaciones grandes.

Cómo practicar

Practica implementando ambos métodos en un entorno Fabric trial o en una suscripción de entrenamiento. Crea datasets con columnas de control y prueba con distintas identidades.

Para preparar el examen, usa el Practice Assessment OFICIAL de Microsoft (es gratuito) y consulta la Study Guide oficial (gratuita) para DP-700 — estos recursos te ayudan a validar conocimientos sin recurrir a material prohibido.

En resumen

• RLS controla qué filas puede ver cada usuario — esencial para proteger datos sensibles en analytics.
• Puede implementarse en el modelo Power BI (roles DAX) o a nivel de tabla/SQL endpoint (views seguras y mapeos).
• Prueba siempre con identidades reales y evita configuraciones que permitan acceso directo a las tablas subyacentes.
• Usa los recursos oficiales de Microsoft (Practice Assessment y Study Guide) para practicar de forma correcta y gratuita.