The process of securing Microsoft SQL Server Analysis Services occurs at multiple levels. You must secure each instance of Analysis Services and its data sources to make sure that only authorized users have read or read/write permissions to selected dimensions, mining models, and data sources. You must also secure underlying data sources to prevent unauthorized users from maliciously compromising sensitive business information. The process of securing an instance of Analysis Services is described in the following topics.
See the following resources to learn about the basic security architecture of an instance of Analysis Services, including how Analysis Services uses Microsoft Windows Authentication to authenticate user access.
Configuring the Logon Account for Analysis Services
You must select an appropriate logon account for Analysis Services and specify the permissions for this account. You must make sure that the Analysis Services logon account has only those permissions that are necessary to perform necessary tasks, including appropriate permissions to the underlying data sources.
For data mining, you need a different set of permissions to build and process models than you need to view or query the models. Making predictions against a model is a kind of query and does not require administrative permissions.
Securing an Analysis Services Instance
Next you must secure the Analysis Services computer, the Windows operating system on the Analysis Services computer, Analysis Services itself, and the data sources that Analysis Services uses.
Configuring Access to Analysis Services
When you set up and define authorized users for an instance of Analysis Services, you need to determine which users should also have permission to administer specific database objects, which users can view the definition of objects or browse the models, and which users are able to access data sources directly.
Special Considerations for Data Mining
To enable an analyst or developer to create and test data mining models, you must give that analyst or developer administrative permissions on the database where the mining models are stored. As a consequence, the data mining analyst or developer can potentially create or delete other objects that are not related to data mining, including data mining objects that were created and are being used by other analysts or developers, or OLAP objects that are not included in the data mining solution.
Accordingly, when you create a solution for data mining, you must balance the needs of the analyst or developer to develop, test and tune models, against the needs of other users, and take measures to protect existing database objects. One possible approach is to create a separate database dedicated to data mining, or to create separate databases for each analyst.
Although the creation of models requires the highest level of permissions, you can control the user's access to data mining models for other operations, such as processing, browsing, or querying, by using role-based security. When you create a role, you set permissions that are specific to data mining objects. Any user who is a member of a role automatically has all permissions associated with that role.
Additionally, data mining models often reference data sources that contain sensitive information. If the mining structure and mining model has been configured to allow users to drill through from the model to the data in the structure, you must take precautions to mask sensitive information, or to limit the users who have access to the underlying data.
If you use Integration Services packages to clean data, to update mining models, or to make predictions, you must ensure that the Integration Services service has the appropriate permissions on the database where the model is stored, and appropriate permissions on the source data.