DP-600: implementar roles de seguridad en modelos semánticos

Te voy a enseñar cómo implementar Row-Level Security (RLS) en modelos semánticos en el contexto de Power BI/Fabric. Esta competencia es esencial en el DP-600 porque garantiza que los usuarios solo ven los datos que les corresponden — un requisito frecuente en soluciones analíticas empresariales. La RLS evita exposiciones inadvertidas y permite cumplir normas de cumplimiento internas y externas.

Qué necesitas saber

Row-Level Security (RLS) restringe qué filas de datos puede acceder un usuario en un modelo semántico. En Power BI y en Fabric, la RLS se aplica a nivel del modelo (tabular) mediante roles que contienen filtros DAX o, en algunos escenarios, mapeos de usuarios. Existen dos modos principales:

• Static RLS: roles con reglas fijas (p. ej.: Sales[Country] = "Germany"). Útil cuando los grupos tienen restricciones inmutables — por ejemplo, un equipo financiero que solo ve datos de Alemania. Es sencillo de gestionar cuando el número de roles es reducido (p. ej. 5-10 regiones).
• Dynamic RLS: usa funciones DAX como USERPRINCIPALNAME() para aplicar filtros en función del usuario que accede. Esencial cuando los permisos dependen de la identidad del usuario o cuando tienes miles de usuarios diferentes. Permite mantener solo unos pocos roles (p. ej.: "RLS_Region") y usar un mapeo para determinar el alcance del usuario.

Ejemplo simple de filtro DAX para un role que limita la tabla Sales por el departamento del usuario (suponiendo una tabla Users con mapeo):

Sales[SalesRegion] IN VALUES(Users[Region])

Otra expresión dinámica común se basa en USERPRINCIPALNAME():

Users[UserPrincipalName] = USERPRINCIPALNAME()

La idea es vincular al usuario con su ámbito mediante relaciones en el modelo o expresiones DAX que consulten tablas de mapeo. Recuerda también las diferencias entre USERNAME() y USERPRINCIPALNAME() — esta última es más fiable en entornos Azure AD.

En la práctica

Pasos prácticos para implementar RLS en un modelo semántico en Power BI Desktop / Fabric Model:

1. Preparar mapeo de usuarios: crea una tabla Users (puede ser importada) con columnas: UserPrincipalName, Region, Department, RoleLevel. En escenarios reales puedes tener 10k-50k filas si el mapeo es por empleado. Alternativamente, usa un mapeo por grupo (Azure AD Group) para reducir la cardinalidad.

2. Establecer relaciones: en el modelo, vincula Users a tablas fact/dimension relevantes (p. ej.: Users[Region] → Sales[SalesRegion]). Usa relaciones de 1:* con dirección simple recomendable desde el lado Users hacia las facts. Verifica la dirección del filtro (single vs both) porque puede afectar al rendimiento y al comportamiento de los filtros.

3. Crear role dinámico: en Power BI Desktop ve a 'Modeling' → 'Manage Roles' y crea un nuevo role, por ejemplo "RLS_Region". Para la tabla Users o directamente en la tabla fact escribe una expresión DAX usando USERPRINCIPALNAME():

   Users[UserPrincipalName] = USERPRINCIPALNAME()

   o, si quieres filtrar por región vía relación:

   Sales[SalesRegion] IN VALUES(Users[Region])

   Si trabajas con UPNs que pueden variar entre mayúsculas y minúsculas, normalízalos con UPPER() o LOWER() en ambas partes del mapeo.

4. Probar roles localmente: usa la funcionalidad "View as" en Power BI Desktop para simular distintos usuarios o roles. Prueba con al menos 10 casos: administrador, 3 usuarios típicos, 3 que no tienen acceso (deben ver 0 filas) y 3 con acceso multirregión. Esto valida que los filtros funcionan antes de publicar.

5. Publicar y asignar usuarios: publica en el tenant de Fabric/Power BI Service. En el servicio, ve al dataset o modelo, abre 'Security' y asigna usuarios o grupos Azure AD a los roles definidos. Se recomienda usar grupos Azure AD (reduce la gestión) y evitar añadir manualmente a cientos de usuarios a un role.

6. Auditar y validar: verifica con cuentas de usuario reales (o grupos) y utiliza logs de auditoría y Usage Metrics para confirmar que los accesos son correctos. En un entorno con 5k informes, configurar alertas de uso anómalo ayuda a detectar errores de RLS.

Errores comunes

• Suponer que la RLS funciona sin relaciones correctas: si la tabla Users no está relacionada correctamente con la fact table, los filtros no se aplicarán como se espera. Por ejemplo, una relación incorrecta puede resultar en 100% de los datos visibles en vez de 0%.
• Usar USERPRINCIPALNAME() sin asegurar el formato correcto: en entornos con identidades federadas, el valor de USERPRINCIPALNAME() puede no coincidir exactamente con la columna UserPrincipalName; normaliza mayúsculas/minúsculas y formatos (upn vs email) en el mapeo.
• Probar solo con administradores: los administradores suelen ver más datos; prueba con cuentas normales o usa la funcionalidad "View as" para simular usuarios reales. Además, prueba medidas complejas (time intelligence) para garantizar que el contexto de filtro no rompe cálculos.
• Descuidar el rendimiento: filtros complejos en modelos con millones de filas pueden reducir el rendimiento. Usa índices en el backend cuando sea posible, simplifica expresiones DAX y evalúa DirectQuery vs Import.

Cómo practicar

Practica implementando roles en distintos escenarios: por región, por línea de negocio y con herencia mediante jerarquías (p. ej.: país → región → tienda). Crea un dataset ficticio con tablas Users (5k filas), Sales (1M filas), Product y Region. Implementa un role dinámico y otro estático, prueba queries y mide tiempo de respuesta (p. ej. 200 ms vs 2s tras aplicar RLS).

Herramientas útiles: DAX Studio para analizar queries y SQL Profiler para diagnosticar DirectQuery. Para práctica oficial, usa el Practice Assessment OFICIAL y gratuito de Microsoft y consulta la study guide gratuita de la certificación DP-600 en la documentación de Microsoft — ambos son recursos oficiales y gratuitos que recomiendo para la preparación práctica y la revisión de las skills measured.

En resumen

• La RLS protege datos a nivel de filas; puede ser estática o dinámica.
• Los modelos necesitan tablas de mapeo y relaciones correctas para que la RLS funcione.
• USERPRINCIPALNAME() es la función clave para RLS dinámica, pero normaliza identidades.
• Probar localmente y en el servicio es crucial; usa grupos Azure AD para gestionar asignaciones a gran escala.