Restricción del acceso a los datos de modelo de Power BI
Como modelador de datos, configure 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 imponen filtros en tablas del modelo mediante expresiones de filtro DAX (Data Analysis Expressions).
Nota:
De forma predeterminada, un modelo de datos no tiene roles. Un modelo de datos sin roles significa que los usuarios (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 que pueda ver todos los datos.
Puede crear, validar y administrar roles en Power BI Desktop. Para los modelos de Azure Analysis Services o SQL Server Analysis Services, puede 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 editor tabular.
Para comprender mejor cómo RLS restringe el acceso a los datos, vea la siguiente imagen animada.
Aplicar principios de diseño de esquema de estrella
Se recomienda aplicar principios de diseño de esquema de estrella para generar un modelo que comprende tablas de dimensiones y hechos. Es habitual configurar Power BI para aplicar reglas que filtren 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 en 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 vendedor. 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 ejemplos presentados en esta unidad.
Definir reglas
Las expresiones de regla se evalúan dentro del contexto de la fila. El 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 que sean 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 a los datos de las ventas del Medio Oeste.
'Region'[Region] = "Midwest"
En los pasos siguientes se explica cómo Power BI aplica la regla. TI:
Filtra la tabla Region , lo que da como resultado una fila visible (para Midwest).
Usa la relación del modelo para propagar el filtro de tabla Region a la tabla State , lo que da como resultado 14 filas visibles (la región midwest comprende 14 estados).
Usa la relación del modelo para propagar el filtro de la tabla State a la tabla Sales, lo que da lugar a miles de filas visibles (los datos de ventas de los estados que pertenecen a la región del Midwest).
La regla estática más sencilla que puede crear restringe el acceso a todas las filas de tabla. Tenga en cuenta la siguiente regla aplicada 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 tabla. Podría ser útil cuando se permite a los vendedores ver los resultados agregados de ventas (de la tabla Ventas ), pero no los detalles de nivel de pedido.
Definir reglas estáticas es sencilla y eficaz. Considere la posibilidad de usarlos cuando necesite crear solo algunos de ellos, como podría ser el caso en Adventure Works, donde solo hay seis regiones de EE. UU. Sin embargo, tenga en cuenta las desventajas: la configuración de reglas estáticas puede implicar un esfuerzo significativo para crear y configurar. También requeriría actualizar y volver a publicar el conjunto de datos cuando se incorporen nuevas regiones.
Si hay muchas reglas para configurar y prevé agregar nuevas reglas en el futuro, considere la posibilidad de crear 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). Los valores de entorno se devuelven de tres funciones DAX específicas:
USERNAME o USERPRINCIPALNAME : devuelve el usuario autenticado de Power BI como un valor de texto.
CUSTOMDATA : devuelve la propiedad CustomData pasada en la cadena de conexión. Las herramientas de informes que no son de 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 al usuario en el formato DOMAIN\username 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) del usuario, como [email protected]. Como alternativa, puede usar la función USERPRINCIPALNAME, que siempre devuelve al usuario en el formato de 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 Region propaga filtros de la tabla AppUser .
La siguiente regla aplicada a la tabla AppUser restringe el acceso a los datos a las regiones del usuario autenticado.
'AppUser'[UserName] = USERPRINCIPALNAME()
Definir reglas dinámicas es sencilla y eficaz cuando una tabla de modelo almacena valores de nombre de usuario. Permiten aplicar un diseño RLS controlado por datos. Por ejemplo, cuando se agregan o quitan vendedores de la tabla AppUser (o se asignan a regiones diferentes), este enfoque de diseño solo funciona.
Validación de roles
Al crear 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, hay la vista como función que 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 con antelación a los usuarios que acceden 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
Siempre que 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 sobre los administradores de la red.
En el caso de los modelos desarrollados de Power BI Desktop, la asignación de roles se realiza normalmente en el servicio Power BI. En el caso de los modelos de Azure Analysis Services o SQL Server Analysis Services, la asignación de roles se realiza normalmente en SSMS.
Para obtener más información sobre cómo configurar RLS, consulte:
Uso del inicio de sesión único (SSO) para orígenes de DirectQuery
Cuando tu modelo de datos tiene tablas de DirectQuery y su origen de datos admite SSO, 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 base de datos Azure SQL para sus operaciones de ventas que reside en el mismo entorno que Power BI. La base de datos exige que RLS controle el acceso a las filas de varias tablas de 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 del 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. El origen de datos aplica entonces RLS en función de la identidad del consumidor del informe.
Para obtener información sobre RLS de 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 se admiten en el servicio Power BI.
Para más información sobre las fuentes de datos que admiten SSO, consulte Inicio de sesión único (SSO) para fuentes de DirectQuery.