Autorización del acceso a objetos y operaciones (Analysis Services)

se aplica a: SQL Server Analysis Services Azure Analysis Services Fabric/Power BI Premium

Los usuarios no administrativos obtienen acceso a cubos, dimensiones y modelos de minería de datos dentro de una base de datos de SQL Server Analysis Services al ser miembros de uno o varios roles de base de datos. Los administradores de SQL Server Analysis Services crean estos roles de base de datos, conceden permisos de lectura o de lectura y escritura en objetos de SQL Server Analysis Services, y asignan usuarios y grupos de Microsoft Windows a cada rol.

SQL Server Analysis Services determina los permisos efectivos para un usuario o grupo de Windows específicos mediante la combinación de los permisos asociados a cada rol de base de datos al que pertenece el usuario o grupo. Como resultado, si un rol de base de datos no concede a un usuario o grupo permiso para ver una dimensión, medida o atributo, pero un rol de base de datos diferente concede a ese usuario o grupo permiso, el usuario o grupo tiene permiso para ver el objeto.

Importante

Los miembros del rol administrador del servidor de SQL Server Analysis Services y los miembros de un rol de base de datos con permisos de control total (administrador) pueden acceder a todos los datos y metadatos de la base de datos y no necesitan permisos adicionales para ver objetos específicos. Además, los miembros del rol de servidor de SQL Server Analysis Services no se pueden denegar el acceso a ningún objeto de ninguna base de datos ni a los miembros de un rol de base de datos de SQL Server Analysis Services que tenga permisos de control total (administrador) dentro de una base de datos no se puede denegar el acceso a ningún objeto de esa base de datos. Las operaciones administrativas especializadas, como el procesamiento, se pueden autorizar a través de roles independientes con menos permisos. Consulte Permisos de proceso de concesión (Analysis Services) para más detalles.

Enumeración de roles definidos para la base de datos

Los administradores pueden ejecutar una consulta de DMV simple en SQL Server Management Studio para obtener una lista de todos los roles definidos en el servidor.

  1. En SSMS, haga clic con el botón derecho en una base de datos y seleccione New Query MDX ( Nueva consulta | MDX).

  2. Escriba la consulta siguiente y presione F5 para ejecutar:

    Select * from $SYSTEM.DBSCHEMA_CATALOGS  
    

    Los resultados incluyen el nombre de la base de datos, la descripción, el nombre del rol y la fecha de última modificación. Con esta información como punto de partida, puede continuar con bases de datos individuales para comprobar la pertenencia y los permisos de un rol específico.

Visión general jerárquica de la autorización de Analysis Services

En esta sección se describe el flujo de trabajo básico para configurar permisos.

Paso 1: Administración del servidor

Como primer paso, decida quién tendrá derechos de administrador en el nivel de servidor. Durante la instalación, se requiere el administrador local que instala SQL Server para especificar una o varias cuentas de Windows como administrador del servidor de Analysis Services. Los administradores del servidor tienen todos los permisos posibles en un servidor, incluido el permiso para ver, modificar y eliminar cualquier objeto del servidor o ver los datos asociados. Una vez completada la instalación, un administrador del servidor puede agregar o quitar cuentas para cambiar la pertenencia a este rol. Consulte Concesión de derechos de administrador del servidor a una instancia de Analysis Services para obtener más información sobre este nivel de permisos.

Paso 2: Administración de bases de datos

A continuación, después de crear una solución tabular o multidimensional, impleméntela en el servidor como una base de datos. Un administrador del servidor puede delegar tareas de administración de bases de datos mediante la definición de un rol que tenga permisos de control total para la base de datos. Los miembros de este rol pueden procesar o consultar objetos en la base de datos, así como crear roles adicionales para acceder a cubos, dimensiones y otros objetos dentro de la propia base de datos. Para obtener más información, consulte Concesión de permisos de base de datos (Analysis Services).

Paso 3: Habilite el acceso al cubo o al modelo para cargas de trabajo de consulta y procesamiento

De forma predeterminada, solo los administradores de servidores y bases de datos tienen acceso a cubos o modelos tabulares. Para que estas estructuras de datos estén disponibles para otras personas de la organización, asigne roles adicionales que asignen cuentas de usuario y grupo de Windows a cubos o modelos, junto con permisos que especifican privilegios de lectura. Para obtener más información, consulte Conceder permisos de cubo o modelo (Analysis Services).

Puede aislar las tareas de procesamiento de otras funciones administrativas. Este aislamiento permite a los administradores de servidores y de bases de datos delegar esta tarea en otras personas o configurar el procesamiento desatendido especificando cuentas de servicio que ejecutan software de programación de tareas. Para obtener más información, consulte Conceder permisos de procesamiento (Analysis Services).

Nota:

Los usuarios no necesitan permisos para las tablas relacionales de la base de datos relacional subyacente desde la que SQL Server Analysis Services carga sus datos. Tampoco necesitan permisos de nivel de archivo en el equipo en el que se ejecuta la instancia de SQL Server Analysis Services.

Paso 4 (opcional): Permitir o denegar el acceso a objetos de cubo interior

SQL Server Analysis Services proporciona opciones de seguridad para establecer permisos en objetos individuales, incluidos miembros de dimensión y celdas dentro de un modelo de datos. Para obtener más información, vea Conceder acceso personalizado a los datos de dimensión (Analysis Services) y Conceder acceso personalizado a los datos de celda (Analysis Services).

También puede variar los permisos en función de la identidad del usuario. Esta variación se conoce a menudo como seguridad dinámica y se implementa mediante la función UserName (MDX).

procedimientos recomendados

Para administrar mejor los permisos, use un enfoque similar a los pasos siguientes:

  1. Cree roles por función (por ejemplo, dbadmin, cubedeveloper, processadmin) para que quien mantenga los roles pueda ver de un vistazo lo que permite el rol. Como se indicó en otra parte, puede definir roles en la definición del modelo, conservando esos roles en las implementaciones de soluciones posteriores.

  2. Cree un grupo de seguridad de Windows correspondiente en Active Directory y, a continuación, mantenga el grupo de seguridad en Active Directory para asegurarse de que contiene las cuentas individuales adecuadas. Este enfoque coloca la responsabilidad de la pertenencia a grupos de seguridad en especialistas de seguridad que ya tienen competencia con las herramientas y los procesos usados para el mantenimiento de cuentas en su organización.

  3. Genere scripts en SQL Server Management Studio para que pueda replicar rápidamente las asignaciones de roles siempre que el modelo se vuelva a implementar desde sus archivos de origen en un servidor. Consulte Conceder permisos de cubo o modelo (Analysis Services) para obtener más información sobre cómo generar rápidamente un script.

  4. Adopte una convención de nomenclatura que refleje el ámbito y la pertenencia al rol. Los nombres de rol solo se ven en las herramientas de diseño y de administración, por tanto, use una convención de nomenclatura que tenga sentido para los especialistas en seguridad de cubos. Por ejemplo, processadmin-windowsgroup1 indica el acceso de lectura, además de los derechos de procesamiento, a las personas de su organización cuyas cuentas de usuario individuales de Windows son miembros del grupo de seguridad windowsgroup1 .

    Incluir información de cuenta puede ayudarle a realizar un seguimiento de las cuentas que se usan en varios roles. Dado que los roles son aditivos, los roles combinados asociados a windowsgroup1 constituyen el conjunto de permisos efectivo para las personas que pertenecen a ese grupo de seguridad.

  5. Los desarrolladores de cubos requieren permisos de control total para los modelos y las bases de datos en desarrollo, pero solo necesitan permisos de lectura una vez que se implementa una base de datos en un servidor de producción. Recuerde desarrollar definiciones y asignaciones de roles para todos los escenarios, incluidas las implementaciones de desarrollo, pruebas y producción.

Si aplica un enfoque como este, minimizará los cambios en las definiciones de rol y las pertenencias a roles del modelo, y además aportará visibilidad a las asignaciones de rol, lo cual facilita la implementación y mantenimiento de los permisos para los cubos.

Consulte también

Concesión de derechos de administrador del servidor a una instancia de Analysis Services
Roles y permisos (Servicios de Análisis)
Metodologías de autenticación compatibles con Analysis Services