DevSecOps: Moderne Systemarchitekturen mit Microgateways
Seite 3: Beispiel 2: Die neue strategische Ausrichtung
Im zweiten Beispiel entwickelt ein größeres Unternehmen einen Teil der eigenen Software in-house. Die Transformation der Softwareentwicklung vom Wasserfallansatz hin zu agilen Methoden ist bereits weit fortgeschritten: Die Entwicklerinnen und Entwickler haben sich in Scrum-Teams organisiert, das Agile Manifest wird gelebt und interpretiert und die Definitions of Done sind etabliert. Diese Transformation gilt im Unternehmen als Erfolg, weil die kürzeren Feedbackzyklen und die stärkere Fokussierung auf die kurzfristige Priorisierung spürbare Verbesserungen in der Zielerreichung gebracht haben. In dieser Situation entscheidet das obere Management des Unternehmens, dass neuerdings auch das DevOps-Paradigma zu befolgen ist und Entwickler viel stärker in die betrieblichen Aspekte einzubeziehen sind.
Das Unternehmen verspricht sich davon ein Aufbrechen der funktionalen Silomentalitäten und eine Kultur, in der die Zielsetzungen der Softwareentwicklung besser auf die übergeordneten Ziele angepasst sind. Längerfristig erwartet das Management, dass eine Applikationslandschaft entsteht, die besser entkoppelt und auch einfacher und kostengünstiger zu betreiben ist.
DevOps und Security
Schnell fällt hierbei auf, dass es auch weiterhin Dienste geben muss, die zwar für den Betrieb der Applikation unerlässlich, aber nach wie vor von spezialisierten Abteilungen aufzubauen und zu betreiben sind. Dazu gehören sicherlich die Infrastrukturdienste: Netzwerk, Compute und Storage oder zentrale Services wie das Identity- und Access-Management. Also genau die Dienste, die moderne Cloudanbieter ihren Kunden "as a Service" anbieten wollen.
Die Diskussion um die Gewährleistung der Sicherheit der Applikation erweist sich als schwieriger, obwohl DevSecOps bereits als Fachbegriff existiert und suggeriert, dass die Integration von Security in DevOps wohl eine gewinnbringende Idee sein könnte. Es stellt sich allerdings die Frage, wie DevSecOps die Arbeit von Entwicklern vereinfacht und die entstehenden Applikationen verbessert.
DevOps stellt sicher, dass Entwickler nicht nur die Endanwendersicht berücksichtigen, sondern auch dafür sorgen, dass der Betrieb reibungslos läuft, weil sie auch diese Probleme kennen und verstehen. Dieser Ansatz lässt sich ebenso auf die Sicherheit anwenden, da Entwickler ihre eigene Applikation am besten verstehen.
Der Zeitpunkt entscheidet
Sicherheit wird als eigener Task in einem Projektplan gemanagt, und die Gatewayregeln entstehen und wachsen nicht mit der Applikation, sondern werden erst in der letzten Phase des Projekts erstellt. Das ist allerdings die Phase, in der der Feinschliff an den Businessfunktionen zur Erfüllung der Kundenanforderungen stattfindet, weshalb die Sicherheitsabnahme aufgrund "wichtigerer Dinge" erst zum Schluss erfolgt. Der CISO hat häufig nichts dagegen einzuwenden, weil schlussendlich die Version der Applikation zu prüfen ist, die auch zum Einsatz in der Produktion gedacht ist. Das kann gut gehen, wenn die Applikation alle Tests besteht, aber zu oft kommt es vor, dass trotzdem ein Sicherheitsproblem gefunden wird. So kurz vor der Fertigstellung führt das unweigerlich zu zeitraubenden und kostspieligen Maßnahmen.
DevSecOps beschreibt die Alternative, bei der Security von Anfang an im Entwicklungs- und Betriebsprozess integriert ist. Mikrogateways können bei der Erreichung dieses Ziels ein hilfreiches Werkzeug sein, indem sie eine sinnvolle Verteilung der Aufgaben ermöglichen.
Beispielsweise kann ein Entwicklerteam in der Continuous-Integration-Umgebung sämtliche Integrationstests via Microgateway durchführen. Dabei gibt es Integrationstests, die sicherstellen, dass die Sicherheitsmechanismen greifen und die Konfiguration des Microgateways keine Lücken aufweist. So wächst die Konfiguration des Microgateways direkt mit dem Ausbau der Funktionalität der Applikationen, wodurch sich der CISO jederzeit ein Bild von der Security machen kann – und nicht erst am Ende der Entwicklung. Die Komplexität stellt dabei nie ein Problem dar, weil sich das Regelset immer nur auf eine einzelne Applikation bezieht.
Dieser Ansatz funktioniert problemlos für Entwickler von Webapplikationen oder REST-Schnittstellen, wobei Entwickler einer REST-Schnittstelle mit einer OpenAPI-Spezifikation über eine besonders einfache und auch sehr wirksame Methode verfügen, um ein Microgateway optimal für den Schutz der Schnittstelle zu konfigurieren.
