Compliance und moderne Softwareentwicklung — Eine komplizierte Liebesgeschichte

Gerade IT-Unternehmen in der Finanzbranche sind (zu Recht) strengen Compliance-Anforderungen unterlegen und bedienen sich deshalb Frameworks wie ITIL und COBIT. Diese Frameworks — entstanden durch Best Practices in der IT — liefern wertvolle Praktiken zur Erfüllung von Anforderungen aus der IT-Governance.

Gleichzeitig versuchen Trends wie Agile, DevOps und Lean den Fokus bei der Entwicklung und dem Betrieb von Softwaresystemen wieder auf die Wertschöpfung zu legen. Ziele wie “faster time-to-market”, “higher quality” und “cost savings” werden als gemeinsames Ziel verfolgt, und nicht — wie vielleicht im klassischen Projektmanagement — als konkurrierende Ziele.

Dabei könnte der Eindruck entstehen, dass Verfechter von ITIL und COBIT von der anderen Seite als “schwerfällig”, “traditionell” und “lähmend” gesehen werden und umgekehrt Verfechter von DevOps als “chaotisch”, “nicht kontrollierbar” und “ohne Verständnis für Security und Risiko-Minimierung”. Diese beiden Arbeitsweisen kommen also niemals zusammen. So weit kann die Liebe nicht reichen. Oder vielleicht doch?

Beziehungsprobleme? Da war doch schon mal was

Auch die DevOps-Bewegung musste den Konflikt zwischen Devs und Ops überwinden. Devs sagte man nach, dass sie nur laufend neue Features entwickeln wollten, sich aber nicht für die Stabilität ihrer Software-Produkte interessierten. Und Ops wollten (so sahen es zumindest die Devs), dass sich die Software-Produkte am besten gar nicht ändern, um Stabilität zu gewährleisten. Jede Änderung ist ja nur ein weiteres Risiko, dass die Software nicht mehr funktioniert. Never change a running system!

Was wurde in der Agile/DevOps/Lean-Bewegung erreicht:

Crossfunctional Product-Teams kümmern sich um Entwicklung und Betrieb ihrer Applikationen. Mit der gemeinsamen Verantwortung steigt auch die Motivation, schnelle Änderbarkeit (Agilität) und Betriebsstabilität gleichermaßen zu gewährleisten. Die Themen werden nicht mehr gegeneinander ausgespielt.
Die Teams sind weitgehend autonom und selbstorganisiert, um ohne große Abstimmungen und Wartezeiten ihre Produkte weiterentwickeln zu können. Reibungsverluste wegen zu hoher Bürokratie und Koordinationsaufwand wird minimiert.

Methoden wie Infrastructure-As-Code (Software-Defined-Everything) und vollautomatisierte Build- und Deployment-Pipelines unterstützen dabei Software schnell und kontrolliert in Produktion zu bringen.
Mit entsprechenden Observability-Tools kann man das Verhalten der Applikation in Produktion besser verstehen und die Betriebsstabilität laufend steigern. Im Idealfall können Informationen der Observability-Tools sogar in der Deployment-Pipeline zur Qualitätssteigerung verwendet werden, bevor die Applikation in Produktion deployt wird.
Dadurch (und durch einige andere Methoden) wurde der Konflikt zwischen “agiler Softwareentwicklung” und “stabilem Betrieb der Software” reduziert. Durch besseres Verständnis beider Seiten und innovative Tools können beide Ziele (Stabilität und Veränderbarkeit) gemeinsam verfolgt werden. Agilität wurde von den Kritikern nicht mehr als “chaotisch” verstanden, sondern als diszipliniertes und schnelles Reagieren auf Veränderungen.

Und jetzt zwischen Compliance und moderner Softwareentwicklung?

Im ersten Schritt muss immer ein besseres gemeinsames Verständnis aufgebaut werden. Klassische Prozessmanager haben möglicherweise nicht soviel Einblick in moderne Entwicklungsmethoden, und umgekehrt beschäftigen sich Software-Engineers nicht ständig mit Compliance-Anforderungen. Außerdem sind Compliance-Anforderungen oft sehr generisch und die Interpretation bzw. zumindest die Implementierung dieser können an moderne Engineering-Methoden angepasst werden. D.h. das WAS und WARUM kann möglicherweise der Compliance-Experte besser beantworten, das WIE möglicherweise der Techniker.

Ich möchte beispielhaft nur die Themen Configurationmanagement, Changemanagement und Schwachstellenmanagement herausgreifen.

Das WAS und WARUM:

Das Ziel vom Configurationsmanagement ist es, alle notwendigen Komponenten der IT-Systeme (und deren wichtigsten Eigenschaften) zu identifizieren und gemeinsam in Beziehung setzen zu können. Wie setzt sich mein Software-Stack zusammen (z.B. auf welchem System ist Software-Komponente xy installiert) und welche Komponenten sind abhängig voneinander (z.B. welche Applikation kommuniziert mit welcher Datenbank). Aus diesen Informationen wird dann eine Configurationmanagement-Datenbank (CMDB) aufgebaut.
Das Configurationmanagement unterstützt weitere ITIL-Praktiken wie Changemanagement, Problemmanagement usw. damit sich diese auf eine gemeinsame Datenbasis beziehen können. Im Changemanagement z.B. “Welche Komponenten ändere ich gerade und welche Komponenten könnten davon betroffen sein”.

Das WIE:

Configurationmanagement muss aber nicht zwingend bedeuten, dass das Erfassen und Aktualisieren dieser Komponenten manuell passieren muss und über Ticket-Systeme anderen Teams übermittelt werden muss. Hier haben bereits in traditionellen IT-Umgebungen sogenannte Discovery-Tools wertvolle Dienste bei der Datensammlung geleistet.

In modernen IT-Systemen wie z.B. kubernetes-basierten Plattformen sind auch technische Komponenten wie Server oder Firewall-Regeln komplett als Code in Versionskontrollsystemen verwaltet und werden über automatisierte Deployment-Pipelines in die Produktion deployt (GitOps).
Die CIs sind also Code-Elemente (bei K8s im YAML beschriebene API-Objects) und auch deren statische Beziehung zueinander findet sich in den API-Objekten wieder. Dynamische Beziehungen, die erst zur Laufzeit bekannt sind, können moderne Observability-Tools wie z.B. Dynatrace erfassen. Diese Informationen können wiederum über APIs in eine zentrale CMDB übertragen werden.

Änderungen dieser CIs sind nur übers VCS möglich, und Commit-Regeln können den Entwickler dazu zwingen, eine Referenz auf die Anforderung (z.B. JIRA-Task) bei jeder Änderung zu hinterlegen.
Damit sind wichtige Anforderungen aus dem Changemanagement-Prozess abgedeckt.

Automatisierte Vulnerability-Scans und Policy-Checks in der Pipeline unterstützen das Schwachstellen-Management und verhindern, dass unsichere Software in Produktion gelangt.

Vollautomatisierte Deployment-Pipelines unterstützen den Release- und Deployment-Prozess. Automatisierte Quality-Gates, gespeist mit Informationen aus modernen Observability-Tools, können die Qualität bereits vor dem Produktivgang kontrollieren. Canary- oder Blue/Green-Deployments können zusätzlich das Risiko beim produktiven Einsatz reduzieren.

Fazit

Compliance-Anforderungen und moderne Entwicklungmethoden müssen sich nicht zwingend widersprechen. Moderne Software-Engineering-Methoden (Software-Defined-Everything, automatisierte Pipelines inkl. Security-Checks, …) unterstützen gewisse Compliance-Anforderungen sogar besser als es traditionelle Entwicklungsmethoden und Infrastrukturen je konnten, weil sie schneller, nachvollziehbarer und erzwingbar durchgeführt werden können.
Dafür benötigt man allerdings formalisierte Compliance-Regeln (Compliance-As-Code), was einer Compliance-Prüfung aber ohnehin nur zugute kommt.

Compliance-Anforderungen könnten also modernen Entwicklungsmethoden sogar noch mehr Auftrieb geben, weil nur sie es schaffen, die strengen Anforderungen wirklich umzusetzen. Es könnte also doch so etwas wie eine Liebesgeschichte entstehen. Zumindest eine sinnvolle Partnerschaft.

Referenzen

Compliance-as-a-Code kommt Finanzunternehmen zugute
Passen IT-Compliance und agile Methoden zusammen?
Are Auditors ready for DevOps
A Love Letter to Auditors from DevOps
Slow Chaos VS Fast Discipline