Zero Trust für SAP – keine Mission Impossible mehr

Zero Trust bei SAP bedeutet: Jede Person, jedes Frontend und jede Transaktion wird explizit verifiziert, kontextbewusst und streng auf die minimal notwendigen Berechtigungen in einer hochgradig vernetzten, geschäftskritischen Landschaft beschränkt. Angesichts der Realität komplexer, oft hybrider SAP-Umgebungen ist dies zunächst eine „Mission Impossible“. Wie also kann Zero Trust für SAP funktionieren?

Was bedeutet Zero Trust für SAP?

Herkömmliche Sicherheitsmodelle basierten auf dem Konzept eines „vertrauenswürdigen internen Netzwerks“, das durch Firewalls, VPNs und Netzwerksegmentierung geschützt wird, mit strengen Kontrollen an den Grenzen und relativ lockeren Kontrollen im Inneren. Genau das stellt Zero Trust in Frage, indem es implizites Vertrauen aufhebt und stattdessen eine kontinuierliche Überprüfung von Identität, Gerätestatus und Kontext verlangt, und zwar bei jeder Zugriffsanfrage. Für SAP bedeutet dies: Jeder und alles wird permanent authentifiziert, autorisiert, überwacht und durch das Least-Privilege-Prinzip eingeschränkt. Jede Aktion gilt als potenziell feindlich, bis ihre Sicherheit nachgewiesen ist. Und der Zugriff wird dann nur für die spezifische Ressource und den benötigten Zeitraum gewährt.

Die Zero-Trust-Architektur stützt sich dabei auf drei Kernprinzipien: explizite Überprüfung, Least Privilege und die Annahme, dass bereits ein Sicherheitsverstoß vorliegt. Jedes von ihnen ist mit bestimmten Voraussetzungen verbunden:

•    „Explizite Überprüfung“ erfordert eine starke Identitätssicherung, Geräte- und Netzwerkprüfungen sowie eine Verhaltensanalyse vor der Zugriffsautorisierung.

•    „Least Privilege“ bedeutet, dass Benutzer und Dienste nur die für ihre Aufgaben erforderlichen Berechtigungen erhalten, wodurch die laterale Bewegung eingeschränkt wird.

• Grundsätzlich von einer Sicherheitsverletzung auszugehen veranlasst Unternehmen dazu, Kontrollen unter der Annahme zu entwerfen, dass Angreifer möglicherweise bereits über gültige Anmeldedaten oder einen Zugangspunkt innerhalb der Umgebung verfügen. Das wiederum führt dazu, dass strenge Verkehrskontrollen, eine robuste Protokollierung und die Erkennung von Bedrohungen in Echtzeit als vorrangige Designziele und nicht als nachträgliche Überlegungen betrachtet werden.

Kontinuierliche Überprüfung anstelle eines statischen Systems 

Bislang diente das SAP-Berechtigungskonzept hauptsächlich der Einhaltung von Vorschriften, der Überwachung einmal eingeräumter Zugriffe und der Aufgabentrennung – ein statisches System und nicht wirklich wirksam für Cyberabwehr. Bei Zero Trust nun setzt die SAP-Umgebung auf eine kontinuierliche Überprüfung von Identitäten und Überwachung von SAP-Protokollen/-Ereignissen, um Anomalien, Betrugsmuster oder einen Missbrauch privilegierter Konten zu erkennen. Sie integriert dabei Identity and Access Management (IAM), Privileged Access Management (PAM) und Tools zur Bedrohungserkennung. Dies erfordert einen ganzheitlichen Ansatz bei der SAP-Sicherheit. Patch-Management, Bedrohungserkennung und Schwachstellenmanagement müssen zusammenwirken.

Wenn SAP selbst zu einer Zero-Trust-Domäne wird und nicht länger eine vertrauenswürdige Insel hinter den Perimeter-Sicherheitsmaßnahmen bleibt, fordert dies ein fundamentales Umdenken. Mehr als einfach eine Frage des Hinzufügens weiterer Authentifizierungsschritte stößt diese Anpassung auf strukturelle Herausforderungen in Bezug auf Transparenz, Patching und die Komplexität von Schwachstellen in großen, angepassten Landschaften.

SAP-Protokolle richtig und frühzeitig lesen

Wer SAP-Protokolle lediglich als Audit-Artefakte betrachtet, dem bleiben Missbrauch von Anmeldedaten, die Ausweitung von Berechtigungen oder eine Manipulation von Daten, die über ansonsten „legitime“ Transaktionen erfolgen, verborgen. Zumal Standard-SAP-Protokolle erst nachträglich erstellt werden und oft keine aussagekräftigen Kontextinformationen wie die Geräteidentität oder eindeutige Benutzermerkmale enthalten. Die herkömmliche Protokollanalyse reicht für moderne Bedrohungsszenarien also nicht aus. Das verzögert die Erkennung und macht SOC-Teams blind für SAP-spezifische Risiken. Derer gibt es viele, zum Beispiel:

•    Missbrauch legitimer SAP-Transaktionen, RFCs oder Hintergrundjobs, um Daten zu exfiltrieren oder zu manipulieren, wobei sich diese in normale Geschäftsaktivitäten einfügen.

•    Ausnutzung von Fehlkonfigurationen, schwacher Aufgabentrennung oder Konten mit übermäßigen Berechtigungen, um Betrug zu begehen oder zwischen Systemen zu wechseln.

•    Nutzung von Zero-Day- oder noch nicht gepatchten Schwachstellen, um sich einen ersten Zugriff zu verschaffen, und anschließende Nutzung von SAP-Berechtigungen und Backdoors in benutzerdefiniertem Code, um unentdeckt zu bleiben.

Rechtzeitige Patches und Zero-Day-Angriffe

Die meisten Unternehmen unterhalten heterogene SAP-Landschaften, die sich über On-Premises-, Private-Cloud- und SaaS-Komponenten erstrecken. In solchen Umgebungen ist es schwierig, einen genauen Überblick über anfällige Komponenten und deren Patch-Stand zu behalten. Nicht aufeinander abgestimmte Patches führen zu ungleichmäßigen Risikoflächen, die Angreifer sofort ausnutzen.

SAP-Patches rechtzeitig zu installieren ist in solchen Fällen bekanntermaßen schwierig, und zwar nicht nur aufgrund der geschäftskritischen Natur von SAP-Systemen, die häufige Ausfallzeiten und Änderungen schlichtweg nicht zulässt. Es sind auch die komplexen Transportlandschaften, in denen Patches und Sicherheitshinweise von Development Qualitätssicherung und Produktion getestet werden müssen, sowie die starken Abhängigkeiten zwischen Komponenten und Add-ons, die ein schnelles Patchen ohne gründliche Regressionstests riskant machen.

Da SAP-Sicherheitshinweise und Patches monatlich (am „Patch Tuesday“) veröffentlicht und einige Schwachstellen als kritisch oder „Hot News“ eingestuft werden, weisen selbst die effizientesten Patch-Management-Prozesse immer noch erhebliche Sicherheitslücken auf, die es Angreifern ermöglichen, in SAP-Systeme einzudringen.

Sicherheitslücken aufgrund komplexer Systemkonfigurationen

Die Sicherheitslage in SAP wird durch komplexe mehrschichtige Umgebungen zusätzlich erschwert:

•    Zahlreiche Produkte (ECC, S/4HANA, PI/PO, BTP) und Tausende von Konfigurationsparametern, die die Sicherheitslage beeinflussen.

•    Benutzerdefinierter Code, User-Exits, Erweiterungen und Schnittstellen, die über die Standard-SAP-Hinweise hinausgehende Sicherheitslücken auf Anwendungsebene verursachen.

•    Hybridbereitstellungen, die On-Premises-Systeme, Cloud-Dienste und Integrationen von Drittanbietern kombinieren, wobei jede Komponente unterschiedliche Sicherheitskontrollen und geteilte Verantwortlichkeiten aufweist.

Darüber hinaus können Fehlkonfigurationen bei Rollen, Profilen und RFC-Zielen auf subtile Weise zusammenwirken und so risikoreiche Berechtigungskombinationen schaffen. Aus der Perspektive eines einzelnen Systems mögen diese nicht offensichtlich sein, systemübergreifende Workflows können jedoch einzelne harmlose Berechtigungen in mächtige Angriffsketten verwandeln.

Patch-Management in die Bedrohungserkennung integrieren

Ein Zero-Trust-Ansatz muss diese Herausforderungen bewältigen bzw. wirksame Ausgleichskontrollen implementieren, wenn sich das Risiko schon nicht auf null oder nahezu null reduzieren lässt. Schlüsselelement zur Verringerung des Sicherheitsrisikos ist die Reduzierung der Angriffsfläche. In SAP-Umgebungen bedeutet dies, jedes SAP-System durch einen kontinuierlichen Schwachstellenmanagement-Prozess effektiv abzusichern. SAP-Teams benötigen dafür zunächst eine Sicherheits-Roadmap, die die Behebung von Schwachstellen nach Risiko und Aufwand priorisiert.

Zunächst sollte das Patch-Management in die Bedrohungserkennung integriert werden. Dies mindert das Risiko, welches durch die für das Patchen von SAP-Systemen benötigte Zeitfenster entsteht. Ergebnis ist ein „virtuelles Patchen“, bei dem die Regeln der Bedrohungserkennung schnell aktualisiert werden, um Ausnutzungsmuster zu überwachen, bis der eigentliche SAP-Patch angewendet wird. Erkennung und Reaktion fungieren somit als kompensierende Kontrollen, wenn sich das Patchen verzögert.

Permanente Superuser-Rollen durch kontrollierte Workflows ersetzen

Eine weitere Ausgleichsmaßnahme besteht darin, privilegierten Zugriff nicht mehr standardmäßig oder auf unbestimmte Zeit zu gewähren. Stattdessen wird ein Privileged Access Management (PAM)-Framework installiert, um zeitnahe Berechtigungserweiterung, starke Authentifizierung und umfassende Überwachung aller privilegierten Aktivitäten durchzusetzen. Für SAP bedeutet dies, dass permanente Superuser-Rollen durch kontrollierte Workflows ersetzt werden, bei denen Benutzer erweiterte Zugriffsrechte für bestimmte Aufgaben und Zeitfenster anfordern, stark authentifiziert werden und deren Sitzungen aufgezeichnet und im Nachhinein überprüft werden.

Wenn PAM mit Laufzeitanalysen und speziell auf SAP ausgerichteter Bedrohungserkennung integriert wird, lassen sich privilegierte Aktivitäten im Kontext bewerten: Ungewöhnliche Zeiten, Standorte oder Transaktionsketten können Warnmeldungen mit hoher Priorität generieren oder sogar eine automatische Beendigung der Sitzung auslösen.

Das Auslösen einer MFA-Abfrage, wenn Benutzer eine dieser Aktionen initiieren, unterbricht die Angriffskette für Angreifer, die auf gestohlene Passwörter oder Session-Hijacking setzen, während legitime Benutzer nur kurze, gezielte Aufforderungen erhalten. Dieser Ansatz steht im Einklang mit Branchenempfehlungen, die die Integration von MFA in Geschäftsabläufe und Verwaltungstools empfehlen, anstatt sie auf den Netzwerkzugang oder VPN-Anmeldungen zu beschränken.

Anstatt sich bei der Anmeldung am SAP-System ausschließlich auf MFA zu verlassen, wenden Zero-Trust-Konzepte die Step-up-Authentifizierung gezielt auf der Ebene kritischer SAP-Transaktionen, Konfigurationsänderungen oder Datenexporte an und bieten so hohe Sicherheit, ohne die Benutzer zu überfordern. Diese Lösungen können die von einem Benutzer in SAP versuchte Aktion überprüfen und Risikosignale von Identitätsanbietern, den Gerätestatus sowie Verhaltensanalysen auswerten. Anschließend entscheiden sie in Echtzeit, ob die Aktion zugelassen, blockiert oder eine verstärkte Authentifizierung wie eine Push-Benachrichtigung vom Authentifikator, ein Token oder eine biometrische Überprüfung erforderlich ist.

Durch die direkte Einbettung dieser Logik in die SAP-Benutzerabläufe schafft die verstärkte Authentifizierung ein fein abgestimmtes Vertrauensmodell, das besser darauf abgestimmt ist, wie Angreifer SAP tatsächlich über kompromittierte Anmeldedaten und den Missbrauch legitimer Transaktionen angreifen.

Fazit

Für Unternehmen, die den SAP-Zugang auf Auftragnehmer, Dienstleister und externe Supportpartner ausweiten, ist Zero Trust am besten als strategisches Rahmenkonzept zu betrachten. In Kombination mit SAP-spezifischen Tools und Vorgehensweisen vermag es die wichtigsten Herausforderungen im Bereich der SAP-Cybersicherheit erheblich zu mindern. Zu wichtigsten Schutzname gegen Risiken, die von der Lieferkette und Partnern ausgehen, wird hierbei die verstärkte Authentifizierung mit MFA. In Kombination mit Just-in-Time-PAM-Workflows kann externen Benutzern ein temporärer, streng begrenzter Zugriff gewährt werden, der stets durch starke Authentifizierung, detaillierte Richtlinien und vollständige Nachvollziehbarkeit geregelt wird. Dies entspricht dem Zero-Trust-Ansatz weitaus besser als die herkömmliche Praxis, externen Administratoren umfassende, dauerhafte Konten zu gewähren.

Im Laufe der Zeit schafft die Integration einer SAP-fähigen verstärkten Authentifizierung mit unternehmensweiten IAM-, PAM- und Sicherheitsanalysen ein Ökosystem, in dem Identität, Risikokontext und Anwendungsverhalten kontinuierlich miteinander verknüpft werden, wodurch Zero-Trust-Prinzipien tief in das Herz der kritischsten Geschäftssysteme des Unternehmens eingebettet werden.