Конор Моука не скористався вразливістю в 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 чотири способи автентифікації без пароля, кожен з різними операційними витратами.
|
Метод |
Вартість |
|
Федерація робочих навантажень (Workload identity federation) |
Рекомендований варіант Snowflake. Без секретів, тому немає нічого для зберігання чи ротації. Вимагає, щоб робоче навантаження виконувалося там, де може бути надано ідентифікатор для федерації. |
|
Зовнішній OAuth (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.
- Кібербезпека
- Викрадення даних
- SaaS
- Сервісний обліковий запис
- Snowflake
- Token Security
За матеріалами: www.bleepingcomputer.com