Hello and welcome to the SAP HANA Academy.
The topic of this video tutorial series is Getting Started with SAP HANA
on the Google Cloud Platform and in this video we will take a look at the secure configuration of
SAP HANA, express edition.
Hi, I am Denys van Kempen.
In the previous video, we created an SAP HANA, express edition VM using Cloud Launcher and
performed the first configuration steps, set the master password and attach a fixed IP to the VM.
I have the output of the - lets call it - the initialization script, here on the console.
Maybe as a reminder, if we go to the Compute Engine menu and select VM instances,
we have in the Connect column a link to open an SSH connection to our VM.
So, that’s what we are looking at here.
You can change the color and font size with the gear icon menu to the top right.
Let’s scroll up a bit.
Note that the SYSTEM password was changed for the SystemDB and for the HXE database.
A root key backup was set and then the instance SSFS and PKI SSFS master keys were changed.
Then, a root key backup specific to the systemdb database was set and a new root key was generated
for the data volume, redo log and internal application of the systemdb which,
after the backup of the root key, were all three activated.
Then, the same was done for the HXE tenant database.
To make sense of this, let’s take a look at an illustration from the SAP HANA security guide.
I wrote about this in the What’s New for SAP HANA 2.0 SPS 01 release,
native encryption of persistence.
Here you will find all the ins and outs on this topic.
I will keep it brief for now.
We have two secure stores, as they are called, SSFS, secure store on the file system.
Think of it as a safe.
Each safe has its own key.
It has not really all that much to do with HANA, to be frank, SAP started using this
for the application server, AS ABAP (Netweaver), a bit earlier, kernel 7.20 to be precise in 2011
and this is where this is coming from.
SAP Basis administrators probably will be familiar with it.
The System PKI store contains the root certificates for internal communication.
PKI, for those not familiar, refers to the public key infrastructure.
Nothing to do with HANA either.
Used everywhere to secure communication between computers.
HANA uses it, for example, for the communication between the different processes.
We will take a look at what processes there are in another video but for now,
let’s say, there is a built-in web server, like Apache, there is a database server, of course
- HANA is foremost an in-memory database -
there is also a built-in application server, a bit like Tomcat or IBM WebSphere for Java, .NET
called HANA XS, extended services,
and so we have all these processes and they all communicate securely, encrypted,
using the certificates stored in this PKI SSFS.
If HANA is running as a distributed system (a cluster of computers),
same thing: secure communication using the PKI SSFS.
If HANA connects to external systems, smart data access, dynamic tiering, any of the enterprise options,
same thing: secure communication using the PKI SSFS.
So, that's the System PKI with its master key.
Then, we also have the instance SSFS, again, with a master key but this time
it stores root encryption keys, and these keys are only used by the HANA instance.
They are color coded here, we have a key in hot pink for our backups,
a key in blue for redo log encryption,
a key in green for data volume encryption
and a key in orange for secure application data.
Say, you want your app to encrypt credit cards data in the database.
So, this is all data-at-rest.
Basically, you can say we have an SSFS for data-in-flight (PKI communication) and one
for data-at-rest, the instance SSFS.
If we return to the console output of our script, we can see that the instance SSFS
master key is changed and then the system PKI one.
Subsequently, the root keys for the different data-at-rest encryption services are generated
and this needs to be done for each database.
SAP HANA 2.0 is a multitenant database container system (MDC) which means that we always have
a systemdb database and a number of tenant databases.
For SAP HANA, express edition, we have systemdb and a tenant database named HXE.
This is the default setup.
HXE will also be the system identifier, the SID.
We can see that here on the prompt.
We are connected as hxeadm, that is the software owner of any HANA system
- express, platform, or enterprise edition, it does not matter -
it is always SID+adm
and then we are in the path, /usr/sap/SID (here HXE) /HDB+instance number.
So, we also have an instance number, here 90, 9-0.
If you remember, we already discussed this when we looked at the firewall rules.
Ports were opened for 8090 and 4390 for HTTP and HTTPS traffic.
Ports were opened for 5 90 13 and 14 for the host agent and for 3 90 13 and 15, for the database.
So, that’s always important to know, the system identifier and the instance number.
For HANA express, this is HXE and 90, 9-0.
As mentioned, our first tenant database is named HXE,
We can add other tenant databases later on - in fact, this is very easy - and we can
also remove, delete, tenant databases.
We could even remove the HXE tenant database This is no problem.
And then, do we need to do all this key stuff again?
No.
When you create a new tenant database, all the root keys are generated, so they are guaranteed to be unique
and when you perform your own installation of SAP HANA, the master keys are also generated.
But here we did not install HANA, we used Cloud Launcher to clone a canned image of
the HANA express edition VM.
The good thing is: it is very fast and very easy.
But not so good: it is a clone, they are all the same; a hackers paradise.
So, before we could allow you to get started, the HANA system has be secured and
that’s what we just have done.
Congratulations, SAP HANA, express edition 2.0 is configured.
Now, we do actually have a video of how you can do this yourself, so without the script.
Here on the SAP HANA express playlist.
So, if you are interested to go a bit more low-level and sharpen your HANA administration
skills, you might want to take a look at that video.
And if you are really curious and already, maybe, a bit of a Linux pro, the actual script
executed to change the keys is located in the bin directory of the home of the HANA
express admin user - here we have it: change_key.sh - and if the page forward a bit, you can see
that - here is the beef - changeSSFSKeys - we set two variables for the path to the key
and the store which happen to be the same for instance SSFS but are different PKI SSFS
and then with the command rsecssfx changekey, the master keys are changed.
SSFS, secure store on the file system - so, this is command line stuff - and if we continue,
for the root keys, then we can see that this is actually done with an SQL command:
ALTER SYSTEM … ENCRYPTION CREATE NEW ROOT KEY WITHOUT ACTIVATE
and this time we use the hdbsql command line tool.
That’s the implementation.
You don’t have to worry about it.
The main point is that our system is now safe, so we can proceed.
In the next video, we will take a look at some of the command line basics for SAP HANA.
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 we also have a page on Facebook and Google+.
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 his video.
Thank you for watching.