Papeles
se aplica a:
SQL Server Analysis Services Azure Analysis Services Fabric/Power BI Premium
Los roles de los modelos tabulares definen permisos de miembro para un modelo. Los miembros del rol pueden realizar acciones en el modelo según lo definido por el permiso de rol. Los roles definidos con permisos de lectura también pueden proporcionar más seguridad en el nivel de fila mediante filtros de nivel de fila.
En el caso de los modelos semánticos de Azure Analysis Services y Power BI, los usuarios deben estar en el identificador de Microsoft Entra. Los nombres de usuario y grupos se especifican mediante la dirección de correo electrónico de la organización o el nombre principal de usuario (UPN). Para SQL Server Analysis Services, los roles contienen miembros de usuario especificados por el nombre de usuario de Windows o por grupo de Windows y permisos (lectura, proceso, administrador).
Importante
Si usa Visual Studio para crear roles y agregar usuarios a un proyecto de modelo tabular que se implementará en Azure Analysis Services o Power BI, use área de trabajo integrada.
Importante
Para que los usuarios se conecten a un modelo implementado mediante una aplicación cliente de informes, debe crear al menos un rol que tenga al menos permiso de lectura. Agregue usuarios de la aplicación cliente de informes al rol como miembros.
La información de este artículo está pensada para los autores de modelos tabulares que definen roles mediante el cuadro de diálogo Administrador de roles en SSDT. Los roles definidos durante la creación de modelos se aplican a la base de datos del área de trabajo del modelo. Una vez implementada una base de datos modelo, los administradores de bases de datos de modelos pueden administrar (agregar, editar, eliminar) miembros de rol mediante SSMS.
Descripción de los roles
Los roles se usan en Analysis Services para administrar el acceso a datos del modelo. Hay dos tipos de roles:
El rol de servidor es un rol fijo que proporciona acceso de administrador a una instancia de servidor de Analysis Services. Los roles de servidor no se aplican a Power BI. En su lugar, Power BI usa roles de área de trabajo.
Los autores y administradores de la base de datos definen los roles de base de datos para controlar el acceso a una base de datos de modelo y a los datos de los usuarios.
Los roles definidos para un modelo tabular son roles de base de datos. Estos roles contienen usuarios o grupos que tienen permisos específicos que definen la acción que los miembros pueden realizar en la base de datos del modelo. Se crea un rol como un objeto independiente en la base de datos y solo se aplica a la base de datos en la que se crea el rol. El autor del modelo agrega usuarios y grupos al rol. De forma predeterminada, el autor del modelo tiene permisos de administrador en el servidor de bases de datos del área de trabajo; para un modelo implementado, un administrador agrega miembros de rol.
Los roles de los modelos tabulares se pueden definir aún más con filtros de fila, también conocidos como seguridad de nivel de fila. Los filtros de fila usan expresiones DAX para definir las filas de una tabla y las filas relacionadas en la muchas direcciones, que un usuario puede consultar. Los filtros de fila que usan expresiones DAX solo se pueden definir para los permisos Read y Read y Process. En Power BI, los roles de modelo se definen en Power BI Desktop y solo se aplican a la seguridad de nivel de fila. Para obtener más información, consulte filtros de fila más adelante en este artículo.
De forma predeterminada, al crear un nuevo proyecto de modelo tabular, el proyecto no tiene ningún rol definido. Los roles se definen mediante el cuadro de diálogo Administrador de roles en SSDT. Cuando se definen roles durante la creación de modelos, se aplican a la base de datos del área de trabajo del modelo. Cuando se implementa el modelo, se aplican los mismos roles al modelo implementado. Una vez implementado un modelo, los miembros del rol de servidor (administrador de Analysis Services) y los administradores de bases de datos pueden administrar los roles asociados con el modelo y los miembros asociados a cada rol mediante SSMS.
Permisos
Los permisos de rol descritos en esta sección solo se aplican a Azure Analysis Services y SQL Server Analysis Services. En Power BI, los permisos se definen para el modelo semántico. Para más información, consulte Administración del acceso al modelo semántico.
Cada rol tiene un único permiso de base de datos definido (excepto el permiso de lectura y proceso combinado). De forma predeterminada, un nuevo rol tiene el permiso Ninguno. Cuando los miembros se agregan a un rol que tiene el permiso Ninguno, no pueden modificar la base de datos, ejecutar una operación de proceso, consultar datos o ver la base de datos a menos que se conceda un permiso diferente.
Un grupo o usuario puede ser miembro de cualquier número de roles, cada rol que tenga un permiso diferente. Cuando un usuario es miembro de varios roles, los permisos definidos para cada rol son acumulativos. Por ejemplo, si un usuario es miembro de un rol con el permiso De lectura y también miembro de un rol con permiso None, ese usuario tiene permisos de lectura.
Cada rol puede tener uno de los siguientes permisos definidos:
| Permisos | Descripción | Filtros de fila mediante DAX |
|---|---|---|
| Ninguno | Los miembros no pueden realizar ningún cambio en el esquema de la base de datos del modelo y no pueden consultar datos. | Los filtros de fila no se aplican. No hay datos visibles para los usuarios de este rol |
| Leer | Los miembros pueden consultar datos (basados en filtros de fila), pero no pueden ver la base de datos del modelo en SSMS, no pueden realizar ningún cambio en el esquema de la base de datos del modelo y el usuario no puede procesar el modelo. | Se pueden aplicar filtros de fila. Solo los datos especificados en la fórmula DAX del filtro de fila son visibles para los usuarios. |
| Lectura y proceso | Los miembros pueden consultar datos (basados en filtros de nivel de fila) y ejecutar operaciones de proceso mediante la ejecución de un script o paquete que contiene un comando de proceso, pero no pueden realizar ningún cambio en la base de datos. Los usuarios con permiso no pueden ver la base de datos del modelo en SSMS. | Se pueden aplicar filtros de fila. Solo se pueden consultar los datos especificados en la fórmula DAX del filtro de fila. |
| Proceso | Los miembros pueden ejecutar operaciones de proceso mediante la ejecución de un script o paquete que contiene un comando de proceso. Los miembros no pueden modificar el esquema de la base de datos del modelo, no pueden consultar datos y no pueden consultar la base de datos del modelo en SSMS. | Los filtros de fila no se aplican. No se puede consultar ningún dato en este rol |
| Administrador | Los miembros pueden realizar modificaciones en el esquema del modelo y pueden consultar todos los datos en el diseñador de modelos, el cliente de informes y SSMS. | Los filtros de fila no se aplican. Todos los datos se pueden consultar en este rol. |
Nota
Los miembros con permisos de lectura y lectura y proceso pueden consultar datos basados en filtros de fila, pero no pueden ver la base de datos de modelos en SSMS. Los miembros no pueden realizar cambios en el esquema de la base de datos del modelo y no pueden procesar el modelo. Sin embargo, en SQL Server Analysis Services 2019 y versiones anteriores, los miembros pueden usar DMV para determinar las definiciones de medida. SQL Server Analysis Services 2022 y versiones posteriores bloquean el acceso a DMV para mejorar la seguridad.
Filtros de fila
Los filtros de fila, comúnmente conocidos como seguridad de nivel de fila en Power BI, definen qué filas de una tabla pueden consultar los miembros de un rol determinado. Los filtros de fila se definen para cada tabla de un modelo mediante fórmulas DAX.
Los filtros de fila solo se pueden definir para roles con permisos de de lectura y de lectura y proceso. De forma predeterminada, si un filtro de fila no está definido para una tabla determinada, los miembros de un rol que tenga permiso Leer o Leer y Procesar pueden consultar todas las filas de la tabla a menos que se aplique el filtrado cruzado de otra tabla.
Después de definir un filtro de fila para una tabla determinada, una fórmula DAX que se evalúa como un valor TRUE/FALSE, define las filas que pueden consultar los miembros de ese rol determinado. No se pueden consultar las filas no incluidas en la fórmula DAX. Por ejemplo, para los miembros del rol Sales, si la tabla Customers tiene la siguiente expresión de filtros de fila, =Customers [Country] = "USA", los miembros del rol Sales solo verán los clientes en ESTADOS UNIDOS.
Los filtros de fila se aplican a las filas especificadas, así como a las filas relacionadas. Cuando una tabla tiene varias relaciones, los filtros aplican seguridad para la relación que está activa. Los filtros de fila se intersecarán con otros archivadores de fila definidos para las tablas relacionadas, por ejemplo:
| Mesa | Expresión DAX |
|---|---|
| Región | =Region[Country]="USA" |
| ProductCategory | =ProductCategory[Name]="Bicycles" |
| Transacciones | =Transacciones[Año]=2020 |
El efecto neto de estos permisos en la tabla Transacciones es que los miembros pueden consultar filas de datos en los que el cliente está en estados Unidos, y la categoría de producto es bicicletas y el año es 2020. Los usuarios no pueden consultar ninguna transacción fuera de EE. UU., ni ninguna transacción que no sea bicicleta o ninguna transacción que no esté en 2020 a menos que sean miembros de otro rol que conceda estos permisos.
Puede usar el filtro, =FALSE(), para denegar el acceso a todas las filas de una tabla completa.
Para más información sobre los roles de modelo en Power BI, consulte seguridad de nivel de fila en Power BI.
Seguridad dinámica
La seguridad dinámica permite definir la seguridad de nivel de fila en función del nombre de usuario del usuario que ha iniciado sesión actualmente o de la propiedad CustomData devuelta desde una cadena de conexión. Para implementar la seguridad dinámica, debe incluir una tabla con valores de inicio de sesión (nombre de usuario de Windows) para los usuarios, así como un campo que se pueda usar para definir un permiso determinado en el modelo. Por ejemplo, incluya una tabla dimEmployees con un identificador de inicio de sesión (dominio\nombredeusuario) así como un valor de departamento para cada empleado del modelo.
Para implementar la seguridad dinámica, puede usar las siguientes funciones como parte de una fórmula DAX para devolver el nombre de usuario del usuario que inició sesión actualmente o la propiedad CustomData en una cadena de conexión:
| Función | Descripción |
|---|---|
| función USERNAME (DAX) | Devuelve el dominio\nombre de usuario del usuario que ha iniciado sesión actualmente. |
| función CUSTOMDATA (DAX) | Devuelve la propiedad CustomData en una cadena de conexión. |
Puede usar la función LOOKUPVALUE para devolver valores para una columna donde el nombre de usuario de Windows es el mismo que el nombre de usuario devuelto por la función USERNAME o una cadena devuelta por la función CustomData. Las consultas se pueden restringir en las que los valores devueltos por LOOKUPVALUE coinciden con los valores de la misma tabla o relacionada.
Por ejemplo, con esta fórmula:
='dimDepartment'[DepartmentId]=LOOKUPVALUE('dimEmployees'[DepartmentId], 'dimEmployees'[LoginId], USERNAME(), 'dimEmployees'[LoginId], 'dimDepartment'[DepartmentId])
La función LOOKUPVALUE devuelve valores para la columna dimEmployees[DepartmentId] donde dimEmployees[LoginId] es el mismo que el LoginID del usuario que ha iniciado sesión actualmente, devuelto por USERNAME y los valores de dimEmployees[DepartmentId] son los mismos que los valores de dimDepartment[DepartmentId]. Los valores de DepartmentId devueltos por LOOKUPVALUE se usan para restringir las filas consultadas en la tabla dimDepartment y las tablas relacionadas con DepartmentId. Solo se devuelven las filas donde DepartmentId está en los valores de departmentId devueltos por la función LOOKUPVALUE.
dimEmployees
| LastName | FirstName | LoginId | DepartmentName | DepartmentId |
|---|---|---|---|---|
| Marrón | Kevin | Adventure-works\kevin0 | Marketing | 7 |
| Bradley | David | Adventure-works\david0 | Marketing | 7 |
| Dobney | JoLynn | Adventure-works\JoLynn0 | Producción | 4 |
| Baretto DeMattos | Paula | Adventure-works\Paula0 | Recursos humanos | 2 |
dimDepartment
| DepartmentId | DepartmentName |
|---|---|
| 1 | Corporativo |
| 2 | Administración general y ejecutiva |
| 3 | Administración del inventario |
| 4 | Fabricación |
| 5 | Garantía de calidad |
| 6 | Investigación y desarrollo |
| 7 | Ventas y marketing |
Probar roles
Al crear un proyecto de modelo en Visual Studio, puede usar la característica Analizar en Excel para probar la eficacia de los roles que ha definido. En el menú modelo de
Roles de scripting
Los roles para los modelos implementados y los modelos semánticos se pueden crear scripts mediante lenguaje de scripting de modelos tabulares (TMSL) para crear o modificar el objeto roles de . Los scripts TMSL se pueden ejecutar en SSMS o con el cmdlet invoke-ASCmd PowerShell.
Consulte también
crear y administrar roles
perspectivas de
Analizar en Excel
función USERNAME (DAX)
función LOOKUPVALUE (DAX)
función CUSTOMDATA (DAX)