Database Reference
In-Depth Information
Securing the Cube
Security, for an Analysis Services cube is a very important issue and one that needs
to be properly understood and implemented. It's almost always the case that some
form of security needs to be in place: the data in the cube may be extremely sensitive.
For example, if a cube contains sales data for a whole company, we may need to
make sure that each sales person can only look at his or her own sales and no one
else's; equally, if a cube contains data regarding the profitability of a company, it's
likely we'll need to ensure that only the finance department and the board have
access to it.
Ignoring security during the initial analysis phase will inevitably lead to problems
during the deployment of the solution. We can't stress this enough: security must be
planned for in advance; it is such a complex issue that it cannot simply be left until
the cube is in production.
In this chapter, we will discuss the Analysis Services security model, exploring the
different ways to use it and highlighting best practices. As with the rest of the topic,
this chapter is not about where to click to add a role to a cube. Instead, we'll focus on
how to solve the most common security problems, and how we can make the best
use of the different security features of Analysis Services.
Sample security requirements
Before diving into technical details, let's outline the sample set of security requirements
that we will use in this chapter to illustrate how security can be implemented.
Imagine we are building a BI solution for a multinational company, and we want to
give employees and partner companies all over the world access to our cube. Here's
what we will need to do:
•
We need to restrict access by Country: Canadian users will be able to see only
Canadian data, French users will only be able to data for France, and so on.
Search WWH ::
Custom Search