Power BI OLS (Seguridad a nivel de objeto)en el Cabo San Lucas M365 Friday

El pasado Viernes 12 de Noviembre impartí una sesión en el evento online M365 Friday Cabo San Lucas sobre OLS (Object Level Security) en Power BI. Antes de nada me gustaría agradecer a sponsor y organizadores del evento que hayan contado conmigo para esta edición, !ha sido todo un honor poder participar!

En esta sesión realizamos 2 demos de OLS, en este post veremos la primera de ellas y en un segundo post comentaremos la segunda demo.

¿Qué es la seguridad OLS en Power BI?

OLS se refiere a a Object Level Security, es decir, seguridad a nivel de objeto. El problema que surgió al anunciarse esta funcionalidad es que el concepto “objeto” es muy genérico y llevó a mucha gente a malinterpretar el alcance de esta seguridad.

Cuando se habla de objeto se refiere a objetos del modelo:

• Tablas
• Campos
• Medidas

NO afecta a objetos visuales del informe:

• Visuales
• Botones
• Pestañas

Por lo tanto, podremos restringir que ciertos usuarios vean algunas tablas, campos o medidas, pero no podremos ocultar pestañas del informe, o gráficos completos.

Aparte, hay que destacar que para implementar OLS es necesaria una herramienta externa llamada Tabular Editor instalada en vuestro equipo. Os dejo este link para descargaros e instalar la versión gratuita de esta herramienta.

Diferencias entre Seguridad OLS y RLS

Antes de incluir seguridad OLS en Power BI, ya existía la seguridad RLS (Row Level Security) o seguridad a nivel de registro. En el caso de RLS, en vez de restringir el acceso a objetos, el sistema filtra registros que no pueden ser vistos por ciertos usuarios. Con RLS podemos crear un informe de Ventas y conseguir que cada comercial vea sólo sus ventas al consultarlo.

A continuación, os presento las principales diferencias y similitudes entre OLS y RLS en la siguiente tabla resumen:

¿Cómo implementar la seguridad OLS en Power BI?

Creación de los Roles de Seguridad

Lo primero que debemos hacer es crear los Roles de Seguridad que queramos configurar. Para ello, en Power BI Desktop debemos ir a Modelado>Administrar Roles:

En nuestro caso, tenemos un informe de Ventas y queremos configurar 2 roles

• un Rol ADMIN para poder ver el informe completo.
• un Rol SALES para comerciales (que no deben ver información de márgenes y costes).

Simplemente creamos los roles sin crear ningún filtro en las tablas.

2. Filtrado de campos o tablas en cada rol

Una vez creados los roles, debemos indicarle a Power BI que objetos (tablas o campos) queremos restringir a cada rol. Este paso debemos hacerlo en Tabular Editor. Si no lo habéis usado antes, Tabular Editor es una herramienta externa que accede al modelo de datos de tu informe y te permite modificarlo y mejorarlo. Os dejo este link a su documentación oficial.

Si ya habéis instalado Tabular Editor, en Power BI Desktop, bajo el menú “Herramientas Externas” verás un botón para acceder a él desde Power BI Desktop:

Accedemos a Tabular Editor desde ese botón y se abrirá la aplicación cargando todo el modelo de nuestro informe:

Como veis en la imagen anterior, se han cargado todas las tablas del modelo, las relaciones e incluso los 2 roles que hemos creado en el paso 1.

Ahora sólo debemos ir al Rol de SALES y en Propiedades > Table Permissions cambiar la seguridad de la tabla Ventas a Read:

Una vez hecho esto, desplegamos el Rol Sales y veremos que hay una función fx Ventas y en propiedades podremos restringir el acceso a los campo BENEFICIO:

Ya podemos presionar el botón de guardar en Tabular Editor y cerrar esta herramienta:

3. Comprobar la Seguridad OLS

Para comprobar la seguridad antes de publicar podemos ir a Power BI Desktop > Modelado > Ver Como y marcar el rol que queremos comprobar:

Si pulsamos sobre ADMIN, como no le hemos indicado ninguna restricción OLS, verá el informe completo:

Si pulsamos sobre SALES, toda visualización que contenga el campo BENEFICIO (al que no tiene acceso) dará error:

¿Por qué muestra error Power BI en las visuales con campos no accesibles?

La verdad es que no es muy elegante que aparezcan visuales con el mensaje “Hubo un problema con uno o más campos”, pero ¿es un problema de la seguridad OLS? ¿de Tabular Editor? ¿del motor visual de Power BI?

Para averiguarlo, he recurrido a un vídeo de SQLBI del gran Marco Russo que os dejo en este link.

Hemos hecho la misma prueba que Marco y hemos accedido al modelo de datos de nuestro informe desde Excel y éste si que sigue mostrando la tabla dinámica cuando accedemos con el Rol SALES, pero quitando las columnas a las que no tenemos acceso.

Visión del Excel con rol ADMIN:

Visión del Excel con rol SALES:

Como veis, ha desaparecido la columna Margen(%) que es una medida que depende del campo BENEFICIO (al que no tiene acceso el rol SALES).

Conclusiones

La seguridad OLS tiene muchísimas posibilidades y un gran rendimiento, pero debe entenderse tal y como es: una herramienta de seguridad y privacidad de datos.

Por lo tanto, los casos de uso habituales de OLS podrían ser:

• Datos Sensibles (datos médicos,…)
• Datos Personales (dirección, edad,…)
• Datos confidenciales (nóminas,…)

En mi opinión, el mostrar el mensaje de error de campo en las visuales no es una buena solución, ya que el usuario puede confundirlo con un mal funcionamiento del informe. Debería al menos mostrar un error personalizado del tipo “No tienes acceso/permiso para consultar el campo X”.

En el siguiente post veremos una posible solución a este problema, que también mostramos en la sesión de Cabo San Lucas.

¿Vosotros que opináis? ¿Lo habíais probado ya? Podéis dejar vuestras opiniones, dudas y aportaciones en los comentarios de este post.