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