Describing Encryption

Objectives

After completing this lesson, you will be able to:

  • Describe encryption

Encryption Overview

Data Volume and Redo Log 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

Cryptographic Libraries

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 Rest Encryption

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.

Note

SAP HANA uses the SSFS instance to protect the encryption root keys from unauthorized access. These root keys protect all encryption keys used in the SAP HANA system, and are encrypted using the SSFS master key.

Unencrypted Data

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.

Secure Communication

Types of Network Communication Channels

To support the different SAP HANA scenarios and setups, SAP HANA provides the following types of network communication channels:

  • Channels used for external access to SAP HANA functionality by end-user clients, administration clients, application servers, and for data provisioning through SQL or HTTP

  • Channels used for SAP HANA internal communication within the database, between hosts in multi-host systems, and between systems in system replication scenarios

Network Integration

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:

External Communication Channels

  • Connections used for administrative purposes

  • Connections used for data provisioning

  • Connections from database clients that access the SQL/MDX interface of the SAP HANA database

  • Connections from HTTP(S) clients

  • Outgoing connections

Internal Communication Channels

  • Internal database communication

  • Internal communication between hosts in a distributed (multi-host) SAP HANA system

  • Internal communication between systems at the different sites in a system replication (high availability) scenario

  • Internal communication between the SAP HANA database and server components, such as extended storage (SAP HANA dynamic tiering)

Communications Using Transport Layer Security Protocol

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.

The network communication can be secured with the Transport Layer Security (TLS) protocol, as follows:

  • Communication between the SAP HANA database and clients that access the SQL interface of the database

  • Internal network communication between the individual components of an SAP HANA system on a single host and also between multiple hosts if the system is distributed

  • For Client Application Access, the SAP Web Dispatcher can be configured to use HTTPS (TLS) for incoming requests from UI front ends and applications, for example, SAP HANA applications. The requests are then forwarded to SAP HANA.

  • Communication between the SAP HANA lifecycle management tools and SAP HANA cockpit, SAP Service Marketplace, and SAP Host Agent

  • Communication between SAP HANA cockpit and sapstartsrv

  • Communication between SAP HANA cockpit and SAP Host Agent

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.

Use of Communication in Keys and Certificates

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.

Secure Communication Between SAP HANA and JDBC/ODBC Clients

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.

Note

You can force all clients who communicate with the SAP HANA database through the SQL interface to use a secured connection. To do this, set the sslEnforce parameter in the communication section of the global.ini configuration file to true. The database then refuses SQL connection attempts that do not use SSL.

Secure Communication Between SAP HANA and JDBC/ODBC Clients

  • TLS/SSL Configuration on the SAP HANA Server

  • Server-Side TLS/SSL Configuration Properties for External Communication (JDBC/ODBC)

  • TLS/SSL Configuration on the Client

  • Client-Side TLS/SSL Configuration Properties (ODBC)

  • Client-Side TLS/SSL Configuration Properties (JDBC)

  • Configure SSL for SAP HANA Cockpit Connections

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

Connection Encryption Configuration: Server-Side Configuration

  • TLS is installed (for example, Open SSL)

  • A certificate is required for both sides when connecting with a TLS configured client.

  • Certificate hierarchy and certificate for the SAP HANA database server are available

    The corresponding root certificate has been deployed on all clients that are to use a TLS-encrypted connection to the server

  • Configuration can be customized for SQLDBC/JDBC-based clients using parameters in the indexserver.ini file, in the Communication section

Certificate Management

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.

Certificates Required for Securing Client-Server Communication using TLS

Server private key
  • Used by the server to encrypt the connection

  • Stored securely using the internal data encryption service of the SAP HANA database

Server certificate

Used by the client to authenticate the server

Root certificates from trusted CAs or certificates from trusted communication partners
  • Optional

  • Used by the client for trust validation (certificate chains)

Certificates Required for User Authentication

User certificates
  • Used by the server to authenticate the connecting user

  • SAML assertions, SAP logon, or assertion tickets, X.509 certificates (HTTP access over XS only)

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.

Certificate Store

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.

Certificate Management using 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.

In-Database Certificate Management Workflow

To manage in-database certificates, proceed as follows:

  1. Import the public-key certificates of trusted communication partners, and the root certificates of trusted certification authorities, into the certificate store.

  2. Complete the following steps:

    1. Create the required certificate collections.

    2. Add trusted certificates from the certificate store to certificate collections.

    3. Add the SAP HANA server certificates to those collections that will be used for server authentication (for example, secure client-server communication over JDBC/ODBC).

  3. Set the purpose of individual collections. The privilege that is required depends on the purpose that is set.

Certificate Management with 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).

Note
For information on migrating file-based certificates into the database, see SAP Note 2175664.

Automatic Generation of PKI/Certificates for Internal Communication Channels

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.

Note

The PKI system cannot be used to secure the communication between the SAP HANA server and clients.

PKI System Keys and Certificate Features

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.

Note
For information on the migration from manual system SSL configuration to the PKI system, see SAP Note 2175672.

Monitoring of Network Security Settings

Network Security Settings

The Network Security Information screen shows the following information:

  • Internal and external network security configuration

  • Certificate and private key stores

Configuration and Monitoring of Data Volume Encryption

If you have not chosen to enable encryption during the installation process, data-at-rest encryption on disk can be configured using SAP HANA cockpit or SQL commands afterwards.

After activating encryption, new data that is saved to disk is encrypted, starting with the next savepoint, log write, or backup. Because of the shadow memory nature of SAP HANA persistence, outdated versions of pages can remain unencrypted on disk. All future redo log entries persisted to log volumes are encrypted.

Caution

For complete protection, we recommend when you reinstall the system to enable data volume encryption during the installation process. All your data is encrypted only after the installation has finished. This also ensures that a new root encryption key is generated.

You can change the page encryption key for the data volume encryption with SAP HANA cockpit or SQL commands.

Enable Data Encryption using SQL:

  • Data Volume encryption:

    Code snippet
    ALTER SYSTEM PERSISTENCE ENCRYPTION ON
    Expand
  • Redo Log encryption:

    Code snippet
    ALTER SYSTEM LOG ENCRYPTION ON
    Expand
  • Backup encryption:

    Code snippet
    ALTER SYSTEM PERSISTENCE BACKUP ON
    Expand

Disable Data Encryption using SQL:

  • Data Volume encryption:

    Code snippet
    ALTER SYSTEM PERSISTENCE ENCRYPTION OFF
    Expand
  • Redo Log encryption:

    Code snippet
    ALTER SYSTEM LOG ENCRYPTION OFF
    Expand
  • Backup encryption:

    Code snippet
    ALTER SYSTEM PERSISTENCE BACKUP OFF
    Expand

After you change the page encryption key, you can choose if you also want to re-encrypt the existing encrypted data with the new key. This happens in the background.

You can monitor the encryption progress in SAP HANA cockpit or with SQL commands.

Note

Although you can encrypt data volumes and redo logs independently of each other with SAP HANA, if you require full protection in the persistence layer, enable both.

SAP HANA cockpit offers ON/OFF switches for Data Encryption. The Data Encryption tile shows important information about the status of data volume, log volume, and backup encryption. Additionally, it informs about the change date of root keys.

Note

You can view the status of data volume encryption and redo log encryption in the M_ENCRYPTION_OVERVIEW system view.

SSFS Encryption Keys

Changing the SSFS Master Keys

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 Key Management

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.

Encryption Root Keys

KeyImpact on the Recoverability of the Database
Data volume encryption root keyChanging the data volume encryption root key does not require a root key backup as a data backup will always contain all the required information to recover that backup successfully. For snapshot-based backups, the data volume encryption root key is part of the data backup itself. For backups other than snapshot-based backups, the data volume encryption root key is not required to recover the system at all.
Redo log encryption root keySAP HANA does not log the key change operation of the redo log encryption root key in the SAP HANA redo log. This means that the redo log encryption root key must be backed up after a new one is created, but before it is actually used to encrypt data. In this way, it is ensured that even in the case of a disaster recovery, all encrypted data can be recovered successfully.
Backup encryption root keySAP HANA does not log the key change operation of the backup encryption root key in the SAP HANA redo log. This means that the backup encryption root key must be backed up after a new one is created, but before it is actually used to encrypt data. In this way, it is ensured that even in the case of a disaster recovery, all encrypted data can be recovered successfully.
Application encryption service root keySAP HANA does not log the key change operation of the application service encryption root key in the SAP HANA redo log. This means that the application service encryption root key must be backed up after a new one is created, but before it is actually used to encrypt data.

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

How to Change Encryption 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.

Back up Root Keys

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.

Managing Data at Rest Encryption

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.

Log in to track your progress & complete quizzes