DevSecOps: Mit DevOps-Prinzipien kontinuierlich sicherer werden

Gerade vor dem Hintergrund zunehmend kürzerer Releases durch Continuous Delivery wird häufig die Sicherheit vernachlässigt. Penetrationstests sind dabei als Sicherheitsmaßnahmen nicht ausreichend. Es bietet sich aber auch die Chance, schneller zu reagieren.

In Pocket speichern vorlesen Druckansicht 10 Kommentare lesen
DevSecOps: Mit DevOps-Prinzipien kontinuierlich sicherer werden
Lesezeit: 12 Min.
Von
  • Martin Reinhardt
Inhaltsverzeichnis

Der erste Teil dieser Artikelserie hat sich mit grundlegenden Informationen zur Sicherheit in der Softwareentwicklung auseinandergesetzt. Der zweite gab einen Überblick über die Werkzeuge von Hackern. Im dritten Teil werden nun Aspekte beleuchtet, um kontinuierlich Sicherheit in den Softwareentwicklungsprozess zu verankern.

Mehr Infos

DevSecOps – die Serie

Neben klassischer Java-Architekturen gilt es in vielen Softwareprojekten mittlerweile, die derzeit populären JavaScript-Umgebungen miteinzubeziehen. Deren Schnelllebigkeit bringt dabei eine weitere Dimension in die Betrachtung, die aber damit auch eine Chance bietet. Es sollten jedoch nicht nur technische Maßnahmen etabliert werden, wichtig ist, dass auf Entwicklerseite mehr Sicherheitsbewusstsein entsteht.

In vielen Fällen kann Nachlässigkeit selbst ausgefeilte Abwehrmaßnahmen zunichte machen. So kann die Nutzung ungesicherter Hotspots schnell in Datendiebstahl enden. Es gilt generell zu beachten: Interne Netzwerke sind nicht per se sicher. Auch in einem internen Netzwerk sind Absicherungsmaßnahmen zu treffen. Außerdem sollte man bei Sicherheitsbetrachtungen den Testcode nicht vernachlässigen, so lassen sich Test-Tools für Exploits im CI-Server nutzen.

Continuous Delivery Pipeline mit Security (Abb. 1)

Ein essenzieller Bestandteil sind um so mehr Authentifizierungsstrategien und pragmatische Rollenkonzepte. Eine Modellierung, die den konkreten Schutzbedarf berücksichtigt, kann helfen:

Modellierung nach Schutzbedarf (Abb. 2)

In der Praxis werden zwar häufige Passwortwechsel immer noch stark propagiert, aber sie schaffen dabei mehr Probleme, als sie lösen. Ein ereignisbezogener Passwortwechsel neben einem jährlich eingeplanten helfen dabei mehr. So lassen sich Konten eher auf Exploits überwachen, zum Beispiel über Dienste wie "have I been pwned?" oder ähnliche Angebote.

Auch das Sperren sollte nicht dauerhaft erfolgen, sondern temporär, um nicht anfällig für Denial-Of-Service-Attacken zu sein. Überdies sollten Passwörter immer sicher, das heißt ausreichend verschlüsselt abgelegt werden. Bei technischen Konten helfen lange, generierte Passwörter, sodass ein Wechsel erst anlassbezogen nötig ist, zum Beispiel bei Personalwechsel, Abteilungswechseln oder bekannten Datenabflüssen.

Lediglich bei Administrationskonten sollten weitere Schutzmaßnahmen mit einem weiteren Authentifizierungsmechanismus ergriffen werden. Ein durchgängiges Rollen- und Rechtekonzept, das nur die erforderlichen Rechte hat, hilft in der Praxis meist mehr, um Angriffsvektoren zu minimieren.

Audits, Penetrationstests und Security-Monitoring sorgen bei Entwicklern eher nicht für Begeisterung: Aber letztlich sind das die Tests für die Security und sie haben damit die gleiche Bedeutung wie die in der Entwicklung. Dabei ist es wichtig, regelmäßig Rechtevergaben zu überprüfen: In Jenkins gibt es etwa mittlerweile ein Plug-in, um bei Audits die konkreten Rechte von Nutzern stichprobenartig zu prüfen.