Snowflake machte überprüfbare Reparatur zum Test der geteilten Cloud-Verantwortung

Zusammenfassung

• Mandiant berichtete, dass jeder von ihr direkt bearbeitete Snowflake-Kampagnenvorfall auf kompromittierte Kundenanmeldedaten zurückzuführen sei, und fand keine Hinweise darauf, dass unbefugter Zugriff auf einen Einbruch in die Unternehmensumgebung von Snowflake zurückzuführen sei. Der Kampagnenbericht ist unterhttps://cloud.google.com/blog/topics/threat-intelligence/unc5537-snowflake-data-theft-extortionverfügbar.
• Die Kampagne stellte dennoch die Verantwortung des Anbieters auf die Probe, da Snowflake die Authentifizierungsoberflächen, Produktvoreinstellungen, Sicherheitsleitfäden, Konto-Telemetrie, Netzwerkrichtlinien-Tools, Trust-Center-Prüfungen und Änderungen nach der Kampagne kontrollierte, die kein einzelner Kunde allein vornehmen konnte.
• Überprüfbare Reparatur bedeutet messbare Veränderung: standardmäßige MFA für menschliche Benutzer in neuen Konten, strengere Passwortregeln, automatische Deaktivierung geleakter Passwörter, Kunden-Evidenzpakete, Netzwerkursprungskontrollen und Einführungsmetriken, die die Risikominderung in der installierten Basis zeigen.
• Die Verantwortung der Kunden bleibt erheblich. Die Kunden kontrollierten die Benutzererstellung, Rollenvergabe, Passwortrotation, MFA-Anmeldung in bestehenden Konten, Zugriff von Auftragnehmern, Netzwerk-Zulassungslisten, Datenminimierung, Exportberechtigungen und die Bereitschaft für Untersuchungen.

Die Plattform wurde nicht als kompromittiert nachgewiesen; die Basislinie erwies sich als zu nachgiebig

Die erste Disziplin besteht darin, die Kampagnengrenze exakt einzuhalten. Mandiants Bericht vom Juni 2024 besagte, dass der unbefugte Zugriff bei den von ihr bearbeiteten Vorfällen auf kompromittierte Kundenanmeldedaten zurückzuführen sei und sie keine Hinweise auf einen Einbruch in die Unternehmensumgebung von Snowflake gefunden habe. Snowflakes Kundenleitfaden, verstärkt durch CISA unter source: cisa.gov, wies die Kunden ebenfalls an, unbefugten Benutzerzugriff zu untersuchen und Identitäts- und Netzwerkkontrollen zu verstärken.

Die geprüften Aufzeichnungen belegen keinen Snowflake-Plattform-Exploit, keine mandantenfähige Eskalation und keinen Diebstahl von Anbieter-Hauptanmeldedaten.

Dieser negative Befund ist wichtig, weil er die sofortige Reaktion prägt. Ein Kunde sollte nicht auf ein Anbieter-Patch warten, wenn das aktive Problem eine gültige Benutzeranmeldedaten ohne MFA, keine Netzwerk-Zulassungsliste und umfassende Rollenberechtigungen ist. Der Kunde muss Anmeldedaten rotieren, Konten deaktivieren, Anmelde- und Abfrageverlauf prüfen, Ursprungsnetzwerke einschränken, Rollen überprüfen, Protokolle aufbewahren und betroffene Personen oder Aufsichtsbehörden benachrichtigen, wenn erforderlich.

Der gegenteilige Fehler besteht darin, zu behaupten, der Anbieter habe keine Verantwortung, weil das erste Geheimnis den Kunden gehörte. Snowflake betrieb den Authentifizierungsendpunkt, der diese Passwörter akzeptierte. Es stellte die MFA-Funktion bereit und entschied, wann das Standardverhalten geändert wurde. Es legte Telemetriefelder offen oder enthielt sie zurück. Es stellte Netzwerkrichtlinienkontrollen und Trust-Center-Ergebnisse bereit. Es konnte Signale über mehrere Kunden hinweg sehen, die kein einzelner Mandant sehen konnte. Es konnte später einen Schutz vor geleakten Passwörtern in den Dienst einbauen.

Das ist echte Kontrolle, auch wenn der Kunde das Konto besaß.

Snowflakes Jahresbericht für das Geschäftsjahr 2025 unter SEC source legt die Position des Unternehmens zur geteilten Verantwortung dar und beschreibt die rechtlichen, regulatorischen und reputationsbezogenen Folgen nach den Aktivitäten von 2024. Eine Einreichung ist eine Unternehmensdarstellung, kein Urteil. Sie ist dennoch relevant, weil Snowflake selbst offenlegte, dass die Kampagne das Geschäftsrisiko über einen einzelnen Kundenten hinaus beeinflusste. Geteilte Verantwortung wurde zu einem Thema für börsennotierte Unternehmen.

Die Linse des Artikels ist daher nicht „Snowflake wurde kompromittiert“ oder „nur die Kunden versagten“. Es ist die überprüfbare Reparatur. Nachdem eine Kampagne ein vorhersehbares Muster von passwortgeschütztem Zugriff, veralteten Infostealer-Anmeldedaten und fehlenden Netzwerkbeschränkungen ausgenutzt hat, benötigen der Anbieter und die Kunden den Nachweis, dass die nächste ähnliche Kampagne weniger gültige Anmeldedaten, weniger passwortgeschützte Sitzungen, weniger uneingeschränkte Ursprünge, bessere Warnungen und eine schnellere Bereitstellung von Beweisen haben wird.

Der Kampagnenpfad nutzte normale Funktionen unter feindlicher Identität

Mandiant beschrieb eine praktische Kette. Anmeldedaten wurden durch Infostealer-Malware von Systemen gestohlen, die nicht Snowflake gehörten, darunter in einigen Fällen Auftragnehmer-Maschinen, die für persönliche Aktivitäten genutzt wurden. Diese Anmeldedaten blieben gültig, manchmal über Jahre hinweg. Die Konten hatten keine MFA. Kundeninstanzen hatten keine Netzwerk-Zulassungslisten. Angreifer verbanden sich mit Standard-Clients und -Tools, führten Aufklärung durch, wählten Daten aus, bereiteten Ergebnisse auf, komprimierten Dateien und riefen sie ab. Das Muster nutzte unterstützte Datenbankfunktionen unter unbefugter Identität.

Diese Unterscheidung ist zentral für die Reparatur. Die Verschlüsselung im Ruhezustand war nicht die entscheidende Barriere. Die End-to-End-Verschlüsselungsdokumentation von Snowflake unter source: docs.snowflake.com beschreibt die Verschlüsselung im Ruhezustand und während der Übertragung, erklärt aber auch, dass Daten während Tabellenoperationen verwendet werden müssen und von autorisierten Benutzern entladen und heruntergeladen werden können. Ein Angreifer, der die Authentifizierung des Kontos erfüllt und eine Rolle erbt, kann den Dienst nach lesbaren Ergebnissen fragen.

Verschlüsselung ist kein Ersatz für Identitätssicherheit, Rollendesign, Exportkontrolle und Erkennung.

Die Zugriffskontrolle bestimmte den Schaden nach dem Login. Die Zugriffskontrollübersicht von Snowflake unter source: docs.snowflake.com beschreibt Rollen, Berechtigungen, Eigentum und Hierarchie. Ein gestohlenes Anmeldedatum mit eingeschränktem Zugriff ist anders als eines mit umfassenden Leseberechtigungen oder Kontoadministration. Ein Dienstkonto, das für eine Pipeline erstellt wurde, ist anders als ein Administrator eines Auftragnehmers. Das Prinzip der geringsten Privilegien ist kein Slogan; es ist der Unterschied zwischen einer feindlichen Sitzung, die eine Ansicht zurückgibt, und einer, die durch wichtige Kundentabellen läuft.

Datenklassifizierung und Maskierung können die Konsequenz reduzieren. Die Dokumentation zur Klassifizierung sensibler Daten von Snowflake unter source: docs.snowflake.com verbindet die Erkennung sensibler Spalten mit Maskierungs- und Zeilenzugriffsrichtlinien. Dies beweist nicht, dass betroffene Kunden solche Kontrollen hatten. Es zeigt einen Reparaturpfad: Kunden sollten persönliche und regulierte Felder identifizieren, nach Möglichkeit Ansichten statt Rohdaten bereitstellen und Exportrollen von gewöhnlichen Leserollen trennen.

Der beobachtete Exfiltrationspfad macht den Export auch zu einer eigenen Kontrolle. Massenentladungen sind in einer Datenplattform legitim. Sie unterstützen Analyse, Backups, nachgelagerte Verarbeitung und Modell-Workflows. Aber eine ungewöhnliche Sitzung, die temporäre Staging-Bereiche erstellt, große Ergebnisse exportiert und sie von einem unbekannten Ursprung herunterlädt, ist nicht nur „eine Abfrage“. Es ist ein Datenbewegungsereignis. Die Reparatur sollte solche Ereignisse messbar, zurechenbar und bei risikoreichen Datensätzen unterbrechbar machen.

MFA-Verfügbarkeit wurde zu MFA-Ergebnissen

MFA war vor der Kampagne verfügbar. Die erfolgreichen Konten in Mandiants Bericht hatten keine MFA. Diese Lücke ist das Herzstück des Streits um die geteilte Verantwortung. Ein Kundenadministrator konnte MFA aktivieren, und viele taten es nicht. Ein Anbieter kann wahrheitsgemäß sagen, dass die Kontrolle verfügbar war. Aber ein Anbieter, der sieht, dass viele hochwertige Konten immer noch nur mit Passwort erreichbar sind, hat das Sicherheitsergebnis nicht erreicht, sondern nur die Einstellung verfügbar gemacht.

Snowflakes Ankündigung vom September 2024 unter source: snowflake.com veränderte die Produktposition. Darin hieß es, dass MFA für menschliche Benutzer in Konten, die ab Oktober 2024 erstellt wurden, standardmäßig erzwungen wird und dass Dienstbenutzer dieser spezifischen Anforderung nicht unterliegen. Es kündigte auch strengere Passwortanforderungen für neu erstellte und geänderte Benutzerpasswörter an. Dies ist eine sinnvolle Reparatur, da es den Standardpfad für zukünftige Konten ändert.

Die Unterscheidung zwischen neuen und bestehenden Konten ist ebenso bedeutsam. Eine Voreinstellung für zukünftige Konten entfernt nicht automatisch jeden nur mit Passwort geschützten Pfad in der installierten Basis. Bestehende Kunden können Legacy-Benutzer, Dienstkonten, Auftragnehmer, Break-Glass-Konten und ältere Clients haben.

Ein überprüfbarer Reparaturbericht sollte daher das Legacy-Risiko direkt messen: Anzahl und Anteil menschlicher Benutzer ohne MFA, privilegierter menschlicher Benutzer ohne MFA, Passwortbenutzer mit veralteten letzten Anmeldedaten, Benutzer mit bekannten kompromittierten Anmeldedaten, Dienstkonten, die Passwörter anstelle stärkerer Workload-Authentifizierung verwenden, sowie Ausnahmen mit Geschäftsinhabern und Ablaufdaten.

Die Dokumentation zu Authentifizierungsrichtlinien von Snowflake unter source: docs.snowflake.com gibt Administratoren Kontrollen über Authentifizierungsmethoden, Clients, Identitätsanbieter und MFA-Anmeldung. Die Dokumentation zur Schlüsselpaar-Authentifizierung unter source: docs.snowflake.com gibt Dienstkonten eine Alternative zu statischen Passwörtern. Diese Kontrollen erlegen den Kunden Pflichten auf, definieren aber auch die Reparaturoberfläche des Anbieters: Das Produkt sollte gute Muster erleichtern, schlechte Ausnahmen sichtbar machen und die Migration weniger riskant gestalten.

Die NIST-Richtlinie zur digitalen Identität unter source: pages.nist.gov hilft, das Ergebnis zu formulieren. Passwörter sind nicht replay-resistent. Phishing-resistente oder kryptografisch gebundene Methoden reduzieren den Wert eines gestohlenen Passworts. Für Snowflake-Kunden bedeutet dies, dass menschliche Administratoren zu föderierten Identitäten oder starker MFA wechseln sollten, während Dienstbenutzer bereichsspezifische Workload-Anmeldedaten verwenden sollten, die rotieren und ohne Personenimitation deaktiviert werden können.

Blockierung geleakter Passwörter machte geteilte Verantwortung messbar

Die direkteste Reparatur eines Anbieters nach einer Kampagne mit gestohlenen Anmeldedaten ist keine Belehrung über die Wiederverwendung von Passwörtern. Es ist, dafür zu sorgen, dass bekannte gestohlene Passwörter nicht mehr funktionieren. Snowflakes Ankündigung vom Dezember 2024 unter source: snowflake.com besagte, dass sie Passwörter, die im Dark Web entdeckt wurden, durch einen datenschutzschonenden Prozess automatisch deaktivieren würde, wenn sie als durchgesickert und noch gültig bestätigt wurden.

Diese Kontrolle adressiert den zentralen Vorteil der Kampagne: Anmeldedaten, die lange vor 2024 gestohlen wurden, wurden vom Dienst weiterhin akzeptiert.

Der Schutz vor durchgesickerten Passwörtern hebt die Kundenpflicht nicht auf. Kunden benötigen weiterhin Endpunktsicherheit, Auftragnehmer-Governance, Passwortrotation, Föderation, Dienstbenutzerdesign und das Prinzip der geringsten Privilegien. Aber er verändert die Arbeitsteilung. Einzelne Kunden können den globalen Markt für Infostealer oft nicht so gut einsehen wie ein Cloud-Anbieter. Ein Anbieter kann Bedrohungsinformationen kaufen oder erhalten, kompromittierte Anmeldedaten kontrolliert abgleichen und ein Passwort deaktivieren, bevor jeder Kunde es unabhängig entdeckt.

Das ist die Art von anbieterseitiger Kontrolle, die geteilte Verantwortung von einer Klausel zu einem Systemverhalten macht.

Die Evidenzfrage sind Einführung und Leistung. Wie viele gültige durchgesickerte Passwörter wurden gefunden? Wie schnell wurden sie deaktiviert? Wie viele gehörten zu privilegierten Benutzern? Wie viele Konten wechselten von Passwort zu Schlüsselpaar oder föderiertem Zugriff? Wie viele Deaktivierungsereignisse führten zu Support-Friktionen oder unsicheren Workarounds? Wie viele Kunden haben noch Ausnahmen? Ohne Metriken bleibt der Schutz vor durchgesickerten Passwörtern eine gute Ankündigung. Mit Metriken wird er zu einer überprüfbaren Reparatur.

Das CISA-Secure-by-Design-Versprechen unter source: cisa.gov rahmt diese Unterscheidung ein. Es fordert Hersteller auf, über optionale Kontrollen hinaus zu messbaren Ergebnissen wie standardmäßiger MFA und Einführungsmetriken zu gelangen. Snowflakes Ankündigung vom Juli 2024 unter source: snowflake.com stellte das Unternehmen in dieses öffentliche Bekenntnis. Das Versprechen ist freiwillig und kein rechtliches Urteil über die Kampagne. Es ist relevant, weil es die Art von Evidenz identifiziert, die Kunden nach dem Vorfall erwarten sollten.

Netzwerkrichtlinien waren ein zweites Tor

Mandiant identifizierte fehlende Netzwerk-Zulassungslisten als einen wiederkehrenden Faktor. Die Dokumentation zu Netzwerkrichtlinien von Snowflake unter source: docs.snowflake.com beschreibt die praktische Voreinstellung: Ohne Richtlinie können sich Benutzer von jedem Computer oder Gerät aus verbinden. Kunden können den Zugriff durch erlaubte oder blockierte Netzwerkstandorte einschränken und private Konnektivitätsmuster für stärkere Grenzen nutzen.

Der Kunde ist der Akteur, der am besten in der Lage ist, legitime Ursprünge zu kennen: Büros, VPNs, Cloud-Workloads, verwaltete Auftragnehmer-Desktops und genehmigte Integrationsanbieter. Snowflake kann nicht jeden gültigen Pfad erraten, ohne den Dienst zu unterbrechen. Aber Snowflake kontrolliert, ob der uneingeschränkte öffentliche Zugriff still oder sichtbar ist.

Ein überprüfbares Reparaturprogramm sollte melden, welchen Konten Netzwerkrichtlinien fehlen, welche privilegierten Benutzer sie umgehen, ob der Zugriff auf interne Staging-Bereiche abgedeckt ist und ob die Richtlinien tatsächlich mit den geschäftlich genehmigten Ursprüngen übereinstimmen.

Netzwerkkontrollen allein sind nicht ausreichend. Ein Angreifer kann ein genehmigtes VPN nutzen, einen Auftragnehmer-Rechner kompromittieren, der sich bereits auf einer Zulassungsliste befindet, oder ein Token nach der Authentifizierung stehlen. Dennoch sollte die Verteidigung mehrschichtig sein. Ein gestohlenes Passwort, keine MFA, keine Netzwerkbeschränkung, eine breite Rolle und ein unüberwachter Export sind eine Kette. Das Durchbrechen eines Glieds kann entscheidend sein. Reparatur ist der Prozess, die Anzahl der Kundenumgebungen zu reduzieren, in denen alle Glieder gleichzeitig offen bleiben.

Der Anbieter sollte auch das Sperrmanagement sicher machen. Administratoren können Netzwerkrichtlinien vermeiden, weil sie befürchten, Geschäftsnutzer oder Dienstaufträge zu blockieren. Simulation, stufenweise Einführung, Notfallkontakte, temporäre Ausnahmen und klare Protokolle reduzieren diese Angst. Je besser der Migrationspfad, desto schwieriger ist es, fehlende Richtlinien als normal zu behandeln.

Telemetrie ist die Evidenzgrenze

Nach einer Datendiebstahlkampagne benötigen Kunden mehr als allgemeine Beruhigung. Sie müssen wissen, wer sich von wo, mit welchem Faktor, mit welchem Client, unter welcher Rolle angemeldet hat, welche Abfragen ausgeführt wurden, welche Objekte berührt wurden, welche Daten entladen wurden, welche Staging-Bereiche genutzt wurden und wie viele Daten bewegt wurden. Snowflakes aktuelle Dokumentation beschreibt mehrere Ansichten, die solche Arbeiten unterstützen können.

LOGIN_HISTORY unter source: docs.snowflake.com bietet Anmeldeversuche mit Quell-IP, Client, Erfolg und Faktorinformationen. QUERY_HISTORY unter source: docs.snowflake.com bietet Abfrageaktivität, Benutzer, Rolle, Abfragetext, Ergebnisgröße, entladene Zeilen und über das Netzwerk gesendete Bytes. ACCESS_HISTORY unter source: docs.snowflake.com kann helfen, den Zugriff auf Objekte und Spalten für berechtigte Editionen zu rekonstruieren. Die Trust-Center-Dokumentation unter source: docs.snowflake.com beschreibt Statusprüfungen und Erkennungen für MFA, Netzwerkrichtlinien, riskante Anmeldungen, ungewöhnliche IP-Adressen und große Überweisungen.

Das sind Fähigkeiten. Fähigkeit ist kein Beweis für Untersuchungsbereitschaft. Kunden müssen berechtigt sein, die Ansichten abzufragen, sie in dauerhaften Sicherheitsspeicher zu exportieren, Latenz und Aufbewahrung zu verstehen und sie mit Identitätsanbieter-, Endpunkt- und Ticketingdaten zu korrelieren. Editionsunterschiede können die Genauigkeit der Feldbereichsabgrenzung verändern. Anbieteransichten können Verzögerungen aufweisen, die für die aktive Eindämmung wichtig sind. Der Abfragetext allein mag einem Datenschutzteam nicht sagen, welche Personen vertreten sind, es sei denn, der Kunde hat Datenkarten.

Überprüfbare Reparatur sollte daher Evidenzpakete umfassen. Wenn Snowflake einen potenziell betroffenen Kunden benachrichtigt, sollte der Kunde Kontokennungen, Benutzer, Zeitstempel, Ursprungsnetzwerke, Status des ersten und zweiten Faktors, Client-Kennungen, Sitzungs- und Abfragekennungen, Rollen, berührte Objekte, Staging-Bereichsnamen, Entladevolumen, Vertrauensgrad und empfohlene Eindämmungsmaßnahmen erhalten. Ein Etikett wie „potenziell betroffen“ ist als Eröffnung akzeptabel, muss aber von genügend Daten gefolgt werden, damit der Kunde entscheiden kann, ob personenbezogene Daten betroffen waren.

Das Eingreifen des Anbieters benötigt auch vorherige Autorisierung. Ein Cloud-Anbieter kann verdächtige Aktivitäten sehen, bevor ein Kunde sie sieht, aber das automatische Blockieren einer Sitzung kann den Betrieb unterbrechen. Nicht zu handeln kann Diebstahl ermöglichen. Reparatur sollte Schwellenwerte für vorübergehende Sperrung, Notfallkontakte der Kunden, Beweissicherung und Übersteuerung definieren. Kunden sollten Sicherheitskontakte benennen, die rund um die Uhr handeln können. Snowflake sollte die Zeit von kundenübergreifendem Signal bis zur Kundenbenachrichtigung und die Zeit von der Benachrichtigung bis zur Eindämmung messen.

Datenlokalität endete beim Zugriff

Die Wahl der Snowflake-Region kann für Latenz, Resilienz, Datenschutz und Beschaffung wichtig sein. Die Dokumentation der unterstützten Regionen unter source: docs.snowflake.com besagt, dass ein Konto in einer Region gehostet wird und dass die Daten dort bleiben, es sei denn, Benutzer kopieren, verschieben oder replizieren sie explizit. Sie nennt auch die wichtige Einschränkung: Die Regionswahl schränkt den Benutzerzugriff auf Snowflake nicht ein.

Die Kampagne machte diese Einschränkung zu einem Souveränitätsproblem. Die Tabellen eines Kunden mögen in einer genehmigten Region gespeichert sein. Eine gültige Identität konnte sich dennoch von anderswo verbinden, die Daten abfragen, in einen Staging-Bereich entladen und eine Kopie herunterladen. Die Platzierung des Quellkontos verhinderte weder den Fernzugriff noch den Export. Der öffentliche Kampagnenbericht belegt nicht die Quell- und Zielländer für jedes Opfer, daher ist keine universelle grenzüberschreitende rechtliche Schlussfolgerung möglich. Die architektonische Lehre bleibt: Speicherort ist nicht Zugriffsort.

Snowflakes Leitfaden zur regionsübergreifenden Freigabe unter source: docs.snowflake.com warnt Kunden, vor der Replikation von Daten in eine andere Region oder ein anderes Land die rechtlichen und regulatorischen Beschränkungen zu bestätigen. Dieser Leitfaden betrifft genehmigte Bewegungen. Der durch Anmeldedaten gesteuerte Export ist anders, da er eine unkontrollierte Kopie außerhalb der ausgewählten Region erstellen kann, ohne die Region des Quellkontos zu ändern. Ein Dateninventar, das nur die Quellregion erfasst, kann korrekt und dennoch nach einem Export unvollständig sein.

Die Reparatur der Datensouveränität benötigt daher vier Ebenen: wo maßgebliche Daten gehostet werden, welche Identitäten sich von welchen Geräten und Gerichtsbarkeiten aus verbinden dürfen, welche Bewegungsfunktionen Kopien erstellen können und welche Beweise nach einem Vorfall vorliegen. Snowflake kontrolliert Regionsangebote, Authentifizierung, Netzwerktools, Exportmechanismen und Telemetrie. Kunden kontrollieren Rechtsgrundlage, Datenfelder, Rollenvergabe, Bewegungsgenehmigungen und Benachrichtigungsanalyse. Beide Seiten benötigen Beweise an ihrer Grenze.

Kundenfälle zeigen Konsequenzen, keine einheitliche Gesamtzahl

Die öffentliche Form der Kampagne wurde durch Offenlegungen betroffener Unternehmen beeinflusst. Jeder Aufzeichnung muss innerhalb ihrer eigenen Fakten bleiben.

Live Nations Einreichung vom Mai 2024 unter SEC source besagte, dass das Unternehmen unbefugte Aktivitäten in einer Cloud-Datenbankumgebung eines Drittanbieters identifizierte, die hauptsächlich Ticketmaster-Daten enthielt, und dass ein krimineller Akteur später angebliche Unternehmensbenutzerdaten zum Verkauf anbot. Die Einreichung nannte Snowflake nicht oder lieferte keine bestätigte Anzahl betroffener Personen.

Ticketmaster Canadas Vorfallseite unter source: help.ticketmaster.ca beschrieb eine isolierte Cloud-Datenbank eines Drittanbieters, mögliche Felder für einige nordamerikanische Ticketkäufer und die Abgrenzung, dass Ticketmaster-Kundenkonten nicht betroffen waren. Der Datenschutzbeauftragte Kanadas identifizierte später Snowflake als Ticketmasters Anbieter in einer parlamentarischen Unterrichtung unter source: priv.gc.ca und wies gleichzeitig darauf hin, dass die Untersuchung noch offen und Ticketmaster Canada weiterhin die geprüfte verantwortliche Stelle sei.

AT&T's Einreichung vom Juli 2024 unter SEC source beschrieb den unbefugten Zugriff auf einen AT&T-Arbeitsbereich auf einer Cloud-Plattform eines Drittanbieters und die Exfiltration von Anruf- und Textinteraktionsaufzeichnungen. Die Einreichung nannte Snowflake nicht. Sie ist nützlich, um einen offengelegten Vorfall in einem Cloud-Arbeitsbereich eines Drittanbieters und seine Feldgrenzen zu verstehen, nicht als eigenständige Zuschreibung.

Diese Beispiele ergeben keine kampagnenweite Personenzahl. Mandiants etwa 165 potenziell betroffene Organisationen ist eine Benachrichtigungspopulation, keine bestätigte Opferzahl, Aufzeichnungszahl oder Anzahl betroffener Personen. Jeder Kunde hatte unterschiedliche Daten, Rollen, Aufbewahrungsfristen, Regionen und Benachrichtigungspflichten. Überprüfbare Reparatur muss jedem Kunden helfen, seine eigenen Fakten abzugrenzen, anstatt eine einzige plattformweite Zahl die ganze Arbeit erledigen zu lassen.

Ein typografischer Hinweis für Evidenzpakete

Wenn Kunden hochkritische Cloud-Sicherheitsbeweise erhalten, kann das Layout entscheiden, ob die richtige Person schnell handelt. Eine Tabelle mit Sitzungen, Faktoren, Rollen, Objekten und Übertragungen muss unter Druck lesbar sein. Der folgende typografische Block gehört in den öffentlichen Teil, weil das Evidenzdesign Teil der Reparatur ist.

Für Snowflake-Kunden bedeutet lesbare Evidenz Zeitstempel in einer Zeitbasis, klare Benutzer- und Rollenbezeichnungen, Trennung bestätigter Aktivität von Verdacht, sichtbarer MFA-Status und direkte Verknüpfungen zwischen Abfragen, Staging-Bereichen, Übertragungsvolumen und betroffenen Datenspeichern. Ein dichter Export von Protokollen kann vollständig, aber unbrauchbar sein. Ein prägnantes Evidenzpaket kann den Unterschied zwischen einer schnellen Eindämmungsentscheidung und einer verzögerten Datenschutzanalyse ausmachen.

Verantwortung durch praktische Kontrolle

Die Angreifer kontrollierten die kriminelle Aktivität: Verwendung gestohlener Anmeldedaten, Eindringen in Kundenumgebungen, Zwischenspeicherung von Daten, Mitnahme und Versuch von Verkauf oder Erpressung. Sie sind für dieses Verhalten verantwortlich.

Kunden kontrollierten viele versagte Tore. Sie erstellten Benutzer, wiesen Rollen zu, entschieden, ob sich menschliche Benutzer nur mit Passwort anmelden konnten, behielten veraltete Anmeldedaten, erlaubten Auftragnehmerzugriff, ließen einige Konten ohne Netzwerkrichtlinien, gewährten Datenzugriff und kontrollierten Exporte. Ein Kunde, dessen hochwertiges Warehouse ein altes Passwort von einem unbekannten Ursprung ohne MFA oder enge Rollen akzeptierte, kann nicht die gesamte Verantwortung auf den Anbieter abwälzen.

Snowflake kontrollierte die Basislinie und die Reparaturwerkzeuge. Es kontrollierte, ob neue menschliche Benutzer standardmäßig MFA hatten, ob durchgesickerte Passwörter anbieterseitig deaktiviert wurden, ob riskante Konfigurationen im Trust Center auftauchten, welche Telemetriefelder verfügbar waren, wie Kunden benachrichtigt wurden, wie Leitfäden verfasst waren und wie schnell Kontrollen nach der Kampagne ausgeliefert wurden. Ein Anbieter, der dasselbe Muster über mehrere Mandanten hinweg sieht, hat die Pflicht, das Muster im Maßstab zu reduzieren, nicht nur jedem Kunden zu sagen, er solle das Handbuch lesen.

Identitätsanbieter, Auftragnehmer und Endpunktbesitzer kontrollierten angrenzende Bedingungen. Auftragnehmergeräte, die über mehrere Kunden hinweg genutzt werden, können einen einzelnen Infostealer-Vorfall auf mehrere Cloud-Mandanten ausdehnen. Identitätsanbieter können stärkere Faktoren und bedingten Zugriff erzwingen. Verwaltete Endpunkte können Anmeldedaten von persönlichen Maschinen fernhalten. Diese Akteure sind wichtig, aber sie löschen nicht die Pflichten von Kunden und Anbietern in Bezug auf das Snowflake-Konto selbst.

Regulierungsbehörden, Versicherer und Beschaffungsteams kontrollieren Anreize. Der NIST-Leitfaden zur Lieferkette unter source: csrc.nist.gov unterstützt die Definition von Lieferantenanforderungen proportional zur Kritikalität. Für ein Datenlager bedeutet dies, dass Verträge und Verlängerungen nach MFA-Einführungsmetriken, Reaktion auf durchgesickerte Passwörter, Evidenzpaketfelder, Aufbewahrungsgarantien, Benachrichtigungszeitplan, Support-Eskalation und regionale Bewegungskontrollen fragen sollten. Ein Sicherheitsfragebogen, der nur fragt, ob MFA existiert, ist nach dieser Kampagne zu oberflächlich.

Was würde dauerhafte Reparatur beweisen

Der Reparaturnachweis sollte mindestens zehn Ergebnisse umfassen.

Erstens: Alle neuen menschlichen Benutzer haben standardmäßig MFA oder stärkeren föderierten Zugriff, und die installierte Basis zeigt einen steigenden Anteil geschützter menschlicher und privilegierter menschlicher Konten. Zweitens: Dienstbenutzer wechseln von statischen Passwörtern zu Schlüsselpaar, OAuth oder anderen bereichsspezifischen Workload-Anmeldedaten mit Rotation. Drittens: Der Schutz vor durchgesickerten Passwörtern meldet bestätigte Deaktivierungsereignisse und die durchschnittliche Zeit bis zur Deaktivierung.

Viertens: Die Abdeckung von Netzwerkrichtlinien nimmt zu, insbesondere für privilegierte Konten und interne Staging-Bereiche.

Fünftens: Trust-Center-Ergebnisse werden nicht nur angezeigt, sondern mit Ausnahmeberechtigten und Ablaufdaten behoben. Sechstens: Telemetrieaufbewahrung und -export sind ausreichend für verspätete Erkennung und Datenschutzabgrenzung. Siebtens: Erkennungen großer Entladungen und ungewöhnlicher Ursprünge werden abgestimmt und an Personen weitergeleitet, die handeln können. Achtens: Anbieterbenachrichtigungen enthalten konkrete Sitzungs-, Abfrage-, Rollen-, Objekt- und Übertragungsbeweise. Neuntens: Betroffene Kunden können Abfragen Personen und regulierten Datenkategorien zuordnen.

Zehntens: Kundenverträge und Verlängerungsüberprüfungen beziehen Evidenz ein, anstatt sich auf Formulierungen zur geteilten Verantwortung zu verlassen.

Rechtsstreitigkeiten können die Aufzeichnung beeinflussen, sollten aber Kontrollevidenz nicht ersetzen. Die Anordung im Stadium der Klagebegründung im Snowflake-Multidistrict-Litigation unter source: govinfo.gov ließ bestimmte Behauptungen zu, behandelte sie jedoch nach Verfahrensstandards. Das ist keine endgültige Haftungsfeststellung. Es zeigt jedoch, dass Gerichte die Voreinstellungen des Anbieters, die Vorhersehbarkeit und die Kausalität untersuchen können, selbst wenn die öffentliche Geschichte mit Kundenanmeldedaten beginnt.

Das Problem der installierten Basis

Sichere Voreinstellungen sind zum Zeitpunkt der Erstellung am effektivsten. Sie sind in einer installierten Basis schwieriger, in der Kunden bereits Automatisierung, Dienstbenutzer, Auftragnehmer, Identitätsanbieter, alte Clients und Notfallkonten haben. Snowflakes Änderung der standardmäßigen MFA für neue Konten war ein wesentlicher Schritt, aber das Risiko der Kampagne lag stark in bestehenden Konten mit bestehenden Gewohnheiten. Überprüfbare Reparatur benötigt daher eine Migrationsgeschichte für die installierte Basis, nicht nur eine Geschichte für neue Konten.

Das Problem der installierten Basis hat mehrere Ebenen. Erstens können alte menschliche Benutzer immer noch direkt mit Passwörtern authentifizieren, weil die Föderation nie abgeschlossen wurde. Zweitens können privilegierte Benutzer Ausnahmen haben, weil Administratoren eine Sperrung befürchten. Drittens können Dienstbenutzer fälschlicherweise als Menschen klassifiziert sein oder Menschen dienstähnliche Anmeldedaten verwenden. Viertens können Auftragnehmer nach Projektende weiterhin Zugriff haben. Fünftens können ruhende Konten immer noch Rollen haben, die auf sensible Daten zugreifen.

Sechstens können Integrationen fehlschlagen, wenn sich Passwortregeln oder Netzwerkrichtlinien plötzlich ändern.

Der Anbieter kann diese Reibung reduzieren, ohne den Mandanten des Kunden zu übernehmen. Er kann Administratoren eine priorisierte Liste riskanter Identitäten zeigen, aufgeteilt nach Berechtigung und Datenreichweite. Er kann Trockenübungsrichtlinien bereitstellen, die zeigen, wer durch MFA oder Netzwerkbeschränkungen blockiert würde. Er kann Ausnahmeberechtigte und Ablaufdaten verlangen. Er kann zwischen Break-Glass-Konten und gewöhnlichen Legacy-Konten unterscheiden. Er kann Migrationshilfen für Dienstbenutzer bereitstellen, die zu Schlüsselpaar- oder OAuth-Mustern wechseln.

Er kann wiederholte Produktanregungen senden, die an tatsächliches Risiko gekoppelt sind, nicht an generische Banner.

Kunden müssen dann handeln. Ein Kunde, der ein Dashboard mit privilegierten Nur-Passwort-Benutzern erhält und diese monatelang unverändert lässt, trägt dieses Restrisiko. Ein Kunde, der nicht sagen kann, ob ein Auftragnehmerkonto noch benötigt wird, hat ein Identitäts-Governance-Versagen. Ein Kunde, der ein Dienstkonto ganze Rohdaten lesen lässt, weil „die Pipeline es früher brauchte“, hat einen übermäßigen Rollenumfang. Geteilte Verantwortung wird konkret, wenn der Anbieter die Evidenz zeigt und der Kunde entweder Abhilfe schafft oder eine rechenschaftspflichtige Ausnahme aufzeichnet.

Der Reparaturnachweis sollte drei Zustände trennen: behoben, ausgenommen und unbekannt. Beheben bedeutet, dass der riskante Zustand beseitigt ist. Ausgenommen bedeutet, dass ein Geschäftsinhaber ihn mit kompensierenden Kontrollen und einem Datum für die Überprüfung akzeptiert hat. Unbekannt bedeutet, dass niemand die Verantwortung übernommen hat. Ein ausgereiftes Programm treibt die unbekannte Zahl gegen Null. Öffentliche Beruhigung überspringt oft diese Unterscheidung; überprüfbare Reparatur hängt von ihr ab.

Kundenevidenz muss technische Protokolle mit Personen verbinden

Snowflake kann reichhaltige technische Telemetrie bereitstellen, aber die Reaktion auf Datenschutz- und Rechtsfragen erfordert eine Brücke von technischen Objekten zu Personen und Pflichten. Eine Abfragekennung, ein Rollenname oder ein Staging-Bereichspfad ist nur der Anfang. Der Kunde muss wissen, welche Tabelle welche persönlichen Felder enthielt, welche betroffenen Personen vertreten waren, welche Länder- oder Staatsregeln gelten, welche vertraglichen Benachrichtigungspflichten bestehen und welche nachgelagerten Systeme Kopien erhalten haben.

Ohne diese Brücke kann der Kunde wissen, dass Bytes den Ort verlassen haben, aber nicht wissen, wen er benachrichtigen muss.

Diese Brücke sollte vor einem Vorfall vorbereitet werden. Datenverantwortliche sollten Feldinventare für regulierte Daten, Geschäftszweck, Aufbewahrungsfrist, Maskierungsrichtlinie und genehmigte Exportrouten pflegen. Sicherheitsteams sollten wissen, wo Snowflake-Protokolle außerhalb der Plattform aufbewahrt werden und wie lange. Datenschutzteams sollten in der Lage sein, eine Liste betroffener Tabellen anzufordern und eine Zuordnung zu Personenkategorien und Feldern zu erhalten. Rechtsteams sollten wissen, welche Regionen und Kundenverträge an diese Aufzeichnungen gebunden sind.

Anbieterevidenz kann dies erleichtern. Wenn eine Benachrichtigung die genauen Rollen, Objekte, Staging-Bereiche und das Volumen enthält, kann der Kunde eine breite und langsame Suche vermeiden. Wenn der Anbieter auch kennzeichnet, ob MFA vorhanden war, ob die Quelle ungewöhnlich war und ob der Schutz vor durchgesickerten Passwörtern später die Anmeldedaten deaktivierte, kann der Kunde Ursache und Eindämmung verstehen. Wenn der Anbieter nur allgemeine Ratschläge gibt, muss der Kunde die Beweise rekonstruieren, während die Uhr für Benachrichtigung und Erpressungsreaktion bereits läuft.

Die Kampagne warf auch eine Aufbewahrungsfrage für die Telemetrie selbst auf. Native Verläufe können ein Jahr abdecken, aber Rechtsstreitigkeiten, verspätete Entdeckung und Anfragen von Aufsichtsbehörden können länger dauern. Hochriskante Kunden sollten Protokolle in einen unabhängigen Sicherheitsspeicher streamen, dessen Aufbewahrung an ihre Verpflichtungen angepasst ist. Ein Anbieter sollte einen solchen Export praktisch und dokumentiert machen. Der Kunde sollte nachweisen, dass es funktioniert, indem er regelmäßig einen Beispielzugriffspfad vom Login über die Abfrage bis zur Datenkategorie rekonstruiert.

Reparatur kann sich nicht auf Kundenscham verlassen

Nach einer Anmeldedatenkampagne ist es verlockend, Kunden ohne MFA als die Lehre der Geschichte zu betrachten. Das ist teilweise wahr und dennoch unzureichend. Kunden öffentlich zu beschämen, deaktiviert keine durchgesickerten Passwörter, gestaltet keine Voreinstellungen neu und liefert keine Evidenzpakete. Es kann Kunden sogar dazu bringen, schwache Konfigurationen zu verstecken, bis ein Vorfall die Offenlegung erzwingt.

Das bessere Modell ist die progressive Härtung. Der Anbieter beginnt mit Sichtbarkeit, dann stärkeren Voreinstellungen, dann gezielten Warnungen, dann Ausnahme-Governance, dann Durchsetzung für Risikokategorien, bei denen die Konsequenz dies rechtfertigt. Kunden erhalten Migrationszeit und Werkzeuge, verlieren aber die Fähigkeit, Hochrisikolücken unsichtbar zu lassen. Beschaffungsteams fragen dann nach Einführungsmetriken und Ausnahmeanzahlen, nicht nur nach Funktionslisten.

Dieser Ansatz erkennt an, dass Cloud-Plattformen gemeinsame Betriebssysteme für Unternehmensdaten sind. Ein Anbieter, der eine sicherere Voreinstellung macht, kann kurzfristig die Kundenreibung erhöhen, reduziert aber auch den Pool von Zielen, die kriminellen Gruppen zur Verfügung stehen. Ein Kunde, der die Durchsetzung akzeptiert, muss möglicherweise Skripte oder Identitäten aktualisieren, gewinnt aber eine stärkere Geschichte für Aufsichtsbehörden, Versicherer und betroffene Personen. Reparatur funktioniert, wenn beide Seiten auf geänderte Bedingungen verweisen können, nicht auf geänderte Botschaften.

Beschaffung sollte Reparaturtelemetrie verlangen

Ein Käufer einer hochwertigen Datenplattform sollte Telemetrie nach der Kampagne als Beschaffungsanforderung behandeln. Die Frage ist nicht nur, ob der Anbieter jetzt MFA, Netzwerkrichtlinien, Kontrollen für durchgesickerte Passwörter und Trust-Center-Ergebnisse anbietet. Die Frage ist, ob der Käufer Beweise erhalten kann, dass diese Kontrollen im eigenen Konto aktiv, vollständig und getestet sind. Funktionsverfügbarkeit ist Anbietersprache. Kontrollabdeckung ist Betriebssprache.

Die Beschaffungsaufzeichnung sollte nach einem Identitätsdeckungsbericht fragen, einschließlich menschlicher Benutzer, privilegierter Benutzer, Dienstbenutzer, ruhender Konten, externer Auftragnehmer, Föderationsstatus, MFA-Status und Passwortausnahmen. Sie sollte nach Netzwerkabdeckung nach Konto, Benutzerklasse, internen Staging-Bereichen und privaten Endpunkten fragen. Sie sollte fragen, ob der Schutz vor durchgesickerten Passwörtern aktiviert ist, welche Ereignisbenachrichtigungen er erzeugt und wie ein deaktiviertes Passwort in Prüfprotokollen widergespiegelt wird.

Sie sollte fragen, welche Trust-Center-Ergebnisse auf der vertraglich vereinbarten Stufe verfügbar sind und wie lange der relevante Verlauf aufbewahrt wird.

Vorfallsklauseln sollten ebenso konkret sein. Eine allgemeine Benachrichtigungsklausel ist nach dieser Kampagne schwach. Kunden benötigen Zeitpläne für Benachrichtigungen mit hohem Schweregrad, Evidenzfelder, die enthalten sein werden, Notfallkontakte, Support-Eskalation, Aufbewahrung von Protokollen und Zusammenarbeit bei der Abgrenzung betroffener Personen. Ein Kunde, der regulierte personenbezogene Daten hält, sollte vor der Verlängerung Beispiel-Evidenzpakete verlangen, nicht nach einem Diebstahl.

Eine Tabletop-Übung kann testen, ob Anbieter und Kunde innerhalb des erforderlichen Zeitfensters von einem verdächtigen Login zur Analyse betroffener Felder gelangen können.

Dies verlagert nicht die gesamte Arbeit auf Snowflake. Der Kunde muss seine eigenen Karten pflegen, Protokolle aufbewahren und seine Datenschutzverpflichtungen kennen. Aber der Anbieter kontrolliert viele Fakten, die benötigt werden, damit die Karte nutzbar wird. Ein Beschaffungsprozess, der nur nach Zusicherungen fragt, wird das betriebliche Problem übersehen. Ein Prozess, der nach Reparaturtelemetrie fragt, wird offenbaren, ob die geteilte Verantwortung für die nächste Kampagne bereit ist.

Dieselbe Evidenz sollte bei Verlängerungen erscheinen. Wenn ein Kunde ein Jahr nach der Kampagne weiterhin passwortlastigen Zugriff hat, sollte die Verlängerung eine benannte Ausnahme oder eine finanzierte Migration erzwingen. Wenn ein Kunde aufgrund der Edition keine ACCESS_HISTORY-Details erhalten kann, sollte die Verlängerung dokumentieren, ob diese Einschränkung für die gespeicherten Daten akzeptabel ist. Wenn Netzwerkrichtlinien fehlen, sollte die Verlängerung den betrieblichen Engpass klar identifizieren. Die Reparatur sollte überprüft werden, bevor die Hebelwirkung in eine andere Vertragslaufzeit verschwindet.

Verlängerungsevidenz sollte auch Plattformänderung von Mandantenänderung trennen. Snowflake kann eine stärkere Voreinstellung ausliefern, aber das Konto des Kunden kann immer noch Nur-Passwort-Benutzer, breite Rollen, veraltete Auftragnehmer und nicht überprüfte Staging-Bereiche enthalten. Der Käufer sollte das eigene Ausnahmeverzeichnis des Kontos anfordern, nicht nur die Produkt-Roadmap des Anbieters. Diese Unterscheidung verhindert eine bekannte Abweichung nach einem Vorfall: Der Anbieter kündigt eine Kontrolle an, Kunden nehmen an, dass das Risiko verschwunden ist, und die installierte Basis bleibt erheblich exponiert.

Für Vorstände und Datenschutzteams ist diese mandantenbezogene Aufzeichnung die Brücke zwischen technischer Reparatur und rechtlichem Vertrauen. Die Behauptung, dass „MFA verfügbar ist“, beantwortet nicht, ob das betroffene Konto sie verwendet hat. Die Behauptung, dass „Netzwerkrichtlinien existieren“, beantwortet nicht, ob die gestohlenen Anmeldedaten von einem ungewöhnlichen Ursprung auf Daten zugreifen konnten. Die Behauptung, dass „Telemetrie aufbewahrt wird“, beantwortet nicht, ob die Organisation Abfragen regulierten Feldern zuordnen kann. Überprüfbare Reparatur lebt von diesen kontospezifischen Antworten.

Was nicht abgeleitet werden sollte

Ein zurückhaltender Bericht sollte vier Sprünge vermeiden. Erstens: Die Kampagne beweist nicht, dass Snowflakes Produktionsplattform kompromittiert wurde. Zweitens: Sie beweist nicht, dass jede benachrichtigte Organisation Daten verloren hat. Drittens: Sie beweist nicht, dass jeder betroffene Kunde dieselben Felder, Personen oder rechtlichen Pflichten hatte. Viertens: Produktänderungen nach der Kampagne beweisen nicht allein Fahrlässigkeit vor den Änderungen. Sicherheitsprodukte entwickeln sich aus vielen Gründen nach Vorfällen weiter, darunter bessere Bedrohungsinformationen und geänderte Standards.

Gleichzeitig erfordert Zurückhaltung keine Stille über die Pflicht des Anbieters. Ein Anbieter kann frei von einem Plattform-Einbruchbefund sein und dennoch für Standarddesign, Telemetriequalität und kundenübergreifende Warnungen verantwortlich sein. Ein Kunde kann für schwache Identitätskontrollen verantwortlich sein und dennoch die Daten des Anbieters für die Untersuchung benötigen. Eine gerichtliche Anordnung kann nicht endgültig sein und dennoch zeigen, dass standardmäßige MFA und Vorhersehbarkeit geprüft werden. Ausgewogene Verantwortung hält all diese Aussagen gleichzeitig am Leben.

Die abschließende Bewertung ist hohe Auswirkung und hohes Vertrauen. Die bestätigte Evidenz stützt eine Kampagne mit Kundenanmeldedaten, keinen Snowflake-Plattform-Einbruch. Aber die Evidenz zeigt auch, warum Anbietervoreinstellungen, Telemetrie und kundenübergreifende Sicherheitsautomatisierung Teil der Verantwortlichkeit sind. Geteilte Verantwortung ist nur glaubwürdig, wenn beide Seiten die Tore zeigen können, die sie geschlossen haben. Nach dieser Kampagne besteht Snowflakes Test nicht darin, ob es sagen kann, dass MFA existierte.

Es ist, ob weniger gestohlene Passwörter zu Sitzungen werden können, weniger Sitzungen auf breite Daten zugreifen können und mehr Kunden genau beweisen können, was passiert ist, bevor Daten den Ort verlassen.