PL-300: cómo implementar seguridad a nivel de fila (RLS) en Power BI

Te enseñaré cómo implementar Row-Level Security (RLS) en Power BI — una competencia del dominio "Gestionar y proteger los recursos de Power BI" del examen PL-300. RLS es esencial para limitar los datos visibles por cada usuario y se evalúa con frecuencia tanto en escenarios prácticos del examen como en implementaciones empresariales.

Lo que necesitas saber

Row-Level Security (RLS) permite que restrinjas qué filas de una tabla puede ver cada usuario (o grupo) en un informe o conjunto de datos. Existen dos modos principales:

• Static RLS: defines roles con reglas estáticas (ej.: [Country] = "Portugal") en el modelo y luego asignas usuarios o grupos a esos roles en el servicio Power BI.
• Dynamic RLS: la regla depende de la identidad del usuario en el momento (por ejemplo, compara [UserEmail] con USERPRINCIPALNAME()). Permite gestionar permisos sin mapear explícitamente a cada usuario a un rol.

Ejemplo simple: tienes una tabla Sales con la columna Region. Quieres que el usuario solo vea ventas de su región. En Static RLS creas un rol RegionFilter con la expresión [Region] = "North". En Dynamic RLS, usas una tabla que mapea usuarios a regiones y filtras con USERPRINCIPALNAME().

Cómo funciona (paso a paso)

Sigue este proceso práctico para implementar RLS en una solución típica:

1. Preparar el modelo: garantiza que tienes una clave que conecta la tabla de hechos (ej.: Sales) con la dimensión que contiene la delegación de los permisos (ej.: Users o Regions). Ej.: Sales[RegionID] se relaciona con Regions[RegionID].

2. Crear una tabla de mapeo (para Dynamic RLS): crea una tabla Users con columnas [UserPrincipalName] y [RegionID]. Puedes mantenerla dentro del modelo o traerla desde una fuente.

3. Definir el rol RLS en Power BI Desktop:

   Modeling > Manage roles > Create > Role name: RegionRole -- Si es Static: Regions[RegionName] = "North"  -- Si es Dynamic: Regions[RegionID] IN VALUES(Users[RegionID])

   La expresión en el gestor de roles es una DAX que resulta verdadera para las filas permitidas.

4. Probar el rol en el Desktop: usa View as Roles (Modeling > View as) para simular un usuario o rol. Para Dynamic RLS usa la opción "Other user" e introduce el correo electrónico para probar el filtrado con USERPRINCIPALNAME().

5. Publicar y asignar usuarios en el servicio Power BI: publica el informe en un workspace en el servicio. En Datasets > Security selecciona el rol que creaste y añade usuarios o grupos (Azure AD) para Static RLS. Para Dynamic RLS no añades mapeos aquí: la regla usa la identidad del usuario cuando accede.

6. Probar en el servicio: usa la opción "Test as role" si está disponible, o pide a un usuario real con las credenciales apropiadas que valide la experiencia en el informe publicado.

En la práctica: ejemplo DAX para Dynamic RLS

Un patrón común es comparar el correo del usuario con la tabla de mapeo. Ejemplo de expresión en un rol:

-- Role: RegionalAccess CONTAINS(   Users,   Users[UserPrincipalName],   USERPRINCIPALNAME(),   Users[RegionID],   Regions[RegionID] )

Una alternativa más simple (cuando la relación está definida entre Users y Regions):

Users[UserPrincipalName] = USERPRINCIPALNAME()

Esta última asume que, a través de la relación, filtra todas las filas de la dimensión Regions y, por consiguiente, las filas de Sales relacionadas.

Errores comunes

• Asumir que RLS funciona sin relaciones correctas: si no hay una relación entre la tabla de mapeo y la tabla de hechos, el filtrado no se propaga.
• Usar USERPRINCIPALNAME() en el Desktop sin probar adecuadamente: en el Desktop el valor puede ser tu usuario; usa "View as" y la opción "Other user" para simular otros usuarios.
• Añadir usuarios al workspace en lugar de al rol (confusión): dar acceso al workspace no sustituye a RLS — puede dar acceso a informes, pero los datos siguen siendo filtrados por RLS si está configurada.

Cómo practicar

Practica creando tanto static como dynamic RLS en modelos de ejemplo. Usa conjuntos de datos con dimensión de usuarios y relaciones claras. Para preparación del examen, haz el Practice Assessment OFICIAL y gratuito de Microsoft y consulta la study guide oficial (también gratuita) — estos recursos ayudan a entender lo que mide el examen sin proporcionar preguntas reales.

En resumen

• RLS limita fila por fila lo que cada usuario ve; existe Static y Dynamic RLS.
• Dynamic RLS usa funciones DAX como USERPRINCIPALNAME() y una tabla de mapeo para evitar gestionar listas de usuarios manualmente.
• Relaciones correctas en el modelo son esenciales para que el RLS se propague a las tablas de hechos.
• Prueba siempre en el Desktop (View as) y en el servicio Power BI; en el servicio asigna usuarios a los roles para Static RLS.