Hello, hello! How are you, friends? How is it going? Welcome everyone back to a new episode of #BestInMicro! Today we’re going to get into a topic that really makes MicroStrategy stand out from the rest of the tools. Today we will talk about security layers in MicroStrategy.
As we already know, unlike other visualization tools, MicroStrategy has a much more complex architecture. To begin with, the great advantage it has over the rest of the tools is its semantic layer, which gives us a range of facilities in terms of security, since it allows us to manage a highly complex structure and to manage in great detail the accesses to the information we have.
As always, we start from the beginning…
There is a well-known saying that goes “information is power”. And this is precisely why it is so important to know, understand and control who is looking at what data. When. How it processes them. As a company, it is important to understand that data should be accessed only by those who have the access to do so.
Today we will review the 6 layers of security that MicroStrategy has. They are :
Let’s not forget that all these security layers can be assigned at both user and user group levels, and maximum restriction is always a priority. For example, if a user belongs to a group that gives access to a report, and also belongs to another group that has blocked access, the user will not be able to access the report.
This is the first safety barrier, logically. When we want to connect to MicroStrategy, the first thing we are asked for is a username and password to connect. Basic, right? This is common to virtually all tools. What I am interested in emphasizing here is that these credentials may be defined in different origins. That is, we have MicroStrategy’s generic authentication, which stores (in encrypted form, of course) the credentials in its Metadata. But there are also other types of authentication, where the credentials are validated against the database, against an LDAP server, a Kerberos or other external servers, with Windows credentials, etc…
As we all know, to connect from MicroStrategy to a database we use a database instance, which tells us:
The connection mapping gives us the possibility to configure the DSN and credentials that are used when connecting to the database, depending on the user or group that wants to make the query.
This not only allows us to manage access and permissions from the database, but also allows us to connect to different databases in the same project for the same objects. For example, if we have a report that shows sales at country level, and each country has its own database, we can use the “Europe” group to connect to the European database, while the “US” group will connect to the US database.
Well, there is not much to comment on this type of security. The famous ACL that exists in any directory, where you specify which permissions (read, execute or write, among others) you have over an object, besides being able to define the permissions over its children (in case of being a folder, logically).
Remember that whenever you want to do an audit I explained in the Metadata Queries article a query to make an extraction of all the objects with their ACLs.
Security filters is one of the great differentials that MicroStrategy has. Basically, it is to assign a filter to any query made by a user or a group.
For example, let’s imagine that a user runs a simple report, and the query generated in the report is select Month_id, Sum (Revenue).
If this user is affected by a security filter, the filter corresponding to the security filter in question will be added when generating the query. For example, if you have a security Filter where the Country is ‘US’, the query that will be executed against the warehouse will be
select Month_id, Sum (Revenue) where country = ‘US‘ and logically, the user will not be able to remove this filter.
This is, roughly speaking, the functionality of a Security Filter: filtering query-level data by user or group. We can see all the security filters that exist in a project in the “Project objects” folder:
Beyond what I have explained here, there are many points to be found on this subject. For example, it can also be assigned at the hierarchy level, and there are considerations when working with cubes or Freeform SQL queries… I’ll make a more exclusive note about security filters in the future!
Just as in ACLs we refer to the access that a user has to a certain object, here we define what a user can do. Privilege is a list of actions that a user (or group of users) can perform in the tool. This ranges from running a report, creating an object, or even using a tool in the suite.
Depending on the user’s purpose, i.e., the tasks or capabilities to be performed with the tool, a set of privileges will be assigned to the user so that he/she can perform these tasks. The privileges that a user has will be directly linked to the license he/she consumes, so we must be very careful when assigning them, since they may end up having an impact on the final cost (and let’s remember that licenses are not what we commonly call free).
You can consult what types of privileges exist in this MicroStrategy note where it explains the privileges that correspond to each license.
Security roles are a set of privileges that are “packaged” or grouped and facilitate management at the project level.
If we look at the security role editor, you will see that it is practically the same as the privilege assignment editor:
Basically, it asks for a name for the role and to select what privileges those to whom the role is assigned will have. By default, several security roles are predefined in MicroStrategy. You can find all the security roles in the administration menu, and there, if you edit them, you will be able to see which privileges each one contains.
We say that the security roles are at the project level because, precisely, when configuring the access that a person or group has to a project, we define it either one by one (as we saw in the previous point, although it is not recommended) or by assigning the role that he/she will have in each project. For example, in the following image, the user will have access to the Enterprise manager project with Power-user privileges. If you look below, you will see that some privileges such as “user view filter editor” and “Alias objects” are also assigned by hand. Depending on the color, you will see where you get each permit from.
I really believe that MicroStrategy is one of the most cutting-edge tools in terms of security. Once I have encountered a situation where I needed to mask a certain part of an attribute string (yes, it was really a very particular case) but even that ended up being solved with a few lines of code in the SDK, so even having challenges beyond the mentioned layers I have found solutions to security issues. I have yet to do some research to see if there are any highlights for this article in terms of how MicroStrategy’s cloud platform works, but I think that, for a general analysis of security issues, the goal is accomplished!
So that’s it for this week, as always, I invite you to ask and comment on any questions, and we’ll meet again in the next article!
* Tu información será utilizada exclusivamente para contactarte en relación al Business Data Master. No hacemos spam ni compartimos datos con terceros.
