Die Website cloud hat den Kontext durcheinander gebracht, auf den sich Verteidiger gewöhnlich stützen, um die Angriffsoberfläche zu verstehen. Angreifer bewegen sich nicht mehr entlang einer linearen Netzwerkebene, von einer Anlage zu einer anderen, bei der die Sichtbarkeit auf einer vorhersehbaren Ebene im Netzwerkstapel verfolgt werden kann. Auf cloud muss jeder Schritt, den ein Angreifer unternimmt, im Zusammenhang mit der cloud Infrastruktur, auf der er operiert, verstanden werden.
In diesem Beitrag möchte ich die einzigartigen Ansätze erläutern, die zur Verteidigung von cloud -Systemen erforderlich sind, indem ich die der cloud zugrunde liegende Architektur, das daraus resultierende Bedrohungsmodell und schließlich die Art und Weise, wie Angreifer solche Systeme missbrauchen, erörtere.
Zunächst ein kurzer Überblick über die klassische On-Prem-Architektur und die Schwachstellen, die Angreifer auszunutzen versuchen. Die Architektur Ihres cloud Service Providers (CSP) steht im Gegensatz zu einem traditionellen Tech-Stack. Ich führe Sie durch die Grundlagen der cloud Architektur, das neue Bedrohungsmodell und die Schritte, die Angreifer unternehmen, um cloud bereitgestellte Ressourcen zu infiltrieren. Sobald wir uns darüber im Klaren sind, warum cloud anders ist, werde ich Ihnen eine cloud-spezifische Art und Weise aufzeigen, wie Angreifer die Umgebung missbrauchen, und wie Verteidiger über die Sichtbarkeit in cloud nachdenken müssen.
Bedrohungsmodell des traditionellen Tech Stack
Es kann hilfreich sein, einen kurzen Überblick über die Architektur von Rechenzentren zu geben, auch wenn die meisten Leser mit den traditionellen Technologien vertraut sind. Die Beschäftigung mit dem Bedrohungsmodell von Rechenzentrumsarchitekturen hilft bei der späteren Gegenüberstellung mit dem Bedrohungsmodell von cloud , aber auch bei der Erinnerung an die eingebauten Annahmen, die wir zum Schutz von Systemen haben.
Prüfung der Vektoren der anfänglichen Kompromisse.
- Klassische Architekturen können mit ungeschützten Management-Ports behaftet sein, über die Angreifer direkten Zugriff auf einen Server erlangen können.
- Wir müssen auch die Risiken modellieren, die mit Schwachstellen auf der Anwendungsschicht verbunden sind, und wie sie ausgenutzt werden können, um Zugang zur Betriebssystemschicht zu erhalten.
- Zu den anderen häufigen Angriffen auf ein klassisches System gehören die immer relevanten Phishing-Angriffe, Implantate, die per E-Mail zugestellt werden, und die Ausnutzung von Schwachstellen auf der Host-Schicht.
Jeder dieser Vektoren kann von einem Angreifer genutzt werden, um in einer Umgebung Fuß zu fassen oder um ein System zu durchdringen, um ein bestimmtes Ziel zu verfolgen - häufig die Vertraulichkeit von Daten.
Die Techniken der Angreifer richten sich nach den Merkmalen des Tech-Stacks.
Es mag wie eine offensichtliche Beobachtung erscheinen, dass Angreifer vom Land leben und ihre Methoden an die Technologie anpassen, mit der sie es zu tun haben. Trotz ihrer Einfachheit hilft diese universelle Wahrheit dabei, die Unterschiedlichkeit der Techniken zu erklären, die verwendet werden, wenn Bedrohungsakteure Systeme vor Ort und die Infrastruktur von cloud angreifen.
Die Systeme vor Ort, mit denen sich die Angreifer beschäftigen, sind wahrscheinlich mit voll funktionsfähigen Betriebssystemen installiert. Diese Angriffsfläche kann genutzt werden, um von einer kompromittierten Workstation auf einen routingfähigen Server im Rechenzentrum des Opfers überzugehen.
Die Server laufen nicht in der Luft, sondern sind über ein Netzwerk miteinander verbunden. Über dieses Netzwerk können sich Angreifer von Host zu Host bewegen.
In der traditionellen Rechenzentrumsarchitektur sind häufig zulässige Egress-Regeln zu finden. Auf diesem ausgehenden Netzwerkpfad versuchen Angreifer, durch Command-and-Control-Tunnel eine Persistenz zu erreichen und Daten aus einem vertrauenswürdigen Netzwerkbereich herauszuschleusen.
Wie Sie feststellen können, wird der Verlauf des im obigen Diagramm dokumentierten Angriffs vor Ort durch die einem Angreifer zur Verfügung stehende Oberfläche bestimmt. Im nächsten Abschnitt, in dem wir uns mit der Architektur von cloud befassen, werden Sie feststellen, dass die gleichen Regeln gelten: Der Technologie-Stack bestimmt die Taktiken und Techniken, die Angreifer einsetzen, um ihre Ziele zu erreichen.
Cloud Architektur und das neue Bedrohungsmodell
cloud basiert auf dem Konzept der gemeinsam genutzten Infrastruktur, bei dem Kunden granularer Zugriff auf bestimmte Schichten des Infrastruktur-Stacks gewährt wird, um Ressourcen zu erstellen und zu verwalten. Ein Kunde von cloud hat die vollständige Autonomie, IaaS-Ressourcen zu erstellen, PaaS-Dienste zu nutzen, Daten zu übertragen und IAM-Richtlinien (Identitäts- und Zugriffsmanagement) zu erstellen, um den Zugriff zu regeln - und das alles aufgrund seiner delegierten Berechtigung für einen Teil der Infrastruktur, die von den cloud Dienstanbietern unterhalten wird.
Der Zugriff auf die Funktionalität wird delegiert und offengelegt für den Kunden über eine Schicht von APIs, die allgemein als Cloud Control-Plane-APIs bezeichnet werden.
Alle Interaktionen der Endbenutzer mit einer cloud Umgebung werden über die Cloud Control-Plane durch Tausende von öffentlich verfügbaren APIs vermittelt. Die Control-Plane-APIs ermöglichen den Kunden die Durchführung von Verwaltungsaufgaben wie die Erstellung neuer Umgebungen, die Bereitstellung von Benutzern, die Verwaltung von Ressourcen und den Zugriff auf Daten, die in verwalteten PaaS-Diensten gespeichert sind.
Die Aufgabe der Control Plane API ist es:
- Autorisieren Sie Anrufer und stellen Sie sicher, dass sie die richtigen Berechtigungen haben, um die angeforderten Aktionen durchzuführen.
- Geben Sie die Aktion an die nachgelagerte Komponente weiter. Eine Aktion könnte das Einschalten einer VM, das Kopieren eines Objekts von einem Bucket in einen anderen oder die Aktualisierung der Berechtigungen eines Benutzers sein.
Die cloud ist leistungsstark!
Indem alle Funktionen über eine Reihe bekannter, öffentlicher APIs zugänglich gemacht werden, können Unternehmen Geschwindigkeit und Skalierbarkeit in einem Maße nutzen, wie sie es bisher nicht konnten. Auf cloud zu bauen, ist wie Benzin für Ihre Entwicklungszyklen zu gießen, und das ist der Grund, warum die große Migration zu cloud in allen Sektoren ernsthaft im Gange ist, trotz der oft hohen Kosten der Migration und der laufenden cloud Infrastrukturkosten.
Wie sollten wir angesichts dieses neuen Paradigmas die Bedrohungen modellieren, denen die auf der Website cloud gespeicherten Daten ausgesetzt sind?
In diesem Zusammenhang halte ich es für sinnvoll, sich auf die anfängliche Kompromissbereitschaft zu konzentrieren, da sie ein hervorragendes Instrument ist, um die Ähnlichkeiten und Unterschiede zwischen On-Prem- und cloud -Bedrohungsmodellen hervorzuheben.
Einige Vektoren der anfänglichen Kompromisse auf der Website cloud sollten Ihnen bekannt vorkommen.
- Die anfängliche Kompromittierung von cloud kann durch offene Verwaltungsports auf IaaS-Ressourcen erfolgen. Wir alle wissen, dass ein offener SSH- oder RDP-Port unerwünschte Aufmerksamkeit auf sich zieht. Auf cloud bleiben diese Risiken bestehen.
- Auch Schwachstellen auf der Anwendungsebene sind nach wie vor von großer Bedeutung. Unsicherer Code, der in öffentlich zugänglichen Webanwendungen eingesetzt wird, führt zumindest zu einer Unterbrechung der Geschäftsabläufe und verschafft Angreifern im schlimmsten Fall ein Standbein in Ihrer DMZ.
Alle Erfahrungen, die Sie bei der Verhinderung und Erkennung von Kompromittierungen über diese beiden Vektoren gesammelt haben, werden Ihnen auf cloud zugute kommen. Die Regeln für die Verhinderung und Erkennung sind zwar leicht cloud-nativ, aber grundsätzlich gleich, wenn sie in einer cloud Umgebung gelten.
Aber was ist mit den APIs auf der Steuerungsebene? Hierbei handelt es sich um öffentliche Endpunkte, bei denen die Autorisierung durch den Kunden konfiguriert werden kann. Diese Angriffsfläche ist völlig neu, und hier wird der versierte Angreifer die Annehmlichkeiten von cloud nutzen, um seine Ziele zu erreichen.
Untersuchen wir, wie ein Angriffsverlauf aussehen könnte, wenn ein Angreifer Control-Plane-APIs im Gegensatz zu einer lokalen Angriffsfläche nutzt (siehe Diagramm):
- Die anfängliche Kompromittierung über Phishing ist eine beliebte Taktik von Angreifern, da sie häufig funktioniert.
- Die Auswirkungen von erbeuteten Anmeldedaten können sich auf cloud verlagern, wenn Anmeldedaten zur Authentifizierung und Autorisierung von Aktivitäten in cloud Umgebungen verwendet werden.
- Es ist unwahrscheinlich, dass die Anmeldeinformationen, die mit der ersten Kompromittierung verbunden sind, dem Angreifer einen direkten Weg bieten. Infolgedessen könnte eine der vielen bewährten Techniken zur Privilegienerweiterung auf cloud eingesetzt werden, um zusätzliche Berechtigungen zu erhalten.
- Kampagnen werden oft eine Form der Persistenz anstreben. Auf der cloud -Kontrollebene sieht das ganz anders aus als bei On-Premises. Persistenz auf cloud sieht oft wie das Backdooring des Kontozugriffs durch die Manipulation der IAM-Richtlinie aus.
- Beim Durchlaufen dieses Angriffsverlaufs sind wir nun an einem Punkt angelangt, an dem der Zugriff auf das Ziel erlangt wurde. Auf cloud bedeutet dies einfach, dass die entsprechenden IAM-Berechtigungen für den Zugriff auf die unter cloud gehosteten Daten erlangt wurden.
- Und schließlich geht es bei diesem Szenario um die Exfiltration von Daten aus der Umgebung. Auch hier werden cloud Control-Plane-APIs verwendet, um Daten aus der Umgebung des Opfers in eine vom Angreifer kontrollierte Umgebung zu übertragen.
Die gesamte Angriffssequenz, von der anfänglichen Kompromittierung bis zu den Auswirkungen, wurde über die öffentlich zugänglichen APIs des Dienstanbieters cloud abgewickelt. Zu keinem Zeitpunkt kam die Netzwerk- oder Host-Schicht ins Spiel. Es waren nicht einmal präventive Kontrollen oder Sensoren in einem Netzwerk möglich.
Cloud-Native Datenexfiltration
Ein Hauptmerkmal eines jeden CSP ist sein Backbone-Netz. Was ist ein Backbone-Netz?
- Es handelt sich um die Diensteschicht des cloud Service Providers, die für betriebliche Hintergrundaufgaben des CSP, das Rückkanalnetzwerk zur Kommunikation mit der mandantenfähigen Infrastruktur und zur Aufrechterhaltung der Verfügbarkeit verwendet wird.
- Das Backbone bezieht sich auch auf das Netz, das der CSP für die Übertragung von Kundendaten verwendet, im Gegensatz zum Transport von Bytes über das offene Netz.
Dieses Backbone-Netz hat zur Folge, dass viele verwaltete Dienste, wie z. B. cloud , automatisch zu allen anderen Speicher-Repositories des CSP geleitet werden können.
Wenn Sie Daten von einem S3-Bucket in ein anderes S3-Bucket verschieben möchten, benötigen Sie lediglich die entsprechenden IAM-Berechtigungen. Der Netzwerkpfad ist bereits über das Backbone-Netzwerk des CSPs (Cloud Service Provider) angelegt.
Als cloud Verbraucher ist es nicht möglich, Netzwerkbeschränkungen für die Daten auf cloud-native storage1 zu implementieren, und Sie haben keinen Einblick in das Netzwerk, über das die Daten übertragen werden.
So ist es beispielsweise nicht möglich, Protokolle der Netzwerkebene aufzunehmen, um den Datenverkehr zwischen zwei S3-Buckets zu erfassen.
Dies sind attraktive Bedingungen für einen Angreifer, der Daten aus einer cloud Umgebung exfiltrieren will.
Sollten sie die entsprechenden IAM-Berechtigungen erhalten, können Daten aus dem Bucket eines Opfers in einen Bucket eines vom Angreifer kontrollierten Kontos verschoben werden, indem Schicht-7-API-Anfragen an die cloud -Kontrollebene gestellt werden.
Um dies auszuführen, interagiert ein Angreifer ausschließlich mit den öffentlich zugänglichen APIs der Steuerungsebene von cloud und nutzt das Backbone-Netzwerk des CSP, eine vorkonfigurierte Netzwerkroute, die für den Kunden nicht zugänglich ist.
Sichtbarkeit auf der Steuerungsebene
Daten, die von einem Bucket in einen anderen verschoben werden, hinterlassen nicht die Art von Spuren, an die die meisten Verteidiger gewöhnt sind.
- Protokolle der Netzwerkebene, die Aufschluss über die Datenpakete geben, die von Ihrem Bucket zu einem anderen übertragen werden - diese sind für Sie als Verbraucher von cloud nicht verfügbar.
- Der Datenverkehr erfolgt über das Backbone-Netz, das für die Kunden von cloud nicht sichtbar ist.
- Wie sieht es mit der Sichtbarkeit auf der Host-Schicht aus?
- Cloud-native Speicher wie S3-Buckets, Azure-Storage-Blobs und dergleichen sind allesamt verwaltete Dienste. Der Kunde hat keinen Zugriff auf die Host- oder Betriebssystemebene wie bei dem Modell "Infrastruktur als Service". Auf verwalteten Diensten können keine Agenten eingesetzt werden.
Bleibt also noch die Steuerungsebene. Keine der von einem Angreifer durchgeführten Aktionen könnte mit herkömmlichen Sensoren identifiziert werden, aber Indikatoren für die Aktivität tauchen in den Protokollen auf, die von der cloud Kontrollebene geschrieben werden.
Alle Aktionen in Bezug auf Ressourcen und cloud-gehostete Daten werden von den cloud control-plane proxy APIs autorisiert und führen zu einer Art von Aufzeichnung.
- Die Aktionen Ihrer Entwickler beim Erstellen ihrer Buckets werden aufgezeichnet, das normale Einlesen und Auslesen von Daten wird aufgezeichnet und führt zu entsprechenden Ereignissen.
- Wenn die Bösewichte hingegen die cloud control-plane APIs nutzen, werden ihre Aktionen als dasselbe Ereignis aufgezeichnet.
Diese Ereignisprotokolle erzählen die Geschichte Ihrer cloud Umgebung, wer von wo aus und mit welchen Anmeldeinformationen auf was zugegriffen hat, aber nicht die Absichten des Benutzers. Um festzustellen, ob eine bestimmte Aktion in böswilliger oder gutartiger Absicht durchgeführt wurde, sind zusätzliche Kontextinformationen erforderlich, und oft muss die Umgebung durch eine größere Brille betrachtet werden.
Abschließende Überlegungen
Ein paar Denkanstöße
- Angreifer werden die einzigartige Architektur von cloud und die cloud-nativen Dienste aus demselben Grund nutzen, aus dem Entwickler cloud verwenden: Es ist schnell! Sie ist skalierbar! Und die cloud control-plane APIs helfen ihnen, ihre Ziele zu erreichen.
- Die Control-Plane ist der Ort, an dem wir Beweise für bösartige oder andere Aktivitäten in einer cloud Umgebung finden können. Die netzwerk- und hostbasierte Überwachung bietet Ihnen nicht die nötige Transparenz.
[1] VPC (Virtual Private Cloud) Service Controls: Nur Google Cloud bietet die Möglichkeit, verwaltete Dienste, die nicht an VPCs gebunden sind, abzugrenzen https://cloud.google.com/vpc-service-controls#section-6