Compliance ohne signifikante Mehraufwände in der Entwicklung, geht das?

Wir sind oft Teil von größeren IT-Projekten bspw. wenn es um die Digitalisierung ganzer Anwendungslandschaften auf der Basis von Hyperscalern, insbesondere AWS oder MS Azure, geht.

Diese Projekte finden bisher in größeren Unternehmen, beispielsweise der Telekommunikations- oder Automotive-Branche statt. Dort haben wir meist umfangreiche Regelwerke und Vorgaben, die Sicherheit und Compliance aus Sicht unserer Auftraggeber sicherstellen sollen.

Die Umsetzung von Compliance-Vorgaben erfolgt dabei aus unserer Erfahrung meist iterativ. Das bedeutet, dass unsere Devs und DevOps im Grunde bei der Umsetzung der Fachlichkeit kaum die Ziele der Compliance in erster Instanz als Vorgabe haben und erst bei einem Check der Ergebnisse auf Compliance und Security-Probleme hin Fehler und somit erst indirekt Anforderungen aufgezeigt bekommen.

Ja, das kann recht mühsam sein

Dieser Prozess ist sehr mühsam, langwierig und unstrukturiert; im Grunde erreicht man den gewollten Compliance-Status durch Trial and Error, wenn man ihn überhaupt erreicht, weil das missliebige Thema gerne schnell gegen etwas anderes ausgetauscht wird. Ach ja, und dann muss man das ja eigentlich auch noch dokumentieren! Das fühlt sich für unsere Entwickler:innen an wie früher ein Nachmittag gefüllt mit Hausaufgaben in Latein und Religion. Da hat wirklich keiner Lust drauf und in der aktuellen Marktlage müssen wir schauen, dass uns deswegen niemand kündigt - OK, leicht übertrieben.

Wie können wir es besser machen?

Wie gehen wir damit um? Im Grunde haben wir die Frage bereits im Artikel Immer einen aktuellen Blick auf den eigenen Compliance-Status: Compliance as a Service angerissen, wollen aber hier gerne etwas stärker in die Prozessbetrachtung gehen.

Die Grundidee bleibt es, Dinge, die eh und regelmäßig getan werden müssen zu automatisieren. Weshalb also nicht die automatisierte Überprüfung der Compliance? Und auch die automatisierte Dokumentation!? Dazu müssen wir verschiedene Tools, bspw. checkov (checkov, Open Source) einführen. Und der Prozess muss umgedreht werden, so dass die Überprüfung der Compliance-Regeln sozusagen frühestmöglich, bei jedem commit der Entwickler:innen, stattfinden kann.

Grob sieht der vorher / nachher-Vergleich so aus:

Was bedeutet das für den Entwicklungsaufwand?

Nun, es ist sicher ein mehr an Arbeit, zum einen die Regeln zur Überprüfung zu definieren und diese ggf. auch aktuell zu halten. Dazu kommt die Dokumentation einzurichten und ebenfalls regelmäßig danach zu schauen, was das Gesamtsystem macht, ob alles noch aktuell und vor allem vollständig ist, da ja im Allgemeinen auch weiterentwickelt wird. Eine Regelaufgabe.

Die Kernfrage ist dabei aber ja die, ob die Aufwände der Automatisierung inklusive der Pflege jene der händisch herbeigeführten Compliance und Dokumentation übertreffen oder nicht. Im Letzteren Fall würde sich der Automatisierungsaufwand also lohnen. Das war unsere initiale Hypothese.

Dazu kommt, dass das Implementieren der Regeln zur Prüfung der Compliance und das Aufsetzen der automatisierten Dokumentation deutlich näher an der üblichen Arbeitsplatzbeschreibung von Developern ist als das Schreiben von Business-Prosa.

Unterm Strich sind wir sicher, denn wir haben unsere Hypothese in verschiedenen Projekten, anfänglich in kleinen und jetzt in größeren, überprüft und können der bisherigen Erfahrung nach davon ausgehen, dass sich die Automatisierung >spätestens< nach ca. ein bis zwei Monaten amortisiert, je nach Umfang und Projektgröße. Dabei gehen wir vom Erfahrungswert aus, dass in Großprojekten bis zu 30 % aller Arbeiten für Dokumentation und Compliance (siehe Iterationen im Schaubild) benötigt werden, auch wenn diese oft noch ernsthaft in Form von Ressourcen allokiert werden, weil sie im Sinne einer Entwicklerschätzung einfach nicht mit bedacht werden, aber das nur am Rande.

Weitere Vorteile

Als Zusatznutzen erhält man ein Compliance Management Dashboard, das den eigenen Echtzeit-Compliance-Status anzeigt. Bisher hat man ein Audit gemacht, deren Ergebnisse dann auch recht schnell wieder veraltet sein konnten. Unser Ansatz ist stets aktuell; Fehler bei der Prüfung der Compliance-Regeln müssen für einen “grünen” Build gefixt werden. Neue Compliance-Regeln können jederzeit integriert werden (sofern technisch sinnvoll formulierbar); damit ist das Gesamtsystem weiter flexibel und skalierbar.

Wasser in den Wein

Natürlich müssen wir etwas Wasser in den Wein schütten, denn nicht alle oder beliebige Forderungen verschiedener Compliance-Standards können einfach so umgesetzt werden. Wir betrachten und überwachen hier in erster Instanz die zugrunde liegenden Infrastrukturen und auch die Prozesse drumherum, welche Gruppen haben beispielsweise Zugriff auf welche Daten? Welche Daten dürfen wie exponiert sein?

Dazu noch ein Satz im Sinne der Vollständigkeit: Wir können hier natürlich nicht die klandestine Weitergabe von Daten durch Mitarbeiter überprüfen oder wer von wem zum Essen eingeladen wird oder Weihnachtsgeschenke erhält. Das fällt auch unter Compliance, lässt sich aber nicht automatisiert prüfen.

Zusammenfassung

Compliance und auch die notwendige Dokumentation kann mit Hilfe verschiedener Tools zumindest auf den heutzutage üblichen Hyperscaler-Infrastrukturen und Toolsets hochgradig automatisiert werden. Im Fokus sind dabei die Software-Infrastrukturen und Betriebsprozesse. Der Aufwand, die Regeln zur Überprüfung der Compliance aktuell zu halten hält sich dabei in Grenzen, denn falsche oder alte Regeln führen üblicherweise zu einem Fehler in der CI/CD-Kette, so dass auf Developer-Seite die Aktualisierung meist sozusagen miterledigt und geprüft werden kann. Das frühe Erkennen von Compliance-Fehlern schon auf der Developer-Seite sorgt aus Prozesssicht für den größten Effizienz-Zugewinn. Die Zeitersparnis folgt aus einer deutlichen Verringerung der Iterationen mit nachgelagerten Prüfinstanzen, sofern diese im neuen System dann überhaupt noch notwendig sind. Dazu kommt sozusagen als Beifang das Echtzeit-Dashboard, das Verantwortlichen einen kontinuierlichen Blick auf den Compliance-Status des eigenen Unternehmens ermöglicht. Das Audit von vor sechs Monaten ist dann wirklich nur noch in Teilen interessant.