DevSecOps für SAP? Aber klar!

CIOs haben vereinzelt Bedenken, dass sie die Silo-Sicherheit einer SAP-Umgebung und Tausender Abap-Eigenentwicklungen nicht aufrechterhalten können, wenn sie moderne, Cloud-basierte Nicht-SAP-Systeme und Dienste in die Prozesslandschaft integrieren. Diese Vorbehalte sind bei einer manuellen Konfiguration und Wartung Hunderter zusätzlicher Cloud-Module und Services nicht unbegründet.

Durch die Nutzung einer abgestimmten, bereits vorintegrierten Container-Plattform für alle Zielarchitekturen von On-premises über Edge bis Cloud lassen sich viele der Anforderungen an Governance, Compliance, Code-Security und Kontrolle bereits von vornherein für alle genutzten Ebenen umsetzen. Die erforderlichen Funktionalitäten für die Sicherheit von End-to-End-Prozessen sind standardmäßig vorhanden.

Will ein Unternehmen Innovationsthemen vorantreiben, führt an der Nutzung neuer Plattformen, Frameworks, Anwendungen und Technologien kein Weg vorbei: Integrierte hybride Multi-Cloud-Plattformen, Cloud-native Anwendungen, Container, Microservices und APIs sind dabei fraglos die entscheidenden Komponenten. Hybrid-Cloud-Plattformen und die Cloud-native Anwendungsentwicklung werden somit auch die SAP-Zukunft nachhaltig bestimmen.

Das heißt auch, dass SAP-Umgebungen nicht mehr als isolierte Systeme, sondern unter Berücksichtigung des Side-by-Side-Extensibility-Konzepts von SAP gesehen werden müssen. Hierbei geht es um die Verbindung von SAP-Daten, -Prozessen und -User-Interfaces mit modernsten Programmierumgebungen, Continuous-Integration- und Delivery-Systemen und DevOps-Methoden. Die sogenannten Side-by-Side Extensions für S/4-Systeme erlauben im Gegensatz zu klassischen Abap-basierten Eigenentwicklungen die einfache Umsetzung von agilen End-to-End-Prozessen und integrieren damit die SAP-Landschaft auch mit Nicht-SAP-Systemen. 

Doch was bedeuten diese Entwicklungen für die Sicherheit? SAP-Infrastrukturen müssen konsequent in eine Security-Strategie integriert werden, wenn Silo-Grenzen überbrückt werden sollen. Etablierte Sicherheitskonzepte sowie SAP-Rollen- und Rechtemanagement dürfen bei einer Non-SAP-Integration nicht verwässert oder aufgeweicht werden – ein „Technischer User“ ist keine dauerhafte Lösung.

Gerade bei der Cloud-nativen Applikationsentwicklung nimmt die Sicherheit eine hohe Priorität ein, die auch bei der Entwicklung moderner
Side–by-Side-basierter SAP-Erweiterungen genutzt wird und eine Abap-Ablösung allein aus Security-Sicht rechtfertigen kann. Im Hinblick auf Containerisierung wird zum Beispiel sichergestellt, dass beim Hostsystem keine unberechtigten Zugriffe zwischen den genutzten Ressourcen möglich sind. Auch sollten Container Images nur aus vertrauenswürdigen Quellen bereitgestellt werden, zum Beispiel nur nach Prüfung durch die interne IT aus vordefinierten Katalogen.

Besonders wichtig ist aber vor allem auch ein solides Linux. Es gibt mehrere Security-Levels zum Schutz von Containern unter Linux wie etwa SELinux (Security-Enhanced Linux). SELinux ist auf dem Linux-Betriebssystem Red Hat Enterprise Linux 8 standardmäßig aktiviert und läuft oft in Hochsicherheitsumgebungen, auch mit Hana.

Insgesamt muss modernes Security-Management also keineswegs bei der SAP-Plattform enden. Die Sicherheit kann konsequent in den mit SAP- und Nicht-SAP-Systemen integrierten End-to-End-Prozessen umgesetzt werden. Eine zentrale Basis dafür sind moderne Enterprise-Kubernetes-Plattformen wie Red Hat OpenShift. Sie enthält alle erforderlichen Funktionalitäten und Services, um eine Container-Management-Plattform für vielfältige, geschäftskritische Anwendungen auf verschiedensten Infrastrukturen zertifiziert zu betreiben. Dazu zählen zum Beispiel SLAs, mehrere Sicherheits-Layer, die Automatisierung oder das Cluster-Management. Und die Sicherheitsfeatures sind dabei umfassend: vom Vulnerability Management über die Netzwerksegmentierung bis hin zur Continuous Compliance oder Risikopriorisierung.