SAP-Entwickler: Abwehrchef statt Sicherheitsproblem?

SAP-Entwickler arbeiten in integrierten geschäftskritischen Umgebungen und erstellen Software, die Daten mit spezifischen Sicherheitseigenschaften und regulatorischen Anforderungen verarbeitet.

Tragende Rolle der Entwickler

SAP-Entwickler haben eine tragende Rolle bei der Gestaltung der Sicherheitslandschaft von SAP-Umgebungen. Die Entwicklung von Code zu den Änderungen an bestehenden SAP-Funktionen oder neuen Anwendungen und Schnittstellen kann ein beliebig komplexes IT-Entwicklungsprojekt sein. Diese Anpassungen sind oft notwendig, können aber Schwachstellen beinhalten und das Sicherheitsniveau des Gesamtsystems reduzieren.

Viele Sicherheitslücken im SAP-Umfeld sind auf fehlende Anforderungen, falsche Entscheidungen im Softwaredesign und Werkzeugauswahl und fehlende Kenntnis über sichere Programmierpraktiken mit den verwendeten Programmiersprachen und Frameworks zurückzuführen. Dabei erzeugen Entwickler unwissentlich mehrere Schwachstellen wie Directory Traversals, Cross-Site-Scripting-Schwachstellen oder Fehler in der Zugriffskontrolle. Eine einzige Schwachstelle kann sensible Geschäftsdaten offenlegen oder eine Kompromittierung des Systems durch einen Angreifer ermöglichen. Stand heute erzeugen Entwickler neben dem Nutzen durch ihre Arbeit neue Sicherheitsrisiken. Entwickler haben umfangreiche Berechtigungen. Mit umfassenden Zugriffsrechten können Entwickler versehentlich oder böswillig Hintertüren einführen, kritische Daten manipulieren oder Sicherheitskontrollen umgehen. Checklisten zur Prüfung von Transportfreigaben umfassen oft bis heute keine Prüfung auf Sicherheitsdefekte oder Schadsoftware.

Wird keine Aufgabentrennung durchgesetzt und Entwickler haben ungehinderten Zugriff auf Entwicklungs-, Test- und Produktionsumgebungen, ist eine Erbeutung dieser Zugänge für Angreifer besonders interessant. Außerhalb der SAP-Welt würde man das Profil eines SAP-Entwicklers als Full-Stack-­Entwickler bezeichnen. Damit sind in Abgrenzung zu Frontend und Backend Programmierer gemeint, die eine Anwendung von der Benutzerschnittstelle über Integrationen bis hin zur Geschäftslogik selbstständig mit dem verfügbaren Technologiestack realisieren.

In Kombination mit ihrem Prozesswissen liefern SAP-Entwickler mit dem SAP-Werkzeugkasten zu Tausenden täglich Erweiterungen und Anpassungen aus und stellen damit SAP-Kunden ein enormes Innovationspotenzial und Wettbewerbsvorteile zur Verfügung. Der angebotene Werkzeugkasten der SAP wird dabei immer größer und es wird oft erwartet, dass SAP-Entwickler die Klaviatur von der Pflege einer SAP-GUI-Bestandsanwendung bis hin zur Verwendung von Fiori-Elements und alles dazwischen beherrschen. Jede dieser Klaviaturen hat individuelle Sicherheitseigenschaften, die der SAP-Entwickler bei deren Verwendung berücksichtigen sollte, um Schwachstellen zu vermeiden und Sicherheitsanforderungen korrekt umzusetzen.

Fatales Learning by Doing

Selten können Sie dafür Zeit und Ressourcen in Anspruch nehmen – meist herrscht eine „Learning by Doing“-Mentalität mit Folgen. „Ich hätte bei dem Begriff ‚Transport‘ nie an ein Softwareauslieferungsformat gedacht“, so der Softwaresicherheitsarchitekt einer Bank. Häufig wissen der übrige IT-Betrieb und die Informationssicherheit überhaupt nicht, in welcher Frequenz und welchem Umfang Softwareentwicklung mit SAP-Technologien als Anwendungsplattform stattfindet. Ein Softwarearchitekt bei einem Kunden hat das einmal als den „Hidden Elephant“ seiner Softwareentwicklungspraxis beschrieben.

So passiert es aber auch, dass Initiativen zur Steuerung von Softwareentwicklungsprozessen oder der Verbesserung der Qualität und Sicherheit die SAP-Entwicklung nicht miteinbeziehen und dafür definierte Prozesse und Werkzeuge für die SAP-Entwicklung nicht oder nur teilweise anwendbar sind. Dabei können Fehler in kundeneigenen Entwicklungen und Add-ons erhebliche Sicherheitsprobleme verursachen. Wie jede Programmiersprache haben auch Abap und Co. spezifische Eigenschaften, denen man als Entwickler Rechnung tragen muss.

Abap-Fehlermuster

Aus den Dutzenden Code-Reviews, die ich in den vergangenen zehn Jahren durchgeführt habe, stechen folgende Fehlermuster besonders hervor:

• Unzureichende Validierung von Eingaben, die zu Directory-Traversal-, SQL-Injection- oder Code-Injection-Schwachstellen führen. Das hat unmittelbar oder mittelbar die Möglichkeit einer vollständigen Kompromittierung eines SAP-Systems zur Folge. Oft liegt hier fehlendes Wissen um die Sicherheitseigenschaften des verwendeten Frameworks oder API zugrunde.

• Fehler im Design und der Implementierung von Zugriffskontrollen wie fehlende oder logisch falsche Berechtigungsprüfungen und unzureichende Funktionstrennung im Design der Datenspeicherung oder -verarbeitung und Anzeige. Damit kann ein Abfluss vertraulicher Informationen einhergehen oder deren Kompromittierung auf Transaktionsebene.
• Unsichere Integrationsdesigns, die letztlich in Möglichkeiten zur Kompromittierung von produktiven SAP-Systemen aus zum Beispiel Test- und Entwicklungsumgebungen resultieren oder andere Formen von Server-Side-Request-Forgery-Angriffen ermöglichen.
• Fehlendes Aufräumen veralteter und meist nicht mehr relevanter Werkzeuge oder Kopien von SAP-Standardanwendungen, bei denen Sicherheitsfunktionen ausgebaut oder Schwachstellenbehebungen der SAP nie eingebaut wurden.

Verwenden Sie ausschließlich „call transaction“ mit der Option „with authority-check“ (Auszug einer leider typisch schlechten Entwicklungsrichtlinie).

Clean-Core-Paradigma

Auch in der SAP-Welt braucht Softwaresicherheit klare Richtlinien in Kombination mit passenden Hilfen für die Entwickler, um diese zu erfüllen. Oft scheiterten Codequalitäts- und Sicherheitsinitiativen an Letzterem. Weder die Einführung einer gegenüber den Standardwerkzeugen verbesserten Quellcodeanalyse noch Verbote in Entwicklungsrichtlinien werden SAP-Entwicklern das Bewusstsein für Sicherheit und die nötige Lösungskompetenz nahebringen.

Das passende Training und sinnvolle Handreichungen in der Form von How-tos sind Grundlage für die notwendige Kulturänderung, damit andere Maßnahmen und Werkzeuge auch greifen. Aber kann ein SAP-Entwickler unter Anwendung des „Clean Core“-Paradigmas und mit Werkzeugen wie SAP Build und Joule künftig überhaupt noch schwerwiegende Sicherheitsprobleme verursachen? ­„Clean Core“ propagiert die Trennung von Erweiterungen und Kernfunktionalität. Neben dem eigennützigen Ziel, Bestandskunden besser in die SAP-Cloud-Dienste migrieren und sie daran gewöhnen zu können, werden operative Risiken bei Updates und Migrationen bei korrekter Anwendung erheblich reduziert.

Sicherheitsdefekte schließen

Die Nutzung der SAP Business Technology Platform (BTP) hat eine striktere Trennung der kundeneigenen Erweiterung vom SAP-Standard zur Folge. Wenn gut umgesetzt, können die möglichen Auswirkungen der oben genannten typischen Schwachstellen reduziert bzw. stark eingedämmt werden oder bestimmte Sicherheitsdefekte wie beispielsweise Directory-Traversal-Schwachstellen ausgeschlossen werden. Die Ansprüche an die Fähigkeiten des Entwicklers, Sicherheit korrekt umzusetzen und dabei ursprünglich transaktionsorientierte Designs in eine Microservicearchitektur zu überführen, sind beachtlich. So obliegen dem SAP-Entwickler nun auch weiterführende Sicherheitsaufgaben, wie das Bauen von Rollen, die Anwendung neuer Konzepte für die Anwendungsprotokollierung und die Prüfung von abhängigen Softwarekomponenten und Bibliotheken auf Schadsoftware und Schwachstellen.

Die Wahrheit liegt im Code

Im klassischen SAP-Betriebsmodell sind dies Aufgaben des Berechtigungs- und Basisadministrators. Hinzu kommen mit cloudnativer Programmierung neue Bedrohungsszenarien, die der SAP-Entwickler behandeln muss. Zum Beispiel ein ökonomischer Denial of Service (EDoS), bei dem die Anwendung missbraucht wird, Dienste und Ressourcen der Cloud so erheblich in Anspruch zu nehmen, dass die Kosten nicht getragen werden können oder Dienste durch Erreichen von Maximalverbrauchswerten deaktiviert werden.

Dabei muss er den zur Verfügung stehenden SAP-Werkzeugkasten mit seinen Sicherheitseigenschaften verstehen und sollte Konzepte zur Sicherheitsanalyse von Softwareanwendungen beherrschen sowie Bedrohungsmodellierung erstellen und Gegenmaßnahmen umsetzen können. Damit wird der SAP-Entwickler zu einem zentralen und steuernden Akteur der IT-Sicherheit Ihrer SAP-Umgebung.

Zusammenfassend lässt sich sagen, dass sowohl cloudnative als auch klassische SAP-Anwendungen, sei es aus kundeneigener Entwicklung oder von Dritten, sorgfältig auf Schwachstellen und Sicherheitskonformität geprüft werden müssen. Die Rolle des SAP-Entwicklers ändert sich dabei immer mehr vom Umsetzer funktionaler Anforderungen hin zu einem Berater, der innovative Lösungen findet, Datensicherheit und -schutz sowie Sicherheitsanforderungen für den Betrieb und die Bereitstellung seiner Anwendung von Beginn an berücksichtigt und deren hinreichende Umsetzung hinterfragt.

SAP-Werkzeugkasten verstehen

Dabei muss er den zur Verfügung stehenden SAP-Werkzeugkasten mit seinen Sicherheitseigenschaften verstehen und sollte Konzepte zur Sicherheitsanalyse von Softwareanwendungen beherrschen sowie Bedrohungsmodellierung erstellen und Gegenmaßnahmen umsetzen können. Damit wird der SAP-Entwickler zu einem zentralen und steuernden Akteur der IT-Sicherheit Ihrer SAP-Umgebung.