Warum SAP BTP DevSecOps erfordert
Die Umsetzung einer SAP-Strategie für einen sicheren „Clean Core“ erfordert von Unternehmen, dass sie kundenspezifischen Code aus der Anwendungsschicht auslagern und die Entwicklung in die cloud verlagern. Die Verlagerung kundenspezifischer Entwicklungen auf Platform SAP Business Technology Platform BTP) verhindert Störungen der Kerngeschäftsprozesse während System-Upgrades, doch der Aufbau einer robusten SAP BTP erfordert eine aktive Governance, da dieses verteilte Side-by-Side-Erweiterungsmodell das Enterprise-Resource-Planning-System (ERP) unter anderem Webangriffen aus dem Internet, unsicheren Anwendungsprogrammierschnittstellen (APIs) und Schwachstellen bei Abhängigkeiten von Drittanbietern aussetzt.
Unternehmen müssen automatisierte Sicherheitsprüfungen für SAP-Anwendungen direkt in ihre CI/CD-Pipelines (Continuous Integration und Continuous Deployment) integrieren. Durch die Automatisierung der Pipelines können Sicherheitsteams Codefehler identifizieren, böswillige Transportanfragen abfangen und benutzerdefinierte Anwendungen absichern, bevor Softwareänderungen in die Produktionsumgebungen gelangen.
Der Wandel hin zur „Clean Core“-Architektur: Von lokalen Lösungen zur Cloud
Die Umstellung auf moderne cloud verändert die Angriffsfläche von Unternehmensanwendungen, da die Codeausführung von isolierten, lokal betriebenen ABAP-Servern auf verteilte, mit dem Internet verbundene cloud verlagert wird. Diese strukturelle Migration erweitert interne Anpassungsmethoden um externalisierte, API-gesteuerte Frameworks, die eine strenge, kontinuierliche Code-Governance erfordern, um die Systemintegrität zu gewährleisten.
Die „SAP Clean Core“-Strategie ist ein architektonisches Rahmenkonzept, das darauf abzielt, kundenspezifische Geschäftslogik strikt von der Standard-ERP-Kernsoftware zu entkoppeln. Diese Methodik beseitigt die bisherige Anhäufung von Anpassungen, bei denen direkte Änderungen an Standard-SAP-Tabellen und hinzugefügte, nicht freigegebene Funktionsbausteine Hindernisse für routinemäßige System-Upgrade-Zyklen darstellten. Durch die konsequente Umsetzung des dreistufigen SAP-Erweiterungsmodells erhalten Unternehmen einen stabilen digitalen Kern, der automatische Updates zulässt, ohne dass kundenspezifische Erweiterungen beeinträchtigt werden.
Um diese modernen Erweiterungen sicher zu entwickeln, nutzen Entwickler zwei unterschiedliche, cloud Ansätze:
- Erweiterbarkeit durch Entwickler auf Stack-Ebene: Entwickler schreiben benutzerdefinierte Erweiterungen mithilfe von ABAP Cloud dem ABAP RESTful Application Programming Model (RAP) direkt im S/4HANA-Speicherbereich. Dieses Modell beschränkt die Entwicklung auf veröffentlichte öffentliche SAP-APIs und erzwingt strenge Zugriffsfilter gemäß Control Data Control (DCL).
- Side-by-Side-Erweiterbarkeit: Anwendungsteams lagern wesentliche Änderungen vollständig auf die SAP Business Technology Platform BTP) aus. Mithilfe des SAP Cloud Programming (CAP)-Modells entwickeln Entwickler Satelliten-Mikroservices in Node.js, Java oder Python, die sich außerhalb der zentralen ERP-Ebene autonom skalieren lassen.
Während die „Side-by-Side“-Erweiterbarkeit die Flexibilität bei Upgrades gewährleistet, verschiebt diese verteilte cloud die primären Bedrohungsvektoren für Anwendungen. Herkömmliche ERP-Systeme stützten sich auf lokalisierte Perimeter und schützten benutzerdefinierte Objekte hinter internen Firewalls. Externalisierte BTP-Anwendungen setzen den digitalen Kern Standard-Web-Schwachstellen wie Cross-Site-Scripting (XSS), Server-Side Request Forgery (SSRF) und fehlerhafte Autorisierung auf Objektebene aus. Darüber hinaus ermöglicht eine Schwachstelle in einer Side-by-Side-Anwendung böswilligen Akteuren, den Reverse-Proxy Cloud SAP Cloud anzugreifen, wodurch ein direkter Weg für laterale Angriffe auf lokale S/4HANA-Systeme geschaffen wird.
Häufige Sicherheitslücken auf Code-Ebene in modernen SAP Cloud
Moderne SAP-spezifische Erweiterungen führen zu kritischen Fehlern auf Code-Ebene, wenn Entwicklungsteams die Liefertermine vorziehen, ohne sichere Programmierstandards durchzusetzen. Fehlende Zugriffskontrollen, nicht validierte dynamische Abfragen und ungeschützte Anwendungsrouter schaffen Angriffsvektoren, die leicht ausgenutzt werden können und die herkömmliche rollenbasierte Identitätsverwaltung vollständig untergraben.
Analyse von Onapsis Research Labs zeigt, dass Schwachstellen auf Anwendungsebene einen kritischen Angriffsmechanismus in der modernen Unternehmenslandschaft darstellen. Wenn Entwickler Legacy-Code migrieren oder neue cloud zügig entwickeln, entgehen regelmäßig mehrere kritische Schwachstellen der manuellen Codeüberprüfung:
1. Fehlende Berechtigungsprüfungen
Das Fehlen expliziter Anweisungen zur Berechtigungsprüfung ist der mit Abstand häufigste Anwendungsfehler bei kundenspezifischen Entwicklungen und macht fast ein Drittel aller veröffentlichten SAP-Sicherheitspatches aus. Im RAP-Modell müssen Entwickler sowohl globale als auch instanzbezogene Autorisierungshandler-Methoden explizit implementieren. Wenn ein Entwickler ein Szenario erstellt, ohne die FOR GLOBAL AUTHORIZATION-Methoden zu definieren, oder Core Data Services (CDS)-View-Entitäten ohne die Annotation @AccessControl.authorizationCheck: #CHECK konfiguriert, befindet sich die Anwendung standardmäßig in einem offenen Zustand. Diese Unterlassung ermöglicht es Benutzern mit geringen Berechtigungen, eine vertikale Berechtigungserweiterung zu erreichen, wodurch sie unbefugten Zugriff auf geschützte Finanzdaten oder personenbezogene Unternehmensdaten erhalten.
2. Dynamische Open-SQL-Injection
Obwohl Open SQL Datenbankabfragen standardmäßig nativ parametrisiert, führen fortgeschrittene dynamische Programmiertechniken erneut zu erheblichen Injektionsrisiken. Wenn benutzerdefinierte Anwendungen zur Laufzeit ganze WHERE-Klauseln oder Tabellenquellen über dynamische Tokens in Klammern ohne Sanitisierung erstellen, können Angreifer den SQL-Ausführungskontext manipulieren. Kritische Schwachstellen wie CVE-2026-27681 zeigen, wie authentifizierte Akteure unvalidierte dynamische Eingaben ausnutzen, um beliebige Datenbankänderungen durchzuführen und Backend-Systeme vollständig zu kompromittieren. Entwickler müssen Systemklassen wie CL_ABAP_DYN_PRG=>ESCAPE_QUOTES einsetzen, um injizierte Zeichen zu neutralisieren.
3. Offengelegte Approuter-Konfigurationen
Bei Side-by-Side-BTP-Bereitstellungen fungiert die Komponente @sap/approuter als zentrales Sicherheitsgateway, das JSON-Web-Tokens (JWT) analysiert und den Webdatenverkehr über den Dienst „Extended Services for User Account and Authentication“ (XSUAA) weiterleitet. Eine einzige Fehlkonfiguration in der Datei „xs-app.json“, wie beispielsweise die Einstellung der Eigenschaft „authenticationType“: „none“ für eine Backend-Route, umgeht die Token-Validierung vollständig. Dieser Fehler macht interne Geschäfts-APIs direkt im öffentlichen Internet zugänglich und ermöglicht es nicht authentifizierten Akteuren, Backend-Datensätze ohne Anmeldedaten herunterzuladen.
Eine einheitliche Governance für SAP BTP erreichen
Um eine nahtlose Erweiterbarkeit in hybriden SAP-Landschaften zu gewährleisten, müssen Unternehmen das Managementplatform mit kontinuierlichen Tests der Anwendungssicherheit vereinen. Durch die Kombination von Konfigurationsprüfungen in Echtzeit mit automatisierten Pipeline-Tests können Entwicklungsteams in Unternehmen cloud Erweiterungen schnell bereitstellen und gleichzeitig die Kerngeschäftsprozesse vor unkontrollierten Cyberrisiken schützen.
Schaffung von Transparenz Platform
Unternehmen, die das SAP-Clean-Core-Modell einführen, müssen eine kontinuierliche Transparenz sowohl über die zugrunde liegenden platform als auch über die in cloud ausgeführten kundenspezifischen Anwendungen gewährleisten. Die Umsetzung einer umfassenden SAP BTP für SAP BTP ermöglicht es Sicherheits- und Basis-Teams, cloud zu überwachen, Mandantenberechtigungen zu prüfen und unbefugte Änderungen in Kyma-, Cloud und SAP Event Mesh-Instanzen zu erkennen.
Automatisierung von Sicherheitskontrollen auf Code-Ebene
Um zu verhindern, dass nicht konformer Code, fest codierte Anmeldedaten und fehlende Zugriffskontrollen in Produktionsumgebungen gelangen, müssen Verantwortliche in der Anwendungsentwicklung automatisierte Sicherheitskontrollen direkt in die Change-Management-Workflows des Unternehmens integrieren. Der Einsatz automatisierter Anwendungssicherheitstests über Onapsis Control SAP BTP ermöglicht es Entwicklern, benutzerdefinierten Node.js-, Java- und Cloud innerhalb nativer integrierter Entwicklungsumgebungen (IDEs) und CI/CD-Pipelines zu scannen. Die Platform Code-Injection-Schwachstellen Platform , validiert API-Endpunktkonfigurationen und führt strukturelle Autorisierungsprüfungen durch, bevor cloud in Live-Systeme bereitgestellt werden.
Häufig gestellte Fragen (FAQs)
Wer ist für die Sicherheit benutzerdefinierter Anwendungen in SAP BTP verantwortlich?
Im Rahmen des SAP-Modells der geteilten Verantwortung trägt der Kunde die volle Verantwortung für die Sicherheit kundenspezifischer Anwendungen, für Schwachstellen auf Code-Ebene sowie für Mandantenkonfigurationen. Während SAP die zugrunde liegende cloud , die physischen Rechenzentren und platform absichert, müssen Unternehmen die Sicherheit kundenspezifischer cloud , API-Definitionen und Zugriffsberechtigungen proaktiv verwalten, um eine Kompromittierung des Systems zu verhindern. Durch die Implementierung kontinuierlicher Code-Scans können Entwicklungsteams ihren Teil der cloud effektiv absichern.
Inwiefern verändert die SAP BTP Erweiterbarkeit SAP BTP die Angriffsfläche der ERP-Anwendung?
Die Side-by-Side-Erweiterbarkeit verändert die Angriffsfläche der Anwendung, indem benutzerdefinierte Anwendungslogik von isolierten lokalen ABAP-Servern in verteilte, internetgestützte Web-Laufzeitumgebungen verlagert wird. Dieser strukturelle Wandel setzt Geschäftsabläufe den typischen cloud Bedrohungsvektoren wie Cross-Site-Scripting (XSS), Server-Side Request Forgery (SSRF) und fehlerhafter Autorisierung auf Objektebene aus. Da diese Anwendungen über den SAP Cloud wieder mit dem digitalen Kern verbunden sind, kann eine nicht behobene Schwachstelle cloud böswilligen Akteuren ermöglichen, sich lateral in zentrale ERP-Produktionsumgebungen vorzuarbeiten.
Warum können herkömmliche Tools zur Identitäts- und Zugriffsverwaltung Exploits in benutzerdefiniertem Code in SAP BTP nicht verhindern?
Herkömmliche Tools zur Identitäts- und Zugriffssteuerung versagen, da Identitätslösungen lediglich die Zuweisung von Benutzerrollen überprüfen, anstatt die strukturelle Integrität des Anwendungscodes zu analysieren. Wenn ein Entwickler innerhalb einer Unternehmenserweiterung obligatorische Zugriffskontrollen oder Routinen zur Parameterüberprüfung auslässt, führt der Anwendungscode Aufgaben in einem von Natur aus unsicheren Zustand aus. In Szenarien mit erweiterten Berechtigungen kann ein Angreifer diese Lücken auf Code-Ebene ausnutzen, um lokalisierte Rollenparameter zu umgehen und so eine horizontale Datenexfiltration oder unbefugten Administratorzugriff zu erlangen.
Wie können Unternehmen sichere Programmierpraktiken in ihre cloud integrieren, ohne den Projektzeitplan zu beeinträchtigen?
Unternehmen können sichere Programmierpraktiken integrieren, indem sie automatisierte Anwendungssicherheitstests direkt in die bestehenden integrierten Entwicklungsumgebungen (IDEs) der Entwickler und in automatisierte zentrale Code-Repositorys einbinden. Die statische Echtzeitanalyse liefert Softwareentwicklern sofortiges Inline-Feedback während des Schreibens des Codes, sodass Entwickler dynamische Schwachstellen und fehlende Zugriffskontrollen beheben können, bevor sie Softwareänderungen festschreiben. Die Kopplung control mit Continuous-Integration-Pipelines stellt sicher, dass nicht konforme Erweiterungen automatisch abgefangen werden, ohne dass langsamere manuelle Peer-Reviews erforderlich sind.
Über den Autor
