RLS en Power BI: seguridad por filas estática, dinámica y validación en el servicio
La seguridad por filas (RLS) no es una característica estética ni una forma de simplificar la interfaz para el usuario final. Es un mecanismo de control de acceso que garantiza que un usuario solo pueda consultar los datos para los que tiene autorización legal o de negocio. En proyectos de gran envergadura, el RLS es la diferencia entre un despliegue exitoso y una brecha de información crítica.
Muchos analistas cometen el error de aplicar filtros visuales o segmentadores pensando que eso protege los datos. Si un usuario tiene permisos de edición o acceso al modelo semántico, cualquier filtro visual es fácilmente eludible. El RLS actúa a nivel de motor de datos (VertiPaq), inyectando una cláusula de filtrado invisible en cada consulta DAX que se ejecuta contra el modelo.
En este artículo abordamos cómo pasar de modelos estáticos rígidos a sistemas dinámicos escalables, analizando el impacto en el rendimiento y los riesgos de una validación incompleta. Si trabajas en entornos complejos como Microsoft Fabric, entender estas bases es fundamental, tal como explicamos en nuestro artículo sobre Seguridad en Microsoft Fabric: Roles, Workspaces y Permisos sin Agujeros.
RLS Estático: Cuándo la sencillez se vuelve un problema
El RLS estático consiste en crear roles específicos en Power BI Desktop (p. ej., «Delegación Norte», «Delegación Sur») y asignarles un filtro DAX fijo en una tabla de dimensiones. Es la solución más rápida para modelos con pocos usuarios o regiones geográficas estables que no cambian con frecuencia.
Para implementarlo, definimos una expresión booleana en la tabla que queremos filtrar. Por ejemplo, en la tabla Sucursal:
[Region] = "Norte"El problema de este enfoque es la escalabilidad. Si tu empresa crece a 50 delegaciones, tendrás que crear 50 roles manualmente, publicarlos y luego asignar a cada usuario a su rol correspondiente en el servicio de Power BI. Cada vez que se cree una nueva oficina, el informe debe ser modificado y republicado. En consultoría, desaconsejamos este método para cualquier escenario que prevea un crecimiento orgánico del número de perfiles de acceso.
RLS Dinámico: Escalando con USERPRINCIPALNAME
La seguridad dinámica utiliza el contexto de identidad del usuario que ha iniciado sesión para filtrar los datos. La función clave aquí es USERPRINCIPALNAME(), que devuelve el correo electrónico del usuario activo (ej. juan.perez@empresa.com).
Para que esto funcione, necesitamos una tabla de seguridad en nuestro modelo (frecuentemente llamada SeguridadUsuarios o UserMapping) que relacione los correos electrónicos con los atributos de filtrado, como el ID de tienda, el departamento o el código de país. Una estructura típica sería:
- UsuarioEmail: juan.perez@empresa.com
- TiendaID: 101
Implementación del filtro dinámico
Una vez que tenemos la tabla de seguridad relacionada con nuestras dimensiones, el rol DAX se reduce a una única línea aplicada sobre la tabla de seguridad:
-- Filtro aplicado en la tabla 'SeguridadUsuarios'
[UsuarioEmail] = USERPRINCIPALNAME()Gracias a la propagación de filtros, al filtrar la tabla de seguridad por el correo del usuario, este filtro viajará a través de la relación hasta la tabla de Ventas o Presupuesto. Aquí es vital haber configurado correctamente las Relaciones, dirección del filtro cruzado y ambigüedad en Power BI. En muchos casos, para que el RLS funcione desde una tabla de seguridad hacia una dimensión, necesitaremos activar la dirección del filtro cruzado en ambos sentidos (Both) o usar esquemas en estrella donde la seguridad cuelga directamente de la dimensión.
El reto de las jerarquías y los mánager
Un escenario habitual en retail o industria es que un mánager deba ver los datos de todas sus tiendas asignadas, mientras que un dependiente solo vea los de la suya. Si usamos una relación simple, el mánager tendría múltiples entradas en nuestra tabla de seguridad.
Si la jerarquía es profunda (director regional > jefe de zona > director de tienda), el RLS puede complicarse. En estos casos, solemos emplear funciones de jerarquía en DAX como PATH, PATHCONTAINS y PATHITEM para aplanar la estructura organizativa y permitir que el filtro se propague hacia abajo en el organigrama.
| Escenario | Tipo de RLS | Complejidad DAX | Mantenimiento |
|---|---|---|---|
| Pocos departamentos fijos | Estático | Muy baja | Manual y alto |
| Muchos usuarios por región | Dinámico Simple | Baja | Automatizado (via tabla) |
| Estructuras jerárquicas | Dinámico Jerárquico | Media/Alta | Automatizado |
| Multisociedad compleja | Dinámico con Bridge | Alta | Centralizado |
Desktop frente a Servicio: El abismo de la validación
Uno de los errores más frecuentes que veo en proyectos es dar por válida la seguridad solo tras probarla en Power BI Desktop con la opción «Ver como roles». Esta prueba es necesaria pero insuficiente.
Por qué «Ver como» en Desktop puede engañarte
- Contexto de administrador: En Desktop, tú eres el autor. El motor de Power BI simula el filtro, pero no replica las restricciones de los espacios de trabajo.
- Permisos de Workspace: El RLS no se aplica a los usuarios que tienen permisos de Administrador, Miembro o Contribuyente (Member/Contributor) en el Workspace donde reside el informe. Solo se aplica a los usuarios con rol de Visor (Viewer). Si intentas probar el RLS con un compañero que es «Colaborador», él verá todo, independientemente de lo que diga el RLS.
- Identidades externas: Probar con
USERPRINCIPALNAME()requiere que el correo coincida exactamente con el UPN de Azure AD. A veces hay discrepancias entre el alias del correo y el UPN real, lo que rompe el filtro dinámico en producción pero no en tus pruebas locales.
Para validar correctamente, debes publicar el informe, ir a la configuración del Modelo Semántico (Semantic Model), entrar en la sección de Seguridad y usar la opción «Probar como rol» desde el propio servicio de Power BI. Esto abrirá una instancia del informe bajo la identidad real de la nube.
Impacto en el rendimiento
El RLS no es gratuito en términos de computación. Cada vez que aplicas un filtro RLS, el motor de Power BI debe evaluar esa expresión antes de ejecutar cualquier medida DAX. Si el filtro RLS es complejo (por ejemplo, un LOOKUPVALUE pesado o filtros sobre tablas de hechos con millones de filas), el rendimiento se resentirá.
Para optimizarlo, sigue estas pautas:
- Aplica el RLS en las tablas de dimensiones más pequeñas, nunca en las tablas de hechos si puedes evitarlo.
- Asegúrate de que las columnas involucradas en el filtro RLS están optimizadas. Consulta nuestra guía sobre Optimización de Modelos Semánticos en Power BI: VertiPaq & Storage Engine.
- Evita el uso de filtrado bidireccional innecesario. Si puedes rediseñar el modelo para que la seguridad fluya en una sola dirección, el motor lo agradecerá.
Checklist para un RLS robusto
- Confirmar que todos los usuarios finales tienen el rol de «Visor» (Viewer) en el Workspace.
- Verificar que la tabla de seguridad no tiene duplicados inesperados que puedan causar errores de ambigüedad.
- Utilizar
USERPRINCIPALNAME()en lugar deUSERNAME()para garantizar la compatibilidad con el inicio de sesión de Power BI Service. - Documentar el comportamiento del RLS para los casos de usuarios que no figuran en la tabla de seguridad (por defecto, no verán nada).
- Realizar una auditoría de rendimiento mediante el Performance Analyzer para medir el impacto del rol en las visualizaciones más críticas.
Preguntas frecuentes
¿Puedo aplicar RLS si uso DirectQuery?
Sí, pero con matices. El RLS se puede definir en Power BI o delegarse al origen de datos (p. ej., SQL Server o Snowflake) mediante el SSO (Single Sign-On). Si lo defines en Power BI, el motor traducirá tus reglas DAX a cláusulas WHERE en SQL, lo que puede afectar al rendimiento de la base de datos de origen.
¿Qué pasa si un usuario pertenece a varios roles?
En Power BI, los roles son aditivos. Si el Rol A le permite ver la delegación Norte y el Rol B la delegación Sur, el usuario verá ambas. El RLS aplica un operador lógico OR entre los filtros de los distintos roles asignados a una misma persona.
¿Puedo ocultar columnas específicas con RLS?
No directamente. El RLS (Row-Level Security) filtra filas. Para ocultar columnas basándose en el usuario, necesitas OLS (Object-Level Security), que se configura mediante herramientas externas como Tabular Editor. El OLS es más restrictivo: si un visual intenta usar una columna oculta para un usuario, el visual completo dará error para ese usuario.
¿Cómo gestionar usuarios que deben verlo todo?
La forma más limpia es no asignarles ningún rol de RLS en el servicio. Si el modelo tiene RLS definido, pero un usuario no está asignado a ningún rol, su comportamiento dependerá de sus permisos en el Workspace. Si es Administrador, verá todo. En modelos dinámicos, solemos incluir una lógica en DAX que detecte si el usuario tiene un perfil de «Superusuario» en la tabla de seguridad para saltar el filtro.
Implementar seguridad por filas requiere rigor técnico y una comprensión clara de cómo crear tu primera medida en DAX y cómo estas interactúan con el contexto de filtro. No te limites a la teoría; despliega, valida en el servicio y monitoriza el rendimiento.