Sicherheit für Daten, Zugriffe und Compliance S/4HANA Security: Das sollten Sie wissen!

Der Cloud-Betrieb von S/4HANA verlagert Sicherheitsfragen auf Identitäten, Berechtigungen, Schnittstellen und kontinuierliche Überwachung. Technische Defaults reichen nicht aus. Entscheidend sind belastbare Konzepte für Zugriffskontrolle, Integration, Monitoring und Compliance im laufenden Betrieb und bei Migrationen.

Der Cloud-Betrieb von S/4HANA verschiebt Sicherheitsentscheidungen auf Identitäten, Berechtigungen, Schnittstellen und Konfigurationszustände außerhalb des klassischen Transaktionsmodells. Ein tragfähiges Konzept verbindet Secure-by-Default-Defaults, technische Härtung, nachvollziehbare Rollenmodelle, zentrale Protokollierung und kontinuierliche Prüfungen über die gesamte Landschaft.

Architektur und Risikooberfläche im Cloud-Betrieb

S/4HANA in Cloud-Umgebungen verteilt Sicherheitskontrollen über mehrere Ebenen, die nicht alle im ABAP-Stack liegen. Administrativer Zugriff läuft über Web-Konsolen, Identity Services, Plattformrollen, APIs und Integrationsdienste, die mit dem ERP-Kern gekoppelt sind, ohne sich in klassischen Rollenmenüs vollständig abzubilden. Daraus folgt eine Risikooberfläche, die sich weniger an einzelnen Transaktionscodes orientiert, sondern an Identitätsquellen, Vertrauensstellungen, Token- und Zertifikatsflüssen, Zielsystemen von Destinations sowie an der Frage, welche Administrationsrollen im Identity- und Plattform-Layer Zugriff auf Konfiguration, Benutzer und Provisionierung erhalten.

Ein belastbares Betriebsmodell beginnt mit einer vollständigen Inventarisierung. Dazu zählen S/4HANA-Tenants, angebundene BTP-Subaccounts, Identity Authentication Service und Identity Directory, Identity Provisioning Service, Cloud Connector, Destination Service, Audit Log Service, Custom Domain Service sowie alle angebundenen Corporate IdPs. Jede Komponente erhält eine Verantwortlichkeit, ein Zielbild für Authentifizierung und Autorisierung und definierte Nachweiswege über Logs, Snapshots und Change-Historie.

Migration als Sicherheitsprojekt und nicht als Nebenaufgabe

Migrationen auf S/4HANA erzeugen technische Abkürzungen, die sich später nur mit hohem Betriebsrisiko korrigieren lassen. Projektteams öffnen häufig Kommunikationspfade, lockern RFC- und GUI-Schutz, vergeben Debug- und Entwicklungsrechte zu breit oder belassen Standardkonten und Standardkennwörter länger als geplant, sobald Schnittstellen, Datenübernahme und Abnahmeläufe unter Zeitdruck stehen. Ein tragfähiger Ansatz integriert Sicherheitsanforderungen direkt in die technischen Abnahmekriterien für den Produktivstart. Secure-by-Default-Defaults bleiben aktiv, Abweichungen landen nicht in Tickets, sondern in einem kontrollierten Abweichungsregister mit Ablaufdatum, Verantwortlichem, Rückführungsplan und Testkette.

Die Migrationsphase nutzt eine eigene Berechtigungsschicht für Projektkonten, die nach dem Go-Live ausläuft, damit temporäre Rechte nicht in den Regelbetrieb diffundieren. Parallel prüft ein festes Paket an Messpunkten die gefährlichen Stellen. Dazu zählen aktive Audit-Logs, gesicherte RFC-Kommunikation, TLS-Standards, deaktivierte Standardkonten, eingeschränkte Debugger-Rechte, überprüfte Schnittstellenkonten und ein nachvollziehbarer Rollenausbau für Fiori und Backend.

Secure-by-Default technisch ausnutzen und kontrolliert abgleichen

Secure-by-Default liefert eine Grundhärtung, die früh einen Mindestzustand erzeugt. Dazu zählen verschlüsselte Tokens für Login-Tickets, restriktivere Defaults gegen unautorisierte RFC-Aufrufe, starke Kennwortrichtlinien, TLS ab 1.2 und ein aktives Security Audit Log. Dieser Zustand dient als Referenz und nicht als Endpunkt. Im Betrieb zählt der Abgleich gegen diesen Referenzzustand, da Konfigurationsänderungen aus Betrieb, Projekten und Integrationen kontinuierlich abweichen. Ein technischer Abgleich nutzt Konfigurationssnapshots und Change-Historie und verknüpft sie mit konkreten Risiken.

Cloud-seitig übernimmt SAP Cloud ALM Configuration and Security Analysis diese Rolle, da tägliche Snapshots Konfigurationen aus Cloud-Services und angebundenen Systemen in eine zentrale Konfigurations- und Change-Datenbank übernehmen und den Verlauf sichtbar halten. Betriebsteams nutzen die Suche nach Schlüsselbegriffen und den Status „non-compliant“, exportieren Change-Listen und führen Abweichungen direkt auf den verantwortlichen Service und Store zurück. Für On-Prem-Übergangssysteme oder hybride Phasen ergänzt der Konfigurationsvergleich über Solution Manager oder Focused Run den Abgleich, damit Abweichungen zwischen Referenzsystem und Zielsystem sichtbar bleiben.

Identitäten und Administrationszugriffe als primärer Kontrollpunkt

Im Cloud-Betrieb steht die Identitätsschicht an erster Stelle. Identity Authentication Service fungiert als strategischer IdP für Cloud-Applikationen, unterstützt SAML und OpenID Connect und arbeitet häufig als Proxy vor einem Corporate IdP. Daraus folgt ein klares Betriebsziel. Administratorzugriffe auf IAS und verwandte Konsolen laufen mit MFA, und der Betrieb setzt auf passwortlose Verfahren, sobald Unternehmensrichtlinien dies tragen.

Self-Registration und Social Sign-In bleiben in Enterprise-Landschaften deaktiviert, sofern keine explizite Consumer-Anforderung existiert. Die Landschaft überprüft regelmäßig angebundene Corporate IdPs, da temporäre Testintegrationen und veraltete Trusts eine realistische Angriffsmöglichkeit öffnen. Cloud ALM spiegelt diese Empfehlungen technisch, da Konfigurationseinträge zu Social Sign-In, Self-Registration, Passwort-Policies und Admin-Konfigurationen als Stores erscheinen, zusammen mit Referenzen auf Empfehlungseinträge und einem Compliance-Status.

Administrative Autorisierung in Cloud Identity Services gewinnt zusätzliche Relevanz durch neue policybasierte Modelle. Dieses Modell ersetzt die klassische Vergabe über Admin-Flex im UI durch Policies, die feinere Rechte vergeben, die an Gruppen im Identity Directory gebunden sind. Die Verwaltung erfolgt über Gruppen- und Rollenprozesse, die sich über SCIM und Identity-Management integrieren lassen. Das reduziert das Risiko, dass einzelne Admin-Konten im Laufe der Zeit zu breit wachsen, und es erleichtert Rezertifizierungen, da Gruppenmitgliedschaften und Policy-Zuweisungen als überprüfbare Objekte vorliegen. Teams messen nicht nur, wie viele Admins existieren, sondern kontrollieren, welche Policy-Familien diese Admins erhalten und ob eine Trennung von Konfiguration, Benutzerverwaltung und Trust-Management besteht.

Bildergalerie

Bildergalerie mit 5 Bildern

Provisionierung und Secrets in Identity Provisioning Service

Identity Provisioning Service steht im Pfad der Benutzer- und Rollenbereitstellung. Diese Komponente benötigt eine sichere Authentifizierung zum Zielsystem, da eine kompromittierte Provisionierung direkten Zugriff auf Benutzerobjekte und Rollenbindungslogik erlaubt. Das Betriebsdesign setzt daher auf zertifikatsbasierte Authentifizierung statt statischer Kennwörter, und es nutzt Maskierungsfunktionen für Secrets in der UI, damit keine Klartextanzeige in Administrationsoberflächen auftaucht.

Konfigurationen, die TLS-Prüfungen umgehen, bleiben auf nichtproduktive Szenarien beschränkt, dazu zählt insbesondere eine globale Trust-All-Option. Zertifikatslaufzeiten gehören in den Betriebskalender, nicht in Incident-Listen. Automatische Zertifikatserneuerung in IPS reduziert Ausfallrisiken bei ablaufenden Zertifikaten, allerdings kollidiert Certificate Pinning auf Zielsystemseite mit automatischem Key-Rollover. Ein Betrieb, der Pinning einsetzt, plant Zertifikatwechsel als Change und verknüpft ihn mit Abnahmetests der Provisionierungspfade.

Frühwarnsystem für SAP

Onapsis-Integration macht Microsoft Sentinel zur SAP-Sicherheitszentrale

Berechtigungen in S/4HANA und die Umgehung transaktionsbasierter Checks

Ein Rollenmodell, das nur Transaktionsberechtigungen betrachtet, greift zu kurz. SAP prüft Transaktionsaufrufe über Autorisierungsobjekte wie S_TCODE, und diese Prüfungen hängen an AUTHORITY-CHECK-Mechanismen. Gleichzeitig existieren reale Umgehungspfade, sobald Programmausführung zu breit freigegeben ist. Der Zusammenhang zwischen Transaktion, Programm und Ausführung bildet die technische Basis für belastbare Rollenpflege.

Betriebsteams analysieren Transaktionen über SE93, ermitteln Programme und vergleichen diese Informationen mit Tabelleninhalten aus TSTC. Ergänzend liefert SU24 Default-Vorschläge für benötigte Autorisierungsobjekte und USOBT zeigt Beziehungen zwischen Transaktionen und Autorisierungsobjekten. Für Text- und Zuordnungsinformationen ergänzt TSTAVT die Sicht. Diese Analyse dient der Kontrolle, ob Rollen nur den Transaktionsaufruf erlauben oder auch die Programmausführung unbeabsichtigt öffnen.

Eine konkrete Risikoquelle liegt in der Ausführung von Programmen über SA38 oder SE38. Sobald ein Benutzer zwar keine Transaktionsberechtigung besitzt, aber Programmausführung erhält, kann er Programme hinter Transaktionen starten, sofern weitere Objekte nicht blockieren. Rollen müssen Transaktionsfreigaben und Programmausführung gemeinsam betrachten, und sie müssen SA38 und SE38 restriktiv behandeln, statt sie aus Bequemlichkeit breit zu vergeben.

Übergang vom Altsystem zur integrierten ERP-Plattform

S/4HANA-Migration: Diese Fakten sollten Sie kennen

Debugging als Privileg und nicht als Komfortfunktion

Debugging stellt in produktiven Systemen ein Hochrisikoprivileg dar, da Debugger-Aktionen Variableninhalte verändern, Sprünge im Kontrollfluss auslösen und Prüfergebnisse manipulieren können. Ein Missbrauchspfad besteht darin, Berechtigungsprüfungen im Debugger zu beeinflussen und so privilegierte Aktionen zu erzwingen, bis hin zur nachträglichen Vergabe von Vollrechten. Technische Steuerung benötigt daher eine feinere Differenzierung als die klassische Nutzung von S_DEVELOP.

Ab ABAP Release 7.57 steht S_DBG als differenzierteres Objekt zur Verfügung, das Softwarekomponente, Paketzuordnung und Aktivität differenziert, einschließlich einer Trennung zwischen Anzeige und Änderung von Variablen sowie der Freigabe für COMMIT WORK und ROLLBACK WORK. Betriebsteams behandeln Debugging in produktiven Systemen als Ausnahmefall mit begrenzter Personengruppe, zeitlichem Rahmen und Auditierbarkeit. Zusätzlich gilt eine harte Regel. Wenn S_DEVELOP und S_DBG parallel auf einen Benutzer treffen, addiert sich faktisch das höhere Privileg aus beiden Welten, daher benötigt jede Zuweisung eine Gegenprüfung, damit keine unbeabsichtigte Eskalation entsteht.

Kritische Autorisierungen, Profile und Rezertifizierung

Kritische Autorisierungen definieren Rechte, die aus Datenschutz- und Datensicherheitslogik heraus Risiken für Datenabfluss und Manipulation tragen. Diese Rechte dürfen nicht unkontrolliert in Rollen und Profilen verbleiben. Technische Auswertung nutzt SUIM zur Analyse von Benutzern mit kritischen Autorisierungen und zur Sicht auf Kombinationen, die ein erhöhtes Risiko darstellen. Die Auswertung arbeitet mit Varianten, die Objekte, Felder und Aktivitäten bündeln und eine Priorisierung nach Risikostufe abbilden.

In der Praxis zeigen Auswertungen oft, dass globale Profile mit Vollzugriff die Ursache für eine Vielzahl roter Befunde darstellen. Der Abbau beginnt nicht im Audit, sondern im Rollenbau. Rollen erhalten eine sprechende Beschreibung, die den fachlichen Zweck abbildet, und die Vergabe folgt einem Prozess, der genehmigende Stellen in die Lage versetzt, Rechteumfang und Risiko zu verstehen. Stellenwechsel führen nicht zum Aufsammeln von Rechten, sondern zum Entzug alter Zuweisungen und zur Neuvergabe entlang des aktuellen Aufgabenprofils.

Operativ reduzieren Teams Berechtigungsballast, indem sie doppelte und abgelaufene Rollenzuweisungen entfernen. PRGN_COMPRESS_TIMES bereinigt Dubletten und abgelaufene Zuweisungen, zuerst im Simulationslauf und danach produktiv mit expliziter Option zur Entfernung abgelaufener Einträge. Dieses Vorgehen reduziert nicht nur optischen Ballast, sondern senkt reale Privilegien, die aus historischen Zuweisungen stammen. Ergänzend liefert SUIM eine Übersicht über alle ausführbaren Transaktionen eines Benutzers, die sich exportieren lässt und Rezertifizierungen technisch stützt.

Operative Werkzeugkette für Analyse, Fehlerdiagnose und Rollenpflege

SU53 liefert bei fehlenden Berechtigungen die relevanten Objekte und Felder für die Diagnose. SU56 zeigt den aktuellen Pufferzustand der Autorisierungen. ST01 zeichnet Autorisierungschecks als Trace auf und unterstützt die Analyse, welche Objekte real geprüft werden. PFCG dient dem Rollenbau und der Pflege von Autorisierungsobjekten. SU01 und SU10 steuern Benutzerpflege, inklusive Massenvorgängen. SU21 unterstützt die Objektanalyse, inklusive Felder, Domänen und referenzierter Tabellen. SU24 liefert Default-Vorschläge und dient als Einstiegspunkt für die Prüfung, welche Objekte eine Transaktion in der Standardwelt erwartet.

Für Datenbrowser-Analysen liefern SE16N und Tabellen wie TOBJ, TSTC, USOBT und TSTAVT die Grundlage. Diese Werkzeugkette strukturiert die tägliche Arbeit an Berechtigungen, Rezertifizierung und forensischer Nachvollziehbarkeit.

Schnittstellen, Cloud Connector und Connectivity in BTP

Cloud-Betrieb setzt auf Integration, und Integration erzeugt Angriffsflächen. Destination Service verlangt TLS ab 1.2, Serverzertifikatsprüfung und einen Verzicht auf Trust-All-Optionen in produktiven Pfaden. Für Internetpfade nutzt die Architektur OAuth, für On-Prem-Pfade nutzt sie Principle Propagation, sofern das Zielbild dies vorsieht, damit zentrale Identitäten durchgängig wirken. Mutual TLS passt zu produktiven Szenarien, sofern Zertifikatsbetrieb, Erneuerung und Trust-Store-Steuerung organisatorisch abgebildet sind.

Cloud Connector bildet die Brücke zu On-Prem-Systemen und benötigt eine harte Konfiguration. Produktive Pfade laufen über HTTPS, URL-Ausnahmen bleiben restriktiv, LDAPS sichert LDAP-Kommunikation, SNC schützt Backend-Zugriffe. Der Betrieb reduziert die Zahl vertrauenswürdiger Root CAs, begrenzt Cipher Suites und ersetzt Default-Superadmins durch LDAP-basierte Benutzer, damit Nachvollziehbarkeit und Trennung von Aufgaben funktionieren. Audit-Logging bleibt aktiv, Traces laufen nur für konkrete Diagnosen und enden nach Abschluss.

Custom Domain Service reduziert Risiken, wenn Rollenvergabe restriktiv bleibt, TLS-Defaults erhalten bleiben und der Trust-Store nicht unnötig aufgebläht ist. Zertifikatsablaufwarnungen gehören in Betriebsüberwachung, nicht in Einmal-Checks. Für Audit Log Service zählt nicht nur Aktivierung, sondern auch Export und Archivierung. Logs fließen automatisiert in zentrale Audit- oder SIEM-Systeme, Retention-Einstellungen folgen Compliance-Anforderungen und eine definierte Archivstrategie verhindert, dass relevante Ereignisse durch kurze Aufbewahrung verloren gehen.

Monitoring und Konfigurationskontrolle im Dauerbetrieb

Cloud ALM Configuration and Security Analysis liefert tägliche Snapshots, speichert die Historie und erlaubt Abfragen nach Diensten, Stores und Schlüsselbegriffen. Teams nutzen diese Funktion als technische Kontrollfläche. Sie definieren ein Set an Suchmustern, das risikorelevante Bereiche abdeckt, darunter Admin-MFA-Status, Passwort-Policy-Zuweisung, Social Sign-In, Self-Registration, Trust-Konfigurationen, Certificate- und TLS-Parameter, sowie Hinweise auf delegierte Konfigurationen. Change-Listen dienen als täglicher Kontrollmechanismus, und Exporte fließen in Review-Routinen. Roadmap-Funktionen für Validierungsregeln, Alerts und Security-Dashboards erweitern diese Kontrolle, der Betrieb kann bereits jetzt mit API-Zugriffen und strukturierten Auswertungen arbeiten.

Auf der SAP-Systemseite ergänzt der Betrieb Monitoring über Audit Logs, Trace-Auswertungen und Prüfungen kritischer Mandantenparameter. Ergänzend liefert ein Security-Check-Ansatz eine mehrschichtige Sicht auf OS, Datenbank, Kernel, Virtualisierung, Web Dispatcher, Firewall, Cloud Connector und Router, allerdings ohne blindes Durchsetzen von Parametern. Parameteränderungen für verschlüsselte GUI- oder RFC-Verbindungen können Arbeitsfähigkeit brechen, wenn Endpunkte oder Partnerstrecken noch unverschlüsselt laufen. Ein kontrollierter Plan nutzt Testphasen, Abnahmeketten und klare Stichtage.

Patchmanagement und Security Notes als technische Pflicht

SAP veröffentlicht Security Notes in hoher Frequenz, und Security Patch Day etabliert einen festen Rhythmus. Angriffsakteure werten veröffentlichte Fixes aus und bauen Exploits zeitnah nach. Ein Betrieb, der Security Notes ohne Priorisierung behandelt, verliert Zeit an irrelevanten Paketen, ein Betrieb ohne Prozess verliert Zeit an Abstimmungschaos. Eine technische Umsetzung filtert Notes nach Relevanz für installierte Komponenten und konkrete Szenarien, nutzt zentrale Tools zur Auswahl relevanter Notes und koppelt den Rollout an definierte Testfälle entlang realer Endpunkte. Der Betrieb hält nicht nur SAP-Komponenten aktuell, sondern bezieht OS, Datenbank und Kernel in den Updatepfad ein.

Notfallzugriffe und privilegierte Tätigkeiten

Produktive Störungen erfordern gelegentlich weitreichende Rechte. Dauerhafte Vergabe solcher Rechte erhöht das Missbrauchsrisiko und verschlechtert Auditfähigkeit. Ein Firefighter-Ansatz löst das technisch, indem er privilegierte Zugriffe zeitlich begrenzt, einen Genehmigungsworkflow nutzt und alle Aktionen protokolliert, sodass nachträgliche Kontrolle reale Handlungen nachvollziehen kann. Der Ansatz funktioniert nicht nur für SAP, sondern auch für begleitende Systeme wie Datenbanken oder Host-Zugriffe, sofern das Identity-Management die Zuweisung übergreifend steuert.

(ID:50698477)