In this new blog series, I will outline some of the best practices of securing your BI platform.
We will take the approach of outlining what assets we need to protect, and based on a threat model analysis, outline the steps you can and should take to secure all aspects of the BI deployment.
Are you absolutely secure?
If you answered yes, you either blew up and burned down your entire IT infrastructure, or you are fooling yourself. Security is all about risk management. Let us therefore do a flyover around some of the ways to lock things down and manage our risk.
In Part 1, we will look at securing the Identity Provider communication, and review how the data is stored.
The main external identity providers are outlined above. From a security standpoint, we are concerned about both the data moving across the network, as well as data about users stored in the CMS repository.
When using the BI Active Directory connector, the calls between the CMS and active directory are actually encrypted natively by the Microsoft infrastructure. The good thing about this is that is you do not need to take any additional steps to protect the network communication for this purpose.
To access the Active Directory, query for and map users, the BI system requires AD credentials.
The rights required on the local computer where the SIA is running are as follows:
-Act as Part of the Operating System
-Logon As a Service.
–Read/Write to HKEY_LOCAL_MACHINE\SOFTWARE\SAP BusinessObjects\Suite XI 4.0
-Read/Write to Install directory (specifically Write access to the Log Locations).
The important part here is the account should NOT be an Administrator on the local machine.
Unlike Active Directory, the logon via LDAP to the underlying identity provider will be sent in clear text over the wire unless you configure SSL.
You can do this while going through the wizard or directly in your LDAP authentication screen after.
At minimum, you should be using Server Authentication. This will allow you to ensure that BI only connects to a trusted LDAP source, and will not send the LDAP credentials to an untrusted source, and of course encrypt the actual traffic, as it should be.
Again, the details you store here are stored encrypted in the CMS repository, and the deep details are here:Encryption & Data Security in BI 4.0
Your SAP authentication also requires an extra step to be encrypted. This is done by in the SNC configuration. Notice you can set different levels on encryption here, and this applies to not only the queries sent from the CMS to the SAP system for user authentication, but also for data access as you build out your reports.
But WAIT you say, I’m using OLAP and UNX and I use STS (the security token service). Isn’t SNC for the legacy xir3 content like UNV?
SNC is ALSO a security layer. The SNC settings for encryption will be used for the STS communication when setting up your SSO to BW. The summary here is that you should be configuring SNC always, at least for the Authentication level of quality of protection, and avoid sending around credentials unencrypted.
You will notice that BI4.1 now ships with a default SNC library to help with the configuration and potentially save you the extra step of downloading the libraries by using the “Use Default” setting for SNC library settings.
In the next part of the security blog series, I will look at protecting the web tier. Secure Your BI Platform Part 2 – Web Tier