Describing Encryption

To protect data saved to disk from unauthorized access at the operating system level, the SAP HANA database supports data encryption in the persistence layer. Data volume encryption protects the data area on disk, while redo log encryption protects the log area on disk. SAP HANA data and log backups can be encrypted too.

The SAP HANA database holds most of its data in-memory for maximum performance. However, it still uses persistent disk storage as a fallback in case of failure. During normal operation, data is automatically saved from memory to disk at regular savepoints. Additionally, all data changes are captured in redo log entries. A redo log entry is written to disk with each committed database transaction. After a power failure, SAP HANA can be restarted like any disk-based database. It returns to its last consistent state by replaying the redo log entries since the last savepoint.

• Secure Communication – Encryption of data communication in the network

  Network traffic can be encrypted using Transport Layer Security (TLS), both between the SAP HANA database and clients, as well as between hosts in a distributed SAP HANA system.

• Encryption of the data persistence layer

  • The SAP HANA database can encrypt data at rest.

  • Encryption works at the page level and uses the AES256 encryption algorithm.

A cryptographic service provider on the server offers the following functions:

• The configuration of secure communication using TLS

• The encryption of the persistence layer

SAP HANA supports the following cryptographic libraries:

• CommonCryptoLib (default)

• OpenSSL

CommonCryptoLib (libsapcrypto.so) is installed by default as part of the SAP HANA server installation at $DIR_EXECUTABLE.

The OpenSSL library is installed by default as part of the operating system installation. In most cases, you can use OpenSSL instead of CommonCryptoLib. However, there are some features in SAP HANA that are only supported by CommonCryptoLib; future features might also only be supported by CommonCryptoLib. For more information, see SAP Note 2093286.

Data volume, redo logs and backups (data and log) can be encrypted as follows:

• Data Volume Encryption

  If data volumes are encrypted, all pages that reside in the data area on disk are encrypted using the AES-256-CBC algorithm. Pages are transparently decrypted as part of the load process into memory. When pages reside in-memory, they are therefore not encrypted, and there is no performance overhead for in-memory page accesses. When changes to data are persisted to disk, the relevant pages are automatically encrypted as part of the write operation.

  Pages are encrypted and decrypted using 256-bit page encryption keys. Page keys are valid for a certain range of savepoints and can be changed by executing SQL statements. After data volume encryption is enabled, an initial page key is automatically generated. Page keys cannot be read in plain text, but are encrypted themselves with a dedicated data volume encryption root key. This key is generated randomly during installation.

• Redo Log Encryption

  If redo logs are encrypted, log entries are encrypted using the AES-256-CBC algorithm before they are written to disk. Log entries are encrypted and decrypted using a 256-bit long root key, which is generated randomly during installation.

• Backup Encryption

  Switch on backup encryption and all subsequent data backups, delta backups, and log backups will be encrypted. Note that data snapshots are not encrypted unless data volume encryption is enabled.

During start up, administrator interaction is not required. The data volume encryption, redo log and backup encryption root keys are stored using the secure storage in the file system (SSFS) functionality, and are automatically retrieved from there.

SAP HANA allows you to encrypt data volumes and redo logs independently of each other. However, if you require full protection in the persistence layer, you should enable both.

Enabling encryption does not increase data size.

The persistence encryption feature does not encrypt the database traces.

For security reasons, do not run the system with extended tracing for more than short-term analysis. This is because tracing might expose security-relevant data that is encrypted in the persistence layer, but not in the trace. Therefore, do not keep such trace files on disk beyond the respective analysis task.

The following external and internal communication channels can be secured:

The connections between SAP HANA and external components and applications come under the following categories:

SAP HANA supports encrypted communication for network communication channels. Use encrypted channels wherever network attacks such as eavesdropping are not protected by other network security measures, for example, access from end-user networks. Alternatively, you can use virtual private network (VPN) tunnels to transfer encrypted information.

Separate certificate collections are supported for internal communication and external communication.

A certificate collection is also referred to as a personal security environment or PSE. It is a secure location where the public information (public-key certificates) and private information (private keys) of the SAP HANA server are stored. A certificate collection can also contain the public information (public-key certificates) of trusted communication partners or root certificates from trusted certification authorities.

By default, certificate collections for client-server communication over JDBC/ODBC are stored within the database. However, to maintain compatibility with previous releases, certificate collections (PSEs) can also be stored in the file system. You can create the certificate collections in the database directly.

The keys and certificates in the certificate collection for internal communication are used for the following communications:

• Communication between database services

• Communication between hosts in a multi-host system

• Communication between hosts and sites in a system replication scenario

Certificates for external communication (for example, JDBC client access, HTTP access) are typically signed by an externally available certification authority (CA). This is because the CA certificates need to be integrated in the relevant clients.

The TLS/SSL protocol secures communication between the SAP HANA database and the clients that access the SQL interface of the database. To use this function, configure the TLS/SSL on both the server and the client.

Server certificate validation is provided by enabling TLS/SSL for client-server communication. The server identifies itself to the client when the connection is established. This reduces the risk of man-in-the-middle attacks and prevents fake servers gaining information from clients.

If the identity of the client connecting to SAP HANA should be validated, you can also enable client certificate validation.

When you configure TLS/SSL on the SAP HANA server, the following general prerequisites apply:

• The SAP Cryptographic Library CommonCryptoLib is available on the server

• The SAP HANA server possesses a public and private key pair, and a public-key certificate

SAP HANA uses X.509 client certificates to secure internal and external communication channels, as well as for several user authentication mechanisms. Certificates can be stored and managed in files in the file system and, in some cases, directly in the SAP HANA database.

All certificate-based user authentication mechanisms in SAP HANA rely on X.509 client certificates for authentication and verification of digital signatures. Secure communication between SAP HANA and clients that access the SQL interface of the database also rely on these certificates. To improve management, you can store these certificates and configure their use directly in the SAP HANA database.

In systems that support multi-tenant database containers, in-database certificates are also used to secure communication when copying or moving a tenant database between two systems.

Although we recommend using in-database storage where possible, you can store and manage certificates in trust and key stores located in the file system. These are personal security environments or PSEs.

However, not all certificates can be stored in the database. In particular, the certificates required to secure internal communication channels with the system public key infrastructure (system PKI) and HTTP client access using SAP Web Dispatcher cannot be stored there. These certificates are contained in PSE files in the file system. Do not delete these files from the file system.

Certificates in the database-managed certification store are used for securing TLS in different communication channels.

Database managed certification store supports

Client-Server communication over JDBC/ODBC, tenant database replication, LDAP server communication and SAML. SAP Logon and Assertion Tickets and X.509 authentication is also included.

File system managed certificates supports

Client-server communication over HTTP and the internal communication.

In-database certificates and certificate collections can be fully managed certificates in the SAP HANA cockpit.

The management of certificates in the SAP HANA database follows a typical workflow. User authorization allows for a full separation of duties. The full workflow is supported by the SAP HANA cockpit.

Certificates in the database can be managed using SAP HANA cockpit or SQL. There are certificates that are managed in the file system, for example, TLS/SSL for HTTP, and TLS/SSL for internal communication (automatic setup via SystemPKI). These cannot be managed with the SAP HANA cockpit functionality. Simplified configuration for these scenarios is achieved by other means (SystemPKI).

You can secure the following internal communication channels:

• Between databases in a multiple-container system

  For an MDC system, only encryption is available; tenant authentication is unavailable.

• Between hosts in a scale-out system

  Also between processes in a single-host system.

• Between SAP HANA systems in system replication scenarios

  Metadata and data channel.

• Between the SAP HANA database and additional server components

  For example, an extended storage server (SAP HANA dynamic tiering option) and smart data streaming server (SAP HANA smart data streaming option).

A public-key infrastructure (PKI system) for securing internal communication channels using TLS is set up automatically during installation. No user interaction is required for the setup.

The keys and certificates used by the PKI system include the following features:

• Each component (host, database, additional server, and so on) receives a public/private key pair and a public-key certificate for mutual authentication.

• The certificates are signed by a dedicated trusted certificate authority (CA), which is unique for each SAP HANA system.

• The certificates are renewed automatically.

• CommonCryptoLib is used as the cryptographic library.

Depending on the communication channel, you might need to enable TLS explicitly.

The initial default master keys that protect the two SSFSs used by SAP HANA are changed during installation or upgrade. If you received your system pre-installed from a hardware or a hosting partner, change them immediately after hand-over to ensure that they are not known outside of your organization.

You change the SSFS master keys using the command-line tool rsecssfx. This requires operating system access (<sid>adm user). For more information about how to change the SSFS master keys, see the SAP HANA Administration Guide.

Encryption root keys are stored in the instance SSFS. Before you change these root keys, it is important to understand how the key change process impacts the recoverability of the database. In some cases, a backup of encryption root keys must be available.

The recommended approach is to always back up all root keys.

SAP HANA generates unique keys during installation. However, if you received SAP HANA pre-installed from a hardware vendor, you can change them to ensure that they are not known outside of your organization. Perform this immediately after hand-over from your hardware partner.

Use the SAP HANA cockpit to change the data volume encryption root key, redo log encryption root key, the backup encryption root key, and the internal application encryption service root key. The key change process is as follows:

1. Generate new keys.
2. Back up new keys.
3. Activate new keys.
4. Back up activated keys.

For more information, see the SAP HANA Administration Guide.

You can change all individual keys manually.

When enabled encryption during installation (default) or after you have generated or activated new encryption root keys, or created a new tenant database with new root keys, you must back up all root keys.

Before backing up the root keys, you have to set the root key backup password. Store the root key backup file in a safe location. Losing this file may result in the database being unrecoverable.

As previously described, encryption of data, logs, and backups is set by default during installation. Therefore, if you do not follow the default settings, proceed as follows to configure and manage data encryption in your SAP HANA system for the first time:

1. Change the master keys of the instance SSFS and the system PKI SSFS.

   Unique master keys are generated during installation or update. You can also change the master keys anytime.

   An administrator can change the SSFS master key using the command-line tool rsecssfx and the credentials of the operating system user <sid>adm. Therefore, the SAP HANA system has to be stopped. For special scenarios like snapshot-based backup and restore, or system replication, see SAP Note 2194396 - After upgrade or SSFS key change wrong SSFS key on System Replication secondary site.

2. Configure the password for the root key backup.

   This password is required to back up the root keys and to restore the backed-up root keys during data recovery.

3. Change the encryption root keys for all encryption services, including the following:

   • Data volume encryption

   • Redo log encryption

   • Internal application encryption

4. Enable the following required services:

   • Data volume encryption

   • Redo log encryption

5. Periodically change the SSFS master keys and encryption root keys according to your security policy.

6. Back up the root keys.