Seguridad (RLS)

La RLS (seguridad a nivel de fila) con Power BI se puede usar para restringir el acceso a los datos para determinados usuarios. Los filtros restringen el acceso a los datos a nivel de fila y se pueden definir filtros dentro de los roles.

La RLS permite:

• Definir filtros de carga de datos según el usuario que está visualizando el informe
• Crear diversos filtrados de datos en un mismo informe
• Restricción por perfil de usuario
• Restricción por rol (cargo/área)

Una de las ventajas de la RLS es tener un único informe y distribuirlo a varios usuarios o clientes, sin tener que crear un informe con datos filtrados para cada perfil de usuario, lo que reduce el mantenimiento de esos informes, ya que un único informe filtraría los resultados presentados de acuerdo con la persona que lo está visualizando.

En Power Embedded, ofrecemos soporte tanto para RLS (Row-Level Security) como para OLS (Object-Level Security).

A continuación, se presenta información para ayudar en la comprensión.

Cuando el informe tiene una o más reglas de RLS, es obligatorio asociarlas al usuario que está visualizando el informe, ya sea mediante RLS estático o dinámico; de lo contrario, no podrá visualizar los informes y se mostrará un mensaje como este:

Cómo administrar las reglas de seguridad en Power Embedded

Para asociar un usuario a una regla de RLS u OLS, tiene 3 formas de hacer esta configuración:

1. En la pantalla de Informes, busque el informe cuyas reglas de RLS desea administrar, haga clic en el botón Acciones y luego en el elemento Seguridad.
   
   Si el informe tiene RLS y este botón no aparece, ingrese a la página de Conjuntos de datos y haga clic en el botón Recargar.
   

1. En la página de Informes, busque el informe cuyas reglas de RLS desea administrar, haga clic en el botón Acciones y luego en el elemento Seguridad.
2. Aparecerá el nombre de los roles, y deberá asociar los usuarios a ese rol.

1. En la página de Conjuntos de datos, busque el conjunto de datos cuyas reglas de RLS desea administrar, haga clic en el botón Acciones y luego en el elemento Seguridad.

Seguridad estática

Para las empresas que necesitan o desean crear varias reglas de seguridad y asociar los usuarios con las reglas, sin necesidad de tener una tabla en el modelo con los usuarios y permisos, existe la seguridad estática, que es más simple de configurar, pero presenta peor rendimiento y es más difícil de administrar en cuanto a los permisos.

En este formato, visualizará la lista de los roles que existen en el modelo y podrá asociar los usuarios o grupos que serán filtrados por esa regla, haciendo clic en el botón de acciones.

Aquí hay una captura de las reglas creadas en Power BI Desktop. Existen dos o más reglas creadas en el modelo.
Esto significa que, si un usuario es asignado a una determinada regla, solo podrá visualizar los datos relacionados con el contexto definido por esa regla.

Al publicar el informe y acceder a “Acciones” > “Seguridad”, Power BI Embedded identifica automáticamente las reglas creadas y cargará la lista con esas reglas.

Después de seleccionar los usuarios incluidos en la RLS estática, haga clic en “Guardar”. El acceso mediante RLS se aplicará automáticamente a esos usuarios.

Aquí hay una captura de la regla creada en Power BI Desktop. Esto significa que si un usuario es asignado a la regla, solo podrá visualizar datos relacionados con esa regla.

Seguridad dinámica

Con la seguridad dinámica, puede definir uno o más roles y se aplicarán automáticamente a todos los usuarios que accedan al informe. Esta es la recomendación de buenas prácticas para una mejor administración de las reglas y un mejor rendimiento.

En este formato, el rol/función creado en Power BI Desktop recibirá el correo electrónico del usuario que está accediendo al informe (utilizando las funciones USERNAME() o USERPRINCIPALNAME()) y será responsable de realizar los filtros utilizando ese correo electrónico, con base en las reglas creadas.

En esta forma de aplicar los filtros automáticamente según el usuario, es necesario mantener en su modelo una tabla con los usuarios y permisos según la regla de RLS.

La siguiente tabla ejemplifica un modelo que contiene la información de correos electrónicos de los usuarios responsables de acceder a determinada información en el informe

Relación entre las tablas; es decir, su tabla estará vinculada a una tabla de hechos que contiene la información.

Al publicar este informe, la regla pasa a visualizarse en el portal; basta con seleccionarla y la regla se aplicará. A diferencia de la estática, aquí no se asigna un usuario a la regla, solo se selecciona la regla que se desea aplicar.

La regla de RLS se aplica utilizando la función USERPRINCIPALNAME() para identificar qué usuario ha iniciado sesión y realizar el filtrado también en las demás tablas; es decir, el usuario solo puede visualizar la información que le corresponde.

Prioridad de la RLS estática y dinámica

Para configurar correctamente las reglas de RLS en algunos escenarios, puede ser necesario utilizar RLS estática y dinámica al mismo tiempo.

Cómo Power Embedded prioriza estas reglas:

1. Verifica si el usuario que está visualizando el informe está asociado a alguna regla de RLS estática. Si lo está, envía esa regla y finaliza la validación.
2. Verifica si el usuario que está visualizando el informe está en algún grupo asociado a alguna regla de RLS estática. Si lo está, envía esa regla y finaliza la validación.
3. Verifica si alguna regla de RLS dinámica está marcada. Si lo está, envía esa regla y finaliza la validación.
4. Si no se cumplió ninguna de las condiciones anteriores, no se enviará ninguna regla de RLS y, probablemente, se producirá un error de RLS al intentar abrir el informe.

RLS con DirectQuery en Power BI

Si se encuentra con el siguiente error al intentar acceder al informe, es muy probable que la tabla que contiene la regla de RLS esté utilizando la conexión DirectQuery.

DirectQuery se utiliza ampliamente para acceder a datos en tiempo real. Sin embargo, es importante destacar que las reglas de Row-Level Security (RLS) no se aplican directamente a las tablas conectadas mediante DirectQuery en Power BI.

Esto sucede porque la configuración de estas reglas, cuando se utiliza DirectQuery, debe realizarse a nivel de la base de datos y no en Power BI.

Por ello, es importante cambiar la conexión de la tabla a los modos Import o Dual, en caso de que sea necesario aplicar estas reglas.

Para cambiar la conexión de la tabla, siga los pasos a continuación:

1. Abra Power BI Desktop.
2. Vaya a la “Vista de modelo“.
3. Seleccione la tabla que tiene reglas de RLS y está conectada mediante DirectQuery.
4. Acceda al menú “Avanzado”, como se muestra en la imagen.
5. Cambie el modo de almacenamiento a “Importar” o “Dual”.

Al seguir el paso a paso anterior, aparecerá en pantalla un aviso como el que se muestra en la imagen. Basta con hacer clic en “Aceptar” y continuar. Después de realizar este proceso, solo debe publicar el informe nuevamente.

Ahora podrá ver su información.

Limitaciones al utilizar RLS en informes Embedded

Al utilizar RLS (Row-Level Security) en informes incorporados (embedded), es importante considerar algunas limitaciones definidas por la API de generación de Embed Token.

De acuerdo con la documentación oficial de Microsoft, el parámetro roles, utilizado durante la generación del token de embed, es responsable de informar qué roles de RLS deben aplicarse al usuario que está accediendo al informe.

Según la documentación:

• Una identidad puede contener hasta 50 roles de RLS
• El nombre de un rol puede contener cualquier carácter, excepto ,
• El nombre del rol no puede superar los 50 caracteres

Esto significa que, al incorporar informes que utilizan RLS, el nombre del rol definido en el modelo no puede tener más de 50 caracteres, ya que este valor se envía en el momento de la generación del token de acceso.
El límite de 50 caracteres se aplica solo al nombre del rol, y no a la lógica o expresión utilizada en la regla de seguridad.

Por lo tanto, al crear roles de seguridad en Power BI Desktop, se recomienda mantener nombres cortos y objetivos, garantizando que la longitud no supere los 50 caracteres, para evitar problemas al generar el token de embed.

Documentación oficial de Microsoft: Embed Token - Permissions