Die Cloud-Sicherheit ist in letzter Zeit immer komplexer geworden. Cloud-Anbieter verwenden Zehntausende von APIs, Container-Orchestrierungssysteme werden immer zahlreicher und komplexer und immer mehr Plattformen und Dienste betreten den Cloud-native-Ring. 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. Daher ist es vielleicht keine Überraschung, dass Gartner prognostiziert: „Bis 2025 , 99 Prozent der Sicherheitsmängel in der Cloud sind auf den Kunden zurückzuführen.“ ¹

Um diese Komplexität zu untersuchen, freuten wir uns, Dan Hubbard, CEO des Cloud-Sicherheitsanbieters Lacework, als Redner auf PagerDutys erster virtueller Summit-Weltkonferenz im September begrüßen zu dürfen. Dan gab seine Sicht auf das Cloud-Sicherheitsproblem und sprach vom „Shared Irresponsibility Model“.

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

Die Realität, so teilte er mit, ist, dass Sie in der Cloud sowohl schnell als auch sicher arbeiten können. Konflikte zwischen DevOps und Sicherheit sind oft sinnlos, und Verantwortungslosigkeit muss bei Ihren Cloud-Sicherheitspraktiken nicht vorkommen. Da die Kunden immer mehr Verantwortung für die Sicherheit ihrer Cloud-Umgebung übernehmen, ist es vielmehr unerlässlich, dass DevOps- und Sicherheitsteams bessere Wege der Zusammenarbeit finden.

Die vier Grundsätze des Cloud-Sicherheitskonflikts

Dan erläuterte, dass sich das Shared Irresponsibility Model 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. Aus diesem Grund 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 – was kritische Probleme sein können.

2. Werkzeuge und Tuning

Unternehmen investieren viel Zeit in den Tooling-Prozess, aber immer wieder kommt es zu Fehltritten. „Wir sehen ziemlich oft, dass DevOps und Sicherheit von zwei unterschiedlichen Datenquellen und Datenebenen aus arbeiten“, erklärt Dan.

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

3. Änderungen in Daten verstehen

Vorbei sind die Zeiten, in denen in einem privaten Rechenzentrum einmal im Monat Änderungen vorgenommen wurden – die Cloud ist viel dynamischer. „Heute geschieht alles in nahezu Echtzeit, also 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 ebenfalls nahezu in Echtzeit korrelieren. Sie müssen zusammenarbeiten und dürfen nicht mit dem Finger auf andere zeigen, um herauszufinden, ob eine Änderung der Infrastruktur durch DevOps 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 sollen, sondern auch, welche Workflows 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 automatisiert werden können.“

Dies könnte beispielsweise die Automatisierung der Deaktivierung der Multifaktor-Authentifizierung oder die Automatisierung einer Reaktion sein, wenn Mitarbeiter Buckets ohne die erforderlichen Berechtigungen öffnen. Und mit der Automatisierung geht die Notwendigkeit einher, dass sich DevOps- und Sicherheitsteams auf die zugrunde liegende Infrastruktur und die erforderliche Sicherheitslage einigen müssen, um dies zu ermöglichen.

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. Innerhalb kürzester Zeit, so Dan, nutzen 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, dass Sie reagieren können“, sagte er. „Die Integration ist eine wirklich großartige Möglichkeit, die von uns gesammelten Informationen direkt an PagerDuty zu übermitteln, um sicherzustellen, 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/.