„Best Practices“ in Sachen Sicherheit mit DevOps

Wie DevOps die Sicherheit erhöhen kann

Carsten Eilers

© Shutterstock.com / Maksim Kabakou

In DevOps steht bekanntlich das „Dev“ für Development und das „Ops“ für Operations, also Entwicklung und Betrieb. Sicherheit kommt darin nicht vor, obwohl sie doch so wichtig ist und sich gerade mit DevOps verbessern lässt, wenn man das denn möchte.

In der Theorie ist das Problem „sichere Entwicklung der Software“ seit der Entwicklung des Security Development Lifecycle (siehe: Eilers, Carsten: „Microsoft Security Development Lifecycle“, in Windows Developer 4.2012) durch Microsoft eigentlich gelöst, und da zu dessen „Best Practices“ unter anderen die beiden Punkte „Secure by default“ (die Standardeinstellungen werden so sicher wie möglich gewählt) und „Secure by deployment“ (das fertige Programm wird so ausgeliefert, dass es möglichst sicher installiert wird) gehören, ist auch das Problem „Sicherer Betrieb der Software“ eigentlich keines mehr. Und wenn sowohl Entwicklung als auch Betrieb sicher sind, dann auch beides zusammen in Form von DevOps. Es gibt also gar keinen Grund, sich darüber Gedanken zu machen. Oder?

Von der Theorie in die Praxis

Das Problem ist  – wie so oft – die Umsetzung der Theorie in die Praxis. Denn was theoretisch wunderbar funktioniert, tut es in der Praxis eher selten. Eine Ursache dafür ist die Kommunikation zwischen Softwareentwicklung und (IT-)Betrieb. Traditionell sind diese Bereiche mehr oder weniger strikt getrennt. Was zum Beispiel im Fall von Microsoft und seinen Kunden (wenn man einmal den Spezialfall Azure ausklammert) auch gar nicht anders möglich ist. Aber hier geht es ja um DevOps und damit im Allgemeinen um die Fälle, in denen sich Entwicklung und Betrieb unter einem Dach befinden (zumindest organisatorisch).

Trotzdem kommt es immer wieder vor, dass die Software zwar korrekt installiert wird (jedenfalls aus Sicht der Entwickler), aber trotzdem nicht so funktioniert wie vorgesehen. Oder dass die Informationen über die Installation unvollständig sind, Konfigurationsänderungen an anderen Systemen nicht berücksichtigt wurden etc. Das führt dazu, dass die Administratoren selbst herausfinden müssen, was wie installiert bzw. konfiguriert werden muss, bevor sie die Software in Betrieb nehmen können.

In der Gegenrichtung gilt Ähnliches: Da die Entwickler im Allgemeinen keinen Zugriff auf die Produktivsysteme haben und ihre Entwicklungs- und Testsysteme von diesen mehr oder weniger stark abweichen, können sie nur anhand von Fehlermeldungen und -beschreibungen prüfen, was im Fehlerfall nicht richtig funktioniert hat.

DevOps betritt die Bühne

Wenn die Entwickler produktiv genug sind, die ständig neuen Softwareversionen zu veröffentlichen, kommt es zum sprichwörtlichen Knall – die Administratoren kommen mit der Installation der neuen Versionen nicht mehr nach, und vor lauter Arbeit wird die Kommunikation deutlich erschwert.

An diesem Punkt setzt bekanntlich das DevOps-Konzept an: Indem Kommunikation, Zusammenarbeit und Integration zwischen Softwareentwicklung und IT-Betrieb verbessert werden, wird die Trennung zwischen beiden Bereichen reduziert oder sogar ganz aufgehoben.
Insbesondere die Softwareverteilung bzw. das Deployment werden dabei weitestgehend automatisiert und zu einem zuverlässigen, wiederholbaren Prozess. Außerdem wird die Qualität der Software laufend überwacht, und alle Beteiligten sollen verstärkt miteinander kommunizieren.

Kontinuierliche Kommunikation

Im Grunde wird bei DevOps der herkömmliche Entwicklungszyklus für Software (Definition der Anforderungen, Entwicklung, Test, Qualitätssicherung, Deployment, Betrieb und Wartung) beibehalten, aber um eine kontinuierliche Kommunikation und Zusammenarbeit der Beteiligten erweitert. Während bei der herkömmlichen Entwicklung lediglich die (Zwischen-)Ergebnisse nach jedem Schritt an den nächsten weitergegeben werden und in mehr oder weniger unregelmäßigen Abständen Abstimmungen zustande kommen, gibt es bei DevOps kontinuierliches Feedback bezüglich der aktuellen Änderungen, das in die weitere Entwicklung bzw. den Betrieb einfließt.

DevOpsCon Istio Cheat Sheet

Free: BRAND NEW DevOps Istio Cheat Sheet

Ever felt like service mesh chaos is taking over? Then our brand new Istio cheat sheet is the right one for you! DevOpsCon speaker Michael Hofmann has summarized Istio’s most important commands and functions. Download FOR FREE now & sort out your microservices architecture!

Außerdem werden möglichst viele Aufgaben automatisiert, um menschliche Fehler zu reduzieren und die Qualität und Konsistenz der Ergebnisse zu verbessern.

Fallstricke

Aus Sicherheitssicht sind diese zusätzliche Kommunikation sowie die Automatisierungen erst einmal zu begrüßen. Beides reduziert die Gefahr von Fehlern und damit möglichen Schwachstellen. Allerdings gibt es auch einige Fallstricke. Zum Beispiel, weil Entwickler bei DevOps häufig Schreibrechte für die Produktivsysteme erhalten oder die Entwickler der Automatisierungstools durch diese Tools oft höhere Benutzerrechte erhalten als für Entwickler eigentlich benötigt.

Zunächst einmal wird so die Gefahr erhöht, dass ein bösartiger Mitarbeiter Schaden anrichtet. Oder, was sehr viel wahrscheinlicher ist, dass ein Angriff auf die Entwicklungsabteilung direkte Auswirkungen auf die Produktivsysteme hat. Und das muss nicht einmal ein Geheimdienst sein, der die neuesten Entwicklungen ausspähen oder Kundendaten kopieren möchte. Es reicht schon ein herkömmlicher Angriff durch Schadsoftware, die Daten löscht oder verschlüsselt. Eine Infektion mit Ransomware, die sämtliche Daten der Entwicklungsabteilung verschlüsselt, lässt sich durch das Einspielen der vorhandenen Backups problemlos kurieren, ohne größere Auswirkungen auf den Rest des Unternehmens zu verursachen. Aber was ist, wenn Daten der Produktivsysteme durch die Verschlüsselung der Ransomware zeitweise nicht erreichbar sind oder womöglich verloren gehen, weil es für einige Daten noch kein Backup gab? Der Ransomware ist es egal, was sie verschlüsselt – alle mit den Rechten des aktuellen Benutzers erreichbaren Dateien bestimmter Typen werden durch verschlüsselte Kopien ersetzt.

Ein weiterer Risikofaktor sind die häufigen Änderungen an der Software. Diese müssen ausgiebig getestet werden, damit sie auf den Produktivsystemen nicht zu Fehlern oder womöglich Schwachstellen führen. Da die Zyklen für die Softwareverteilung durch die häufigen Änderungen bei DevOps deutlich kürzer sind, besteht die Gefahr, dass bei den Funktionstests und den Qualitätssicherungsmaßnahmen Einschränkungen auftreten, die sich auf das Ergebnis auswirken. Man könnte zum Beispiel dazu übergehen, lediglich den geänderten Code zu prüfen – und übersieht dadurch womöglich eine Schwachstelle, die erst im Zusammenspiel mit dem bisherigen Code auftritt. Zum Beispiel, weil ein Parameter im alten Code nicht initialisiert wird, er im neuen Code aber als initialisiert betrachtet wird. Oder weil der neue Code eine Benutzereingabe entgegennimmt und ungeprüft an eine alte Funktion weitergibt, die davon ausgeht, dass die Eingaben geprüft und vertrauenswürdig sind. Solche Fehler, die schnell zu Schwachstellen führen, passieren schon bei der herkömmlichen Entwicklung. Wie groß ist da die Gefahr, dass sie unter Zeitdruck nicht bemerkt werden?

Denn ganz allgemein besteht das Risiko, dass DevOps zu Zeitdruck führt. Und dem fallen schnell Tests zum Opfer, deren Ergebnis „ja sowieso bekannt“ ist oder die für weniger wichtig gehalten werden. Wie eben gerade Schwachstellentests oder auch Härtungsmaßnahmen, die mit der eigentlichen Funktion des Codes nichts zu tun haben. Die Software funktioniert auch mit Schwachstellen. So lange, bis jemand sie für einen Angriff ausnutzt.

Als weiterer Risikofaktor werden mitunter die durch DevOps geänderten Tools und Entwicklungsumgebungen genannt, mit denen die Entwickler zumindest anfangs nicht richtig umgehen können. Das sehe ich persönlich etwas anders. Mit jedem Tool muss man sich vertraut machen, bevor man optimal damit arbeiten kann. Ob das nun im Rahmen einer herkömmlichen Entwicklung geschieht oder im Rahmen von DevOps, ist egal. Bei DevOps ist lediglich die Gefahr größer, dass Fehler während der Entwicklung auf den Betrieb durchschlagen. Aber um das zu verhindern, sollten die ohnehin durchgeführten Tests etc. ausreichen. Ob ein Fehler nun seine Ursache in einer Fehlbedienung einer neuen Entwicklungsumgebung oder in einer falschen Entscheidung eines Entwicklers hat, ist für das Endergebnis egal – der Fehler muss bei Tests entdeckt und korrigiert werden.

DevOps in Sachen Sicherheit

DevOps bietet die Möglichkeit, die Sicherheit in einigen Punkten zu verbessern:

  • Kontrolle: Bei DevOps gibt es viele und meist kleine Änderungen an der Software anstelle von seltenen, aber großen Änderungen bei der herkömmlichen Entwicklung. Sofern man nicht den Fehler macht, die ausführlichen Tests zu weit zu reduzieren, bietet diese „Kleinteiligkeit“ auch einen großen Vorteil: Ein Fehler hat meist nur geringe Auswirkungen auf die Stabilität und Verfügbarkeit der Produktivsysteme, und je eher Fehler entdeckt werden, desto einfacher können sie korrigiert werden. Informationen über einige der Risiken, die im Rahmen von DevOps auftreten können, sowie mögliche Gegenmaßnahmen durch entsprechende Kontrollen wie Sicherheits- und Funktionsvalidierung des Codes, finden Sie in: DeLuccia IV, James; Gallimore, Jeff; Kim, Gene; Miller, Byron: „DevOps Auditor Defense Toolkit“.
  • Nachvollziehbarkeit: Viele DevOps-Tools protokollieren die Änderungen sehr umfangreich, sodass sich jederzeit nachvollziehen lässt, wer was wann getan oder veranlasst hat. Das vereinfacht Audits, da sich verdächtige Änderungen leicht nachvollziehen lassen.
  • Transparenz: Die ständige Rückkopplung zwischen den einzelnen Schritten der Softwareentwicklung und des Betriebs und die enge Zusammenarbeit zwischen allen Beteiligten führen zu einer hohen Transparenz. Dadurch kann auf Abweichungen schneller reagiert und Schwachstellen oder allgemein Sicherheitsverletzungen können leichter aufgedeckt werden.

Fazit

Die Einführung von DevOps kann die Sicherheit reduzieren, muss es aber nicht. Ganz im Gegenteil: wenn man die Vorteile von DevOps nutzt, lässt sich die Sicherheit sogar erhöhen. Inwiefern, ist abhängig von den individuellen Umgebungen.

Vereinfacht müssen Sie bei der Einführung von DevOps „nur“ darauf achten, dass die vorhandenen Sicherheitsprozeduren auf DevOps übertragen werden. Und dass so wenige Sicherheitsbarrieren wie möglich auf der Strecke bleiben. Alle werden sich nicht aufrechterhalten lassen, wenn Entwicklung und Betrieb zusammen wachsen sollen. Allerdings sollte man darauf achten, bei allen Änderungen auch immer alle dadurch entstehenden Risiken zu berücksichtigen.

Niemand würde eine Brandmauer zwischen zwei Brandabschnitten im Gebäude einreißen, nur weil an einer Stelle ein Durchgang benötigt wird. Eine Brandschutztür reicht dafür aus. Und das gleiche gilt im übertragenen Sinne für die Firewall und sonstigen Schutzmaßnahmen zwischen Entwicklungs- und Produktivsystemen. Denken Sie einfach immer daran, dass alles, was schief gehen kann, auch schief gehen wird. Dafür sorgt nicht nur Murphys Gesetz, sondern im Zweifelsfall auch ein Cyberkrimineller, der es auf Ihre Daten etc. abgesehen hat.

Aufmacherbild: Security concept: blue opened padlock via Shutterstock.com / Urheberrecht: Maksim Kabakou

Verwandte Themen:

Geschrieben von
Carsten Eilers
Carsten Eilers
Dipl.-Inform. Carsten Eilers ist freier Berater und Coach für IT-Sicherheit und technischen Datenschutz und Autor einer Vielzahl von Artikeln für verschiedene Magazine und Onlinemedien. Sie erreichen ihn unter www.ceilers-it.de, sein Blog finden Sie unter www.ceilers-news.de.
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
4000
  Subscribe  
Benachrichtige mich zu: