Стежити «Журнали Snowflake» означають одне з двох, і експорт працює однаково для обох. Це можуть бути дані безпеки, які ваша команда зберігає в таблицях Snowflake. Або ж це може бути власний журнал аудиту Snowflake, SNOWFLAKE.ACCOUNT_USAGE вигляди, такі як LOGIN_HISTORY і QUERY_HISTORY. Для невеликих вибірок запустіть запит у SnowSQL з виходом у форматі JSON. Для всього більшого розвантажте за допомогою COPY INTO stage, використовуючи FILE_FORMAT = (TYPE = JSON), і завантажте файли за допомогою GET.
Власні журнали Snowflake привернули багато уваги у 2024 році, коли зловмисники використали вкрадені облікові дані, щоб увійти в облікові записи клієнтів, які не використовували MFA. Історія входу та запитів тепер є стандартними запитами під час розслідування. Prime Core має понад 24,000 унікальних правил виявлення, відображених для 676 технік MITRE ATT&CK. Нижче показано, як отримати дані, очистити їх і безкоштовно дослідити їх у LogTotal.
Перед тим, як почати
Доступ до ACCOUNT_USAGE. За замовчуванням, лише ACCOUNTADMIN може читати ці вигляди. Інші ролі потребують надання IMPORTED PRIVILEGES для бази даних SNOWFLAKE або однієї з її ролей.
Затримка та збереження. Вигляди ACCOUNT_USAGE зберігають історію за рік, але відстають на кілька годин. За останні сім днів без затримки функція таблиці INFORMATION_SCHEMA.LOGIN_HISTORY є альтернативою.
Склад. Запити та розвантаження вимагають працюючого складу, і вони споживають кредити. Фільтруйте за часом.
Варіант 1: SnowSQL з виходом у форматі JSON (невеликі вибірки)
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
Варіант 2: Вивантаження на stage (більші експорти)
COPY INTO @~/exports/login_history_1019/
З (
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;
JSON розвантаження потребує одного стовпця, тому запит обгортає кожен рядок у OBJECT_CONSTRUCT(*). Ця функція виключає NULL поля. Потім завантажте зі stage користувача (@~):
GET @~/exports/login_history_1019/ file:///tmp/sf_export/;
та об’єднайте файли з cat /tmp/sf_export/* > sf_logins_1019.jsonl. Такий самий шаблон працює для ваших власних таблиць безпеки. Замініть ім’я таблиці та її стовпець з позначками часу.
На що звертати увагу в історії входу
Зверніть увагу на невдалі входи (IS_SUCCESS = ‘NO’) у вибухах та входи з паролем без другого фактора (SECOND_AUTHENTICATION_FACTOR порожній). Відзначте входи з клієнтських IP та типів клієнтів, яких ви не впізнаєте. Потім відстежте ті сесії до QUERY_HISTORY, щоб побачити, що було прочитано.
Завантажте, очистіть та перегляньте в LogTotal
- Завантажити. Відкрити logtotal.com і перенесіть файл .jsonl.
- Очистити.
- Переглянути.
Коли щось йде не так
| Симптом | Ймовірна причина | Fix |
|---|---|---|
| Об’єкт не існує або не авторизований на ACCOUNT_USAGE | Роль не має доступу до бази даних SNOWFLAKE | Запитайте про IMPORTED PRIVILEGES або роль бази даних |
| Сьогоднішні входи відсутні | Затримка ACCOUNT_USAGE | Використайте INFORMATION_SCHEMA.LOGIN_HISTORY для останніх подій |
| Помилка COPY INTO щодо стовпців | JSON розвантаження потребує одного стовпця | Обгортайте ряди у OBJECT_CONSTRUCT(*) |
| Поля відсутні у JSON | OBJECT_CONSTRUCT виключає NULL значення | Очікується; відсутність означає NULL |
| GET не вдається | Не запущено з SnowSQL або SNOWFLAKE CLI | GET запускається з клієнта, а не з веб-інтерфейсу |
FAQ
Чи можу я зробити це у веб-інтерфейсі?
Запит, так. Завантаження з веб-інтерфейсу не є JSON. Наведений вище шлях клієнта дає вам строку JSON.
Як щодо таблиць подій Snowflake?
Таблиці подій зберігають журнали та треки з ваших власних функцій і додатків. Експортуйте їх так само, як будь-яку таблицю.
