DevOps-Sicherheit, Teil 2: Fallstricke und Vorteile
Wie es mit der sicheren Entwicklung in Theorie und Praxis aussieht, sowohl Allgemein als auch im Fall von DevOps, habe ich bereits im ersten Teil beschrieben. DevOps führt zu zusätzlicher Kommunikation zwischen Entwicklung und Betrieb, außerdem werden möglichst viele Aufgaben automatisiert, um menschliche Fehler zu reduzieren und die Qualität und Konsistenz der Ergebnisse zu verbessern.
Vorsicht, Gefahr!
Aus Sicherheitssicht sind diese zusätzliche Kommunikation sowie die Automatisierungen erst mal zu begrüßen. Beides reduziert die Gefahr von Fehlern und damit möglichen Schwachstellen. Es gibt aber auch einige Fallstricke. Zum Beispiel, weil bei DevOps die Entwickler oft Schreibrechte für die Produktivsysteme erhalten oder die Entwickler der Automatisierungstools durch diese Tools oft höhere Benutzerrechte erhalten als sie sie als Entwickler eigentlich bräuchten.
Erst mal erhöht dass Allgemein die Gefahr, 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 dass muss nicht mal 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 ja hoffentlich vorhandenen Backups problemlos kurieren ohne größere Auswirkungen auf den Rest des Unternehmens zu haben.
Aber was ist, wenn Daten der Produktivsysteme durch die Verschlüsselung durch die Ransomware zeitweise nicht erreichbar sind oder womöglich verloren gehen, weil es für einige Daten noch kein Backup gab? Oder wenn die Schadsoftware auch Rechner infiziert, die für die Steuerung der Produktion benötigt werden? 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. Die müssen ausgiebig getestet werden, damit sie auf den Produktivsystemen nicht zu Fehlern oder womöglich Schwachstellen führen. Da bei DevOps die Zyklen für die Softwareverteilung durch die häufigen Änderungen deutlich kürzer sind besteht die Gefahr, dass es bei den Funktionstests und den Qualitätssicherungsmaßnahmen zu Einschränkungen kommt, die sich dann natürlich 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 aber als initialisiert betrachtet wird. Oder weil der neue Code eine Benutzereingabe entgegen nimmt und ungeprüft an eine alte Funktion weiter gibt, die davon aus geht, 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 die Gefahr, 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 die jemand 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 sowieso durchgeführten Tests etc. ausreichen. Ob ein Fehler nun seine Ursache in einer Fehlbedienung einer neuen Entwicklungsumgebung oder in zum Beispiel einer falschen Entscheidung eines Entwicklers hat, ist für das Endergebnis egal - der Fehler muss bei Tests entdeckt und korrigiert werden.
DevOps mit Sicherheit
DevOps bietet auch die Möglichkeit, die Sicherheit in einigen Punkten zu verbessern:
- Kontrolle: Bei DevOps gibt es viele und meist kleine Änderungen an der Software statt seltener, aber großer Ä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.
- Nachvollziehbarkeit: Viele DevOps-Tools protokollieren die Änderungen sehr umfangreich, so dass 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.
Zusammenfassung
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. Dass Allgemein ausführlicher zu beschreiben ist ziemlich schwierig, dafür sind die individuellen Umgebungen zu unterschiedlich. Deshalb verzichte ich auch zumindest vorerst darauf.
Vereinfacht müssen Sie bei der Einführung von DevOps "nur" darauf achten, dass die hoffentlich schon vorhandenen Sicherheitsprozeduren auf DevOps übertragen werden. Und dass so wenig Sicherheitsbarrieren wie möglich auf der Strecke bleiben. Alle werden sich nicht aufrecht erhalten lassen, wenn Entwicklung und Betrieb zusammenwachsen sollen. Man sollte bei allen Änderungen nur immer auch alle dadurch entstehenden Risiken 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.
Und damit ist der kurze Ausflug in die DevOps-Sicherheit auch schon beendet. Vielleicht gehe ich später noch mal ausführlicher auf einzelne Punkte ein.
Das Thema der nächsten Folge seht noch nicht endgültig fest.
Trackbacks