Sicherheit in die DevOps-Strategie integrieren DevSecOps in 4 Schritten

Die Agilität von DevOps und Microservices-Umgebungen macht die Integration der Sicherheit nicht gerade einfacher. DevSecOps lässt sich aber durchaus realisieren, wenn man vom traditionellen Sicherheitsdenken abrückt.

Anbieter zum Thema

PresseBox - unn | UNITED NEWS NETWORK GmbH

FIS Informationssysteme und Consulting GmbH

* Ivan Novikov ist CEO und Vorsitzender von Wallarm, einem Anbieter von KI-gestützter Anwendungssicherheit.

Ende Mai findet in Barcelona die größte KubeCon-Konferenz bis dato statt. Dabei liegt ein thematischer Schwerpunkt auf DevOps-Prozessen und verteilten, Microservice-basierten Anwendungen. Eben diese Umgebungen einschließlich ihrer Cloud-basierten Zielsysteme und flexiblen Infrastrukturen machen die Sicherheit aber viel komplizierter.

Will man DevSecOps in diesen neuen Microservices-Landschaften umsetzen, geht es um nicht weniger als die Integration von Sicherheitsphilosophien und -prozessen in DevOps-Praktiken. Führt man sich vor Augen, dass APIs und Container sowie Kubernetes bei der Anwendungsbereitstellung über hochperformante CI/CD-Pipelines eine immer größere Rolle spielen, wird schnell klar, dass die Sicherheit mehr von dieser DevOps-Integration abhängt als von den jeweiligen Toolsets.

DevSecOps ist also mehr als ein Modewort von Unternehmen für Unternehmen. Als Kombinationsbegriff spiegelt DevSecOps die gegenseitige Abhängigkeit der Verantwortlichkeiten wieder, um Sicherheit von einem festen Satz unflexibler Tools hin zu einem umfassenden Prozess als solchen zu transformieren.

Was sind also die Herausforderungen, die verhindern, dass ein Unternehmen eine DevSecOps-Philosophie nachhaltig verfolgen kann? Und wie können Unternehmen diesen Herausforderungen begegnen?

Sicherheit kann ein ganz natürlicher Teil von DevOps sein

Sicherheitstests lassen sich leicht in die Testphase jeder Integration oder Bereitstellung integrieren. Der Return on Invest mag nicht immer so offensichtlich sein, wie er nach einer Sicherheitsverletzung oder einem Programmcode-Problem ist, doch der Blick zurück ist auch nicht gerade viel wert. Weil eine Integration an jedem Punkt möglich ist, warum optimieren wir dann nicht auf dieses Ziel hin?

Sicherheit neu denken und die Codequalität verbessern

Wie wir in puncto Sicherheit denken, ist ein enormes Hindernis für DevSecOps. Für die meisten ist die unmittelbare Wertschöpfung nicht leicht zu erkennen. Stattdessen wird Sicherheit oft damit gleichgesetzt, Zeit und Ressourcen für ein „Was wäre wenn“-Untergangsszenario zu opfern, wenn nicht gar zu verschwenden.

Sicherheit bietet aber einen beträchtlichen positiven Wert, wenn wir unser Verständnis auf das Testen ausweiten. Das muss nicht bis zur Bereitstellung warten oder auf Anwendungsprüfungen beschränkt sein. Die umfassendsten Sicherheitsprüfungen lassen sich an und in der gesamten Umgebung vornehmen.

Durch das Testen während des gesamten CI/CD-Lebenszyklus sind Teams Sicherheitsproblemen einen Schritt voraus und helfen, die Qualität des Programmcodes zu verbessern. Kontinuierliche Tests können sich wiederholende und systemische Probleme ermitteln.

Beispielsweise könnte fehlerhafter Code, der zu spät identifiziert wird, zu Lieferproblemen führen. Durch das Erkennen wiederkehrender Probleme außerhalb von Bibliotheken lassen sich Zyklen schaffen, die einen besseren Überblick über neuen Input geben, was letztendlich die Codequalität verbessert. Firmenspezifische Probleme lassen sich identifizieren und beheben, bevor sie überhaupt auftreten.

Die wirkliche Transformation von DevOps zu DevSecOps liegt also im Umstieg von Sicherheit „von der Stange“ auf die Sichereheitsprozess-gestütze Kompetenzbildung bei den Entwicklern. Auf technischer Ebene hat der Entwickler zunächst einmal keinen Grund, Anwendungen zu testen, bevor neuer Code eingepflegt wird. Dies erfolgt nur, wenn die Geschäftsprozesse Entwickler dabei unterstützen, Sicherheit als Primär-KPI zu etablieren.

Sicherheit für ihren Teil kann mit Richtlinien dafür sorgen, dass Entwickler Tests für ihre Anwendungen generieren und Probleme vor dem Release korrigieren. Operations sollte die Entwicklung dabei unterstützen, Anwendungen in jeder Entwicklungsphase zu testen, entsprechende Workflows und Prozesse festzulegen und Anwendungen erst nach Abschluss der Testphase freizugeben.

Entwickler und Sicherheitsabteilung arbeiten zusammen

Anhand der Kurzlebigkeit und hohen Geschwindigkeit des Lebenszyklus der kontinuierlichen Integration und Bereitstellung (CI/CD), haben sich Entwicklungs- und Betriebsteams in vielen Unternehmen zu einem kombinierten Team, DevOps, weiterentwickelt. Gemeinsam verwalten und unterstützen sie die CI/CD-Systeme in einer intuitiven, starken Symbiose.

Wenn nur durch wenige Minuten getrennt mehrere Bereitstellungen erfolgen, ist es oft schwierig, für Funktionstests Platz zu schaffen. Wenn Sicherheit ein Teil der DevOps sein soll, muss es sich um Sicherheit als Prozess (Security as a Process) handeln, die von der Operations-Abteilung unterstützt und von Entwicklern als Teil ihres gemeinsamen CI/CD-Workflows umgesetzt wird.

Vier Schritte zur Entwicklung von DevSecOps

Leider ist die Zeit meist zu knapp, um alles umzusetzen, was der Sicherheit zuträglich ist. Deshalb ist es so wichtig, zu automatisieren und zu verstehen, wie man gemäß der jeweils eigenen Geschäftslogik priorisiert werden sollte.

Es ist unmöglich, alle bekannten Tests und Varianzen umzusetzen und dann die Ergebnisse hunderttausender von Anforderungen zu generieren und zu analysieren. Um den CI/CD-Timelines zu entsprechen, muss das Testing in wenigen Stunden oder höchstens bei der nächtlichen Build-Erstellung erfolgen – einschließlich der Durchführung von Funktions-, Sicherheits- und aller anderen Tests.

Die richtige Planung sowie zugehörige Prozesse, Tools und die offensichtliche Umsetzung von Security-as-a-Process helfen, Sicherheit in DevSecOps zu realisieren. Auf der folgenden Seite finden Sie einen grundlegenden Überblick über Ihre Möglichkeiten.

(ID:45930163)