Thought Leadership
Wer heute mit IT-Sicherheitsverantwortlichen über SAP spricht, stößt oft auf ein erstaunliches Muster: Die eigene Cloud-Infrastruktur wird engmaschig überwacht, Endpoints werden gepatcht, Zugriffsrechte regelmäßig überprüft. Und SAP? Bleibt außen vor.
Nicht aus Nachlässigkeit, sondern aus einem tief verankerten Missverständnis: SAP gilt vielerorts als Blackbox, als isolierte Insel, für die ein eigenes Team zuständig ist, das schon wissen wird, was es tut. Diese Trennung birgt Gefahren, und sie wird mit der Migration in die Cloud noch problematischer.
Die Jenga-Angst vor dem eigenen Datenbestand
Ein Bild, das mir in Gesprächen mit Kunden immer wieder begegnet: das Datenmanagement als Jenga-Turm. Die Sorge, dass das Löschen oder Archivieren alter Daten einen Baustein entfernt, der irgendwo tief im System eine tragende Funktion hat, und plötzlich wackelt alles. Diese Angst ist nachvollziehbar, aber in den meisten Fällen unbegründet. Alte, längst nicht mehr benötigte Daten haben in der Regel keinen Einfluss auf den aktuellen Systembetrieb. Das Problem ist nicht der Turm. Das Problem ist, dass niemand genau weiß, welcher Baustein was trägt, weil niemand ihn systematisch geprüft hat. Genau diese fehlende Systematik ist der eigentliche Risikofaktor, nicht nur beim Datenmanagement, sondern bei der SAP-Sicherheit insgesamt.
Warum SAP zwischen den Stühlen sitzt
Die Zuständigkeit für SAP-Sicherheit fällt in vielen Organisationen durch das Raster. IT-Sicherheitsteams betrachten SAP als Spezialgebiet, das nicht in ihre Verantwortung fällt. SAP-Teams wiederum sehen sich primär als Betreiber und Prozessverantwortliche, nicht als Sicherheitsexperten. Beide Seiten haben recht, doch der häufige Effekt ist, dass niemand sich vollständig zuständig fühlt.
Hinzu kommt, dass die Komplexität von SAP-Projekten regelmäßig falsch eingeschätzt wird, ebenso die Annahme, Sicherheit ließe sich am Ende eines Projekts mit geringem Aufwand nachrüsten. Das ist ungefähr so realistisch wie der Versuch, ein Haus nachträglich mit einem Fundament zu versehen. Sicherheit ist kein letzter Schritt, sie ist eine Designentscheidung, die von Anfang an mitgedacht werden muss.
Warten auf die Systemprüfung ist keine Strategie
Viele Unternehmen verlassen sich in Sachen SAP-Sicherheit fast ausschließlich auf externe Audits. Das folgt einem vertrauten Rhythmus: Monatelang passiert wenig, dann rückt der Audit-Termin näher, und plötzlich wird ein externer Berater für ein Voraudit engagiert, der in wenigen Tagen finden soll, was über Monate liegen geblieben ist. Diese Hektik ist teuer, sie bindet Ressourcen genau dann, wenn sie ohnehin knapp sind, und sie führt selten zu nachhaltigen Verbesserungen, weil am Ende des Projekts nur das Nötigste repariert wird, um durch die Prüfung zu kommen. Wer Sicherheit nur über die dritte Verteidigungslinie, also externe Auditoren, absichert, hat faktisch keine Kontrolle über den eigenen Systemzustand zwischen zwei Prüfterminen. Ein Jahr ist eine lange Zeit in einer SAP-Landschaft.
Deshalb empfehle ich Unternehmen den Aufbau eines internen Kontrollsystems, orientiert am „Three Lines of Defense“-Modell. Die erste Linie sind die operativen Teams selbst, die im Tagesgeschäft auf Risiken achten. Die zweite Linie sind interne Kontroll- und Compliance-Funktionen, die regelmäßig und unabhängig von den operativen Teams prüfen. Die dritte Linie bleiben externe Auditoren, aber eben nicht mehr als einzige Instanz, sondern als Bestätigung dessen, was intern längst bekannt ist.
In der Praxis bedeutet das: proaktive, wiederkehrende Prüfschritte, im Idealfall quartalsweise, die kritische Berechtigungen, Notfallzugänge, Schnittstellenkonfigurationen und Custom-Code-Änderungen systematisch durchleuchten. Das klingt zunächst nach zusätzlichem Aufwand, kehrt sich aber schnell um: Ein Unternehmen, das quartalsweise zehn Stunden investiert, spart sich am Ende die wochenlange Feuerwehrübung vor dem Jahresaudit, und es reduziert das Risiko, dass zwischen den Prüfterminen etwas übersehen wird, das im Ernstfall richtig teuer werden kann.
Die Cloud verschiebt Verantwortung
Ein Trugschluss, der besonders häufig auftritt: Mit der Migration in die Cloud, insbesondere in SAP RISE, würden Sicherheitsfragen automatisch zur Aufgabe des Cloud-Anbieters. Das stimmt nur teilweise, und genau in dieser Teilwahrheit liegt die Gefahr. Cloud-Anbieter übernehmen oft weniger Aufgaben, als klassische Hosting-Dienstleister es früher taten. Wer aus einem klassischen Outsourcing-Modell kommt, überträgt dieses Vertrauen unbewusst auf das neue Cloud-Modell, ohne zu prüfen, ob die Zuständigkeiten tatsächlich deckungsgleich sind.
Beim Monitoring zeigt sich das besonders deutlich: Ist der Cloud-Anbieter zuständig, oder das Unternehmen selbst? Die Antwort steht meist im Kleingedruckten des Vertrags, wird aber selten von den Teams gelesen, die täglich mit dem System arbeiten. Da interne IT-Abteilungen ohnehin an ihrer Kapazitätsgrenze arbeiten, wird diese Verantwortung gerne komplett beim Cloud-Betreiber vermutet, oft fälschlicherweise. Die Konsequenz ist eine Lücke, die niemand bewusst geöffnet hat, aber jeder stillschweigend in Kauf nimmt, weil es unbequem wäre, sie zu schließen.
Sicherheit ist kein letzter Schritt, sie ist eine Designentscheidung, die von Anfang an mitgedacht werden muss.
Jonas Krüger, mindsquare AG
Ein Rat an jedes Unternehmen vor einer RISE-Migration: eine klare Verantwortlichkeitsmatrix erstellen, Zeile für Zeile, bevor der erste Server umzieht. Wer überwacht was, wer patcht was, wer reagiert im Incident-Fall, und in welcher Zeit. Diese Matrix sollte nicht im Vertrag verstauben, sondern regelmäßig gegen die tatsächliche Praxis geprüft werden.
S/4HANA: Neu heißt nicht automatisch sicher
Auch bei der Migration auf S/4HANA lohnt sich ein genauer Blick. Neue S/4HANA-Systeme kommen grundsätzlich mit „Security by Default“-Einstellungen, restriktiven Grundeinstellungen, die im Neuaufbau ein solides Sicherheitsniveau garantieren sollen. Das klingt beruhigend, greift bei Migrationsprojekten aber oft nicht: Zugunsten der Abwärtskompatibilität werden diese Standardeinstellungen häufig nicht aktiviert, weil bestehende Prozesse, Schnittstellen oder Berichte sonst nicht mehr funktionieren würden. Das Ergebnis sind unbeabsichtigte Sicherheitsrisiken, die nicht aus Nachlässigkeit entstehen, sondern aus der stillschweigenden Priorisierung von Kompatibilität vor Sicherheit, eine Entscheidung, die selten explizit getroffen, sondern meist einfach so hingenommen wird.
Was Unternehmen jetzt tun sollten
SAP-Sicherheit ist kein Nischenthema für Spezialisten, sondern ein integraler Bestandteil der Unternehmenssicherheit insgesamt. Konkret können Unternehmen die folgenden 4 Schritte unternehmen.
Erstens: SAP-Teams und IT-Sicherheit müssen zusammenarbeiten, statt nebeneinander her zu existieren. Dazu ist es notwendig, dass sie eine gemeinsame Sprache finden und sich regelmäßig austauschen, um falsche Annahmen über die Zuständigkeiten und Umsetzungsgrade der anderen Seite abzubauen.
Zweitens: Interne Kontrollmechanismen nach dem Three-Lines-of-Defense-Prinzip ersetzen das Prinzip Hoffnung vor dem nächsten Audit, mit proaktiven, quartalsweisen Prüfroutinen statt punktueller Hektik.
Drittens: Bei jeder Cloud-Migration gehört eine klare, schriftlich fixierte Verantwortlichkeitsmatrix auf den Tisch, bevor der erste Server umzieht. Das Shared Responsibility Model der SAP kann dabei ein erster Ausgangspunkt sein, der jedoch konkretisiert werden muss.
Und viertens: Sicherheitseinstellungen bei S/4HANA-Migrationen müssen gegen die Secure-by-Default Einstellungen abgeglichen werden und sollten vor dem Go Live durch einen SAP Security Check oder Penetration Test validiert werden.
Der Jenga-Turm mag stabiler sein, als viele befürchten. Aber nur, wer weiß, welcher Baustein was trägt, und wer proaktiv nachschaut, statt einmal im Jahr, kann diese Stabilität auch wirklich einschätzen, statt sie einfach zu erhoffen.
