4 Mythen über DevOps in einer regulierten Industrie

• Agile und DevOps-Praktiken können in einer regulierten Branche funktionieren

• Neue Cybersicherheitsbestimmungen werden die Umsetzung von Agile und DevOps-Praktiken nicht behindern, sondern vielmehr einbeziehen

• Dies kann durch Ansätze wie das "Shift-Left"-Prinzip, CI/CD-Pipelines sowie durch die Nutzung von unternehmenstauglichen Frameworks wie Java Spring oder .Net Core erreicht werden

Vor kurzem sprach ich mit einem Partner, der im IT-Bereich in der Finanzindustrie tätig ist. Und er sagte mir: "Es lohnt sich nicht, Agile- und DevOps-Praktiken in einer regulierten Branche zu implementieren".

Ich war von dieser Perspektive überrascht. Vor allem deshalb, weil ich nicht nur die erfolgreiche Implementierung von DevOps in einer stark regulierten Branche erlebt habe, sondern auch gesehen habe, wie Prozesse durch Sicherheitsvorschriften durchgesetzt werden. Deshalb möchte ich mit einigen Mythen über die Idee brechen, DevOps heute in einer regulierten Industrie zu implementieren.

Mythos Nr. 1: Eine Verordnung tritt zu einem bestimmten Datum in Kraft. Das damit verbundene Projekt hat also eine feste Zeit, ein festes Budget und auch einen festen Umfang.

Regelungen für Unternehmen sind meist dazu da, die Interessen der Kunden zu schützen und die Qualität einer Dienstleistung oder eines Produkts sicherzustellen. Um dies zu erreichen, erzwingen Vorschriften in der Regel einen Prozess zur Sicherung der Qualität. Sie schreiben jedoch nicht vor, wie der Prozess umgesetzt werden muss.

Zum Beispiel besagt die Allgemeine Datenschutzverordnung (EU GDPR) oder das äquivalente Personal Data Protection Act 2012 (PDPA) in Singapur, dass der Kunde das Recht hat, von einem Unternehmen Informationen darüber zu verlangen, welche Daten das Unternehmen über den Kunden besitzt und wie diese verarbeitet werden.

Es gibt jedoch mehrere Optionen zur Umsetzung dieses Prozesses. Es kann sich um eine vollautomatische Anwendung handeln, die Daten von mehreren CRMs und anderen Systemen sammelt und diese Daten an den Kunden exportiert. Oder eine einfache E-Mail-Antwort des Rechts- oder Compliance-Teams kann ausreichend sein. Daher sehen wir, dass der Umfang einer geeigneten Lösung in der Regel flexibel ist.

Eine flexible Lösung bedeutet, dass auch der Projektzeitplan in der Regel formbar ist. Während Regulierungen in der Finanzindustrie feste Beschränkungen für Finanztransaktionen auferlegen können, führen unterschiedliche Lösungen zu unterschiedlichen Kosten pro Transaktion.

Auf diese Weise könnte es möglich sein, eine einfache Lösung innerhalb kurzer Zeit zu implementieren und zu einer komplexeren Lösung überzugehen, die dazu beiträgt, die Kosten pro Transaktion in Zukunft zu senken. Auch dies kann bei der agilen Produktentwicklung schrittweise in mehreren Iterationen erreicht werden.

Mythos Nr. 2: Es ist einfach nicht möglich, DevOps in einer regulierten Industrie zu implementieren

In der Vergangenheit habe ich einige Zeit in der Gesundheitsbranche gearbeitet. Die Gesundheitsbranche ist stark reguliert, um die ordnungsgemäße Versorgung eines Patienten zu gewährleisten. Daher betrug die minimale Zeit bis zur Veröffentlichung einer neuen Version eines Produkts etwa 6 Monate, und in der Regel noch viel länger.

Vor einigen Jahren jedoch gab die Food and Drug Administration (FDA) in den Vereinigten Staaten die Cybersicherheitsverordnung heraus, dass jede Sicherheitslücke, die in einem medizinischen Produkt festgestellt wird, spätestens 60 Tage nach der Feststellung der Schwachstelle behoben werden muss.

Dies schien eine unmögliche Aufgabe in einer Branche zu sein, in der jegliche Korrekturen und die Veröffentlichung einer neuen Produktversion mindestens 6 Monate dauern können. Die Lösung war einfach: Verkürzung der Release-Zeit auf weniger als 60 Tage, was wir durch die Übernahme der DevOps-Praktiken und die Automatisierung möglichst vieler Aufgaben im Release-Prozess erreicht haben:

• Automatisierte Genehmigungen statt manueller Abzeichnungen.
• Automatisierte Tests anstelle von manuellen Tests.
• Automatisierte Infrastruktur-Bereitstellung und -Validierung statt manuell.
• Automatisierte Generierung von Dokumentation zur Freigabe/Testung/Rückverfolgbarkeit.

Der erste Punkt ist besonders wichtig, aber oft auch der am schwierigsten umzusetzende. Und weil dies in der Regel eine Änderung der Organisation und der Verantwortlichkeiten der Rollen bedeutet.

Die Hauptbotschaft hier ist, dass die Implementierung von DevOps in einer regulierten Industrie nicht nur möglich ist, sondern sogar durch die Einführung neuer Vorschriften erforderlich wird. Und während die strenge Regulierung der Cybersicherheit jetzt in der Gesundheitsbranche gilt, könnten sehr ähnliche Vorschriften auch von anderen Branchen übernommen werden. Beispielsweise gibt es bereits Diskussionen über die Durchsetzung von Korrekturen von Sicherheitslücken in zukünftigen Aktualisierungen der GDPR.

Mythos Nr. 3: Es ist nicht möglich, die Sicherheit eines Systems zu gewährleisten, wenn alle 2 Wochen eine neue Version erscheint

Der Prozess der traditionellen Softwareentwicklung umfasst mehrere Schritte: Spezifikation, Implementierung, Test und Validierung, Sicherheitsvalidierung und andere Arten der Validierung.

Diese Schritte werden in der Regel von verschiedenen Abteilungen oder Teams getrennt durchgeführt. Der Vorteil dieses Verfahrens ist eine starke Konzentration auf bestimmte Aspekte durch Experten mit einem hohen Maß an Wissen und Erfahrung. Beispielsweise kann ein Sicherheitsexperte mit mehrjähriger Sicherheitsvalidierung einen äußerst zuverlässigen Bericht über den Sicherheitsstatus eines Softwaresystems erstellen.

Leider lässt sich dieser Ansatz nicht gut skalieren. Insbesondere dann, wenn die Sicherheitsvalidierung einer einzelnen Softwareversion bis zu mehreren Wochen oder sogar Monaten dauern kann.

Dieses Problem kann durch das Prinzip "Shift Left" gelöst werden. Das Prinzip verschiebt die Aufgabe in frühere Stadien des Prozesses. In Bezug auf die Sicherheitsvalidierung besagt das Prinzip, die Sicherheitsvalidierung in die CI/CD-Pipelines aufzunehmen und idealerweise die Software-Sicherheit bereits in der Systemspezifikations- und Entwurfsphase zu berücksichtigen.

Dies kann mehrere Aufgaben umfassen:

• Definieren Sie Product Backlog Items mit spezifischen Sicherheitszielen.
• Statische Code-Analyse für bewährte Verfahren (z.B. keine Verwendung veralteter Kryptographie-Algorithmen).
• Suche nach Abhängigkeiten mit Sicherheitslücken.
• Automatisierte Sicherheitstests.
• Validierung von Best Practices für die Infrastrukturkonfiguration.

Die Aufgabe eines Sicherheitsexperten besteht dabei darin, Teams in die Lage zu versetzen, sichere Software zu entwickeln. Er/sie sollte den Teams helfen, die Sicherheit in die Pipelines zu integrieren und die Pipelines dann regelmäßig zu validieren und zu verbessern. Auf diese Weise kann die Arbeit eines Sicherheitsexperten viel besser skaliert werden.

Mythos Nr. 4: Software-Entwickler sind nicht für die Sicherheit verantwortlich

Vor einigen Jahren wurden die meisten Unternehmensanwendungen auf Anwendungsservern oder in komplexen Laufzeitumgebungen (z. B. J2EE oder .NET Framework) bereitgestellt. Die Umgebung bietet die Infrastruktur, die Anwendungen normalerweise benötigen, einschließlich Konfiguration, Protokollierung, Ausnahmebehandlung, Statusverwaltung, Drosselung und mehr.

Der Vorteil dieses Ansatzes bestand darin, dass die Sicherheit der Anwendungsinfrastruktur durch den Betrieb verwaltet werden konnte. Wenn beispielsweise eine Schwachstelle im Authentifizierungsmodul des Anwendungsservers gefunden wurde, wurde der Anwendungsserver gepatcht, und alle Anwendungen auf dem Server wurden ohne Beteiligung des Entwicklungsteams gesichert.

Andererseits war der Nachteil dieses Ansatzes, dass die Komponenten in der Regel eng an die Laufzeit- oder Anwendungstechnologie gekoppelt waren. Dies machte das Testen von Anwendungskomponenten sehr kompliziert oder fast unmöglich, da die Komponenten nicht außerhalb des Anwendungsservers oder in einer sehr spezifischen Umgebung laufen konnten.

Vor einiger Zeit wurden agilere Frameworks entwickelt (z.B. Java Spring oder .NET Core). Diese Rahmenwerke bieten eine Umkehrung der Kontroll- und Abhängigkeitsinjektionsmerkmale, um hochgradig komponierbare und erweiterbare Komponenten zu entwickeln. Auf diese Weise wird es viel einfacher, die Stückprüfung solcher Komponenten zu implementieren.

Darüber hinaus bieten diese Frameworks Dienste für ein effektives Anwendungs-Bootstrap mit minimalen Abhängigkeiten. Anwendungen können dann als in sich geschlossene Pakete mit fast keinen Abhängigkeiten von systemweiten oder gemeinsam genutzten Frameworks bereitgestellt werden. Beispielsweise können Anwendungen als Docker-Container eingesetzt werden.

Leider wird es dadurch für die Operationen unmöglich, bekannte Schwachstellen zu patchen. Sicherheitspatches müssen daher als Teil der Software-Entwicklung durchgeführt werden und fallen somit natürlich in die Verantwortung des Software-Entwicklungsteams.

Wie können Agile und DevOps-Praktiken in einer regulierten Branche funktionieren?

Da die Bedeutung der Cybersicherheit im digitalen Zeitalter immer wichtiger wird, glaube ich, dass wir sehen, dass diese neuen Cybersicherheitsvorschriften die Umsetzung der agilen und DevOps-Praktiken nicht behindern, sondern vielmehr umfassen werden, um sicherzustellen, dass die Anbieter in der Lage sind, schnell auf Sicherheitslücken zu reagieren.

Dies kann durch Ansätze wie das "Shift Left"-Prinzip erreicht werden, bei dem die isolierte Sicherheitsvalidierung auf die Sicherheitsintegration in die Softwareentwicklungsprozesse und CI/CD-Pipelines verlagert wird, sowie durch die Nutzung von Frameworks wie Java Spring oder .NET Core, die mit dieser Überlegung entwickelt wurden.Wie können agile und DevOps-Praktiken in einer regulierten Branche funktionieren?

Da die Bedeutung der Cybersicherheit im digitalen Zeitalter immer wichtiger wird, glaube ich, dass wir sehen, dass diese neuen Cybersicherheitsvorschriften die Umsetzung der agilen und DevOps-Praktiken nicht behindern, sondern vielmehr umfassen werden, um sicherzustellen, dass die Anbieter in der Lage sind, schnell auf Sicherheitslücken zu reagieren.

Dies kann durch Ansätze wie das "Shift Left"-Prinzip erreicht werden, bei dem die isolierte Sicherheitsvalidierung zur Sicherheitsintegration in die Softwareentwicklungsprozesse und CI/CD-Pipelines verlagert wird, sowie durch die Nutzung von Frameworks wie Java Spring oder .NET Core, die mit dieser Überlegung entwickelt wurden.