Seguridad a nivel de fila (RLS) de Power BI: Un tutorial completo

Seguridad a nivel de fila (RLS) en Power BI te permite controlar qué filas de datos pueden ver los usuarios en función de los filtros. Esta funcionalidad es especialmente valiosa en situaciones en las que varios usuarios necesitan acceder a un informe compartido, pero con vistas personalizadas según sus funciones o departamentos.

En este tutorial, te guiaré a través de una comprensión práctica y profunda de RLS, incluyendo sus configuraciones estáticas y dinámicas, pasos de implementación práctica, técnicas empresariales avanzadas y errores comunes que he aprendido a evitar. También compartiré las mejores prácticas y compararé RLS con otros modelos de seguridad.

Si acabas de empezar con Power BI, te recomiendo que consultes nuestra programa de habilidades Fundamentos de Power BI, que te ayudará a dominar todas las habilidades esenciales que necesitarás.

¿Qué es la seguridad a nivel de fila?

La seguridad en el nivel de fila (RLS) es una característica de seguridad de Power BI que restringe el acceso a las filas de una tabla en función de la identidad del usuario que ve el informe. En lugar de duplicar informes para diferentes grupos de usuarios, RLS te permite aplicar filtros a nivel de datos para que cada usuario vea solo los datos que está autorizado a ver.

Esto es fundamental para preservar la confidencialidad e integridad de los datos, especialmente en situaciones que implican información confidencial o privada. RLS opera dentro del modelo de datos de Power BI y garantiza que los usuarios no autorizados no puedan acceder a datos restringidos, ni siquiera a través de métodos indirectos como segmentadores o desgloses.

Funciones y filtros

La implementación de RLS se basa en tres elementos fundamentales:

• Roles: Agrupaciones lógicas con reglas de acceso definidas.
• DAX filtros: Expresiones que determinan a qué datos puede acceder cada función.
• Asignaciones de usuario: Configuración de qué usuarios o grupos pertenecen a qué roles.

Estos elementos funcionan conjuntamente para evaluar cada consulta en función de las condiciones de acceso antes de devolver los resultados.

Casos de uso

RLS es muy aplicable en muchos sectores y escenarios, entre los que se incluyen:

• Territorios de venta: Los gerentes de ventas solo ven los datos de rendimiento de su región.
• : Los médicos solo tienen acceso a los registros de los pacientes que les han sido asignados.
• e SaaS multitenant: Los clientes solo ven los datos de su propia organización en los paneles compartidos.

Este modelo de seguridad permite que los conjuntos de datos compartidos permanezcan seguros al tiempo que se minimiza la duplicación y la sobrecarga administrativa.

Arquitecturas RLS estáticas frente a dinámicas

La seguridad a nivel de fila se puede dividir en dos tipos: estática y dinámica.

He resumido sus diferencias en la tabla siguiente:

Consejo: Utiliza RLS estático para grupos de usuarios pequeños y fijos. Utiliza RLS dinámico para entornos en crecimiento o a gran escala.

A continuación, voy a repasar algunas implementaciones de ejemplos estáticos y dinámicos.

Implementación de RLS estático

El RLS estático implica la creación de roles con filtros DAX codificados de forma fija. Cada función corresponde a un grupo o segmento específico, como una región geográfica o un departamento.

Estos son los pasos generales para implementar un RLS estático:

1. Crea un rol con el nombre, por ejemplo, «Región_Este».
2. Aplica un filtro como [Region] = "East" a esa función.
3. Asigna usuarios específicos a la función en Power BI Service.

Implementación dinámica de RLS

RLS dinámico utiliza funciones como USERNAME() o USERPRINCIPALNAME() combinadas con tablas de asignación para filtrar dinámicamente los datos en función de la identidad del usuario.

Estos son los pasos generales para implementar un RLS dinámico:

1. Crea una tabla de asignación que vincule a los usuarios con los niveles de acceso. Esta será tu tabla de seguridad. Esta tabla debe incluir columnas como los correos electrónicos de los usuarios, sus regiones de acceso y sus nombres.
2. Escribe un filtro DAX como: [Region] = RELATED(UserRegion[Region])
3. Filtra esa tabla con: UserRegion[Email] = USERPRINCIPALNAME()

Configuración de la seguridad a nivel de fila en Power BI Desktop

Ahora veremos una guía rápida sobre cómo configurar la seguridad estática a nivel de fila utilizando un sencillo conjunto de datos de ventas.

1. Creación de un conjunto de datos de muestra con Python

Para probar RLS, crea un conjunto de datos de muestra con Python:

import pandas as pd

data = {
    'Salesperson': ['Alice', 'Bob', 'Charlie', 'Alice', 'Bob', 'Charlie'],
    'Region': ['East', 'West', 'South', 'East', 'West', 'South'],
    'SalesAmount': [15000, 20000, 18000, 17000, 21000, 16000],
    'Email': ['alice@company.com', 'bob@company.com', 'charlie@company.com'] * 2,
    'Date': pd.date_range(start='2025-01-01', periods=6, freq='M')
}

sales_df = pd.DataFrame(data)
sales_df.to_csv('sample_sales_data.csv', index=False)

2. Importación a Power BI y creación de una visualización de referencia

1. Abre Power BI Desktop.
2. Ir a Inicio > Obtener datos > Texto/CSV.
3. Selecciona el archivo « sample_sales_data.csv ».

4. Carga los datos en el modelo.

Asegúrate de que los tipos de datos sean los correctos y confirma que la columna « Email » coincida con los formatos de identidad de inicio de sesión (normalmente, el correo electrónico).

5. Crea un gráfico de columnas apiladas básico en Power BI. Arrastra el campo Fecha al eje X y el campo Importe de ventas al eje Y.

Así es como debería verse tu tabla:

Puedes encontrar más información sobre el uso de Power BI en nuestra hoja de referencia rápida, que se muestra a continuación.

3. Creación de roles

A continuación, creemos algunos roles para definir qué roles pueden tener qué permisos.

1. Ir a Modelado > Administrar roles.

2. Haz clic Crear y asigna un nombre a tu función, por ejemplo, « SalesRegionStatic ».
3. Selecciona la tabla correspondiente.
4. Introduce una expresión DAX de filtro:

[Email] = “charlie@company.com”

Así es como debería verse tu interfaz:

5. Guarda y cierra el cuadro de diálogo.

Si los cambios se guardan correctamente, aparecerá una barra verde de notificación como se muestra a continuación.

4. Funciones de prueba

1. Ir a Modelado > Ver como roles.

2. Selecciona el rol « SalesRegionStatic » que hemos creado anteriormente.

3. Ver imágenes del informe filtradas por esa identidad.

Como puedes ver en la imagen siguiente, el gráfico se ha filtrado para mostrar solo los datos en los que el correo electrónico es «charlie@company.com».

Esto permite la validación local antes de la implementación.

Asignación de usuarios y administración de roles en el servicio Power BI

Una vez configuradas y probadas las funciones RLS en Power BI Desktop, el siguiente paso es publicar el informe en el servicio Power BI. Esto te permite asignar usuarios o grupos de seguridad específicos a cada función, lo que garantiza que se aplique el control de acceso cuando se comparte el informe.

1. Publicación del informe en el servicio Power BI

1. En Power BI Desktop, haz clic en Inicio > Publicar > En Power BI.
2. Selecciona el área de trabajo de destino en tu servicio Power BI.

3. Después de publicar, inicia sesión en Power BI Service en https://app.powerbi.com.

Así es como se ve el mío en el servicio Power BI en la web.

La publicación es un requisito previo para configurar las asignaciones de roles RLS, ya que los roles definidos en Power BI Desktop se transfieren junto con el conjunto de datos.

2. Acceder a la configuración de seguridad

1. Selecciona el menú Más opciones para el modelo semántico correspondiente.Haz clic en los tres puntos suspensivos (...) junto al conjunto de datos y selecciona Seguridad.
2. Verás una lista de roles definidos en Power BI Desktop.

Aquí es donde asignas usuarios o grupos de Azure Active Directory (AAD) a cada rol.

3. Asignación de usuarios individuales y grupos de seguridad

Para asignar usuarios, introduce sus direcciones de correo electrónico completas en el cuadro de texto situado debajo de la función deseada, pulsa Intro y haz clic en Añadir.

Para asignar grupos AAD, utiliza el nombre del grupo (por ejemplo, Sales_Region_East o Finance_Team). Asegúrate de que el grupo ya está definido y mantenido en Azure Active Directory.

4. Verificación del acceso asignado

Después de asignar usuarios o grupos, dedica unos minutos a comprobar que se muestran los datos correctos al grupo adecuado.

Cada persona solo verá los datos filtrados por la expresión DAX vinculada a tu función. No se les notificará directamente la asignación de funciones, por lo que es posible que desees comunicarles las instrucciones de acceso una vez que hayas realizado la verificación.

5. Probar asignaciones de roles en el servicio Power BI

1. En la misma página, haz clic en el nombre de RLS que definiste anteriormente y haz clic en los tres puntos (...), y luego en Probar como rol.

2. Power BI abrirá una versión de solo lectura del informe en la que solo se mostrarán los datos permitidos por la función seleccionada.

Para RLS dinámico, también puedes simular lo que verá un usuario específico:

• Haz clic en Probar como rol.
• Introduce el correo electrónico de un usuario para simular su experiencia.

Esto es útil para garantizar que tus filtros dinámicos (por ejemplo, basados en USERPRINCIPALNAME()) funcionan correctamente.

Técnicas avanzadas de implementación

RLS se puede integrar aún más en tu flujo de trabajo de Power BI mediante algunas técnicas avanzadas. Aquí hay algunos que debes tener en cuenta:

1. Integración de grupos de seguridad

El uso de grupos de seguridad de Azure Active Directory (AAD) te permite asignar permisos de acceso a grupos completos en lugar de a usuarios individuales. 

Esta práctica resulta especialmente útil en empresas en las que los empleados se incorporan o abandonan equipos con frecuencia, ya que elimina la necesidad de actualizar manualmente los permisos de acceso en Power BI.

2. Consideraciones sobre modelos de datos complejos

Al crear modelos de datos a gran escala, asegúrate de que RLS no interfiera con las relaciones y la propagación de filtros. 

Aquí tienes algunos consejos:

• Utiliza un diseño de esquema en estrella para evitar uniones complejas.
• Limita el uso de relaciones bidireccionales a menos que sea necesario.
• Evita las relaciones ambiguas que podrían dar lugar a un filtrado incorrecto.
• Optimiza el rendimiento minimizando las columnas calculadas en tablas con muchos filtros.

3. Enfoques híbridos

Un enfoque híbrido para el RLS es la combinación de técnicas estáticas y dinámicas. 

Por ejemplo, puedes definir un rol estático para conceder acceso a una unidad de negocio específica y aplicar filtros dinámicos dentro de ese rol en función de direcciones de correo electrónico o nombres de usuario individuales. Este método permite una lógica de seguridad flexible y por capas.

4. Seguridad a nivel de objeto (OLS)

La seguridad a nivel de objeto te permite ocultar tablas o columnas completas a determinados roles. Complementa RLS añadiendo otra capa de protección de datos. El OLS se puede utilizar para campos sensibles como la información salarial o médica.

Estrategias de prueba y validación

1. Pruebas en escritorio

Power BI Desktop ofrece una forma útil de simular diferentes vistas de usuario a través de la función de rol «Ver como». Esta función ayuda a los programadores de informes a validar que la lógica de seguridad a nivel de fila funciona correctamente antes de publicar el informe.

Cómo probar RLS en Power BI Desktop:

1. Haz clic en el pestaña .
2. Seleccionar Ver como en la cinta.
3. Selecciona los roles que has configurado (por ejemplo, SalesRegionStatic).
4. Si lo deseas, introduce un nombre de usuario/correo electrónico de prueba si estás utilizando RLS dinámico.
5. Haz clic en Aceptar y examina cómo se filtran los elementos visuales.

Esto simula el informe como si un usuario asignado a esa función lo estuviera viendo. Es especialmente útil cuando se prueban filtros RLS dinámicos que dependen de funciones DAX como USERPRINCIPALNAME().

2. Pruebas de servicio

Una vez publicado en Power BI Service, RLS debe probarse de nuevo en el entorno de la nube para garantizar su precisión.

Cómo probar RLS en Power BI Service:

1. Navega hasta el conjunto de datos en tu área de trabajo.
2. Haz clic en el ... junto al conjunto de datos > Seguridad.
3. Selecciona un rol > haz clic en Probar como rol.
4. Utiliza la opción «Probar como usuario específico» para simular filtros RLS dinámicos.

Esto garantiza que los filtros se comporten según lo esperado para los usuarios reales.

3. Consejos clave para la validación

Para la validación, puedes considerar el uso de cuentas de prueba o identidades de servicio para imitar el uso real. Todos los filtros de los elementos visuales clave, como tablas y gráficos, también deben revisarse periódicamente.

También debes comprobar minuciosamente los segmentadores, los desgloses y los marcadores para asegurarte de que no se filtran datos no autorizados.

Errores comunes y soluciones

La implementación de RLS puede presentar algunos problemas, por lo que a continuación se indican algunos de los más comunes y cómo solucionarlos.

1. Problemas posteriores a la publicación

Después de publicar en Power BI Service, algunos usuarios observan que RLS no funciona como esperaban, aunque sí lo hacía en Power BI Desktop.

Soluciones:

• Asegúrate de que el informe se vuelva a publicar después de realizar cambios en las funciones o los filtros.
• Confirma que el correo electrónico utilizado en USERPRINCIPALNAME() coincide con el formato de dominio de inicio de sesión del conjunto de datos.

2. Conflictos de roles en el espacio de trabajo

Los usuarios con determinados roles en el espacio de trabajo (administrador, miembro) pueden omitir RLS sin darse cuenta.

Soluciones:

• Asignar usuarios como Videntes en el espacio de trabajo para aplicar las reglas de RLS.
• Evita conceder derechos de colaborador/administrador a menos que sea necesario para el desarrollo de contenidos.

3. Limitaciones de la función DAX

Los errores más comunes surgen del uso incorrecto de funciones DAX como USERNAME() y USERPRINCIPALNAME():

• USERNAME() puede devolver un nombre de cuenta local en lugar de un correo electrónico cuando se prueba en el escritorio.
• Utiliza USERPRINCIPALNAME() para mantener la coherencia con el comportamiento de la identidad en la nube.

Consejos:

• Añade una tabla de referencia con ejemplos de correos electrónicos para facilitar las pruebas locales.
• Utiliza lógica condicional o valores predeterminados en DAX para evitar errores de filtrado.

4. Problemas con DirectQuery y SSO

El RLS dinámico con fuentes DirectQuery requiere especial atención, especialmente cuando se utiliza con el inicio de sesión único (SSO).

Problemas comunes:

• Una configuración incorrecta de la puerta de enlace puede bloquear la suplantación de identidad de los usuarios.
• La configuración de SSO con Kerberos puede fallar si los SPN están mal configurados.

Soluciones:

• Consulta la documentación de Microsoft sobre SSO con puertas de enlace de Power BI.
• Trabajar en estrecha colaboración con los equipos de TI e infraestructura para habilitar la delegación de Kerberos.

Eliminar o desactivar RLS para acceso público

Puede haber situaciones en las que sea necesario eliminar RLS de forma temporal (por ejemplo, para demostraciones o paneles abiertos) o permanente (por ejemplo, al compartir datos con partes interesadas externas). En tales casos, tendrás que tener cuidado con la configuración de visibilidad para evitar fugas inesperadas.

Desactivación de RLS en Power BI Desktop

Para desactivar RLS:

1. Abre tu informe en Power BI Desktop.
2. Navega a Modelado > Administrar roles.
3. Selecciona y elimina todos los roles o desactiva sus filtros.
4. Guarda y vuelve a publicar el conjunto de datos en Power BI Service.

Una vez eliminados, todos los usuarios podrán acceder al conjunto de datos completo, a menos que se hayan implementado otras medidas de seguridad.

Compartir de forma segura sin RLS

Si la RLS no es viable o necesaria, considera las siguientes prácticas para mantener la seguridad de los datos:

• Utiliza permisos a nivel de conjunto de datos: Comparte el conjunto de datos o el informe solo con usuarios de confianza y utiliza los permisos del espacio de trabajo (visor, colaborador) de forma adecuada.
• Evita publicar en la web: «Publicar en la web» elimina todos los controles de seguridad. En su lugar, utiliza «Insertar para la organización» o Power BI Embedded para compartir de forma segura en público.

Eliminar RLS no significa eliminar toda la seguridad. Utiliza otras capas de control de acceso y funciones para compartir en Power BI Service para garantizar una difusión responsable de los datos.

Prácticas recomendadas para la implementación empresarial

La implementación exitosa de la seguridad a nivel de fila en toda la empresa requiere una planificación minuciosa, una arquitectura escalable y una gobernanza adecuada. En esta sección se describen las mejores prácticas probadas en diferentes dimensiones de la implementación de RLS.

1. Modelado de datos

Un modelo de datos bien diseñado permite configuraciones RLS eficientes y fáciles de mantener.

Recomendaciones:

• Sigue un esquema en estrella con relaciones claras entre las tablas de hechos y dimensiones.
• Evita las relaciones bidireccionales innecesarias que podrían introducir ambigüedad en el filtrado.

2. Gestión de roles

La gestión centralizada y coherente de las funciones de RLS ayuda a reducir los errores y mejorar la colaboración.

Recomendaciones:

• Mantén un documento de definición de roles para realizar un seguimiento de la lógica RLS y las expresiones DAX.
• Utiliza nombres descriptivos para las funciones (por ejemplo, «Región_Este_Ventas») para evitar confusiones.

3. Optimización del rendimiento

El RLS puede afectar al rendimiento de los informes, especialmente cuando se utilizan filtros complejos o conjuntos de datos de gran tamaño.

Recomendaciones:

• Preagregar los datos, cuando sea posible, utilizando tablas resumen.
• Minimiza el uso de columnas calculadas en la lógica RLS.
• Utiliza la indexación y las consultas optimizadas en los sistemas de origen para admitir escenarios de DirectQuery.

RLS frente a modelos de seguridad alternativos

Ahora compararemos las diferencias entre la seguridad a nivel de fila (RLS) y otras características de seguridad, en particular la seguridad a nivel de objeto (OLS).

1. Granularidad y caso de uso

RLS permite controlar el acceso a filas individuales de datos, lo que resulta ideal para filtrar datos por identidad de usuario, ubicación geográfica, departamento o unidad de negocio. Por otro lado, OLS controla el acceso a tablas o columnas completas, lo que resulta útil para ocultar información financiera o de recursos humanos confidencial (por ejemplo, la columna de salarios). 

2. Implementación y adaptación dinámica

RLS se puede implementar fácilmente en Power BI Desktop a través de filtros DAX en roles. Estas reglas pueden ser estáticas (filtros codificados) o dinámicas (lógica impulsada por el usuario). OLS se configura a través del Editor tabular o el punto final XMLA. También requiere un área de trabajo premium o un conjunto de datos de Power BI alojado en Analysis Services.

He elaborado un resumen comparativo en la tabla siguiente:

Conclusión

En resumen, la seguridad a nivel de fila (RLS) en Power BI es un método clave para garantizar la gobernanza de los datos dentro de la plataforma. Permite a las organizaciones ofrecer experiencias analíticas personalizadas y seguras en un único informe o panel de control, sin comprometer la confidencialidad ni la integridad de los datos subyacentes.

La seguridad es un factor cada vez más importante en la gestión y el control de datos, lo cual es un aspecto importante al trabajar con Power BI. Para obtener información más detallada sobre Power BI, consulta nuestra Implementación y mantenimiento de activos en Power BI o nuestro Informes en Power BI. Para más información, consulta nuestras guías sobre Jerarquías de Power BI y Paneles de Power BI.