DevOps für SAP: Von DevSecOps zu Secure DevOps – der Fahrplan für mehr Sicherheit

DevOps ist in der Finanzwirtschaft angekommen. In immer mehr Banken arbeiten Software-Entwicklung (Development) und IT-Betrieb (Operations) Hand in Hand, um schneller und flexibler auf die steigenden Markt- und Kundenanforderungen reagieren zu können. Mit Secure DevOps wird IT-Sicherheit von Anfang an in die agile Programmierumgebung integriert.   

von Dr. Markus Schumacher, Geschäftsführer Virtual Forge

Zwei bis drei Releases pro Jahr: Das war einmal der Standard in der Finanzbranche. Digitaler Wandel, neue Technologien und branchenfremde Wettbewerber setzen die Bankinstitute zunehmend unter Druck, in immer kürzeren Zeitabständen hochwertige Anwendungen und Funktionen zu entwickeln, um innovative Geschäftsmodelle, Produkte und Services zu unterstützen. Viele Banken entscheiden sich für das DevOps-Konzept – zumal wenn die Programmierung in vorhandenen SAP-Umgebungen erfolgen soll. So steht mit SAP HANA eine neue Entwicklungsplattform zur Verfügung, die durch die Big-Data-Verarbeitung optimale Voraussetzungen für eine rasche und agile Programmierung neuer Anwendungen bietet und dabei einen hohen Qualitätsanspruch wahrt.

Genügt DevSecOps?

Dafür gilt Dev­Se­cOps der­zeit als Mit­tel der Wahl. Doch greift die­ser Si­cher­heits­an­satz zu kurz, da er sich vor­ran­gig auf funk­tio­na­le Schutz­kom­po­nen­ten kon­zen­triert. So ver­wen­det Dev­Se­cOps zum Bei­spiel Au­then­ti­fi­zie­run­gen, Be­rech­ti­gun­gen und Ver­schlüs­se­lung, um Schnitt­stel­len ge­gen Ma­ni­pu­la­tio­nen ab­zu­schir­men und zu ver­hin­dern, dass Dritt­kom­po­nen­ten mög­li­che Si­cher­heits­lü­cken ver­ur­sa­chen. Dies reicht je­doch nicht aus, um den ho­hen Ri­si­ken im De­v­Ops-Um­feld um­fas­send zu be­geg­nen. Bes­ser ist es, zu­sätz­lich ei­nen tech­ni­schen An­satz zu ver­fol­gen, der Si­cher­heit in den ge­sam­ten De­v­Ops-Le­bens­zy­klus in­te­griert und in je­der Pha­se spe­zi­el­le Prüf­werk­zeu­ge nutzt: Se­cu­re De­v­Ops. Als Ba­sis soll­ten Si­cher­heits­stan­dards, wie OWASP Top 10, SANS 25, BI­ZEC App / 11 und BI­ZEC Tec / 11, die­nen, die agil an je­weils meh­re­ren Prüf­punk­ten ge­tes­tet wer­den – an­ge­fan­gen bei der Pro­gram­mie­rung über die Kon­fi­gu­ra­ti­on neu­er An­wen­dun­gen und Funk­tio­nen bis hin zum Trans­port ins Ziel­sys­tem.

Tests in jeder DevOps-Projektphase

Für Secure DevOps sind im SAP-Umfeld folgende Testszenarien erforderlich:

1. Code-Entwicklung
Identifizieren und korrigieren Sie Fehler und Schwachstellen im ABAP-Code bereits während der Programmierung! Denn je eher eine SAP-Sicherheitslücke beseitigt wird, desto geringer ist der Folgeaufwand. Dazu können neben den Standard-Prüfwerkzeugen in der SAP-Entwicklungsumgebung auch Open-Source-Tools und Add-ons von Drittanbietern genutzt werden. Allen Tools ist gemeinsam, dass sie vorkonfigurierte Prüfkataloge zur Analyse des ABAP-Quellcodes integrieren. Damit kann jede Prüfung unmittelbar während des Code-Schreibens automatisch erfolgen – ähnlich der interaktiven Rechtschreibprüfung von Microsoft Word, die Text-Dokumente direkt bei der Eingabe auf Fehler untersucht und korrigiert. Mit den automatischen ABAP-Quellcode-Analysen werden manuelle Prüfungen durch die Entwickler überflüssig und die Fehlerquoten minimiert.

2. Testphase
Geben Sie prinzipiell keinen Quellcode frei, ohne ihn im Anschluss an die Programmierung automatisch getestet zu haben! Auch für diese Phase stehen verschiedene Prüfwerkzeuge zur Verfügung, mit denen sich der ABAP-Code direkt in der Entwicklungsumgebung testen lässt. Ob dabei Tools von SAP oder Open Source- und Add-on-Anbietern zum Einsatz kommen, hängt von Ihren individuellen Anforderungen ab. Wichtig ist: Zeigt sich in der Testphase, dass der Quellcode nicht den erforderlichen Qualitätsansprüchen genügt, darf er auf keinen Fall ins nächste Level überführt, sondern muss vorab korrigiert werden.

3. Build-Phase
Weitere Sicherheits- und Qualitätstests sollten Sie für die Build-Phase vorsehen, noch bevor die Eigenentwicklungen ins produktive SAP-System gelangen. In der Build-Phase werden die ABAP-Code-Fragmente zusammen mit den Konfigurationen und Tabellen-Inhalten in ausführbare Einheiten „gepackt“ – daher auch „Pakete“ oder, im SAP-Jargon: „Transporte“ genannt. Wenn das SAP-Transportwesen die einzelnen Objekte ins Produktivsystem einspielt, nimmt es leider keine detaillierten Überprüfungen vor. Da sich dadurch erst nach dem Transport herausstellt, ob sich Anpassungen negativ auswirken, sollten die Objekte bereits in der Build-Phase überprüft werden. Zudem stellt die Integration der Tests in den Change-Prozess sicher, dass die Anpassungen im SAP-Produktivsystem keine kritischen Einstellungen verändern oder unbeabsichtigt Daten überschreiben.

4. Laufzeit-Umgebung / Betrieb
Überprüfen Sie den Systembetrieb zyklisch mit geeigneten Prüfwerkzeugen! Nur so lässt sich herausfinden, ob durch eine Änderung nicht nur das Laufzeit-Verhalten eines Systems, sondern auch das Sicherheitsniveau beeinflusst wurde – etwa dann, wenn eine neue Konfiguration eine Protokollierung deaktiviert. Kommt es im laufenden Betrieb zu einem Sicherheitsvorfall, muss dafür gesorgt sein, dass der System-Administrator sofort einen entsprechenden Alarm erhält.

Nahtlose Integration der Prüfwerkzeuge

Bereits in klassischen SAP-Entwicklungsumgebungen sind IT-gestützte Tests für Finanzinstitute unverzichtbar, um Schwachstellen rechtzeitig erkennen und beseitigen zu können. Noch mehr gilt dies für DevOps-Umgebungen, in denen neue Anwendungen und Updates in immer kürzeren Zyklen aufgebaut, getestet und freigegeben werden müssen. Damit aus Sicherheit ein ständiger Begleiter der Anwendungsentwicklung und des IT-Betriebs wird, sollten DevOps-Teams in jeder Phase geeignete Prüfwerkzeuge einsetzen. Wenn diese von verschiedenen Herstellern stammen, müssen sie unbedingt darauf achten, dass die einzelnen Komponenten nahtlos integriert werden können und keine Medienbrüche entstehen. Ansonsten geht im schnellen DevOps-Umfeld leicht der Überblick verloren – mit der fatalen Folge, dass vorhandene Fehler- und Mängellisten übersehen werden können. aj