Data Encryption Comparison between HANA 1.0 and HANA 2.0

[Private_Member_67472]

Recently, I was dealing with the challenge whether I should implement server-side data encryption (with focus on data and logs) on our SAP HANA 1.0 SPS 12 system or I should wait with the implementation until the upgrade to latest release of SAP HANA, which is currently HANA 2.0 SPS 00.

For this purpose, I was analyzing the question what is possible to implement in SAP HANA 1.0 and HANA 2.0, regarded from a data and log encryption perspective. As many others might be exploring this, I wanted to share my findings with you.

In general, SAP HANA copies data from memory to disk at regular savepoints and additionally captures all data changes in redo log entries. This ensures that the database can be restored to its most recent committed state after failure. However, this data remains unencrypted on disk of the HANA server and should be saved from unauthorized access at OS level from a security perspective. This is when encryption comes into play.

The following table gives an overview of a direct comparison between SAP HANA 1.0 and SAP HANA 2.0 SPS 00 and will be used as reference in the following:

	HANA 1.0 SPS12	HANA 2.0
Cryptographic Service Provider required	Yes	Yes
Data Volume Encryption	Yes	Yes
Encryption Keys stored in SSFS	Yes	Yes
Renewal of (Page) Encryption Keys recommended	Yes	Yes
Redo Log Encryption	No	Yes (since SPS 00)
Memory Encryption	No	No
Backup Encryption	No	Yes (since SPS 01)
Database Trace Encryption	No	No
Root Key Backup possible/required	No	Yes
Password for Root Key Backup possible	No	Yes
Import of root key e.g. after disaster recovery	No	Yes

 

Similarities between SAP HANA 1.0 and SAP HANA 2.0:

As a prerequisite for encrypting the data volume SAP HANA requires the availability of a cryptographic service provider. This is by default and recommended the CommonCryptoLib. The encryption of the data volume is possible for both. In this case, a persistence root encryption key must be created. This key is used to encrypt the page encryption key and is stored in SSFS and automatically retrieved from there. For instance, this ensures that no administrator action is needed for startup.

Once changes to data are moved from memory to disk, the relevant pages are automatically encrypted during the write operation. These pages are encrypted by using a 256-bit “page encryption key”. From a security point of view this page encryption key (and encryption keys in general) should be renewed periodically.

Both SAP HANA 1.0 and SAP HANA 2.0 do not support the encryption of database traces. In addition, SAP HANA 1.0 and SAP HANA 2.0 SPS 00 do not support the encryption of data backups (supported with SAP HANA 2.0 SPS 01😞 For encrypting data backups a suitable third-party tool must be used with the backint interface. Same applies to the database trace, which are not encrypted either. A general recommendation is to avoid large tracing files on OS level.

 

Differences between SAP HANA 1.0 and SAP HANA 2.0:

Finally, Since SAP HANA 2.0 SPS 00 redo log encryption is possible. Once it is activated log entries are encrypted using an 256-bit long root key. Consider that this encryption key is another key than for data volume encryption and must be maintained separately.

Since SAP HANA 2.0 SPS 01 backup encryption is supported natively and can be enabled for all kinds of backup types. Same applies to the key as mentioned above, it is an additional one and must be maintained separately.

There is the possibility/need to backup the encryption root keys with HANA 2.0 e.g. for redo log encryption (since SPS 00), backup encryption (since SPS 01). In a disaster scenario, it may be necessary to provide these encryption root key backups for recovery. Having lost the encryption root key backups may lead to an unrecoverable situation. Therefore, performing an encryption root key backup is highly recommended. As a consequence, each time changing an encryption root key requires a new root key backup. In addition, the root key backup is secured by a password. This password must be set before the actual root key backup is performed.