Out of the box, the HANA database is not encrypted.
For those businesses that demand encryption, from within HANA Studio you can activate the encryption of the HANA data volumes.
The HANA documentation supplied with SPS7, suggests that the recommended approach is to encrypt the data volumes as part of the HANA installation process. This is due to the “Copy-on-write” method used to persist data on disk. An already used database may still have unencrypted data pages in it, even after encryption is enabled.
You should note that the words “data volumes” means the location of the database files for the indexserver and the statistics server, which is usually something like “/hana/data/<SID>/mnt0000<n>/hdb0000<n>/*.dat”.
Tip: You can check which values for “<n>” in the above, will be used, by checking the “Landscape Overview” tab and the “Volumes” tab within that.
Prerequisites:
– SAP recommend changing the SSFS encryption key after installation of the HANA system. This key is used to store the data volume encryption key and others.
– Disk space of the data volume areas (we discuss this below anyway).
– Take a cold backup of the HANA DB area and config files.
– Access to the HANA Studio (you can do this with SQL access and hdbsql, but I don’t show this).
Let’s begin:
From within HANA Studio, open the “Security” tab and navigate to the “Data Volume Encryption” tab.
You will notice that encryption is not already enabled.
Tick the “Activate encryption of data volumes” tick box, then click the “Execute” button:
The encryption process will start immediately (“Encryption Pending” then “Encryption Running”):
The status is updated when each server process finishes:
Once the encryption process is completed successfully, the tick box is enabled again for you to be able to de-encrypt the volumes should you wish to reverse the process:
My small (empty) HANA DB @ sps7, took approximately 10 minutes to encrypt.
The data volume sizes increased as part of the encryption process.
The indexserver data volume went from 324MB used to 341MB used:
Of more importance is the dramatic increase in the allocated (Total Size).
It’s gone from 513MB to 896MB! You will need to be aware of the disk space you may need before enabling encryption.
The statistics server is smaller and went from 80MB used to 101MB used:
Again, notice that we’ve got an increased allocation from 320MB to 400MB.
Validate the encryption status using an SQL console:
SELECT * FROM M_PERSISTENCE_ENCRYPTION_STATUS;
What are the implications for encryption?
Well, the data volumes have been encrypted, but we’ve not seen anything about encrypting the logs or the backups.
Also, to preserve the performance of the HANA system in memory, the data is decrypted when read from the disk into memory.
Is encrypting the HANA DB transaction logs feasible? Probably not. There are various whitepapers detailing the issues of encryption of data stored on SSDs. Since the majority of high performance appliance resellers use SSDs for the HANA DB transaction logs, the use of software layer encryption on SSDs is not worth the effort and would probably reduce the performance of the database. Instead, using the SSD hardware layer encryption may prove useable, but this is only worth while if you think that the SSD could be physically stolen. SSD hardware encryption doesn’t prevent an intruder at the O/S level from seeing the data.
Is encrypting the HANA DB backups (data and logs) feasible? Yes this is definitely something that should be employed. There are 3rd party backup tools that will take a copy of the HANA backup files, then encrypt and store elsewhere. But these tools may not support secure wipe, so the disk location of the backup files would potentially still contain the data. Using backup tools certified for SAP with the BackInt interface would be better, since the data doesn’t touch the disks, it’s piped straight to the backup device via the “network”.
There is possibly some slight performance impact from encrypting the data volumes. The data files are written to at least every 5 minutes. They are also read from during HANA start up. These I/O operations will be the same speed as they were before, except there will be some additional software routines involved to perform the encryption, which will use slightly more memory and mean a slight delay between the data being read/written to/from the disk.
Be aware of bugs in the backup/restore process.
I’ve seen mention of bugs in other software products where an encrypted backup is void due to a software bug. Ensure that you test your solution thoroughly.
SAP recommend that you change the Page Encryption Key (used to encrypt the data volumes) regularly as per your organisations standards. This may yet again increase the allocated size.
Summary:
– Data volume encryption is easy and fast in HANA. There’s not really any reason to not implement it. Beware of implementing in an already populated database and ensure you change the keys regularly.
– Backups and transaction log volumes are not encrypted and for the logs there’s a good reason why you may not want to.
– Performance in certain scenarios could be affected slightly.
– You should attempt to implement a supported Backint capable backup product with encryption, since the backups with this method don’t touch the unencrypted disks.
– Encryption can be performed and validated at the SQL command level.
– Be aware that data volume encryption in HANA will require more disk space to be allocated to the data volumes, increasing the footprint of the HANA database by as much as 50%.
