[Aufmachergrafik: heller, corporate design] DevOps aus Sicherheitsperspektive

Ordnungsmerkmale

Ordnungsmerkmale

erschienen in: <kes> 2014#6, Seite 6

Rubrik: Management und Wissen

Schlagwort: DevOps

Zusammenfassung: DevOps ist eine Methode, um die Kommunikation, Zusammenarbeit und Integration zwischen der Softwareentwicklung und dem IT-Betrieb zu verbessern. Der Artikel gibt einen Einblick in die Risiken aus Perspektive der Informationssicherheit und beschreibt Kontrollmaßnahmen für eine überlegte und sichere Implementierung von DevOps.

Autor: Von Dr. Stefan Beißel, Köln

Traditionell sind Softwareentwicklung und IT-Betrieb zwei strikt getrennte Bereiche. Das ist in der Praxis jedoch oft problematisch. So besteht beispielsweise die Gefahr, dass neue Software durch den IT-Betrieb zwar korrekt installiert wird, diese aber nicht wie gewünscht und ohne Fehler funktioniert. Teilweise kommt es auch vor, dass keine genauen Vorgaben zur Installation vorhanden sind, sodass der IT-Betrieb selbst herausfinden muss, was genau zu tun ist. Neue Software erfordert zudem häufig eine Anpassung der Konfiguration von Betriebssystemen, Datenbanken oder Applikationen. Wenn der Betrieb dies überstürzt oder unprofessionell durchführt, ist die Funktion der Systeme gefährdet. Dadurch dass die Softwareentwickler wiederum keinen direkten Zugriff auf die Produktivumgebung besitzen, können sie lediglich indirekte Informationen über Probleme im Verhalten der installierten Software erhalten. Außerdem nehmen sie manchmal mithilfe moderner Programmierwerkzeuge so schnell und häufig Änderungen am Programmcode vor, dass der IT-Betrieb mit der ordnungsmäßigen Installation der Änderungen nicht mehr hinterher kommt.

Die im Jahr 2009 auf einer Konferenz in Belgien erstmals vorgestellte DevOps-Methode, ein Schachtelwort aus Development und Operations, hat das Ziel, diese Lücke zwischen der Softwareentwicklung und dem IT-Betrieb zu beseitigen, indem sie die Kommunikation, Zusammenarbeit und Integration zwischen den beiden Bereichen verbessert. So sollen die Umsetzung beschleunigt, Fehler minimiert, der Betrieb stabilisiert und die IT-Wertschöpfung insgesamt erhöht werden. Die Softwareverteilung (Deployment) ist in der Methode ein zuverlässiger, häufig ausgeführter und wiederholbarer Prozess. Die Qualität der Software soll laufend überwacht werden und die Beteiligten sollen verstärkt Feedback geben.

Die regulären Phasen des traditionellen Software- Development-Lifecycles (SDLC), und zwar Definition der Anforderungen, Entwicklung, Test, Qualitätssicherung, Softwareverteilung (Deployment), Betrieb und Wartung, sind auch Bestandteil bei DevOps. Der Unterschied besteht darin, dass die beteiligten Funktionseinheiten bei DevOps kontinuierlich kommunizieren und zusammenarbeiten, anstatt lediglich Zwischenergebnisse zu übergeben und sich in regelmäßigen Abständen abzustimmen (vgl. Abbildung 1). Außerdem wird bei DevOps die Automatisierung möglichst vieler Aufgaben angestrebt, um menschliche Fehler zu reduzieren und die Effizienz im SDLC zu steigern. So können wiederkehrende Aufgaben mit reduziertem Zeit- und Arbeitsaufwand durchgeführt werden. Auch die Qualität und Konsistenz der Ergebnisse kann man so erhöhen.

[ALTText]
Abbildung 1: Traditioneller Software- Development- Lifecycle (SDLC) und DevOps

Unternehmen, die DevOps bereits umsetzen, profitieren von einer erheblichen Steigerung der IT-Performance. Sie sind in der Lage, neuen Programmcode bis zu 30-mal häufiger mit bis zu 50 Prozent weniger Fehlern zu implementieren, und es ist doppelt so wahrscheinlich, dass sie ihre Profitabilität, ihre Produktivität und Marktanteile erhöhen [1].

Risiken

Aus der Perspektive der Informationssicherheit ist es besonders wichtig, dass das bestehende Sicherheitsniveau eines Unternehmens durch DevOps nicht beeinträchtigt wird. Insbesondere dürfen Unternehmen die Trennung zwischen Softwareentwicklung und IT-Betrieb nicht vollständig aufheben, da dies auch zu Verstößen gegen Compliance-Vorgaben, wie PCI-DSS und ISO 27001, führt.

Durch eine unüberlegte Implementierung von DevOps kann es zu gravierenden Risiken für die Informationssicherheit kommen. So können beispielsweise Manipulationen bei DevOps eher durchgeführt werden, da die Entwickler meist Schreibrechte auf Produktionssysteme erhalten. Dadurch haben sie die Möglichkeit, eine Hintertür in den Programmcode wichtiger Software einzubauen und sie für Betrugsversuche zu missbrauchen. Wenn sie danach bestimmte Protokolle oder ganze Datenträger löschen, sind ihre Spuren komplett verwischt. Auch die hohe Automatisierung von DevOps verhindert nicht, dass solche Manipulationen möglich sind. Zumindest die Entwickler der Automatisierungstools können auch die Automatisierung manipulieren und Sicherheitskontrollen umgehen oder Programme mit unerwünschtem oder schadhaftem Verhalten einschleusen.

Ein weiteres Risiko sind Fehler im Programmcode, die zum Beispiel in Produktionssystemen zu gravierenden Störungen führen. Solche Fehler können durch unzureichende Tests zunächst unerkannt bleiben. Bei DevOps sind die Zyklen für die Softwareverteilung durch die häufigeren Änderungen im Programmcode grundsätzlich weitaus kürzer. Dies kann dazu führen, dass die Tests der Funktion und die Maßnahmen zur Qualitätssicherung stark reduziert und eingeschränkt werden. Dadurch erhöht sich die Wahrscheinlichkeit, dass man Fehler übersieht und diese bis zum produktiven Einsatz der Software unbemerkt bleiben.

Ebenso kann die DevOps-Methode Angriffe begünstigen. Durch die Aufhebung der Trennung zwischen Softwareentwicklung und IT-Betrieb werden oft auch die Sicherheitsbarrieren reduziert. Die traditionelle Funktionstrennung, die dafür sorgt, dass Entwickler keinerlei Berechtigungen in der Produktivumgebung besitzen, wird bei DevOps aufgehoben oder zumindest aufgeweicht. Dadurch kann ein Angreifer unter Umständen leichter Zugriff auf die Produktivumgebung erlangen, um Schadsoftware zu installieren oder Daten zu kompromittieren.

Da bei DevOps eine hohe Umsetzungsgeschwindigkeit gefordert wird, die zu hohem Zeitdruck auf die beteiligten Mitarbeiter führt, sind auch Prozessabweichungen zu befürchten. Als Resultat könnten Sicherheitsprozesse, wie Härtungsmaßnahmen und Schwachstellenscans, vernachlässigt werden. Außerdem besteht die Gefahr, dass die Verantwortlichen durch die eher kleineren und häufigeren Änderungen umfangreiche Sicherheitstests für unnötig halten, obwohl die Gesamtheit aller Änderungen trotzdem gravierend ist. Möglicherweise entstehen auch durch das Zusammenspiel der Änderungen neue Schwachstellen, die aufgrund fehlender Sicherheitstests unbemerkt bleiben.

Ebenso problematisch sind Bedienfehler. Sie können bei DevOps entstehen, wenn Mitarbeiter durch neue DevOps-Tools überfordert werden, was zu unbewussten Sicherheitsverletzungen führen kann. Insbesondere erhöht sich in der Regel die Anzahl der eingesetzten Automatisierungstools, zum Beispiel Jenkins, GitHub, Chef, Puppet, New Relic, SaltStack, Nagios und Splunk. Die Benutzeroberflächen der Tools unterscheiden sich teilweise fundamental. Eine korrekte Bedienung kann man oft nicht ohne Weiteres von den Mitarbeitern erwarten. Auch die vorhandenen Bedienungsanleitungen und Systemhandbücher reichen häufig nicht aus, da diese nicht immer komplett verstanden werden.

Chancen

Durch DevOps ergeben sich aber nicht nur Risiken, sondern auch Chancen, um die Sicherheit im Unternehmen zu verbessern. So kann man mit der Methode folgende Punkt verbessern:

Laut einer Studie erwarten 45 Prozent der Befragten durch DevOps eine Erhöhung der Informationssicherheit in ihrem Unternehmen [2]. Demgegenüber sind nur sieben Prozent der Meinung, dass die Informationssicherheit durch DevOps negativ beeinträchtigt wird. 42 Prozent der Anwender können durch DevOps eine Verbesserung in den Bereichen Überwachung, Alarmierung und Audit verzeichnen.

Kontrollmaßnahmen

Um die oben genannten Risiken, die durch DevOps entstehen, zu minimieren, können die Verantwortlichen Kontrollmaßnahmen, wie Sicherheits- und Funktionsvalidierung von Programmcode, Zugriffsschutz, Richtlinien, Schulungen und die Förderung des Sicherheitsbewusstseins, umsetzen (vgl. Abbildung 2). Das „DevOps Auditor Defense Toolkit“ [3] beinhaltet beispielsweise Informationen über einige Risiken, die speziell im Rahmen von DevOps auftreten können, und entsprechende Kontrollmaßnahmen, um diese Risiken zu minimieren. Darin nennen die Autoren auch die technischen Maßnahmen Sicherheits- und Funktionsvalidierung von Programmcode sowie Zugriffsschutz, die im Folgenden näher beschrieben werden.

[ALTText]
Abbildung 2: Zusammenhang zwischen Risiken und Kontrollmaßnahmen

Sicherheitsvalidierung von Programmcode

Zur Risikominimierung sollte man den gesamten Programmcode, der in die Produktivumgebung überführt werden soll, aus der Perspektive der Informationssicherheit validieren. So können Entwickler keine Hintertüren in den Programmcode einschleusen oder unter Umständen unbeabsichtigt Sicherheitslücken zulassen. Dazu wird ein Peer-Review durchgeführt, um den Code auf Korrektheit und Einhaltung der Softwareentwicklungsrichtlinien des Unternehmens zu überprüfen. Insbesondere sensiblen Programmcode sollten zusätzlich andere Entwickler überprüfen. Der Peer-Review-Prozess ist vorab vom Management zu institutionalisieren, um zu gewährleisten, dass der Prozess stets durchgeführt wird und die Reviewer für ihre Aufgaben qualifiziert sind. Zur Sicherheitsvalidierung gehört außerdem ein automatischer Sicherheitstest, zum Beispiel mittels Tools zur Quellcodeanalyse. Bei der Suche nach Schwachstellen sollte man unter anderem die schwerwiegendsten Sicherheitsschwachstellen von Webanwendungen gemäß OWASP berücksichtigen [4].

Funktionsvalidierung von Programmcode

Darüber hinaus ist es sinnvoll, den Programmcode in angemessener Weise auf seine Funktion zu validieren. So stellt man sicher, dass die Software wie gewünscht in der Produktivumgebung funktioniert und Störungen verhindert oder schnell beseitigt werden. Die Entwickler arbeiten dafür am besten bereits vor der Erstellung des Programmcodes Testroutinen aus. So werden eine fehlende oder mangelnde Testbarkeit des Codes verhindert und die Erstellung der Tests grundsätzlich nicht durch Zeitdruck oder Nachlässigkeit beeinträchtigt. Wenn alle durchgeführten Tests positiv ausfallen, können die Verantwortlichen den Code freigeben. Die Testergebnisse sollten sie jedoch dauerhaft vorhalten, beispielsweise mithilfe einer Versionskontrollsoftware. Wenn Tests nicht bestanden werden, sind die Entwickler und der entsprechende Manager darüber zu informieren, zum Beispiel mittels automatischem E-Mail-Versand. Anhand von Protokollen sollte man zudem die Funktionsfähigkeit des Programmcodes in der Produktivumgebung nachhalten, sodass Entwickler diese Informationen im Fall von Störungen als Hilfsmittel bei der Fehlersuche nutzen können. Nachdem ein Fehler durch beispielsweise eine Wiederherstellung des Ursprungszustands oder durch einen Patch – der jedoch erneut die Tests durchlaufen muss – behoben wurde, sollten Entwicklungsabteilung und IT-Betrieb zusammen herausfinden, wie die automatischen Tests anzupassen sind, damit gleichartige Probleme nicht mehr auftreten.

Zugriffsschutz

Die dritte technische Kontrollmaßnahme betrifft den Zugriffsschutz. Alle Systeme und Applikationen in der jeweiligen Umgebung, zum Beispiel Datenbanken, Betriebssysteme, Netzwerkgeräte und Speichersysteme, müssen vor unbefugtem Zugriff geschützt werden. Vertreter der Softwareentwicklung, des IT-Betriebs und der Informationssicherheit sollten zusammenarbeiten, um die Übergänge der Umgebungen abzusichern. Die Netzwerkumgebung ist so zu betreiben, dass unerwünschte ein- und ausgehende Verbindungen blockiert und Angriffsversuche erkannt werden. Sie sollte zudem regelmäßig gescannt werden, um sicherzustellen, dass sie so konfiguriert und segmentiert ist, wie ursprünglich im Design vorgegeben. Hierzu kann man zum Beispiel prüfen, ob bestimmte IP-Adressen erreichbar sind. Außerdem hilft es, wenn externe Spezialisten regelmäßig Penetrationstests durchführen und die Ergebnisse Vertretern der Softwareentwicklung, des IT-Betriebs und der Informationssicherheit kommunizieren.

Aber nicht nur die Übergänge der Umgebungen sollte man schützen, sondern auch die Bestandteile im Inneren. Beispielsweise sind Skripte so zu gestalten, dass sie konform zu branchenüblichen Best Practices sind. Auch sollten sie regelmäßig überprüft, aktualisiert und durch die Informationssicherheit genehmigt werden. Das Ausrollen der Software sollte zudem auf einem Image basieren, das hinreichend getestet wurde. In der Produktivumgebung ist außerdem die Integrität wichtiger Dateien mit geeigneter Software zu überwachen, um nicht autorisierte Änderungen zu identifizieren. Zusätzlich müssen die Systeme im Hinblick auf unübliches Verhalten überwacht werden.

Neben diesen technischen Kontrollmaßnahmen bieten sich auch einige organisatorische an. So können Unternehmen mithilfe von Richtlinien den sicheren Umgang von DevOps-Tools regeln. Solche Richtlinien machen verbindlich, welche Vorgaben und Erwartungen an Administratoren und Entwickler gestellt werden. Unter anderem sollte man darin Informationen, Systeme und Applikationen definieren, auf die Mitarbeiter im Rahmen von DevOps zugreifen dürfen. Die Richtlinien sollten auch unterstreichen, dass jeder Mitarbeiter die Verantwortung für sein Handeln übernehmen muss und ein Verstoß in jedem Fall definierte und klare disziplinarische Maßnahmen mit sich bringt. Um zu beurteilen, ob die vorhandenen Richtlinien angemessen sind, bieten sich folgende Fragen als Hilfestellung an:

Zusätzlich sollte das Unternehmen mithilfe passender Schulungen bei den Entwicklern und Administratoren ein Verständnis über die DevOps-Methode und den sicheren Umgang mit DevOps-Tools herstellen. Dabei ist zu verdeutlichen, dass die ständige Bewahrung eines angemessenen Sicherheitsniveaus besonders wichtig ist. Neben Schulungen können Unternehmen auch Maßnahmen zur Förderung des Sicherheitsbewusstseins durchführen. Dafür bieten sich Webinare, Newsletter oder auch regelmäßige Informationen im Intranet an. Nur wenn die Mitarbeiter wissen, wie sensibel die Daten sind, mit denen sie im Rahmen von DevOps arbeiten, und welche Sicherheitskriterien dabei von Bedeutung sind, können sie bewusst darauf achten und Abweichungen vermeiden oder melden.

In manchen Fällen können Unternehmen aufgrund technischer oder organisatorischer Beschränkungen eigentlich notwendige Kontrollmaßnahmen nicht umsetzen. Sie sollten dann jedoch zumindest kompensierende Maßnahmen oder Workarounds einführen, die das verbleibende Risiko auf ein akzeptables Maß reduzieren. Dazu gehören zum Beispiel zusätzliche Autorisierungen, bevor neuer Programmcode in die Produktivumgebung überführt werden darf, ergänzende Genehmigungen und Überwachungen für Entwickler, die auf solche Systeme zugreifen, die Überwachung des gesamten Programmcodes auf Änderungen, die Überwachung der Zugriffe auf den originalen Quellcode oder weitere Schutzmaßnahmen für produktive Daten, zum Beispiel Verschlüsselung oder restriktivere Berechtigungen sowie umfassende Protokollierungen und Protokollauswertungen.

Implementierung

Ob die Implementierung von DevOps in Anbetracht der zu berücksichtigenden Sicherheitsaspekte tatsächlich wirtschaftlich lohnenswert ist, hängt von unterschiedlichen Faktoren ab. Zum Beispiel spielt die vorhandene Arbeitskultur eine große Rolle. Die Vorteile der Methode lassen sich nämlich nur durch eine bessere Zusammenarbeit realisieren. Gibt es im IT-Bereich eines Unternehmens noch keine Arbeitskultur, die von Zusammenarbeit und offener Kommunikation geprägt ist, beeinträchtigt das stark die Effektivität von DevOps.

Essenziell ist auch die Unterstützung der Geschäftsführung. Nur wenn diese die IT als wichtig genug erachtet, um einen spürbaren Einfluss auf die Profitabilität des Unternehmens zu nehmen, erhalten neue Methoden, wie DevOps, das nötige Gewicht. Das brauchen die Verantwortlichen dann beispielsweise, wenn womöglich Änderungen an der Organisation und am Arbeitsverhalten vorgenommen und durchgesetzt werden müssen.

Grundsätzlich spielt bei der Überlegung, ob DevOps überhaupt Sinn macht, die Zahl der Eigenentwicklungen eine Rolle. Die Anzahl und die Bedeutung der selbst entwickelten Applikationen müssen hoch genug sein, damit sich ein fundamentales Umdenken der Entwickler und Administratoren im Rahmen von DevOps überhaupt lohnt. Ansonsten sind die Investitionen zur Umstellung höher als die zu erwartende Steigerung der Wertschöpfung.

Hat sich ein Unternehmen jedoch für DevOps entschieden, sollte die Einführung gut vorbereitet und schrittweise ausgeführt werden. Auf diese Weise kann man verhindern, dass sich die womöglich hohen Erwartungen an DevOps nicht erfüllen oder dass Verantwortliche gravierende Sicherheitsmängel übersehen. Vor allem folgende Punkte sollten Unternehmen bei der Planung der Implementierung bedenken:

Bei der Implementierung von DevOps ist es aus Sicherheitsperspektive besonders empfehlenswert, Mitarbeiter aus der Informationssicherheit und der Revision einzubeziehen. Wie schon beschrieben, kann die Methode dazu führen, dass sich die Entwickler und Administratoren in Graubereichen bewegen und dass so neue Risiken für die Sicherheit des Unternehmens entstehen. Durch eine qualifizierte Risikobewertung und einer Hilfestellung bei der Auswahl und Umsetzung von Kontrollmaßnahmen können die Risiken bereits im Voraus vermindert und Compliance-Probleme reduziert werden.

Fazit

DevOps ist eine junge und vielversprechende Methode zur Verbesserung der Entwicklung und des Betriebs von Software, die große Vorteile für die Wertschöpfung durch die IT mit sich bringt. Allerdings können mit DevOps, besonders bei einer unüberlegten Implementierung, gravierende Risiken entstehen, die möglicherweise den gesamten Geschäftsbetrieb des Unternehmens gefährden. Dazu gehören finanzielle Schäden und Reputationsverluste, die mit Manipulationen, Programmfehlern, Angriffen, Prozessabweichungen und Bedienfehlern einhergehen können. Demgegenüber stehen allerdings auch potenzielle Sicherheitsvorteile, wie die verbesserte Kontrolle der Softwareverteilung sowie größere Nachvollziehbarkeit und erhöhte Transparenz.

Insgesamt kann man DevOps aus Sicherheitsperspektive weder grundsätzlich ablehnen noch empfehlen. Vielmehr müssen sich wie oben beschrieben Unternehmen vor der Einführung von DevOps aller Risiken und Chancen bewusst sein und angemessene Kontrollmaßnahmen auswählen. Vor der Implementierung von DevOps sollten sie zudem prüfen, ob alle erforderlichen Voraussetzungen vorhanden sind, damit der Nutzen nicht durch Defizite in der Sicherheit oder der Wirtschaftlichkeit ausbleibt. Die eigentliche Implementierung führt man dann wie beschrieben am besten schrittweise durch. Besonders zu empfehlen ist es, Vertreter der Informationssicherheit und der Revision in den gesamten Prozess mit einzubeziehen. So werden Experteneinschätzungen zur Sicherheit und Compliance von Anfang an berücksichtigt und Sicherheitsrisiken sowie spätere Compliance-Probleme vermieden.

Dr. Stefan Beißel (CISA, CISSP, PMP) verantwortet als ITSecurity Officer bei der EVO Payments International die Leitung sicherheitsrelevanter Projekte und die Compliance zum PCI-DSS (Stefan.Beissel@EVOpayments.com). Er promovierte am Institut für Produktion und Industrielles Informationsmanagement der Universität Duisburg-Essen.

Literatur

[1]
Puppet Labs (2014) 2014 State of DevOps Report, [externer Link]http://puppetlabs.com/sites/default/files/2014-state-of-devops-report.pdf
[2]
InformationWeek (2014) DevOps’ Role In Application Security, [externer Link] www.darkreading.com/application-security/devops-role-in-application-security/d/d-id/1269160
[3]
DeLuccia, J.; Gallimore, J.; Kim, G.; Miller, B. (2014) DevOps Auditor Defense Toolkit, [externer Link] https://plus.google.com/communities/103372669680429508474
[4]
OWASP (2013) OWASP Top 10 – 2013 – The Ten Most Critical Web Application Security Risks, [externer Link] http://owasptop10.googlecode.com/files/OWASP%20Top%2010%20-%202013.pdf