Best Practices und Tools für eine sichere SAP-Umgebung

Secure by Default und die Rolle technischer Benutzer

SAP liefert S/4HANA mit aktivierter Secure-by-Default-Konfiguration aus. Viele sicherheitsrelevante Parameter sind bereits gesetzt, darunter TLS-Verschlüsselung, Audit-Log-Aktivierung und restriktive Gateway-Einstellungen. Trotzdem erfordert ein belastbarer Sicherheitsstandard zusätzliche Schritte. Die bekannten Standardbenutzer wie SAP*, DDIC oder EARLYWATCH bleiben Angriffspunkte, wenn ihre Kennwörter nicht unmittelbar geändert oder Konten vollständig gesperrt werden.

Technische RFC-Benutzer erfordern eine gezielte Einschränkung ihres Berechtigungsumfangs. Standardmäßig verfügen sie häufig über zu breite Rechteprofile oder generische Rollen, die weit über den funktionalen Bedarf hinausgehen. Deshalb sind ihre Rechte manuell auf die tatsächlich benötigten Funktionen zu reduzieren. Zugriffe auf Dialogtransaktionen, Debug-Umgebungen oder administrative Objekte bleiben ausgeschlossen. Die Trennung vom interaktiven Benutzerkontext ist ebenso durchzusetzen wie eine strikte Kontrolle über genutzte Rollen und ausführbare Funktionen. Nur so lässt sich die Rolle technischer Konten im Gesamtsystem sauber und sicher abbilden.

Parameter, Rollen und Zugriffskontrolle

Die SAP Security Baseline bildet die Grundlage für die technische Absicherung von S/4HANA-Systemen. Mit dem Report RSPFRECOMMENDED lassen sich aktive Profilparameter systemweit mit den empfohlenen Sicherheitseinstellungen abgleichen. Dabei geht es vor allem um Passwortrichtlinien, maximale Fehlversuche, Sperrzeiten und Regeln für Benutzer-Sessions. Rollen wie SAP_ALL oder SAP_NEW enthalten umfangreiche Berechtigungen ohne fachliche Trennung und sollten deshalb nicht zum Einsatz kommen. Stattdessen definieren Administratoren gezielt eigene Rollen, die nur die tatsächlich benötigten Transaktionen und Berechtigungsobjekte enthalten. Die Struktur trennt klar zwischen administrativen und fachlichen Aufgaben. Für Ausnahmen und Notfälle kommt das sogenannte Firefighter-Konzept zum Einsatz, das auf einem geregelten Freigabeprozess basiert und alle Aktionen vollständig protokolliert.

Das SAP Security Baseline Template liefert einen praxisorientierten Referenzrahmen für die grundlegende Absicherung von SAP-Systemen. Es stellt keine optionalen Empfehlungen dar, sondern definiert ein Mindestmaß an Konfiguration, das in produktiven Landschaften verpflichtend umzusetzen ist. Die Inhalte basieren auf der SAP Secure Operations Map, die Sicherheitsmaßnahmen entlang Layer System, Application, Identity, Process und Governance strukturiert. Das Template dokumentiert technische Vorgaben wie sichere Profilparameter, Passwortregeln, Verschlüsselungseinstellungen und Benutzerrestriktionen – inklusive Kritikalitätsbewertung und Prüfmethoden.

Das Template lässt sich in SAP Focused Run integrieren und ermöglicht dort eine automatisierte Prüfung sicherheitsrelevanter Einstellungen über vorkonfigurierte Prüfregeln. Für bestehende Umgebungen kann auch der Solution Manager genutzt werden, wobei die dort enthaltene Configuration Validation funktional eingeschränkt ist und von SAP langfristig nicht weiterentwickelt wird. Die aktuelle Version des Templates liegt als PDF- und Word-Datei vor und kann zusätzlich über GitHub für die technische Einbindung bezogen werden. Durch diese Integration lässt sich die Konformität mit der Baseline kontinuierlich überwachen. Jede Abweichung wird transparent, Risiken lassen sich frühzeitig erkennen.

Die technische Umsetzung kann über Templates automatisiert erfolgen, zum Beispiel bei der Prüfung sicherheitsrelevanter Parameter oder der Systemhärtung im Gateway. Ergänzt durch regelmäßige Patch-Zyklen, individuelles Monitoring und strukturiertes Rollenmanagement entsteht daraus ein belastbares Sicherheitsfundament. Die Baseline bildet dabei keinen Abschluss, sondern markiert den Ausgangspunkt für weiterführende Absicherungsmaßnahmen, die an die spezifischen Risiken und Systemkonstellationen angepasst werden.

Sichere Kommunikation und Protokollierung

Nach der Installation lässt das Gateway alle Registrierungen zu. Zugriffskontrollen greifen erst, wenn reginfo- und secinfo-Dateien vollständig eingerichtet sind und der Parameter gw/acl_mode auf 1 steht. Nur dann blockiert das System nicht autorisierte Verbindungen. Alle nicht ausdrücklich freigegebenen Registrierungen sind vorher erlaubt. Callback-Funktionen bleiben ausgeschaltet, wenn keine definierte Gegenstelle existiert. TLS oder SNC sichern RFC, HTTP, OData und SAP GUI erst nach manueller Konfiguration. ICM und Web Dispatcher setzen Sicherheits-Header nur bei aktivem Parameter-Set. Die Authentifizierung erfolgt über SAML, X.509 oder Kerberos, wenn Identity Provider vollständig angebunden sind. Single Sign-On läuft über SAP IAS oder angebundene Verzeichnisdienste. Konten mit erhöhten Rechten verlangen einen zweiten Faktor.

Monitoring, Logging und SIEM-Anbindung

Das Audit-Log protokolliert sicherheitsrelevante Vorgänge wie Anmeldungen, Rollenänderungen, Benutzerpflege, RFC-Zugriffe und Berechtigungsprüfungen. Die Aktivierung erfolgt direkt nach der Installation und bleibt dauerhaft aktiv. Für Webzugriffe liefert das ICM-Access-Log zusätzliche Daten über verwendete Endpunkte, Methoden und IP-Adressen.

Alle Protokolle fließen in externe Auswertungssysteme wie ein zentrales SIEM-System oder SAP Enterprise Threat Detection (ETD). So entsteht eine kontinuierliche Überwachung mit direkter Alarmierung bei Auffälligkeiten. In BW/4HANA ergänzt die Lesezugriffsprotokollierung (RAL) das Monitoring um den Zugriff auf sensible Dateninhalte. Transaktionale Zugriffe analysieren Administratoren über Query-Logs und Tabellen wie RSECVAL_CL und RSECUSERAUTH_CL.

Automatisierte Bedrohungserkennung und Echtzeit-Reaktion

Die Absicherung moderner SAP-Landschaften verlangt mehr als klassische Logging- und Prüfmechanismen. Mit SAP Enterprise Threat Detection steht eine native Lösung zur Verfügung, die sicherheitsrelevante Ereignisse in Echtzeit analysiert und automatisch korreliert. Die Lösung nutzt die In-Memory-Fähigkeiten von SAP HANA, um Log-Daten aus verschiedenen Komponenten zu aggregieren, zu durchsuchen und verdächtige Muster zu erkennen. Im Unterschied zu externen SIEM-Systemen verarbeitet ETD SAP-spezifische Protokollformate nativ. So lassen sich unter anderem ABAP-Logins, RFC-Aufrufe, Fiori-Zugriffe und Systemparameteränderungen in Echtzeit auswerten.

Ergänzend unterstützt ETD forensische Analysen durch rückwirkende Datenrecherche und dynamische Angriffsmuster. Angriffe wie ABAP Injection, Directory Traversal oder illegitime Rechteerweiterung lassen sich durch definierbare Regelwerke identifizieren. Alerts können automatisiert an Security-Teams übergeben oder in bestehende Sicherheitsplattformen integriert werden. Die enge Verzahnung mit SAP-eigenen Schnittstellen verhindert das Überschreiben oder Löschen kompromittierender Protokolle und erhöht so die Integrität des Monitorings. Über definierte Erkennungsmuster lassen sich neue Angriffstechniken integrieren, ohne Quellcode anzupassen. So entsteht ein geschlossenes System für Angriffserkennung und Sicherheitsereignismanagement, das sich mit zentralen Kontrollstrukturen verbinden lässt.

Patch-Management und Sicherheits-Updates

SAP veröffentlicht jeden Monat neue Security Notes mit Einstufung in High, Medium und Hot News. Administratoren sollten jeden Hinweis prüfen und bewerten, welche Patches für das eigene System erforderlich sind. Die Umsetzung läuft über SAP Cloud ALM oder den Solution Manager, abhängig von der eingesetzten Architektur. Nach dem Einspielen kritischer Updates sollten alle betroffenen Parameter kontrolliert und das Systemverhalten überprüft werden. Kernel, ICM, ABAP und HANA folgen getrennten Patch-Zyklen und müssen jeweils separat aktualisiert werden. Ohne klaren Ablauf bleiben bekannte Schwachstellen offen und angreifbar. Ein durchgehender Patch-Prozess verhindert diese Lücken und erhöht die Sicherheit.

Die HANA-Datenbank verlangt eigene Schutzmaßnahmen. Daten- und Log-Bereiche verschlüsseln Administratoren manuell, damit Inhalte auch im Ruhezustand geschützt bleiben. Der SYSTEM-User bleibt nach der Installation aktiv und besitzt uneingeschränkten Zugriff. Administratoren sollten das Konto direkt sperren und stattdessen eigene Admin-Benutzer mit minimalem Rechteumfang anlegen. Remote-Verbindungen lassen sich nur über TLS absichern. Tabellen, Views und administrative Funktionen stehen ausschließlich Rollen zur Verfügung, die gezielt zugewiesen sind. Das HANA Cockpit zeigt Konfigurationsfehler, Metriken und sicherheitsrelevante Abweichungen an. Die Audit-Funktionen protokollieren alle Zugriffe und leiten sie bei Bedarf an externe Monitoring-Systeme weiter.

Verzahnung von Cloud-Sicherheit und zentraler Zugriffskontrolle

Die zunehmende Durchdringung von hybriden Architekturen mit SAP BTP, S/4HANA Cloud und Drittplattformen verlangt nach konsistenter Zugriffskontrolle über Systemgrenzen hinweg. SAP Identity Authentication (IAS) übernimmt dabei eine zentrale Rolle. Die Integration mit Entra ID, Okta oder anderen Identity Providern erlaubt einheitliches Identity Federation über OpenID Connect. Unternehmen steuern Single Sign-On und Multifaktor-Authentifizierung über eine zentrale Oberfläche. Gleichzeitig sichern Cloud Connector und SAP IAS die Kommunikationsbrücke zwischen Cloud- und On-Premises-Systemen mit rollenbasierter Zugriffskontrolle, Firewall-Härtung und IP-Whitelist.

Im Zusammenspiel mit SAP Cloud ALM, den Audit Logs der Business Technology Platform und SIEM-Anbindung entsteht ein übergreifendes Sicherheitsmodell mit Echtzeitüberwachung für alle Zugriffe. Ergänzend bietet SAP Cloud Identity Access Governance vorkonfigurierte Richtlinien, kontinuierliche Risikoanalysen und Compliance-Dashboards für BTP, S/4HANA Cloud und SAP Analytics Cloud. Die Plattform bewertet Berechtigungsstrukturen automatisiert, erkennt SoD-Verstöße und steuert die Rollenzuordnung regelbasiert. Im Hintergrund laufen Remediation-Prozesse, die riskante Berechtigungen zurücknehmen oder Benutzerrechte dynamisch anpassen. Die Cloud-spezifischen Sicherheitskontrollen fügen sich nahtlos in bestehende GRC-Prozesse ein und erweitern sie um dynamische Risikoerkennung auf Applikationsebene.

Integrations- und Entwicklungsumgebungen

Viele Schwachstellen entstehen nicht im Betrieb, sondern schon in der Entwicklung. Offene Exits, fehlende Prüfmechanismen und unsauberer Code lassen sich nur vermeiden, wenn Sicherheitsanforderungen von Anfang an im Projekt verankert sind. CI/CD-Pipelines sollten statische Codeanalysen und Sicherheitsscans integrieren. Transporte lassen sich nur dann kontrollieren, wenn Prüfroutinen aktiv eingebunden sind.

Unsichere Funktionsaufrufe, fehlende Authority-Checks oder direkte Systemzugriffe bleiben sonst unentdeckt. Entwickler halten sich nicht automatisch an Vorgaben – die Einhaltung muss technisch überprüft und regelmäßig validiert werden. Erweiterungen im SAP Cloud Application Programming Model (CAP) oder ABAP RESTful Application Programming Model (RAP) ermöglichen eine saubere Trennung vom Anwendungskern, verhindern aber nur dann Seiteneffekte, wenn die Regeln beider Modelle konsequent umgesetzt werden. Zugriff erfolgt über definierte APIs, nicht über direkte Tabellen oder modifizierte Standardlogik. Nur so bleibt das System wartbar und update-fähig.

Governance, Prozesse und Toolchain

Sicherheit entsteht nicht durch einmalige Maßnahmen. Der Schutz bleibt nur stabil, wenn Verantwortlichkeiten klar verteilt sind und technische Prüfungen dauerhaft greifen. SAP Cloud ALM unterstützt die Steuerung sicherheitsrelevanter Aufgaben, übernimmt aber keine Überwachung von selbst. Audit Logs erfassen nur dann relevante Ereignisse, wenn sie vollständig aktiviert sind. Systemabweichungen lassen sich nur auswerten, wenn Metriken und Prüfparameter sauber definiert wurden. Clean-Core-Vorgaben und Zero-Trust-Konzepte liefern die Struktur, ersetzen aber keine Umsetzung. Wer Rollen regelmäßig prüft, technische Altlasten beseitigt und Konfigurationsänderungen kontrolliert, hält Angriffsflächen klein. SAP stellt dafür die Werkzeuge bereit. Die Umsetzung verlangt Struktur, Konsequenz und Erfahrung.

Die initiale Sicherheitskonfiguration entscheidet über die Robustheit eines S/4HANA-Systems. Wer auf SAP-Standards setzt, bekannte Schwachstellen schließt und technische Grundregeln beachtet, schafft eine verlässliche Architektur. Sicherheitsmaßnahmen greifen nur, wenn sie vom ersten Tag an durchgängig umgesetzt sind. Technische Baselines, parametrisierte Kontrollmechanismen und strukturierte Audit-Prozesse bilden das Fundament eines widerstandsfähigen SAP-Kerns. Alles andere bleibt Stückwerk.