Einführung
Erfahren Sie, wie die Snowflake Data Cloud starke Sicherheit bietet, indem sie Netzwerk-Egress-Proxying, Namespaces, seccomp-bpf und ptrace zur Isolierung von Workloads nutzt.
Die sicherste Tür ist eine Mauer. Sie verhindert den unbefugten Zugang, kann aber auch den autorisierten Zugang behindern. Eine Wand ist leicht zu entwerfen. Es ist schwieriger, eine Tür zu entwerfen, die sowohl sicher als auch nützlich ist. Bei Snowflake dreht sich alles um die Daten: ein einfacher, kontrollierter Zugriff auf nahezu unbegrenzte Datenmengen mit modernsten Tools, Anwendungen, Diensten und Sicherheit. Diese Sicherheit ist jedoch nur von begrenztem Wert, wenn die Kunden feststellen, dass sie eher eine Mauer als eine Tür ist.
Bis vor kurzem bot Snowflake eine relativ begrenzte Anzahl von Programmierprimitiven: SQL-Abfragen und eine feste Anzahl eingebauter Funktionen. Potenzielle Angreifer konnten den neuesten Exploit nicht in Snowflake ausführen, da die Ausführung dieses Codes bis zur Einführung von Snowpark einfach nicht zu den von Snowflake angebotenen Services gehörte. Da Snowflake immer wieder neue Workloads in der Snowflake Data Cloud bereitstellt, mussten die Oberfläche vergrößert werden, um sie unterzubringen. Die Kunden wollten eine Tür. Deswegen wurde Snowpark entwickelt.
Snowpark ermöglicht es Data Cloud-Benutzern, Java- und Python-Bibliotheken von Drittanbietern einzubinden. So können Sie problemlos benutzerdefinierte Funktionen (UDFs), benutzerdefinierte Tabellenfunktionen (UDTFs) und gespeicherte Prozeduren erstellen. Natürlich birgt das zusätzliche Risiken. Um dies zu kompensieren, hat Snowflake sich auf seine Sicherheitsprinzipien konzentriert, Arbeitslasten isoliert und mehrere unabhängige Verteidigungsebenen entwickelt.
Potenzielle Bedrohungen
Die Snowpark-Bibliotheken von Drittanbietern stellen nicht vertrauenswürdigen Code dar, der eine sehr reale Bedrohung für die Sicherheit darstellen könnte. Wenn dieser Code einen Weg findet, sich mit einem feindlichen Endpunkt im Internet zu verbinden, könnte er zusätzliche bösartige Nutzdaten abrufen, Befehle und Kontrollen ausführen und sensible Daten exfiltrieren. Wenn böswillige Akteure in der Lage sind, Prozesse auf Plattformebene zu beobachten oder zu manipulieren, könnten sie Daten beschädigen oder einen Denial-of-Service-Angriff (DoS) durchführen.
Die Sicherheitsarchitektur von Snowflake
Die Abbildung zeigt die sichere Sandbox von Snowflake, die aus fünf Komponenten besteht, die Schutz bieten: Namespaces und cgroups, seccomp-bpf, chroot filesystem, ptrace und Bedrohungserkennung. Innerhalb der Sicherheits-Sandbox befindet sich eine Sprachlaufzeit. Im Inneren der Sprachlaufzeit gibt es eine benutzerdefinierte Funktion. Außerhalb der sicheren Sandbox besteht eine Query Engine. Es gibt einen bidirektionalen Pfeil zwischen der Query-Engine und der Sprachlaufzeit innerhalb der Sandbox.
Wie in der obigen Abbildung dargestellt, setzt Snowflake eine vielschichtige Sicherheitsarchitektur ein, um potenziell bösartige Arbeitslasten zu isolieren. Diese Mechanismen schützen den Kernel, das Netzwerk, das Host-Dateisystem und die Workload-Orchestrierungsprozesse. Diese Architektur umfasst eine Reihe von verschiedenen Tools und Lösungen. Dazu gehören:
- Namespaces und cgroups – Namespaces werden zur Prozessisolierung verwendet.
- seccomp-bpf – Seccomp BPF (SECure COMPuting with filters) wird zur Einschränkung von Systemaufrufen verwendet.
- chroot – chroot isoliert die von Prozessen lokal erreichbaren Dateien.
- ptrace – ptrace überwacht Systemaufrufe, die Prozesse tätigen.
Die erste Verteidigungslinie von Snowflake ist die von Snowflake entwickelte Sprachlaufzeit, die Angriffe auf Architekturebene erschwert. Dadurch wird die Anwendung einer Vielzahl potenzieller Taktiken, Techniken und Verfahren (TTPs) entweder behindert oder verhindert.
Die Sprachlaufzeit wird in einem Chroot-Dateisystem ausgeführt, das einen minimalen Satz gemeinsam genutzter Bibliotheken und anderer Abhängigkeiten enthält, die für die Ausführung der UDF erforderlich sind. Außerdem läuft sie innerhalb ihrer eigenen Namespaces, einschließlich Netzwerk, Benutzer, Einhängen, PID, IPC, UTS, CGroup und Zeit. Die Namespace-Isolierung ist ein primärer Mechanismus, der von gängigen Container-basierten Lösungen eingesetzt wird.
Alle Prozesse in der Sandbox-Umgebung unterliegen einem seccomp-bpf-Filter, der die Oberfläche der Kernel-Systemaufrufe minimiert und nur die für die Ausführung erforderlichen UDFs einschließt. Snowflake kontrolliert außerdem Systemaufrufe mit ptrace, das als Teil der Funktionen zur Erkennung von Bedrohungen verwendet wird, um zu erkennen, wann die Nutzung von Systemaufrufen auf bösartige Aktivitäten hinweisen könnte.
Kontrolle des Egress-Verkehrs
Ein Beispiel für einen Rechenknoten mit einer sicheren Sandbox und einer Abfrage-Engine im Inneren. Die sichere Sandbox und die Query-Engine sind durch einen bidirektionalen Pfeil miteinander verbunden. Rechts neben dem Rechenknoten befindet sich ein Egress-Proxy. Es gibt einen unidirektionalen Pfeil von der Query Engine zum Egress Proxy.
Der gesamte Netzwerkverkehr zwischen den Rechenclustern und dem Internet durchläuft einen Egress-Proxy, der Zugriffskontrollrichtlinien durchsetzt und Überwachungsaufgaben übernimmt.
Snowflake wertet den gesamten Netzwerkverkehr von Rechenclustern als nicht vertrauenswürdig. Der Verkehr zu internen Diensten ist auf eine Reihe von authentifizierten Endpunkten beschränkt. Der Verkehr zu externen Netzwerken durchläuft einen Egress-Proxy, der Zugriffskontrollrichtlinien durchsetzt und auf unerwartete Netzwerkaktivitäten überwacht.
Der Egress-Proxy blockiert Versuche, auf nicht autorisierte Endpunkte zuzugreifen, und meldet solche Versuche an das Snowflake Incident Response Team.
Szenario eines Angriffs
Nehmen wir an, dass ein Bedrohungsakteur, den wir als „Malory“ bezeichnen, versucht, unbefugten Zugriff auf einen Rechenknoten in Snowflake zu erhalten, um Kundendaten zu missbrauchen. Sie schreibt ein Python-Skript, das versucht, auf beliebigen Arbeitsspeicher und Speicher auf dem Rechenknoten zuzugreifen. Sie stellt jedoch fest, dass die Mechanismen zur Durchsetzung der Isolierung, einschließlich Namespaces, Prozessisolierung und ein Chroot-Dateisystem, ihre Versuche verhindern, auf Ressourcen außerhalb der eingeschränkten Sandbox-Umgebung zuzugreifen, in der ihr Skript ausgeführt wird.
Malorys nächste Strategie ist der Versuch, aus der Sandbox-Umgebung auszubrechen, also sucht sie nach Möglichkeiten, Container-Escape-Taktiken anzuwenden. Dazu gehören fähigkeitsbasierte Ausbrüche, einhängbare Geräte, Steuersockets und die Ausnutzung von Schwachstellen wie CVE-2019–5736 oder CVE-2020–15257. Sie findet eine gründlich abgeschottete Umgebung vor, in der die Möglichkeit, solche Techniken einzuführen, einfach nicht gegeben ist.
Nehmen wir weiter an, dass Malory eine fortgeschrittene Bedrohungsakteurin ist, die einen Zero-Day-Exploit anwendet, um erfolgreich aus der Sandbox-Umgebung auszubrechen und die Kontrolle über den Compute-Node zu übernehmen. Sie stellt fest, dass der Rechenknoten von den meisten Snowflake-Diensten über Netzwerksicherheitsgruppen, die für ihre VPC gelten, abgeschottet ist. Sie entdeckt einige Endpunkte, auf die sie zugreifen kann, z. B. einen, der Statusinformationen für laufende Abfragen im Konto bereitstellt. Sie benötigt jedoch Anmeldeinformationen, um die internen Authentifizierungsprüfungen zu bewältigen. Die einzigen Anmeldeinformationen, die sie hat, gelten für das spezifische Konto für den Rechenknoten, den sie kompromittiert hat. Da sie das gleiche Konto verwendet, um ihren Angriff zu starten, hat sie keinen Zugriff auf Kundendaten außerhalb ihres eigenen Kontos.
Malory denkt, dass sie zumindest versuchen kann, den Betrieb von Snowflake zu stören, indem sie einen Denial-of-Service-Angriff durchführt, aber sie stellt fest, dass ein Mechanismus zur Begrenzung der Übertragungsrate eine Beeinträchtigung des Dienstes verhindert und das Bedrohungserkennungsteam von Snowflake über potenziell bösartige Aktivitäten im Netzwerk informiert.
An diesem Punkt gibt Malory den direkten Angriff auf die Infrastruktur von Snowflake auf und greift stattdessen die Software-Lieferkette eines Zielbenutzers an, indem sie trojanischen Code in eine Python-Abhängigkeit einschleust und so versucht, die Daten des Zielbenutzers über das Netzwerk zu exfiltrieren. Der Egress-Proxy von Snowflake erkennt den Versuch des Trojaners, eine Verbindung zu einem nicht autorisierten Endpunkt im Internet herzustellen, blockiert die Verbindung und alarmiert das Snowflake-Team zur Erkennung von Bedrohungen über das nicht autorisierte Netzwerkereignis.
Trotz aller Versuche von Malory wurde er vereitelt und/oder entdeckt, bevor er eine Reihe von Versuchen unternehmen konnte, das System zu infiltrieren und großen Schaden anzurichten.
Fazit
Dank dieser Kombination aus sicherheitsorientiertem Design, On-Host-Zugriffskontrolle, Isolierungsmechanismen und einem Egress-Proxy sind Snowflake und seine Kunden in hohem Maße vor potenziell bösartigem Code geschützt, der seinen Weg in UDFs finden könnte. Die Data Cloud hat das Snowpark-Team dazu inspiriert, weiterhin fortschrittliche Technologien zur Sicherung Ihrer Daten zu entwickeln. Obwohl die Entwicklung von Snowpark eine ambitionierte Herausforderung war, zeigt das äußerst positive Feedback zu Art, Größe und Vielfalt der Workloads, die Kunden bereits mit Snowpark ausführen, dass sich der Aufwand für Snowflake gelohnt hat.
Quelle: medium
Erfahren Sie hier mehr über Lösungen im Bereich Snowflake oder besuchen Sie eines unserer kostenlosen Webinare.
