Der gefährlichste Satz beim Cloud-Umstieg: „SAP kümmert sich“

Ab in die SAP-Cloud und bequem zurücklehnen? Von wegen. Wer mit RISE with SAP in die Private Cloud geht, gibt Verantwortung ab – aber keineswegs die komplette. Zwischen der Infrastruktur-Security des Anbieters und den Konfigurations-, Berechtigungs- und Datenschutzpflichten der Kunden klafft in der Praxis oft eine gefährliche Wissenslücke. Wo genau die Grenze im Shared-Responsibility-Modell verläuft, welche Stolperfallen IT-Verantwortliche regelmäßig übersehen und warum „Cloud“ nicht gleichbedeutend mit „Sorglos-Paket“ ist, klärt das Kurzinterview mit SAP-Expertin Jessica Wolf.

Jessica Wolf ist Senior Consultant bei cbs Corporate Business Solutions und seit mehr als acht Jahren in der SAP-Welt tätig. Nach ihrem Einstieg in SAP Basis spezialisierte sie sich auf SAP Security. Seit über zweieinhalb Jahren ist sie stellvertretende Sprecherin des DSAG-Arbeitskreises Security & Vulnerability Management.

Viele Unternehmen verbinden „Cloud“ unbewusst mit „Der Anbieter kümmert sich um alles“. Wo genau verläuft beim Shared-Responsibility-Modell die Grenze zwischen SAP- und Kundenverantwortung – und wo liegen die häufigsten Missverständnisse?

Die zentrale Frage ist zunächst, was sich Unternehmen vom Wechsel in die Private Cloud eigentlich erhoffen. Geht es vor allem darum, den technischen Betrieb zu entlasten? Oder besteht die Erwartung, dass Security damit weitgehend „mit erledigt“ ist? Genau an dieser Stelle gehen Erwartungen und tatsächliche Verantwortlichkeiten häufig auseinander.

Denn Shared Responsibility bedeutet bereits im Namen: Die Verantwortung wird geteilt, nicht vollständig abgegeben. SAP übernimmt – abhängig vom konkreten Vertrag und den gebuchten Services – wesentliche Aufgaben für Infrastruktur, Plattform und technische Betriebsleistungen. Umso wichtiger ist es, von Beginn an klar festzuhalten, wer welche Aufgaben verantwortet und welche Themen beim Kunden verbleiben.

Dabei sollte ein Unternehmen nicht einfach davon ausgehen, dass ein SAP-System automatisch „sicher“ ist, nur weil es in der Private Cloud betrieben wird. Die entscheidenden Fragen sind: Was bedeutet Sicherheit für das eigene Unternehmen? An welchen Referenzmodellen, internen Vorgaben oder Mindestanforderungen orientieren wir uns? Und erfüllen Konfiguration, Berechtigungen, Schnittstellen und Betriebsprozesse diese Anforderungen tatsächlich? Das muss aktiv hinterfragt und überprüft werden.

Der Kunde bleibt insbesondere für die sichere Nutzung seiner Systeme, Daten und Geschäftsprozesse selbst verantwortlich. Dazu gehören unter anderem Berechtigungen, Konfiguration, Hardening, Schnittstellen, Applikations-Monitoring, Risiko- und Asset-Management sowie die Reaktion auf sicherheitsrelevante Ereignisse.

Vertiefen Sie Ihre SAP-Kompetenz mit Live-Online-Kursen für die ABAP-Entwicklung, S/4HANA-Administration, Security und Fachprozesse. Lernen Sie mit erfahrenen SAP-Praktiker*innen, stellen Sie Fragen im Live-Chat und schauen Sie sich die Aufzeichnung noch einmal in Ruhe an. Je nach Thema eignen sich unsere Angebote als vertiefende Schulung oder als kompaktes Training für konkrete Aufgaben im SAP-Alltag. Mitmachen können Sie bequem zu Hause oder im Büro.

Das vielleicht größte Missverständnis entsteht bereits beim Vertragsabschluss: Was genau wird eigentlich beauftragt – und was müsste aus Security-Sicht zusätzlich vereinbart werden? RISE-Verträge werden teilweise auf C-Level abgeschlossen, ohne die zuständigen Fachabteilungen, SAP-Verantwortlichen und Security-Teams frühzeitig ausreichend einzubeziehen. So können unbewusst Lücken entstehen: Leistungen werden vorausgesetzt, sind aber nicht enthalten; Verantwortlichkeiten werden bei SAP vermutet, bleiben aber beim Kunden; notwendige Security-Services werden erst erkannt, wenn es bereits zu spät oder zumindest deutlich aufwendiger ist.

Unternehmen sollten deshalb frühzeitig prüfen: Welche Security-Leistungen benötigen wir wirklich? Welche Lücken müssen wir selbst schließen? Und für welche Themen benötigen wir ergänzende Services von SAP oder anderen spezialisierten Anbietern? Entscheidend ist, diese Fragen nicht erst nach dem Go-live zu stellen.

Hinzu kommt ein allgemeines Reifeproblem: SAP-Security ist in vielen Unternehmen gegenüber der klassischen IT-Security noch deutlich weniger etabliert. Themen wie Security Information and Event Management (SIEM), Security Operations Center (SOC) und Incident Response sind in der allgemeinen IT-Security häufig Standard, in SAP-Umgebungen aber noch nicht konsequent angekommen. Angriffe auf SAP-Systeme sind keineswegs nur ein theoretisches Szenario. Sie existieren – und Unternehmen müssen ihre SAP-Systeme entsprechend schützen.

Die entscheidende Frage lautet daher nicht nur: Was übernimmt SAP? Sondern auch: Welche Risiken und Aufgaben bleiben bei uns, welche Sicherheitsanforderungen stellen wir selbst – und wie stellen wir sicher, dass wir diese auch beherrschen?

Welche konkreten Aufgaben – etwa bei Berechtigungskonzepten, Konfiguration oder Datenschutz – bleiben in der Private Cloud zwingend beim Kunden, und was passiert, wenn diese vernachlässigt werden?

Die Verantwortung des Kunden beschränkt sich nicht auf die Daten, die im SAP-System gespeichert sind. Er muss auch die Konfigurationen, Berechtigungen, Schnittstellen und Geschäftsprozesse kritisch betrachten und darf sich nicht einfach darauf verlassen, dass der Betrieb in der Private Cloud automatisch eine sichere Applikation gewährleistet.

Ein zentraler Bereich ist das Berechtigungs- und Rollenkonzept. Rollen, privilegierte Zugriffe, Funktionstrennungen sowie Benutzer- und Notfallzugänge bleiben in der Verantwortung des Kunden. In vielen Unternehmen werden Berechtigungen zwar grundsätzlich bearbeitet – die Frage ist aber, ob sie risikoorientiert, aktuell und angemessen ausgestaltet sind.

Auch das Hardening und die Sicherheitskonfiguration müssen kontinuierlich betrachtet werden. Meine klare Empfehlung ist, ein statisches Security-Monitoring über die relevanten Konfigurationen zu legen und diese regelmäßig gegen eine definierte Security-Baseline zu prüfen. Das ist ein guter erster Schritt. Entscheidend ist anschließend, Abweichungen zu bewerten, zu priorisieren, zu beheben und nachzuverfolgen. Sicherheitsrelevante Einstellungen sollten nicht einfach blind als sicher vorausgesetzt werden.

Ein weiterer wichtiger Punkt ist die Überwachung der SAP-Anwendung. Je nach Leistungsumfang kann die Überwachung von Netzwerk und Infrastruktur bei SAP liegen. Was jedoch innerhalb der Applikation passiert, bleibt grundsätzlich eine wesentliche Kundenverantwortung, sofern dafür keine zusätzlichen Services vereinbart wurden. Der Kunde muss beispielsweise festlegen:

• Welche Aktivitäten privilegierter Benutzer sind kritisch?
• Welche Berechtigungs- oder Konfigurationsänderungen müssen alarmiert werden?
• Welche Transaktionen oder Geschäftsprozesse sind besonders schützenswert?
• Welche Schnittstellenaktivitäten sind auffällig?
• Wie soll bei einem konkreten Alarm reagiert werden?

Diese Applikationsalarme sollten außerdem mit den übrigen Meldungen des unternehmensweiten SOC korreliert werden. Ein zusätzlich eingekaufter Service kann Aufgaben übernehmen, ersetzt aber nicht die Verantwortung des Kunden für die fachliche Definition und Priorisierung seiner Use Cases sowie für die Reaktionswege.

Auch die Schnittstellenlandschaft wird häufig unterschätzt. Welcher Kunde kennt tatsächlich alle seine Schnittstellen, hat sie vollständig inventarisiert, beschrieben und kritisch eingestuft? Dabei müsste klar sein, welche Daten übertragen werden, welche Systeme beteiligt sind, wer verantwortlich ist und welche Schnittstellen besonders exponiert oder geschäftskritisch sind.

Schließlich ist auch ein Risiko- und Asset-Management notwendig – unabhängig vom Betriebsmodell. Die Systeme müssen geschützt werden – aber wie soll das funktionieren, wenn ein Unternehmen seine kritischen Assets, Daten, Prozesse, Schnittstellen und Risiken gar nicht kennt?

Wer diese Themen vernachlässigt, riskiert unter anderem unbemerkte Fehlkonfigurationen, übermäßige Berechtigungen, unzureichend geschützte Schnittstellen, verspätete Erkennung von Angriffen, Datenschutzverletzungen, Betriebsunterbrechungen und erhebliche Probleme bei Audits oder der Aufarbeitung eines Sicherheitsvorfalls.

Was raten Sie IT-Verantwortlichen, die gerade den Umstieg mit RISE with SAP planen oder bereits vollzogen haben, um ihre Sicherheitsverantwortung von Anfang an richtig wahrzunehmen?

Der erste Schritt sollte nicht die Auswahl eines einzelnen Tools sein, sondern eine realistische Ermittlung des Reifegrads der bestehenden SAP-Security. Unternehmen sollten zunächst feststellen, wo sie tatsächlich stehen und wo sich wesentliche Lücken auftun.

Danach sollten die kritischsten Lücken priorisiert bearbeitet werden. Ich würde insbesondere folgende Schritte empfehlen:

1. Verantwortlichkeiten klären: Die vertragliche Leistungsabgrenzung zwischen SAP, dem Kunden und gegebenenfalls weiteren Dienstleistern muss konkret und verständlich dokumentiert werden.
2. SAP-Security-Reifegrad bewerten: Dabei gilt es, unter anderem Berechtigungen, Konfiguration, Hardening, Schnittstellen, Monitoring, Incident Response, Risiko- und Asset-Management zu betrachten.
3. Kritische Assets und Prozesse identifizieren: Der Kunde muss wissen, welche Daten, Geschäftsprozesse, Systeme und Schnittstellen für sein Unternehmen besonders kritisch sind.
4. Berechtigungen und Konfiguration überprüfen: Rollen, privilegierte Zugriffe, Funktionstrennungen und sicherheitsrelevante Systemeinstellungen gilt es, zu überprüfen und regelmäßig zu rezertifizieren. Ein statisches Monitoring gegen eine Security-Baseline kann hierfür als erster konkreter Baustein dienen.
5. SAP-Security-Use-Cases definieren: Firmen sollten festlegen, welche Ereignisse im SAP-System erkannt werden müssen, welche davon kritisch sind und wie darauf reagiert wird.
6. SAP-Monitoring in das Unternehmens-SOC integrieren: Applikationsalarme sollten mit den übrigen Sicherheitsmeldungen des Unternehmens korreliert werden. Dafür braucht es klare Zuständigkeiten, Eskalationswege und einen belastbaren Incident-Response-Prozess.
7. Schnittstellen inventarisieren und bewerten: Jede relevante Schnittstelle sollte bekannt, beschrieben, einem Verantwortlichen zugeordnet und hinsichtlich ihrer Kritikalität und Risiken bewertet sein.
8. Kontinuierliche Verbesserung etablieren: Security ist kein einmaliges Projekt zum Go-live. Es ist wichtig, Konfigurationen, Berechtigungen, Risiken, Use Cases und Reaktionsprozesse regelmäßig zu überprüfen und weiterzuentwickeln.

Die wichtigste Frage, die sich IT-Verantwortliche stellen sollten: Wie wollen Sie Ihre SAP-Systeme schützen, wenn Sie nicht wissen, welche Daten, Prozesse, Schnittstellen und Konfigurationen für Ihr Unternehmen kritisch sind?

Ganz gleich, wo die Systeme laufen: Security darf kein optionales Projekt mehr sein. Sicherheit muss von Anfang an mitgedacht werden – in der Architektur, im Betrieb, in den Prozessen und in den Verantwortlichkeiten. Sie beginnt nicht irgendwann nach dem Go-live, sondern jetzt. Jede konkrete Maßnahme ist besser als abzuwarten.