Security recommendations for SAP HANA on RHEL

SAP HANA is SAP’s in-memory database (DB) that has been around since 2010. It is used as the backbone of their main applications like Enterprise Resource Planning (ERP) or Business Warehouse (BW), or as a standalone application since it incorporates many features that are useful for Big Data and analytics.

There are other databases (Oracle, SQL Server, DB2, MaxDB and Sybase) on which SAP applications can run, but starting in 2027 customers wishing to maintain regular support will have to migrate to the new ERP suite, SAP S/4HANA. The suite only runs on SAP HANA, and Red Hat Enterprise Linux (RHEL) is one of two supported platforms for the database.

All of SAP’s applications are critical since they sit at the core of the company, and SAP HANA is especially resource demanding. Given this criticality, IT departments need to drive the highest levels of security and performance for the SAP ecosystem to limit impact on the company’s operations.

In February 2022, after extensive testing on RHEL 8.2, 8.4, 8.6 and 9 using the SAP HANA validation test suite (which is used by SAP to assess if a system can run SAP HANA at acceptable performance levels), Red Hat’s engineering team concluded that SELinux can run in Enforcing mode (the recommended mode) with a minimal impact to database performance (around 2%, which is acceptable and in line with SAP standards). 

SAP has already modified the OSS Note with the recommendations for SAP HANA on RHEL 8, and will do so for other versions once they have completed the tests themselves.

This is important because it means that RHEL customers will be able to apply higher security levels to their hosts running SAP HANA and tailor the policies to their needs. This adds another piece to the Red Hat platform for SAP workloads that plays a crucial role in providing everything RHEL customers need to manage the entire lifecycle of the SAP hosts in an easier way with a stronger security posture.

What is SELinux?

Security-Enhanced Linux (SELinux) is a Linux Security Model (LSM) that allows defining security policies to implement mandatory access controls (MAC), providing a very granular layer to strengthen the OS against attacks. The underlying idea is to regulate or constrain the possible actions of a subject (usually a process) on a target (files, memory, I/O devices, network resources, etc.). 

The policies contain rules that are evaluated when a subject tries to access a target to determine whether access will be allowed. In addition to MAC, SELinux is also based on and implements role-based access control (RBAC).

In SELinux, processes run in domains so they are separated from each other. Each process is assigned a username, a role and a domain, and each target is labeled with a name, role and a type. In the policies, the domains that users need to belong to in order to execute an action on a target (for example to bind to a listening port) are specified. If a process is compromised, the attacker will only have access to the resources in the domain that process has been assigned to, avoiding the danger of that attacker having access to system files and gaining control of the whole operating system.

This is also a very useful feature for applications deployed in containers, as it provides an additional layer of isolation between the containers and the hosts on which they run.

SELinux has 3 operation modes:

• Enforcing. The policies are active and enforced.

• Permissive. The system uses the policies but it does not deny access to the targets, it just writes the approval and denial messages in the system logs (this mode is normally used to test policies before rolling them out to production).

• Disabled.

Further recommendations

There are other security guidelines that Red Hat’s engineering team have compiled in this whitepaper as a result of this testing.

Minimize RHEL and package installation

The first is to carry out a minimal installation of RHEL on the servers that will host SAP HANA in order to minimize the opportunities for malicious exploits. There are many packages in the OS that aren’t used by a host that only runs SAP HANA, so there is no need to install them as they can be potential points of attack. Besides this, having a minimal installation will make the server update process much easier.

From RHEL 7 on there is an option that allows you to install only the packages needed for basic functionality. In addition to that, the compat-sap c++ and libtool-ltdl will need to be installed as well, as they are used by the DB. Depending on the customer scenario, they might need to install additional packages on top of the minimal installation, but the recommendation from Red Hat is to go for the minimal RHEL installation plus the two additional packages, and then add the rest that are necessary depending on the usage of the DB.

Complementing the minimal package installation, we can use a plugin to whitelist application RPMs. The fapolicyd RPM plugin registers any update done with YUM or RPM package managers and notifies the fapolicyd daemon about changes in the install database. If there is an attempt to install an RPM which is not in the fapolicyd whitelist, it will be denied.

Another recommendation is to disable all of the network services that are not strictly needed for the normal functioning of SAP HANA and for the applications and users to connect to it. Here, as with the OS packages, the fewer network services listening on different ports, the lower the chances of attack. And since network services need to be regularly patched to avoid newly discovered exploits, their maintenance will be easier if their number is reduced. Some of the services whose deactivation is highly recommended are vsftpd (Very Secure FTP Daemon) and  telnet, because the transactions of the former are unencrypted and the latter is an unsecured protocol.

Restrict user privileges

The next recommendation for hardening the security of RHEL hosts running SAP HANA is to restrict the number of users that can run the sudo command and thus be able to execute other commands as root.

It’s also very important to disable the possibility of logging in with the root user via ssh, so that it can only be utilized locally on the host. Having another account (with permissions to log on via ssh) that can run a reduced set of administrative commands using ‘su -’ should be enough.

All SAP installations create a user called <sid>adm (‘sid’ is the SAP installation name or identifier) and it has unrestricted permissions over all the SAP processes and files. It is similar to root at SAP level and it also exists for SAP HANA. It is recommended to limit the number of people with access to this user and change its password as soon as the system is handed over to the admin team after installation and set up.

Automate logouts and password expiry

The next set of recommendations concerns the password and login policies for the users. It is advised to enable automatic logouts after a certain time of inactivity, to define the validity period of passwords as well as how often they can be changed and to lock out users after a number of failed attempts, so that brute force attacks are prevented.

Restrict user file and home directory permissions

There are also things to consider regarding file and user home directory permissions. Newly created files should not by default be readable or modifiable by users other than the one that has created them. In order to achieve this, the default umask for new files should be set to 077, and home directories should only be accessible by their owner.

Encrypt hard drives

An added layer of security is achieved by using encrypted hard drives. In order to unlock root and secondary volumes that are encrypted, RHEL provides an implementation of the Policy-Based Decryption (PBD) that allows different unlocking methods to be combined (like user password, Trusted Platform Module devices (TPM), smart cards, etc.) in the form of policies so that the volumes can be unlocked in different ways.

The implementation that comes with RHEL consists of the Clevis framework and plugins called pins. The recommendation is to use one of the subcategories of PBD called Network Bound Disk Encryption (NBDE) with which root volumes can be encrypted (on physical and virtual machines) and the encryption key is tied to an external server (or servers) in a secure and anonymous way across the network.

The node that has the root volumes to be unlocked uses a Clevis client, and the external server(s) are Tang server(s). When the node boots, it tries to connect to the external Tang server(s) performing a cryptographic handshake. If it can reach the minimum number of servers that has been defined (or the only server if there is only one Tang server) it will be able to construct its decryption key to unlock the volume and continue booting. This mechanism makes it more difficult for attackers to gain control of the node because they would need access to it and to the Tang server(s).

Encrypt network traffic

SAP HANA supports the use of encrypted channels for both client connections (from applications, users, administration clients or data provisioning tools) and internal DB process communication, so it is recommended to use this feature when the network is not protected in another way.

Another possibility is to use VPN tunnels to transfer encrypted information. It is very important to have a well-defined network topology for SAP HANA tailored to the use cases of the customer. The SAP HANA Security Guide contains many more recommendations that should be taken into account when planning a SAP HANA landscape deployment. A particularly important one is to configure SSL between the DB and the clients.

Conclusion

This set of recommendations allows customers to run their SAP workloads in an environment with greater security controls while maintaining very granular control of the processes that keep performance levels at an optimal level. Find out more here: Red Hat Enterprise Linux Security Hardening Guide for SAP HANA 2.0.

If you are interested in more solutions built with these and other products of the Red Hat's portfolio visit the Portfolio Architecture website.