Compartir a través de


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

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

Analysis Services determina los permisos efectivos de 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. 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 tendrá permiso para ver el objeto.

Importante

Los miembros del rol Administrador del servidor de Analysis Services y los miembros de un rol de base de datos que tienen 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 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 Analysis Services que tenga permisos de control total (administrador) dentro de una base de datos no se pueden denegar el acceso a ningún objeto dentro de esa base de datos. Las operaciones administrativas especializadas, como el procesamiento, se pueden autorizar a través de roles independientes que tengan menos permisos. Consulte Concesión de permisos de proceso (Analysis Services) para obtener más información.

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.

Información general de arriba abajo 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 Conceder permisos de administrador del servidor (Analysis Services) para obtener más información sobre este nivel de permisos.

Paso 2: Administración de bases de datos

Después de crear una solución tabular o multidimensional, se implementa en el servidor como una base de datos. Un administrador del servidor puede delegar tareas de administración de bases de datos definiendo un rol que tenga permisos de control total para la base de datos en cuestión. 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. Consulte Concesión de permisos de base de datos (Analysis Services) para obtener más información.

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

De forma predeterminada, solo los administradores de servidores y bases de datos tienen acceso a cubos o modelos tabulares. Hacer que estas estructuras de datos estén disponibles para otras personas de la organización requiere asignaciones de roles adicionales que asignen cuentas de usuario y grupo de Windows a cubos o modelos, junto con permisos que especifican Read privilegios. Consulte el documento 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, lo que permite a los administradores de servidores y bases de datos delegar esta tarea a otras personas o configurar el procesamiento desatendido especificando cuentas de servicio que ejecutan software de programación. Consulte Otorgar permisos de proceso (Analysis Services) para obtener más información.

Nota:

Los usuarios no requieren ningún permiso para las tablas relacionales de la base de datos relacional subyacente desde la que Analysis Services carga sus datos y no requieren permisos de nivel de archivo en el equipo en el que se ejecuta la instancia de Analysis Services.

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

Analysis Services proporciona una configuración 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, consulte 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. Esto se conoce a menudo como seguridad dinámica y se implementa mediante la función UserName (MDX)

procedimientos recomendados

Para administrar mejor los permisos, se recomienda un enfoque similar al siguiente:

  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 mantenga el grupo de seguridad en Active Directory para asegurarse de que contiene las cuentas individuales adecuadas. Esto coloca la responsabilidad de la pertenencia a grupos de seguridad en especialistas en 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 roles solo son visibles en las herramientas de diseño y administración, por lo que utilice una convención de nombres 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 requerirán permisos de control total para los modelos y bases de datos en desarrollo, pero solo necesitarán permisos de lectura una vez que se implemente 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.

El uso de un enfoque como este minimiza los cambios en las definiciones de roles y la pertenencia a los roles en el modelo, y proporciona visibilidad sobre las asignaciones de roles que facilitan la implementación y el mantenimiento de los permisos de cubos.

Véase también

Concesión de permisos de administrador del servidor (Analysis Services)
Roles y permisos (Servicios de Análisis)
Metodologías de autenticación admitidas por Analysis Services