Cómo autorizar el acceso a objetos y operaciones (Analysis Services)

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

El acceso de usuarios no administrativos a cubos, dimensiones y modelos de minería de datos dentro de una base de datos de SQL Server Analysis Services se concede mediante la pertenencia a uno o varios roles de base de datos. SQL Server Analysis Services los administradores crean estos roles de base de datos, conceden permisos de lectura o lectura y escritura en objetos SQL Server Analysis Services y, a continuación, asignan usuarios y grupos de Microsoft Windows a cada rol.

SQL Server Analysis Services determina los permisos efectivos para un usuario o grupo específicos de Windows mediante la combinación de los permisos asociados a cada rol de base de datos al que pertenece el usuario o grupo. En consecuencia, si un rol de base de datos no concede a un usuario o grupo permiso para ver una dimensión, medida o atributo y otro rol diferente sí lo hace, el usuario o grupo tendrá 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 que tienen permisos de control total (administrador) pueden tener acceso 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 y 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 pueden denegarse el acceso a ningún objeto dentro de esa base de datos. Se pueden autorizar operaciones administrativas especializadas, como el procesamiento, a través de roles independientes con menos permisos. Consulte Concesión de permisos de proceso (Analysis Services) para obtener más información.

Lista de roles definidos para la base de datos

Los administradores pueden ejecutar una simple consulta DMV 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 siguiente consulta y presione F5 para ejecutar:

   Select * from $SYSTEM.DBSCHEMA_CATALOGS  
   

   Los resultados incluyen el nombre de la base de datos, una descripción, el nombre de los roles y la fecha de la última modificación. Con esta información como punto de partida, puede ir a bases de datos individuales para comprobar la pertenencia y los permisos de un rol concreto.

Introducción general descendente a las autorizaciones en Analysis Services

Esta sección trata sobre el flujo de trabajo básico para configurar permisos.

Paso 1: Administración de servidores

El primer paso es decidir quién tendrá derechos de administrador en el nivel de servidor. Durante la instalación, el administrador local que instala SQL Server debe especificar una o varias cuentas de Windows como el administrador de servidor de Analysis Services. Los administradores de servidor cuentan con todos los permisos posibles para un servidor, lo cual incluye los permisos para ver, modificar y eliminar cualquier objeto del servidor o para ver los datos asociados. Una vez se ha completado la instalación, los administradores de servidor pueden agregar o quitar cuentas para cambiar la pertenencia de 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 crearse una solución tabular o multidimensional, se implementa en el servidor como base de datos. Un administrador de servidor puede delegar tareas de administración de base de datos; para ello, debe definir un rol que tenga permisos de Control total para la base de datos relevante. Los miembros que pertenecen a este rol pueden procesar o consultar objetos en la base de datos, así como crear roles adicionales para obtener acceso a cubos, dimensiones y otros objetos de la base de datos. Consulte Concesión de permisos de base de datos (Analysis Services) para obtener más información.

Paso 3: Permitir el acceso de cubos o modelos para las cargas de trabajo de procesamiento y consulta

De forma predeterminada, solo los administradores del servidor y la base de datos tienen acceso a los cubos o los modelos tabulares. Con el fin de que estas estructuras de datos se encuentren disponibles para otras personas de la organización, se deben hacer otras asignaciones de rol que hagan corresponder cuentas de usuario y grupo de Windows a cubos o modelos, junto con los permisos que especifiquen privilegios de Read . Consulte Conceder permisos de cubo o modelo (Analysis Services) para obtener más información.

Las tareas de procesamiento se pueden aislar de otras funciones administrativas, de forma que los administradores de servidor y de base de datos puedan delegar esta tarea a otras personas o bien, configurar un procesamiento desatendido mediante la especificación de cuentas de servicio que ejecuten software de programación. Consulte Concesión de permisos de proceso (Analysis Services) para obtener más información.

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 y no requieren 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 interiores del cubo

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 modificar permisos de acuerdo a la identidad del usuario. Esto se conoce a menudo como seguridad dinámica y se implementa mediante la función UserName (MDX).

Procedimientos recomendados

Para administrar con más eficacia los permisos, se recomienda un enfoque similar al siguiente:

1. Cree roles según la función (por ejemplo, dbadmin, cubedeveloper, processadmin), de forma que independientemente de quien ostente el rol, pueda ver rápidamente lo que permite hacer dicho rol. Según se dijo anteriormente, se pueden definir los roles en la definición del modelo, de forma que esos roles se mantienen en implementaciones posteriores de la solución.

2. Cree el correspondiente grupo de seguridad de Windows en Active Directory y, posteriormente, conserve este grupo de seguridad en Active Directory para garantizar que contiene las cuentas individuales apropiadas. De esta forma, la responsabilidad de la pertenencia a grupos de seguridad recaerá sobre especialistas en seguridad que ya tienen amplia experiencia con las herramientas y procesos que se usan para el mantenimiento de las cuentas en la 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 a 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 del 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 acceso de lectura y derechos de procesamiento para las personas de la organización cuyas cuentas de usuario de Windows individuales pertenezcan al grupo de seguridad windowsgroup1 .

   Si incluye información sobre la cuenta le resultará útil para llevar un seguimiento de las cuentas que se usan en los diversos roles. Dado que los roles se van sumando unos a otros, los roles combinados asociados a windowsgroup1 componen el conjunto efectivo de permisos para las personas que pertenecen a ese grupo de seguridad.

5. Los desarrolladores de cubos necesitarán permisos de Control total para los modelos y bases de datos en desarrollo, pero únicamente necesitarán permisos de Lectura una vez que se haya incorporado una base de datos en un servidor de producción. Recuerde crear definiciones y asignaciones de rol para todos los escenarios, lo cual incluye implementaciones de desarrollo, prueba 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 (Analysis Services)
Metodologías de autenticación admitidas por Analysis Services