Por qué tu RLS de Power BI funciona en Desktop pero filtra datos en Fabric

By Mirko Peters · 2026-08-11

¡Bienvenido de nuevo al blog de ingeniería de datos y analítica! Si alguna vez has creado un dashboard espectacular, has verificado tu Row-Level Security en local en Power BI Desktop, lo has publicado en la nube y luego te has llevado un susto cuando un usuario estándar ha accedido a información que no le correspondía, no eres el único. La arquitectura de seguridad en los entornos analíticos moder

Automatically translated with AI from the original post. Read the English original

¡Bienvenido de nuevo al blog de ingeniería de datos y analítica! Si alguna vez has creado un dashboard espectacular, has verificado tu Row-Level Security en local en Power BI Desktop, lo has publicado en la nube y luego te has llevado un susto cuando un usuario estándar ha accedido a información que no le correspondía, no eres el único. La arquitectura de seguridad en los entornos analíticos modernos es notoriamente complicada. Al pasar del desarrollo local a plataformas en la nube a escala empresarial, como Microsoft Fabric, las suposiciones que mantenían tus datos a salvo en tu portátil pueden venirse abajo por completo.

En este artículo vamos a analizar en detalle por qué tu RLS de Power BI puede estar filtrando datos después de la publicación, cómo difiere la asignación de identidades entre entornos y cómo implementar patrones de seguridad robustos y nativos de la nube. Vamos a desgranar la arquitectura detrás de la seguridad de datos empresarial.

Conceptos básicos (el modelo mental)

Antes de escribir una sola línea de Data Analysis Expressions, o DAX, necesitas establecer el modelo mental correcto para la seguridad. Demasiados desarrolladores tratan Row-Level Security como una simple casilla de verificación o un ajuste administrativo rápido al final de un proyecto. En realidad, la seguridad es un sistema interconectado.

• Seguridad centrada en el modelo: las relaciones y las direcciones de filtro determinan cómo se propaga el RLS. Si tu modelo de datos tiene relaciones rotas o rutas de muchos a muchos inesperadas, los filtros de seguridad no llegarán correctamente a tus tablas de hechos.
• Diseño de roles: pocos roles bien diseñados son mejores que muchos roles extensos y solapados. Crear cien roles estáticos para usuarios individuales se convertirá rápidamente en una pesadilla administrativa.
• Contexto dinámico: la seguridad debe responder a quién está viendo el informe y a qué está relacionado dentro de la organización en su conjunto.
• Realidad de la nube: la resolución de identidades y la configuración del inquilino en Fabric pueden cambiar radicalmente el comportamiento respecto a tu equipo local. Entender cómo la nube asigna la identidad de tu usuario es imprescindible.

Diseñar filtros que aguanten (patrones DAX)

Escribir expresiones DAX seguras para tus roles es la piedra angular del aislamiento eficaz de datos. Según la estructura organizativa y la escala de tu organización, probablemente elegirás entre patrones de filtrado estáticos y dinámicos.

RLS estático (audiencias sencillas y fijas)

• Ejemplo en DimRegion:
  DimRegion[Region] = "US"

RLS dinámico mediante tabla puente (recomendado)

• Tablas: Users (UPN, UserKey), UserRegion (UserKey, RegionKey), DimRegion (RegionKey, Region)
• Filtro de rol en Users:
  Users[UPN] = USERPRINCIPALNAME()
• Opcionalmente, restringe DimRegion mediante una relación desde Users > UserRegion > DimRegion.

Evitar

• La seguridad basada en columnas calculadas, que se evalúa en el momento de la actualización de datos y no de forma dinámica según el contexto de cada usuario.
• USERNAME() en Fabric (usa siempre USERPRINCIPALNAME(); asegúrate de probar a fondo los formatos de correo y los sufijos UPN).
• Codificar de forma fija correos o dominios individuales directamente en tus expresiones de filtro.

Patrones dinámicos útiles

• Modelos multiinquilino: asigna TenantId desde tu tabla central Users directamente a las tablas de hechos y de dimensiones.
• Jerarquías: almacena las relaciones entre responsable y subordinados, materializa una tabla de acceso y filtra por todos los descendientes estructurales del usuario actual.

Diseño de roles y relaciones

La forma de tu modelo de datos define tus límites de seguridad. Usa filtros de dirección única siempre que sea posible para evitar rutas ambiguas de muchos a muchos que puedan eludir sin querer las restricciones de seguridad. Crea dimensiones de seguridad dedicadas, como tablas puente entre usuario y acceso, en lugar de incrustar lógica de negocio compleja directamente en tus tablas de hechos. Prefiere siempre unos pocos roles reutilizables combinados con filtros dinámicos antes que decenas de roles estáticos.

Asignaciones sin sorpresas (usuarios y grupos)

Gestionar las asignaciones de forma eficiente es clave para la salud operativa a largo plazo. Asigna siempre tus roles a grupos de Azure AD en lugar de cuentas de usuario individuales, para que el sistema escale sin problemas cuando los empleados cambien de equipo. Evita la pertenencia obsoleta programando revisiones trimestrales de acceso con los propietarios de los grupos. Ojo con las pertenencias superpuestas a grupos: los usuarios que pertenecen a varios grupos de seguridad pueden ampliar sin querer su acceso a los datos.

Desktop frente a Fabric: qué cambia después de publicar

Aquí es donde se producen la mayoría de las fugas de seguridad. En Power BI Desktop trabajas en un entorno local controlado. Una vez que publicas en Microsoft Fabric, la nube asume la gestión de identidades. USERPRINCIPALNAME() devuelve la dirección de correo de la nube en Fabric, mientras que las vistas previas en Desktop pueden comportarse de forma distinta según las credenciales locales. Además, el propietario del conjunto de datos, las credenciales de actualización, la configuración del área de trabajo y la latencia de sincronización de grupos en Azure AD pueden alterar lo que un usuario puede ver realmente.

Pruebas que detectan de verdad las fugas

Nunca confíes únicamente en la función "Ver como" de Power BI Desktop para dar por válida la seguridad en producción. Es útil para comprobaciones rápidas, pero debes probar en Fabric. Valida con grupos de seguridad y cuentas de usuario reales en un área de trabajo que no sea de producción. Prueba cada rol en las páginas principales de los informes y en los elementos visuales sensibles. Considera automatizar comprobaciones puntuales mediante los puntos de conexión XMLA o herramientas de automatización para exportar conjuntos de resultados pequeños con cuentas de prueba conocidas.

Gobernanza y operaciones

Mantener la seguridad a lo largo del tiempo exige una gobernanza rigurosa. Cataloga tus roles, documenta sus filtros DAX, enumera las tablas afectadas y anota los públicos previstos. Aplica control de cambios mediante solicitudes de extracción (pull requests) que exijan evidencias de pruebas de RLS antes de fusionar cambios en el modelo. Define contratos de datos claros que especifiquen qué dimensiones y tablas de hechos deben participar en RLS. Realiza recertificaciones trimestrales de la pertenencia a grupos y supervisa los informes de alto riesgo para detectar anomalías.

Patrones de fallo habituales (y soluciones)

Si encuentras problemas, compáralos con estos patrones de fallo habituales:

• Funciona en Desktop, filtra datos en Fabric: se debe a usar USERNAME() o formatos de identidad que no coinciden. Solución: estandariza en USERPRINCIPALNAME() y alinea los valores de Users[UPN].
• El usuario ve demasiado: se debe a una ruta de muchos a muchos que evita la seguridad. Solución: introduce una dimensión de seguridad y restringe las relaciones.
• El acceso de un antiguo equipo persiste: se debe a pertenencias obsoletas a grupos de Azure AD. Solución: automatiza los flujos de recertificación y los procesos de eliminación.
• Columna calculada usada como identidad: no tiene efecto por usuario. Solución: traslada la lógica a DAX de filtro de rol sobre las tablas del modelo.

Lista de verificación de inicio rápido (esta semana)

• Añade una tabla Users indexada por USERPRINCIPALNAME() y relaciónala con tus tablas de acceso.
• Convierte los filtros fijos en filtros dinámicos basados en tablas, cuando sea conveniente.
• Sustituye cualquier lógica con USERNAME() por USERPRINCIPALNAME() y vuelve a probar en Fabric.
• Asigna los roles a grupos de AAD y programa una revisión de acceso con los propietarios de los grupos.
• Publica en un área de trabajo de prueba, valida con usuarios reales y corrige las brechas de identidad.
• Documenta tus roles, DAX y tablas en el README del modelo.

Recursos SEO sugeridos

• Slug de URL: power-bi-row-level-security-architecture
• Meta título: Seguridad a nivel de fila en Power BI: arquitectura, patrones DAX y gobernanza preparada para la nube
• Meta descripción: Ve más allá de la casilla de RLS. Aprende patrones DAX dinámicos, diseño de roles, asignación a grupos de Azure AD y pruebas específicas de Fabric para mantener los datos sensibles realmente seguros.
• Palabras clave: Power BI, Row-Level Security, RLS, USERPRINCIPALNAME, grupos de Azure AD, Fabric, RLS dinámico, gobernanza de datos

Conclusión

La seguridad a nivel de fila no es una función que puedas configurar una vez y olvidar. Es un sistema vivo formado por modelos de datos, relaciones, fórmulas DAX, asignación de identidades y configuración de gobernanza en la nube. Si abandonas los roles estáticos y frágiles, adoptas tablas puente dinámicas y robustas, y pruebas con rigor dentro de Microsoft Fabric, tus datos seguirán protegidos sin importar cómo crezca y cambie tu organización.

Para profundizar en este tema y escuchar estrategias prácticas de implementación, no dejes de consultar nuestro episodio de podcast relacionado: Implement Power BI Row-Level Security in Microsoft Fabric. ¡No te limites a bloquear tus datos, diseña una arquitectura de seguridad resiliente que se adapte a la evolución de tu organización!