Eventos
31 mar, 23 - 2 abr, 23
El último evento dirigido por la comunidad de Power BI, Fabric, SQL y AI. 31 de marzo - 2 de abril. Use el código MSCUST para un descuento de 150 USD. Los precios sube el 11 de febrero.
Regístrate hoyEste explorador ya no se admite.
Actualice a Microsoft Edge para aprovechar las características y actualizaciones de seguridad más recientes, y disponer de soporte técnico.
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).
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).
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:
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.
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.
Una vez publicado en Power BI, debe asignar miembros a roles de modelo semántico. 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 administrar las pertenencias a grupos de seguridad en el identificador de Microsoft Entra. Posiblemente, delega la tarea a los administradores de red.
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()
)
)
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 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.
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:
Sin embargo, hay desventajas asociadas a evitar RLS:
Si RLS produce resultados inesperados, compruebe los siguientes problemas:
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.
Para obtener más información sobre este artículo, consulte los recursos siguientes:
Eventos
31 mar, 23 - 2 abr, 23
El último evento dirigido por la comunidad de Power BI, Fabric, SQL y AI. 31 de marzo - 2 de abril. Use el código MSCUST para un descuento de 150 USD. Los precios sube el 11 de febrero.
Regístrate hoyCursos
Módulo
Implementación de la seguridad de nivel de fila - Training
La seguridad de nivel de fila (RLS) permite crear un único informe, o un conjunto de ellos, destinado a los datos de un usuario concreto. En este módulo, aprenderá a implementar la RLS mediante un método estático o dinámico, y cómo Microsoft Power BI simplifica las pruebas de RLS en Power BI Desktop y el servicio Power BI.
Certificación
Microsoft Certified: Power BI Data Analyst Associate - Certifications
Demostrar métodos y procedimientos recomendados que se alinean con los requisitos empresariales y técnicos para modelar, visualizar y analizar datos con Microsoft Power BI.