Cloud-Sicherheit ist in letzter Zeit immer komplexer geworden. Cloud-Anbieter nutzen Zehntausende von APIs, Container-Orchestrierungssysteme werden immer zahlreicher und komplexer, und immer mehr Plattformen und Dienste werden in den Cloud-nativen Bereich integriert. Darüber hinaus stellt jede dieser Komponenten ein potenzielles Sicherheitsrisiko für Unternehmen dar. Und Sie als Kunde sind für die Konfiguration und Sicherheit dieser Komponenten verantwortlich. Kein Wunder also, dass Gartner prognostiziert, „bis 2025 , 99 Prozent der Sicherheitsmängel in der Cloud sind auf die Schuld des Kunden zurückzuführen.“ ¹

Um diese Komplexität zu untersuchen, freuten wir uns, Dan Hubbard, CEO des Cloud-Sicherheitsanbieters Lacework, als Redner auf der ersten virtuellen Summit-Weltkonferenz von PagerDuty im September begrüßen zu dürfen. In seiner Stellungnahme zum Cloud-Sicherheitsproblem sprach Dan vom „Modell der gemeinsamen Verantwortungslosigkeit“.

„Leider sehen wir in vielen Unternehmen, dass DevOps auf die Sicherheit hinweist und sagt: ‚Oh, diese Sicherheit. Sie bremsen uns ständig mit diesen großen, belastenden Sicherheitsprozessen aus.‘ Und die Sicherheitsleute sagen: ‚Oh, DevOps. Die entwickeln sich so schnell. Sie machen uns nur unsicher‘“, erklärte Dan.

Tatsächlich, so erklärte er, könne man in der Cloud sowohl schnell als auch sicher arbeiten. Konflikte zwischen DevOps und Sicherheit seien oft sinnlos, und Verantwortungslosigkeit müsse bei Cloud-Sicherheitspraktiken nicht vorkommen. Da Kunden immer mehr Verantwortung für die Sicherheit ihrer Cloud-Umgebung übernehmen, sei es unerlässlich, dass DevOps- und Sicherheitsteams bessere Wege der Zusammenarbeit finden.

Die vier Grundsätze des Cloud-Sicherheitskonflikts

Dan erklärte, dass sich das Modell der gemeinsamen Verantwortungslosigkeit um vier Schlüsselfaktoren dreht:

1. Architektur und Infrastruktur

Wenn die Sicherheitsarchitektur nicht mit der Cloud-Infrastruktur übereinstimmt, können DevOps-Teams frustriert sein, weil Cloud-Sicherheitsprodukte nicht zu ihren Praktiken passen. „Deshalb brauchen wir Modelle für die organisatorische Verantwortung“, erklärte Dan.

Zusammenarbeit und Kommunikation zwischen DevOps und Sicherheit sind unerlässlich, damit klar ist, wer für die Behebung einer Sicherheitsverletzung verantwortlich ist. „Hier kommt es zu Schuldzuweisungen, Fehlausrichtungen und Governance-Problemen“, sagte er – und das können kritische Probleme sein.

2. Werkzeuge und Tuning

Unternehmen investieren viel Zeit in den Tooling-Prozess, doch immer wieder kommt es zu Fehltritten. „Wir sehen häufig, dass DevOps und Sicherheit mit zwei unterschiedlichen Datenquellen und Datenebenen arbeiten“, erklärt Dan.

Idealerweise sollten die Tools teamübergreifend gemeinsam genutzt werden. Es müssen nicht unbedingt dieselben Tools sein, sie sollten aber aus derselben Datenebene stammen. Auf diese Weise können sich Entwicklung und Sicherheit darauf einigen, wer die Leistung optimiert, und gemeinsame Risikomodelle nutzen. Beide Teams können so Ursache und Wirkung der Security-DevOps-Operationen nachvollziehen.

3. Änderungen in Daten verstehen

Vorbei sind die Zeiten, in denen in einem privaten Rechenzentrum einmal im Monat Änderungen vorgenommen wurden – die Cloud ist deutlich dynamischer. „Heute geschieht alles nahezu in Echtzeit, daher muss die Sicherheit damit Schritt halten – und man muss die mit Änderungen verbundenen Risiken verstehen“, sagte Dan.

Der Schlüssel liegt also darin, dass DevOps- und Sicherheitsteams diese Änderungen und Risiken nahezu in Echtzeit korrelieren. Sie müssen zusammenarbeiten und nicht mit dem Finger auf andere zeigen, um herauszufinden, ob eine von DevOps vorgenommene Infrastrukturänderung das Risiko einer Sicherheitsverletzung erhöht. Und wenn es zu Ausfallzeiten kommt, müssen sie zusammenarbeiten, um herauszufinden, ob diese durch ein Sicherheitsereignis oder einen Entwicklerfehler verursacht wurden.

4. Workflows und Automatisierung

Ein weiterer Schlüsselfaktor für das Shared Irresponsibility Model ist nicht nur das Wissen, welche Workflows erstellt und ausgeführt werden müssen, sondern auch, welche automatisiert werden sollen. „Die Fähigkeit, gemeinsame Workflows durch Automatisierung zusammenzuführen und zu erstellen, wird wirklich wichtig sein“, sagte Dan. „Es gibt viele wiederholbare Dinge, die tatsächlich automatisierbar sind.“

Dies könnte beispielsweise die Automatisierung der Deaktivierung der Multifaktor-Authentifizierung oder die Automatisierung einer Reaktion sein, wenn Mitarbeiter Buckets ohne die entsprechenden Berechtigungen öffnen. Mit der Automatisierung geht auch die Notwendigkeit einher, dass sich DevOps- und Sicherheitsteams auf die zugrunde liegende Infrastruktur und die dafür erforderliche Sicherheitslage einigen.

Zusammenarbeit mit PagerDuty ermöglichen

Damit Entwickler und Sicherheitsteams ihre Reaktion auf Vorfälle harmonisieren können, Lacework und PagerDuty hat kürzlich eine Integrationspartnerschaft angekündigt. Laut Dan nutzen innerhalb kurzer Zeit rund 40 Prozent der Lacework-Kunden die PagerDuty Integration.

Die Integration wird DevOps- und Sicherheitsteams informieren Wie Der Vorfall sollte behoben werden. „Wir geben Ihnen so viele Informationen, wie Sie brauchen, um reagieren zu können“, sagte er. „Die Integration ist eine hervorragende Möglichkeit, die gesammelten Informationen direkt an PagerDuty zu übermitteln. So wird sichergestellt, dass die richtige Person die richtigen Daten erhält, um das Ticket direkt zu schließen oder zu priorisieren.“

Möchten Sie die gesamte Sitzung ansehen? Hier kostenlos registrieren um es zusammen mit anderen Partner- und Kundensitzungen auf Abruf anzusehen.

¹ Quelle: Smarter With Gartner, Inc., Ist die Cloud sicher?, 10. Oktober 2019, https://www.gartner.com/smarterwithgartner/is-the-cloud-secure/.