Jenseits der Sicherheitsgrenzen: Wie Angreifer bei SAP- Cloud -Migrationen ihre Angriffe ausweiten (und wie man sie stoppen kann)

Die erweiterte Angriffsfläche hybrider SAP-Landschaften

SAP- cloud -Migrationen vergrößern die Angriffsfläche eines Unternehmens, da der Übergang von isolierten On-Premise-Systemen zu komplexeren, miteinander verbundenen Hybridumgebungen erfolgt. Die Migration zu RISE with SAP, SAP Business Technology Platform (BTP) und SaaS-Lösungen fördert zwar die geschäftliche Agilität, kann jedoch auch potenzielle Vektoren für laterale Bewegungen schaffen, die herkömmliche Perimeter-Abwehrmaßnahmen umgehen können. Angreifer müssen Unternehmensfirewalls nicht durchbrechen, wenn sie falsch konfigurierte Vertrauensbeziehungen, offengelegte Trace-Protokolle und gemeinsam genutzte Anmeldedaten für „ cloud “ ausnutzen können, um sich frei zwischen On-Premise- und „ cloud “-Instanzen zu bewegen.

Um diese Angriffe über die Sicherheitsgrenzen hinweg zu veranschaulichen, hielten CTO JP Perez-Etchegoyen, der leitende Forscher für offensive Sicherheit Pablo Artuso und der Senior Sales Engineer Hector Espinosa kürzlich einen Vortrag mit dem Titel „Beyond the Perimeter: Managing the Expanded Attack Surface of SAP- Cloud -Migrations“, die vierte Folge unserer Doku-Serie „Hacking & Defending SAP Applications“.

Das Wichtigste in Kürze

• Firewalls schützen SAP-Daten nicht mehr: Während das ausschließliche Verlassen auf Firewalls in der Vergangenheit bereits kritische Sicherheitslücken hinterließ, hat sich das Risiko heute erheblich verschärft. Hybride Architekturen schaffen Verbindungsbrücken (wie beispielsweise den SAP- Cloud -Connector und RFC-Ziele), die Angreifer nutzen, sobald sie sich einen ersten Zugang verschafft haben. 
• Unsichere Konfigurationen können sensible Daten offenlegen: Durch die Aktivierung einer ausführlichen Diagnoseprotokollierung (z. B. „ Cloud -Connector-Tunnel-Traffic-Trace“) können Base64-verschlüsselte Administrator-Anmeldedaten direkt in lesbare Protokolldateien geschrieben werden.
• Vertrauensbeziehungen können als Waffe eingesetzt werden: Durch die Kompromittierung eines lokalen S/4HANA- oder ERP-Systems können Angreifer etablierte SM59-Ziele und Kommunikationsvereinbarungen missbrauchen, um Hintertür-Konten in SAP BTP einzurichten.
• Unterkonten sind keine festen Sicherheitsgrenzen: Schwachstellen in Webanwendungen (z. B. Befehlsinjektion in BTP-Anwendungen) legen Umgebungsvariablen (VCAP_SERVICES) offen, wodurch Angreifer Dienstzugangsdaten im Klartext abgreifen und über Unterkonten hinweg zu internen Datenbanken vordringen können.

Die Realität der hybriden SAP-Umgebung: Warum herkömmliche Perimeter-Kontrollen versagen

Herkömmliche Perimeter-Sicherheit versagt in modernen SAP-Umgebungen, da hybride „ cloud “-Verbindungen externe Endpunkte zu internen Gateways machen.

In älteren Architekturen befanden sich ERP-Systeme (Enterprise Resource Planning) hinter den Firewalls des Unternehmens. Sicherheitsteams setzten auf Netzwerksegmentierung, um die zentrale Geschäftslogik zu schützen. Heute erstreckt sich ein SAP-Ökosystem im Unternehmen über mehrere Betriebsebenen:

Wenn Unternehmen S/4HANA-Transformationen durchführen oder auf „RISE with SAP“ umsteigen, schaffen sie enge Integrationsabläufe zwischen diesen Schichten. Angreifer zielen auf die Integrationsprotokolle, Authentifizierungstoken und Diagnosekonfigurationen ab, die diese Umgebungen miteinander verbinden, anstatt direkt die abgesicherten Anwendungskerne anzugreifen.

Untersuchungen von Onapsis Research Labs zeigen, dass Angreifer neu bekannt gewordene Sicherheitslücken bereits innerhalb von 72 Stunden ausnutzen. Um diese hybriden Umgebungen zu „ defend “, müssen Sicherheitsteams verstehen, wie Angreifer sich quer durch „ cloud “- und lokale Topologien bewegen. 

Angriffsvektor 1: „ Cloud “-Konnektor zur lokalen Umgebung  

Angreifer nutzen „ cloud “-Konnektoren als Sprungbrett zu lokalen Kernsystemen, indem sie Base64-verschlüsselte Anmeldedaten aus Diagnoseprotokollen extrahieren und gefährliche ICF-Dienste aufrufen.

Der SAP- Cloud -Connector fungiert als Reverse-Invocation-Proxy, der Anwendungen unter SAP BTP undcloud mit lokalen Systemen verbindet. Da er sichere ausgehende Tunnel aufbaut, muss keine Firewall-Ports für eingehenden Datenverkehr geöffnet werden. Falsche Konfigurationen im Cloud -Connector bergen jedoch erhebliche Risiken.

Die Exploit-Kette

1. Risiko durch Trace-Konfiguration: Ein Administrator aktiviert während der Fehlerbehebung die ausführliche Diagnose-Trace-Funktion (insbesondere den Tunnel-Traffic-Trace) im SAP- Cloud -Connector.
2. Extraktion von Anmeldedaten: Ein Benutzer mit einer Monitor- oder Support-Rolle mit geringen Berechtigungen greift auf Protokolldateien zu. In den Trace-Protokollen werden HTTP/REST-Nutzdaten aufgezeichnet, die an interne Systeme weitergeleitet werden, darunter Base64-kodierte HTTP-Basic-Authentifizierungs-Header.
3. Internal Gateway Targeting: Der Angreifer entschlüsselt die Base64-Zeichenkette, um die vom BTP-Ziel verwendeten Administrator-Anmeldedaten im Klartext offenzulegen.
4. Dienstmissbrauch: Der Angreifer stellt eine direkte Verbindung zum internen Anwendungsserver her und ermittelt aktivierte ICF-Dienste (Internet Communication Framework). Durch den Aufruf des SOAP-RFC-Dienstes führt der Angreifer Remote-Funktionsaufrufe durch, um einen neuen Dialogbenutzer mit den vollständigen Administratorberechtigungen „SAP_ALL“ anzulegen.

Dazu haben wir eine Demo vorbereitet. Im ersten Teil der Demo sehen Sie einen schwarzen Bildschirm. Das ist der Bildschirm des Administrators. Er ist für den Angriff eigentlich nicht relevant, dient aber dazu, Ihnen zu zeigen, wie man diese Protokollierung aktiviert. Hier sehen wir also diesen Teil der Konfiguration, in dem oben das Kontrollkästchen zu sehen ist. Sobald es aktiviert ist, erscheinen dort neue Dateien. Springen wir nun zur Anzeige des Angreifers, des „Monitor“-Benutzers. Wir sehen diese Dateien dort, und sie können gelesen werden. Der Monitor kann den Datenverkehr auslesen, der über die Anwendung zum HR-System fließt. Richtig? Hier sieht man also nicht nur das Passwort – eine Base64-kodierte Benutzerkennung –, sondern auch die URL. Für einen Angreifer ist es also ziemlich einfach, diese Base64-Kodierung zu entschlüsseln und die tatsächlichen Anmeldedaten zu erhalten, die im BTP-Zielsystem verwendet werden. Danach kann der Angreifer zwei verschiedene Befehle ausführen, um beispielsweise die Konnektivität zum lokal betriebenen HR-System zu überprüfen. Der erste führt zu einem Fehlercode 401, da keine Anmeldedaten angegeben wurden. Der zweite führt – zum Glück für den Angreifer – zu einem Erfolgscode 200, da die Anmeldedaten gültig waren. Nun kann der Angreifer verschiedene Maßnahmen ergreifen, um diese Anmeldedaten zu testen. Beispielsweise könnte er die SAP-GUI aufrufen und versuchen, sich im System anzumelden. Leider handelt es sich hierbei für den Angreifer nicht um einen Dialogbenutzer. Er kann jedoch andere ICF-Dienste nutzen. Zum Beispiel den sehr bekannten SOAP-RFC, der ziemlich gefährlich ist. Hier sehen wir, dass der Angreifer erkennt, dass dieser aktiviert ist. Mithilfe eines speziell gestalteten Skripts wird der Angreifer also versuchen, einen neuen Benutzer im System mit potenziell sehr hohen Berechtigungen anzulegen. In diesem Fall versuchen wir, „SAP_ALL“ zu verwenden. Ob dies funktioniert oder nicht, hängt von den Berechtigungen aller Anmeldedaten ab. Aber wie Sie hier sehen können, hat es funktioniert. Nun kann sich der Angreifer also mit dem neu erstellten Benutzer über das SAP-GUI anmelden. Und nur zum Zwecke dieser Demonstration würde es zeigen, dass die Anmeldedaten – Entschuldigung – die erhaltenen Berechtigungen tatsächlich „SAP_ALL“ waren.

Leitfaden zur Fehlerbehebung und Absicherung: Absicherung des SAP- Cloud -Konnektors

Um das Risiko einer Offenlegung von Anmeldedaten für den „ Cloud “-Connector zu minimieren, sollten Sie die folgenden Sicherheitsmaßnahmen umsetzen:

Voraussetzungen

• Administratorzugriff auf die SAP- Cloud -Connector-Verwaltungskonsole.
• Berechtigung zum Ändern von ICF-Serviceknoten in der Transaktion SICF auf den Ziel-ABAP-Systemen.

Schritt-für-Schritt-Anleitung

1. Diagnose-Trace deaktivieren: Öffnen Sie die „ Cloud “-Connector-Konsole, navigieren Sie zu „Tools“ > „Trace“ und stellen Sie sicher, dass das Kontrollkästchen „Tunnel Traffic Trace“ deaktiviert ist. Wenden Sie bei der Aktivierung des Trace ein striktes „Vier-Augen-Prinzip“ (doppelte Autorisierung) an.
2. Anwendung des Prinzips der geringstmöglichen Berechtigungen: Überprüfen Sie die BTP-Ziele im Cockpit von „ SAP BTP “. Stellen Sie sicher, dass die in den Zielen angegebenen Benutzer des Dienstkontos nur über minimale Berechtigungen verfügen, die streng auf die erforderlichen Remote-Funktionsmodule (RFCs) beschränkt sind.
3. Unsichere ICF-Dienste deaktivieren: Melden Sie sich am lokalen System an, führen Sie die Transaktion SICF aus, suchen Sie den Knoten /sap/bc/soap/rfc und deaktivieren Sie den Dienst, sofern er für den Geschäftsbetrieb nicht ausdrücklich erforderlich ist.
4. Konfigurieren Sie explizite Zugriffs Control slisten (ACLs): Beschränken Sie im „ Cloud “-Connector unter „Zugriffs Control “ die zulässigen Ressourcen auf bestimmte Funktionsmodule, anstatt uneingeschränkten Zugriff auf alle RFC-Endpunkte (/ oder ALL) zu gewähren.

Validierungsschritt

Führen Sie die Transaktion SM20 (Sicherheitsprotokoll) aus oder starten Sie einen automatisierten Scan über Onapsis Assess, um zu überprüfen, ob SOAP-RFC-Aufrufe aus externen IP-Bereichen blockiert und protokolliert werden.

Angriffsvektor 2: Pivoting von lokalen Systemen zuCloud durch Missbrauch von Vertrauensbeziehungen

Angreifer verschaffen sich von lokalen Systemen aus Zugang zu „ cloud “-Umgebungen, indem sie gespeicherte RFC-Ziele und Kommunikationsvereinbarungen mit übermäßigen Berechtigungen missbrauchen.

Unternehmen gehen häufig davon aus, dass ein Angreifer, der sich Zugriff auf ein lokales System verschafft hat, keine Zugriffsmöglichkeiten auf cloud -Umgebungen wie SAP BTP hat. Allerdings pflegen Anwendungen regelmäßig vorab festgelegte Vertrauensbeziehungen über SM59-RFC-Ziele und OAuth-Client-Konfigurationen.

Die Exploit-Kette

1. Erste Kompromittierung vor Ort: Ein Angreifer erlangt Ausführungsrechte auf einem internen S/4HANA- oder ERP-System (z. B. über Schwachstellen in benutzerdefiniertem Code oder gestohlene Anmeldedaten).
2. Zielprüfung: Der Angreifer führt die Transaktion SM59 aus, um aktive HTTP/RFC-Verbindungen zu identifizieren, die auf ABAP auf SAP BTP oder anderen cloud -Mandanten verweisen.
3. Missbrauch durch Konfigurationsabweichungen: Der mit „ cloud “ verbundene Kommunikationsbenutzer verfügt über übermäßig zugewiesene Kommunikationskonfigurationen, da Testartefakte in der Produktionsumgebung zurückblieben.
4. Cloud Backdoor-Provisioning: Der Angreifer setzt einen benutzerdefinierten ABAP-Bericht ein, der mithilfe des gespeicherten Ziel-Tokens REST-Aufrufe an die BTP-Verwaltungs-APIs ausführt. Das Skript legt einen neuen BTP-Kommunikationsbenutzer und einen Geschäftsbenutzer mit erweiterten Berechtigungen an und richtet so eine unbeaufsichtigte Hintertür im „ cloud “ ein.

Nun zur Demo: Ich habe gesagt, dass es sich um ein S/4-System handelt. Richtig? Es handelt sich also um ein System, das entweder auf einer privaten cloud oder vor Ort läuft. Wenn wir uns S/M 59 ansehen, können wir die bestehende Integration mit ABAP auf BTP erkennen. Wir haben es getestet. Es funktioniert. Es verweist auf einen bestimmten Mandanten von ABAP auf BTP, und dort gibt es einen speziellen Bericht, der ausgeführt werden kann und uns die Konnektivität sowie einen gewissen Informationsaustausch mit dem Remote-System zeigt. Doch dann hat dieser Angreifer das On-Premises-System kompromittiert – denn das ist ja das übergeordnete Ziel, nicht wahr? Es soll gezeigt werden, dass eine Kompromittierung in einem System Auswirkungen auf die anderen, die übrigen Systeme haben kann. In diesem Fall erstellt dieser Angreifer einen bestimmten Bericht, benutzerdefinierten Code, der für verschiedene Zwecke genutzt werden kann. Wir werden sehen, was damit gemacht wird. Das ist jedoch nur aufgrund der Berechtigungen des Angreifers möglich. Er hat erkannt, dass über diese Destination eine etablierte Vertrauensbeziehung besteht. Dieser ABAP-Code nutzt also im Grunde diese Destination. Der Angreifer listet zunächst die Kommunikationsbenutzer über diese konfigurierte Kommunikationsvereinbarung auf. Anschließend nutzt er dieselbe Kommunikationsvereinbarung, um einen weiteren Kommunikationsbenutzer anzulegen. Und zwar ebenfalls über denselben Code – es handelt sich um einen Code, der alles Mögliche ausführen könnte. In diesem Fall nutzt er jedoch die richtigen APIs, um eine Verbindung zu ABAP auf BTP herzustellen. Er legt zudem einen Geschäftsbenutzer an und erweitert dessen Berechtigungen. Durch diese Integration gelang es dem Angreifer also tatsächlich, einen Fuß in das ABAP-auf-BTP-System zu setzen und sowohl einen Kommunikationsbenutzer als auch einen Geschäftsbenutzer anzulegen. Und nun listen wir die Benutzer auf. Jetzt sehen wir diesen Backdoor-Benutzer, der angelegt wurde. Richtig? Dies dient lediglich zu Demonstrationszwecken. Je nach den Berechtigungen, je nach dem bereitgestellten Code sowie den Berechtigungen sowohl auf dem Ziel- als auch auf dem Quellsystem könnten andere Aktionen ausgeführt werden. Und wir können dort den angelegten Kommunikationsbenutzer sehen, was im Grunde die Kompromittierung des Zielsystems verdeutlicht.

Leitfaden zur Fehlerbehebung und Absicherung: Absicherung von Integrationszielen

Schützen Sie systemübergreifende Verbindungen vor dem Missbrauch von Anmeldedaten, indem Sie folgende Maßnahmen ergreifen:

Schritt-für-Schritt-Anleitung

1. Beseitigung statisch gespeicherter Passwörter: Ersetzen Sie fest codierte Benutzerpasswörter in SM59-Zielen durch „Principal Propagation“ unter Verwendung von gegenseitigen X.509-TLS-Zertifikaten oder OAuth 2.0-SAML-Bearer-Assertions.
2. Transport- und Codesicherheit umsetzen: Integrieren Sie den Onapsis „ Control “ in Ihren Transportmanagement-Workflow (SAP TMS, ChaRM, Rev-Trac), um den gesamten benutzerdefinierten ABAP-Code vor der Migration zu überprüfen und unbefugte API-Aufrufe an externe „ cloud “-Mandanten zu blockieren.
3. Cloud -Kommunikationsvereinbarungen prüfen: Melden Sie sich beim SAP BTP -Cockpit an, navigieren Sie zu „Kommunikationsmanagement“ > „Kommunikationsvereinbarungen“ und widerrufen Sie nicht genutzte Kommunikationsszenarien (z. B. APIs zur Benutzerverwaltung).

Validierungsschritt

Überprüfen Sie im „ SAP BTP “-Cockpit das Protokoll „Änderungsbelege“ unter „Benutzerverwaltung“, um sicherzustellen, dass in den letzten 30 Tagen keine nicht autorisierten Kommunikationsbenutzer oder Rollensammlungen angelegt wurden.

Angriffsvektor 3: „ Cloud “ bis hin zur Ausnutzung von Schwachstellen in lokalen Systemen sowie „ Cloud Foundry RCE“ bis hin zur Exfiltration interner HR-Daten

Angreifer nutzen Schwachstellen in Webanwendungen von BTP-Apps aus, um Anmeldedaten für den „Shared cloud “-Dienst abzugreifen und lokale HR-Daten über die Grenzen von Unterkonten hinweg zu exfiltrieren.

Ein weit verbreiteter Irrtum in der Architektur ist es, Unterkonten unter SAP BTP oder Foundry-Bereiche unter Cloud als isolierte Sicherheitsgrenzen zu betrachten. Wenn mehrere Anwendungen unter cloud die zugrunde liegende Konnektivität und Zielservices gemeinsam nutzen, kann eine Schwachstelle in einer Anwendung mit geringer Kritikalität hochwertige Unternehmensdatenbanken gefährden.

Die Exploit-Kette

1. Ausnutzung von Anwendungsschwachstellen: Ein externer Angreifer identifiziert eine Schwachstelle, die die Ausführung von Remote-Code (RCE) ermöglicht (z. B. eine Befehlsinjektionsschwachstelle in einer UI5- oder Node.js-Anwendung), die in der „ Cloud Foundry BTP“ ausgeführt wird.
2. Extraktion von Umgebungsvariablen: Durch die Ausführung von Betriebssystembefehlen innerhalb des Containers untersucht der Angreifer die Umgebungsvariable „VCAP_SERVICES“. In „ Cloud Foundry“ enthält „VCAP_SERVICES“ JSON-Objekte, in denen API-Schlüssel, Tokens und Passwörter im Klartext für gebundene Ziel- und Konnektivitätsdienste gespeichert sind.
3. Dienstübergreifende Erfassung von Anmeldedaten: Der gemeinsame Zieldienst enthält Anmeldedaten sowohl für die Anwendung mit geringem Risiko (supplier_prod) als auch für die hochwertigen Produktionssysteme (HR_prod).
4. Datenexfiltration: Mithilfe des erbeuteten HR_prod-Service-Tokens leitet der Angreifer Abfragen über den vom „ Cloud “-Connector eingerichteten internen Proxy weiter und extrahiert so Daten zu Mitarbeitervergütungen, Bankdaten und persönlichen Unterlagen direkt aus der internen Datenbank.

Schauen wir uns also ein Video an. Sehen wir uns an, wie das tatsächlich funktioniert. Zunächst sehen Sie den Bildschirm der Lieferantenportal-Anwendung. Das ist für das eigentliche Geschehen nicht besonders relevant. Wichtig ist vielmehr, dass Sie erkennen, dass es eine Sicherheitslücke gibt, die der Angreifer nun ausnutzen wird. Es handelt sich um eine Befehlsinjektion. Da dieser Bildschirm für diese Demo etwas zu klein ist, können wir, wie Sie gleich sehen werden, direkt die API nutzen. Wir wechseln nun zum zweiten Tab in Chrome, um die laufende App in größerer Darstellung zu sehen. In „ Cloud Foundry“ gibt es also diesen „VCAP_SERVICES“-Eintrag, der alle Anmeldedaten der eigentlichen Anwendungen enthält, die für die Verbindung zum Ziel und die Konnektivität benötigt werden. Wie Sie hier sehen können – direkt im JSON-Format –, sind all diese Informationen im Betriebssystem gespeichert. Mit diesen Informationen kann ein Angreifer, der Zugriff darauf hat, zunächst Tokens erstellen und diese Dienste – den Ziel- und den Verbindungsdienst – nutzen. Auf dem folgenden Bildschirm sehen Sie, wie der Angreifer diese Informationen nutzt und alle Ziele mit den Daten aus dem gemeinsamen Dienst, dem „Destination Shared Service“, ausliest. Hier sehen Sie „HR_prod“ und „supplier_prod“ mit Passwörtern im Klartext. Richtig? Das ist möglich. Das ist kein Fehler. Das ist standardmäßig so. Mit diesen Informationen – den „HR_prod“-Daten – können wir nun den Konnektivitätsdienst nutzen, richtig, mit diesen neuen Anmeldedaten, und versuchen, das System zu erreichen, das hinter dem „ Cloud “-Konnektor liegt. Der Dienst läuft, wie ich bereits sagte, über einen internen Proxy. Der einzige Weg, ihn zu erreichen, ist also über diesen internen Proxy mithilfe der Remote-Code-Ausführung. Richtig? Der Angreifer hat also zunächst versucht, zu prüfen, ob das System erreichbar ist. Und nun wird er versuchen, alle Informationen auszulesen, die im HR-System offengelegt sind – so, als würde er die andere Anwendung, nämlich die HR-Portal-Anwendung, nutzen. Hier ist eine anschaulichere Darstellung dieser offengelegten Informationen, bei der man beispielsweise das monatliche Einkommen jedes einzelnen Mitarbeiters des Unternehmens sowie die E-Mail-Adresse sehen kann

Leitfaden zur Fehlerbehebung und Absicherung: Isolierung von BTP-Diensten und -Anwendungen

Verhindern Sie mit den folgenden Abwehrmaßnahmen den Verlust von Anmeldedaten zwischen verschiedenen Anwendungen und das Pivoting über Unterkonten:

Schritt-für-Schritt-Anleitung

1. Sicherheitsgrenzen für Unterkonten durchsetzen: Trennen Sie hochwertige Geschäftsanwendungen (Personalwesen, Finanzen) in dedizierte BTP-Unterkonten mit unabhängigen Destination-Service-Instanzen auf. Verwenden Sie einzelne Destination-Service-Bindungen nicht gemeinsam für Anwendungen, die nicht miteinander in Zusammenhang stehen.
2. Scannen Sie benutzerdefinierten BTP-Code auf Sicherheitslücken: Integrieren Sie DevSecOps-Code-Tests in Ihre CI/CD-Pipelines (Azure DevOps, GitHub Actions, SAP Cloud ALM), um Befehlsinjektionen, SQL-Injektionen und fest codierte Geheimnisse vor der Bereitstellung zu erkennen.
3. Einschränkung der Ressourcenpfade des „ Cloud “-Konnektors: Konfigurieren Sie detaillierte Zugriffs Control slisten im „ Cloud “-Konnektor. Geben Sie genaue URL-Pfade an (z. B. /sap/bc/gui/sap/its/supplier_app/*), anstatt pauschalen Domänenzugriff (/) zu gewähren.

Validierungsschritt

Überprüfen Sie die Audit-Protokolle des „ Cloud “-Konnektors (ljs_trace.log), um sicherzustellen, dass Anfragen, die auf nicht autorisierte Backend-URL-Pfade abzielen, eine HTTP-403-„Forbidden“-Antwort erhalten.

Wie Onapsis eine mehrschichtige Verteidigung in hybriden SAP-Topologien gewährleistet

Die Onapsis- Platform -Lösung bietet einheitliche, automatisierte Transparenz, Schwachstellenmanagement, Bedrohungserkennung und Codesicherheit in lokalen Umgebungen sowie in RISE with SAP- und BTP-Landschaften.

Um komplexe Hybridumgebungen zu sichern, reicht es nicht mehr aus, nur punktuelle manuelle Überprüfungen durchzuführen. Die Onapsis- Platform -Lösung deckt Sicherheit und Compliance über den gesamten Lebenszyklus ab:

• Onapsis Assess: Bietet ein kontinuierliches Schwachstellenmanagement mit über 6.000 Prüfungen für ABAP, Java, HANA, BTP, den „ Cloud “-Konnektor, den Web Dispatcher und SuccessFactors. Überprüft automatisch, ob manuelle SAP-Sicherheitshinweise und Workarounds korrekt umgesetzt wurden.
• Onapsis Control: Führt statische, dynamische und interaktive Anwendungssicherheitstests für benutzerdefinierten ABAP-, Fiori-, SAPUI5-, HANA XSJS- und BTP Node.js-Code durch. Bietet eine automatisierte Korrekturfunktion namens „One-Click Fix“ direkt in der IDE, um den Code vor der Bereitstellung zu bereinigen.
• Onapsis Defend: Funktioniert als Echtzeit-Anwendungs-Intrusion-Detection-System (IDS) mit über 2.500 speziellen SAP-Regeln zur Erkennung von Bedrohungen und über 574 Exploit-Signaturen. Bietet Zero-Day-Schutzregeln vor der Veröffentlichung von Patches etwa 120 Tage vor der Veröffentlichung öffentlicher SAP-Sicherheitshinweise.
• Onapsis Research Labs: Das führende „ threat research “-Team, dem die Entdeckung von über 1.000 Zero-Day-Schwachstellen in geschäftskritischen Anwendungen zugeschrieben wird und das als direkte Informationsquelle ( threat intelligence ) für die US-Behörde CISA, das deutsche BSI und die SAP-Entwickler fungiert. Laut den offiziellen Danksagungen an SAP-Sicherheitsforscher sind die Forscher von Onapsis bei der verantwortungsvollen Offenlegung von Sicherheitslücken branchenweit führend.