Snowflake als Einfallstor: Wie gestohlene Zugangsdaten bei Kunden zu Massendatenabflüssen führten – und warum „die Cloud war nicht gehackt“ die falsche Lehre ist
Einstieg: Wenn ein Plattformname zur Schlagzeile wird – obwohl er nicht der eigentliche Täter ist
„Snowflake gehackt“ war die verkürzte Überschrift, die sich in vielen Köpfen festsetzte. Technisch ist sie falsch – und inhaltlich trotzdem gefährlich nahe an der Wahrheit. Denn der Vorfall rund um Snowflake-Kundenkonten zeigt eine der unangenehmsten Realitäten moderner IT-Sicherheit: Ein Anbieter kann formal korrekt funktionieren, während seine Kunden reihenweise kompromittiert werden. Der Schaden entsteht nicht durch einen Plattform-Exploit, sondern durch Identitätsversagen an der Kundenschnittstelle – skaliert über eine hochvernetzte Datenplattform.
Was folgte, war kein einzelner Datenabfluss, sondern eine Serie: Ticketing-, Finanz- und Marketingunternehmen meldeten massive Exfiltrationen. Der gemeinsame Nenner war nicht Malware, nicht Zero-Day, nicht Supply-Chain-Code – sondern fehlende MFA, wiederverwendete Zugangsdaten und unzureichendes Monitoring auf Snowflake-Accounts.
Dieser Artikel ist wichtig, weil er eine unbequeme Lektion transportiert: Cloud-Sicherheit scheitert heute selten an Kryptografie – sondern an Identitäten.
Was passiert ist – die Ereigniskette ohne Verkürzungen
Der Kernvorfall
Angreifer verschafften sich Zugang zu Snowflake-Kundenkonten, indem sie gestohlene Zugangsdaten nutzten. Diese Credentials stammten nach übereinstimmenden Berichten aus Infostealer-Malware-Kampagnen, die zuvor Endgeräte kompromittiert hatten. Entscheidend: In mehreren betroffenen Snowflake-Accounts war keine Multi-Faktor-Authentifizierung aktiviert.
Mit gültigen Benutzername/Passwort-Kombinationen meldeten sich Angreifer regulär an – ohne Exploit, ohne Alarm, ohne Brute-Force-Spuren. Von dort aus wurden große Datenmengen abgefragt und exfiltriert.
Die Wirkung
Mehrere prominente Unternehmen meldeten anschließend Datenabflüsse, darunter Organisationen mit Millionen bis Hunderten Millionen Datensätzen. Öffentlich diskutiert wurden u. a.:
- Kundendaten aus Ticketing- und Entertainment-Kontexten
- Marketing- und Profildaten
- Metadaten mit hoher Re-Identifizierbarkeit
Snowflake selbst stellte klar, dass keine Schwachstelle in der Plattform ausgenutzt wurde. Das ist technisch korrekt – aber operativ unvollständig.
Warum „Snowflake war nicht gehackt“ die falsche Schlussfolgerung ist
Plattform-Sicherheit vs. Nutzungssicherheit
Cloud-Plattformen wie Snowflake sind hochgradig abgesichert. Genau deshalb verlagert sich der Angriffspunkt:
- weg von Servern
- weg von Hypervisoren
- weg von Speicher
hin zu Identitäten, Konfigurationen und Betriebsmodellen der Kunden.
In diesem Fall war der Single Point of Failure das Kundenkonto – und zwar nicht abstrakt, sondern ganz konkret: ein Benutzer ohne MFA, mit einem Passwort, das bereits anderswo kompromittiert war.
Identität ist die neue Perimeter-Grenze
In klassischen Rechenzentren bedeutete „Perimeter“ Firewall, VPN, Segmentierung. In Cloud-Datenplattformen ist der Perimeter:
- der Login
- die Rolle
- die Query-Berechtigung
Wenn ein Angreifer dort „legitim“ erscheint, greift fast kein klassischer Schutzmechanismus.
Credential Stuffing und Infostealer: Altbekannt, aber immer noch unterschätzt
Woher die Zugangsdaten kamen
Die Angreifer nutzten nach Angaben von Sicherheitsfirmen Infostealer-Malware, die auf Endgeräten Zugangsdaten aus Browsern, Passwortmanagern und Konfigurationsdateien extrahiert. Diese Datensätze werden:
- automatisiert gesammelt
- in Untergrundforen verkauft
- für gezielte Zugriffe auf Cloud-Dienste genutzt
Das ist kein neues Phänomen. Neu ist nur, wie gut es skaliert, wenn ein einzelnes Konto Zugriff auf zentrale Datenplattformen hat.
Warum Passwörter allein nicht mehr tragfähig sind
Passwörter verlieren ihren Schutzwert, sobald sie:
- wiederverwendet werden
- auf Endgeräten ohne starke Isolation gespeichert sind
- nicht durch MFA abgesichert werden
Im Snowflake-Kontext bedeutete das: Ein einziges kompromittiertes Entwickler- oder Analystenkonto konnte – abhängig von Rollen – große Teile eines Data Warehouses lesend zugänglich machen.
Der stille Verstärker: Rollen, Berechtigungen und „bequeme Defaults“
Überprivilegierung als Normalzustand
In vielen Datenplattformen ist es Alltag, dass:
- Analyse-Accounts breite Leserechte haben
- Service-Accounts lange bestehen bleiben
- Rollen historisch gewachsen und selten ausgemistet werden
Das Ergebnis: Ein erfolgreicher Login liefert mehr Daten als nötig – und damit einen höheren Schaden pro Incident.
Query ist Exfiltration
Ein besonders tückischer Aspekt: In Snowflake ist eine Datenabfrage kein „auffälliger“ Akt. Große SELECTs sehen aus wie normale Analytics-Jobs. Ohne gezieltes Monitoring gilt:
- Hohe Datenmengen = Business as usual
- Lange Query-Laufzeiten = normal
- Exporte = legitim
Genau hier konnten Angreifer unauffällig arbeiten.
Warum dieser Vorfall ein Branchenproblem ist – nicht nur ein Snowflake-Thema
Jede moderne Datenplattform teilt dieses Risiko
Ob Snowflake, BigQuery, Redshift oder Synapse: Das Muster ist übertragbar. Überall gilt:
- Identitäten steuern Zugriff
- Abfragen sind Kernfunktion
- Daten liegen zentral
Damit wird jede Plattform zum High-Value-Ziel, sobald ein einzelnes Konto kompromittiert ist.
„Wir hatten MFA optional“ ist kein tragfähiger Zustand mehr
Optionales MFA ist faktisch kein MFA. Der Snowflake-Vorfall zeigt, dass optionale Sicherheit in der Praxis bedeutet: Die kritischsten Konten haben sie nicht aktiviert.
Was Unternehmen konkret hätten tun können – und jetzt tun müssen
Technische Mindestmaßnahmen
MFA erzwingen – ohne Ausnahmen
- für alle Benutzer
- für Service-Accounts über Workload-Identitäten
- auch für temporäre Zugriffe
Credential Hygiene
- Passwörter nicht wiederverwenden
- regelmäßige Rotation
- kompromittierte Credentials aktiv jagen (Threat Intel, Leaked Credential Monitoring)
Rollen radikal entschlacken
- Least Privilege wirklich umsetzen
- Lesezugriffe begrenzen
- Trennung von Entwicklungs-, Analyse- und Produktionsrollen
Monitoring, das diesen Namen verdient
- Alarme bei ungewöhnlichen Query-Volumina
- Alerts bei Massen-SELECTs außerhalb normaler Zeitfenster
- Geo-Anomalien bei Logins
- Korrelation von Login → Query → Export
Organisatorische Konsequenz
- Cloud-Security nicht an den Anbieter delegieren
- Identitäten als kritische Assets behandeln
- Incident-Playbooks für „legitime Logins mit illegitimer Absicht“
