S/4HANA Datenbanksicherheit: HANA-DB absichern in 8 Schritten

Mit S/4HANA rückt die SAP HANA-Datenbank ins Zentrum der gesamten Systemarchitektur. Anders als bei klassischen Datenbanken wie Oracle oder DB2, die hinter dem Applikationsserver „versteckt“ waren, ist HANA in S/4HANA der zentrale Datenspeicher und Rechenmotor. Das bedeutet: Ein kompromittierter Datenbankzugriff gefährdet nicht nur Daten, sondern die gesamte Geschäftslogik. Dieser Leitfaden zeigt 8 konkrete Maßnahmen, um Ihre HANA-Datenbank abzusichern.

1. SYSTEM- und Notfall-Benutzer absichern

Der SYSTEM-Benutzer in HANA hat standardmäßig uneingeschränkte Rechte auf die gesamte Datenbank. Die wichtigste Maßnahme nach jeder HANA-Installation:

• Passwort des SYSTEM-Benutzers ändern – sofort nach Installation, mit einem Passwort, das der gleichen Komplexität wie Ihre stärksten Policies entspricht.
• SYSTEM deaktivieren für den täglichen Betrieb. Erstellen Sie stattdessen dedizierte Admin-Benutzer mit nur den benötigten Privilegien.
• Notfall-Benutzer-Konzept etablieren: Ein gesicherter Notfall-Benutzer (nicht SYSTEM) mit dokumentierter Vier-Augen-Freigabe für Notfälle.
• Weitere Standardbenutzer prüfen: _SYS_REPO, _SYS_STATISTICS und weitere technische Benutzer sollten minimale Rechte haben.

2. Verschlüsselung auf allen Ebenen

HANA als In-Memory-Datenbank erfordert ein mehrschichtiges Verschlüsselungskonzept:

Data-at-Rest (Persistenz-Verschlüsselung)

• Persistence Encryption aktivieren – Verschlüsselt Daten auf dem Persistent Storage (Data Volumes, Log Volumes). Konfiguration über ALTER SYSTEM SET ENCRYPTION ON.
• Page-Level-Encryption – Seit HANA 2.0 SPS05 verfügbar. Verschlüsselt einzelne Seiten im Data Volume statt nur ganzer Volumes.
• Root Key Management – Der Root Encryption Key sollte extern verwaltet werden (KMIP-Integration oder SAP HANA Key Management).

Data-in-Transit (Kommunikation)

• TLS/SSL für alle HANA-Verbindungen – Sowohl für Client-Zugriffe (JDBC, ODBC, HANA Studio) als auch für System-Replikation.
• Internal Communication Encryption – In Scale-Out-Szenarien die interne Kommunikation zwischen HANA-Nodes verschlüsseln.
• indexserver.ini → [communication] → ssl = systempki – Erzwingt SSL für den Indexserver.

Data-in-Use (In-Memory)

• Klassische Verschlüsselung schützt keine Daten im RAM. Hier greifen: strikte Zugriffskontrolle, OS-Level-Absicherung und Netzwerk-Segmentierung.
• In RISE/Cloud-Umgebungen bietet SAP zusätzlich Confidential Computing Optionen mit Intel SGX / AMD SEV.

3. Zugriffskontrolle: Wer darf was auf DB-Ebene?

Das SAP-Berechtigungskonzept auf ABAP-Ebene schützt nicht vor direkten Datenbankzugriffen. Parallel dazu muss ein HANA-Berechtigungskonzept existieren:

• Least Privilege auf DB-Ebene – Jeder Benutzer bekommt nur die Privilegien, die er für seine Aufgabe braucht. Kein DATA ADMIN für Entwickler.
• Schema-basierte Trennung – Verschiedene Schemata für verschiedene Anwendungen. Zugriff nur auf das eigene Schema.
• Analytic Privileges nutzen für Reporting-Zugriffe – beschränken den sichtbaren Datenausschnitt auf Zeilenebene.
• SQL-Zugriff kontrollieren: Wer darf per HANA Studio, DBeaver oder JDBC direkt auf die Datenbank zugreifen? Idealerweise nur DBA-Notfall-Accounts und automatisierte Prozesse.

4. HANA Audit Policies konfigurieren

HANA hat ein eigenes Audit-Framework, das unabhängig vom SAP Security Audit Log (SAL) auf ABAP-Ebene funktioniert:

• Audit Policy für privilegierte Aktionen – Jede Nutzung von SYSTEM, DATA ADMIN, oder CATALOG READ protokollieren.
• DDL-Statements überwachen – CREATE, ALTER, DROP auf Tabellen und Views. Verhindert unautorisierte Schema-Änderungen.
• Fehlgeschlagene Logins tracken – Brute-Force-Versuche auf DB-Ebene erkennen.
• Konfigurationszuänderungen protokollieren – Änderungen an INI-Dateien (global.ini, indexserver.ini) müssen nachvollziehbar sein.
• Audit Trail extern sichern – HANA-Audit-Logs an ein SIEM-System weiterleiten (Syslog-Target). Lokale Logs können von einem Angreifer mit DB-Admin-Rechten gelöscht werden.

Konfiguration über HANA Studio oder SQL: CREATE AUDIT POLICY policy_name AUDITING SUCCESSFUL ...

5. Netzwerk-Segmentierung für HANA

HANA öffnet mehrere Netzwerk-Ports, die gezielt geschützt werden müssen:

• Port 3<NN>13 (indexserver) – Nur vom SAP-Applikationsserver erreichbar. Niemals aus dem Büro-Netzwerk direkt.
• Port 3<NN>15 (indexserver SQL/MDX) – Für BI-Tools, streng kontrolliert und nur über VPN oder Jump-Server.
• Port 3<NN>17 (XS Engine / Web) – Nur aktivieren wenn XS Advanced benötigt wird. Ansonsten deaktivieren.
• Dediziertes DB-Netzwerk – HANA sollte in einem eigenen VLAN laufen, getrennt vom Applikations- und Benutzernetzwerk.
• System-Replikation – Falls HANA System Replication (HSR) genutzt wird, die Replikation über ein separates Netzwerk leiten und verschlüsseln.

6. Backup-Sicherheit

Ein unverschlüsseltes Backup ist ein kompletter Datensatz in den Händen eines Angreifers:

• Backup-Verschlüsselung aktivieren – BACKUP DATA USING BACKINT ('ENCRYPTION_KEY') oder über die Backup-Konfiguration in global.ini.
• Backup-Ziel absichern – NFS-Shares, Azure Blob Storage oder AWS S3 mit eigener Zugriffskontrolle und Verschlüsselung konfigurieren.
• Backup-Integrität prüfen – Regelmäßige Recovery-Tests. Ein Backup, das sich nicht wiederherstellen lässt, ist kein Backup.
• Backup-Retention & Rotation – Definieren Sie klare Aufbewahrungsfristen. Alte Backups, die nicht mehr benötigt werden, müssen sicher gelöscht werden.
• 3-2-1-Regel einhalten: 3 Kopien, 2 verschiedene Medien, 1 Kopie Off-Site.

7. HANA-Updates & Patching

Die HANA-Datenbank ist ein eigenständiges Softwareprodukt mit eigenem Patch-Zyklus:

• SPS-Upgrades (Support Package Stacks) – Erscheinen halbjährlich. Enthalten neue Sicherheits-Features und Fixes. Planen Sie mindestens ein SPS-Upgrade pro Jahr.
• Revision-Updates – Erscheinen häufiger, enthalten Security Fixes. Kritische Revisions innerhalb von 30 Tagen einspielen.
• SAP Security Notes für HANA – Werden separat vom ABAP-Stack veröffentlicht. Eigene Überwachung einrichten (Stichwort: Kernel-Patches vs. DB-Patches).
• Kompatibilität prüfen – HANA-Version muss mit der S/4HANA-Version kompatibel sein. Die SAP Product Availability Matrix (PAM) ist verbindlich.

8. Monitoring & Anomalie-Erkennung

Proaktives Monitoring ist der Schlüssel zur frühzeitigen Erkennung von Sicherheitsvorfällen:

• HANA Cockpit nutzen für zentrales Monitoring aller HANA-Instanzen. Alerts für ungewöhnliche Aktivitäten konfigurieren.
• Speicherverbrauch überwachen – Plötzliche Spitzen können auf DoS-Angriffe oder unkontrollierte Queries hindeuten.
• Langlaufende SQL-Statements identifizieren – Können sowohl ein Performance-Problem als auch ein Hinweis auf Datenexfiltration sein.
• Verbindungsanzahl tracken – Ungewöhnlich viele gleichzeitige Verbindungen von unbekannten IPs sind ein Warnsignal.
• Integration mit SIEM – HANA-Alerts, Audit-Logs und OS-Level-Events in ein zentrales Security Information and Event Management (SIEM) zusammenführen.

Checkliste: HANA-DB-Sicherheit auf einen Blick

Fazit

Die Sicherheit einer S/4HANA-Umgebung steht und fällt mit der Absicherung der HANA-Datenbank. Viele Unternehmen investieren erheblich in ABAP-Berechtigungen und Netzwerk-Firewalls, übersehen aber die Datenbankebene. Ein kompromittierter DB-Zugang umgeht sämtliche Applikations-Sicherheit. Die 8 Maßnahmen in diesem Leitfaden bilden ein solides Fundament – unabhängig davon, ob Sie HANA On-Premise, in der Private Cloud oder über RISE with SAP betreiben.

Sie möchten Ihre HANA-Datenbank professionell absichern lassen? Wir bieten einen strukturierten HANA Security Check als Einstieg an.

HANA Security Check anfragen →

Weitere Artikel

Brauchen Sie Unterstützung bei diesem Thema?

Wir helfen Ihnen bei der Umsetzung – von der Analyse bis zum Go-Live.

Jetzt anfragen

← Alle Artikel