Snowflake: Nachweisbare Reparatur als Test für geteilte Cloud-Verantwortung

Zusammenfassung

• Mandiant berichtete, dass jeder von ihm direkt bearbeitete Vorfall der Snowflake-Kampagne auf kompromittierte Kundenzugangsdaten zurückzuführen war und keine Hinweise darauf gefunden wurden, dass ein unbefugter Zugriff auf einen Verstoß gegen die Unternehmensumgebung von Snowflake zurückzuführen war. Der Kampagnenbericht ist unterhttps://cloud.google.com/blog/topics/threat-intelligence/unc5537-snowflake-data-theft-extortionabrufbar.
• Die Kampagne stellte dennoch die Anbieterverantwortung auf die Probe, da Snowflake Authentifizierungsoberflächen, Produktstandards, Sicherheitsleitfäden, Kontotelemetrie, Netzwerkrichtlinien-Werkzeuge, Trust Center-Prüfungen und Änderungen nach der Kampagne kontrollierte, die kein einzelner Kunde allein hätte umsetzen können.
• Nachweisbare Reparatur bedeutet messbare Veränderung: Standard-MFA für menschliche Benutzer in neuen Konten, strengere Passwortregeln, automatische Deaktivierung geleakter Passwörter, Kundenbeweispakete, Netzwerkursprungskontrollen und Einführungsmetriken, die eine Risikominderung über die installierte Basis hinweg zeigen.
• Die Kundenverantwortung bleibt erheblich. Kunden kontrollierten Benutzererstellung, Rollenzuweisungen, Passwortrotation, MFA-Registrierung in bestehenden Konten, Zugriff durch Auftragnehmer, Netzwerk-Zulassungslisten, Datenminimierung, Exportberechtigungen und Untersuchungsbereitschaft.

Die Plattform war nicht nachweislich kompromittiert; die Grundkonfiguration war nachweislich zu permissiv

Die erste Disziplin besteht darin, die Grenzen der Kampagne präzise zu halten. Mandiants Bericht vom Juni 2024 stellte fest, dass die unbefugten Zugriffe in den von ihm bearbeiteten Vorfällen auf kompromittierte Kundenzugangsdaten zurückzuführen waren und keine Hinweise auf eine Kompromittierung der Unternehmensumgebung von Snowflake gefunden wurden. Die Kundenleitlinien von Snowflake, die durch CISA unterhttps://www.cisa.gov/news-events/alerts/2024/06/03/snowflake-recommends-customers-take-steps-prevent-unauthorized-accessverbreitet wurden, wiesen die Kunden ebenfalls an, unbefugte Benutzerzugriffe zu untersuchen und Identitäts- sowie Netzwerkkontrollen zu verstärken. Die überprüften Aufzeichnungen belegen keinen Plattform-Exploit bei Snowflake, keinen mandantenübergreifenden Ausbruch und keinen Diebstahl von Master-Zugangsdaten des Anbieters.

Diese negative Feststellung ist wichtig, weil sie die unmittelbare Reaktion prägt. Ein Kunde sollte nicht auf einen Anbieter-Patch warten, wenn das aktuelle Problem aus gültigen Benutzerzugangsdaten ohne MFA, ohne Netzwerk-Zulassungsliste und mit weitreichenden Rollenberechtigungen besteht. Der Kunde muss Zugangsdaten rotieren, Konten deaktivieren, Anmelde- und Abfrageverläufe überprüfen, Ursprungsnetzwerke einschränken, Rollen überprüfen, Protokolle aufbewahren und bei Bedarf betroffene Personen oder Aufsichtsbehörden benachrichtigen.

Der umgekehrte Fehler wäre zu sagen, der Anbieter trage keine Verantwortung, weil das erste Geheimnis den Kunden gehörte. Snowflake betrieb den Authentifizierungsendpunkt, der diese Passwörter akzeptierte. Es stellte die MFA-Fähigkeit bereit und entschied, wann das Standardverhalten geändert wird. Es legte Telemetriefelder offen oder hielt sie zurück. Es bot Netzwerkrichtlinienkontrollen und Trust Center-Ergebnisse. Es konnte kundenübergreifende Signale erkennen, die kein einzelner Mandant sehen konnte. Es konnte später einen Schutz vor geleakten Passwörtern in den Dienst integrieren.

Das ist echte Kontrolle, auch wenn das Konto dem Kunden gehörte.

Der Jahresbericht von Snowflake für das Geschäftsjahr 2025 unterhttps://www.sec.gov/Archives/edgar/data/1640147/000164014725000052/snow-20250131.htmlegt die Position des Unternehmens zur geteilten Verantwortung dar und beschreibt rechtliche, regulatorische und Reputationsfolgen nach den Aktivitäten von 2024. Ein solcher Bericht ist eine Unternehmensdarstellung und keine richterliche Entscheidung. Er ist dennoch relevant, weil Snowflake selbst offengelegt hat, dass die Kampagne das Geschäftsrisiko über einzelne Kundenmandanten hinaus beeinflusste. Die geteilte Verantwortung wurde zu einem Thema börsennotierter Unternehmen.

Die Perspektive dieses Artikels ist daher nicht „Snowflake wurde kompromittiert“ oder „die Kunden allein haben versagt“. Es geht um nachweisbare Reparatur. Nachdem eine Kampagne ein vorhersehbares Muster aus reinem Passwortzugriff, veralteten Infostealer-Zugangsdaten und fehlenden Netzwerkeinschränkungen ausgenutzt hat, benötigen Anbieter und Kunden den Nachweis, dass die nächste ähnliche Kampagne auf weniger nutzbare Zugangsdaten, weniger reine Passwortsitzungen, weniger uneingeschränkte Ursprünge, bessere Warnungen und eine schnellere Bereitstellung von Beweisen stoßen wird.

Der Kampagnenpfad nutzte gewöhnliche Funktionen unter feindlicher Identität

Mandiant beschrieb eine praktische Kette. Zugangsdaten waren durch Infostealer-Malware von Systemen gestohlen worden, die nicht Snowflake gehörten, darunter in einigen Fällen auch Auftragnehmer-Rechner, die für private Aktivitäten genutzt wurden. Diese Zugangsdaten blieben gültig, teilweise über Jahre hinweg. Den Konten fehlte MFA. Kundeninstanzen hatten keine Netzwerk-Zulassungslisten. Angreifer verbanden sich mit Standard-Clients und -Werkzeugen, führten Aufklärungsarbeiten durch, wählten Daten aus, bereiteten Ergebnisse auf, komprimierten Dateien und zogen sie ab.

Das Muster nutzte unterstützte Datenbankfunktionen unter einer nicht autorisierten Identität.

Diese Unterscheidung ist für die Reparatur von zentraler Bedeutung. Verschlüsselung im Ruhezustand war nicht die entscheidende Barriere. Die Dokumentation von Snowflake zur Ende-zu-Ende-Verschlüsselung unterhttps://docs.snowflake.com/en/user-guide/security-encryption-end-to-endbeschreibt die Verschlüsselung im Ruhezustand und während der Übertragung, erklärt aber auch, dass Daten bei Tabellenoperationen genutzt 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 um lesbare Ergebnisse bitten. Verschlüsselung ist kein Ersatz für Identitätssicherung, Rollendesign, Exportkontrolle und Erkennung.

Die Zugriffskontrolle bestimmte den Explosionsradius nach der Anmeldung. Die Übersicht von Snowflake zur Zugriffskontrolle unterhttps://docs.snowflake.com/en/user-guide/security-access-control-overviewbeschreibt Rollen, Berechtigungen, Eigentumsverhältnisse und Hierarchien. Eine gestohlene Zugangsdaten mit engem Zugriff unterscheidet sich von einer mit umfassenden Leseberechtigungen oder Kontoadministration. Ein Servicekonto, das für eine Pipeline erstellt wurde, unterscheidet sich von einem Administrator eines Auftragnehmers. Das Prinzip der geringsten Rechte ist nicht nur ein Schlagwort; es ist der Unterschied zwischen einer feindlichen Sitzung, die eine einzige Ansicht zurückgibt, und einer feindlichen Sitzung, die durch die wichtigsten Kundentabellen wandert.

Datenklassifizierung und Maskierung können die Folgen verringern. Die Dokumentation von Snowflake zur Klassifizierung sensibler Daten unterhttps://docs.snowflake.com/en/user-guide/classify-introverbindet die Erkennung sensibler Spalten mit Maskierungs- und Zeilenzugriffsrichtlinien. Dies beweist nicht, dass betroffene Kunden über solche Kontrollen verfügten. Es zeigt einen Reparaturpfad auf: Kunden sollten personenbezogene und regulierte Felder identifizieren, wo möglich Ansichten statt Rohdaten bereitstellen und Exportrollen von gewöhnlichen Leserollen trennen.

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

MFA-Verfügbarkeit wurde zu MFA-Ergebnissen

MFA war bereits vor der Kampagne verfügbar. Den erfolgreich angegriffenen Konten aus Mandiants Bericht fehlte sie. Diese Lücke ist der Kern des Streits um die geteilte Verantwortung. Ein Kundenadministrator konnte MFA aktivieren, und viele taten dies nicht. Ein Anbieter kann wahrheitsgemäß sagen, die Kontrolle sei verfügbar gewesen. Aber ein Anbieter, der viele hochwertige Konten sieht, die weiterhin allein mit Passwort erreichbar sind, hat das Sicherheitsziel nicht erreicht, sondern nur die Einstellung verfügbar gemacht.

Die Ankündigung von Snowflake vom September 2024 unterhttps://www.snowflake.com/en/blog/multi-factor-identification-default/veränderte die Produktpositionierung. Darin hieß es, MFA werde ab Oktober 2024 für menschliche Benutzer in neu erstellten Konten standardmäßig erzwungen und Servicebenutzer seien von dieser spezifischen Anforderung ausgenommen. Außerdem wurden strengere Passwortanforderungen für neu erstellte und geänderte Benutzerpasswörter angekündigt. Dies ist eine bedeutsame Reparatur, da sie den Standardpfad für zukünftige Konten ändert.

Die Unterscheidung zwischen neuen und bestehenden Konten ist ebenso bedeutsam. Ein Standard für zukünftige Konten beseitigt nicht automatisch jeden reinen Passwortzugriff in der installierten Basis. Bestehende Kunden haben möglicherweise Legacy-Benutzer, Servicekonten, Auftragnehmer, Notfallkonten und ältere Clients.

Eine nachweisbare Reparaturaufstellung sollte daher das Legacy-Risiko direkt messen: Anzahl und Anteil menschlicher Benutzer ohne MFA, privilegierte menschliche Benutzer ohne MFA, Passwortbenutzer mit veralteten letzten Anmeldezeitpunkten, Benutzer mit bekannten offengelegten Zugangsdaten, Servicekonten, die Passwörter anstelle stärkerer Workload-Authentifizierung verwenden, sowie Ausnahmen mit Geschäftsverantwortlichen und Ablaufdaten.

Die Dokumentation von Snowflake zu Authentifizierungsrichtlinien unterhttps://docs.snowflake.com/en/user-guide/authentication-policiesgibt Administratoren Kontrollen über Authentifizierungsmethoden, Clients, Identitätsanbieter und MFA-Registrierung. Die Dokumentation zur Schlüsselpaar-Authentifizierung unterhttps://docs.snowflake.com/en/user-guide/key-pair-authbietet Servicekonten eine Alternative zu statischen Passwörtern. Diese Kontrollen legen Pflichten für die Kunden fest, aber sie definieren auch die Reparaturoberfläche des Anbieters: Das Produkt sollte gute Muster erleichtern, schlechte Ausnahmen sichtbar machen und die Migration risikoärmer gestalten.

Die NIST-Leitlinien für digitale Identität unterhttps://pages.nist.gov/800-63-4/sp800-63b.htmlhelfen, das Ziel zu formulieren. Passwörter sind nicht wiedergaberesistent. Phishing-resistente oder kryptografisch gebundene Methoden verringern den Wert eines gestohlenen Passworts. Für Snowflake-Kunden bedeutet dies, dass menschliche Administratoren über föderierte Identität oder starke MFA gehen sollten, während Servicebenutzer bereichsspezifische Workload-Zugangsdaten verwenden sollten, die rotieren und deaktiviert werden können, ohne eine Person zu imitieren.

Blockierung geleakter Passwörter machte geteilte Verantwortung messbar

Die direkteste Anbieterreparatur nach einer Kampagne mit gestohlenen Zugangsdaten ist kein Vortrag über Passwortwiederverwendung. Es geht darum, bekannte gestohlene Passwörter unwirksam zu machen. Die Ankündigung von Snowflake vom Dezember 2024 unterhttps://www.snowflake.com/en/blog/leaked-password-protection/besagte, dass im Darknet entdeckte Passwörter durch einen datenschutzfreundlichen Prozess automatisch deaktiviert werden, wenn sie als geleakt und weiterhin gültig bestätigt sind. Diese Kontrolle adressiert den zentralen Vorteil der Kampagne: Zugangsdaten, die lange vor 2024 gestohlen wurden, blieben vom Dienst akzeptiert.

Der Schutz vor geleakten Passwörtern beseitigt nicht die Kundenpflichten. Kunden benötigen weiterhin Endpunktsicherheit, Auftragnehmer-Governance, Passwortrotation, Föderierung, Servicebenutzer-Design und das Prinzip der geringsten Rechte. Aber er verändert die Arbeitsteilung. Einzelne Kunden können den globalen Infostealer-Markt oft nicht so gut überblicken wie ein Cloud-Anbieter. Ein Anbieter kann Bedrohungsinformationen kaufen oder empfangen, offengelegte Zugangsdaten kontrolliert abgleichen und ein Passwort deaktivieren, bevor jeder Kunde es selbst entdeckt.

Das ist die Art von Anbieterkontrolle, die geteilte Verantwortung von einer Vertragsklausel in ein Systemverhalten verwandelt.

Die Nachweisfrage ist Einführung und Leistung. Wie viele gültige geleakte Passwörter wurden gefunden? Wie schnell wurden sie deaktiviert? Wie viele gehörten privilegierten Benutzern? Wie viele Konten wechselten von Passwort zu Schlüsselpaar oder föderiertem Zugang? Wie viele Ereignisse deaktivierter Passwörter führten zu Support-Reibungen oder unsicheren Workarounds? Wie viele Kunden haben weiterhin Ausnahmen? Ohne Metriken bleibt der Schutz vor geleakten Passwörtern eine gute Ankündigung. Mit Metriken wird er zu nachweisbarer Reparatur.

Die CISA-Initiative „Secure by Design“ unterhttps://www.cisa.gov/sites/default/files/2024-05/CISA%20Secure%20by%20Design%20Pledge_508c.pdfumreißt diese Unterscheidung. Sie fordert Hersteller auf, über optionale Kontrollen hinaus zu messbaren Ergebnissen wie Standard-MFA und Einführungsmetriken überzugehen. Die Ankündigung von Snowflake vom Juli 2024 zu dieser Verpflichtung unterhttps://www.snowflake.com/en/blog/snowflake-cybersecurity-cisa-secure-by-design/platzierte das Unternehmen innerhalb dieser öffentlichen Selbstverpflichtung. Die Verpflichtung ist freiwillig und kein rechtliches Urteil über die Kampagne. Sie ist relevant, weil sie die Art von Nachweisen benennt, die Kunden nach dem Vorfall erwarten sollten.

Netzwerkrichtlinie war ein zweites Tor

Mandiant identifizierte fehlende Netzwerk-Zulassungslisten als einen wiederkehrenden Faktor. Die Dokumentation von Snowflake zu Netzwerkrichtlinien unterhttps://docs.snowflake.com/en/user-guide/network-policiesbeschreibt den praktischen Standard: Ohne eine Richtlinie können Benutzer von jedem Computer oder Gerät aus eine Verbindung herstellen. Kunden können den Zugriff auf erlaubte oder blockierte Netzwerkstandorte beschränken und private Konnektivitätsmuster für stärkere Abgrenzungen 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 zugelassene Integrationsanbieter. Snowflake kann nicht jeden gültigen Pfad erraten, ohne den Dienst zu beeinträchtigen. Aber Snowflake kontrolliert, ob uneingeschränkter öffentlicher Zugriff still oder sichtbar ist.

Ein nachweisbares Reparaturprogramm sollte berichten, welche Konten keine Netzwerkrichtlinien haben, welche privilegierten Benutzer sie umgehen, ob der Zugriff auf interne Stages abgedeckt ist und ob die Richtlinien tatsächlich mit den geschäftlich genehmigten Ursprüngen übereinstimmen.

Netzwerkkontrollen allein reichen nicht aus. Ein Angreifer kann ein genehmigtes VPN nutzen, einen Auftragnehmer-Rechner kompromittieren, der bereits auf einer Zulassungsliste steht, oder nach der Authentifizierung ein Token stehlen. Dennoch sollte die Verteidigung mehrschichtig sein. Ein gestohlenes Passwort, keine MFA, keine Netzwerkeinschränkung, eine weitreichende Rolle und ein nicht überwachter Export bilden eine Kette. Das Durchbrechen eines einzelnen Gliedes kann entscheidend sein. Reparatur ist der Prozess, die Anzahl der Kundenumgebungen zu reduzieren, in denen alle Glieder gemeinsam offen bleiben.

Der Anbieter sollte auch die Verwaltung von Aussperrungen sicher gestalten. Administratoren vermeiden möglicherweise Netzwerkrichtlinien, weil sie fürchten, geschäftliche Benutzer oder Serviceaufträge zu blockieren. Simulation, gestaffelte 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 betrachten.

Telemetrie ist die Nachweisgrenze

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

LOGIN_HISTORY unterhttps://docs.snowflake.com/en/sql-reference/account-usage/login_historyliefert Anmeldeversuche mit Quell-IP, Client, Erfolg und Faktorinformationen. QUERY_HISTORY unterhttps://docs.snowflake.com/en/sql-reference/account-usage/query_historyliefert Abfrageaktivitäten, Benutzer, Rolle, Abfragetext, Ergebnisgröße, entladene Zeilen und über das Netzwerk gesendete Bytes. ACCESS_HISTORY unterhttps://docs.snowflake.com/en/sql-reference/account-usage/access_historykann helfen, den Zugriff auf Objekte und Spalten für berechtigte Editionen zu rekonstruieren. Die Dokumentation des Trust Centers unterhttps://docs.snowflake.com/en/user-guide/trust-center/overviewbeschreibt Haltungsprüfungen und Erkennungen für MFA, Netzwerkrichtlinien, riskante Anmeldungen, ungewöhnliche IP-Adressen und große Übertragungen.

Das sind Fähigkeiten. Fähigkeiten sind kein Beweis für Untersuchungsbereitschaft. Kunden müssen die Rechte haben, die Ansichten abzufragen, sie in einen dauerhaften Sicherheitsspeicher zu exportieren, Latenz und Aufbewahrung zu verstehen und sie mit Daten des Identitätsanbieters, der Endpunkte und Ticketsysteme zu korrelieren. Editionsunterschiede können die Präzision der feldbezogenen Abgrenzung verändern. Anbieteransichten können Verzögerungen aufweisen, die für eine aktive Eindämmung relevant sind.

Abfragetexte allein verraten einem Datenschutzteam möglicherweise nicht, welche Personen betroffen waren, es sei denn, der Kunde verfügt über Datenlandkarten.

Nachweisbare Reparatur sollte daher Beweispakete umfassen. Wenn Snowflake einen potenziell betroffenen Kunden benachrichtigt, sollte der Kunde Kontoidentifikatoren, Benutzer, Zeitstempel, Ursprungsnetzwerke, Status des ersten und zweiten Faktors, Client-Identifikatoren, Sitzungs- und Abfrageidentifikatoren, Rollen, berührte Objekte, Stage-Namen, Entladevolumen, Konfidenz und empfohlene Eindämmungsmaßnahmen erhalten. Eine Bezeichnung wie „potenziell betroffen“ ist als Einstieg akzeptabel, muss jedoch von ausreichenden Daten gefolgt werden, damit der Kunde entscheiden kann, ob personenbezogene Daten involviert waren.

Anbietereingriffe benötigen auch eine vorherige Ermächtigung. Ein Cloud-Anbieter kann verdächtige Aktivitäten sehen, bevor der Kunde sie bemerkt, aber das automatische Blockieren einer Sitzung kann den Betrieb stören. Nicht zu handeln kann Diebstahl ermöglichen. Die Reparatur sollte Schwellenwerte für vorübergehende Aussetzung, Notfallkundenkontakte, Beweissicherung und Übersteuerung definieren. Kunden sollten Sicherheitskontakte benennen, die jederzeit handeln können. Snowflake sollte die Zeit vom kundenübergreifenden Signal bis zur Kundenbenachrichtigung und die Zeit von der Benachrichtigung bis zur Eindämmung messen.

Datenlokalität endete beim Zugriff

Die Wahl der Region bei Snowflake kann für Latenz, Resilienz, Datenschutz und Beschaffung von Bedeutung sein. Die Dokumentation zu unterstützten Regionen unterhttps://docs.snowflake.com/en/user-guide/intro-regionsbesagt, dass ein Konto in einer Region gehostet wird und die Daten dort verbleiben, es sei denn, Benutzer kopieren, verschieben oder replizieren sie ausdrücklich. Sie nennt auch die entscheidende Einschränkung: Die Regionswahl beschränkt nicht den Benutzerzugriff auf Snowflake.

Die Kampagne machte diese Einschränkung zu einem Souveränitätsproblem. Die Tabellen eines Kunden mögen in einer genehmigten Region gespeichert worden sein. Eine gültige Identität konnte sich dennoch von anderswo aus verbinden, die Daten abfragen, sie in eine Stage entladen und eine Kopie herunterladen. Die Platzierung des Quellkontos verhinderte keinen Fernzugriff oder Export. Die öffentliche Kampagnendokumentation legt nicht die Quell- und Zielländer für jedes Opfer fest, sodass keine universelle grenzüberschreitende rechtliche Schlussfolgerung haltbar ist. Die architektonische Lehre bleibt: Speicherlokalität ist nicht Zugriffslokalität.

Die Anleitung von Snowflake zur regionsübergreifenden Datenfreigabe unterhttps://docs.snowflake.com/en/user-guide/secure-data-sharing-across-regions-plaforms.htmlwarnt Kunden davor, rechtliche und regulatorische Einschränkungen zu bestätigen, bevor sie Daten in eine andere Region oder ein anderes Land replizieren. Diese Anleitung betrifft genehmigte Bewegungen. Der zugangsdatengesteuerte Export unterscheidet sich, weil er eine unkontrollierte Kopie außerhalb der gewählten Region erzeugen kann, ohne die Region des Quellkontos zu ändern. Eine Dateninventur, die nur die Quellregion erfasst, kann nach einem Export korrekt und dennoch unvollständig sein.

Die Reparatur der Datensouveränität benötigt daher vier Schichten: Wo die maßgeblichen Daten gehostet werden, welche Identitäten von welchen Geräten und Rechtsordnungen aus Verbindungen herstellen dürfen, welche Bewegungsfunktionen Kopien erzeugen können und welche Beweise nach einem Vorfall vorliegen. Snowflake kontrolliert Regionsangebote, Authentifizierung, Netzwerk-Tools, Exportmechanik und Telemetrie. Kunden kontrollieren die rechtliche Grundlage, Datenfelder, Rollenzuweisungen, Bewegungsgenehmigungen und die Analyse von Benachrichtigungen. Beide Seiten benötigen Beweise an ihrer Grenze.

Kundenfälle zeigen Folgen, nicht eine einzige Gesamtzahl

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

Die Einreichung von Live Nation vom Mai 2024 unterhttps://www.sec.gov/Archives/edgar/data/1335258/000133525824000081/lyv-20240520.htmgab an, das Unternehmen habe unbefugte Aktivitäten in einer Cloud-Datenbankumgebung eines Drittanbieters festgestellt, die hauptsächlich Ticketmaster-Daten enthielt, und ein krimineller Akteur habe später angebliche Unternehmensbenutzerdaten zum Verkauf angeboten. Die Einreichung nannte Snowflake nicht und lieferte keine bestätigte Zahl betroffener Personen.

Die Vorfallseite von Ticketmaster Canada unterhttps://help.ticketmaster.ca/hc/en-us/articles/26420491205009-Ticketmaster-Data-Security-Incidentbeschrieb 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 kanadische Datenschutzbeauftragte identifizierte später Snowflake als Anbieter von Ticketmaster in einem parlamentarischen Briefing unterhttps://www.priv.gc.ca/en/privacy-and-transparency-at-the-opc/proactive-disclosure/opc-parl-bp/ethi_20251006/is_20251006/, wobei er gleichzeitig darauf hinwies, dass die Untersuchung noch offen sei und Ticketmaster Canada weiterhin der überprüfte Verantwortliche sei.

Die Einreichung von AT&T vom Juli 2024 unterhttps://www.sec.gov/Archives/edgar/data/732717/000073271724000046/t-20240506.htmbeschrieb unbefugten Zugriff auf einen AT&T-Arbeitsbereich auf einer Cloud-Plattform eines Drittanbieters und die Exfiltration von Anruf- und Textinteraktionsdaten. Die Einreichung nannte Snowflake nicht. Sie ist nützlich, um einen offengelegten Vorfall eines Cloud-Arbeitsbereichs eines Drittanbieters und seine Feldabgrenzungen zu verstehen, nicht als eigenständige Zuschreibung.

Diese Beispiele begründen keine kampagnenweite Personenzahl. Mandiants rund 165 potenziell betroffene Organisationen sind eine Benachrichtigungspopulation, keine bestätigte Opferzahl, Datensatzzahl oder Zahl betroffener Einzelpersonen. Jeder Kunde hielt unterschiedliche Daten, Rollen, Aufbewahrungsfristen, Regionen und Benachrichtigungspflichten. Nachweisbare Reparatur muss jedem Kunden helfen, seine eigenen Fakten einzugrenzen, anstatt einer einzigen Zahl auf Plattformebene die ganze Arbeit zu überlassen.

Ein typografischer Hinweis für Beweispakete

Wenn Kunden Cloud-Sicherheitsbeweise mit hoher Dringlichkeit 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 Typografieblock gehört in den öffentlichen Teil, da das Beweisdesign Teil der Reparatur ist.

Typografie ist die Kunst und Technik, Schrift so anzuordnen, dass geschriebene Sprache leserlich, lesbar und visuell ansprechend wird. Sie umfasst die Auswahl von Schriftarten, Schriftgrößen, Zeilenlängen, Zeilenabständen und Buchstabenabständen.

• Die Typografie entstand mit der Erfindung des beweglichen Lettern durch Johannes Gutenberg im 15. Jahrhundert.
• Zu den Schlüsselelementen gehören Schriftartauswahl, Kerning, Laufweite und Zeilenabstand.
• Gute Typografie verbessert die Lesbarkeit und vermittelt Stimmung oder Ton in der Gestaltung.

Für Snowflake-Kunden bedeutet lesbare Beweismittel Zeitstempel in einer einheitlichen Zeitbasis, klare Benutzer- und Rollenbezeichnungen, Trennung bestätigter Aktivitäten von Verdachtsmomenten, sichtbarer MFA-Status und direkte Verbindungen zwischen Abfragen, Stages, Übertragungsvolumen und betroffenen Datenspeichern. Ein dichter Export von Protokollen mag vollständig, aber unbrauchbar sein. Ein prägnantes Beweispaket kann den Unterschied zwischen einer schnellen Eindämmungsentscheidung und einer verzögerten Datenschutzanalyse ausmachen.

Was nicht gefolgert werden sollte

Ein zurückhaltender Bericht sollte vier Fehlschlüsse vermeiden. Erstens beweist die Kampagne nicht, dass die Produktionsplattform von Snowflake kompromittiert wurde. Zweitens beweist sie nicht, dass jede benachrichtigte Organisation Daten verloren hat. Drittens beweist sie nicht, dass jeder betroffene Kunde dieselben Felder, Personen oder rechtlichen Pflichten hatte. Viertens beweisen Produktänderungen nach der Kampagne allein noch keine 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 kein Schweigen über die Anbieterpflichten. Ein Anbieter kann von einem Plattformverstoß freigesprochen sein und dennoch für das Standarddesign, die 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 Verfügung kann nicht endgültig sein und dennoch zeigen, dass Standard-MFA und Vorhersehbarkeit geprüft werden. Ausgewogene Verantwortlichkeit hält all diese Aussagen gleichzeitig aufrecht.

Die abschließende Bewertung lautet hohe Auswirkungen und hohes Vertrauen. Die bestätigten Beweise stützen eine Kampagne mit Kunden-Zugangsdaten, nicht einen Plattformverstoß bei Snowflake. Die Beweise zeigen aber auch, warum Anbieterstandards, Telemetrie und kundenübergreifende Sicherheitsautomatisierung Teil der Verantwortlichkeit sind. Geteilte Verantwortung ist nur glaubwürdig, wenn beide Seiten die von ihnen geschlossenen Tore vorweisen können. Nach dieser Kampagne besteht der Test für Snowflake nicht darin, ob man sagen kann, dass MFA existierte.

Es geht darum, ob weniger gestohlene Passwörter zu Sitzungen werden können, weniger Sitzungen umfassende Daten erreichen können und mehr Kunden genau nachweisen können, was geschah, bevor Daten das Unternehmen verlassen.