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 gab an, dass jeder von Mandiant direkt bearbeitete Kampagnenvorfall auf kompromittierte Kundenanmeldedaten zurückging. Es fand keine Hinweise darauf, dass der unbefugte Kunden zugriff durch einen Einbruch in Snowflakes Unternehmensumgebung verursacht wurde. Snowflake erklärte ebenfalls, dass es keine Hinweise auf eine Sicherheitslücke, Fehlkonfiguration oder einen Einbruch in seine Plattform gebe, die diese Aktivität verursacht hätten.
• Beobachtete Kontrollkette:Die erfolgreichen Konten besaßen keine Multi-Faktor-Authentifizierung, enthielten Anmeldedaten, die in historischen Infostealer-Aufzeichnungen offengelegt waren, und verfügten über keine Netzwerk-Zulassungslisten. Die Angreifer nutzten dann unterstützte Snowflake-Clients und SQL-Befehle, um Daten aufzulisten, zu sammeln, zu komprimieren und herunterzuladen. Etwa 165 Organisationen wurden als potenziell betroffen benachrichtigt; dies ist keine Zahl bestätigter Sicherheitsverletzungen, Personen oder Datensätze.
• Erkenntnis zur geteilten Verantwortung:Kunden kontrollierten ihre Benutzer, Rollen, Passwortrotation, MFA-Aktivierung, Netzwerkrichtlinien, Endgerätehygiene 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 strengere Standardverhalten die installierte Basis erreichten. Diese Verantwortlichkeiten bestehen gleichzeitig, nicht gegenseitig ausschließend.
• Erkenntnis zur Souveränität:Die Wahl einer Snowflake-Region bestimmt, wo die Speicherung und Berechnung des Kontos erfolgen; Snowflakes Dokumentation stellt ausdrücklich klar, 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-, Ausgabe- und Beweiskontrollen ist eine Entscheidung über die Platzierung, keine vollständige Souveränitätskontrolle.

Die Plattform wurde nicht als gehackt nachgewiesen, aber die Dienstbeziehung wurde getestet

Die erste Disziplin in diesem Fall ist die Begrifflichkeit. Eine Snowflake-Kundeninstanz war nicht dasselbe wie Snowflakes eigene Unternehmensumgebung oder die gemeinsame Produktionsplattform. Eine Person mit gültigen Anmeldedaten konnte auf das Konto eines Kunden zugreifen, ohne in einen anderen Mandanten einzudringen, eine Softwaresicherheitslücke auszunutzen, ein Administrator-Konto des Anbieters zu erlangen oder die Infrastruktur zu durchbrechen, die Kunden trennte. Die öffentlichen Beweise stützen die Kompromittierung von Kundenkonten. Sie stützen keine plattformweite technische Kompromittierung.

Mandians UNC5537-Kampagnenbericht ist in diesem Punkt ungewöhnlich direkt. Bei jedem 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 eigene Untersuchungs- und Härtungshinweise trennten ebenfalls betroffene Kundenkonten von der Produktionsplattform und gaben Kunden Abfragen und Indikatoren zur Untersuchung ihrer eigenen Umgebungen.

CISA verstärkte diese Anleitung in einer Warnung vom 3. Juni 2024.

Diese negative Feststellung ist wichtig. Das Ereignis als Einbruch in Snowflakes Plattform zu bezeichnen, könnte implizieren, dass ein Defekt im gemeinsamen Code oder der Infrastruktur alle Mandanten öffnete oder dass Snowflake eine Master-Anmeldeinformation verlor, die Kunden freischaltete. Der überprüfte Datensatz 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 überprüfen, Netzwerke einschränken, Rollenberechtigungen reduzieren und Beweise sichern.

Der umgekehrte Fehler besteht darin, das Fehlen eines Plattform-Einbruchs als Fehlen einer Frage zur Rechenschaftspflicht des Anbieters zu behandeln. Ein Cloud-Dienst ist nicht nur eine neutrale Festplatte, auf der ein Kunde zufällig Bits ablegt. Snowflake hat die Authentifizierungsendpunkte gebaut und betrieben, 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 Produktsteuerungen, die einen zweiten Faktor hätten erfordern oder den Netzwerkursprung einschränken können.

Snowflake hatte auch eine kundenübergreifende Sichtbarkeit, die kein einzelner Kunde besitzen konnte. Die Tatsache, dass eine entscheidende Kontrolle vom Kunden konfiguriert werden konnte, bestimmt, wer eine operative Pflicht hatte, sie zu konfigurieren. 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 2025 Form 10-K formalisiert seine Position. Es besagt, dass Snowflake für die Sicherheit der Plattform und der zugrunde liegenden Cloud-Infrastruktur 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 Pflichten wie MFA und Netzwerkrichtlinien durch die Kunden zurück, während es Klagen, behördliche Untersuchungen, Anfragen von Gesetzgebern, Reputationsschäden und die Möglichkeit von Freistellungsstreitigkeiten dokumentiert.

Dies sind wesentliche Unternehmensbeweise für 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 gehackt?“ und weiter als „Wessen Passwort wurde gestohlen?“ Sie lautet: In jedem Schritt von gestohlenem Geheimnis bis zu heruntergeladenen Daten, welcher Akteur konnte die Aktion verhindern, erkennen, unterbrechen, rekonstruieren oder warnen? Rechenschaftspflicht folgt der Kontrolle über diese Schritte.

Die Kampagne verband alten Endgeräte-Diebstahl mit aktueller Cloud-Berechtigung

Mandiant erhielt im April 2024 erstmals Bedrohungsinformationen über Datenbankdatensätze, die später auf eine Snowflake-Instanz eines Opfers zurückgeführt wurden. Dieses Opfer beauftragte Mandiant, das zu dem Schluss kam, dass der Eindringling zuvor durch Infostealer-Malware gestohlene Anmeldedaten verwendet hatte. Das betreffende Konto hatte keine MFA aktiviert. Am 22. Mai, nachdem Informationen identifiziert wurden, die auf eine breitere Kampagne hindeuteten, kontaktierte Mandiant Snowflake und begann, potenzielle Opfer zu benachrichtigen. Snowflake veröffentlichte am 30. Mai Kunden-Erkennungs- und Härtungsanleitungen.

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

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

Die Anmeldeverlauf erklärt, warum eine Cloud-Anmeldung im Jahr 2024 mit einer Endgeräteinfektion Jahre zuvor beginnen konnte. Mandiant fand heraus, 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 hatten zuvor eine Offenlegung von Anmeldedaten. Dieser Prozentsatz bezieht sich auf Konten, die der Akteur in der analysierten Kampagne genutzt hat, 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. Den betroffenen Kundeninstanzen fehlten 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: Kenne den Kontolocator, Benutzernamen und das noch gültige Passwort; verbinde von einem angreifergesteuerten System; erhalte eine Sitzung;

erbe die zugewiesene Rolle; frage ab, was diese Rolle lesen darf.

Die Endgeräte-Dimension war darüber hinaus verteilter, als eine herkömmliche Erzählung über ein Mitarbeiter-Laptop 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, einschließlich Gaming oder heruntergeladener Inhalte. Ein Gerät eines Auftragnehmers kann außerhalb der verwalteten Endgeräteflotte des Kunden liegen, während es Anmeldedaten für mehrere Kunden trägt. Es kann auch ein Administratorkonto besitzen, da spezialisierte Auftragnehmer oft zur Einrichtung oder zum Betrieb von Datenplattformen eingestellt werden.

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 Endgerätewerkzeuge des Kunden unsichtbar sein.

Dies ist ein Cloud-Abhängigkeitsmultiplikator. Die Anmeldedaten werden von einem Endgerät gestohlen, möglicherweise außerhalb der Flotte von Snowflake oder des Dateninhabers. Die Anmeldedaten werden von einem globalen Dienst akzeptiert. Die Rolle kann ein konsolidiertes Data Warehouse erreichen, das Jahre von Datensätzen 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 das Stehlen, Kaufen, Testen und Verwenden von Anmeldedaten; das Eindringen in Kundenumgebungen ohne Autorisierung; das Entwenden von Daten; 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 bei der Authentifizierung. Mandiant beobachtete Zugriff über Snowsight, SnowSQL, Treiber und Datenbankwerkzeuge. Der Akteur listete Benutzer, Rollen, Sitzungen, Organisationsnamen, Datenbanken, Schemata und Tabellen auf. Er verwendete vertraute SQL-Befehle, um Daten auszuwählen, temporäre Staging-Bereiche zu erstellen, Abfrageausgaben in komprimierte Dateien zu kopieren und diese Dateien auf einen lokalen Rechner abzurufen. In mehreren Fällen traten ä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 auf einen angreifergesteuerten Client.

Kein Schritt in dieser Kette erforderte eine Fehlfunktion der Datenbank. Dies ist der Grund, warum Verschlüsselung ruhender Daten, obwohl notwendig, nicht die entscheidende Kontrolle war. Snowflakes Ende-zu-Ende-Verschlüsselungsdokumentation besagt, dass Kundendaten ruhend und unter TLS während der Übertragung verschlüsselt sind, aber sie erklärt auch, dass Snowflake Daten entschlüsselt, während Transformationen oder Tabellenoperationen durchgeführt werden, und es 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.

Dasselbe Prinzip gilt für kundenverwaltete Schlüssel. Schlüsselkontrolle kann sich mit Anbieter-, Speicher- und Widerrufsszenarien befassen, 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 dem Login. Snowflakes aktuelles Zugriffskontrollmodell unterstützt rollenbasierte und diskretionäre Zugriffskontrollen, Eigentümerschaft, Rollenhierarchie und Objektberechtigungen. Eine Anmeldeinformation, die nur einer engen Datenbank oder Ansicht zugewiesen ist, hat eine andere Konsequenz als eine mitACCOUNTADMIN, breiter Warehouse-Nutzung oder Lesezugriff auf rohe Datensä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 auslaufen, nicht mit einem gültigen Passwort ruhen.

Datenrichtlinien können das Ergebnis auch bei kompromittierter Rolle einschränken. Snowflakes Dokumentation zur Klassifizierung sensibler Daten verbindet die Erkennung persönlicher und sensibler Spalten mit Maskierungs- und Zeilenzugriffsrichtlinien. Dies ist eine Beschreibung der aktuellen Funktionalität, kein Beweis dafür, dass jeder betroffene Kunde seine Daten im Jahr 2024 klassifiziert oder maskiert hatte. Es etabliert die Designfrage: Hat der Kunde vollständige historische Tabellen Identitäten ausgesetzt, die nur Aggregate, aktuelle Partitionen, tokenisierte Felder oder genehmigte Ansichten benötigten?

Export ist selbst eine privilegierte Geschäftsfunktion und sollte als solche behandelt werden. Ein Data Warehouse benötigt oft Bulk-Unloads 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 sollte beobachtbar sein und für risikoreiche Datensätze möglicherweise eine Genehmigung, Ratenbegrenzung, Zielbeschränkungen, kurzlebige Erhöhung oder eine separate Exportrolle rechtfertigen.

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

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

MFA ist der schärfste Test der geteilten Verantwortung, da beide Seiten eine wahre Tatsache angeben können. Der Kundenadministrator war in der Lage und erwartet, sie zu aktivieren. Snowflake bot MFA seit 2015 und Netzwerkrichtlinien seit 2016 an. Gleichzeitig konnten die erfolgreichen Konten im Jahr 2024 ohne MFA authentifizieren, was bedeutet, dass die effektive Grundlinie 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, 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 die Reibung bei der Einführung; sie rechtfertigen es 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 hin zu stärkeren Voreinstellungen. Die Ankündigung des Secure by Design-Versprechens im Juli 2024 betonte MFA-Richtlinienkontrollen und Trust-Center-Überprüfungen. Im September 2024 erklärte Snowflake, dass MFA für menschliche Benutzer in ab Oktober 2024 erstellten Konten standardmäßig erzwungen würde, während SSO mit Identitätsanbieter-MFA für Menschen und OAuth oder Schlüsselpaar-Authentifizierung für Dienste empfohlen wurden. Die Unterscheidung zwischen neuen und bestehenden Konten ist wichtig. Eine sichere Voreinstellung schützt zukünftige Erstellungen;

sie entfernt nicht automatisch jeden geerbten Passwortpfad in der installierten Basis.

Snowflake führte später Leaked Password Protection ein, das Bedrohungsintelligenz-Feeds verwendet, um gemeldete durchgesickerte 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 UNC5537's Vorteilen: alte Infostealer-Anmeldedaten, die weiterhin verwendbar waren. Sie ist auch ein Beweis dafür, dass sich geteilte Verantwortung weiterentwickeln kann.

Kunden müssen weiterhin Identitäten und Rotationen verwalten, aber der Anbieter kann kundenübergreifende Intelligenz nutzen, um ein gestohlenes Passwort unwirksam zu machen, bevor jeder Kunde es unabhängig findet.

Aktuelle Dokumentation zu Authentifizierungsrichtlinien ermöglicht es Administratoren, zulässige Methoden und Clients zu steuern und MFA auf Konto- oder Benutzerebene zu erzwingen. Sie warnt auch davor, dass Client-Typ-Beschränkungen unverbindlich sind und nicht die einzige Sicherheitsgrenze darstellen sollten. Aktuelle Schlüsselpaar-Anleitungen geben Dienstbenutzern eine Alternative zu statischen Passwörtern. Diese Seiten beschreiben Fähigkeiten, die bis 2026 verfügbar sind; sie dürfen nicht rückwirkend als Beweis für die genauen Funktionen, Voreinstellungen oder den Durchsetzungsstatus für jeden Kunden im April 2024 gelesen werden.

Standards helfen zu erklären, warum Anbietervoreinstellungen in die Analyse gehören. NISTs aktuelle Leitlinien zur Authentifizierung und Authentifikatorverwaltung behandeln Passwörter als nicht wiederholungssicher und definieren Phishing-Resistenz als Protokolleigenschaft, die nicht von der Wachsamkeit des Benutzers abhängt. Das CISA Secure by Design-Versprechen von 2024 identifiziert ausdrücklich Standard-MFA, anhaltende Produkt-nudges, grundlegende SSO-Unterstützung und Veröffentlichung von Einführungsmetriken als Möglichkeiten, mit denen Softwarehersteller die MFA-Nutzung messbar erhöhen können.

Snowflake hat dieses freiwillige Versprechen nach der Kampagne unterzeichnet. Das Versprechen ist kein rechtliches Urteil über Snowflakes Design im Jahr 2024, aber es lehnt die Idee ab, dass das Anbieten einer Checkbox die Rolle des Anbieters erschöpft.

Die verantwortliche Grundlinie unterscheidet Identitätstypen. Menschliche Administratoren sollten phishing-resistente MFA oder eine stark verwaltete föderierte Identität verwenden. Arbeitslasten sollten Arbeitsanmeldedaten verwenden, die eingegrenzt, rotiert und zurückverfolgt 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 Eigentümer, ein Ablaufdatum, einen genehmigten Gerätestatus und keine kundenü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

Mandians dritter wiederkehrender Faktor war das Fehlen von Netzwerk-Zulassungslisten. Eine gültige Anmeldeinformation konnte daher von einer Infrastruktur aus verwendet werden, die keinen geschäftlichen Grund hatte, das Data Warehouse des Kunden zu erreichen. Netzwerkbeschränkungen würden ein gestohlenes Passwort nicht reparieren, aber sie könnten dieses Passwort von einem nicht vertrauenswürdigen Ursprung aus unzureichend machen.

Snowflakes aktuelle Dokumentation zu Netzwerkrichtlinien macht die Voreinstellung explizit: Ohne Richtlinie können Benutzer von jedem Computer oder Gerät aus eine Verbindung herstellen. 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 Zugriffskontrollen für öffentliche Zugänge können hochsensible Konten 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 steuert die standardmäßige Erreichbarkeit, die Richtliniensyntax, die Möglichkeit, eine Änderung zu simulieren, den Aussperrungsschutz, die 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 Unternehmens-VPN leiten, eine Workload innerhalb der zulässigen Cloud kompromittieren oder einen Token nach der Authentifizierung stehlen. Große Unternehmen können sich ändernde Ausgangsadressen haben, die statische Listen erschweren. 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 sie wegzulassen.

Die Kampagne zeigt 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 abgelehnt. Least Privilege 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 erfolgreich, wo mehrere gleichzeitig fehlten oder zu permissiv waren.

Für die Rechenschaftspflicht 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 operatives Ergebnis. „MFA verfügbar“ ist eine Produkttatsache. „Kein privilegierter Mensch kann eine Sitzung mit einem wiederverwendbaren Passwort allein aufbauen“ ist ein Ergebnis. Geteilte 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 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ärungen, ähnliche Staging-Befehle, eine Zunahme von Nur-Passwort-Anmeldungen oder mit Bedrohungsintelligenz-Feeds 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 aktuelle LOGIN_HISTORY-Ansicht behält ein Jahr Anmeldeversuche und umfasst Benutzer, Ursprungs-IP, gemeldeten Client, ersten und zweiten Faktor, Erfolg und zugehörige Risikodetails mit dokumentierter Latenz. QUERY_HISTORY behält ein Jahr Abfrageaktivität und verbindet eine Abfrage mit dem authentifizierenden Ereignis, der Sitzung, dem Benutzer, der Rolle, dem Text, Ergebnisbytes, entladenen Zeilen und über das Netzwerk gesendeten Bytes. Enterprise-Kunden können ACCESS_HISTORY verwenden, um aufgerufene Tabellen, Ansichten, Spalten, Staging-Bereiche, Richtlinien und geänderte Objekte zu rekonstruieren.

Diese Schemata bieten 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 weiterleiten, sie nach nativen Fenstern aufbewahren, falls erforderlich, und eine Reaktion durchführen. Eine Telemetrielatenz von zwei Stunden kann für eine retrospektive Überprüfung akzeptabel sein, aber für bestimmte Bulk-Export-Entscheidungen zu langsam. Eine Enterprise-Edition-Grenze für den Spaltenzugriffsverlauf kann auch beeinflussen, wie genau ein Kunde den Umfang der Offenlegung eingrenzen kann.

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

Snowflakes aktuelles Trust Center überprüft MFA-Aktivierung, Konto-Netzwerkrichtlinie, privilegierte Rollen, ruhende Benutzer, riskante Anmeldungen, ungewöhnliche IP-Adressen und große Datenübertragungen durch Sicherheits- und Bedrohungsintelligenz-Scanner. Die aktuelle Dokumentation nennt auch Einschränkungen: Einige Pakete müssen aktiviert werden; 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 Funktionalität 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 ausreichenden Beweisen zum Handeln zu benachrichtigen. 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 Übertragungsvolumen, Eindämmungsstatus und Konfidenz.

„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 die vertragliche Befugnis des Anbieters überschreiten. Untätigkeit kann fortgesetzten Diebstahl ermöglichen. Das Design sollte daher Risikoschwellen, vorübergehende Halten, Kunden-Eskalationskanäle, Notfallkontakte und einen schnellen Übersteuerungsprozess im Voraus definieren. Kunden sollten Personen benennen, die jederzeit eine Warnung mit hohem Schweregrad erhalten und eine Aussetzung autorisieren können.

Der Anbieter sollte die Zeit von kontoübergreifendem Signal bis Kundenkontakt, Zeit bis 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 Anforderungen an Latenz, Ausfallsicherheit, Datenschutz, Regulierung und Souveränität haben. Snowflakes Dokumentation zu unterstützten Regionen besagt, dass jedes Konto in einer Region gehostet wird und dass Daten in dieser Region verbleiben, es sei denn, Benutzer kopieren, verschieben oder replizieren sie explizit. Dieselbe Seite enthält die kritische Einschränkung: Regionen legen fest, wo Daten gespeichert und Rechenleistung bereitgestellt wird; sie schränken den Benutzerzugriff auf Snowflake nicht ein.

Diese Unterscheidung verwandelt die UNC5537-Kette in einen Souveränitätsfall. Vor dem Eindringen könnten die Tabellen eines Kunden in einem ausgewählten Land oder regionalen Cloud-Standort gespeichert und verarbeitet worden sein. Nach erfolgreicher Authentifizierung konnte der Angreifer das regionale Konto von woanders abfragen, Ergebnisse sammeln und auf einen Client herunterladen. Mandiant beobachtete das technische Muster des lokalen Abrufs aus temporären Staging-Bereichen.

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

Regionsübergreifende Freigabe und Replikation schaffen einen separaten, legitimen Bewegungspfad. Snowflakes Leitfaden für regionsübergreifende Freigabe fordert Organisationen auf, rechtliche und regulatorische Einschränkungen zu bestätigen, bevor Daten in eine andere Region oder ein anderes Land repliziert werden. Dies ist eine geplante Bewegung unter Kundenverwaltung. Anmeldedatengetriebener 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 werden.
• Zugriff:Welche menschlichen und maschinellen Identitäten sich 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ämmung und Benachrichtigung durchführen kann.

Der Anbieter kontrolliert wichtige Teile aller vier Schichten, auch 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 hält kundenübergreifende Bedrohungssichtbarkeit und kann durchgesickerte Passwörter deaktivieren. Der Kunde entscheidet über seine Rechtsgrundlage, Datenkategorien, Rollen, erlaubte Ursprünge, Maskierung, Aufbewahrung und genehmigte Bewegung.

Eine regionale Hosting-Verpflichtung ohne diese ergänzenden Kontrollen kann eine enge Rechenzentrumsstandortanforderung erfüllen, während die praktische Befugnis zum globalen Kopieren von Daten offen bleibt.

Dies ist auch der Grund, warum Verschlüsselung und Souveränität nicht gleichgesetzt werden sollten. Verschlüsselung kann ein gespeichertes Objekt vor dem Infrastrukturbetreiber oder einem unbefugten Speicherschichtleser schützen. Eine Anwendung, die das Objekt analysieren muss, stellt Daten notwendigerweise in einem autorisierten Abfragekontext zur Verfügung. Wenn Identitätssicherung und Rollenumfang schwach sind, kann kryptografische Lokalität mit operativer Exfiltration koexistieren.

Kundenoffenlegungen zeigen unterschiedliche Konsequenzen, keinen einheitlichen Einbruch

Die Kampagne wird oft mit prominenten Kundennamen beschrieben, aber die öffentlichen Aufzeichnungen jedes Kunden haben ihren eigenen Umfang, Daten, Terminologie und Konfidenz. Es ist unsicher, Fakten eines Unternehmens auf ein anderes zu übertragen oder eine Behauptung aus einem kriminellen Forum in eine bestätigte Population umzuwandeln.

Live Nations Form 8-K vom 31. Mai 2024 Form 8-K gab an, dass es am 20. Mai unbefugte Aktivitäten in einer Cloud-Datenbankumgebung eines Drittanbieters identifizierte, die Unternehmensdaten, hauptsächlich von Ticketmaster, enthielt. Es gab an, dass am 27. Mai ein krimineller Akteur das angebliche Angebot von Benutzerdaten des Unternehmens zum Verkauf anbot und dass Live Nation Strafverfolgungsbehörden, Aufsichtsbehörden und Benutzer nach Bedarf benachrichtigte. Die Einreichung nannte Snowflake nicht, bot keine bestätigte Zahl betroffener Personen und erklärte den Authentifizierungspfad nicht.

Ticketmaster Canadas Vorfallsseite gibt eine andere Detailtiefe. Sie beschreibt unbefugten Zugriff auf eine isolierte Cloud-Datenbank, die von einem Drittanbieter-Datendienstleister gehostet wird, besagt, dass die Datenbank begrenzte persönliche Informationen einiger nordamerikanischer Ticketkäufer enthielt, und listet mögliche Felder wie E-Mail, Telefonnummer, verschlüsselte Karteninformationen und andere von Kunden bereitgestellte Informationen auf. Es besagt, dass Ticketmaster-Kundenkonten nicht betroffen waren.

Diese letzte Grenze ist wichtig: Die Kompromittierung eines Backend-Data Warehouses ist kein Beweis dafür, dass der Angreifer den Login jedes Einzelnen bei Ticketmaster erhalten hat oder über das Verbraucherkonto Transaktionen durchführen konnte.

Das parlamentarische Informationsblatt des kanadischen Datenschutzbeauftragten vom Oktober 2025 parlamentarisches Informationsblatt identifiziert Snowflake als den von Ticketmaster genutzten Drittanbieter, gibt einen Vorfallszeitraum vom 2. April bis 18. Mai 2024 für Ticketmaster Canada an und besagt, dass personenbezogene Daten von Millionen, einschließlich Kanadiern, betroffen waren. Es gab auch an, dass die Untersuchung noch offen ist und dass Ticketmaster Canada als Datenverantwortlicher unter PIPEDA die untersuchte Einheit ist.

Dies ist ein nützlicher regulatorischer Kontext, aber keine endgültige Feststellung, die die Angemessenheit von Sicherheitsvorkehrungen, den Zeitpunkt der Benachrichtigung oder die Haftung klärt.

AT&T's Form 8-K vom 12. Juli 2024 Form 8-K veranschaulicht, warum Quellgrenzen wichtig sind, selbst wenn Vorfälle gemeinsam diskutiert werden. AT&T gab an, dass ein Akteur unbefugt auf einen AT&T-Arbeitsbereich auf einer Cloud-Plattform eines Drittanbieters zugegriffen und Dateien vom 14. bis 25. April exfiltriert hat. Die Dateien enthielten Anruf- und Textinteraktionsaufzeichnungen für fast alle AT&T-Wireless-Kunden und relevante mobile virtuelle Netzwerkbetreiberkunden für bestimmte Zeiträume in 2022 und einen Tag in 2023.

AT&T gab an, dass die Dateien keinen Anruf- oder Textinhalt, Sozialversicherungsnummern, Geburtsdaten oder andere persönliche Informationen enthielten, wie AT&T diesen Begriff verwendete. Die Einreichung selbst nennt Snowflake oder UNC5537 nicht. Sie stützt AT&T's Vorfallsfakten, nicht eine Kampagnenzuschreibung für sich 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 einem Verbraucherlogin. 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“ zusammen mit den Auswirkungen. Rechenschaftspflicht wird weniger glaubwürdig, wenn die Analyse dramatische Behauptungen ausweitet und einschränkende fallen lässt.

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

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

Ein Kunde hätte die beobachtete Kampagne an mehreren Punkten unterbrechen können. Er hätte Passwörter nach Offenlegung von Endgeräten rotieren, Nur-Passwort-Dienstkonten verbieten, MFA für Menschen erzwingen, Zugriff über einen verwalteten Identitätsanbieter föderieren, Netzwerke einschränken, Auftragnehmer-Benutzer auslaufen lassen, Rollenberechtigungen reduzieren, sensible Felder klassifizieren und maskieren, Exportprivilegien isolieren, Login- und Abfrageverlauf überwachen und Cloud-Anbieter-Benachrichtigungen proben können.

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

Endgeräte- und Auftragnehmer-Governance verdienen besondere Aufmerksamkeit. Ein Benutzer mit einer hochriskanten Cloud-Rolle sollte sich nicht von einem unverwalteten persönlichen Computer aus authentifizieren. Auftragnehmer sollten nach Möglichkeit kundenverwaltete virtuelle Desktops oder Geräte mit Endgeräteüberwachung verwenden. Ihre Identität sollte pro Kunde eindeutig, mit einem Sponsor verbunden und automatisch ablaufend sein. Die Organisation sollte Anmeldedaten-Expositionsfeeds nach ihren Snowflake-Kontomustern durchsuchen und Rotation erzwingen, wenn Beweise auftauchen, ohne auf bestätigten Missbrauch zu warten.

Least Privilege muss gegen Daten getestet werden, nicht gegen die Berufsbezeichnung. „Analyst“ mag nicht-administrativ klingen, behält aber 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 Kennungen benötigt werden, ob Bulk-Ergebnismengen 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 aussehender Rollenname.

Kunden besitzen auch die Reaktionsbereitschaft. Sie sollten in der Lage sein, einen Snowflake-Benutzer einem Mitarbeiter oder Auftragnehmer zuzuordnen, eine Abfrage den betroffenen Datenpersonen und einen Export einer Gerichtsbarkeit und Benachrichtigungsanalyse. Native einjährige Verläufe können für längere rechtliche Aufbewahrung oder verzögerte Entdeckung unzureichend sein, daher sollten risikoreiche Kunden relevante Ereignisse an einen unabhängigen Sicherheitsspeicher streamen. Anbieterwarnungen benötigen einen getesteten Pfad zum Sicherheitsteam des Kunden, Datenschutzbeauftragten, Geschäftsinhaber und Entscheidungsträger.

NISTs Cybersecurity Framework Supply-Chain-Leitfaden empfiehlt, Lieferantenanforderungen nach Kritikalität zu definieren und zu kommunizieren. Hier angewendet, sollte ein Snowflake-Kunde vertraglich die Zeitrahmen für Vorfallsbenachrichtigungen, Beweisfelder, Aufbewahrung, Support-Eskalation, regionale Verarbeitung, Sichtbarkeit von Unterauftragsverarbeitern, Änderungsmitteilung und Zugriff auf Zusicherungen festlegen. Er sollte auch einen Ausstiegs- oder Isolationsplan für die Datenfunktionen unterhalten, deren Verlust oder Kompromittierung nicht tolerierbar wäre.

Geteilte Verantwortung sollte als testbare Schnittstellen geschrieben werden, nicht als ein Absatz, der nur 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 beobachtete.

Die Rechenschaftspflicht des Anbieters hat in diesem Fall sechs Teile.

Sichere Grundlinie.Privilegierter menschlicher Zugriff sollte nicht allein von einem wiederverwendbaren Passwort abhängen. Dienstidentitäten sollten einen eigenen 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.

Konfigurationssichtbarkeit.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. Ergebnisse sollten auf Organisationsebene sichtbar und für Audits exportierbar sein.

Kundenübergreifende Erkennung.Wiederverwendete Infrastruktur, durchgesickerte Anmeldedaten, ungewöhnliche Clients, Aufklärungssequenzen, temporäre Staging-Bereicherstellung und große Exporte können ein Kampagnensignal bilden. Der Anbieter sollte auf Dienstebene erkennen, wahrscheinliche Opfer kontaktieren und definieren, wann eine hochvertrauenswürdige Aktivität einen temporären Block auslöst.

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

Warnung und Koordination.Eine Kundenwarnung muss über einen bekannten Notfallweg erfolgen und Beweise enthalten, nicht nur den Rat, Protokolle zu überprüfen. Der Anbieter sollte Bestätigung, Eindämmung und wiederholte Offenlegung verfolgen und Anfragen von Strafverfolgungsbehörden und Aufsichtsbehö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 Wirksamkeitsmaße. Snowflakes spätere Änderungen hin zu Standard-MFA, Deaktivierung durchgesickerter Passwörter, Trust-Center-Befunden 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 realen oder simulierten Versuch?

Diese Zuweisung macht Snowflake nicht zum Datenverantwortlichen für jeden Kundendatensatz, noch macht sie den Anbieter für jede Kundenkonfiguration verantwortlich. Sie erkennt an, dass ein Cloud-Unternehmen von der Konzentration von Daten und dem Betrieb einer Sicherheitsgrenze profitiert. Größe schafft Pflichten, die nur der Anbieter erfüllen kann, insbesondere mandantenübergreifende Korrelation und grundlegende Technik.

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

Snowflake und betroffene Unternehmen sahen sich nach den Vorfällen mit konsolidierten Zivilklagen konfrontiert. In einer bundesgerichtlichen Anordnung vom 29. Oktober 2025 entschied das Bezirksgericht von 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 angebliche Standard-MFA und Vorhersehbarkeit als relevant für Pflicht, Verletzung und Kausalität in diesem Verfahrensstadium.

Diese Anordnung ist kein Urteil, dass Snowflake oder Ticketmaster fahrlässig war. Bei einem Antrag auf Abweisung prüft das Gericht, ob gut dargelegte Behauptungen eine plausible Klage darlegen; es klärt keine streitigen Beweise, bestimmt den endgültigen Vorfallsmechanismus für jeden Kläger oder legt Schadensersatz fest. Snowflake bestritt die Behauptungen und argumentierte, dass die Nichtumsetzung von MFA, Netzwerkrichtlinien und anderen Sicherheitsvorkehrungen durch die Kunden den Schaden verursacht habe.

Die Anordnung ist bedeutsam, weil sie zeigt, dass die Beschreibung von MFA als Kundeneinstellung nicht automatisch jeden Anbieterpflichtanspruch beendete. Sie ist kein Ersatz für die endgültige Beweisaufnahme.

Die kanadische Datenschutzuntersuchung hatte eine andere Zuweisung. 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 eigener 10-K erkannte zahlreiche Klagen, behördliche Untersuchungen und Anfragen von Gesetzgebern an, berichtete jedoch keine endgültige universelle Haftungszuweisung. Zum Zeitpunkt der Veröffentlichung unterstützen die hier überprüften öffentlichen Quellen weder die Behauptung, dass Snowflake rechtlich entlastet sei, noch dass jeder Kunde rechtlich schuld sei, noch dass ein endgültiges Gericht oder eine Aufsichtsbehörde die operative Zuweisung dieses Artikels übernommen hat.

Operative Rechenschaftspflicht kann vor endgültiger Haftung bewertet werden. War Nur-Passwort-Zugriff vorhersehbar? Ja. Konnte der Kunde MFA und Netzwerkrichtlinien erzwingen? Ja. Konnte Snowflake Voreinstellungen gestalten und kundenübergreifende Aktivitäten erkennen? Ja. Haben Kriminelle den resultierenden Pfad absichtlich ausgenutzt? Ja. Diese Aussagen können nebeneinander bestehen. Deliktsrecht, Vertragsrecht, Datenschutz- und Wertpapierrecht können Konsequenzen je nach Gerichtsbarkeit und Kläger unterschiedlich zuweisen, aber die Technik sollte nicht darauf warten, dass ein Slogan gewinnt.

Ein messbarer Test für geteilte Verantwortung

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

Vorstände sollten Ergebnisse erhalten, keine Funktionsinventare. Nützliche Maßnahmen 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 zum Aussetzen einer hochvertrauenswürdigen Sitzung und die Zeit zur Erstellung eines feldebasierten Offenlegungspakets.

Snowflake sollte aggregierte Fortschritte veröffentlichen, wo dies ohne Offenlegung von Kunden möglich ist. CISAs 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 Laufe der Zeit. Eine Aussage, dass das Trust Center aktiviert ist, ist weniger informativ als die Anzahl der kritischen Befunde, die ü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 dieselbe Strenge von sich selbst verlangen. Ein Anbieter kann keine Organisation retten, die breite Rollen erstellt, Befunde ignoriert, alte Auftragnehmer-Benutzer 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 Auslassungen weniger wahrscheinlich zu machen, massiven Datendiebstahl zu verursachen.

Was das öffentliche Register noch nicht feststellt

Die Beweise sind stark genug, um ein Kampagnenmuster zu rekonstruieren, aber nicht jeden Vorfall eines Opfers.

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

Es veröffentlicht nicht den Benutzertyp, die Rollenhierarchie, den MFA-Verlauf, die Netzwerkkonfiguration, den Endgeräteeigentümer, die Sitzungssequenz, die abgerufenen Spalten oder das Exportvolumen für jede Organisation. Auftragnehmergeräte-Befunde aus mehreren Untersuchungen sollten nicht jedem Opfer zugewiesen werden. Die 79,7-Prozent-Statistik zur Anmeldedatenoffenlegung sollte nicht in einen Opferprozentsatz umgewandelt werden.

Es stellt keine Softwaresicherheitslücke, mandantenübergreifende Flucht, Kompromittierung von Snowflakes Produktionsplattform, Diebstahl einer Anbieter-Master-Anmeldeinformation oder Zugriff auf jeden Snowflake-Kunden fest. Die beobachtete Verwendung unterstützter Clients und Befehle ist ein Beweis für Anmeldedatenmissbrauch, kein Nachweis dafür, dass der Produktcode ausgenutzt wurde.

Es beweist nicht, dass regionale Daten in jedem Vorfall eine nationale Grenze überschritten haben. Die Architektur erlaubte Fernzugriff und lokalen Download; eine rechtliche Übertragungsanalyse würde Quell-, Ziel-, Datenpersonen-, Vertrags- und Gerichtsbarkeitsfakten für jeden Kunden erfordern.

Es erlaubt nicht, Ticketmasters mögliche Felder, AT&T's Anrufdetailumfang oder eine kriminelle Forumszahl auf andere Kunden zu verallgemeinern. Live Nations Einreichung nannte Snowflake nicht. AT&T's Einreichung nannte Snowflake oder UNC5537 nicht. Eine externe Zuordnung 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 den Betrieb von Kontrollen im April und Mai 2024. Spätere Standard-MFA, Leaked-Password-Schutz, 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.

Geteilte 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 daher die Frage nach dem Anbieter abgeschlossen ist. Dies ist technisch unvollständig.

UNC5537 fand eine skalierbare Verbindungsstelle zwischen Endgerätekompromittierung 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 wenn eine authentifizierte Sitzung eine unkontrollierte Kopie anderswo erstellte.

Kunden hatten die klarste Pflicht, ihre Benutzer, Rollen, Endgeräte, Auftragnehmer und Daten zu verwalten. Snowflake hatte die klarste Pflicht, die Dienstgrenze zu sichern und zu überwachen, 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. Aufsichtsbehörden und Gerichte müssen die rechtlichen Pflichten auf der Grundlage der für jede Organisation geltenden Fakten und des geltenden Rechts bewerten. Diese Zuweisungen überschneiden sich, weil sich die Kontrollen überschneiden.

Die Produktrichtung nach der Kampagne erkennt implizit die Lücke zwischen Fähigkeit und Ergebnis an. Standard-MFA für neue menschliche Benutzer, Deaktivierung durchgesickerter Passwörter, stärkere Authentifizierungsrichtlinie, Dienstbenutzer-Migration und Trust-Center-Befunde bringen die Sicherheit näher an die Grundlinie des Anbieters. Sie löschen die Kundenverantwortung nicht. Sie machen das gemeinsame System weniger abhängig davon, dass jeder Administrator die richtige Option findet und aktiviert, bevor ein gestohlenes Passwort getestet wird.

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

Geteilte 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 vorher und nachher getan haben.