Hello and welcome to the SAP HANA Academy.
The topic of this video tutorial series is SAP HANA Service and in this video we will
take a look at Data Storage and Network Security for the Cloud Foundry environment.
This video has been recorded in January 2019.
For earlier or later releases, please check the playlist on the SAP HANA Academy.
Hi, I am Denys van Kempen.
We do not have direct access to the file system, to the operating system, when using the HANA
service, and unlike on-premise HANA, we find that data-at-rest encryption, so that’s
data volume encryption, redo log encryption, and backup encryption, they are all activated
by default.
There is no on/off button here, as would be the case with on-premise HANA.
Files are encrypted by the cloud provider.
What we can do is manage the root keys.
Always start with setting the root key backup password.
Make sure to read the small print.
No root key backup password might mean you will not be able to recover your database,
should this ever need to be done.
So make sure to store the password securely, maybe use a password manager.
Next, we can change the root keys.
You can make a selection.
Data volume encryption root key is required to encrypt and decrypt the actual database
data files.
This happens transparently when the data is loaded into memory.
HANA is an in-memory database, of course, most data will be in-memory, we only write
to the data volumes during checkpoints, from time to time, not very often.
So, this means there is no impact on performance.
Here we have Note 2159014 FAQ SAP Hana Security
This explains that for certain specific operations there could be some impact usually not higher
than a medium single-digit percentage.
Database snapshots is a such an example.
Regular database backups have their own encryption but a snapshot happens on the data volume
and, for this reason, is encrypted by the data volume key.
Important to know, when you include snapshots in your backup strategy.
You will need both root keys during the recovery.
Redo log encryption root key, a separate volume, and thus, with its own key.
The backup key, already mentioned it.
And the Application encryption service root key.
As I just said, data in memory is not encrypted, but if there are certain column values, which
need to be encrypted (credit cards, social security numbers, etc.), of course, this can
very well be taken care of at the application level and the app can then leverage this HANA
service.
No need to create your own.
Maybe as a reminder, here we have an illustration from the SAP HANA Security Guide for the SAP
HANA Service.
We have data and log backups, encrypted with a root key, we have disk and log volumes each
encrypted with a root key, and security-relevant application data, also protected by yet another
key.
That’s the keys we see here.
Preparing to change root keys.
You will get a warning.
Again, read the small print.
Download the keys or cancel, if you do not want to backup but back out.
Step 3.
Here we are prompted another time whether we have backed up the root keys.
Again, no keys, no recovery — you do not want to have to explain why, after two warnings,
you still did not properly secure your stuff — and then we can activate the new root
keys.
Here we can see the versions we have.
You can always backup the last root keys, the active version, another time, maybe to
store in another location, if need be.
So, we have four root keys, what about the master key?
There is one key which protects the encryption root keys, the ones we just changed.
It is stored in the instance secure store in the file system, the instance SSFS.
There is another which protects the X.509 certificate infrastructure used to secure
internal TLS-based communication.
Stored in the system PKI SSFS.
What does that mean?
PKI stands for public key infrastructure, here it is just a synonym for X.509 certificate
infrastructure.
Same thing.
Just regular public key / private key protection.
X.509 is the most common format to encode certificates and we store them in or on the
file system.
Here we have another illustration from the security guide for on-premise HANA, and here
we also see the two safes, each protected by a master key.
The instance SSFS stores the root keys.
The System PKI SSFS stores the keys used for internal communication.
Here we some examples, between tenants, between internal processes, between hosts in case
of a distributed system or systems in case of replication.
Most of this not really relevant for our HANA Service but, in case you wondered, what does
this all mean?
Now you know.
It is on the file system, managed by the cloud provider, not by us.
We have no access.
Just to let you know that all this communication is encrypted.
TLS-based.
Same as for HTTPS encryption, also TLS based.
TLS / SSL.
Same thing.
Back to our overview.
While we are at it, let’s also take a look at Network Security Information.
Here we can see the same information.
Internal communication: TLS/SSL secured by the System PKI, listening on global network.
We can also see that for client connections, TLS/SSL is enforced.
We have recorded a couple of videos about how you can configure your clients for ODBC,
or JDBC, Python, Ruby, Go, and so on.
Validate client certificates is not enabled by default.
You need to set this up, first.
Otherwise, nobody can connect.
And then under general settings, the cryptographic provider is listed: the SAP CommonCryptoLibrary.
This is just for your information, for the security audit.
To make any changes, you would need to modify system parameters.
Manage database backups we will cover in another video.
Until next time.
Thanks for watching.
You can find more video tutorials on our YouTube channel.
If you would like to be informed about new video tutorials, please subscribe to our channel.
You can connect with us on LinkedIn or follow us on Twitter, as well for updates, and if
you are watching this video on YouTube, do not hesitate to leave your comments to the
video page and, if you like, give us your vote on this video.
Thank you for watching the SAP HANA Academy