So, you’ve just migrated to your new SAP HANA environment. You spent many hours architecting the proper solution, migrating, configuring, and testing. The business is starting to see the benefits of running on SAP HANA, and you are feeling good about wrapping up a successful project.
Have you considered the critical points in securing your system?
Your SAP system is the lifeblood of your organization, and thus the data it uses needs to be secure and properly locked down. The single act of limiting external access to the environment does not guarantee a lack of intrusion. News of recent data breaches prove how adept hackers are at obtaining access to a network in a multitude of fashions. Once inside, a hacker will start chipping away at access into your system. One of the first access points to be tested will be the communication entry points from other systems connected to your environment, such as sibling servers within the environment, or even the external (cold) storage of your SAP HANA environment.
How do you ensure your SAP HANA system is secured from any internal threats?
When installing your SAP HANA environment, a dedicated Public Key Infrastructure (PKI) will be created. Managed by a trusted certificate authority unique to your instance, each host and database will have a public and private key pair along with a public key certificate for mutual authentication.
Ok…so what does all that really mean?
Your SAP HANA environment is likely comprised of multiple servers. Each of these servers holds a “communication certificate” to its sibling servers and vice versa. These communication certificates are created and managed by a trusted certificate authority (CA) that is unique to your environment, and they will only be applicable to your systems. Your environment will not accept false certificates created by a different CA, reducing the chance of any forged certificates being used to access the system.
These certificates are held in the file system in Personal Security Environments (PSEs). The root PSE is held in a separate Secure Store File System (SSFS), tightly stored away for additional security. Should the database detect that the SSFS content and key information is not consistent, it will issue an alert, and encrypted SAP HANA data may become inaccessible until SAP Support can be contacted.
The good news is that the majority of the above were automatically done behind the scenes during your installation. Where you come into play is in verifying that each communication channel has Transport Layer Security (TLS) and Secure Sockets Layer (SSL) switched on. We could go on for hours about TLS and SSL, but basically it’s a way to authenticate servers and clients using encrypted messaging. Your job is merely to verify that the implementation team has this turned on for each communication channel.
What about that external (cold) data that is stored off on disk (that everyone forgets about)?
We all know operating systems can be vulnerable to the snooping eye. Well, the folks at SAP have thought of that as well. This data is being held on what is known as the “persistence layer.” This is merely technical terminology for the data storage at rest in data structures. Data at rest encryption, otherwise referred to as data volume encryption, is supported by SAP HANA. This additional layer of security on the operating system is yet a further method of securing all data within the SAP HANA environment.
This all may sound a bit overwhelming. After a successful SAP HANA migration, this is probably the last thing you want to consider. It is like locking your car doors at the grocery store. Chances are nobody will be looking to break in. However, in that one off chance there is, do not leave the doors wide open and the engine on. Speak to your implementation team and verify that these couple crucial steps were not overlooked. It is vital to the security of your system.
To find out more about SAP HANA migration projects or properly securing your SAP HANA environment, please visit us at symmetrycorp.com.