In our previous article we’ve already covered how SAP ABAP Security Storage works. Today’s post is dedicated to SAP HANA Security Storage.
SAP HANA is a recent key product of SAP. It is a software solution based on the in-memory technology, that reduces the time of the data processing significantly.
This product has obviously caused an excitement among large enterprises interested in processing their data in real time. We do not doubt that SAP HANA is capable of processing big data. However, the security of critical data companies stored in SAP HANA deserves attention.
The HANA platform is shipped with equipment (hardware platform with pre-installed SAP HANA software) provided by such vendors as HP, IBM, Del, Hitachi, Fujitsu, and Cisco. HANA is also available as a cloud solution (called HANA One) from several cloud service providers like Amazon and Microsoft Azure.
So, what encrypted data are stored in SAP HANA, where are they stored and, above all, how secure are they?
Let’s look at SSFS_ < SID>.DAT file, where < SID> is an identifier of SAP HANA.
This file can contain the following information:
- User data (login, encrypted pass),
- Encrypted Root key,
- Encrypted other keys.
As you can see, there are user passwords. It’s what an attacker is searching for!
3DES is used as an encryption algorithm. And it’s the key that have some issues. By default, SAP HANA uses the same key for encryption as ABAP Security Storage, and, as a result, the key is the same for all SAP HANA systems.
With access to the encrypted storage (file SSFS_.DAT), nothing prevents an attacker from stealing the data that this storage contains.
Besides user passwords, an attacker, for example, can get access to the root key. The eponymous database called SAP HANA is an in-memory solution, which means that all data are processed in random-access memory of a server that, for instance, does not allow an attacker to simply copy the database file and access the data. However, as it turns out, HANA uploads data to the disk as a backup.
“The SAP HANA database holds the bulk of its data in memory for maximum performance, but it still uses persistent disk storage to provide a fallback in case of failure. Data is automatically saved from memory to disk at regular savepoints. The data belonging to a savepoint represents a consistent state of the data on disk and remains so until the next savepoint operation has completed., After a power failure, the database can be restarted like any disk-based database and returns to its last consistent state,” – says SAP HANA Security Guide.
An attacker seems to be able to access the data from these backups. To prevent it, SAP has implemented disk encryption.
“Data volume encryption ensures that anyone who can access the data volumes on disk using operating system commands cannot see the actual data. If data volumes are encrypted, all pages that reside in the data area on disk are encrypted using the AES-256-CBC algorithm. After data volume encryption has been enabled, an initial page key is automatically generated. Page keys are never readable in plain text, but are encrypted themselves using a dedicated persistence encryption root key.” – SAP HANA Security Guide.
But try to guess where SAP HANA stores these keys. You are absolutely right, in the following fields of SSFS_ < SID>.DAT file:
_SERVER/PERSISTENCE/ROOTKEY _SERVER/DPAPI
“SAP HANA uses SAP NetWeaver SSFS to protect the root encryption keys that are used to protect all encryption keys used in the SAP HANA system from unauthorized access.” – SAP HANA Security Guide
Thus, with access to protected storage, an attacker can also gain access to the encrypted SAP HANA disk and, as a consequence, compromise sensitive data stored in the database.
Defense:
- Change SSFS master key using the rsecssfx tool
- Change Data volume encryption root key using the hdbnsutil tool
- Change Data encryption service root key using the hdbnsutil tool
- Monitor your SAP system regularly for various vulnerabilities and misconfigurations to prevent attackers from accessing your database.
References:
Comments