© Liashko/Shutterstock.com
Entwickler Magazin
„Best Practices“ in Sachen Sicherheit mit DevOps

Wie DevOps die Sicherheit erhöhen kann

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.

Carsten Eilers


In der Theorie ist das Problem „sichere Entwicklung der Software“ seit der Entwicklung des Security Devel­opment Lifecycle [1] 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-Ko...

Entwickler Magazin
„Best Practices“ in Sachen Sicherheit mit DevOps

Wie DevOps die Sicherheit erhöhen kann

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.

Carsten Eilers


In der Theorie ist das Problem „sichere Entwicklung der Software“ seit der Entwicklung des Security Devel­opment Lifecycle [1] 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-Ko...

Neugierig geworden?


   
Loading...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang