SAP-Profilparameter: Sicherheitseinstellungen für On-Prem, Cloud & S/4HANA

SAP-Profilparameter sind das Rückgrat der Systemsicherheit. Ein falsch gesetzter Parameter kann eine Tür öffnen, die kein Firewall-Regelwerk schließt. Doch die Parameterrelevanz unterscheidet sich je nach Deployment-Modell erheblich: Was On-Premise unverzichtbar ist, existiert in der Cloud oft gar nicht – und S/4HANA bringt eigene Anforderungen mit. Dieser Leitfaden zeigt die wichtigsten Sicherheitsparameter im Vergleich aller drei Umgebungen.

1. Login & Authentifizierung

Die Login-Parameter sind in jeder SAP-Umgebung die erste Verteidigungslinie. Hier unterscheiden sich die Umgebungen jedoch deutlich:

On-Premise (ECC / S/4HANA On-Prem)

Auf dem klassischen ABAP-Stack kontrollieren Sie jeden Aspekt selbst:

• login/min_password_lng = 12 – Mindestlänge für Passwörter. SAP-Standard ist 8, wir empfehlen 12 für Produktivsysteme.
• login/fails_to_session_end = 3 – Nach 3 Fehlversuchen wird die Session beendet.
• login/fails_to_user_lock = 5 – Nach 5 Fehlversuchen wird der Benutzer gesperrt. Verhindert Brute-Force-Angriffe.
• login/password_expiration_time = 90 – Passwort läuft nach 90 Tagen ab. In Kombination mit Komplexe-Regeln ein guter Kompromiss.
• login/min_password_specials = 1 – Mindestens ein Sonderzeichen. Zusammen mit login/min_password_digits und login/min_password_uppercase ergibt sich eine solide Komplexität.
• login/no_automatic_user_sapstar = 1 – Verhindert das automatische Anlegen des SAP*-Benutzers mit Standardpasswort. Einer der am häufigsten übersehenen Parameter.

S/4HANA (On-Prem & Private Cloud)

S/4HANA nutzt dieselben ABAP-Parameter, bringt aber zusätzliche Aspekte:

• login/password_compliance_to_current_policy = 1 – Erzwingt, dass bestehende Passwörter bei nächster Anmeldung gegen die aktuelle Policy geprüft werden. Wichtig nach einer Migration.
• icf/set_HTTPonly_flag_on_cookies = 3 – Setzt das HttpOnly-Flag für alle Cookies. In S/4HANA mit Fiori-Oberfläche besonders relevant, da deutlich mehr HTTP-basierte Kommunikation stattfindet.
• login/accept_sso2_ticket = 0 – Deaktiviert SSO2-Tickets, wenn Sie stattdessen SAML oder X.509 nutzen. In S/4HANA mit Identity Authentication Service (IAS) die empfohlene Vorgehensweise.

Cloud (BTP / RISE with SAP)

In der Cloud-Welt verschiebt sich die Verantwortung:

• Passwort-Policies werden über den SAP Cloud Identity Services (IAS) konfiguriert, nicht über Profilparameter. Sie definieren Mindestlänge, Komplexität und Ablauf in der IAS-Administrationskonsole.
• Multi-Faktor-Authentifizierung (MFA) ist in der Cloud nativ verfügbar und sollte für alle administrativen Zugänge verpflichtend aktiviert werden.
• SAML 2.0 / OpenID Connect – Cloud-Systeme nutzen standardmäßig föderierte Authentifizierung. Die klassischen login/*-Parameter existieren hier nicht.

2. Kommunikation & Verschlüsselung

Unverschlüsselte Kommunikation ist 2026 keine Option mehr – egal in welcher Umgebung.

On-Premise

• snc/enable = 1 – Aktiviert Secure Network Communication für RFC- und Dialog-Verbindungen. Ohne SNC werden Passwörter im Klartext übertragen.
• snc/data_protection/max = 3 – Maximaler Schutzlevel (Privacy): Verschlüsselung + Integrität + Authentifizierung.
• ssl/ciphersuites – Definiert die erlaubten TLS-Cipher-Suites. Deaktivieren Sie veraltete Suites (TLS 1.0/1.1) konsequent.
• icm/HTTPS/verify_client = 1 – Erzwingt Client-Zertifikatsprüfung für HTTPS-Verbindungen zum ICM.
• SAPDBHOST / rdisp/msserv_internal – Trennen Sie Datenbank- und Message-Server-Kommunikation konsequent vom Benutzernetzwerk.

S/4HANA

• Alle On-Prem-Parameter gelten weiterhin.
• icm/HTTP/redirect_0 = PREFIX=/, FROM=*, FROMPROT=HTTP, TOPROT=HTTPS – Erzwingt HTTPS-Redirect für alle HTTP-Anfragen. Bei Fiori-Nutzung unverzichtbar.
• is/HTTP/show_detailed_errors = FALSE – Verhindert detaillierte Fehlermeldungen im Browser. Angreifer können sonst aus Stack-Traces Systemdetails ableiten.

Cloud (BTP)

• TLS 1.2+ ist standardmäßig erzwungen – Sie können es nicht deaktivieren (was gut ist).
• Mutual TLS (mTLS) kann für Service-to-Service-Kommunikation über das BTP Service Binding konfiguriert werden.
• Destinations in BTP sollten immer mit OAuth2 oder Client Certificates konfiguriert werden – niemals mit Basic Authentication und gespeicherten Passwörtern.

3. Gateway & RFC-Sicherheit

Der SAP Gateway ist ein bevorzugtes Angriffsziel. Die Absicherung unterscheidet sich nach Umgebung:

On-Premise

• gw/sec_info = /usr/sap/<SID>/SYS/profile/secinfo – Definiert, welche externen Programme RFC-Funktionen aufrufen dürfen. Eine leere oder fehlende Datei = offene Tür.
• gw/reg_info = /usr/sap/<SID>/SYS/profile/reginfo – Kontrolliert die Registrierung externer Server-Programme am Gateway.
• gw/reg_no_conn_info = 255 – Begrenzt Verbindungsinformationen. Reduziert die Angrifffläche bei Gateway-Enumeration.
• gw/acl_mode = 1 – Aktiviert den strikten ACL-Modus. Ohne diesen Parameter werden secinfo/reginfo nur als „Empfehlung“ behandelt.
• rfc/reject_expired_passwd = 1 – Lehnt RFC-Verbindungen mit abgelaufenen Passwörtern ab. Verhindert, dass alte Service-Accounts mit längst abgelaufenen Credentials noch funktionieren.

S/4HANA

• Alle On-Prem-Parameter gelten identisch.
• Zusätzlich: In S/4HANA mit eingebettetem Fiori wird der Gateway-Service (OData) intensiver genutzt. Prüfen Sie die ICF-Services unter /sap/opu/odata/ – nur benötigte Services sollten aktiv sein.

Cloud (BTP)

• Der klassische SAP Gateway existiert in BTP nicht. Stattdessen erfolgt die Kommunikation über den Cloud Connector als Reverse-Invoke-Proxy.
• Im Cloud Connector konfigurieren Sie explizit, welche On-Prem-Ressourcen (Host + Port + Pfad) erreichbar sind – ein deutlich granularerer Ansatz als die klassischen secinfo/reginfo-Dateien.
• Prinzip: Nur die minimal notwendigen Ressourcen freigeben. Jede URL und jeder RFC-Funktionsbaustein muss einzeln freigeschaltet werden.

4. Audit & Logging

Ohne Logging keine Nachvollziehbarkeit – und kein bestandenes Audit.

On-Premise & S/4HANA

• rsau/enable = 1 – Aktiviert das Security Audit Log (SAL). Unverständlicherweise in vielen Systemen noch deaktiviert.
• rsau/max_diskspace/local = 2000000 – 2 GB Speicher für Audit-Logs. Der Standardwert ist oft zu klein für Produktivsysteme.
• rsau/integrity = 1 – Integritätsschutz für Audit-Logs. Verhindert nachträgliche Manipulation der Logdateien.
• rec/client – Definiert die Mandanten, für die Tabellenprotokollierung aktiv ist. Für Produktivmandanten zwingend erforderlich.
• rslg/collect_daemon/host – Zentraler Syslog-Host. Leiten Sie Audit-Daten an ein SIEM-System weiter für zentrale Auswertung.

Cloud (BTP)

• Audit-Logging ist als SAP Audit Log Service verfügbar und muss pro Subaccount aktiviert werden.
• Konfiguration erfolgt über die BTP-Cockpit-API, nicht über Profilparameter.
• Log Retention: Standardmäßig 90 Tage. Für Compliance-Anforderungen prüfen Sie, ob eine Archivierung ins SAP Data Custodian oder ein externes SIEM notwendig ist.

5. Systemintegrität & Härtung

Diese Parameter schützen die Systemkern-Integrität:

On-Premise & S/4HANA

• auth/rfc_authority_check = 6 – Strengste Stufe der RFC-Berechtigungsprüfung. Verhindert, dass RFC-Funktionsbausteine ohne Autorisierungsprüfung aufgerufen werden.
• login/system_client – Definiert den Standard-Mandanten. Stellen Sie sicher, dass kein Produktiv-Mandant als Standard-Mandant konfiguriert ist, um versehentliche Anmeldungen zu vermeiden.
• rdisp/gui_auto_logout = 900 – Automatischer Logout nach 15 Minuten Inaktivität. Verhindert unbeaufsichtigte Sessions.
• login/disable_cpic = 1 – Deaktiviert CPIC-Anmeldungen, wenn nicht explizit benötigt.
• system/secure_communication = ON – Erzwingt sichere Kommunikation zwischen SAP-Systemen. In S/4HANA-Landschaften mit mehreren verbundenen Systemen unverzichtbar.

S/4HANA-spezifisch

• abap/heap_area_dia = 4000000000 – In S/4HANA mit HANA-Datenbank sind größere Memory-Bereiche nötig. Gleichzeitig schützen Limits vor Memory-basierten DoS-Angriffen.
• icm/HTTP/logging_0 – HTTP-Access-Logging für den ICM. Bei Fiori-Frontends kritisch für die Nachvollziehbarkeit von Benutzerzugriffen.
• is/HTTP/show_detailed_errors = FALSE – Kein Stack-Trace im Browser. Besonders wichtig bei öffentlich erreichbaren Fiori-Launchpads.

Cloud (BTP)

• Systemintegrität liegt primär in SAPs Verantwortung (Shared Responsibility Model).
• Ihre Verantwortung: Sichere Konfiguration der Custom Applications, Destinations, Service Keys und Role Collections.
• BTP Security Recommendations: SAP pflegt eine aktuelle Liste mit über 80 konkreten Empfehlungen für BTP-Sicherheit – prüfen Sie diese regelmäßig.

6. Vergleichsübersicht: Parameter nach Umgebung

7. Checkliste: Parameter-Review in 5 Schritten

Fazit

Profilparameter sind kein „Set and Forget“. In einer Welt, in der On-Prem, S/4HANA und Cloud koexistieren, braucht jede Umgebung ihre eigene Parameterstrategie – aber ein einheitliches Sicherheitsniveau. Die gute Nachricht: Die meisten Parameter-Änderungen erfordern kein Budget, sondern Wissen und einen strukturierten Review-Prozess.

Wenn Sie einen systematischen Parameter-Review für Ihre SAP-Landschaft benötigen – egal ob On-Prem, Cloud oder hybrid – sprechen Sie uns an.

Parameter-Review 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