RLS Power BI: cómo garantizar que cada usuario vea solo sus datos

Toda empresa que distribuye reportes de Power BI llega a la misma pregunta: ¿cómo mostrar el mismo panel a la dirección, a cada gerente regional y a cada vendedor sin que uno vea los números del otro? Copiar el reporte para cada público parece rápido, pero multiplica el mantenimiento y el riesgo de que alguien reciba el archivo equivocado.

La respuesta es la RLS (row-level security, o seguridad a nivel de fila). Con ella, un único modelo y un único reporte filtran los datos según el usuario que inició sesión. Para la mayoría de las empresas, el mejor camino es la RLS dinámica, con una tabla de permisos y la función USERPRINCIPALNAME.

En esta guía verás cómo funciona la RLS Power BI, la diferencia entre estática y dinámica, cómo configurarla y probarla, qué cambia en reportes embedded, los errores más comunes y por qué vale la pena tener una app para gestionar quién ve qué.

¿Qué es la RLS en Power BI y cómo funciona?

La RLS es una capa de seguridad aplicada al modelo semántico, la parte de Power BI que guarda tablas, relaciones y medidas. Creas roles y, para cada uno, escribes una regla en DAX, el lenguaje de fórmulas de Power BI, que indica qué filas de una tabla puede ver ese rol. El filtro se propaga por las relaciones: si el rol solo ve la sucursal de Campinas en la tabla de sucursales, las ventas, metas e inventario también quedan restringidos a Campinas.

Los roles se crean en Power BI Desktop, y los usuarios o grupos se asignan a ellos en el servicio de Power BI. Un detalle importante: la RLS solo restringe a quien tiene permiso de Visor. Los administradores, miembros y colaboradores del workspace ven todos los datos, porque pueden editar el contenido.

RLS estática o dinámica: ¿cuál elegir?

RLS estática

En la RLS estática, cada rol tiene un valor fijo en la regla, como Región igual a Sur. Funciona bien cuando hay pocos segmentos y casi no cambian. El problema aparece con el crecimiento: 30 sucursales se convierten en 30 roles, y cada cambio exige editar y volver a publicar el modelo. En operaciones con muchos clientes, sucursales o vendedores, la estática se vuelve mantenimiento manual.

RLS dinámica con USERPRINCIPALNAME

En la RLS dinámica, existe un único rol y una tabla de permisos que vincula el correo de cada usuario con lo que puede ver. La regla usa USERPRINCIPALNAME, una función DAX que devuelve el nombre de inicio de sesión del usuario en Microsoft Entra ID, normalmente el correo corporativo. Power BI compara ese inicio de sesión con la tabla y mantiene solo las filas permitidas. Cuando alguien cambia de área, modificas una fila en la tabla, no el modelo.

Una tabla de permisos simple suele tener:

• El correo del usuario, exactamente como aparece al iniciar sesión.
• El código del segmento permitido: sucursal, región, centro de costo, cartera de clientes o país.
• Una fila por combinación de usuario y segmento, para quien accede a más de una sucursal.
• Un indicador de acceso total para la dirección, o un rol separado sin filtro.

¿Cómo configurar y probar la RLS dinámica?

El paso a paso a continuación sirve para la mayoría de los modelos en modo importación:

1. Crea la tabla de permisos en una fuente controlada, como una base de datos, con el correo y el código del segmento.
2. Carga la tabla en el modelo y ocúltala. Evita conectarla al resto del modelo con una relación bidireccional.
3. En Modelado, Administrar roles, crea un rol con un filtro en la dimensión (por ejemplo, Sucursal) que mantenga solo los códigos asociados a USERPRINCIPALNAME() en la tabla de permisos.
4. Trata las excepciones: acceso total para la dirección y qué pasa con quien no está en la tabla. El valor seguro por defecto es no ver nada.
5. Prueba en Desktop con Ver como, simulando usuarios reales.
6. Publica y, en la opción Seguridad del modelo semántico en el servicio, agrega usuarios o grupos de Microsoft Entra ID al rol.
7. Da a los consumidores permiso de Visor o distribuye el contenido mediante una app de Power BI, para que se aplique la RLS.
8. Programa la actualización del modelo: en modo importación, los cambios en la tabla de permisos solo valen después del refresh.

Cómo probar con Ver como

En Power BI Desktop, la opción Ver como, en la pestaña Modelado, permite elegir el rol e indicar otro usuario, simulando el resultado de USERPRINCIPALNAME. En el servicio, la misma prueba está en la Seguridad del modelo semántico, en Probar como rol. Arma un guion con casos reales: un usuario con una sucursal, uno con varias, un director y un correo que no está en la tabla. Verifica que los totales coincidan con lo esperado. Las medidas que usan ALL siguen respetando la RLS, así que un porcentaje sobre el total muestra el total de lo que el usuario puede ver, no el de la empresa.

¿Cómo funciona la RLS en reportes embedded?

Cuando el reporte se inserta en un portal o sistema con Power BI Embedded, hay dos escenarios. Si los usuarios son de tu organización e inician sesión con su cuenta de Microsoft Entra ID, la RLS funciona como en el servicio. Si el reporte se muestra a clientes o socios que no tienen cuenta en tu organización, la aplicación se autentica en Power BI y genera un token de inserción con una identidad efectiva: el nombre del usuario y los roles que se le aplican.

En ese caso, USERPRINCIPALNAME devuelve el nombre enviado por la aplicación, que puede ser un correo o un código de cliente. La regla de oro es que esa identidad se defina en el servidor, a partir del inicio de sesión de tu sistema, y nunca en el navegador. Si estás decidiendo entre insertar Power BI o construir un panel propio, mira cuándo usar un dashboard en HTML/CSS o Power BI.

RLS y seguridad a nivel de objeto: ¿cuál es la diferencia?

La RLS restringe filas; la seguridad a nivel de objeto (OLS, object-level security) oculta tablas o columnas enteras a determinados roles. Es útil cuando el problema no es qué sucursal ve la persona, sino qué información: costo, margen o salario, por ejemplo. Para quien no tiene acceso, la columna simplemente no existe en el modelo, y los visuales que dependen de ella muestran un error. La OLS suele configurarse con herramientas externas, como Tabular Editor, y puede combinarse con la RLS en el mismo modelo.

¿Cuáles son los errores más comunes con RLS?

• Relaciones bidireccionales repartidas por el modelo. Los filtros de seguridad se propagan por caminos inesperados, pueden ocultar o liberar datos indebidamente y hacen más lento el reporte.
• Un rol por cliente, sucursal o persona. Decenas de roles se vuelven mantenimiento manual y aumentan la probabilidad de que alguien quede en el rol equivocado.
• Permisos controlados en una hoja de cálculo suelta. Sin dueño, sin historial y sin validación, un correo mal escrito quita el acceso a alguien o da acceso a quien no debería tenerlo.
• Usar filtros de página o segmentadores para ocultar datos. Eso no es seguridad: el usuario puede cambiar el filtro.
• Creer que la RLS vale para todos. Quien es miembro, colaborador o administrador del workspace ve todo.
• Probar solo con tu propio usuario. El caso que se filtra suele ser justamente el que nadie simuló.

¿Por qué usar una app para gestionar los accesos?

Con la RLS dinámica, la seguridad pasa a depender de la calidad de la tabla de permisos. Por eso, en lugar de una hoja de cálculo, conviene tener una pequeña aplicación de registro, un CRUD (crear, consultar, modificar y eliminar registros), donde el área de negocio otorga y revoca accesos sin abrir un ticket con TI.

Una buena app de accesos tiene inicio de sesión único con Microsoft Entra ID, una lista de segmentos tomada del propio modelo (sucursales, países, carteras), aprobación cuando hace falta e historial de quién otorgó qué y cuándo, y graba los datos en una base que Power BI lee. Fue el camino en MasterSense: las ventas de 4 países, en 3 idiomas, están en un único BI en Microsoft Fabric con datos de SAP HANA, y una app de accesos define quién ve qué. Este tipo de aplicación forma parte de nuestros sistemas a medida, y hay un registro interactivo con control de acceso en nuestra galería de ejemplos.

Cómo ayuda Wolkee

Wolkee diseña modelos de Power BI con RLS desde el inicio: tabla de permisos, reglas en DAX, pruebas por perfil y, cuando tiene sentido, una app de gestión de accesos integrada con Microsoft Entra ID. Son 9 años en el mercado, más de 500 entregas y proyectos en 8 países, con dashboards y BI para finanzas, ventas, operaciones y contact center.

Si necesitas revisar la seguridad de tus reportes o empezar un modelo nuevo, agenda un diagnóstico gratuito de 30 minutos. Te mostramos un prototipo funcional antes del contrato y respondemos en hasta 1 día hábil.

Preguntas frecuentes

¿La RLS en Power BI requiere licencia Premium?

No. La RLS no depende de una licencia específica: se define en Power BI Desktop y se aplica en el servicio. Lo que cambia es el acceso al contenido. En workspaces compartidos comunes, quien visualiza necesita licencia Pro o Premium por usuario; en capacidades Premium o Fabric del tamaño adecuado, los usuarios con licencia gratuita también pueden visualizar. Confirma las reglas vigentes con Microsoft.

¿La RLS funciona con DirectQuery?

Sí. La RLS funciona tanto en modo importación como en DirectQuery. En DirectQuery, los filtros de seguridad se traducen en las consultas enviadas a la fuente, por lo que el rendimiento también depende de la base de datos. Si el reporte usa una conexión en vivo con un modelo de Analysis Services, los roles se definen en ese modelo y no en el archivo de Power BI.

¿Los usuarios con RLS pueden exportar datos que no deberían ver?

No. La exportación respeta la RLS: el usuario exporta solo las filas que puede ver en el modelo. El punto de atención es otro: si tiene permiso de edición en el workspace, la RLS no se aplica y ve y exporta todo. También conviene revisar, en la configuración del inquilino y del reporte, quién puede exportar y en qué formatos.

¿Cuál es la diferencia entre USERNAME y USERPRINCIPALNAME?

Ambas funciones identifican al usuario conectado, pero pueden devolver formatos distintos. En Power BI Desktop, USERNAME suele devolver dominio y usuario, mientras que USERPRINCIPALNAME devuelve el inicio de sesión en formato de correo. En el servicio, ambas devuelven el nombre principal del usuario. Por coherencia entre entornos, la recomendación general es usar USERPRINCIPALNAME en la regla y en la tabla de permisos.