Śledź „Logi Snowflake” oznaczają jedno z dwóch: dane bezpieczeństwa przechowywane przez Twój zespół w tabelach Snowflake lub własny dziennik audytu Snowflake, czyli widoki SNOWFLAKE.ACCOUNT_USAGE, takie jak LOGIN_HISTORY i QUERY_HISTORY. W przypadku małych ekstrakcji uruchom zapytanie w SnowSQL z wyjściem JSON. Dla większych, wyładuj używając COPY INTO w etapie używając FILE_FORMAT = (TYPE = JSON) i pobierz pliki za pomocą GET.
Własne logi Snowflake przyciągnęły wiele uwagi w 2024 roku, gdy atakujący użyli skradzionych poświadczeń, aby zalogować się do kont klientów, które nie wymagały MFA. Historia logowań i zapytań jest teraz standardowym wymaganiem w dochodzeniach. Prime Core posiada ponad 24,000 unikalnych reguł detekcji, zmapowanych na 676 technik MITRE ATT&CK. Poniżej pokazano, jak wydobyć dane, oczyścić je i za darmo zbadać w LogTotal.
Zanim zaczniesz
Dostęp do ACCOUNT_USAGE. Domyślnie tylko ACCOUNTADMIN może odczytać te widoki. Inne role potrzebują przyznania IMPORTED PRIVILEGES na bazie danych SNOWFLAKE lub jednej z jej ról baz danych.
Opóźnienie i retencja. Widoki ACCOUNT_USAGE przechowują rok historii, ale mogą mieć opóźnienie do kilku godzin. Dla ostatnich siedmiu dni bez opóźnienia funkcja tabeli INFORMATION_SCHEMA.LOGIN_HISTORY jest alternatywą.
Magazyn. Zapytania i załadunki potrzebują działającego magazynu i zużywają kredyty. Filtruj według czasu.
Opcja 1: SnowSQL z wyjściem JSON (małe ekstrakcje)
snowsql -q "SELECT * FROM SNOWFLAKE.ACCOUNT_USAGE.LOGIN_HISTORY
WHERE EVENT_TIMESTAMP >= '2026-10-19' AND EVENT_TIMESTAMP < '2026-10-20'"
-o output_format=json -o friendly=false -o timing=false > sf_logins_1019.json
jq -c '.[]' sf_logins_1019.json > sf_logins_1019.jsonl
Opcja 2: Wyładuj na etapie (większe eksporty)
COPY INTO @~/exports/login_history_1019/
FROM (
SELECT OBJECT_CONSTRUCT(*)
FROM SNOWFLAKE.ACCOUNT_USAGE.LOGIN_HISTORY
WHERE EVENT_TIMESTAMP >= '2026-10-19' AND EVENT_TIMESTAMP < '2026-10-20'
)
FILE_FORMAT = (TYPE = JSON COMPRESSION = NONE)
OVERWRITE = TRUE;
Załadunki JSON potrzebują jednej kolumny, dlatego zapytanie obejmuje każdy wiersz w OBJECT_CONSTRUCT(*). Ta funkcja pomija pola NULL. Następnie pobierz z etapu użytkownika (@~):
GET @~/exports/login_history_1019/ file:///tmp/sf_export/;
i połącz pliki z cat /tmp/sf_export/* > sf_logins_1019.jsonl. Ten sam schemat działa dla własnych tabel bezpieczeństwa. Zamień nazwę tabeli i jej kolumny timestamp.
Na co zwrócić uwagę w historii logowania
Szukaj nieudanych logowań (IS_SUCCESS = 'NO’) w seriach i logowań hasłem bez drugiego czynnika (SECOND_AUTHENTICATION_FACTOR puste). Zawie{r}[big]zaj logowania z nieznanych adresów IP klientów i typów klientów. Następnie śledź sesje w QUERY_HISTORY, aby zobaczyć, co było odczytane.
Wgraj, oczyść i przejrzyj w LogTotal
- Wgraj. Otwórz logtotal.com i wrzuć plik .jsonl.
- Oczyść.
- Przejrzyj.
Gdy coś pójdzie nie tak
| Objaw | Prawdopodobna przyczyna | Fix |
|---|---|---|
| Obiekt nie istnieje lub brak autoryzacji na ACCOUNT_USAGE | Rola nie ma dostępu do bazy danych SNOWFLAKE | Poproś o IMPORTED PRIVILEGES lub rolę bazy danych |
| Dziś brak logowań | Opóźnienie ACCOUNT_USAGE | Użyj funkcji LOGIN_HISTORY w INFORMATION_SCHEMA dla ostatnich zdarzeń |
| Błąd COPY INTO dotyczący kolumn | Załadunek JSON wymaga jednej kolumny | Otaczaj wiersze w OBJECT_CONSTRUCT(*) |
| Brakujące pola w JSON | OBJECT_CONSTRUCT eliminuje wartości NULL | Oczekiwane; brak oznacza NULL |
| GET nie powiodło się | Nie uruchomione z SnowSQL lub CLI Snowflake | GET uruchamiane z klienta, nie z interfejsu webowego |
FAQ
Czy mogę to zrobić w interfejsie sieciowym?
Zapytania, tak. Pobieranie z interfejsu webowego nie jest w formacie JSON. Powyższa ścieżka klienta daje linie JSON.
A co z tabelami wydarzeń Snowflake?
Tabele wydarzeń przechowują logi i ślady z Twoich własnych funkcji i aplikacji. Eksportuj je tak samo jak każdą tabelę.
