DevOps – Wundermittel oder Risiko?

Effizienteres Arbeiten und die Optimierung der operativen Abläufe sind derzeit mehr denn je die Ziele jedes Unternehmens.

In der IT-Branche wurde vor ziemlich genau zehn Jahren damit begonnen, dass die Aufgaben von Software-Entwicklern (Developer) und Administratoren (IT Operation) zusammengeführt wurden. Administrative und softwarebasierte Tätigkeiten wurden so vereint – der Beruf des DevOp Engineers war geboren.

Er ist ein Tausendsassa: Er entwirft Skripts sowie Entwicklungstools und programmiert nicht nur agile Software, sondern testet auch Geräte, verwaltet digitale Zertifikate oder ist für das Monitoring von Servern zuständig. Er kümmert sich auch um die häufigen kleinen Updates und nutzt dabei eine Microservice-Architektur, durch die große, komplexe Systeme in kleine, unabhängige Systeme unterteilt werden.

DevOps Engineers werden mit Java, Python, Ruby und PHP konfrontiert

Sie brauchen außerdem Kenntnisse in verschiedenen Serversystemen auf Windows, Mac und Linux und müssen mit Open-Source-Technologien und -Tools umgehen können. Auch mit Sicherheitskonzepten müssen sie sich auskennen. Hier gibt es sogar schon eine Erweiterung des Begriffes: DevSecOps. Anders als die Sicherheitsteams früher testen sie neue Applikationen nicht erst nach deren Fertigstellung auf Sicherheitslücken, sondern sind von Anfang an schon dazu in der Lage, auch die Sicherheitsaspekte in die Entwicklung einzubinden.

Was früher zwei oder drei Mitarbeiter inhaltlich geleistet und gelernt haben, liegt nun in der Verantwortung eines einzelnen, der auch das entsprechende Rundum-Wissen mitbringen muss.

Zwei ehemals isoliert arbeitende Unternehmensbereiche wurden dadurch zusammengeführt, Prozesse und Systeme wurden komprimiert, sodass eine bessere Koordination sowie eine höhere Qualitätssicherung möglich werden sollte. Auch die Reaktionszeiten auf veränderte Entwicklungsprozesse sollten dadurch kürzer werden. Angestrebt wird insgesamt eine effizientere Zusammenarbeit der Bereiche Development, Operations und Qualitätssicherung.

Doch in der Branche ist DevOps mehr als das.

Es ist eine Philosophie, eine Kultur, in der es in erster Linie um die Zusammenarbeit der Entwickler und erst im zweiten um Organisatorisches geht. John Willis, einer der Vorreiter der Bewegung, gibt fünf Grundprinzipien für diese Management-Strategie vor:

• Culture – sie beinhaltete gegenseitiges Vertrauen, ständigen Informationsfluss und hohe Lernbereitschaft
• Automation – die Automatisierung bestimmter Arbeitsvorgänge
• Lean – Verschwendung soll vermieden werden; Wert, Transparenz und ganzheitliche Prozessoptimierung sollen generiert werden
• Measurement – einheitliche Bewertungskriterien
• Sharing – die Bereitschaft, Wissen zu teilen, voneinander zu lernen und Erkenntnisse proaktiv mitzuteilen

Um die Vorteile des DevOps-Konzepts realisieren zu können, müssen innerhalb der Unternehmen Strukturen verändert werden. Wie das am besten geschieht, dafür gibt es genaue Anleitungen. Auch die Verantwortungen müssen angepasst werden, die Mitarbeiter sollen in möglichst viele Entscheidungsprozesse eingebunden werden. Notfalls sollen Mediatoren eingesetzt werden, die zwischen den Seiten vermitteln.

Doch nicht alles ist Gold, was glänzt.

So gibt es Unternehmen, bei denen das Management mit der Umsetzung des kulturellen Teils Probleme hat. Oft ist die Ausbildung der Mitarbeiter nicht ausreichend, um auch wirklich allen Anforderungen – Software-Programmierung, Administration und Sicherheit – gleichermaßen gewachsen zu sein.

"Das Konzept DevOps kann nur in sehr großen Einheiten funktionieren", ist Philipp Kobel von toscom überzeugt. "Das heiß nämlich nicht, ein Entwickler macht alles – in kleinen Firmen wird das aber oft so gehandhabt."

Eigentlich ginge es um Geschwindigkeit – tatsächlich umgesetzt werde die Idee aber wohl oft zur Einsparung der Operation-Mitarbeiter. "Das verstehe ich als Fehlinterpretation." Oft würden die Webentwickler das auch gar nicht wollen – 24/7-Dienste oder Monitoring. Viel lieber würden sie neue Software schreiben. "Sie wollen keine DevOps sein, sondern Developer-Heroes."

Das ursprüngliche Konzept spreche von einer engen Zusammenarbeit, nicht davon, dass einer alles macht, so Kobel. "Spezialisierung ist immer besser, nicht schwächer." Denn gerade auch aus der Sicherheitsperspektive kann das Konzept der DevOps durchaus ein Risiko darstellen. So darf die Trennung zwischen Software-Entwicklung und IT-Betrieb nicht komplett aufgehoben werden, um nicht eventuell gegen Compliance-Vorgaben wie etwa PCI-DSS und ISO 27001 (Zertifizierung auf Basis von IT-Grundschutz) zu verstoßen.

DevOps bekommen jedenfalls auch einen sehr großen Vertrauensvorschuss:

Als Entwickler erhalten sie meist Schreibrechte auf Produktionssysteme, wodurch sie leicht die Gelegenheit haben, die entsprechende Software für Betrugsversuche zu missbrauchen. Ein Nachweis fällt schwer – können Sie doch ihre Spuren und die zugehörigen Protokolle auch gleich selbst löschen. Das wird auch durch die hohe Automatisierung nicht verhindert.

Da es keine Trennung mehr zwischen der Software-Entwicklung und dem IT-Betrieb gibt, werden bei DevOps auch die Sicherheitsbarrieren reduziert. Hier haben Entwickler auch Berechtigungen in der Produktiventwicklung – auch ein Angreifer kann daher leichter darauf zugreifen.

Auch unabsichtliche Fehler im Programmcode können lange unerkannt bleiben, da die Zyklen für die Softwareverteilung grundsätzlich deutlich kürzer sind. So können die Funktionstests und die Maßnahmen zur Qualitätssicherung stark reduziert werden, sodass es wahrscheinlicher wird, dass Fehler lange übersehen werden. Bei starkem Zeitdruck, der durch die verlangte hohe Umsetzungsgeschwindigkeit entsteht, können Schwachstellenscans oder Härtungsmaßnahmen vernachlässigt werden.

Auch könnten DevOps Sicherheitstests für unnötig halten, wenn sie ohnehin immer nur mehrere kleinere Änderungen vornehmen – unbeachtet dessen, dass dadurch neue Schwachstellen entstehen können.