"Row-Level Security (RLS): gestión corporativa de permisos en Power BI"

«El director general debe ver todas las ventas; los directores de zona, solo la suya; los comerciales, solo sus clientes.» Esa necesidad se cubre con la función de Row-Level Security (RLS) de Power BI. Bien planteada, permite gestionar decenas de niveles de permiso con un único informe y un único conjunto de datos; mal planteada, abre un agujero de seguridad y degrada el rendimiento. En este artículo abordamos en detalle el RLS estático y el dinámico, el uso de USERPRINCIPALNAME y la práctica real.

01. ¿Qué es el RLS y qué resuelve?

Row-Level Security aplica filtros al modelo de datos para que un mismo informe muestre a cada usuario un conjunto de filas distinto. En lugar de duplicar diez informes distintos, se monta uno solo y se separan roles y filtros.

El RLS trabaja en dos capas:

• Capa de modelo: qué filas ve cada rol se define con filtros DAX
• Capa de servicio: qué usuario está asignado a qué rol se gestiona en Power BI Service

Si esas dos capas no se conectan bien, el usuario o no ve ningún dato o accede a datos que no le corresponden.

02. RLS estático: sencillo pero no escala

En el RLS estático se define a mano un filtro DAX para cada rol. Por ejemplo:

• Rol «Norte»: [Región] = "Norte"
• Rol «Levante»: [Región] = "Levante"
• Rol «Distribuidor Madrid»: [Región] = "Centro" && [Ciudad] = "Madrid"

Este enfoque funciona con pocos roles (de dos a cinco), pero con más de veinte su gestión se vuelve un infierno. Cada vez que se añade una región hay que actualizar el modelo y volver a publicarlo.

03. RLS dinámico: el enfoque escalable y correcto

En el RLS dinámico se define un único rol y el filtro trabaja según quién haya iniciado sesión. La función USERPRINCIPALNAME() devuelve el correo del usuario conectado, y ese valor se cruza con una tabla de seguridad llamada, por ejemplo, «Usuarios»:

• Tabla Usuarios: [Correo], [Nombre], [Región], [Código de distribuidor], [Rol]
• Filtro DAX en la dimensión Región: [Región] IN CALCULATETABLE(VALUES(Usuarios[Región]), Usuarios[Correo] = USERPRINCIPALNAME())

Cuando se incorpora un usuario nuevo no se toca el modelo: basta con añadir una fila a la tabla Usuarios.

04. Diseño de la tabla de seguridad

El corazón del RLS dinámico es la tabla de seguridad. Una tabla bien diseñada:

• Muestra con claridad la relación usuario-acceso (un usuario puede acceder a varias regiones)
• Se puede relacionar con las dimensiones principales
• Es fácil de mantener (con origen en Excel, SharePoint o SQL)
• Admite jerarquía de roles (director general = todas las regiones)

La práctica habitual para el rol de dirección general: un asterisco en la tabla de seguridad o un campo de filtro vacío, y en DAX la lógica de «si es asterisco, se ve todo».

05. Proceso de prueba y validación

Después de aplicar el RLS es peligroso avanzar dando por hecho que «ya está publicado, funcionará». Pasos de prueba:

• Vista previa por rol con la función «Ver como roles» de Power BI Desktop
• Prueba real en Service iniciando sesión con distintas cuentas de correo
• Comprobar que el total del informe cambia según el usuario
• Comprobar que se muestran cero filas si el usuario filtra por una dimensión fuera de su permiso
• Medir el impacto en el rendimiento (una consulta con RLS puede ser entre un 10% y un 30% más lenta)

06. Diferencia con Object-Level Security (OLS)

El RLS oculta filas, pero todas las columnas siguen visibles. En algunos escenarios hace falta ocultar columnas: por ejemplo, que solo Recursos Humanos vea la columna de salario en una tabla de nóminas. Para eso se usa Object-Level Security (OLS).

El OLS se define con una herramienta externa como Tabular Editor; Power BI Desktop todavía no tiene interfaz para ello. En escenarios corporativos se usan juntos: permisos por filas más ocultación por rol de las columnas sensibles.

07. Trampas habituales

Errores frecuentes al implantar RLS:

• Que el resultado de USERPRINCIPALNAME no coincida exactamente con el correo de la tabla Usuarios (mayúsculas, espacios)
• Conectar la tabla de seguridad con una relación bidireccional: el rendimiento se hunde
• Publicar sin haber probado el RLS en un modelo compuesto (mezcla de DirectQuery e importación)
• Olvidar la exportación a Excel: los datos exportados desde el informe respetan el filtro, pero el acceso directo del equipo técnico a la base de datos deja el RLS fuera de juego
• No volver a definir el RLS en los informes de plantilla después de publicarlos en Service