Коннор Моука не скористався вразливістю в Snowflake. Він та його спільники використали справжні облікові дані клієнтів, багато з яких були давніми, для входу, охопивши понад 165 організацій-клієнтів Snowflake.
Вони викрали мільярди записів, включно з даними дзвінків та текстових повідомлень майже всіх бездротових клієнтів AT&T. Моука визнав себе винним 5 серпня у комп’ютерному шахрайстві, шахрайстві з використанням електронних засобів, крадіжці особистих даних при обтяжуючих обставинах та змові.
Кампанія виявила знайому проблему з ідентифікацією: облікові дані залишалися дійсними ще довго після їх компрометації, у постраждалих акаунтах був відсутній другий фактор автентифікації, а мережеві обмеження часто не застосовувалися.
Snowflake змушує клієнтів розв’язувати цю проблему з ідентифікацією, зосереджуючись на нелюдських ідентичностях.
Під час Фази 3 впровадження автентифікації Snowflake мігрує старих користувачів служб до типу SERVICE, який блокуватиме автентифікацію на основі пароля. Заміна цих паролів — це механічна частина.
Виявлення призначення кожного акаунта, призначення відповідального та визначення, скільки доступу йому все ще потрібно, — ось справжній виклик.
Акаунти, що досі мають пароль
Незабаром автентифікація за допомогою пароля буде заборонена для всіх службових акаунтів. Тип користувача LEGACY_SERVICE буде повністю вилучено, а наявні старі акаунти мігруються до типу SERVICE, який не може зберігати пароль.
Snowflake проводить цей процес у три фази, і перші дві вже закрили більшість шляхів:
- Вересень 2025 – січень 2026: Людські користувачі мали надавати другий фактор у Snowsight. Службові користувачі не були зачеплені.
- Травень 2026 – липень 2026: Кожен новостворений нелюдський користувач мав бути типу SERVICE, який не може використовувати пароль.
- Серпень 2026 – жовтень 2026: Старі службові акаунти в підключених облікових записах Snowflake повинні відмовитися від автентифікації за паролем до дати примусового виконання Фази 3 для їхнього облікового запису.
Залишилися найстаріші акаунти. Вони мали більше часу для витоку облікових даних та їх невідповідної ротації, для зміни команд відповідальними особами та для втрати документації залежностей.
Не дозволяйте хаотичним агентам зіпсувати вам день
Ідентифікація — це ключ до безпечного захисту агентів з самого початку.
Token Security виявляє кожного агента, відображає ризикований доступ та автоматично застосовує політики на основі намірів. Масштабуйте ШІ безпечно, не втрачаючи контроль і не сповільнюючи інновації, починаючи з ідентифікації.
Переконайтесь самі.
Крок 1: Створіть інвентаризацію зараз, а не в жовтні
Для кожного службового акаунта на платформі слід відповісти на три запитання:
- Які з них автентифікуються до Snowflake?
- Хто є власником кожного з них?
- Що зламається, коли пароль перестане працювати?
Snowflake сам відповідає на перше запитання. Схема ACCOUNT_USAGE зберігає список користувачів для кожного типу акаунта, а історія входів записує клієнта та вихідну IP-адресу для кожної спроби автентифікації протягом 365 днів.
Разом вони надають набір акаунтів, які все ще входять з паролем, коли кожен останній раз це робив і звідки.
Друге та третє запитання складніші. Snowflake не може сказати вам, хто запитував службовий акаунт, яка система від нього залежить або кого викликати, коли він перестане працювати. Ця інформація зберігається в пам’яті того, хто її налаштував, у квитку 2022 року або (ймовірно) ніде.
Інвентаризація, зібрана в жовтні через наявність терміну, не є управлінням. Вона фіксує один момент часу і починає втрачати актуальність наступного разу, коли хтось створює новий акаунт.
Крок 2: Призначте відповідального власника для кожного акаунта
Запис про власника — це те, що запобігає тому, щоб наступний службовий акаунт залишався без перевірки роками. Однак, володіння не може бути просто рядком у таблиці.
Хто приймає сповіщення, коли автентифікація цього акаунта збійне о 2 годині ночі? Якщо відповідь — “ніхто”, акаунт не має власника, і питання вже не в тому, як його мігрувати, а в тому, чи він взагалі має існувати.
Володіння означає відповідальність за деактивацію так само, як і за час роботи.
Там, де володіння залишається неясним, використовуйте контрольоване вікно вимкнення перед видаленням.
Моніторте збої, відновіть акаунт за потреби та виведіть його з експлуатації лише після перевірки залежностей.
Крок 3: Оберіть метод для кожного акаунта, а не один для всієї системи
Snowflake надає користувачам SERVICE чотири способи автентифікації без пароля, кожен з яких має різні експлуатаційні витрати.
| Метод | Що це коштує |
| Federation identity workload | Рекомендований варіант Snowflake. Не потребує секретів, тому зберігати чи обертати нічого. Вимагає, щоб робоче навантаження виконувалося там, де може бути представлено ідентифікатор, що підлягає федерації. |
| External OAuth | Надійний, потребує досвіду для налаштування стороннього IdP як сервера авторизації. |
| Key-pair authentication | Без пароля на запит, але все ще довгостроковий секрет, і єдиний метод без жодних обмежень. Snowflake рекомендує мережеві політики та стратегію обертання, але не вимагає жодного з них, і немає примусового терміну дії, як це буває з токенами. |
| Programmatic access tokens | Найпряміша заміна пароля. Для користувачів SERVICE Snowflake за замовчуванням вимагає мережеву політику та обмеження ролей, хоча політики автентифікації можуть послабити обидва. Обертання не перевіряє ці передумови під час обертання, тому команди повинні перевіряти мережеву політику, надану роль, термін дії та власника під час кожного обертання. |
Не намагайтеся обмежуватися одним методом.
Федерація — це правильний вибір за замовчуванням, коли робоче навантаження виконується на платформі, яка може представити ідентифікатор Snowflake.
Автентифікація за допомогою пари ключів або токен, обмежений роллю, є запасним варіантом, коли її неможливо використовувати, з мережевою політикою та графіком обертання, узгодженими в рамках однієї зміни, а не як наступний крок.
Довгостроковий секрет, мігрований без будь-якого з цих методів, пройде термін Фази 3 без заперечень, але це та ж проблема контролю в новому форматі.
Крок 4: Розглядайте замінений пароль як скомпрометований
Припустіть, що облікові дані, які ви замінюєте, вже знаходяться в журналі інфостилера.
Mandiant та Snowflake виявили, що щонайменше 79,7% акаунтів, використаних у кампанії UNC5537, мали попереднє розкриття облікових даних.
Найдавніша інфекція інфостилером, пов’язана з цими обліковими даними, датувалася листопадом 2020 року, що означає, що цей пароль все ще працював приблизно через три з половиною роки після його викрадення.
Переключення робить пароль недійсним у Snowflake, але не видаляє скопійовані або повторно використані облікові дані з магазинів секретів, змінних CI, посібників або кінцевих точок.
Шукайте повторне використання, відкличте будь-які залежні облікові дані та зменште область дії ролі акаунта під час тієї ж зміни.
AI-агенти стискають ту саму проблему життєвого циклу ідентичності
Термін виконання Snowflake — це прев’ю проблеми управління, яку AI-агенти значно посилять. Snowflake вже визнає автоматизованих AI-агентів як окремий тип ідентичності SERVICE_AGENT.
Мітка нова, але питання контролю знайомі: хто володіє агентом? Яку ідентичність він використовує? Що йому дозволено робити? Коли цей доступ має закінчитися?
Замовте технічну демонстрацію, щоб побачити, як Token Security може ідентифікувати власників без ідентичностей, відобразити приховані залежності та встановити контроль над життєвим циклом до того, як наступний термін виконання платформи змусить вирішувати цю проблему.
Спонсоровано та написано Token Security.
Оригінал статті: www.bleepingcomputer.com