I often get questions from both potential & existing customers about how content in the BI system is protected. This in itself is a pretty big topic, but we'll break it down into the major aspects of data storage and data transport, and what SAP Business Intelligence 4.0 offers in this respect.
Data storage in BI.
There are 2 main places where data of interest is stored in BI:
1) The metadata in the repository which represents the functionality of the BI system. This includes information about data sources, report layout, users accounts, scheduling - everything that makes the BI system what it is. This is all stored in the database that the Central Management Server connects to.
2) The actual report content. Data that you pull from external data sources and store in reports is never stored in the BI repository. It is stored on the file system by the "File Repository Service" (FRS).
Let's look at the metadata first. You could always encrypt an entire database using the database vendors native encryption functionality, however this is probably overkill. Is something like a report title or a report layout sensitive data? In BI 4, we automatically encrypt any passwords to external systems such as universe connection credentials to a database you report off, or credentials to external identity providers. These items are encrypted using FIPS 140-2 certified libraries. For those that are really curious about the actual algorithms in play AES-128 is used to encrypt any sensitive data that is used during the operation of the BI system. SHA-256 one way hash is used to protect BI logon passwords for the native "Enterprise" users.
However entrance to your house is only as safe as is access to the keys to open the lock. So how are the cryptographic keys protected? In the Central Management Console (CMC) you will see a new entry for "Cryptographic Keys". Here you can manage these keys, including creating new keys, deleting old keys.
There is always going to be one and only one Active key. With the active key, any new content that needs to be encrypted, will be encrypted with that key. When you create a new key, you will see the previous key with a status of 'Deactivated', and your new key being 'Active'. Here, the previous key is only being used for decryption of objects which were encrypted with this key (you can see the object count in the 'Objects' column). All new content will now be encrypted with the new Active key.
You can revoke a 'Deactivated' key. When you do so, all objects which were encrypted with the Deactiveated key will be re-encrypted with the new Active key.
By default, only the Cryptographic Officers user group can perform these rekeying actions.
Where are these above mentioned keys stored? They are stored in the repository database encrypted by yet another key! What this means is that if your entire database was compromised by say a rouge DB administrator, they would be unable to get any meaningful use from it. The 'master' key is stored with the Central Management Server (CMS) and is used by the CMS in order to decrypt the keys in the repository which in turn are used to decrypt your BI connection objects, user data etc. Make sure you protect access to your master key by securing the BI install directory! You can change this master key at any time. To do so, on windows:
1. Start the Central Configuration Manager,
2. Stop the Server Intelligence Agent (SIA)
3. Right click on the Server Intelligence Agent and select properties
4. Go to the Configuration tab
5. See the "CMS Cluster Key Configuration" and click on "Change..."
6. You can create a new cluster key or generate a new random one (most secure)
7. If you have multiple CMS clustered, you will need to enter the same cluster key on all systems.
8. The first system you perform this action on will automatically re-encrypt the keys in the repository with this new key.
Now let's look at the second part, file repository server. Instances of reports that are generated are stored on the FRS. You can think of it almost like an FTP server. At this time, this content is not universally strongly encrypted. There are two steps you can take to secure this further.
1) Secure & restrict access to the folder where you FRS content is stored. By default this is a subdirectory of where you installed your BI deployment to.
2) You can use OS level encryption to further encrypt this content.
Data in Transit
In your most basic workflow, a user will logon to the BI portal, access a report, and fetch some data from an external database. Another common workflow will be a user logging on with a client like Crystal Reports Designer, or Information Designer tool, and similarly access some data. The vector of attack we are concerned about here is the man-in-the-middle. Here again there is functionality you can make use of to further protect your system. Not of course that there is a performance penalty when the system has to do complex cryptographic calculations & key exchanges.
Let's walk through our use cases.
Logon
The logon operation will be your user's browser to the web application server. Any data sent here could be subject to a man in the middle attack. This connection can be secured in your web application server with TLS/SSL. For the default Tomcat that ships with BI, you can refer to the Tomcat documents here for a how-to: http://tomcat.apache.org/tomcat-6.0-doc/ssl-howto.html
Server to Server Communication
The BI Servers communicate over the CORBA protocol. You can enable CORBA SSL (it's actually using TLS 1.0) to encrypt communication between servers and clients. Note that when you configure CORBA TLS, all servers and clients must be configured for CORBA TLS. That that are not will be unable to connect. For detailed how-to, refer to the Administrator's guide in the "Configuring servers for SSL" section.
Note that in BI 4.0, anytime a client connects directly to the server, the logon action is always done over a secure channel so credentials are never sent over the network in clear text. However further communication will not be encrypted unless TLS encryption is enabled.
Accessing Data
The Business Intelligence Suite offers a number of reporting clients and data access methods. Your communication channel encryption options here will vary depending on the database vendor. Here again for maximum security you can enable secure communication between the data access driver and the database.
- SAP Managed Tags:
20 Comments
