Originalartikel von Mark Nunnikhoven, VP Cloud Research
Die Cloud steckt voller neuer Möglichkeiten. So können Anwender etwa mit einem einzigen Befehl das Pendant eines ganzen Datacenters starten. Die Skalierung, um die Anforderungen von Millionen von Kunden zu erfüllen, kann vollständig automatisiert erfolgen. Erweiterte Machine Learning-Analysen sind so einfach wie ein API-Aufruf. Damit sind Teams in der Lage, Innovationen zu beschleunigen und sich fast ausschließlich darauf zu konzentrieren, Geschäftswert zu generieren. Doch so einfach, wie es scheint, ist es nicht.
Es war zu erwarten, dass neben diesem Steigerungspotenzial auch die Sicherheitsherausforderungen zunehmen, die es bei On-Premises gibt, und Teams mit Zero-Days, Schwachstellenketten und Schatten-IT zu kämpfen haben würden. Doch stellt sich heraus, dass diese Probleme nicht ganz oben auf der Sorgenliste stehen.
Den größten Kummer bereiten Fehler in Form von Service-Fehlkonfigurationen.
Geteilte Verantwortung
Viele Unternehmen denken, hinsichtlich der Cloud-Sicherheit sind die Cloud Service Provider selbst ein großes Risiko. Doch gibt es keine Zahlen, die diese Annahme bestätigen. Alle vier großen Service Provider Alibaba Cloud, AWS, Google Cloud und Microsoft Azure hatten in den letzten fünf Jahren zwei Sicherheitsverletzungen bei ihren Diensten … alle zusammen.
Dennoch sollte nicht vergessen werden, dass jeder dieser Service Provider im Laufe der Jahre mit einer Vielzahl an Sicherheitsschwachstellen fertig zu werden hatte. Die beiden oben erwähnten Sicherheitsvorfälle hatten eine Fehlkonfiguration als Ursache. Der erste stammt von März 2020 und betraf Google Cloud, der zweite passierte im Januar 2020 und traf Microsoft Azure. Weitere Einzelheiten dazu beinhaltet der Originalbeitrag.
Viele Cloud-Dienste sind einfach verwaltete Service-Angebote von gängigen kommerziellen oder Open-Source-Projekten. Diese Projekte hatten verschiedene Sicherheitsprobleme, mit denen sich die Anbieter auseinandersetzen mussten.
Der Vorteil der Cloud für Benutzer oder Builder liegt darin, dass alle operativen Arbeiten – und Sicherheit ist operative Arbeit – in jeder Cloud dem Shared Responsibility Model folgt. Darin gibt es sechs Bereiche, in denen betriebliche Arbeiten erforderlich sind. Abhängig von der genutzten Art des Service wechseln die Verantwortlichkeiten. Nutzt ein Unternehmen Instanzen oder virtuelle Maschinen, so ist es für das Betriebssystem, die darauf laufenden Anwendungen und die Daten verantwortlich. Im Fall eines vollständig gemanagten Service ist das Unternehmen für die Sicherheit der Daten, die in dem Service verarbeitet und vorgehalten werden, zuständig. Für alle Arten von Cloud-Services liegt die Verantwortung für die Dienstkonfiguration beim Unternehmen.
Trotz klarer Zuständigkeiten bieten die Provider eine Reihe von Funktionen, die Unternehmen bei der Erfüllung ihrer Aufgaben unterstützen und die Dienste an ihre Bedürfnisse anpassen.
Es gibt zahlreiche Belege dafür, dass Fehlkonfigurationen das größte Problem bei der Cloud-Sicherheit sind. Sicherheitsforscher, -anbieter oder Branchenorganisationen stimmen in den Ergebnissen überein:
65% — 70% aller Sicherheitsprobleme in der Cloud starten mit einer Fehlkonfiguration. 45% der Organisationen glauben, dass Vertraulichkeits- und Sicherheitsherausforderungen ein Hindernis für die Migration in die Cloud darstellen. Das ist schade, denn wird das Shared Responsibility Model richtig verstanden, so ist es einfacher, eine robuste Sicherheitsposition aufrechtzuerhalten. Organisationen sollten darauf drängen, schneller in die Cloud zu wechseln, um ihre Sicherheit zu verbessern.
Tempo des Wandels
Fehlkonfigurationen sind nichts anderes als Fehler. Manchmal sind diese Fehler ein Versehen, ein anderes Mal eine falsche Wahl, die aus mangelndem Sicherheitsbewusstsein getroffen wurde. Alles hängt mit den Fähigkeiten zusammen, die die Cloud zugänglich macht und zu einer entsprechenden Steigerung des Innovationstempos geführt hat.
Mit der Zeit werden die Teams schneller und können Innovationen mit einer geringen Fehlerquote erreichen. Tatsächlich sind 43 % der Teams, die eine DevOps-Philosophie eingeführt haben, in der Lage, mindestens einmal pro Woche Code bereitzustellen und dabei eine Fehlerquote von unter 15 % beizubehalten.
Und wenn doch einmal ein Fehler auftritt, können sie ihn innerhalb eines Tages beheben. Noch beeindruckender ist, dass 46 % dieser Teams in der Lage sind, die Probleme innerhalb einer Stunde zu beheben. Leider ist auch bekannt, dass Cyberkriminelle weniger als einen Tag brauchen, und jede Lücke kann ausreichen, damit sie in den Unternehmenssystemen Fuß fassen und einen Vorfall verursachen.
Die anderen 57 % der Teams, von denen die meisten große Unternehmen sind, haben oft das Gefühl, dass ihr mangelndes Tempo Schutz bietet. Ein vorsichtiges Vorgehen in der Cloud ermöglicht ihnen eine maßvollere Herangehensweise und reduziert ihre Fehlerquote. Das mag zwar stimmen, aber um sie herum findet dennoch ein Wandel statt. Die Cloud-Service-Provider selbst bewegen sich in einem rasanten Tempo.
Im Jahr 2020 haben die vier großen Hyperscale-Anbieter über 5.000 neue Funktionen für ihre Dienste veröffentlicht.
https://www.trendmicro.com/content/dam/trendmicro/global/en/research/21/a/the-top-worry-in-cloud-security-for-2021/04-the-worry-in-cloud-security-for-2021.jpg
Für Single-Cloud-Anwender bedeutet das fast zwei neue Funktionen pro Tag … Minimum. Für die wachsende Zahl von Multi-Cloud-Benutzern nimmt das Tempo der Veränderungen noch zu.
Selbst wenn sich Ihr Team also langsam bewegt, verschiebt sich der Boden unter ihm schnell.
Ziel der Cybersicherheit
Das Ziel der Cybersicherheit ist eigentlich ziemlich einfach: Sicherstellen, dass das, was gebaut wurde, wie angedacht funktioniert und nur so.
In einer traditionellen On-Premises-Umgebung besteht dieser Standardansatz aus einem starken Perimeter und einer weitreichenden Sichtbarkeit über das gesamte Unternehmen hinweg. In der Cloud funktioniert das nicht. Das Tempo der Veränderungen ist zu schnell, sowohl intern als auch beim Provider. Kleinere Teams bauen mehr und mehr auf. Oft agieren diese Teams von vornherein außerhalb der zentralen CIO-Infrastruktur.
Dies macht es erforderlich, dass die Sicherheit wie ein weiterer Aspekt eines guten Gebäudes behandelt wird. Sie kann nicht wie eine eigenständige Aktivität gehandhabt werden. Das klingt nach einer monumentalen Aufgabe, ist es aber nicht. Hier erweisen sich Sicherheitskontrollmechanismen als sehr wertvoll.
Geht es um Sicherheitskontrollmechanismen, so spricht man meistens darüber, was sie stoppen. Die Verwendung eines Intrusion Prevention Systems kann Würmer und andere Arten von Netzwerkangriffen stoppen. Anti-Malware-Schutzmaßnahmen können Ransomware, Cryptominers und andere bösartige Verhaltensweisen stoppen, usw. Das ist hervorragend und funktioniert gut mit den Sicherheitsteams.
Builder jedoch haben eine andere Perspektive. Im richtigen Kontext ist es einfach zu zeigen, wie Sicherheitskontrollmechanismen ihnen helfen können, besser zu bauen. Das Posture Management stellt sicher, dass die Einstellungen erhalten bleiben, unabhängig davon, wie oft ein Team im Laufe der Woche Deployments durchführt. Netzwerkkontrollen stellen sicher, dass nur gültiger Datenverkehr den Code erreicht. Die Container-Zugangskontrolle stellt sicher, dass der richtige Container zur richtigen Zeit bereitgestellt wird.
Sicherheitskontrollmechanismen tun so viel mehr, als nur zu verhindern, dass etwas passiert. Sie geben Antworten auf kritische Fragen, die sich Entwickler immer öfter stellen. Zwei Kernfragen sind es:
- Was kann dieser Code sonst noch tun? (Sehr wenig dank der Sicherheitskontrollmechanismen)
- Bist Du Dir sicher? (Ja, ich setze die Mechanismen ein, um sicherzugehen)
Wenn sie gut entwickelt und intelligent eingesetzt werden, helfen Sicherheitskontrollmechanismen den Teams, Lösungen zu liefern, die zuverlässiger, einfacher zu beobachten und verlässlicher sind.
Sicherheit hilft, besser zu bauen.