Snowflakes Credential-Diebstahl-Kampagne und die Grenzen der geteilten Verantwortung

Zusammenfassung

• Bestätigte Kampagnengrenze:Mandiant führte eine finanziell motivierte Kampagne auf UNC5537 zurück und erklärte, dass jeder von Mandiant direkt bearbeitete Kampagnenvorfall auf kompromittierte Kundenanmeldedaten zurückzuführen sei. Es wurden keine Hinweise darauf gefunden, dass der unbefugte Kundenaccess aus einem Einbruch in Snowflakes Unternehmensumgebung resultierte. Snowflake erklärte ebenfalls, es habe keine Hinweise auf eine Schwachstelle, Fehlkonfiguration oder einen Einbruch in seine Plattform gefunden, der die Aktivität verursacht habe.
• Beobachtete Kontrollkette:Die erfolgreichen Konten verfügten nicht über Multi-Faktor-Authentifizierung, behielten Anmeldedaten, die in historischen Infostealer-Aufzeichnungen offengelegt wurden, und hatten keine Netzwerk-Zulassungslisten. Die Angreifer nutzten dann unterstützte Snowflake-Clients und SQL-Operationen, um Daten aufzulisten, zu staging, zu komprimieren und herunterzuladen. Ungefähr 165 Organisationen wurden als potenziell betroffen benachrichtigt; dies ist keine Zählung bestätigter Sicherheitsverletzungen, Personen oder Datensätze.
• Befund zur gemeinsamen Verantwortung:Kunden kontrollierten ihre Benutzer, Rollen, Passwortrotation, MFA-Anmeldung, Netzwerkrichtlinien, Endpunkt-Hygiene und Datenminimierung. Snowflake kontrollierte, welche Schutzmaßnahmen existierten, wie sie präsentiert und standardmäßig eingestellt waren, welche kundenübergreifenden Signale die Plattform sehen konnte und wie schnell Warnungen und ein stärkeres Standardverhalten die installierte Basis erreichten. Diese Verantwortlichkeiten bestehen gleichzeitig, nicht gegenseitig ausschließend.
• Befund zur Souveränität:Die Wahl einer Snowflake-Region bestimmt, wo Kontospeicherung und -berechnung lokalisiert sind; Snowflakes Dokumentation besagt ausdrücklich, dass dies den Benutzerzugriff nicht einschränkt. In dieser Kampagne konnte eine gültige Identität einen regional gespeicherten Datensatz in eine heruntergeladene Kopie verwandeln. Datenlokalität ohne Identitäts-, Ausgangs- und Beweiskontrollen ist eine Platzierungsentscheidung, keine vollständige Souveränitätskontrolle.

Die Plattform wurde nicht als kompromittiert nachgewiesen, aber die Dienstbeziehung wurde auf die Probe gestellt

Die erste Disziplin in diesem Fall ist die Terminologie. Eine Snowflake-Kundeninstanz war nicht dasselbe wie Snowflakes eigene Unternehmensumgebung oder die gemeinsame Produktionsplattform. Eine Person mit gültigen Anmeldedaten konnte in das Konto eines Kunden eindringen, ohne in einen anderen Mandanten zu gelangen, eine Softwareschwachstelle auszunutzen, ein Anbieteradministratorkonto zu erlangen oder die Infrastruktur zu durchbrechen, die Kunden trennt. Die öffentlichen Beweise belegen eine Kompromittierung von Kundenkonten. Sie belegen keinen plattformweiten technischen Einbruch.

Mandiant'sUNC5537-Kampagnenberichtist in diesem Punkt ungewöhnlich direkt. Für jeden Vorfall im Zusammenhang mit der Kampagne, den Mandiant selbst bearbeitete, war die Ursache kompromittierte Kundenanmeldedaten. Die Untersuchung ergab keine Hinweise darauf, dass der unbefugte Zugriff auf Kundenkonten auf einen Einbruch in Snowflakes Unternehmensumgebung zurückzuführen war. Snowflakes eigeneMitteilung zu Untersuchung und Härtungunterschied ebenfalls zwischen betroffenen Kundenkonten und der Produktionsplattform und gab Kunden Abfragen und Indikatoren zur Untersuchung ihrer eigenen Umgebungen. CISA verstärkte diese Anleitung in einerWarnung vom 3. Juni 2024.

Dieser negative Befund ist wichtig. Den Vorfall als Einbruch in Snowflakes Plattform zu bezeichnen, könnte implizieren, dass ein Fehler in gemeinsamem Code oder Infrastruktur jeden Mandanten öffnete oder dass Snowflake eine Master-Anmeldedaten verlor, die Kunden freischaltete. Die überprüfte Aufzeichnung belegt keines von beidem. Es würde auch die Maßnahmen verschleiern, die Kunden sofort ergreifen mussten: nur-passwort Benutzer identifizieren, Anmeldedaten rotieren, Anmelde- und Abfrageverlauf prüfen, Netzwerke einschränken, Rollenberechtigungen reduzieren und Beweise sichern.

Der gegenteilige Fehler besteht darin, das Fehlen eines Plattformeinbruchs als Fehlen einer Anbieterverantwortungsfrage zu behandeln. Ein Cloud-Dienst ist nicht nur eine neutrale Festplatte, auf der ein Kunde zufällig Bits ablegt. Snowflake baute und betrieb die Authentifizierungsendpunkte, die die Anmeldedaten akzeptierten, die Schnittstellen, die die Angreifer nutzten, die Abfrage-Engine, die ihre Befehle verarbeitete, die Telemetrie, die die Sitzungen aufzeichnete, und die Produktkontrollen, die einen zweiten Faktor hätten erfordern oder die Netzwerkherkunft einschränken können.

Snowflake hatte auch eine kundenübergreifende Sichtbarkeit, die kein einzelner Kunde besitzen konnte. Die Tatsache, dass eine entscheidende Kontrolle durch den Kunden konfigurierbar war, bestimmt, wer eine operative Pflicht zur Konfiguration hatte. Sie beantwortet nicht, ob die Voreinstellungen, Warnungen, Erkennung und Durchsetzung des Anbieters im Verhältnis zur Datenkonzentration auf seinem Dienst angemessen waren.

Snowflakes Form 10-K für das Geschäftsjahr 2025formalisiert seine Position. Es besagt, dass Snowflake für die Plattform- und zugrunde liegende Cloud-Infrastruktursicherheit verantwortlich ist, während Kunden Kontrollen für ihre Umgebungen auswählen und konfigurieren. Es führt den Zugriff im Mai 2024 auf die Nichterfüllung von Verpflichtungen wie MFA und Netzwerkrichtlinien durch Kunden zurück und vermerkt gleichzeitig Klagen, behördliche Untersuchungen, Anfragen von Gesetzgebern, Reputationsschäden und die Möglichkeit von Regressstreitigkeiten. Dies ist substanzieller Unternehmensnachweis über Snowflakes dargelegtes Modell und Geschäftsrisiko. Es ist keine unabhängige Entscheidung, dass jede Verantwortung oder jeder Rechtsanspruch auf Kundenseite liegt.

Die nützliche Frage ist daher enger als „Wer wurde kompromittiert?“ und weiter als „Wessen Passwort wurde gestohlen?“. Sie lautet: Welcher Akteur konnte bei jedem Schritt vom gestohlenen Geheimnis bis zu den heruntergeladenen Daten die Aktion verhindern, erkennen, unterbrechen, rekonstruieren oder davor warnen? Rechenschaft folgt der Kontrolle über diese Schritte.

Die Kampagne verband alten Endpunkt-Diebstahl mit aktueller Cloud-Autorität

Mandiant erlangte erstmals im April 2024 Bedrohungsinformationen über Datenbankdatensätze, die später auf eine Snowflake-Instanz eines Opfers zurückverfolgt wurden. Dieses Opfer beauftragte Mandiant, das zu dem Schluss kam, dass der Eindringling Anmeldedaten verwendete, die zuvor von Infostealer-Malware gestohlen worden waren. Das betreffende Konto hatte keine MFA aktiviert. Am 22. Mai, nachdem Mandiant Hinweise auf eine breitere Kampagne identifiziert hatte, kontaktierte es Snowflake und begann, potenzielle Opfer zu benachrichtigen. Snowflake veröffentlichte am 30. Mai eine Kundenleitfaden zur Erkennung und Härtung.

Bis zum Juni-Bericht hatten Mandiant und Snowflake etwa 165 Organisationen benachrichtigt, die potenziell betroffen waren.

Jeder Begriff in diesem letzten Satz muss vor Übertreibung geschützt werden. „Etwa“ kennzeichnet eine Schätzung. „Potenziell betroffen“ beschreibt eine Benachrichtigungspopulation, nicht 165 abgeschlossene forensische Ergebnisse. „Organisationen“ bedeutet nicht Konten, Datenbanken, Personen oder Datensätze. Einige Organisationen betreiben möglicherweise mehrere Snowflake-Konten, und ein Konto kann Daten über eine viel größere Population enthalten. Der Bericht enthält keine kampagnenweite Gesamtzahl bestätigter Organisationen, betroffener Personen, exportierter Bytes oder Lösegeldzahlungen.

Die Historie der Anmeldedaten erklärt, warum eine Cloud-Anmeldung im Jahr 2024 mit einer Endpunktinfektion Jahre zuvor beginnen konnte. Mandiant stellte fest, dass die meisten von UNC5537 verwendeten Anmeldedaten in historischen Infostealer-Ausgaben vorhanden waren, wobei die früheste damit verbundene Infektion im November 2020 beobachtet wurde. Mindestens 79,7 Prozent der vom Akteur genutzten Konten wiesen eine vorherige Offenlegung von Anmeldedaten auf. Dieser Prozentsatz bezieht sich auf die vom Akteur in der analysierten Kampagne genutzten Konten, nicht auf alle Snowflake-Kunden oder alle 165 benachrichtigten Organisationen.

Drei Bedingungen verwandelten wiederholt offengelegte Geheimnisse in funktionierenden Zugriff. Die betroffenen Konten waren nicht mit MFA konfiguriert. In Infostealer-Aufzeichnungen gefundene Passwörter blieben gültig, manchmal über Jahre. Die betroffenen Kundeninstanzen verfügten nicht über Netzwerk-Zulassungslisten, die Verbindungen auf vertrauenswürdige Ursprünge beschränken würden. Keine dieser Bedingungen ist ein neuartiger Exploit.

Zusammen bildeten sie einen dauerhaften Autorisierungspfad: kennen Sie die Kontolokalisierung, den Benutzernamen und das noch gültige Passwort; verbinden Sie sich von einem vom Angreifer kontrollierten System; erhalten Sie eine Sitzung; erben Sie die zugewiesene Rolle; fragen Sie ab, was diese Rolle lesen darf.

Die Endpunktdimension war ebenfalls verteilter, als es eine herkömmliche Mitarbeiter-Laptop-Erzählung vermuten lässt. In mehreren Untersuchungen fand Mandiant die frühere Infostealer-Infektion auf Systemen von Auftragnehmern, die auch für persönliche Aktivitäten genutzt wurden, darunter Spiele oder heruntergeladene Raubkopien. Ein Gerät eines Auftragnehmers kann außerhalb der verwalteten Endpunktflotte des Kunden liegen, während es Anmeldedaten für mehrere Kunden trägt. Es kann auch ein Administratorkonto enthalten, da spezialisierte Auftragnehmer oft eingestellt werden, um Datenplattformen aufzubauen oder zu betreiben.

Der Kunde, der den Benutzer erstellt hat, bleibt für die Identität und ihre Berechtigungen verantwortlich, aber die Offenlegung kann für die eigenen Endpunkt-Tools des Kunden unsichtbar sein.

Dies ist ein Cloud-Abhängigkeitsmultiplikator. Die Anmeldedaten werden von einem Endpunkt gestohlen, möglicherweise außerhalb sowohl von Snowflakes als auch der Flotte des Dateninhabers. Die Anmeldedaten werden von einem globalen Dienst akzeptiert. Die Rolle kann ein konsolidiertes Warehouse erreichen, das jahrelange Aufzeichnungen aus mehreren Geschäftssystemen enthält. Der Angreifer muss diese Quellsysteme nicht mehr einzeln kompromittieren. Der analytische Wert, der das Warehouse für den Kunden nützlich machte, machte den erfolgreichen Zugriff auch für einen Erpressungsakteur wertvoll.

Die Angreifer tragen die direkte Verantwortung für den Diebstahl, Kauf, Test und die Nutzung von Anmeldedaten; das Eindringen in Kundenumgebungen ohne Autorisierung; die Datennahme; und den Versuch von Verkauf oder Erpressung. Die Beschreibung der Kontrollfehler, die diese Verbrechen ermöglichten, verwässert diese Verantwortung nicht. Sie erklärt, warum dieselbe kriminelle Technik in großem Maßstab erfolgreich war und wo Wiederholungen reduziert werden können.

Unterstützte Funktionen wurden zu einem Exfiltrationspfad

Die Kampagne endete nicht mit der Authentifizierung. Mandiant beobachtete Zugriff über Snowsight, SnowSQL, Treiber und Datenbank-Tools. Der Akteur listete Benutzer, Rollen, Sitzungen, Organisationsnamen, Datenbanken, Schemata und Tabellen auf. Er verwendete vertraute SQL-Operationen, um Daten auszuwählen, temporäre Staging-Bereiche zu erstellen, Abfrageergebnisse in komprimierte Dateien zu kopieren und diese Dateien auf einen lokalen Rechner abzurufen. In mehreren Fällen tauchten ähnliche Befehle in verschiedenen Kundenumgebungen auf.

Diese Sequenz macht den Vorfall als normale Funktionalität unter unbefugter Identität lesbar:

1. Ein gültiger Kundenbenutzername und ein gültiges Passwort stellten eine Sitzung her.
2. Die Sitzung erbte Rollen und Objektberechtigungen, die vom Kunden zugewiesen wurden.
3. Aufklärung identifizierte wertvolle Tabellen und verfügbare Staging-Bereiche.
4. Abfragen wählten Datensätze aus, die die Rolle lesen durfte.
5. Vorübergehendes Staging undCOPY INTOkonvertierten Ergebnisse in herunterladbare Dateien.
6. GETverschob Dateien zu einem vom Angreifer kontrollierten Client.

Kein Schritt in dieser Kette erforderte eine Fehlfunktion der Datenbank. Deshalb war die Verschlüsselung ruhender Daten, obwohl notwendig, nicht die entscheidende Kontrolle. SnowflakesDokumentation zur Ende-zu-Ende-Verschlüsselungbesagt, dass Kundendaten ruhend und während der Übertragung unter TLS verschlüsselt sind, erklärt aber auch, dass Snowflake Daten während Transformationen oder Tabellenoperationen entschlüsselt und Benutzern erlaubt, Ergebnisse zu entladen und herunterzuladen. Verschlüsselung schützt Dateien und Transport vor Parteien, die keine Autorisierung oder Schlüssel haben. Sie verhindert nicht, dass eine akzeptierte Identität mit einer erlaubten Rolle den Dienst auffordert, lesbare Ergebnisse zurückzugeben.

Das gleiche Prinzip gilt für kundenverwaltete Schlüssel. Schlüsselkontrolle kann Anbieter-, Speicher- und Widerrufsszenarien adressieren, aber ein laufendes Konto muss seine Schlüsselhierarchie verwenden, um autorisierte Abfragen zu bedienen. Sofern eine Schlüsselrichtlinie nicht mit einer separaten Entscheidung verbunden ist, die die Sitzung oder Operation ablehnt, kann die Datenbank den Kontoinhaber nicht von einem Eindringling unterscheiden, der die konfigurierte Authentifizierungsrichtlinie des Inhabers erfüllt hat.

Das Rollendesign kontrollierte daher den Radius nach der Anmeldung. Snowflakes aktuellesZugriffskontrollmodellunterstützt rollenbasierte und diskretionäre Zugriffskontrollen, Eigentum, Rollenhierarchie und Objektberechtigungen. Eine Anmeldedaten, die nur einer engen Datenbank oder Ansicht zugewiesen sind, haben andere Konsequenzen als eine mitACCOUNTADMIN, breiter Warehouse-Nutzung oder Lesezugriff auf Rohdatensätze. Ein Dienstkonto, das von einer Integration verwendet wird, sollte nicht die explorative Reichweite eines menschlichen Administrators erben. Die temporäre Rolle eines Auftragnehmers sollte mit dem Engagement ablaufen, anstatt mit einem gültigen Passwort ruhend zu bleiben.

Datenschutzrichtlinien können das Ergebnis auch bei Kompromittierung einer Rolle eingrenzen. SnowflakesDokumentation zur Klassifizierung sensibler Datenverbindet die Erkennung persönlicher und sensibler Spalten mit Maskierungs- und Zeilenzugriffsrichtlinien. Dies ist eine Beschreibung der aktuellen Fähigkeit, kein Beweis dafür, dass jeder betroffene Kunde seine Daten im Jahr 2024 klassifiziert oder maskiert hatte. Es stellt die Gestaltungsfrage: Hat der Kunde vollständige historische Tabellen für Identitäten offengelegt, die nur Aggregate, aktuelle Partitionen, tokenisierte Felder oder genehmigte Ansichten benötigten?

Der Export ist selbst eine privilegierte Geschäftsfunktion und sollte als solche behandelt werden. Ein Data Warehouse benötigt oft Massenentladungen für legitime Pipelines, Backups, Modelltraining und nachgelagerte Systeme. Ein pauschales Verbot ist selten realistisch. Aber das Erstellen eines Staging-Bereichs, das Entladen eines ungewöhnlich großen Ergebnisses oder die Verwendung eines unbekannten Clients und Netzwerkursprungs sollten beobachtbar sein und für risikoreiche Datensätze eine Genehmigung, Ratenbegrenzung, Zielbeschränkung, kurzlebige Erhöhung oder eine separate Exportrolle rechtfertigen.

Die Befehle der Kampagne waren normal genug, um ausgeführt zu werden, aber im Kontext ungewöhnlich genug, um eine schnelle Sicherheitsentscheidung zu verdienen.

Der Kunde besaß die Einstellung; Snowflake besaß die Basislinie

MFA ist der schärfste Test der gemeinsamen Verantwortung, da beide Seiten eine wahre Tatsache behaupten können. Der Kundenadministrator war in der Lage und wurde erwartet, es zu aktivieren. Snowflake bot MFA seit 2015 und Netzwerkrichtlinien seit 2016 an. Gleichzeitig konnten sich die erfolgreichen Konten im Jahr 2024 ohne MFA authentifizieren, was bedeutet, dass die effektive Basislinie des Dienstes für diese Konten einen Nur-Passwort-Pfad erlaubte.

Der Unterschied zwischen Verfügbarkeit und Durchsetzung ist nicht semantisch. Eine Sicherheitsfunktion kann kostenlos, dokumentiert und empfohlen sein und dennoch in den relevanten Sitzungen fehlen. Administratoren stehen vor alten Integrationen, nicht interaktiven Dienstbenutzern, Auftragnehmern, Break-Glass-Konten, mehreren Clients und der Angst vor Aussperrung. Diese Einschränkungen erklären Reibung bei der Einführung; sie rechtfertigen nicht, privilegierten menschlichen Zugriff von einem wiederverwendbaren Passwort abhängig zu machen.

Sie geben dem Anbieter auch Informationen, die benötigt werden, um Migrationswerkzeuge zu bauen, menschliche und Dienstidentitäten zu trennen und Ausnahmen explizit zu machen.

Nach der Kampagne bewegte sich Snowflakes öffentliche Ausrichtung von der Empfehlung zu stärkeren Voreinstellungen. SeineAnkündigung des Secure by Design-Versprechensvom Juli 2024 betonte MFA-Richtlinienkontrollen und Trust Center-Prüfungen. Im September 2024 erklärte Snowflake, dassMFA standardmäßig erzwungen wirdfür menschliche Benutzer in Konten, die ab Oktober 2024 erstellt wurden, während SSO mit Identitätsanbieter-MFA für Menschen und OAuth oder Schlüsselpaar-Authentifizierung für Dienste empfohlen wird. Die Unterscheidung zwischen neuen und bestehenden Konten ist wichtig. Eine sichere Voreinstellung schützt zukünftige Erstellung; sie kündigt nicht automatisch jeden vererbten Passwortpfad in der installierten Basis.

Snowflake führte späterLeaked Password Protectionein, das Bedrohungsinformationen nutzt, um gemeldete geleakte Passwörter in einem datenschutzschonenden Prozess zu testen und ein Passwort zu deaktivieren, wenn es als noch gültig bestätigt wird. Diese anbieterseitige Kontrolle adressiert direkt einen von UNC5537s Vorteilen: alte Infostealer-Anmeldedaten, die weiterhin verwendbar waren. Sie ist auch ein Beleg dafür, dass sich die gemeinsame Verantwortung weiterentwickeln kann. Kunden müssen weiterhin Identitäten und Rotationen verwalten, aber der Anbieter kann dienstübergreifende Intelligenz nutzen, um ein gestohlenes Passwort zu deaktivieren, bevor jeder Kunde es unabhängig findet.

Die aktuelleDokumentation zu Authentifizierungsrichtlinienermöglicht es Administratoren, erlaubte Methoden und Clients zu kontrollieren und MFA auf Konto- oder Benutzerebene zu verlangen. Sie warnt auch, dass Client-Typ-Beschränkungen nach bestem Bemühen erfolgen und nicht die einzige Sicherheitsgrenze sein sollten. Die aktuelleSchlüsselpaar-Anleitunggibt Dienstbenutzern eine Alternative zu statischen Passwörtern. Diese Seiten beschreiben Fähigkeiten, die bis 2026 verfügbar sind; sie dürfen nicht rückwärts als Beweis für die genauen Funktionen, Voreinstellungen oder den Durchsetzungszustand für jeden Kunden im April 2024 gelesen werden.

Standards helfen zu erklären, warum Anbietervoreinstellungen in die Analyse gehören. NISTs aktuelleAnleitung zur Authentifizierung und Authentifikatorverwaltungbehandelt Passwörter als nicht wiederholungsresistent und definiert Phishing-Resistenz als Protokolleigenschaft, die nicht von der Wachsamkeit des Benutzers abhängt. DasCISA Secure by Design-Versprechenvon 2024 identifiziert ausdrücklich Standard-MFA, anhaltende Produktaufforderungen, Basis-SSO-Unterstützung und Veröffentlichung von Einführungsmetriken als Mittel, mit denen Softwarehersteller die MFA-Nutzung messbar steigern können. Snowflake unterzeichnete dieses freiwillige Versprechen nach der Kampagne. Das Versprechen ist kein rechtliches Urteil über Snowflakes Design im Jahr 2024, aber es lehnt die Idee ab, dass das Anbieten eines Kontrollkästchens die Rolle des Anbieters erschöpft.

Die rechenschaftspflichtige Basislinie unterscheidet Identitätstypen. Menschliche Administratoren sollten phishing-resistente MFA oder eine stark regulierte föderierte Identität verwenden. Dienst-Workloads sollten Workload-Anmeldedaten verwenden, die begrenzt, rotiert und zugeordnet werden können, ohne vorzutäuschen, dass ein Roboter eine Push-Benachrichtigung beantworten kann. Break-Glass-Zugriff sollte selten, überwacht, zeitlich begrenzt und getestet sein. Auftragnehmeridentitäten sollten einen Besitzer, ein Ablaufdatum, eine genehmigte Gerätehaltung und keine clientübergreifende Wiederverwendung von Anmeldedaten haben.

Jede Ausnahme sollte in einem Dashboard erscheinen, dessen Nenner alle Identitäten sind, nicht nur aktive Mitarbeiter.

Netzwerkrichtlinie war ein zweites Tor, kein Ersatz für Identität

Mandiant's dritter wiederkehrender Faktor war das Fehlen von Netzwerk-Zulassungslisten. Eine gültige Anmeldedaten konnte daher von einer Infrastruktur verwendet werden, die keinen geschäftlichen Grund hatte, auf das Warehouse des Kunden zuzugreifen. Netzwerkbeschränkungen hätten ein gestohlenes Passwort nicht repariert, aber sie hätten dieses Passwort von einem nicht vertrauenswürdigen Ursprung aus unzureichend machen können.

Snowflakes aktuelleDokumentation zu Netzwerkrichtlinienmacht die Voreinstellung explizit: Ohne Richtlinie können Benutzer von jedem Computer oder Gerät aus verbinden. Kunden können IP-Bereiche und private Endpunkte zulassen oder blockieren, Kontrollen auf Konto- oder Benutzerebene anwenden und den Zugriff auf interne Staging-Bereiche mit zusätzlicher Konfiguration einschränken. Private Konnektivität und öffentliche Zugriffskontrollen können Konten mit hohem Sicherheitsbedarf weiter härten.

Der Kunde kennt seine genehmigten Büros, Cloud-Workloads, VPNs, Auftragnehmer und Integrationsendpunkte, daher muss der Kunde die nutzbare Zulassungsliste definieren. Snowflake kann nicht jeden legitimen Ursprung ableiten, ohne das Geschäft zu stören. Doch der Anbieter kontrolliert die Standarderreichbarkeit, die Richtliniensyntax, die Fähigkeit, eine Änderung zu simulieren, Aussperrungsschutz, Protokollierung und ob ein Administrator gewarnt wird, wenn keine Kontorichtlinie existiert.

Eine Plattform kann die Wahl des Kunden bewahren, während sie uneingeschränkten öffentlichen Zugriff zu einer sichtbaren, zeitlich begrenzten Ausnahme macht, anstatt zu einem stillen Dauerzustand.

Netzwerkregeln haben auch Grenzen. Angreifer können eine Sitzung von einem genehmigten Auftragnehmergerät aus erhalten, über ein erlaubtes Firmen-VPN leiten, eine Workload innerhalb der erlaubten Cloud kompromittieren oder einen Token nach der Authentifizierung stehlen. Große Unternehmen können wechselnde Ausgangsadressen haben, die statische Listen schwierig machen. Private Konnektivität kann SaaS-Tools ausschließen, die sie nicht unterstützen. Dies sind Gründe, Netzwerkkontrollen mit starker Identität und Verhaltenserkennung zu paaren, nicht Gründe, sie wegzulassen.

Die Kampagne demonstriert den Wert unabhängiger Tore. Passwortrotation hätte historische Anmeldedaten ungültig gemacht. MFA hätte einen weiteren Faktor erfordert. Eine Netzwerkrichtlinie hätte unbekannte Ursprünge abgewiesen. Das Prinzip der geringsten Privilegien hätte sichtbare Daten reduziert. Exportkontrollen hätten das Staging unterbrechen können. Erkennung hätte die Verweildauer verkürzen können. Keine einzelne Maßnahme ist perfekt; der Angreifer war dort erfolgreich, wo mehrere gleichzeitig fehlten oder zu permissiv waren.

Für die Rechenschaft benötigt jedes Tor einen Eigentümer und ein Wirksamkeitsmaß. „Netzwerkrichtlinie unterstützt“ ist eine Produkttatsache. „Jedes Produktionskonto hat eine getestete Richtlinie, die den Dienst und interne Staging-Bereiche abdeckt“ ist ein Betriebsergebnis. „MFA verfügbar“ ist eine Produkttatsache. „Kein privilegierter Mensch kann eine Sitzung allein mit einem wiederverwendbaren Passwort aufbauen“ ist ein Ergebnis. Gemeinsame Verantwortung wird nur dann sinnvoll, wenn beide Parteien die Ergebnisse an ihrer Grenze zeigen können.

Der Anbieter sah eine Kampagne, die jeder Kunde nur als einzelnen Vorfall sehen konnte

Ein einzelner Kunde konnte seine eigenen fehlgeschlagenen und erfolgreichen Anmeldungen, Clients, IP-Adressen, Abfragetexte, Rollen, Staging-Bereiche und Datenbewegungen überprüfen. Snowflake konnte Muster über Konten hinweg korrelieren: dieselbe Infrastruktur, ungewöhnliche Clients, wiederholte Aufklärung, ähnliche Staging-Befehle, eine Zunahme von Nur-Passwort-Anmeldungen oder mit Bedrohungsinformationen abgeglichene Anmeldedaten. Diese Asymmetrie ist die wichtigste nicht-vertragliche Verantwortung des Anbieters. Sie entsteht durch den Betrieb des Dienstes in großem Maßstab.

Snowflakes aktuelleLOGIN_HISTORY-Ansichtbehält ein Jahr Anmeldeversuche und enthält Benutzer, Ursprungs-IP, gemeldeten Client, erste und zweite Faktoren, Erfolg und zugehörige Risikodetails mit dokumentierter Latenz.QUERY_HISTORYbehält ein Jahr Abfrageaktivität und verbindet eine Abfrage mit dem authentifizierenden Ereignis, der Sitzung, dem Benutzer, der Rolle, dem Text, den Ergebnisbytes, entladenen Zeilen und über das Netzwerk gesendeten Bytes. Enterprise-Kunden könnenACCESS_HISTORYverwenden, um aufgerufene Tabellen, Ansichten, Spalten, Staging-Bereiche, Richtlinien und geänderte Objekte zu rekonstruieren. Diese Schemata liefern das Rohmaterial für eine qualitativ hochwertige Untersuchung.

Rohverlauf ist nicht dasselbe wie Erkennung. Ein Kunde muss Analysten Zugriff gewähren, die Daten exportieren oder abfragen, normales Verhalten verstehen, Warnungen schreiben, sie routen, falls erforderlich über native Fenster hinaus aufbewahren und eine Reaktion besetzen. Eine Telemetrielatenz von zwei Stunden mag für eine retrospektive Überprüfung akzeptabel sein, für einige Bulk-Export-Entscheidungen jedoch zu langsam. Eine Enterprise-Edition-Grenze für die Spaltenzugriffshistorie kann auch beeinflussen, wie genau ein Kunde das Gefährdungsausmaß eingrenzen kann.

Diese Produkt- und Betriebstatsachen sollten während der Beschaffung getestet werden, nicht erst nach einem Diebstahl entdeckt werden.

Snowflakes aktuellesTrust Centerprüft MFA-Anmeldung, Konto-Netzwerkrichtlinie, privilegierte Rollen, ruhende Benutzer, riskante Anmeldungen, ungewöhnliche IP-Adressen und große Datentransfers durch Sicherheits- und Bedrohungsinformationsscanner. Die aktuelle Dokumentation nennt auch Einschränkungen: Einige Pakete müssen aktiviert sein; einige Erkennungen können innerhalb einer Stunde eintreffen; und die Existenz einer konfigurierten Richtlinie beweist nicht, dass ihr Inhalt das beabsichtigte Ziel erreicht. Auch hier ist die aktuelle Fähigkeit kein Beweis dafür, was ein bestimmter Kunde oder Snowflake im Frühjahr 2024 erkannt hat. Sie zeigt, was ein Anbieter produktisieren kann, sobald ein kundenübergreifendes Fehlermuster verstanden ist.

Das Warnsystem sollte auf zwei Ebenen arbeiten. Auf der Mandantenebene benötigen Kunden sofortige, exportierbare Ereignisse und Kontrollen, um Aktivitäten zu blockieren oder auszusetzen. Auf der Anbieterebene benötigt Snowflake Kampagnenanalysen und einen geübten Prozess, um Kunden mit genügend Beweisen zu benachrichtigen, um zu handeln. Eine nützliche Benachrichtigung enthält Konto- und Benutzerkennungen, Zeitstempel in UTC, Quellinfrastruktur, Authentifizierungsfaktor, Sitzungs- und Abfrage-IDs, Befehle, berührte Objekte und Spalten, Staging-Aktionen, geschätztes Transfervolumen, Eindämmungsstatus und Vertrauensniveau.

„Potenziell betroffen“ ist eine angemessene Eröffnungsbezeichnung nur, wenn ihr die Beweise folgen, die zur Klärung des Potenzials erforderlich sind.

Anbietereingriff benötigt auch Governance. Das automatische Blockieren einer Kundensitzung kann die Produktion unterbrechen und über die vertragliche Befugnis des Anbieters hinausgehen. Nichtstun kann fortgesetzten Diebstahl ermöglichen. Das Design sollte daher Risikoschwellen, vorübergehende Sperren, Kundeneskalationskanäle, Notfallkontakte und einen schnellen Übersteuerungsprozess im Voraus definieren. Kunden sollten Personen benennen, die jederzeit eine Warnung mit hoher Schwere erhalten und eine Sperrung autorisieren können.

Der Anbieter sollte die Zeit vom kontoübergreifenden Signal bis zum Kundenkontakt, die Zeit bis zur Eindämmung und den Anteil der benachrichtigten Kunden messen, die ein vollständiges Beweispaket abrufen können.

Datenlokalität machte Zugriff nicht lokal

Snowflake vermarktet und dokumentiert regionale Bereitstellung, da Kunden Latenz-, Resilienz-, Datenschutz-, Regulierungs- und Souveränitätsanforderungen haben. SnowflakesDokumentation zu unterstützten Regionenbesagt, dass jedes Konto in einer Region gehostet wird und dass Daten in dieser Region bleiben, es sei denn, Benutzer kopieren, verschieben oder replizieren sie explizit. Dieselbe Seite enthält die kritische Einschränkung: Regionen bestimmen, wo Daten gespeichert und Rechenleistung bereitgestellt wird; sie schränken den Benutzerzugriff auf Snowflake nicht ein.

Diese Unterscheidung macht die UNC5537-Kette zu einem Souveränitätsfall. Vor dem Eindringen wurden die Tabellen eines Kunden möglicherweise an einem ausgewählten nationalen oder regionalen Cloud-Standort gespeichert und verarbeitet. Nach erfolgreicher Authentifizierung konnte der Angreifer das regionale Konto von anderswo abfragen, Ergebnisse staging und auf einen Client herunterladen. Mandiant beobachtete das technische Muster des lokalen Abrufs von temporären Staging-Bereichen.

Die öffentliche Kampagnenaufzeichnung legt weder das Herkunftsland noch das Zielland noch den rechtlichen Transferstatus für jedes Opfer fest, daher ist keine universelle Behauptung eines rechtswidrigen grenzüberschreitenden Transfers haltbar. Die Architektur zeigt dennoch, dass die Speicherlokalität allein die Benutzerlokalität nicht erzwingen konnte.

Regionsübergreifende Freigabe und Replikation schaffen einen separaten, legitimen Bewegungspfad. SnowflakesAnleitung zur regionsübergreifenden Freigaberät Organisationen, rechtliche und regulatorische Beschränkungen zu bestätigen, bevor Daten in eine andere Region oder ein anderes Land repliziert werden. Dies ist eine geplante Bewegung unter Kundenverwaltung. Anmeldedatengesteuerter Export ist anders: Er kann eine unkontrollierte Kopie außerhalb der ausgewählten Umgebung erstellen, ohne den Standort des Quellkontos zu ändern. Ein Dateninventar, das nur die Quellregion aufzeichnet, wird weiterhin „EU“ oder „Kanada“ angeben, selbst nachdem ein Angreifer eine Kopie entfernt hat.

Datensouveränität hat daher mindestens vier Schichten:

• Platzierung:wo die autoritativen Speicher- und Rechenressourcen bereitgestellt sind.
• Zugriff:welche menschlichen und maschinellen Identitäten verbinden dürfen, von welchen Geräten, Netzwerken und Gerichtsbarkeiten.
• Bewegung:welche Abfragen, Entladungen, Freigaben, Replikationen, Konnektoren und Downloads eine weitere Kopie erstellen dürfen.
• Beweise und Abhilfe:ob die Organisation nachweisen kann, woher der Zugriff kam, was abgeflossen ist, welche Personen oder regulierten Datensätze betroffen waren und wie schnell sie eindämmen und benachrichtigen kann.

Der Anbieter kontrolliert wichtige Teile aller vier Schichten, selbst wenn der Kunde die Richtlinie wählt. Er bietet Regionen an und hält Kontodaten in ihnen. Er authentifiziert Anfragen und stellt Netzwerkkontrollen bereit. Er führt Exportbefehle aus und zeichnet Abfragemetadaten auf. Er verfügt über kontoübergreifende Bedrohungssichtbarkeit und kann geleakte Passwörter deaktivieren. Der Kunde entscheidet über seine Rechtsgrundlage, Datenkategorien, Rollen, zulässige Ursprünge, Maskierung, Aufbewahrung und genehmigte Bewegung.

Eine regionale Hosting-Zusage ohne diese ergänzenden Kontrollen kann eine enge Anforderung an den Rechenzentrumsstandort erfüllen, während die praktische Befugnis zum globalen Kopieren von Daten exponieren bleibt.

Aus diesem Grund sollten Verschlüsselung und Souveränität nicht vermischt werden. Verschlüsselung kann ein gespeichertes Objekt vor dem Infrastrukturbetreiber oder einem unbefugten Speicherschicht-Leser schützen. Eine Anwendung, die das Objekt analysieren muss, macht Daten zwangsläufig für einen autorisierten Abfragekontext verfügbar. Wenn Identitätssicherung und Rollenumfang schwach sind, können kryptografische Lokalität und operative Exfiltration nebeneinander bestehen.

Kundenoffenlegungen zeigen unterschiedliche Konsequenzen, nicht einen einheitlichen Vorfall

Die Kampagne wird oft durch prominente Kundennamen beschrieben, aber die öffentliche Aufzeichnung jedes Kunden hat ihren eigenen Umfang, ihre eigenen Daten, Begriffe und Vertrauensniveau. Es ist unsicher, die Fakten eines Unternehmens auf ein anderes zu übertragen oder eine Behauptung aus einem kriminellen Forum in eine bestätigte Population umzuwandeln.

Live NationsForm 8-Kvom 31. Mai 2024 gab an, dass es am 20. Mai unbefugte Aktivitäten in einer Cloud-Datenbankumgebung eines Drittanbieters identifizierte, die Unternehmensdaten enthielt, hauptsächlich von Ticketmaster. Es sagte, dass am 27. Mai ein krimineller Akteur angebliche Unternehmensbenutzerdaten zum Verkauf anbot und dass Live Nation Strafverfolgungsbehörden, Regulierungsbehörden und Benutzer nach Bedarf benachrichtigte. Die Einreichung nannte Snowflake nicht, lieferte keine bestätigte Anzahl betroffener Personen oder erklärte den Authentifizierungspfad.

Ticketmaster CanadasVorfallseitebietet eine andere Detailtiefe. Sie beschreibt unbefugten Zugriff auf eine isolierte Cloud-Datenbank, die von einem externen Datendienstanbieter gehostet wird, sagt, dass die Datenbank begrenzte persönliche Informationen einiger nordamerikanischer Ticketkäufer enthielt, und listet mögliche Felder auf, darunter E-Mail, Telefonnummer, verschlüsselte Karteninformationen und andere von Kunden bereitgestellte Informationen. Sie sagt, dass Ticketmaster-Kundenkonten nicht betroffen waren. Diese letzte Grenze ist wichtig: Die Kompromittierung eines Backend-Data Warehouse ist kein Beweis dafür, dass der Angreifer die Ticketmaster-Anmeldung jeder Person erhalten hat oder über das Verbraucherkonto Transaktionen durchführen konnte.

Dasparlamentarische Merkblattdes kanadischen Datenschutzbeauftragten vom Oktober 2025 identifiziert Snowflake als den von Ticketmaster verwendeten Drittanbieter, gibt einen Vorfallszeitraum vom 2. April bis 18. Mai 2024 für Ticketmaster Canada an und sagt, dass personenbezogene Daten von Millionen, einschließlich Kanadiern, betroffen waren. Es sagt auch, dass die Untersuchung noch offen sei und dass Ticketmaster Canada als Datenverantwortlicher nach PIPEDA die untersuchte Einheit sei. Dies ist ein nützlicher regulatorischer Kontext, aber kein endgültiger Befund, der die Angemessenheit von Sicherheitsvorkehrungen, den Zeitpunkt der Benachrichtigung oder die Haftung klärt.

AT&TTsForm 8-Kvom 12. Juli 2024 veranschaulicht, warum Quellgrenzen wichtig sind, selbst wenn Vorfälle zusammen diskutiert werden. AT&T gab an, dass ein Akteur unrechtmäßig auf einen AT&T-Arbeitsbereich auf einer Cloud-Plattform eines Drittanbieters zugriff und Dateien vom 14. bis 25. April exfiltrierte. Die Dateien enthielten Anruf- und Textinteraktionsaufzeichnungen für fast alle AT&T-Wireless-Kunden und relevante Mobilfunknetzbetreiberkunden für bestimmte Zeiträume in 2022 und einen Tag in 2023. AT&T sagte, die Dateien enthielten keine Anruf- oder Textinhalte, Sozialversicherungsnummern, Geburtsdaten oder andere persönliche Informationen, wie AT&T diesen Begriff verwendete. Die Einreichung selbst nennt weder Snowflake noch UNC5537. Sie stützt AT&T's Vorfallsfakten, nicht eine Kampagnenzuschreibung allein.

Diese Aufzeichnungen ergeben vier Disziplinregeln. Erstens: Verwenden Sie die Einreichung eines Kunden nur für diesen Kunden. Zweitens: Unterscheiden Sie zwischen einer Datenbank, einem Organisationskonto und einer Verbraucheranmeldung. Drittens: Unterscheiden Sie Datenfelder von der Anzahl der Personen, die durch sie repräsentiert werden. Viertens: Bewahren Sie negative Fakten wie „kein Nachrichteninhalt“ oder „Verbraucherkonto nicht betroffen“ neben den Auswirkungen auf. Die Glaubwürdigkeit der Rechenschaft sinkt, wenn die Analyse dramatische Behauptungen ausweitet und einschränkende fallen lässt.

Kunden blieben für die Daten und Identitäten verantwortlich, die sie delegierten

Die Kundenseite der gemeinsamen Verantwortung ist erheblich. Die Organisation erstellte oder genehmigte Snowflake-Benutzer, wählte Authentifizierungspfade aus, wies Rollen zu, lud Daten hoch, bewahrte Verlauf auf, wählte eine Region, aktivierte Integrationen und entschied, welche Mitarbeiter und Auftragnehmer das Warehouse abfragen durften. Sie hatte auch die primäre Beziehung zu den in ihren Daten repräsentierten Personen und behielt in der Regel die Verantwortlichkeiten des Datenverantwortlichen nach geltendem Datenschutzrecht.

Ein Kunde hätte die beobachtete Kampagne an mehreren Punkten unterbrechen können. Er konnte Passwörter nach Endpunkt-Offenlegung rotieren, Nur-Passwort-Dienstkonten verbieten, MFA für Menschen verlangen, Zugriff über einen regulierten Identitätsanbieter föderieren, Netzwerke einschränken, Auftragnehmerbenutzer auslaufen lassen, Rollenberechtigungen reduzieren, sensible Felder klassifizieren und maskieren, Exportprivilegien isolieren, Anmelde- und Abfrageverlauf überwachen und Cloud-Anbieterbenachrichtigungen proben.

Für regulierte oder risikoreiche Datensätze sind dies grundlegende Betriebspflichten, keine optionalen Verbesserungen, die an die Beschaffung delegiert werden.

Die Governance von Endpunkten und Auftragnehmern verdient besondere Aufmerksamkeit. Ein Benutzer mit einer risikoreichen Cloud-Rolle sollte sich nicht von einem nicht verwalteten persönlichen Computer authentifizieren. Auftragnehmer sollten nach Möglichkeit kundenkontrollierte virtuelle Desktops oder Geräte mit Endpunktüberwachung verwenden. Ihre Identität sollte pro Kunde eindeutig sein, mit einem Sponsor verknüpft und automatisch ablaufen. Die Organisation sollte Anmeldedaten-Expositionsfeeds nach ihren Snowflake-Kontomustern durchsuchen und bei Auftauchen von Beweisen die Rotation erzwingen, ohne auf bestätigten Missbrauch zu warten.

Das Prinzip der geringsten Privilegien muss anhand von Daten getestet werden, nicht anhand von Jobtiteln. „Analyst“ mag nicht-administrativ klingen, behält aber möglicherweise den Lesezugriff auf jede Zeile in einer Kunden-, Mitarbeiter- oder Transaktionstabelle. Eine Rollenüberprüfung sollte fragen, welche Zeilen und Spalten zurückgegeben werden können, ob rohe Identifikatoren benötigt werden, ob Bulk-Result-Sets in Staging-Bereiche geschrieben werden können und ob die Identität neue Anmeldedaten oder Integrationen erstellen darf. Beispielabfragen unter der Rolle sind stärkere Beweise als ein sauber klingender Rollenname.

Kunden besitzen auch die Reaktionsbereitschaft. Sie sollten in der Lage sein, einen Snowflake-Benutzer einem Mitarbeiter oder Auftragnehmer zuzuordnen, eine Abfrage betroffenen Datensubjekten und einen Export einer Gerichtsbarkeit und einer Benachrichtigungsanalyse. Native Ein-Jahres-Verläufe können für längere rechtliche Aufbewahrung oder verspätete Entdeckung unzureichend sein, daher sollten risikoreiche Kunden relevante Ereignisse in einen unabhängigen Sicherheitsspeicher streamen.

Anbieterwarnungen benötigen einen getesteten Pfad zum Sicherheitsteam des Kunden, zur Datenschutzabteilung, zum Geschäftsinhaber und zur Entscheidungsträger auf Führungsebene.

NISTsLeitfaden zur Lieferkette des Cybersicherheitsrahmensempfiehlt, Anbieteranforderungen je nach Kritikalität zu definieren und zu kommunizieren. Angewendet auf diesen Fall sollte ein Snowflake-Kunde vertraglich den Zeitpunkt der Vorfallbenachrichtigung, Beweisfelder, Aufbewahrung, Support-Eskalation, regionale Verarbeitung, Sichtbarkeit von Unterauftragsverarbeitern, Kontrolländerungsmitteilung und Sicherstellungszugriff vereinbaren. Er sollte auch einen Ausstiegs- oder Isolationsplan für die Datenfunktionen unterhalten, deren Verlust oder Kompromittierung unerträglich wäre. Die gemeinsame Verantwortung sollte als testbare Schnittstellen geschrieben werden, nicht als ein Absatz, der erst nach einem Vorfall erscheint.

Snowflake blieb für die Risikominderung auf Dienstebene verantwortlich

Snowflake kontrollierte nicht die Malware auf dem persönlichen Gerät eines Auftragnehmers oder die Entscheidung des Kunden, MFA deaktiviert zu lassen. Es kontrollierte jedoch, ob ein altes Passwort der einzige Faktor bleiben konnte, ob uneingeschränkte Ursprünge die stille Voreinstellung waren, ob riskante Konfigurationen anhaltende Warnungen erzeugten und was der Anbieter tat, nachdem er ein Muster über Kunden hinweg beobachtet hatte.

Die Verantwortung des Anbieters in diesem Fall hat sechs Teile.

Sichere Basislinie.Privilegierter menschlicher Zugriff sollte nicht allein von einem wiederverwendbaren Passwort abhängen. Dienstidentitäten sollten einen separaten Typ und unterstützte Nicht-Passwort-Methoden haben. Neue Voreinstellungen sollten bestehende risikoreiche Konten durch gestaffelte Durchsetzung, explizite Ausnahmen und Migrationshilfe erreichen, anstatt nur neue Mandanten zu schützen.

Konfigurationstransparenz.Der Anbieter sollte Sicherheitsadministratoren einen vollständigen Nenner zeigen: Menschen ohne MFA, Legacy-Dienstbenutzer mit Passwörtern, ruhende Konten, Benutzer ohne Netzwerkbeschränkungen, privilegierte Rollen und Konten, die öffentlichen Zugang erlauben. Die Ergebnisse sollten auf Organisationsebene sichtbar und für Prüfungen exportierbar sein.

Kundenübergreifende Erkennung.Wiederverwendete Infrastruktur, geleakte Anmeldedaten, ungewöhnliche Clients, Aufklärungssequenzen, Erstellung temporärer Staging-Bereiche und große Exporte können ein Kampagnensignal bilden. Der Anbieter sollte auf Dienstebene erkennen, wahrscheinliche Opfer kontaktieren und definieren, wann hochsichere Aktivitäten eine vorübergehende Sperrung auslösen.

Aktionsfähige Telemetrie.Kunden benötigen Authentifizierungs-, Abfrage-, Objekt-, Staging- und Transferbeweise mit ausreichender Aufbewahrung und niedriger Latenz, um einen aktiven Diebstahl einzudämmen. Beweise mit höherer Genauigkeit sollten nicht genau dort nicht verfügbar werden, wo der Dienst die Daten mit der größten Auswirkung speichert.

Warnung und Koordination.Eine Kundenwarnung muss einen bekannten Notfallweg durchlaufen und Beweise enthalten, nicht nur Ratschläge, Protokolle zu überprüfen. Der Anbieter sollte Bestätigung, Eindämmung und wiederholte Offenlegung verfolgen und Anfragen von Strafverfolgungsbehörden und Regulierungsbehörden unterstützen, ohne unsichere Beobachtungen in bestätigte Opferzahlen umzuwandeln.

Überprüfung nach dem Vorfall.Angekündigte Funktionen und Voreinstellungen benötigen Einführungs- und Wirksamkeitsmessungen. Snowflakes spätere Änderungen hin zu Standard-MFA, Deaktivierung geleakter Passwörter, Trust Center-Ergebnissen und stärkeren Identitätstypen adressieren den beobachteten Pfad. Die verbleibende Rechenschaftsfrage ist die Abdeckung: Welche Benutzer und Clients sind tatsächlich geschützt, welche Ausnahmen bestehen noch und wie oft stoppt eine Kontrolle einen echten oder simulierten Versuch?

Diese Zuordnung macht Snowflake weder zum Datenverantwortlichen für jeden Kundendatensatz, noch macht sie den Anbieter für jede Kundenkonfiguration verantwortlich. Sie erkennt an, dass ein Cloud-Unternehmen davon profitiert, Daten zu konzentrieren und eine Sicherheitsgrenze zu betreiben. Der Maßstab schafft Pflichten, die nur der Anbieter erfüllen kann, insbesondere die kontoübergreifende Korrelation und die Basislinientechnik.

Spätere Gerichtsverfahren testen dieselbe Grenze, ohne sie bereits zu klären

Snowflake und betroffene Unternehmen sahen sich nach den Vorfällen einer konsolidierten Zivilklage gegenüber. In einerBundesgerichtsverfügungvom 29. Oktober 2025 entschied das Bezirksgericht Montana, dass klagende Finanzinstitute bestimmte Fahrlässigkeitstheorien gegen Snowflake und Ticketmaster ausreichend dargelegt hatten, um Anträge auf Abweisung zu überstehen. Das Gericht behandelte die behauptete Standard-MFA und Vorhersehbarkeit als relevant für Pflicht, Verletzung und Kausalität in diesem Verfahrensstadium.

Diese Verfügung ist kein Prozessurteil, dass Snowflake oder Ticketmaster fahrlässig waren. In einem Antrag auf Abweisung prüft das Gericht, ob gut dargelegte Behauptungen eine plausible Klage darlegen; es klärt keine streitigen Beweise, bestimmt nicht den endgültigen Vorfallsmechanismus für jeden Kläger oder teilt Schadensersatz zu. Snowflake bestritt die Behauptungen und argumentierte, dass die Nichterfüllung von MFA, Netzwerkrichtlinien und anderen Sicherheitsvorkehrungen durch Kunden den Schaden verursacht habe.

Die Verfügung ist bedeutsam, weil sie zeigt, dass die Beschreibung von MFA als Kundeneinstellung nicht automatisch jeden Anspruch auf Anbieterpflicht beendete. Sie ist kein Ersatz für die endgültige Sachverhaltsaufnahme.

Die kanadische Datenschutzuntersuchung hatte eine andere Zuordnung. Der OPC sagte, Ticketmaster Canada bleibe der Verantwortliche und sei die untersuchte Einheit, während das Büro Snowflake um Informationen kontaktierte. Dies spiegelt ein gängiges Datenschutzprinzip wider: Die Auslagerung der Speicherung lagert die Pflicht des Verantwortlichen zum Schutz und zur Benachrichtigung nicht aus. Es bedeutet nicht, dass der Dienstanbieter keine eigenen vertraglichen, technischen oder gesetzlichen Pflichten hat.

Snowflakes eigenes 10-K führte zahlreiche Klagen, behördliche Untersuchungen und Anfragen von Gesetzgebern auf, berichtete jedoch keine endgültige universelle Haftungszuweisung. Zum Zeitpunkt der Veröffentlichung unterstützen die hier überprüften öffentlichen Quellen weder die Erklärung, dass Snowflake rechtlich entlastet sei, noch dass jeder Kunde rechtlich schuld sei, noch dass ein endgültiges Gericht oder eine Regulierungsbehörde die operative Zuordnung dieses Artikels übernommen habe.

Die operative Rechenschaft kann vor der endgültigen Haftung bewertet werden. War Nur-Passwort-Zugriff vorhersehbar? Ja. Konnte der Kunde MFA und Netzwerkrichtlinien verlangen? Ja. Konnte Snowflake Voreinstellungen entwerfen und kontoübergreifende Aktivitäten erkennen? Ja. Haben Kriminelle den resultierenden Pfad vorsätzlich ausgenutzt? Ja. Diese Aussagen können nebeneinander bestehen. Delikts-, Vertrags-, Datenschutz- und Wertpapierrecht können die Konsequenzen je nach Gerichtsbarkeit und Kläger unterschiedlich zuweisen, aber die Technik sollte nicht auf einen Slogan warten, um zu gewinnen.

Ein messbarer Test der gemeinsamen Verantwortung

Die stärkste Antwort ist kein weiteres Diagramm mit „Kunde“ auf der einen und „Anbieter“ auf der anderen Seite. Es ist eine Reihe von Kontrollen, deren Abdeckung und Versagensverhalten demonstriert werden können.

Vorstände sollten Ergebnisse erhalten, keine Funktionsinventare. Nützliche Kennzahlen umfassen den Prozentsatz menschlicher Benutzer, die durch phishing-resistente MFA geschützt sind, die Anzahl der passwortfähigen Dienstbenutzer, das Alter jeder Break-Glass-Ausnahme, den Prozentsatz der Konten mit getesteten Netzwerkrichtlinien, die Anzahl privilegierter Auftragnehmeridentitäten nach Ablauf, die mediane Zeit bis zur Warnung bei unbekannten Ursprüngen, die Zeit bis zur Sperrung einer hochsicheren Sitzung und die Zeit bis zur Erstellung eines feldebene Offenlegungspakets.

Snowflake sollte aggregierte Fortschritte veröffentlichen, wo dies ohne Offenlegung von Kunden möglich ist. CISA-Versprechen sieht ausdrücklich Einführungsstatistiken nach Benutzer- und MFA-Typ vor. Eine Aussage, dass MFA verfügbar ist, ist weniger informativ als die Verteilung der Nur-Passwort-Anmeldungen im Zeitverlauf. Eine Aussage, dass Trust Center aktiviert ist, ist weniger informativ als wie viele kritische Befunde über einen definierten Zeitraum offen bleiben. Eine Aussage, dass verdächtige Kunden benachrichtigt wurden, ist weniger informativ als die Benachrichtigungslatenz und die Vollständigkeit des Beweispakets.

Kunden sollten von sich selbst dieselbe Strenge verlangen. Ein Anbieter kann eine Organisation nicht retten, die breite Rollen erstellt, Befunde ignoriert, alte Auftragnehmerbenutzer behält und niemanden hat, der den Notfallkontakt beantwortet. Der Zweck stärkerer Voreinstellungen ist nicht, das Eigentum an der Kundensicherheit auf Snowflake zu übertragen. Es ist, vorhersehbare Unterlassungen weniger wahrscheinlich zu machen, zu massenhaftem Datendiebstahl zu werden.

Was die öffentliche Aufzeichnung noch nicht feststellt

Die Beweise sind stark genug, um ein Kampagnenmuster zu rekonstruieren, aber nicht jeden Opfervorfall.

Die öffentliche Aufzeichnung identifiziert nicht alle benachrichtigten Organisationen, bestätigt nicht, dass alle 165 unbefugten Zugriff erlitten haben, oder liefert eine endgültige kampagnenweite Gesamtzahl betroffener Personen, Tabellen, Datensätze oder heruntergeladener Bytes. Sie zeigt nicht, welche Opfer Lösegeldforderungen bezahlt haben oder ob eine versprochene Löschung erfolgt ist.

Sie veröffentlicht nicht den Benutzertyp, die Rollenhierarchie, die MFA-Historie, die Netzwerkkonfiguration, den Endpunktbesitzer, die Sitzungssequenz, die aufgerufenen Spalten oder das Exportvolumen für jede Organisation. Erkenntnisse zu Auftragnehmergeräten aus mehreren Untersuchungen sollten nicht auf jedes Opfer übertragen werden. Die Statistik zur Offenlegung von Anmeldedaten von 79,7 % sollte nicht in einen Prozentsatz der Opfer umgewandelt werden.

Sie stellt keine Softwareschwachstelle, mandantenübergreifende Flucht, Kompromittierung von Snowflakes Produktionsplattform, Diebstahl einer Anbieter-Master-Anmeldedaten oder Zugriff auf jeden Snowflake-Kunden fest. Die beobachtete Verwendung unterstützter Clients und Befehle ist Beweis für Anmeldedatenmissbrauch, nicht dafür, dass der Produktcode ausgenutzt wurde.

Sie beweist nicht, dass regionale Daten bei jedem Vorfall eine nationale Grenze überschritten haben. Die Architektur erlaubte Fernzugriff und lokalen Download; eine rechtliche Transferanalyse würde Herkunft, Ziel, Datensubjekt, vertragliche und gerichtliche Fakten für jeden Kunden erfordern.

Sie erlaubt nicht, Ticketmasters mögliche Felder, AT&TTs Anrufdetailumfang oder eine Zählung aus einem kriminellen Forum auf andere Kunden zu verallgemeinern. Live Nations Einreichung nannte Snowflake nicht. AT&TTs Einreichung nannte weder Snowflake noch UNC5537. Externe Assoziation kann für weitere Untersuchungen relevant sein, aber die Einreichungen sollten für das zitiert werden, was sie tatsächlich feststellen.

Schließlich beweist die aktuelle Snowflake-Dokumentation nicht die Funktionsweise der Kontrollen im April und Mai 2024. Spätere Standard-MFA, Schutz geleakter Passwörter, Trust Center-Erkennung, Authentifizierungsrichtlinien und Identitätsänderungen können Wiederholungen reduzieren, aber öffentliche Beweise für Einführung, Ausnahmenabdeckung, Erkennungsleistung und unabhängige Wirksamkeit bleiben begrenzter als die Funktionsbeschreibungen.

Gemeinsame Verantwortung muss den Moment überleben, in dem eine Empfehlung ignoriert wird

Die Snowflake-Kampagne wird am besten nicht als Wettbewerb zwischen zwei absoluten Geschichten verstanden. Eine Geschichte besagt, dass die Plattform gehackt wurde und allein der Anbieter versagte. Die Beweise stützen dies nicht. Die andere besagt, dass Kunden Passwörter verloren haben und die Anbieterfrage damit erledigt ist. Dies ist technisch unvollständig.

UNC5537 fand eine skalierbare Schnittstelle zwischen Endpunktkompromittierung und Cloud-Konzentration. Historische Passwörter blieben gültig. Menschliche und Dienstidentitäten waren nicht immer getrennt. MFA- und Netzwerktore fehlten. Unterstützte Abfrage- und Staging-Funktionen bewegten Daten schnell. Der Anbieter konnte ein Muster über Mandanten hinweg sehen, während jeder Kunde nur sein eigenes Konto sah. Eine gewählte Speicherregion konnte die Quelldaten an Ort und Stelle halten, selbst als eine authentifizierte Sitzung anderswo eine unkontrollierte Kopie erstellte.

Kunden hatten die klarste Pflicht, ihre Benutzer, Rollen, Endpunkte, Auftragnehmer und Daten zu verwalten. Snowflake hatte die klarste Pflicht, die Dienstgrenze zu sichern und zu beobachten, hochwertige Schutzmaßnahmen einfach und zunehmend unvermeidlich zu machen, Kampagnenverhalten zu erkennen und Beweise zu liefern. Die Angreifer trugen die direkte Verantwortung für die Straftaten. Regulierungsbehörden und Gerichte müssen die rechtlichen Pflichten auf der Grundlage der Fakten und des auf jede Organisation anwendbaren Rechts bewerten. Diese Zuordnungen überschneiden sich, weil sich die Kontrollen überschneiden.

Die Produktrichtung nach der Kampagne erkennt implizit die Lücke zwischen Fähigkeit und Ergebnis. Standard-MFA für neue menschliche Benutzer, Deaktivierung geleakter Passwörter, stärkere Authentifizierungsrichtlinie, Dienstbenutzermigration und Trust Center-Ergebnisse bringen Sicherheit näher an die Anbieterbasislinie. Sie löschen die Kundenverantwortung nicht. Sie machen das gemeinsame System weniger abhängig davon, dass jeder Administrator vor dem Test eines gestohlenen Passworts jede richtige Option findet und aktiviert.

Das ist der dauerhafte Rechenschaftstest für eine Cloud-Datenplattform. Nehmen Sie an, dass ein Kunde eine Warnung übersieht, ein Auftragnehmergerät infiziert wird, eine Anmeldedaten gültig bleibt und ein Angreifer gewöhnliche Produktfunktionen verwendet. Fragen Sie dann, ob die Voreinstellung die Anmeldung blockiert, ein anderes Tor den Ursprung abweist, die Rolle wenig preisgibt, der Export einen Eingriff auslöst und die Beweise den Kunden rechtzeitig erreichen.

Gemeinsame Verantwortung ist nur glaubwürdig, wenn der Dienst nach einem vorhersehbaren Fehler einer Partei verteidigungsfähig bleibt und wenn beide Parteien beweisen können, was sie davor und danach getan haben.