Restricción del acceso a los datos de modelo de Power BI
Como modelador de datos, configura RLS mediante la creación de uno o varios roles. Un rol tiene un nombre único en el modelo y normalmente incluye una o varias reglas. Las reglas aplican filtros en las tablas del modelo mediante expresiones de filtro de DAX (expresiones de análisis de datos).
Nota
De forma predeterminada, un modelo de datos no tiene roles. Un modelo de datos sin roles significa que los usuarios (los que tienen permiso para consultar el modelo de datos) tienen acceso a todos los datos del modelo.
Sugerencia
Es posible definir un rol que no incluya ninguna regla. En este caso, el rol proporciona acceso a todas las filas de todas las tablas del modelo. Esta configuración de roles sería adecuada para un usuario administrador con permiso para ver todos los datos.
Puede crear, validar y administrar roles en Power BI Desktop. En el caso de los modelos de Azure Analysis Services o SQL Server Analysis Services, se pueden crear, validar y administrar roles mediante SQL Server Data Tools (SSDT).
También puede crear y administrar roles mediante SQL Server Management Studio (SSMS), o mediante una herramienta de terceros, como Tabular Editor.
Para comprender mejor cómo restringe RLS el acceso a los datos, vea la siguiente imagen animada.
Aplicación de principios de diseño de esquemas de estrella
Se recomienda aplicar principios de diseño de esquemas de estrella para generar un modelo que comprenda tablas de hechos y de dimensiones. Es habitual configurar Power BI para aplicar reglas que filtran las tablas de dimensiones, lo que permite que las relaciones del modelo propaguen eficazmente esos filtros a las tablas de hechos.
La siguiente imagen es el diagrama del modelo de datos de análisis de ventas de Adventure Works. Muestra un diseño de esquema de estrella que consta de una sola tabla de hechos denominada Sales. Las demás tablas son tablas de dimensiones que admiten el análisis de medidas de ventas por fecha, territorio de ventas, cliente, revendedor, pedido, producto y comercial. Observe las relaciones del modelo que conectan todas las tablas. Estas relaciones propagan filtros (directa o indirectamente) a la tabla Sales.
Este diseño de modelo admite los ejemplos que se presentan en esta unidad.
Definición de reglas
Las expresiones de regla se evalúan dentro del contexto de fila. Contexto de fila significa que la expresión se evalúa para cada fila mediante los valores de columna de esa fila. Cuando la expresión devuelve TRUE, el usuario puede "ver" la fila.
Sugerencia
Para más información sobre el contexto de fila, consulte el módulo Incorporación de tablas y columnas calculadas a modelos de Power BI Desktop. Aunque en este módulo se describe cómo agregar cálculos de modelo, incluye una unidad que presenta y describe el contexto de fila.
Puede definir reglas estáticas o dinámicas.
Reglas estáticas
Las reglas estáticas usan expresiones DAX que hacen referencia a constantes.
Tenga en cuenta la siguiente regla aplicada a la tabla Región que restringe el acceso de datos a las ventas de Midwest.
'Region'[Region] = "Midwest"
En los pasos siguientes se explica cómo aplica la regla Power BI. Este:
Filtra la tabla Región, lo que da como resultado una fila visible (para Midwest).
Usa la relación del modelo para propagar el filtro de tabla Región a la tabla Estado, lo que da lugar a 14 filas visibles (la región de Midwest consta de 14 estados).
Usa la relación de modelo para propagar el filtro de tabla Estado a la tabla Ventas, lo que da lugar a miles de filas visibles (los hechos de ventas de los estados que pertenecen a la región de Midwest).
La regla estática más sencilla que puede crear restringe el acceso a todas las filas de tabla. Considere la posibilidad de aplicar la siguiente regla a la tabla Detalles de ventas (no se muestra en el diagrama del modelo).
FALSE()
Esta regla garantiza que los usuarios no puedan acceder a ningún dato de la tabla. Podría ser útil si se permite al personal de ventas ver los resultados de ventas agregados (de la tabla Ventas), pero no los detalles en el nivel de pedido.
La definición de reglas estáticas es sencilla y eficaz. Considere la posibilidad de usarlas aunque solo necesite algunas de ellas, como podría ser el caso de Adventure Works, donde solo hay seis regiones de EE. UU. Sin embargo, sea consciente de las desventajas: la configuración de reglas estáticas puede implicar un esfuerzo significativo de creación y configuración. También requeriría actualizar y volver a publicar el conjunto de datos cuando se incorporen nuevas regiones.
Si hay muchas reglas que configurar y prevé que se agregarán nuevas reglas en el futuro, considere la posibilidad de usar reglas dinámicas en su lugar.
Reglas dinámicas
Las reglas dinámicas usan funciones DAX específicas que devuelven valores de entorno (en lugar de constantes). Tres funciones DAX específicas devuelven los valores de entorno:
USERNAME o USERPRINCIPALNAME: devuelve el usuario autenticado de Power BI como un valor de texto.
CUSTOMDATA: devuelve el contenido de la propiedad CustomData en la cadena de conexión. Las herramientas de informes que no son Power BI que se conectan al conjunto de datos mediante una cadena de conexión pueden establecer esta propiedad, como Microsoft Excel.
Nota
Tenga en cuenta que la función USERNAME devuelve el usuario con el formato DOMINIO\nombre de usuario cuando se usa en Power BI Desktop. Sin embargo, cuando se usa en el servicio Power BI, devuelve el formato del nombre principal de usuario (UPN), como username@adventureworks.com. Como alternativa, puede usar la función USERPRINCIPALNAME, que siempre devuelve el usuario en el formato del nombre principal de usuario.
Considere un diseño de modelo revisado que ahora incluye la tabla AppUser (oculta). Cada fila de la tabla AppUser describe un nombre de usuario y una región. Una relación de modelo con la tabla Región propaga los filtros de la tabla AppUser.
Si se aplica la siguiente regla a la tabla AppUser se restringe el acceso de datos a las regiones del usuario autenticado.
'AppUser'[UserName] = USERPRINCIPALNAME()
La definición de reglas dinámicas es sencilla y eficaz cuando una tabla de modelo almacena los valores de nombre de usuario. Permite aplicar un diseño RLS controlado por datos. Por ejemplo, cuando se agregan vendedores a la tabla AppUser o se eliminan de esta (o se asignan a regiones diferentes), este enfoque de diseño funciona con normalidad.
Validación de roles
Cuando crea roles, es importante probarlos para asegurarse de que aplican los filtros correctos. En el caso de los modelos de datos creados en Power BI Desktop, la función Ver como le permite ver el informe cuando se aplican distintos roles y se pasan valores de nombre de usuario diferentes.
Configuración de las asignaciones de roles
Las asignaciones de roles deben configurarse de antemano para que los usuarios accedan al contenido de Power BI. La asignación de roles implica asignar objetos de seguridad de Microsoft Entra a los roles. Los objetos de seguridad pueden ser cuentas de usuario o grupos de seguridad.
Sugerencia
Cuando sea posible, se recomienda asignar roles a grupos de seguridad. De este modo, habrá menos asignaciones y puede delegar la administración de pertenencia a grupos a los administradores de red.
En el caso de los modelos desarrollados de Power BI Desktop, la asignación se realiza normalmente en el servicio Power BI. En los modelos de Azure Analysis Services o SQL Server Analysis Services, la asignación de roles se realiza normalmente en SSMS.
Para más información acerca de cómo configurar RLS, consulte:
Uso del inicio de sesión único (SSO) para orígenes de DirectQuery
Cuando el modelo de datos tiene tablas de DirectQuery y su origen de datos admite el inicio de sesión único, el origen de datos puede aplicar permisos de datos. De este modo, la base de datos aplica RLS, y los conjuntos de datos e informes de Power BI respetan la seguridad del origen de datos.
Tenga en cuenta que Adventure Works tiene una instancia de Azure SQL Database para sus operaciones de ventas que residen en el mismo inquilino que Power BI. La base de datos aplica RLS para controlar el acceso a las filas de varias tablas de la base de datos. Puede crear un modelo de DirectQuery que se conecte a esta base de datos sin roles y publicarlo en el servicio Power BI. Al establecer las credenciales del origen de datos en el servicio Power BI, habilite el inicio de sesión único. Cuando los consumidores de informes abren informes de Power BI, Power BI pasa su identidad al origen de datos. A continuación, el origen de datos aplica RLS en función de la identidad del consumidor del informe.
Para obtener información sobre RLS en Azure SQL Database, consulte Seguridad de nivel de fila.
Nota
Las tablas calculadas y las columnas calculadas que hacen referencia a una tabla DirectQuery desde un origen de datos con autenticación SSO no son compatibles con el servicio Power BI.
Para más información sobre los orígenes de datos que admiten SSO, consulte Inicio de sesión único (SSO) para orígenes de DirectQuery.