Instrucciones de seguridad de nivel de fila (RLS) en Power BI Desktop

Este artículo está dirigido a modeladores de datos como usted que trabajan con Power BI Desktop. Describe las prácticas de diseño adecuadas para aplicar seguridad de nivel de fila (RLS) en los modelos de datos.

Es importante comprender las filas de tabla de los filtros de RLS. No se pueden configurar para restringir el acceso a los objetos de modelo, como tablas, columnas o medidas.

Nota

En este artículo no se describe RLS ni cómo configurarlo. Para obtener más información, consulte Restricción del acceso a datos con seguridad de nivel de fila (RLS) en Power BI Desktop.

Además, no se trata la aplicación de RLS en conexiones dinámicas a modelos hospedados externamente con Azure Analysis Services o SQL Server Analysis Services. En estos casos, es Analysis Services quien aplica RLS. Cuando Power BI se conecta mediante inicio de sesión único (SSO), Analysis Services aplicará RLS (a menos que la cuenta tenga privilegios de administrador).

Crear roles

Es posible crear varios roles. Cuando piense en las necesidades de permisos que requiere un único usuario de informes, procure crear un único rol que conceda todos esos permisos, en lugar de optar por un diseño en el que un usuario de informes sea miembro de varios roles. El motivo es que un usuario de informes podría asignarse a varios roles, ya sea directamente mediante su cuenta de usuario o indirectamente mediante la pertenencia a grupos de seguridad. Las asignaciones de roles múltiples pueden producir resultados inesperados.

Cuando se asigna un usuario de informes a varios roles, los filtros RLS se vuelven aditivos. Esto significa que los usuarios de informes pueden ver filas de tabla que representan la unión de esos filtros. Pero aún hay más: en algunos escenarios no es posible garantizar que un usuario de informes no vea las filas de una tabla. Por lo tanto, a diferencia de los permisos aplicados a objetos de base de datos de SQL Server (y otros modelos de permisos), no se aplica el principio "una vez denegado, denegado siempre".

Considere un modelo con dos roles: El primer rol, llamado Workers (Trabajadores), restringe el acceso a todas las filas de la tabla Payroll (Nómina) mediante la siguiente expresión de regla:

FALSE()

Nota

Una regla no devolverá ninguna fila de la tabla cuando su expresión se evalúe como FALSE.

Aún así, un segundo rol, denominado Managers (Directivos), permite el acceso a todas las filas de la taba Payroll (Nómina) mediante la siguiente expresión de regla:

TRUE()

Atención: Si un usuario de informes se asigna a ambos roles, verá todas las filas de la tabla Payroll (Nómina).

Optimización de RLS

RLS funciona aplicando filtros automáticamente a cada consulta DAX, y estos filtros pueden tener un impacto negativo en el rendimiento de las consultas. Por lo tanto, la eficacia de RLS se reduce a un buen diseño del modelo. Es importante seguir las instrucciones para el diseño de modelos, como se describe en los siguientes artículos:

• Descripción de un esquema de estrella e importancia para Power BI
• Todos los artículos de la guía de instrucciones de la relación se encuentran en la documentación de orientación de Power BI.

En general, suele ser más eficaz aplicar filtros RLS en tablas de tipo de dimensión y no tablas de tipo de hechos. Y basarse en relaciones bien diseñadas para garantizar que los filtros RLS se propaguen a otras tablas de modelos. Los filtros RLS solo se propagan a través de relaciones activas. Por lo tanto, evite usar la función DAX LOOKUPVALUE cuando las relaciones de modelo puedan lograr el mismo resultado.

Siempre que se apliquen filtros RLS en las tablas de DirectQuery y existan relaciones con otras tablas de DirectQuery, asegúrese de optimizar la base de datos de origen. Puede implicar el diseño de índices adecuados o el uso de columnas calculadas persistentes. Para obtener más información, vea Instrucciones del modelo de DirectQuery en Power BI Desktop.

Medición del impacto de RLS

Es posible medir el impacto en el rendimiento de los filtros de RLS en Power BI Desktop mediante el Analizador de rendimiento. En primer lugar, determine la duración de las consultas visuales de informes cuando no se aplique RLS. A continuación, use el comando Ver como en la pestaña Modelado de la cinta de opciones para aplicar RLS y determinar y comparar las duraciones de la consulta.

Configuración de las asignaciones de roles

Una vez publicado en Power BI, debe asignar miembros a roles de modelo semántico (anteriormente conocido como conjunto de datos). Solo los propietarios de modelos semánticos o los administradores del área de trabajo pueden agregar miembros a roles. Para más información, consulte Seguridad de nivel de fila (RLS) con Power BI (Administración de la seguridad en el modelo).

Los miembros pueden ser cuentas de usuario, grupos de seguridad, grupos de distribución o grupos habilitados para correo. Siempre que sea posible, se recomienda asignar grupos de seguridad a roles de modelo semántico. Implica la administración de pertenencias a grupos de seguridad en Microsoft Entra ID (anteriormente conocido como Azure Active Directory). Posiblemente, delega la tarea a los administradores de red.

Validación de roles

Pruebe cada rol para asegurarse de que filtra el modelo correctamente. Se realiza fácilmente mediante el uso del comando Ver como en la pestaña de la cinta Modelado.

Cuando el modelo tenga reglas dinámicas que usen la función DAX USERNAME, asegúrese de comprobar los valores esperados e inesperados. Al insertar contenido de Power BI, en concreto con el escenario Inserción para los clientes, la lógica de la aplicación puede pasar cualquier valor como un nombre de usuario de identidad efectivo. Siempre que sea posible, asegúrese de que los valores accidentales o malintencionados den como resultado filtros que no devuelven ninguna fila.

Considere un ejemplo que use Power BI insertado, donde la aplicación pasa el rol de trabajo del usuario como el nombre de usuario efectivo: Es "Manager"(Directivo) o "Worker" (Trabajador). Los administradores pueden ver todas las filas, pero los trabajadores solo pueden ver las filas en las que el valor de la columna Tipo es "Interno".

Se define la siguiente expresión de regla:

IF(
    USERNAME() = "Worker",
    [Type] = "Internal",
    TRUE()
)

El problema con esta expresión de regla es que todos los valores, excepto "Worker" (Trabajador), devuelven todas las filas de la tabla. Por lo tanto, un valor accidental, como "Wrker", devuelve involuntariamente todas las filas de la tabla. Así pues, es más seguro escribir una expresión que pruebe cada valor esperado. En la expresión de regla mejorada siguiente, un valor inesperado hace que la tabla no devuelva ninguna fila.

IF(
    USERNAME() = "Worker",
    [Type] = "Internal",
    IF(
        USERNAME() = "Manager",
        TRUE(),
        FALSE()
    )
)

RLS de diseño parcial

A veces, los cálculos necesitan valores que no están restringidos por filtros de RLS. Por ejemplo, es posible que en un informe se tenga que mostrar la relación entre los ingresos obtenidos para la región de ventas del usuario del informe y todos los ingresos obtenidos.

Aunque no es posible que una expresión DAX invalide RLS —de hecho, no puede determinar ni siquiera que se aplique RLS—, puede usar una tabla de modelo de resumen. La tabla del modelo de resumen se consulta para recuperar los ingresos de "todas las regiones" y no está restringida por ningún filtro de RLS.

Veamos cómo podría implementar este requisito de diseño. En primer lugar, tenga en cuenta el siguiente diseño de modelo:

El modelo consta de cuatro tablas:

• La tabla Salesperson (Comercial) almacena una fila por comercial. Incluye la columna EmailAddress (Dirección de correo electrónico), que almacena la dirección de correo electrónico de cada vendedor. Esta tabla está oculta.
• La tabla Sales (Ventas) almacena una fila por pedido. Incluye la medida Revenue % All Region (% ingresos toda la región), que está diseñada para devolver una relación de los ingresos obtenidos por la región del usuario del informe con respecto a los ingresos obtenidos por todas las regiones.
• La tabla Date (Fecha) almacena una fila por fecha y permite filtrar y agrupar el año y el mes.
• SalesRevenueSummary (Resumen de los ingresos por ventas) es una tabla calculada. Almacena los ingresos totales para cada fecha de pedido. Esta tabla está oculta.

La siguiente expresión define la tabla calculada SalesRevenueSummary (Resumen de los ingresos por ventas):

SalesRevenueSummary =
SUMMARIZECOLUMNS(
    Sales[OrderDate],
    "RevenueAllRegion", SUM(Sales[Revenue])
)

Nota

Una tabla de agregación podría lograr el mismo requisito de diseño.

La siguiente regla de RLS se aplica a la tabla Salesperson (Comercial):

[EmailAddress] = USERNAME()

En la tabla siguiente se describe cada una de las tres relaciones del modelo:

Relación	Descripción
	Hay una relación de varios a varios entre las tablas Salesperson (Comercial) y Sales (Ventas). La regla de RLS filtra la columna EmailAddress (Dirección de correo electrónico) de la tabla oculta Salesperson (Comercial) mediante la función de DAX USERNAME. El valor de la columna Region (Región) (para el usuario del informe) se propaga a la tabla Sales (Ventas).
	Hay una relación de uno a varios entre las tablas Date (Fecha) y Sales (Ventas).
	Hay una relación de uno a varios entre las tablas Date (Fecha) y SalesRevenueSummary (Resumen de los ingresos por ventas).

La expresión siguiente define la medida Revenue % All Region (% ingresos toda la región):

Revenue % All Region =
DIVIDE(
    SUM(Sales[Revenue]),
    SUM(SalesRevenueSummary[RevenueAllRegion])
)

Nota

Tenga cuidado y evite la divulgación de hechos confidenciales. Si solo hay dos regiones en este ejemplo, un usuario del informe puede calcular los ingresos de la otra región.

Cuándo evitar el uso de RLS

A veces tiene sentido evitar el uso de RLS. Si solo tiene algunas reglas RLS simplistas que aplican filtros estáticos, considere la posibilidad de publicar varios modelos semánticos en su lugar. Ninguno de los modelos semánticos define roles porque cada modelo semántico contiene datos para una audiencia de usuario de informe específica, que tiene los mismos permisos de datos. A continuación, cree un área de trabajo por público y asigne permisos de acceso al área de trabajo o a la aplicación.

Por ejemplo, una empresa que tiene sólo dos regiones de ventas decide publicar un modelo semántico para cada región de ventas en diferentes áreas de trabajo. Los modelos semánticos no aplican RLS. Sin embargo, usan parámetros de consulta para filtrar los datos de origen. De esta manera, se publica el mismo modelo en cada espacio de trabajo; solo que tienen diferentes valores de parámetros del modelo semántico. A los comerciales se les asigna acceso a solo una de las áreas de trabajo (o aplicaciones publicadas).

Hay varias ventajas asociadas con la evitación de RLS:

• Mejor rendimiento de las consultas: puede dar lugar a un rendimiento mejorado gracias a la reducción de filtros.
• Modelos más pequeños: Aunque da como resultado más modelos, su tamaño es menor. Los modelos más pequeños pueden mejorar la capacidad de respuesta de la consulta y la actualización de datos, especialmente si la capacidad de hospedaje experimenta presión sobre los recursos. Además, es más fácil mantener los tamaños de modelo por debajo de los límites de tamaño impuestos por su capacidad. Por último, es más fácil equilibrar las cargas de trabajo entre diferentes capacidades, ya que puede crear áreas de trabajo en distintas capacidades —o mover áreas de trabajo a estas—.
• Características adicionales: se pueden usar características de Power BI que no funcionan con RLS, como Publicar en Web.

Sin embargo, hay desventajas asociadas a evitar RLS:

• Varias áreas de trabajo: se requiere un área de trabajo para cada audiencia de usuario de informes. Si se publican aplicaciones, también hay una aplicación por cada audiencia del usuario de informes.
• Duplicación de contenido: los informes y paneles se deben crear en cada área de trabajo. Su configuración y mantenimiento requiere un esfuerzo adicional, además de tiempo.
• Usuarios con privilegios elevados: los usuarios con privilegios elevados, que pertenecen a varias audiencias de usuarios de informes, no pueden ver una vista consolidada de los datos. Tendrán que abrir varios informes (desde diferentes áreas de trabajo o aplicaciones).

Solución de problemas de RLS

Si RLS produce resultados inesperados, compruebe los siguientes problemas:

• Existen relaciones incorrectas entre las tablas del modelo, en cuanto a las asignaciones de columnas y las direcciones de filtro. Tenga en cuenta que los filtros de RLS solo se propagan a través de relaciones activas.
• La propiedad de relación Aplicar filtro de seguridad en ambas direcciones no se ha configurado correctamente. Para obtener más información, vea Instrucciones para relaciones bidireccionales.
• Las tablas no contienen datos.
• Se cargan valores incorrectos en las tablas.
• El usuario está asignado a varios roles.
• El modelo incluye tablas de agregación, y las reglas de RLS no filtran de forma coherente las agregaciones y los detalles. Para obtener más información, vea Uso de agregaciones en Power BI Desktop (RLS para agregaciones).

Cuando un usuario específico no puede ver ningún dato, podría deberse a que su UPN no está almacenado o se ha escrito incorrectamente. Puede suceder repentinamente porque su cuenta de usuario ha cambiado como resultado de un cambio de nombre.

Sugerencia

Con fines de prueba, agregue una medida que devuelva la función DAX USERNAME. Puede asignarle un nombre similar a "Who Am I" (Quién soy). A continuación, agregue la medida a un objeto visual de tarjeta en un informe y publíquela en Power BI.

Los creadores y consumidores que solo tengan permiso de lectura en el modelo semántico solo podrán ver los datos que tienen permitido ver (según su asignación de roles RLS).

Cuando un usuario visualiza un informe en un área de trabajo o en una aplicación, el RLS puede aplicarse o no en función de los permisos de su modelo semántico. Por este motivo, es fundamental que los consumidores y creadores de contenidos solo posean permiso de lectura sobre el modelo semántico subyacente cuando deba aplicarse el RLS. Para obtener más información sobre las reglas de permisos que determinan si se aplica RLS, consulte el artículo Planeamiento de la seguridad del consumidor de informes.

Contenido relacionado

Para obtener más información sobre este artículo, consulte los recursos siguientes:

• Seguridad de nivel de fila (RLS) con Power BI
• Restricción del acceso a datos con seguridad de nivel de fila (RLS) en Power BI Desktop
• Relaciones de modelos en Power BI Desktop
• Planeación de la implementación de Power BI: Planeamiento de la seguridad del consumidor de informes
• ¿Tiene alguna pregunta? Pruebe a preguntar a la comunidad de Power BI
• ¿Sugerencias? Ideas para contribuir a mejorar Power BI