Skip to content

DevOps-Sicherheit, Teil 1: Sichere Entwicklung in Theorie und Praxis

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 obwohl sie sich gerade mit DevOps verbessern lässt, wenn man das denn möchte. Und wer möchte das schon nicht?

Theoretisch sicher

In der Theorie ist das Problem "Sichere Entwicklung der Software" seit der Entwicklung des Security Development Lifecycles 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" ja eigentlich keines mehr. Und wenn sowohl Entwicklung als auch Betrieb sowieso schon sicher sind, dann ist es beides zusammen in Form von DevOps natürlich auch. Es gibt also gar keinen Grund, sich darüber Gedanken zu machen. Oder?

Von der Theorie in der Praxis

Das Problem ist mal wieder, wie so oft, die Umsetzung der Theorie in der Praxis. 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 mal 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,... was dazu führt, dass die Administratoren selbst heraus finden müssen, was wie installiert und/oder 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 an Hand von Fehlermeldungen und -beschreibungen prüfen, was im Fehlerfall nicht richtig funktioniert hat.

DevOps eilt zur Rettung!

Wenn die Entwickler dann noch so produktiv sind, dass sie ständig neue Softwareversionen veröffentlichen (möchten), kommt es zum sprichwörtlichen Knall - die Administratoren kommen mit der Installation der neuen Versionen nicht mehr nach, und vor lauter Arbeit kommt die Kommunikation womöglich ganz zum Erliegen (das ist jetzt mit Absicht etwas übertrieben).

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 / das Deployment wird 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.

Alles beim Alten, aber man redet mehr miteinander

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 jeden Schritt an den nächsten weiter gegeben werden und es in mehr oder weniger unregelmäßigen Abständen Abstimmungen gibt, gibt es bei DevOps laufend Feedback auf die aktuellen Änderungen, dass dann in die weitere Entwicklung bzw. Betrieb einfließt.

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

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. Und um die geht es in der nächsten Folge.

Carsten Eilers

>
        </div>
                
        <footer class= Kategorien: Grundlagen

Trackbacks

Dipl.-Inform. Carsten Eilers am : DevOps-Sicherheit, Teil 2: Fallstricke und Vorteile

Vorschau anzeigen
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, a