Autorizar el acceso a objetos y operaciones (Analysis Services)

El acceso de los usuarios no administrativos a los cubos, dimensiones y modelos de minería de datos de una base de datos de Analysis Services se obtiene 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 de Lectura y escritura en objetos de Analysis Services y luego asignan usuarios y grupos de Microsoft Windows a cada rol.

Analysis Services establece los permisos efectivos para un usuario o grupo específico de Windows al combinar los permisos que están asociados con cada rol de base de datos al que el usuario o grupo pertenece. 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 de administrador del servidor de Analysis Services y los miembros del rol de base de datos que tienen los permisos de Control total (administrador) pueden acceder a todos los datos y metadatos en la base de datos, y no necesitan permisos adicionales para ver objetos específicos. Además, a los miembros del rol de servidor de Analysis Services no se les puede denegar el acceso a ningún objeto de ninguna base de datos. Asimismo, a los miembros de un rol de base de datos de Analysis Services que tenga los permisos de Control total (administrador) no se les puede denegar el acceso a ningún objeto de dicha base de datos. Se pueden autorizar las operaciones administrativas especializadas, como por ejemplo el procesamiento, mediante roles independientes con menos permiso. Para obtener información detallada, vea Conceder permisos de procesamiento (Analysis Services).

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 secundario en una base de datos y seleccione 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.

Información general descendente de la autorización de Analysis Services

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

Paso 1: Administración de servidores

Como primer paso debe decidir quién dispondrá de derechos de administrador a nivel de servidor. Durante la instalación, el administrador local que instala SQL Server debe especificar una o varias cuentas de Windows como administrador de servidor de Analysis Services. Los administradores de servidor tienen todos los permisos posibles en un servidor, incluido el permiso para ver, modificar y eliminar cualquier objeto del servidor, así como ver los datos asociados. Finalizada la instalación, el administrador de servidor puede agregar o quitar cuentas para cambiar la pertenencia de este rol. Vea Conceder permisos de administrador de servidor (Analysis Services) para obtener información detallada acerca de este nivel de permiso.

Paso 2: Administración de bases de datos

Posteriormente, tras crear una solución tabular o multidimensional, se despliega en el servidor como base de datos. El administrador de servidor puede delegar las tareas de administración de base de datos definiendo un rol que tenga los permisos de Control total de la base de datos en cuestión. Los miembros de dicho rol pueden procesar o efectuar consultas de objetos de la base de datos, así como crear roles adicionales para acceder a los cubos, dimensiones y otros objetos que se encuentren en la base de datos. Para obtener más información, vea Conceder permisos de base de datos (Analysis Services).

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

De forma predeterminada, solo los administradores de servidor y de base de datos pueden acceder a los cubos o a los modelos tabulares. Para hacer que estas estructuras de datos estén disponibles para otras personas de su organización se necesitan asignaciones de roles adicionales que asignen cuentas de grupos y usuarios de Windows a los cubos o modelos, junto con los permisos que especifiquen los privilegios Read. Para obtener información detallada, vea Conceder permisos de modelo o de cubo (Analysis Services).

Las tareas de procesamiento se pueden aislar de otras funciones administrativas, permitiendo que los administradores de servidor y de base de datos puedan delegar dicha tarea a otras personas o configurar el procesamiento desatendido mediante la especificación de cuentas de servicio que ejecuten un software de programación. Para obtener información detallada, vea Conceder permisos de procesamiento (Analysis Services).

[!NOTA]

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

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

Analysis Services proporciona una configuración de seguridad para establecer los permisos de objetos individuales, incluidos los miembros de dimensión y las celdas de un modelo de datos. Para obtener información detallada, vea Conceder acceso personalizado a los datos de dimensiones (Analysis Services) y Conceder acceso personalizado a los datos de las celdas (Analysis Services).

También puede cambiar los permisos en función de la identidad de usuario. Normalmente se conoce como seguridad dinámica, y se implementa con la función UserName (MDX)

Prácticas recomendadas

Para gestionar mejor los permisos recomendamos un enfoque parecido al siguiente:

1. Cree roles por función (por ejemplo, dbadmin, cubedeveloper, processadmin...) para que la persona que actualice los roles pueda ver a simple vista qué permite cada rol. Tal y como se ha indicado en otro apartado, puede definir roles en la definición de modelos, conservando así dichos roles mediante posteriores implementaciones de soluciones.

2. Cree un grupo de seguridad de Windows en Active Directory y actualícelo para asegurarse de que contiene las cuentas individuales adecuadas. Esta acción hace que la responsabilidad de la pertenencia a grupos de seguridad recaiga en especialistas de seguridad que ya dominan las herramientas y los procesos usados para actualizar cuentas en su organización.

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

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

   Si incluye información de la cuenta le será más fácil realizar un seguimiento de las cuentas usadas en distintos roles. Dado que los roles son acumulativos, los roles combinados asociados a windowsgroup1 componen el conjunto de permisos efectivos de las personas que pertenecen a este grupo de seguridad.

5. Los desarrolladores de cubos necesitarán los permisos de Control total de los modelos y las bases de datos que se están desarrollando, pero solo necesitan los permisos de lectura cuando se distribuya una base de datos a un servidor de producción. No se olvide de desarrollar asignaciones y definiciones de roles para todos los escenarios, incluidos las implementaciones de desarrollo, de pruebas y de producción.

Si usa un enfoque como este se minimizarán los cambios en las definiciones de roles y la pertenencia a roles dentro del modelo, y se proporcionará visibilidad a las asignaciones de roles, facilitando la implementación y la actualización de los permisos de cubos.

Vea también

Tasks

Conceder permisos de administrador de servidor (Analysis Services)

Conceptos

Roles y permisos (Analysis Services)

Metodologías de autenticación admitidas por Analysis Services