Hana Database Encryption

[Former Member]

We are in the process of implementing Hana DB in our environment. We are taking 15TB Oracle non-encrypted database to a Hana 6TB Database on Linux. I understand the concept behind encryption and the advantages and disadvantages of implementing it in the Oracle world.

My question is around the Migration and when to implement the Encryption. Per SAP, one should enable the encryption right after the Software installation and I think that it will slow down the Migration speed significantly. We have tables with Billions of rows and each data point now has to go thru the encryption Logic. We were wondering if it makes sense to implement the Encryption after the migration. That way we take out one big factor.

We are also not sold to the idea of Encryption. Do you guys have any suggestion/Recommendation?

Thanks in Advance!!!

[lbreddemann · Accepted solution]

SAP HANA encrypts data on the persistence level - not row-wise and not while the data in in memory.

The encryption is part of the so called savepoint process, which runs, for the majority of it, asynchronously.

The estimated overall performance impact of activating encryption is considered to be below 5% if I'm not mistaken.

Based on that I don't expect a high impact on the overall migration runtime.

[Former Member · Accepted solution]

Hi Lars, Thanks for replying back. Per SAP note the recommended overhead is 5% which is fine for a day in life kind of ETL situation. I am more worried about choking the Pipe when we try to migrate 15TB of data. That case each row will now be intercepted and go thru an additional logic of Encryption. Per Oracle on their White Paper, Oracles Encryption adds 5 to 35% of overhead.
Also the data in the backup, RedoLog and over the Network is not encrypted so I am also thinking that do we even need to Encrypt anything?

How does this impact the System Refreshes and Disaster Recovery?

[lbreddemann · Accepted solution]

None of your in-flight data will be encrypted.

And again, the migrated rows won't be encrypted. Instead, pages that are written out during a savepoint get encrypted. This process is completely de-coupled from your data loading transactions.

If you do want to end up with an encrypted data area, then it's important to activate it before any data is loaded. The encryption will only affect the pages that currently belong to the database - those pages that had been part of former versions of the database can and likely be still in the data volume files and remain not encrypted.

As for the 'pipe choking': even with SAP HANA's in-memory technology, IO and network contention still are bottleneck for mass data loading activities. The encryption really would only add to the total runtime, when the system is already running at around 96% total CPU usage during a savepoint.

Whether or not you decide to implement data volume encryption is up to you. Considering that in most SAP HANA setups the data volumes reside on NFS shares that are accessible by admins and that can be copied, while the system is using them, I'd say it's at least some degree of protection.

Not sure what your last question is about, but the documentation covers backup&recovery...

[Former Member · Accepted solution]

So the encryption happens at the page level and not every block of the data during the encryption, that's good. Do you know, without the encryption, can anyone read the data in the data file of the HANA database? For any other database excepting BWA, the data is in some form of Binary and no one else can read it. If the HANA DB file is in non-Binary plain English format then it makes sense to worry about the Encryption else it will complicate things. The maintenance of root key or someone messing up the root key by mistake is a good reason to worry about.

[lbreddemann · Accepted solution]

Just because it's binary doesn't mean nobody can read it.

If you're skilled in analysing data structures on the level of e.g. database data files, then you can read practically any unencrypted database.

That's why there is encryption in the first place.

And no, 'plain English' is not what SAP HANA uses to store it's data. It is indeed a binary format.

[Former Member · Accepted solution]

Agreed, so the sole purpose of Encryption is to prevent the OS users be it system admins or un-authorized users from reading the data file by either copying it to a new location or by using some vi tool at the OS level? Can the DBA/Admins still use Hana Studio or the HDBSQL to read the data from the database even after the encryption? I think the data is not encrypted at the Block level, like value "TESTING" will not be stored as "&*&yhsgasyu1". So after encryption do the DBAs need to do anything special to access the data using Hana Studio or HDBSQL?

Thank You so much for your answers. I am trying to understand the unknowns that might hurt us back once we implement it.

[lbreddemann · Accepted solution]

Correct, the encryption ensures that without the right secure key, the data volumes cannot be read.

This does not change anything for users that connect to the database process. Just as with about any other DBMS out there, users and admins don't get to see what's in data files but what the database process makes out of it. For SAP HANA that's no different.

[Former Member · Accepted solution]

Sorry it was not clear, can DBA/BASIS use Hana Studio or HBDSQL to access the data in an Un-encrypted format like any end user would see from the SAP Front End application?

Its like me using sqlplus > select * from dual

[lbreddemann · Accepted solution]

Yep, same thing.

[Former Member · Accepted solution]

Hi Lars, Thanks for answering. I have another SAP HANA expert telling me that once Encrypted, the HANA Studio and HDBSQL will work like before and you can still query the data in the DSO and you will see the same data in the un-encrypted format. I doubt that its a true statement, if so then whats the point of encrypting then?

Also in few cases SAP itself comes back to us(in the case of Oracle) and asks us to run few Update/Insert/Delete statement to set/unset a flag. If I cant see the data using hdbsql or HANAStudio after Encryption then how do I perform these tasks?

Message was edited by: A KS

[lbreddemann · Accepted solution]

The point of the encryption is to make it a lot harder to make sense of what's inside the data volumes when you don't have the decryption key.

It's not about "user-land' encryption, table access permissions, encrypting columns or anything like that.

Think of it as a big padlock on the box called 'your database'. To open the box, aka to start the database, you need the key. You need this key only at this point in time - simply to 'open the box'.

But once the box is opened (that is your SAP HANA instance is running) then you can use it as you always used it. No difference there.

That is BTW the same way, encryption works for Oracle databases. Once the database is up and running, the users can access the data and don't need to think about the whole decrypting process.

[Former Member · Accepted solution]

Glad that I came across an expert like you!!!!

To summarize:

1. Create a Encryption Key at the OS level

2. Encrypt the database, better to do it before the data Migration, right after the Installation

3. Make sure that the Encryption key is secured, no one messes with it

4. In order to change the Key shutdown the database and change the key

This does not prevent any user(be it inside SAP Application or Hana database) from running any Native SQL or Hana Studio.

In order to start the DB, make sure that the key is there. Same is true for the Shutdown.

[lbreddemann · Accepted solution]

For the details of how to handle the keys, please have a thorough read through the administration guide.