Während meiner beruflichen Tätigkeit als Cybersecurity-Experte und IT-Architekt stoße ich oft auf Bedenken von Teams, die DevOps praktizieren, wenn ich über Cybersicherheit spreche. Ebenso höre ich häufig Verweise auf DevSecOps als Lösung, um Sicherheit in ihren Ansatz zu integrieren.
Daher habe ich mich entschieden, diesen Artikel zu schreiben, um zu erklären:
- Was DevOps wirklich ist, da viele Teams den Begriff falsch verstehen und ihn eher als Trendwort nutzen.
- Wie Sicherheit aussehen sollte, wenn DevOps ernst genommen wird.
- Warum eine Ableitung wie „DevSecOps“ nicht existiert, sondern eher ein Buzzword ist – oft als Ausrede für mangelndes Bewusstsein für Cybersicherheit oder als bequemer Weg, DevOps halbherzig umzusetzen.
Viel Spaß beim Lesen!
Was ist DevOps?
Aus einer logischen Perspektive betrachtet, ist DevOps genau das, was die beiden kombinierten Begriffe Development („Dev“) und Operations („Ops“) ausdrücken. Es vereint zwei ehemals getrennte Teams in einem Ansatz, um Effizienz zu steigern und Reibungen zwischen den Teams zu reduzieren.
Im Internet gibt es viele Definitionen für den Begriff DevOps, doch die meisten beschreiben ihn als mehr als nur die Zusammenführung zweier Teams. DevOps umfasst:
- Kulturelle Philosophien,
- Praktiken und
- Tools,
mit dem Ziel, die Fähigkeit einer Organisation zu erhöhen, Anwendungen und Services mit hoher Geschwindigkeit bereitzustellen. Diese Formulierung lehnt sich an die Definition von Amazon AWS für DevOps an.
Lassen wir uns nun anschauen, wie diese Kultur definiert ist und welche Prinzipien innerhalb eines DevOps-Ansatzes angewendet werden.
Die DevOps-Kultur
Manche DevOps-Evangelisten bezeichnen DevOps als eine Art Religion. Auch wenn diese Sichtweise vielleicht übertrieben ist, lebt DevOps doch von einer einzigartigen Kultur. Schauen wir uns die wesentlichen Merkmale dieser Kultur an.
Alles, was das Team tut, dient dazu, das Kundenerlebnis zu verbessern.
Klingt logisch – schließlich sollte ein Produkt dem Kunden einen Nutzen bieten. In der Realität entwickeln sich Projekte jedoch oft in andere Richtungen, weil:
- Teammitglieder zu technisch fokussiert sind,
- Anforderungen falsch interpretiert werden, oder
- eine „Das haben wir schon immer so gemacht“-Mentalität vorherrscht.
Im DevOps-Ansatz steht der Kunde explizit im Mittelpunkt jeder Aktivität. Man entwickelt immer mit dem Endziel vor Augen. Deshalb muss eine enge Verbindung zwischen Business und Kunde bestehen, um deren Bedürfnisse optimal zu erfüllen.
Nebenbemerkung: Genau aus diesem Grund halte ich Begriffe wie „BizDevOps“ für überflüssig – denn in DevOps ist bereits impliziert, dass man eng mit dem Business zusammenarbeitet.
Es gibt keine Silos oder Schuldzuweisungen – das Team trägt die Verantwortung als Ganzes.
In getrennten Teams gibt es oft die Tendenz, anderen die Schuld zuzuschieben, wenn etwas nicht funktioniert. Das gilt besonders für klassische Entwicklungs- und Betriebsteams.
Die DevOps-Kultur bekämpft dieses Problem, indem sie End-to-End-Verantwortung für Services festlegt:
- Ein Team ist für einen Service verantwortlich.
- Wenn etwas schiefläuft, ist das gesamte Team verantwortlich.
- Wer etwas baut, besitzt es auch („You build it, you own it“).
Das bedeutet, dass DevOps-Teams autonom und funktionsübergreifend arbeiten. Innerhalb des Teams geht es um Kompetenzen, nicht um klassische Rollen.
Teams experimentieren und suchen nach Verbesserungen – sie scheitern schnell oder lernen schnell.
Ein zentrales Ziel eines DevOps-Teams ist die kontinuierliche Verbesserung.
- Alles, was automatisiert werden kann, wird automatisiert.
- Teams experimentieren ständig mit neuen Methoden, um schneller und effizienter Wert zu liefern.
- Risiken werden bewusst eingegangen, aber Fehler werden schnell erkannt, korrigiert und das Gelernte wird mit dem Team geteilt.
- Feedback wird nicht als Kritik, sondern als wertvolle Gelegenheit zur Verbesserung betrachtet.
Ein DevOps-Team ist die Verkörperung einer Growth-Mindset-Kultur. 🚀
Die Sicht auf Sicherheit im DevOps-Ansatz und warum es kein DevSecOps gibt
Zunächst sollten wir klären, wo Sicherheit innerhalb der Entwicklung und des Betriebs eines Services positioniert wird. Der Erfolg eines Services hängt von seiner Qualität ab, die durch Anforderungen definiert wird. Normalerweise werden die Anforderungen an einen Service zu Beginn eines Projekts festgelegt.
- Funktionale Anforderungen sind Anforderungen, die der Endbenutzer explizit fordert – sie definieren die grundlegenden Funktionen, die ein System bieten soll. Diese Anforderungen sind für den Endbenutzer oft sichtbar.
- Nicht-funktionale Anforderungen sind Rahmenbedingungen, die ein System erfüllen muss, damit ein Service zufriedenstellend genutzt und betrieben werden kann. Diese Anforderungen sind für den Endbenutzer meist nicht sichtbar und umfassen Wartbarkeit, Verfügbarkeit, Performance, Flexibilität und Sicherheit.
Ein Beispiel:
Wenn ein Service die Anforderungen an Verfügbarkeit, Vertraulichkeit oder Integrität nicht erfüllt (alle drei gehören zu den Sicherheitsanforderungen), dann sind die nicht-funktionalen Anforderungen nicht erfüllt.
Sicherheit ist ein integraler Bestandteil nicht-funktionaler Anforderungen
Da Anforderungen die Servicequalität definieren, ist Sicherheit ein natürlicher Bestandteil dieser Anforderungen.
Warum sollte man Sicherheit dann anders behandeln als andere Qualitätsaspekte?
Per Definition gibt es kein DevOps ohne Sicherheit.
Das bedeutet, es gibt auch keinen Grund, „DevSecOps“ als neues Buzzword zu definieren.
Warum fehlt oft die richtige Sicherheitsintegration?
Ein wichtiger Punkt:
Auch wenn ein DevOps-Team End-to-End-Verantwortung trägt, werden die Anforderungen (einschließlich Sicherheit) oft von externen Stakeholdern definiert.
- Der Begriff „DevSecOps“ wird oft als Ausrede für mangelndes Sicherheitswissen oder fehlende Motivation zur Implementierung von Sicherheit verwendet.
- Ein fehlendes Sicherheitsteam, das Sicherheitsanforderungen definiert, kann jedoch ebenfalls Teil des Problems sein.
- Idealerweise werden Anforderungen von einer Sicherheitsabteilung definiert und anschließend mit dem DevOps-Team diskutiert, abgestimmt und angepasst, damit sie für alle Beteiligten sinnvoll sind.
Sicherheit ist die Aufgabe aller und muss gemeinsam erarbeitet werden – besonders innerhalb eines DevOps-Ansatzes. 🚀
Sicherheitsverantwortlichkeiten eines DevOps-Teams
Da DevOps-Teams stark auf Automatisierung setzen und häufig Cloud-Technologien nutzen, höre ich oft, dass Sicherheit im DevOps-Umfeld völlig anders funktioniert oder dass bestimmte Sicherheitskontrollen nicht anwendbar seien, weil sie das Team in seiner Geschwindigkeit einschränken.
Ja, Schnelligkeit ist ein zentrales Element der DevOps-Kultur, aber schnell zu sein bedeutet nicht, essenzielle Aufgaben auszulassen, um Zeit zu sparen.
Sicherheitsprinzipien wie Least Privilege, Zero Trust oder Separation of Duties gelten auch für DevOps-Teams – eventuell in einer anderen Implementierungsform (z. B. Infrastructure as Code, Software Defined Firewalling), aber sie bleiben bestehen. Auch Sicherheitstests müssen genauso durchgeführt werden wie andere Qualitätsprüfungen – denn Sicherheit ist ein Teil der Qualität.
Wichtige Sicherheitsverantwortlichkeiten eines DevOps-Teams
Hier sind einige essenzielle Sicherheitsverantwortlichkeiten, die aus betrieblicher Sicht für DevOps-Teams gelten:
- Identity & Access Management
- Logging, Monitoring & Alerting
- Konfigurationsmanagement
- Patch-Management
- OS-Image-Management
- Backup
- Asset-Management
- Service-Management
- Compliance-Management (Einhaltung von Unternehmens-, IT- und Sicherheitsrichtlinien sowie gesetzlichen Vorgaben)
Diese Liste erscheint zunächst umfangreich, aber viele Unternehmen haben erfolgreich DevOps umgesetzt, indem sie ein zentrales Plattform-Team etabliert haben.
Die Rolle eines zentralen Plattform-Teams
Ein zentrales Plattform-Team stellt eine einheitliche Plattform bereit, die andere DevOps-Teams für ihre Projekte nutzen können.
Typischerweise übernimmt das Plattform-Team alle Verantwortlichkeiten bis auf OS-Level, sodass sich die einzelnen DevOps-Teams auf projektspezifische Aufgaben konzentrieren können.
Zusätzlich zu den oben genannten Sicherheitsverantwortlichkeiten kümmert sich das Plattform-Team um:
- Definition von Plattform-Standards gemäß Unternehmensrichtlinien und gesetzlichen Vorgaben
- Implementierung von Sicherheitsleitplanken und Compliance-Monitoring, um sicherzustellen, dass Projekte konform bleiben
- Plattform-Provisionierung
- Integration neuer Umgebungen
- Strategische Weiterentwicklung der Plattform
Vorteile eines zentralen Plattform-Teams für DevOps-Sicherheit
✅ Projektbezogene DevOps-Teams bleiben schnell, da viele Sicherheitsverantwortlichkeiten zentral geregelt sind.
✅ Standardisierte Sicherheits- und Compliance-Vorgaben erleichtern die Einhaltung von Vorschriften.
✅ DevOps-Teams können sich auf ihre Kernaufgaben konzentrieren (z. B. Testing, Service-Monitoring).
Fazit: Sicherheit ist ein fester Bestandteil von DevOps – ein gut strukturiertes Plattform-Team kann helfen, Geschwindigkeit und Sicherheit in Einklang zu bringen. 🚀
Zusammenfassung
DevOps ist ein großartiger Ansatz, der Projekten viele Vorteile bietet – insbesondere durch die DevOps-Kultur, die sich durch End-to-End-Verantwortung, hohe Automatisierung und kundenorientierte Aktivitäten auszeichnet.
Leider wird Sicherheit oft nicht als Teil von DevOps betrachtet, obwohl dieser Ansatz perfekt geeignet wäre, um exzellente Sicherheitsstandards zu erreichen.
Da Sicherheit keine separate Disziplin, sondern ein wesentlicher Bestandteil der Produktqualität ist, sind Begriffe wie DevSecOps unangebracht.
Sicherheitsrelevante Verantwortlichkeiten können zentral in einem dedizierten Plattform-Team gebündelt werden, um Effizienz und Sicherheit optimal zu vereinen. 🚀
