Wprowadzenie do problemu / definicja
Snowflake przyspiesza odchodzenie od haseł w przypadku kont serwisowych, czyli tożsamości używanych przez aplikacje, integracje, zadania automatyczne, potoki danych i skrypty, a nie bezpośrednio przez pracowników. Z perspektywy bezpieczeństwa to istotna zmiana, ponieważ takie konta bardzo często działają latami bez pełnej kontroli właścicielskiej, regularnej rotacji sekretów i skutecznych ograniczeń dostępu.
Problem nie sprowadza się jednak wyłącznie do samej metody logowania. W wielu organizacjach przez lata narastał tak zwany dług tożsamości: nieudokumentowane zależności, nadmiarowe uprawnienia, brak jednoznacznego właściciela oraz słaba widoczność tego, gdzie i w jaki sposób konto techniczne jest faktycznie wykorzystywane.
W skrócie
Snowflake kończy obsługę haseł dla starszych kont serwisowych i przenosi je do modelu SERVICE, który nie przechowuje hasła. To element szerszej zmiany bezpieczeństwa wdrażanej etapami w latach 2025–2026.
- Zmiana ma ograniczyć ryzyko przejęcia kont przez skradzione poświadczenia.
- Największym wyzwaniem nie będzie sama migracja techniczna, lecz identyfikacja zależności i właścicieli kont.
- Organizacje muszą przejrzeć role, źródła logowań i metody uwierzytelniania kont nieosobowych.
- Prosta zamiana hasła na inny sekret nie rozwiązuje problemu nadmiarowych uprawnień i słabej kontroli dostępu.
Kontekst / historia
Zmiana polityki Snowflake wpisuje się w szerszy kontekst incydentów związanych z przejętymi poświadczeniami. W 2024 roku szeroko opisywano działania grupy UNC5537, która uzyskiwała dostęp do środowisk klientów Snowflake przy użyciu wcześniej skradzionych danych uwierzytelniających. Według ustaleń nie chodziło o wykorzystanie luki w samej platformie, lecz o użycie prawidłowych loginów i haseł, często pozyskanych wcześniej przez malware typu infostealer.
Śledztwa pokazały, że część wykorzystywanych poświadczeń była ujawniona znacznie wcześniej, a ich ekspozycja mogła sięgać kilku lat wstecz. To unaoczniło skalę problemu z długo żyjącymi kontami technicznymi, które pozostawały aktywne mimo braku rotacji, ograniczeń sieciowych czy nowocześniejszych metod uwierzytelniania. W efekcie konta serwisowe przestały być postrzegane jako detal administracyjny, a zaczęły być traktowane jako pełnoprawny obszar ryzyka cyberbezpieczeństwa.
Analiza techniczna
Z technicznego punktu widzenia Snowflake eliminuje model LEGACY_SERVICE i przenosi konta do typu SERVICE, który nie pozwala na logowanie przy użyciu hasła. Sama zmiana nie oznacza jednak automatycznej poprawy bezpieczeństwa, jeśli zostanie przeprowadzona bez analizy sposobu użycia tych kont.
Konto serwisowe zwykle stanowi część większego łańcucha zależności. Może być używane przez proces ETL, narzędzie BI, harmonogram zadań, aplikację pośredniczącą, pipeline CI/CD albo skrypt uruchamiany okazjonalnie. Wyłączenie hasła bez wcześniejszego wykrycia tych powiązań może spowodować przerwy operacyjne, natomiast zachowanie starych wzorców dostępu pod nową metodą logowania utrwali wcześniejsze słabości.
W miejsce haseł Snowflake dopuszcza kilka alternatywnych mechanizmów uwierzytelniania. Najbardziej dojrzałym wzorcem jest federacja tożsamości obciążeń, w której proces uwierzytelnia się bezsekretowo na podstawie zaufanej tożsamości platformowej. Stosowane są również external OAuth, pary kluczy oraz tokeny dostępu programistycznego. Każda z tych metod ma odmienny profil ryzyka: federacja ogranicza problem przechowywania sekretów, natomiast klucze prywatne i tokeny nadal wymagają bezpiecznej dystrybucji, rotacji i ścisłego ograniczania uprawnień.
Istotną rolę odgrywa także telemetria. Historia logowań i dane o klientach inicjujących sesje pozwalają ustalić, które konta nadal próbują korzystać z wycofywanych metod uwierzytelniania, z jakich adresów IP pochodzą połączenia oraz jakie systemy zależą od danego konta. To ważne narzędzie planowania migracji, choć samo w sobie nie rozwiązuje problemu odpowiedzialności biznesowej za konto.
Konsekwencje / ryzyko
Najpoważniejszym ryzykiem jest potraktowanie całej zmiany jako formalnego zadania zgodności, a nie projektu porządkującego bezpieczeństwo tożsamości. W takim scenariuszu organizacja zastąpi hasło innym sekretem, ale nie ograniczy ról, nie wskaże właściciela i nie usunie zbędnych miejsc użycia konta. Efekt będzie jedynie pozorną poprawą bezpieczeństwa.
Drugie zagrożenie to przerwy w działaniu usług. Starsze integracje często mają słabą dokumentację, a wiedza o ich zależnościach bywa rozproszona pomiędzy administratorów, integratorów i dostawców zewnętrznych. Wyłączenie hasła bez testów może zatrzymać procesy raportowe, synchronizację danych lub automatyzację operacyjną.
Trzecie ryzyko wiąże się z pozostawieniem śladów starego sekretu poza samą platformą. Nawet jeśli konto przestaje akceptować hasło, jego wcześniejsza wartość może nadal istnieć w repozytoriach kodu, systemach CI/CD, magazynach sekretów, dokumentacji operacyjnej czy lokalnych skryptach administracyjnych. Jeśli było współdzielone z innymi systemami, konsekwencje mogą wyjść daleko poza środowisko Snowflake.
Nie można też pominąć ryzyka związanego z nadmiernymi uprawnieniami. Konto techniczne z szerokimi rolami, bez restrykcji sieciowych i z długo żyjącymi poświadczeniami pozostaje bardzo atrakcyjnym celem dla grup nastawionych na kradzież danych i wymuszenia.
Rekomendacje
Organizacje powinny rozpocząć od pełnej inwentaryzacji kont nieosobowych. Dla każdego konta należy ustalić właściciela technicznego i biznesowego, systemy zależne, aktualną metodę uwierzytelniania, zakres ról oraz typowe źródła logowania. Konto bez przypisanego właściciela powinno zostać uznane za podwyższone ryzyko.
Kolejnym krokiem powinna być klasyfikacja kont według krytyczności i sposobu wykorzystania. Tam, gdzie to możliwe, warto wdrażać federację tożsamości obciążeń i rezygnować ze statycznych sekretów. Jeśli konieczne jest użycie kluczy lub tokenów, należy wymusić krótkie okresy ważności, bezpieczne przechowywanie, regularną rotację i powiązanie z politykami sieciowymi.
Migracja jest również dobrym momentem na przegląd uprawnień zgodnie z zasadą najmniejszych przywilejów. Nie należy przenosić nadmiarowych grantów do nowego modelu uwierzytelniania. Warto oddzielić funkcje administracyjne od operacyjnych i usunąć role, które nie są już potrzebne.
W praktyce sprawdza się także kontrolowane wyłączanie kont w zaplanowanych oknach testowych. Krótkie odcięcie pozwala ujawnić ukryte zależności i ocenić, czy konto jest nadal wymagane przez jakikolwiek proces. Jeśli nie pojawiają się błędy, konto może zostać zakwalifikowane do dekomisji.
Równolegle należy potraktować zastępowane hasło jako potencjalnie skompromitowane. Oznacza to konieczność wyszukania jego kopii w skryptach, pipeline’ach, repozytoriach kodu, runbookach i dokumentacji. Sama zmiana metody logowania nie usuwa skutków wcześniejszego wycieku poświadczeń.
- Wykonaj pełną inwentaryzację kont serwisowych.
- Przypisz właściciela technicznego i biznesowego do każdego konta.
- Wdróż zasadę najmniejszych uprawnień.
- Preferuj federację tożsamości obciążeń zamiast statycznych sekretów.
- Monitoruj historię logowań, adresy źródłowe i próby użycia starych metod logowania.
- Usuń pozostałości starych haseł z kodu, narzędzi i dokumentacji.
Podsumowanie
Wyłączenie haseł dla kont serwisowych w Snowflake to ważny krok w stronę ograniczenia ryzyka wynikającego ze skradzionych poświadczeń, ale nie jest to rozwiązanie kompletne samo w sobie. Najtrudniejszy etap dopiero się zaczyna i obejmuje identyfikację właścicieli, odkrycie zależności, redukcję uprawnień oraz wdrożenie dojrzałego modelu zarządzania tożsamościami nieosobowymi.
Firmy, które wykorzystają tę zmianę do uporządkowania całego cyklu życia kont technicznych, realnie poprawią poziom bezpieczeństwa. Te, które ograniczą się do prostego zastąpienia hasła innym sekretem, zachowają większość wcześniejszych słabości.
Źródła
- Snowflake ends service-account passwords. Now comes the hard part — https://www.bleepingcomputer.com/news/security/snowflake-ends-service-account-passwords-now-comes-the-hard-part/
- UNC5537 Targets Snowflake Customer Instances for Data Theft and Extortion — https://cloud.google.com/blog/topics/threat-intelligence/unc5537-snowflake-data-theft-extortion