Technische Härtung, Identity Controls und Detektion für SOC-Betrieb Initiale Sicherheitskonfiguration von SAP S/4HANA

SAP S/4HANA bündelt Geschäftslogik, Datenhaltung und UI in einer Platt­form mit hoher Auswirkung auf finanzielle und operative Kernprozesse. Die Erst­kon­fi­gu­ra­ti­on legt fest, ob Rollen, Schnittstellen, Protokolle und Patch­prozesse Angriffe abwehren oder Angreifern reproduzierbare Einstiege liefern. In der Praxis entscheidet die Qualität dieser Startphase über Incident-Volumen, Auditbefunde und die Reaktionsfähigkeit des Betriebs.

Die initiale Si­cher­heits­kon­fi­gu­ra­ti­on von SAP „S/4HANA“ folgt einer klaren technischen Abfolge, die organisatorische Steuerung, Systeminventarisierung, präventive Schutz­maß­nah­men, laufende Überwachung, strukturierte Reaktion und Wie­der­an­lauf­me­cha­nis­men miteinander verzahnt. Zu Beginn steht die formale Festlegung von Verantwortlichkeiten, Freigabewegen und technischen Zuständigkeiten für Security, Basis, Entwicklung und Betrieb. Darauf aufbauend erfolgt eine vollständige Erfassung aller si­cher­heits­relevanten Systembestandteile, darunter Mandantenrollen, RFC-Verbindungen, HTTP-Endpunkte, aktivierte „OData“-Services, Custom-Code-Anteile, privilegierte Konten und angebundene Fremdsysteme.

Bildergalerie

Bildergalerie mit 8 Bildern

Einstieg in ein sicheres SAP-System mit NIST

Erst auf dieser Grundlage lassen sich technische Schutz­maß­nah­men wirksam umsetzen, zum Beispiel durch restriktive Rollenmodelle nach Least-Privilege, belastbare Funk­ti­ons­trennung, Härtung si­cher­heits­relevanter Parameter, Einschränkung von Schnittstellen sowie durch­gän­gige Verschlüsselung von Kommunikation und gespeicherten Daten. Parallel dazu wird eine kontinuierliche Überwachung etabliert, die si­cher­heits­relevante Ereignisse zentral protokolliert, Kon­fi­gu­ra­ti­ons­abweichungen erkennt und ungewöhnliche Nutzungsmuster sichtbar macht.

Für den Fall bestätigter Vorfälle müssen technische und organisatorische Reaktionsmechanismen definiert sein, die Analyse, Eindämmung, Dokumentation und Nachverfolgung ermöglichen. Ergänzend stellt die Startkon­fi­gu­ra­ti­on sicher, dass Wie­der­her­stel­lungs­prozesse für SAP-Systeme technisch getestet sind und klare Abläufe für Backup, Restore und Wiederanlauf existieren, um nach Si­cher­heits­ereignissen oder Systemausfällen den Geschäftsbetrieb kontrolliert fortzusetzen.

Ein belastbarer Start von S/4HANA setzt einen Rahmen, der sich an Govern, Identify, Protect, Detect, Respond und Recover ausrichtet. Diese Begriffe stammen aus dem NIST Cybersecurity Framework in und dienen als strukturierende Kategorien für Si­cher­heits­maßnahmen über den gesamten Lebenszyklus eines IT-Systems hinweg. Im SAP-Umfeld greifen unter anderem der DSAG-Leitfaden zur SAP Security und gängige SOC-Modelle diese Terminologie zur technischen Einordnung von Governance, Schutz, Überwachung, Reaktion und Wiederanlauf auf.

Govern definiert Verantwortlichkeiten und Change-Regeln für Security, Basis, Entwicklung, Betrieb und Fachbereiche. Identify erfasst Systemrollen, Mandanten, Interfaces, RFC-Destinationen, HTTP-Endpunkte, Custom-Code-Anteile und kritische Geschäftsobjekte, ergänzt um eine priorisierte Risikobewertung. Protect konkretisiert Härtung, IAM, Kryptografie und Kon­fi­gu­ra­ti­ons­standards. Detect verankert Telemetrie, Audit-Policies, zentrale Logausleitung und Baselines zur Abweichungserkennung. Respond implementiert Incident-Playbooks, Zuständigkeiten, Ticketflüsse und Eskalationswege. Recover bindet Backup, Restore, Wiederanlaufsequenzen und Kom­mu­ni­ka­ti­ons­prozesse in die Betriebsrealität ein.

Sicherheitslücke ermöglicht Systemkontrolle

Notfallpatch für kritische Zero-Day-Schwachstelle in SAP NetWeaver

Systemlandschaft, Mandantenmodell und Transportregeln

Die Trennung von Entwicklung, Qualitätssicherung und Produktion bildet die erste harte Linie. Produktion erhält restriktive Zugriffe, keine generellen Entwicklerrechte und keinen direkten Zugriff auf produktive Daten durch Entwicklungswerkzeuge. Mandantenrollen folgen einem Konzept mit eindeutigem Customizing- und Produktivmandanten. Transportwege laufen über definierte Korridore mit Freigaben, Protokollen und nachvollziehbaren Zuständigkeiten. Diese Regeln adressieren die zentrale Schwäche vieler Landschaften, in denen Notfallzugriffe, Ad-hoc-Transporte und direkte Produktivänderungen die Nachvollziehbarkeit zerstören und SoD-Kontrollen aushebeln. Für regulierte Umgebungen zählt zudem die Beweisbarkeit, dass keine Person allein kritische Änderungen plant, umsetzt und freigibt.

Security-Insider Podcast – Folge 106

Zertifiziert, qualifiziert, weitergebildet: Cybersicherheitskompetenz im Wandel

Bedrohungslage und Patchdruck mit konkretem Angriffsprofil

Die Erstkon­fi­gu­ra­ti­on muss Exploitpfade realistisch abbilden. Ein kritischer Fall zeigt das Risiko durch ABAP-Code-Injection mit Eskalation aus niedrigen Rechten bis zur vollständigen Kontrolle über S/4HANA. CVE-2025-42957 hat einen CVSS-Score von 9.9, ein Exploit taucht im Feld auf, und ungepatchte Systeme geraten damit in ein nachvollziehbares Zielprofil. Reverse Engineering eines Fixes erleichtert die Exploitentwicklung, da ABAP im System einsehbar bleibt. Angriffsfolgen umfassen direkte Manipulation in der SAP-Datenbank, das Anlegen von Konten mit SAP_ALL, das Abziehen von Passwort-Hashes und Änderungen an Geschäftsprozessen. Der Zusammenhang zwischen Patchlatenz und Angreiferfähigkeit wirkt hier unmittelbar. Das initiale Si­cher­heits­design muss deshalb ein Patchverfahren fest verdrahten, das Security Notes zeitnah durch Test, Freigabe und Einspielung bringt, ohne dass jedes Mal ein neues Verfahren diskutiert.

Identity, Au­then­ti­fi­zie­rung und Sitzungssteuerung

IAM beginnt mit einer konsistenten Quelle für Identitäten und starken Au­then­ti­fi­zie­rungs­faktoren. SSO reduziert Passwortwiederverwendung und erlaubt zentrale Sperren, verlangt aber Session-Parameter, Token-Laufzeiten und eine belastbare Abmeldung. MFA gehört in die Standardlinie für administrative Konten, Notfallzugriffe, Remote-Zugriffe und alle Pfade mit erhöhtem Risiko. In Cloud-Szenarien bindet sich die Au­then­ti­fi­zie­rung an SAP Cloud Identity Services mit IAS und IPS, ergänzt um SAML oder OIDC. Diese Protokolle erlauben eine zentrale Policy-Steuerung, die auch spätere Plattformänderungen übersteht.

Für Public-Cloud-Varianten fällt die Kontrolle über Teile der Autorisierung enger aus, da SAP Standardinhalte und Updatezyklen vorgibt. In Private Cloud bleibt mehr Spielraum, verlangt aber auch mehr Disziplin bei eigenem Baselining, bei Rollendesign und bei Change-Kontrolle. In allen Modellen gilt, dass eine starke Au­then­ti­fi­zie­rung allein keine Autorisierung ersetzt, da viele reale Vorfälle über kompromittierte Low-Priv-Accounts starten.

Bildergalerie

Bildergalerie mit 8 Bildern

Angriffsziel SAP

Strukturelle Schwächen erhöhen das Risiko für SAP-Landschaften

Autorisierung, SoD und technische Kontrollen im Berechtigungswesen

Die Erstkon­fi­gu­ra­ti­on muss ein Rollenmodell liefern, das Least Privilege technisch erzwingt. In S/4HANA verschiebt sich der Zugang in Richtung Fiori, Kataloge, Spaces und Pages, aber die Backend-Prüfung bleibt an Berechtigungsobjekte gekoppelt. Ein Rollenmodell trennt daher UI-Sichtbarkeit von Backend-Rechten und behandelt Frontend-Rollen nicht als Si­cher­heits­beweis. SoD gehört in die Baseline, nicht in spätere Optimierungsphasen. Kritische Trennungen betreffen Beschaffung, Zahlungsfreigaben, Stammdatenpflege, Buchungsvorgänge, Benutzerverwaltung, Transportfreigaben und Notfallzugriffe.

Ein Regelwerk muss Änderungen im Geschäftsprozess abbilden und muss daher eine regelmäßige Pflege erhalten. GRC-Mechanismen wie Risk Terminator unterstützen hier, da sie Rollenänderungen und Zuweisungen gegen definierte SoD-Regeln prüfen und Konflikte früh signalisieren. In Cloud-Kontexten übernimmt IAG Teile der Workflows für Anträge, Freigaben, Risikoprüfung und Rezertifizierung, mit vordefinierten Prozessvarianten. IAG bezeichnet „SAP Identity Access Governance“, einen cloudbasierten Dienst zur Steuerung von Identitäten und Berechtigungen, der Benutzeranträge, mehrstufige Genehmigungen, regelbasierte Risikobewertungen und turnusmäßige Zugriffsüberprüfungen zentral abbildet und damit klassische GRC-Funktionen für Cloud- und Hybrid-S/4HANA-Szenarien bereitstellt. Die Erstkon­fi­gu­ra­ti­on muss diese Workflows so aufsetzen, dass Manager, Rollenverantwortliche und Risikoverantwortliche getrennte Freigaben liefern, soweit die Organisation das personell abbildet.

Berechtigungsprüfungen und Toolgestützte Kontrolle in der Startphase

Toolgestützte Prüfungen verkürzen den Weg von Vermutung zu Befund. „CheckAud“ liefert hierfür ein regelwerksbasiertes Modell zur Prüfung kritischer Berechtigungsvergaben und SoD-Konflikte. Die Inhalte umfassen umfangreiche Abfragen, vordefinierte Funk­ti­ons­tren­nungs­ma­tri­zen, Score-Bewertungen nach Eintrittswahrscheinlichkeit und Schadenspotenzial sowie Herkunftsnachweise für kritische Rechte.

Zero-Day-Lücke in SAP NetWeaver

Von der Lücke zur Welle: Was CVE-2025-31324 über ERP-Exploits verrät

Für S/4HANA-Projekte ist die automatische Differenzierung zwischen „SAP ERP“ und S/4HANA und der Abgleich zur „Simplification List“ relevant, da Rollen, Transaktionen und Prozesse sich verschieben. Parameter-Audits über Instanzen und Abgleich gegen DSAG-Prüfleitfäden passen in die Startphase, da Baseline-Parameter später schwerer neu verhandelt werden. Der ParaMeter-Baustein adressiert Parameterdiskrepanzen und visualisiert Abweichungen über Scoring, was als frühe Härtungsmaßnahme in DEV und QAS beginnt und vor dem Go-live eine produktive Baseline erzeugt. Ein Exporter für ABAP-seitigen Datenexport unterstützt zusätzliche Analysen und erlaubt wiederkehrende Exporte über Batchläufe, was für kontinuierliche Kontrollprozesse relevant bleibt.

Fiori-Stack, OData und konkrete Absicherung der UI-Angriffsfläche

Fiori bringt eine servicebasierte Angriffsfläche, weil jede Anwendung über HTTP erreichbare OData-Services, aktivierte ICF-Knoten und Gateway-Endpoints mit dem Backend kommuniziert und damit zusätzliche, netzwerkseitig adressierbare Zugriffspunkte schafft, die unabhängig von der klassischen SAP-GUI-Autorisierung abgesichert, überwacht und begrenzt werden müssen.

Die Erstkon­fi­gu­ra­ti­on muss daher die Kette aus Launchpad, Katalogen, Target Mapping, OData-Services und Backend-Autorisierungen technisch richtig schließen. Kataloge steuern nicht nur Sichtbarkeit, sie bündeln auch Anwendungen, die sich über Suche und Kachelmechanik indirekt auffinden lassen. Das reduziert den Nutzen reiner UI-Ausblendungen, wenn dahinterliegende Autorisierungen zu breit bleiben. Spaces und Pages strukturieren die Darstellung, ersetzen aber keine Berechtigungsprüfung. OData-Services laufen als Brücke zwischen Frontend und Backend und benötigen restriktive Aktivierung. Nicht benötigte Services bleiben deaktiviert, produktive Aktivierung folgt einer expliziten Freigabe. Gateway- und ICM-Kon­fi­gu­ra­ti­onen erzwingen HTTPS, restriktive TLS-Policies und eine nachvollziehbare Zertifikatsverwaltung.

Ein Web Dispatcher im Perimeter und Proxy-Ketten mit Inhaltsfilterung gehören in das Betriebsmodell, wenn externe Zugriffe auf Launchpad oder APIs existieren. Der Betrieb muss zudem die Konsequenz von SSO für Notfallkonten lösen. Ein häufiger Fehler besteht darin, dass ein Firefighter-Login zwar technisch erfolgt, der Aufruf über Launchpad aber durch SSO wieder auf die persönliche Identität fällt, wodurch Protokolle, Reviewer-Prozesse und Nachweise nicht mehr passen. Diese Fälle benötigen eine Trennung der Pfade und eine technische Kontrolle, dass Launchpad-Aufrufe im Notfallkontext in der Notfallidentität laufen.

Bildergalerie

Bildergalerie mit 8 Bildern

Teil 1: Häufigste Sicherheitslücken und typische Angriffe

Cybersicherheit für SAP: Grundlagen & Best Practices

Schnittstellenhärtung, RFC-Kontrolle und Transportpfade

RFC und HTTP-basierte Integrationen benötigen dedizierte technische Benutzer mit minimalen Rechten, begrenzten Destinationen und nachvollziehbarer Protokollierung. Trust-Beziehungen ohne harte Au­then­ti­fi­zie­rung erhöhen das Risiko und gehören nicht in die Baseline. Jede Schnittstelle erhält ein Eigentümermodell, einen Zweck und definierte Kom­mu­ni­ka­ti­ons­part­ner. Batch-Jobs, Hintergrundbenutzer und technische Kom­mu­ni­ka­ti­ons­konten laufen durch Rezertifizierung, da diese Identitäten häufig außerhalb normaler Rollenreviews liegen. In heterogenen Landschaften mit vielen Schnittstellen steigt die Relevanz von Monitoring, da Angriffe nicht nur über Benutzeroberflächen laufen, sondern über Maschinenkommunikation, Jobketten und API-Aufrufe.

Protokollierung, Detektion, SIEM-Integration und Baselines

Detect muss in der Erstkon­fi­gu­ra­ti­on funktionieren, sonst fehlt im Vorfall die Zeitleiste. Audit-Policies erfassen Anmeldeereignisse, Rollen- und Benutzeränderungen, kritische Parameteränderungen, RFC- und HTTP-Zugriffe sowie si­cher­heits­relevante Transaktionspfade. Logausleitung in ein zentrales System erlaubt Korrelation mit Signalen aus AD, VPN, EDR und Netzwerk. False Positives verlieren in SAP-Kontext schnell an Akzeptanz, daher braucht die Startphase ein Baselining mit Change-Fenstern, Systemrollen und bekannten Batchmustern. „SecurityBridge“ passt als SAP-natives Add-on in diese Linie, da es Telemetrie, Kon­fi­gu­ra­ti­ons­prüfungen, Schwachstellen- und Patchinformationen sowie Codeanalysen im SAP-Kontext zusammenführt.

„HyperLogging“ verdichtet Ablaufkontexte für forensische Auswertung und unterstützt Nachweise, erfordert aber Ressourcenplanung für Retention und Auswertung. Die Plattform liefert Ereignisse mit SAP-Kontext an SIEM oder SOAR und bindet ITSM für Tickets, Fristen und Zuständigkeiten an. Diese Kopplung schließt die Lücke, in der SAP-Signale isoliert bleiben und im SOC keine Priorisierung erhalten. Als Alternative oder Ergänzung kommt ETD als SIEM-orientierte Komponente in Betracht, da sie SAP- und Nicht-SAP-Quellen korreliert und Anomalien in Echtzeit analysiert. Die Erstkon­fi­gu­ra­ti­on muss dabei festlegen, welche Quelle die führende Detektionsinstanz liefert und wie der Betrieb Alarme triagiert, eskaliert und dokumentiert.

Teil 2: Kernaspekte eines SAP-Cybersicherheitsprogramms

Cybersicherheit für SAP: Umsetzung in der Praxis

Schwachstellenmanagement, Code-Si­cher­heit und Clean-Core-Entscheidungen

Protect und Identify hängen stark an Custom-Code und an Change-Volumen. „Secure Coding“ für ABAP und „UI5“ gehört daher in die Startphase, zusammen mit statischer Analyse über ATC und CVA sowie ergänzenden Prüfungen für unsichere Muster. Injection-Risiken, fehlerhafte Berechtigungsprüfungen und Transportfehler zählen zu typischen Ursachen, die in S/4HANA durch Service- und UI-Schichten sichtbarer werden. „Clean Core“ reduziert langfristig die Menge eigener Anpassungen, kollidiert aber mit Projektzeitplänen und kurzfristigen Prozessanforderungen. Die Erstkon­fi­gu­ra­ti­on muss deshalb definieren, nach welchen Kriterien Standardinhalte Vorrang erhalten und wann eine Anpassung technisch und organisatorisch durchgeht. In Public Cloud verschärft sich dieser Punkt, da SAP quartalsweise Updates, Deprecation-Mechanismen und Abhängigkeiten vorgibt. Werkzeuge für Release-Impact-Analysen und das Management deprecierter Apps und Kataloge müssen deshalb früh in die Betriebsroutine, da Rollen, Kataloge und Schulungen sonst in jedem Updatezyklus unter Druck geraten.

Backup, Recovery und Betriebsmodelle mit klaren Verantwortlichkeiten

Recover setzt technische Wie­der­her­stel­lungs­pläne voraus, die SAP-Systeme als Teil einer Gesamtresilienz behandeln. Backup-Strategien, Restore-Prozeduren und Wiederanlaufsequenzen müssen in der Startphase dokumentiert sein, einschließlich Kommunikation und Zuständigkeiten. Cloud-Modelle liefern physische Si­cher­heit, Redundanzmechanismen, Datenisolation und externe Zertifizierungen, ersetzen aber keine interne Kontrolle über Identitäten, Rollen, Schnittstellen und Logging. Regionale Datenhaltung und vertraglich festgelegte Datenresidenz beeinflussen Compliance und Incident-Abwicklung, da Forensik und Nachweise auf konkrete Speicherorte und Verantwortlichkeiten treffen.

Teil 3: Shared Responsibility

Cybersicherheit für SAP: Tools & Verantwortlichkeiten

Bildergalerie

Bildergalerie mit 8 Bildern

(ID:50684650)