Das SAP-Modell der geteilten Verantwortung: Wer ist für die Sicherheit von benutzerdefiniertem Anwendungscode in „ SAP BTP “ verantwortlich?

Während Unternehmen ihre ERP-Landschaften mithilfe von „RISE with SAP“ modernisieren und auf die „ cloud “ umsteigen, verbreitet sich eine gefährliche Annahme: dass SAP die gesamte Sicherheit automatisch für sie übernimmt. Entwicklungsteams migrieren benutzerdefinierten Code und Erweiterungen auf die SAP Business Technology Platform (BTP), nutzen Low-Code-Tools und KI-Copiloten und gehen davon aus, dass die integrierten Schutzmechanismen der „ platform“ den Rest übernehmen. Der Aufbau einer robusten Sicherheit für die Unternehmens SAP BTP erfordert jedoch eine aktive Governance, da die Umstellung auf eine sichere cloud platform benutzerdefinierte Anwendungen nicht automatisch sicher macht. Um Ihr Unternehmen zu schützen, müssen Sie genau verstehen, wo die Aufgabe von SAP endet und Ihre beginnt. 

Das Wichtigste in Kürze:

• Die „ Cloud “-Sicherheitsillusion: Die Verlagerung von benutzerdefiniertem Code auf SAP BTP führt nicht automatisch zu einer Erhöhung der Sicherheit. Das „SAP BTP “-Modell der geteilten Verantwortung sieht vor, dass SAP zwar die zugrunde liegende Infrastruktur absichert, Sie jedoch weiterhin zu 100 % für die Sicherheit Ihrer benutzerdefinierten Anwendungen, Ihres Codes und Ihrer Daten verantwortlich sind.
  
• Konfiguration vs. Absicherung: Der Einsatz moderner Tools wie SAP Build oder KI-Copiloten erfordert ein aktives Sicherheitsmanagement und nicht nur das Umschalten von Einstellungen in „ platform “. Da diese Umgebungen eine schnelle Anwendungserstellung ermöglichen, benötigen Sie speziell entwickelte Application Security Testing (AST)-Lösungen, um Schwachstellen im benutzerdefinierten Anwendungscode vor der Bereitstellung kontinuierlich zu scannen, zu erkennen und zu beheben.
  
• Die dritte Risikoeebene: Generative KI beschleunigt die Entwicklung, führt jedoch eine komplexe neue Variable ein. Die Grundlage für die Sicherheit von KI-AnwendungenSAP BTP liegt darin, KI-generierte Logik genauso zu behandeln wie von Menschen geschriebenen Code – das heißt, sowohl die generierte Logik selbst als auch die SAP-Datenzugriffsberechtigungen, mit denen sie interagiert, müssen gründlich validiert werden.
  
• Sicherung des „Clean Core“: Die Verlagerung von benutzerdefiniertem Code in „ SAP BTP “ im Rahmen einer „Clean Core“-Strategie ist nur dann sicher, wenn Sie einen „Shift-Left“-Ansatz verfolgen und die Sicherheit mit einbeziehen. Automatisierte, SAP-native Anwendungssicherheitstests (AST) sind unerlässlich, um Schwachstellen zu erkennen, bevor diese in Ihre „ cloud “-Umgebung bereitgestellt werden.

Die Daten hinter der Selbstzufriedenheit bei „ Cloud “

Aktuelle Branchentrends zeigen, dass Unternehmen zwar zunehmend auf „ cloud “-Erweiterungen setzen, ihre Sicherheitsmaßnahmen jedoch gefährlich hinterherhinken. Das Zeitfenster für Angriffe ist gnadenlos: Untersuchungen von Onapsis zeigen, dass neue, ungeschützte ERP-Anwendungen (Enterprise Resource Planning), die in der „ cloud “ bereitgestellt werden, von Angreifern in weniger als drei Stunden entdeckt und kompromittiert werden.

In unserem jüngsten Webinar, „Die verborgenen Risiken von KI-generiertem SAP-Custom-Code“, haben wir unsere Teilnehmer befragt und dabei eine enorme Wissenslücke hinsichtlich der Verantwortlichkeiten für die Sicherheit von „ cloud “ festgestellt. Als wir die Teilnehmer fragten, inwieweit sie mit dem SAP-Modell der geteilten Verantwortungbefragten, waren die Ergebnisse aufschlussreich. Während 26,7 % die Kernkonzepte verstanden, gab eine Mehrheit (53,3 %) zu, dass sie eine Auffrischung benötigten, und 13,3 % gingen fälschlicherweise davon aus, dass SAP mittlerweile die gesamte Sicherheit übernimmt.

Das Missverständnis, dass SAP sich automatisch „um die Sicherheit kümmert“, schafft genau die Schwachstelle, auf die Angreifer setzen. Im selben Webinar gaben 61,6 % der Teilnehmer an, dass sie häufig oder gelegentlich KI zur Code-Generierung einsetzen. Auf die Frage, ob sie das Gefühl hätten, dies sicher zu tun, sank das Vertrauen jedoch drastisch: Über 56 % antworteten entweder mit „Wahrscheinlich nicht“ oder „Weiß nicht“, und 37,5 % antworteten mit einem optimistischen „Ja, ich hoffe es.“

Die Konfiguration eines „ Control “ ist noch keine Absicherung: SAP Build Code und Joule

Die Kluft zwischen dem Versprechen sicherer „ cloud “-Plattformen und der Realität in SAP-Umgebungen tritt oft zutage, wenn Teams Tools für die schnelle Entwicklung einsetzen. „ SAP BTP “ bietet beeindruckende Beschleuniger wie „SAP Build Code“ für die professionelle Entwicklung und „SAP Joule“ für KI-gestützte Unterstützung.

Da diese Tools jedoch so benutzerfreundlich sind, verwechseln Entwickler häufig Konfiguration mit Sicherheit.

• SAP Build Code: Das Generieren oder Schreiben benutzerdefinierter Backend-Services ist mittlerweile unglaublich schnell geworden. Wenn der Code, der Daten aus Ihrem SAP-System abruft, jedoch keine ordnungsgemäßen Berechtigungsprüfungen oder Autorisierungsanmerkungen enthält, machen Sie Backend-ERP-Daten sofort für unbefugte Benutzer zugänglich. Die Anbindung des Services ist nicht gleichbedeutend mit dessen Absicherung. 
• SAP Joule: Wenn Entwickler Joule Studio nutzen, um benutzerdefinierte Skills, Aktionen und API-Integrationen in Unternehmenssysteme zu erstellen, müssen sie die Sicherheitskonfigurationen von SAP Joule Studio aktiv verwalten. Wenn ein Entwickler einen Joule-Skill so konfiguriert, dass er Mitarbeiterdaten oder Finanzdaten über eine REST-API abruft, führt die KI diese Abfrage blind aus. Die KI versteht von sich aus weder Ihre internen Datenschutzprotokolle noch die Vertrauenskonfigurationen der Identity Authentication Services (IAS) oder die SAP-Berechtigungslogik.

Die Konfiguration einer KI-Anweisung, eines Systemziels oder eines Workflows ist reine Routinearbeit. Die Sicherung dieser Verbindung erfordert eine gezielte, SAP-spezifische Validierung.

Die Haftungsfalle: Das Modell der geteilten Verantwortung im Rahmen des „ SAP BTP “ verstehen

Die Annahme, dass der Anbieter von „ cloud “ alles übernimmt, birgt für Entwicklungsteams ein erhebliches Haftungsrisiko. Das „SAP BTP Shared Responsibility Model“ legt klare, binäre Grenzen für Sicherheit und Compliance in der „ cloud “ fest. Einfach ausgedrückt: SAP sorgt für die Sicherheit der „ platform “, während der Kunde für die Sicherheit des Codes und der Daten verantwortlich ist.

• Verantwortung FÜR die „ Cloud “ (SAP): SAP ist zuständig für die physische Sicherheit des Rechenzentrums, die Hardware, die Netzwerkisolierung, die Installation von Betriebssystem-Patches sowie die standardmäßige SAP-Softwareinfrastruktur.
• Verantwortung auf Seiten des „ Cloud “ (Kunden): Der Kunde trägt die alleinige Verantwortung für die Datenverwaltung, Verschlüsselung, Rollengestaltung und Identitätsverwaltung. Entscheidend ist, dass diese Verantwortung auch den gesamten benutzerdefinierten Code (ABAP, UI5, Node.js), Low-Code-Anwendungen von SAP Build sowie BTP-Erweiterungen umfasst. 

Während das traditionelle Modell eine binäre Trennung zwischen SAP und dem Kunden vorsieht, führt die moderne Entwicklung eine komplexe dritte Ebene ein: generative KI. Wenn also in einer „ cloud “-Umgebung ein KI-Copilot eine Sicherheitslücke in Ihrer benutzerdefinierten BTP-Erweiterung verursacht oder ein falsch konfigurierter Joule-Skill sensible Daten preisgibt – wer trägt dann die Haftung?

Das liegt beim Kunden. Auch wenn der Fehler von einem KI-Anbieter oder einem Low-Code-Tool verursacht wurde, befindet sich diese kundenspezifische Anwendung vollständig in Ihrem Verantwortungsbereich. Da Sie die Haftung tragen, reicht es angesichts des enormen Umfangs und der Geschwindigkeit der modernen BTP-Entwicklung nicht mehr aus, sich auf manuelle, nach bestem Wissen und Gewissen durchgeführte Prüfungen durch Mitarbeiter zu verlassen.

Sicherheitsvorkehrungen für BTP und KI

Entwickler prüfen mittlerweile immer mehr Code in immer kürzerer Zeit und räumen dabei häufig der Funktionalität Vorrang vor der Sicherheit ein. Daher müssen Unternehmen strenge interne Leitlinien festlegen. Um die „ control “ wiederherzustellen und KI sicher zu nutzen, sollten Teams ein umfassendes Governance-Rahmenwerk integrieren, das speziell auf die Entwicklung von „ cloud “ zugeschnitten ist:

• Verantwortlichkeit: Setzen Sie strenge Richtlinien zum Schutz geistigen Eigentums durch und stellen Sie sicher, dass maßgeschneiderte BTP-Anwendungen und KI-Modelle comply den internen Prüfungen und gesetzlichen Rahmenbedingungen entsprechen.
  
• Robust und zuverlässig: „ Defend “ beugt KI-Halluzinationen vor, indem es überprüft, ob automatisch generierter Code tatsächlich auf vorhandene, autorisierte SAP-Module verweist, anstatt „Phantom“-Abhängigkeiten zu erfinden.
  
• Intern: Schützen Sie sensible personenbezogene Daten, indem Sie sicherstellen, dass alle Daten, die über SAP Build Code oder Joule-Skills übertragen werden, strikt Ihren festgelegten SAP-Berechtigungskonzepten und rollenbasierten Zugriffskontrollen entsprechen.
  
• Sicher und geschützt: Schützen Sie sich vor neuen Angriffsvektoren wie der Eingabe von Befehlen in Eingabeaufforderungen. Machen Sie automatisierte Sicherheitstests zu einem obligatorischen Schritt in der Bereitstellungspipeline, anstatt sie nur gelegentlich nachträglich durchzuführen.

Den Kern sauber halten mit einem „Shift-Left“-Ansatz für die statische Typanalyse (AST)

Ein zentrales strategisches Ziel für SAP-Kunden ist es heute, einen „Clean Core“ zu erreichen, indem kundenspezifische Logik aus dem Haupt-ERP ausgelagert und Erweiterungen auf der „ SAP BTP “ entwickelt werden. Eine „Clean Core“-Strategie ohne integrierte Sicherheit weist jedoch eine kritische Lücke auf: Sie können zwar Ihr ERP bereinigen, verlagern die Schwachstellen damit jedoch lediglich auf eine neue, weniger überwachte Oberfläche auf der BTP. 

Um echte SAP BTP Sicherheit von KI-Anwendungen, müssen Sie eine „Shift-Left“-Strategie verfolgen und die Sicherheitsüberprüfung ganz an den Anfang des Entwicklungszyklus verlagern. Generische Web-Scanner reichen dafür nicht aus. Unternehmen benötigen strenge, SAP-native Anwendungssicherheitstests (AST) wie Onapsis Control, die Ihren benutzerdefinierten Code bereits in den frühen Entwicklungsphasen schützen und den Code im Ruhezustand, während der Entwicklung und in Aktion scannen. Die Lösung bietet:

• In die Entwicklerumgebung integrierte Integration: Sicherheitshinweise werden direkt in der IDE (wie VS Code, SAP Business Application Studio oder ADT) angezeigt und dienen Ihren Entwicklern als interaktive Rechtschreibprüfung, noch bevor anfälliger Code überhaupt committet wird.
  
• Fundierte SAP-Kenntnisse: Umfassende Kenntnisse, die On-Premise-S/4HANA-, RISE-Umgebungen, BTP-Services und komplexe Berechtigungsobjekte abdecken.
  
• Transportblockierung: Automatisierte Kontrollmechanismen, die verhindern, dass fehlerhafter oder anfälliger Code überhaupt in Produktionsumgebungen gelangt.

Sind Sie bereit, Ihre Programmierpraktiken im Bereich „ cloud “ und KI zu optimieren? Nehmen Sie Kontakt mit uns auf!

Häufig gestellte Fragen (FAQ)

Wer ist für die Sicherheit benutzerdefinierter Anwendungen in SAP BTP verantwortlich?

Im Rahmen des Modells der geteilten Verantwortung von „SAP BTP “ trägt der Kunde die volle Verantwortung für die Sicherheit aller benutzerdefinierten Anwendungen, Erweiterungen und Codes, die auf SAP BTP bereitgestellt werden. Während SAP die zugrunde liegende Infrastruktur von cloud platform sowie die Standardsoftware schützt, liegt die Sicherung Ihres benutzerdefinierten Codes, Ihrer Daten, Rollen und Berechtigungsprüfungen vollständig in Ihrem Verantwortungsbereich.

Werden meine Anwendungen durch die Verwendung der nativen SAP-Tools wie SAP Build automatisch sicher?

Nein. SAP Build bietet zwar ein sicheres Grundgerüst, doch die von Ihnen entworfene Logik, die von Ihnen bereitgestellten APIs und die Daten, mit denen Sie eine Verbindung herstellen, müssen von Ihrem Team aktiv abgesichert werden. Die Konfiguration eines Low-Code-Tools ist nicht gleichbedeutend mit der Absicherung seiner Architektur und seiner Zugriffspunkte.

Wie gehen wir mit Risiken um, wenn wir KI-Copiloten wie SAP Joule integrieren?

Die Verwaltung der Sicherheitskonfigurationen von SAP Joule Studio liegt ausschließlich in der Verantwortung des Kunden. Sie müssen sicherstellen, dass alle benutzerdefinierten Skills, REST-APIs oder der der KI gewährte Datenzugriff den internen Autorisierungskonzepten und Datenschutzrichtlinien Ihres Unternehmens entsprechen, um eine unbefugte Offenlegung von Daten zu verhindern.

Warum ist eine „Clean Core“-Strategie grundsätzlich unvollständig, wenn ein Unternehmen nicht gleichzeitig einen „Shift-Left“-Sicherheitsansatz umsetzt?

Wenn Sie das ERP-Kernsystem säubern, aber unsicheren benutzerdefinierten Code und KI-generierte Erweiterungen ohne frühzeitige Sicherheitsprüfungen auf „ SAP BTP “ auslagern, verlagern Sie die Schwachstellen lediglich an einen neuen, möglicherweise weniger überwachten Ort. Um eine echte „ SAP BTP “-Sicherheit für KI-Anwendungen zu erreichen, ist ein „Shift-Left“-Ansatz erforderlich, bei dem automatisierte Prüfungen frühzeitig in den Entwicklungslebenszyklus integriert werden, um sicherzustellen, dass Ihre BTP-Erweiterungen genauso sicher sind wie Ihr Kernsystem. 

Warum ist die „SAP-Native Coverage“ bei der Implementierung automatisierter Sicherheitstests für BTP-Anwendungen so wichtig?

Allgemeine Web-Schwachstellenscanner führen zu gefährlichen blinden Flecken, da ihnen ein tiefgreifendes Verständnis der einzigartigen Architektur von SAP fehlt. Eine robuste, SAP-native AST-Lösung analysiert ABAP, BTP-Dienste, SAP-Build-Workflows und benutzerdefinierte Namespace-Logik direkt, um SAP-spezifische Schwachstellen effektiv zu identifizieren und zu beheben.