Analysis Services Security - SQL Server Analysis Services 2012 Cube Development - page 238

Chapter 7. Analysis Services Security
In this chapter, we will cover:
• Managing instance-level administrative security
• Managing database-level security
• Managing cube-level security
• Managing dimension hierarchy-level security
• Implementing dynamic security
• Implementing cell-level security
Introduction
This chapter teaches how to secure Analysis Services starting at the instance level
and working all the way down to the individual cube cells. Analysis Services admin-
istrators have unrestricted access to all items within the server—they can restart the
service, read and process data in every database, dimension, and cube, alter config-
uration settings, collect traces, and so on. This level of access is best reserved for
database administrators. SSAS developers need full access to the database they're
working with but not necessarily to the entire instance; each instance could host mul-
tiple databases constructed by multiple development teams. Individual users may
need access to all or some of the cube and dimension data depending on their job
requirements. In addition to explicitly defining the list of dimension members, you can
also dynamically configure the security if your cube is queried by many users, each
requiring access to a specific dataset.
Unlike the SQL Server relational engine, Analysis Services has no concept of its own
security logins; it completely relies on the security of the Windows operating system.
However, you can define very granular security settings for each Windows user or
group.
Analysis Services builds a bitmap of the dimension members or cells that are avail-
able for reading or writing whenever the user connects to the instance. So, defining
security adds some overhead to the application. Generally, if you don't have too many
roles (several hundred) or if you use effective MDX functions for implementing dy-
namic security, such overhead is negligible.