Seguridad a nivel de fila en Power BI: acceso a datos multiinquilino

La seguridad a nivel de fila (RLS) es el mecanismo que garantiza que cada usuario vea solo los datos a los que está autorizado a acceder. En un entorno de múltiples inquilinos o múltiples departamentos, RLS no es opcional: es la diferencia entre una plataforma de análisis gobernada y una filtración de datos a punto de ocurrir. Sin embargo, la propia telemetría de uso de Microsoft sugiere que menos del 30 por ciento de las organizaciones con Power BI Premium han implementado RLS en sus conjuntos de datos de producción.

La razón no es que el SPI sea conceptualmente difícil. La razón es que los detalles de implementación tienen matices, el proceso de prueba es manual y la interacción entre RLS y otras características de Power BI (DirectQuery, modelos compuestos, incrustaciones, agregaciones) crea casos extremos que toman desprevenidos a los equipos. Esta guía cubre todos los aspectos de la implementación de RLS, desde el rol estático más simple hasta la seguridad dinámica compleja con la integración de Azure Active Directory.

---

Conclusiones clave

• La seguridad a nivel de fila en Power BI filtra datos a nivel de modelo mediante expresiones DAX, lo que garantiza que los usuarios no puedan eludir la seguridad modificando informes o objetos visuales.
• Los códigos rígidos RLS estáticos filtran valores (adecuados para grupos de usuarios pequeños y estables), mientras que el RLS dinámico usa funciones DAX como USERNAME() y USERPRINCIPALNAME() para filtrar dinámicamente según el usuario que ha iniciado sesión.
• RLS solo funciona en los modos Importación y DirectQuery. No se aplica a conexiones activas a Analysis Services (que tienen su propio RLS).
• La seguridad a nivel de objetos (OLS) oculta tablas o columnas completas, complementando RLS para escenarios en los que los usuarios ni siquiera deberían saber que existen ciertos datos.
• La prueba de RLS requiere la característica "Ver como" en Power BI Desktop y el servicio. Nunca asuma que RLS funciona sin realizar pruebas explícitas para cada rol.
• RLS en escenarios integrados (Power BI Embedded) requiere pasar la identidad efectiva en el token de inserción, que es una fuente común de errores de implementación.
• El impacto en el rendimiento de RLS suele ser inferior al 5 por ciento para modelos bien diseñados, pero los filtros DAX mal escritos pueden degradar el rendimiento en un 50 por ciento o más.

---

Comprender la seguridad a nivel de fila

¿Qué hace el SPI?

RLS aplica expresiones de filtro DAX a una o más tablas en un modelo de datos de Power BI. Cuando un usuario abre un informe, Power BI evalúa las reglas de RLS y filtra silenciosamente las filas que el usuario no está autorizado a ver. El usuario experimenta un informe normal: simplemente no puede ver datos fuera de su alcance.

Fundamentalmente, RLS opera en la capa del modelo de datos, no en la capa del informe. Esto significa:

• Los usuarios no pueden omitir RLS creando sus propios informes en el mismo conjunto de datos.
• Los filtros RLS se propagan a través de relaciones (un filtro en Dim_Region filtra automáticamente Fact_Sales a través de la relación)
• Las medidas DAX respetan el contexto RLS (CALCULATE, SUMX y otras funciones operan en el subconjunto filtrado)
• Exportar a Excel, CSV o PowerPoint solo exporta los datos que el usuario está autorizado a ver

RLS frente a otros mecanismos de seguridad

RLS es el único mecanismo que controla a qué filas específicas de datos puede acceder un usuario. Los otros mecanismos controlan el acceso a nivel de espacio de trabajo, informe u objeto.

---

Seguridad estática a nivel de fila

Static RLS asigna usuarios a roles con valores de filtro codificados. Esta es la implementación más simple y funciona bien para escenarios con una pequeña cantidad de regiones, departamentos o unidades de negocios fijos.

Creando un rol estático

En Power BI Escritorio:

1. Vaya a Modelado y luego a Administrar roles.
2. Haga clic en Crear para agregar un nuevo rol.
3. Asigne un nombre al rol (p. ej., "Ventas en Norteamérica")
4. Seleccione la tabla para filtrar (por ejemplo, Dim_Región)
5. Escriba la expresión del filtro DAX:

[Region] = "North America"

Esta expresión significa: cuando a un usuario se le asigna el rol "Ventas de América del Norte", cada tabla relacionada con Dim_Region solo mostrará filas donde la región sea América del Norte. Un usuario que vea un informe de ventas verá solo las ventas de América del Norte. Un usuario que vea un panel de recursos humanos (si se conecta a través de una dimensión regional) solo verá empleados norteamericanos.

Múltiples roles

Puedes crear múltiples roles con diferentes filtros:

• Ventas EMEA: [Region] = "EMEA"
• Ventas APAC: [Region] = "APAC"
• Ejecutivo Global: Sin filtro (ve todos los datos)

A un usuario se le pueden asignar múltiples roles. Cuando se asignan a múltiples roles, los filtros se combinan con la lógica OR: el usuario ve la unión de los datos de todos los roles. Por ejemplo, un usuario asignado tanto a "Ventas en Norteamérica" ​​como a "Ventas en EMEA" ve datos de ambas regiones.

Limitaciones del RLS estático

El RLS estático se vuelve inmanejable cuando:

• Tiene más de 10 a 15 valores de filtro distintos (crear y mantener más de 15 roles es tedioso)
• Las asignaciones de usuario a rol cambian con frecuencia (cada cambio requiere un administrador de Power BI)
• La lógica del filtro es más compleja que la simple igualdad (por ejemplo, los gerentes deberían ver los datos de su equipo más los suyos propios).
• Tienes cientos de usuarios en docenas de unidades de negocio.

Para estos escenarios, el RLS dinámico es la solución.

---

Seguridad dinámica a nivel de fila

Dynamic RLS utiliza funciones DAX que se evalúan en tiempo de ejecución para determinar el usuario que inició sesión y aplicar los filtros adecuados. Las dos funciones clave son:

• USERNAME() — Devuelve el dominio\nombre de usuario o UPN del usuario actual
• USERPRINCIPALNAME(): devuelve el correo electrónico/UPN del usuario actual (recomendado para implementaciones en la nube)

Configuración de RLS dinámico

Paso 1: crear una tabla de mapeo de seguridad

Esta tabla asigna usuarios a su alcance de datos autorizado. Se puede almacenar en la fuente de datos (base de datos), una lista de SharePoint o un archivo de Excel:

Importe esta tabla a su modelo de Power BI como SecurityMapping.

Paso 2: crear el rol RLS

Cree una función única (por ejemplo, "DynamicSecurity") con un filtro DAX en la tabla de asignación de seguridad:

[UserEmail] = USERPRINCIPALNAME()
    || [UserEmail] = "ALL"

Paso 3: Crea relaciones

Establezca relaciones desde SecurityMapping con sus tablas de dimensiones:

• SecurityMapping[Región] a Dim_Región[Región]
• SecurityMapping[Departamento] a Dim_Department[Departamento]
• Asignación de seguridad[CompanyId] a Dim_Company[CompanyId]

Estas relaciones deben ser de uno a muchos desde la dimensión hasta la tabla de asignación de seguridad, o puede utilizar un filtro cruzado bidireccional. Sin embargo, los filtros bidireccionales tienen implicaciones de rendimiento: un mejor enfoque utiliza CROSSFILTER o TREATAS en la expresión DAX.

Paso 4: Alternativa sin relaciones (enfoque TREATAS)

En lugar de crear relaciones a partir de la tabla de mapeo de seguridad, puede usar TREATAS en la expresión RLS en la tabla de hechos directamente:

VAR CurrentUser = USERPRINCIPALNAME()
VAR UserRegions =
    CALCULATETABLE(
        VALUES(SecurityMapping[Region]),
        SecurityMapping[UserEmail] = CurrentUser
            || SecurityMapping[UserEmail] = "ALL"
    )
RETURN
    [Region] IN UserRegions

Este enfoque evita la complejidad de relaciones adicionales y mantiene la lógica de seguridad autónoma.

RLS dinámico con jerarquía de gerentes

Un requisito común es que los gerentes vean datos de toda su cadena de informes. Esto requiere una jerarquía padre-hijo en la tabla de empleados o usuarios.

Método 1: función RUTA

Si su tabla de usuarios tiene una columna ManagerId, use la función PATH de DAX:

UserPath = PATH(Users[UserId], Users[ManagerId])

Luego en la expresión RLS:

VAR CurrentUserId =
    LOOKUPVALUE(Users[UserId], Users[Email], USERPRINCIPALNAME())
RETURN
    PATHCONTAINS([UserPath], CurrentUserId)

Esta expresión devuelve VERDADERO para los datos propios del usuario actual y todos los datos que pertenecen a sus subordinados directos e indirectos.

Enfoque 2: Mesa de seguridad aplanada

Calcule previamente la jerarquía en su proceso ETL y cree un mapeo de seguridad plano donde cada administrador aparezca con todos los alcances de datos de sus informes. Esto tiene más rendimiento en el momento de la consulta porque evita la sobrecarga de la evaluación de PATH.

---

Seguridad a nivel de objetos (OLS)

La seguridad a nivel de objetos oculta tablas o columnas enteras a los usuarios. A diferencia de RLS, que filtra filas, OLS hace que las tablas o columnas sean completamente invisibles: no aparecen en la lista de campos y cualquier referencia visual a un campo oculto muestra un error.

Cuándo utilizar OLS

• Ocultar columnas de salario en conjuntos de datos de recursos humanos a usuarios que no son de recursos humanos
• Ocultar tablas relacionadas con costos a los equipos de ventas que solo deberían ver los ingresos.
• Ocultar la PII del cliente (correo electrónico, teléfono, dirección) a los analistas que solo necesitan datos agregados
• Ocultar columnas de precios estratégicos a los usuarios generales.

Configurando OLS

OLS se configura a través del Editor tabular (una herramienta externa) o puntos de conexión XMLA, no a través de la interfaz de usuario de Power BI Desktop.

En el editor tabular:

1. Abra el modelo a través de la cinta de herramientas externas.
2. Navegue hasta la tabla o columna que desea restringir.
3. En el panel Propiedades, busque Permisos de tabla o Permisos de columna en cada función.
4. Establezca el permiso en "Ninguno" (el valor predeterminado es "Leer")

Por ejemplo, para ocultar la columna Salario en la tabla Empleados del rol "Ventas":

• Rol: Ventas
• Tabla: Empleados
• Columna: Salario
• Permiso: Ninguno

Los usuarios asignados al rol de Ventas no verán la columna Salario en la lista de campos y no podrán hacer referencia a ella en los cálculos DAX.

Limitaciones de OLS

• OLS requiere Power BI Premium o Pro con puntos de conexión XMLA habilitados
• OLS no se puede configurar en la interfaz de usuario nativa de Power BI Desktop
• OLS es solo a nivel de metadatos --- no filtra filas
• Si una medida hace referencia a una columna oculta, la medida en sí generará un error para los usuarios restringidos.

---

RLS con DirectQuery

RLS funciona con DirectQuery, pero el comportamiento es diferente del modo Importar en aspectos importantes.

Cómo funciona

En el modo DirectQuery, Power BI traduce el filtro RLS DAX en una cláusula WHERE de SQL y lo envía al origen de datos. La fuente de datos realiza el filtrado y solo se devuelven filas autorizadas.

Transferencia de inicio de sesión único (SSO)

Cuando se usa DirectQuery con SSO en una base de datos como Azure SQL o Azure Synapse, Power BI pasa la identidad del usuario a la base de datos. Si la base de datos tiene su propia seguridad a nivel de fila (por ejemplo, CREATE SECURITY POLICY de SQL Server), esa seguridad se aplica además del RLS de Power BI.

Importante: Si habilita el paso de SSO, se omite el RLS de Power BI porque la base de datos controla la seguridad. Debes elegir uno u otro:

• Power BI RLS (definido en DAX, administrado en Power BI)
• RLS a nivel de base de datos (definido en SQL, administrado en la base de datos)
• Ambos (se aplican Power BI RLS Y base de datos RLS --- el usuario ve la intersección)

Consideraciones de rendimiento

Los filtros RLS en DirectQuery agregan cláusulas WHERE a cada consulta. Si las columnas de filtro no están indexadas en la base de datos, el rendimiento puede degradarse significativamente. Asegúrese de que:

• Las columnas de filtro RLS tienen índices de base de datos.
• La expresión del filtro DAX es lo suficientemente simple como para traducirla a SQL eficiente.
• Se prueba el rendimiento de las consultas con el "Analizador de rendimiento" en Power BI Desktop

---

RLS en Power BI integrado

Power BI Embedded (incrustación de informes en aplicaciones personalizadas) tiene requisitos RLS únicos porque es posible que los usuarios finales no tengan cuentas de Power BI o Azure AD.

Escenario de datos de propiedad de la aplicación

En el patrón de inserción "La aplicación posee datos", una entidad de servicio o una cuenta maestra se autentica en Power BI y la aplicación pasa la identidad del usuario en el token de inserción.

Generando un token de inserción con RLS:

Al llamar a la API REST de Power BI para generar un token de inserción, incluya el parámetro identities:

{
  "datasets": [
    {
      "id": "dataset-guid-here"
    }
  ],
  "reports": [
    {
      "id": "report-guid-here"
    }
  ],
  "identities": [
    {
      "username": "[email protected]",
      "roles": ["DynamicSecurity"],
      "datasets": ["dataset-guid-here"]
    }
  ]
}

El valor username es lo que devuelve USERPRINCIPALNAME() en la expresión DAX. La matriz roles especifica qué roles RLS aplicar. Puede pasar cualquier cadena como nombre de usuario; no es necesario que sea una cuenta real de Azure AD.

Errores comunes de incrustación

Error 1: No pasar la identidad efectiva. Si genera un token de inserción sin el parámetro identities, el informe incorporado muestra todos los datos. Este es el error de incrustación de RLS más común.

Error 2: Pasar roles pero no nombre de usuario. El nombre de usuario es necesario para RLS dinámico. Sin él, USERPRINCIPALNAME() devuelve un resultado en blanco y el filtro DAX no coincide con ninguna fila; el informe aparece vacío.

Error 3: usar la identidad de la entidad de servicio. La entidad de servicio es un administrador del espacio de trabajo y omite RLS. Debe pasar explícitamente la identidad del usuario final.

Error 4: codificar roles en el token de inserción para RLS dinámico. Si usa RLS dinámico con un único rol (por ejemplo, "DynamicSecurity"), pase siempre ese nombre de rol. No cree roles separados para cada usuario, eso anula el propósito del RLS dinámico.

---

Prueba de seguridad a nivel de fila

Ver como rol (Power BI Desktop)

En Power BI Desktop, vaya a Modelado y luego Ver como:

1. Seleccione los roles a probar
2. Opcionalmente, ingrese un nombre de usuario para probar el RLS dinámico (esto simula el valor USERPRINCIPALNAME())
3. Haga clic en Aceptar

El informe ahora muestra datos como si usted fuera el usuario especificado con el rol especificado. Verificar:

• Las tarjetas KPI muestran los totales filtrados correctos
• Las tablas solo muestran filas dentro del alcance del usuario.
• Los gráficos reflejan los datos filtrados.
• El filtrado cruzado entre imágenes respeta los límites de RLS
• Las páginas de acceso a detalles mantienen el contexto RLS

Ver como (servicio Power BI)

En el servicio Power BI, abra la configuración del conjunto de datos y seleccione Seguridad. Puede probar roles directamente seleccionando "Probar como rol" e ingresando un nombre de usuario.

Lista de verificación de pruebas automatizadas

Cree una matriz de prueba con los siguientes escenarios:

---

Optimización del rendimiento para RLS

Medir el impacto

Antes y después de implementar RLS, use el Analizador de rendimiento en Power BI Desktop para medir los tiempos de consulta. Abra el panel Analizador de rendimiento, comience a grabar, interactúe con el informe y compare los tiempos de consulta DAX con y sin RLS.

Una implementación RLS bien diseñada añade menos del 5 por ciento de gastos generales. Si ve una degradación superior al 10 por ciento, investigue las expresiones del filtro DAX.

Técnicas de optimización

Mantenga las expresiones de filtro simples. La expresión RLS ideal es una comparación de una sola columna:

[Region] = USERPRINCIPALNAME()

Evite expresiones complejas con múltiples llamadas CALCULATE, FILTER o LOOKUPVALUE en el propio filtro RLS.

Utilice claves de números enteros en lugar de comparaciones de texto. Filtrar en [CompanyId] = 1 es más rápido que [CompanyName] = "ECOSIRE Private Limited". Asigne los correos electrónicos de los usuarios a claves enteras en la tabla de asignación de seguridad.

Minimice el número de tablas con filtros RLS. Aplique RLS a las tablas de dimensiones y deje que la propagación de relaciones maneje las tablas de hechos. La aplicación de RLS directamente a tablas de hechos grandes obliga a Power BI a evaluar el filtro en cada fila de la tabla de hechos.

Agregue previamente cuando sea posible. Si un usuario solo necesita datos a nivel de resumen, considere crear una tabla agregada previamente con el filtro de seguridad aplicado durante ETL. Esto reduce el volumen de datos que Power BI necesita filtrar en el momento de la consulta.

Evite los filtros cruzados bidireccionales. Las relaciones bidireccionales aumentan la complejidad de las consultas y pueden entrar en conflicto con RLS. Utilice relaciones unidireccionales (de dimensión a hecho) y aplique RLS en el lado de la dimensión.

---

Errores y soluciones comunes

Error 1: RLS no se aplica a los administradores del espacio de trabajo

Los administradores y miembros del espacio de trabajo con permiso de edición omiten RLS. Siempre ven todos los datos. Esto es por diseño: los administradores necesitan acceso completo para administrar el espacio de trabajo.

Solución: Utilice la función "Visor" para usuarios empresariales que deberían estar sujetos a RLS. Otorgue únicamente roles de administrador/miembro/colaborador al equipo de BI.

Error 2: ALL() Eliminación de filtros RLS

La función DAX ALL() elimina todos los filtros de una tabla, incluidos los filtros RLS. Si una medida usa ALL() en una tabla filtrada por RLS, puede exponer datos que el usuario no debería ver.

-- DANGEROUS: This measure ignores RLS on Dim_Region
Total Global Sales =
CALCULATE(SUM(Fact_Sales[Revenue]), ALL(Dim_Region))

Solución: Utilice ALLSELECTED() en lugar de ALL() cuando desee eliminar filtros visuales/de segmentación pero conservar los filtros RLS:

-- SAFE: This measure preserves RLS filters
Total Sales for Context =
CALCULATE(SUM(Fact_Sales[Revenue]), ALLSELECTED(Dim_Region))

Error 3: CALCULAR RLS anulando

CALCULATE con argumentos de filtro explícitos puede anular RLS en ciertos escenarios, particularmente con REMOVEFILTERS:

-- DANGEROUS: REMOVEFILTERS is equivalent to ALL
Total Revenue All Regions =
CALCULATE(SUM(Fact_Sales[Revenue]), REMOVEFILTERS(Dim_Region[Region]))

Solución: Audite todas las medidas DAX para el uso de TODOS, REMOVEFILTERS y ALLEXCEPT. Asegúrese de que no hagan referencia a columnas filtradas por RLS.

Error 4: modelos compuestos y RLS

En modelos compuestos (que combinan Import y DirectQuery), RLS se debe definir por separado para tablas de importación y tablas de DirectQuery. Una única función RLS puede contener filtros para ambos, pero el comportamiento difiere:

• Importar tablas: el filtro RLS es evaluado por el motor Power BI
• Tablas DirectQuery: el filtro RLS se traduce a SQL y se envía a la fuente

Si el origen de DirectQuery no admite la función DAX utilizada en el filtro RLS, la consulta fallará.

Error 5: Informes paginados que ignoran RLS

Los informes paginados de Power BI (creados en el Generador de informes) pueden omitir el RLS del conjunto de datos si se conectan directamente al origen de datos. Para aplicar RLS, los informes paginados deben conectarse a través del conjunto de datos de Power BI (no directamente a la base de datos) y el usuario debe tener un rol de RLS asignado.

---

Patrón de arquitectura RLS empresarial

Para organizaciones grandes, ECOSIRE recomienda una arquitectura RLS estandarizada:

Diseño de capas de seguridad

1. Tabla de mapeo de seguridad almacenada en una base de datos central (lista de Azure SQL o SharePoint)
2. Rol RLS único denominado "DynamicSecurity" usando USERPRINCIPALNAME()
3. Sincronización de grupo de Azure AD que completa automáticamente la tabla de asignación de seguridad según la pertenencia al grupo.
4. Soporte de jerarquía usando una tabla padre-hijo preaplanada
5. Pista de auditoría registro de qué usuarios accedieron a qué datos (a través de registros de actividad de Power BI y la API REST)

Proceso de gobernanza

1. Los administradores de datos mantienen la tabla de mapeo de seguridad
2. Los cambios se revisan y aprueban mediante un proceso de gestión de cambios.
3. Las auditorías mensuales comparan las asignaciones de Power BI RLS con el sistema de registro de recursos humanos.
4. Las pruebas de penetración trimestrales verifican la eficacia del RLS

Esta arquitectura se adapta a miles de usuarios en cientos de conjuntos de datos y, al mismo tiempo, mantiene un único punto de administración de seguridad.

---

Preguntas frecuentes

¿Funciona RLS con licencias gratuitas de Power BI?

No. RLS requiere licencias Power BI Pro o Premium por usuario para todos los usuarios que consumen informes protegidos por RLS. Los usuarios de licencia gratuita solo pueden acceder al contenido en un espacio de trabajo con capacidad Premium y, aun así, necesitan una licencia Pro o PPU para que se les asignen funciones RLS. En escenarios de Power BI Embedded, los usuarios finales no necesitan licencias de Power BI. RLS se aplica a través del token de inserción.

¿Puedo implementar RLS basado en grupos de Azure AD en lugar de usuarios individuales?

No directamente. RLS de Power BI evalúa las expresiones DAX con respecto a USERPRINCIPALNAME(), que devuelve el correo electrónico del usuario individual. Sin embargo, puede crear una tabla de asignación de seguridad que asigne grupos de Azure AD a ámbitos de datos y completarla mediante Microsoft Graph API o la sincronización de membresía de grupo de Azure AD. La expresión DAX todavía filtra por correo electrónico del usuario, pero la tabla de asignación de seguridad proporciona la asignación de grupo a datos.

¿Qué sucede si un usuario no tiene asignado ningún rol de RLS?

Si RLS está definido en un conjunto de datos y un usuario no está asignado a ninguna función, el usuario no ve ningún dato. El informe se carga pero todos los elementos visuales se muestran en blanco o cero. Este es el valor predeterminado seguro: Power BI no asume ningún acceso a menos que se conceda explícitamente. Sin embargo, los administradores y miembros del espacio de trabajo con permiso de edición omiten RLS y siempre ven todos los datos independientemente de las asignaciones de roles.

¿Puede RLS filtrar datos en paneles de control en tiempo real?

Sí. RLS funciona con los modos Importar y DirectQuery. En el modo DirectQuery, el filtro RLS se traduce a una cláusula WHERE de SQL y se envía a la base de datos con cada consulta, por lo que el filtrado se realiza en tiempo real. En el modo Importar, el filtrado se aplica en memoria cuando el usuario abre el informe. Ambos modos ofrecen la misma garantía de seguridad: el usuario sólo ve los datos autorizados.

¿Cómo audito quién accedió a qué datos a través de RLS?

Power BI proporciona registros de actividad a través del centro de administración de Microsoft 365 y la API REST de Power BI. Estos registros registran vistas de informes, actualizaciones de conjuntos de datos y operaciones de exportación, incluida la identidad del usuario. Sin embargo, los registros no registran qué filas específicas vio un usuario. Para una auditoría detallada del acceso a los datos, habilite la auditoría a nivel de base de datos (por ejemplo, pgaudit de PostgreSQL o auditoría de Azure SQL) para registrar las consultas reales generadas por DirectQuery con filtros RLS aplicados.