Snowflake führt die Abkündigung in drei Phasen durch; die ersten beiden haben die meisten Türen bereits geschlossen. Übrig bleiben die ältesten Konten — jene, bei denen Zugangsdaten am längsten Zeit hatten zu lecken und unrotiert zu bleiben, bei denen Verantwortliche das Team gewechselt haben und Abhängigkeiten ihre Dokumentation verloren haben.
Für jedes Dienstkonto sind drei Fragen zu klären. Die erste beantwortet Snowflake selbst: Das Schema ACCOUNT_USAGE führt die Benutzerliste je Kontotyp, und die Anmeldehistorie hält Client und Quell-IP jedes Authentifizierungsversuchs 365 Tage lang fest. Damit lässt sich ermitteln, welche Konten sich noch mit Passwort anmelden, wann zuletzt und von wo.
Die beiden anderen Fragen sind schwieriger. Snowflake kann nicht sagen, wer ein Dienstkonto angefordert hat, welches System davon abhängt und wen man anruft, wenn es ausfällt. Diese Information steckt im Gedächtnis derjenigen, die es eingerichtet haben, in einem Ticket von 2022 — oder nirgendwo.
Eine Inventarliste, die nur entsteht, weil eine Frist drängt, ist keine Governance: Sie erfasst einen einzigen Moment und beginnt zu verfallen, sobald das nächste Konto angelegt wird. Entscheidend ist ein belastbarer Eigentümereintrag, und zwar mehr als eine Zeile in einer Tabelle. Die Prüffrage lautet: Wer nimmt den Alarm an, wenn die Authentifizierung dieses Kontos um zwei Uhr nachts fehlschlägt? Lautet die Antwort „niemand“, hat das Konto keinen Eigentümer — dann geht es nicht mehr um die Migration, sondern um die Frage, ob es überhaupt existieren soll. Verantwortung heißt dabei Deprovisionierung genauso wie Verfügbarkeit. Wo die Zuordnung unklar bleibt, empfiehlt sich ein kontrolliertes Deaktivierungsfenster vor der Löschung: Fehler beobachten, das Konto notfalls wiederherstellen und erst nach Prüfung der Abhängigkeiten abschalten.
SERVICE-Benutzern stehen vier passwortlose Verfahren offen, mit unterschiedlichen Betriebskosten. Workload Identity Federation ist Snowflakes empfohlene Option: geheimnisfrei, es gibt nichts zu speichern oder zu rotieren — verlangt aber, dass die Workload dort läuft, wo sie eine föderierbare Identität vorweisen kann. External OAuth ist stark, erfordert jedoch das Know-how, einen fremden Identitätsanbieter als Autorisierungsserver zu konfigurieren. Key-Pair-Authentifizierung ist beim Zugriff passwortlos, bleibt aber ein langlebiges Geheimnis und ist das einzige Verfahren ohne mitgelieferte Schutzmechanismen: Snowflake empfiehlt Netzwerkrichtlinien und eine Rotationsstrategie, verlangt aber keines von beidem, und einen erzwungenen Verfall wie bei Tokens gibt es nicht. Programmatische Zugriffstokens sind der direkteste Passwortersatz; für SERVICE-Benutzer fordert Snowflake standardmäßig eine Netzwerkrichtlinie und eine Rollenbeschränkung, die sich über Authentifizierungsrichtlinien allerdings aufweichen lassen. Bei der Rotation werden diese Voraussetzungen nicht erneut geprüft — Netzwerkrichtlinie, Rollenzuweisung, Ablaufdatum und Eigentümer sollten daher bei jeder Rotation validiert werden.
Ein einziges Verfahren für alles zu wählen, ist nicht sinnvoll. Föderation ist der richtige Standard, wo die Plattform eine Identität gegenüber Snowflake vorweisen kann; Key-Pair oder ein rollenbeschränktes Token sind der Rückfall — mit Netzwerkrichtlinie und Rotationsplan in derselben Änderung statt als Folgeaufgabe. Ein langlebiges Geheimnis ohne beides übersteht die Frist von Phase 3 anstandslos, ist aber dasselbe Kontrollversagen in neuem Format.
Die Grundannahme sollte lauten: Das ersetzte Zugangsdatum liegt bereits in einem Infostealer-Log. Mandiant und Snowflake stellten fest, dass mindestens 79,7 Prozent der in der UNC5537-Kampagne genutzten Konten zuvor offengelegte Zugangsdaten hatten. Die früheste zugehörige Infostealer-Infektion datiert auf November 2020 — jenes Passwort funktionierte also noch rund dreieinhalb Jahre nach dem Diebstahl. Die Umstellung entwertet das Passwort in Snowflake, entfernt aber keine Kopien aus Secret-Stores, CI-Variablen, Runbooks oder Endgeräten. Wiederverwendung suchen, abhängige Zugangsdaten widerrufen und den Rollenumfang des Kontos in derselben Änderung reduzieren.
Snowflake führt bereits einen eigenen Identitätstyp SERVICE_AGENT für automatisierte KI-Agenten. Das Etikett ist neu, die Kontrollfragen sind alt: Wer verantwortet den Agenten, welche Identität nutzt er, worauf darf er zugreifen und wann endet dieser Zugriff?
Der Beitrag wurde von Token Security verfasst und gesponsert; Autor ist Mitgründer und CTO Ido Shlomo.