S/4HANA Database Security: Securing Your HANA DB in 8 Steps

With S/4HANA, the SAP HANA database moves to the centre of the entire system architecture. Unlike classical databases such as Oracle or DB2, which were “hidden” behind the application server, HANA in S/4HANA is the central data store and compute engine. This means: a compromised database access endangers not only data but the entire business logic. This guide shows 8 concrete measures to secure your HANA database.

1. Secure SYSTEM and Emergency Users

The SYSTEM user in HANA has unrestricted rights to the entire database by default. The most important measure after every HANA installation:

• Change the SYSTEM user password – immediately after installation, using a password that meets the same complexity requirements as your strongest policies.
• Deactivate SYSTEM for daily operations. Instead, create dedicated admin users with only the privileges they need.
• Establish an emergency user concept: a secured emergency user (not SYSTEM) with documented four-eyes-principle approval for emergencies.
• Check other standard users: _SYS_REPO, _SYS_STATISTICS and other technical users should have minimal privileges.

2. Encryption at All Levels

HANA as an in-memory database requires a multi-layered encryption concept:

Data-at-Rest (Persistence Encryption)

• Enable Persistence Encryption – encrypts data on persistent storage (data volumes, log volumes). Configuration via ALTER SYSTEM SET ENCRYPTION ON.
• Page-Level Encryption – available since HANA 2.0 SPS05. Encrypts individual pages in the data volume rather than entire volumes.
• Root Key Management – the root encryption key should be managed externally (KMIP integration or SAP HANA Key Management).

Data-in-Transit (Communication)

• TLS/SSL for all HANA connections – both for client access (JDBC, ODBC, HANA Studio) and for system replication.
• Internal Communication Encryption – in scale-out scenarios, encrypt internal communication between HANA nodes.
• indexserver.ini → [communication] → ssl = systempki – enforces SSL for the index server.

Data-in-Use (In-Memory)

• Classical encryption does not protect data in RAM. What helps here: strict access control, OS-level security and network segmentation.
• In RISE/Cloud environments, SAP additionally offers Confidential Computing options with Intel SGX / AMD SEV.

3. Access Control: Who Can Do What at DB Level?

The SAP authorisation concept at ABAP level does not protect against direct database access. A parallel HANA authorisation concept must exist:

• Least privilege at DB level – every user receives only the privileges they need for their task. No DATA ADMIN for developers.
• Schema-based separation – different schemas for different applications. Access only to one’s own schema.
• Analytic Privileges for reporting access – restrict the visible data subset at row level.
• Control SQL access: who is allowed to access the database directly via HANA Studio, DBeaver or JDBC? Ideally only DBA emergency accounts and automated processes.

4. Configure HANA Audit Policies

HANA has its own audit framework that operates independently of the SAP Security Audit Log (SAL) at ABAP level:

• Audit policy for privileged actions – log every use of SYSTEM, DATA ADMIN, or CATALOG READ.
• Monitor DDL statements – CREATE, ALTER, DROP on tables and views. Prevents unauthorised schema changes.
• Track failed logins – detect brute-force attempts at DB level.
• Log configuration changes – changes to INI files (global.ini, indexserver.ini) must be traceable.
• Secure audit trail externally – forward HANA audit logs to a SIEM system (syslog target). Local logs can be deleted by an attacker with DB admin rights.

Configuration via HANA Studio or SQL: CREATE AUDIT POLICY policy_name AUDITING SUCCESSFUL ...

5. Network Segmentation for HANA

HANA opens several network ports that must be specifically protected:

• Port 3<NN>13 (indexserver) – reachable only from the SAP application server. Never directly from the office network.
• Port 3<NN>15 (indexserver SQL/MDX) – for BI tools, strictly controlled and only via VPN or jump server.
• Port 3<NN>17 (XS Engine / Web) – only enable if XS Advanced is required. Otherwise deactivate.
• Dedicated DB network – HANA should run in its own VLAN, separated from the application and user network.
• System replication – if HANA System Replication (HSR) is used, route replication over a separate network and encrypt it.

6. Backup Security

An unencrypted backup is a complete data set in the hands of an attacker:

• Enable backup encryption – BACKUP DATA USING BACKINT ('ENCRYPTION_KEY') or via the backup configuration in global.ini.
• Secure the backup target – configure NFS shares, Azure Blob Storage or AWS S3 with their own access control and encryption.
• Verify backup integrity – regular recovery tests. A backup that cannot be restored is not a backup.
• Backup retention & rotation – define clear retention periods. Old backups that are no longer needed must be securely deleted.
• 3-2-1 rule: 3 copies, 2 different media, 1 copy off-site.

7. HANA Updates & Patching

The HANA database is a standalone software product with its own patch cycle:

• SPS upgrades (Support Package Stacks) – released semi-annually. Contain new security features and fixes. Plan at least one SPS upgrade per year.
• Revision updates – released more frequently, containing security fixes. Apply critical revisions within 30 days.
• SAP Security Notes for HANA – published separately from the ABAP stack. Set up dedicated monitoring (keyword: kernel patches vs. DB patches).
• Check compatibility – the HANA version must be compatible with the S/4HANA version. The SAP Product Availability Matrix (PAM) is authoritative.

8. Monitoring & Anomaly Detection

Proactive monitoring is the key to early detection of security incidents:

• HANA Cockpit for centralised monitoring of all HANA instances. Configure alerts for unusual activities.
• Monitor memory consumption – sudden spikes may indicate DoS attacks or uncontrolled queries.
• Identify long-running SQL statements – these can be both a performance issue and an indication of data exfiltration.
• Track connection count – an unusually high number of simultaneous connections from unknown IPs is a warning sign.
• Integration with SIEM – consolidate HANA alerts, audit logs and OS-level events in a central Security Information and Event Management (SIEM) system.

Checklist: HANA DB Security at a Glance

Conclusion

The security of an S/4HANA environment stands and falls with securing the HANA database. Many organisations invest considerably in ABAP authorisations and network firewalls but overlook the database level. A compromised DB access bypasses all application security. The 8 measures in this guide form a solid foundation – regardless of whether you run HANA on-premise, in the private cloud or via RISE with SAP.

Want to have your HANA database professionally secured? We offer a structured HANA Security Check as a starting point.

Request HANA Security Check →

Related Articles

Need support with this topic?

We help you with implementation – from analysis to go-live.

Get in touch

← All articles