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.
Active Directory
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 data at rest, meaning the data that is stored in the CMS database is going to be strongly encrypted. Refer to my articles on data security in BI4 for more information on the specifics: Encryption & Data Security in BI 4.0
The important consideration here then is, how much access the AD account (v8\bossosvcacct) above has in active directory. You should always consider security in depth. What IF somehow the account is compromised. How much damage could it do in your enterprise?
This account only needs to list your Active Directory contents. This is controlled with the "List Contents" right. While the best practices for locking down Active Directory are a little beyond the scope, you can for example reduce the account's ability to query for additional user properties like email address. Some examples contained in this external blog on hiding AD objects.
The account that the SIA runs under should also run with minimum privileges. Suppose the process gets exploited somehow or the credentials fall into the wrong hands. You most certainly don't want the account to have the capability to create a user or grant permissions.
In many cases, users will use the same account for querying active directory as they do for running the SIA.
When creating the account in AD, while more tricky to sometimes setup , constrained delegation can allow you to limit the services for which a resulting kerberos ticket is used for. While this is not supported for the OLAP on MSAAS when working with SSO to database, it should work for all other use cases and is a way to restrict the usage.
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.
LDAP
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
SAP
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
- SAP Managed Tags:
