Конър Мучка не е експлоатирал уязвимост в 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 открива всеки агент, картографира рисковия достъп и автоматично прилага политики, базирани на намеренията. Мащабирайте безопасно изкуствения интелект (AI), без да губите контрол или да забавяте иновациите, като започнете от идентичността.

Стъпка 1: Създайте инвентара сега, а не през октомври

Трябва да се отговори на три въпроса за всеки сервизен акаунт в платформата:

  • Кои от тях се автентикират в Snowflake?
  • Какво ще се счупи, когато паролата спре да работи?
  • Кой притежава акаунта?

Snowflake отговаря сам на първия въпрос. Схемата ACCOUNT_USAGE съхранява списъка с потребители за типа на всеки акаунт, а историята на влизанията записва клиента и изходния IP адрес за всеки опит за автентикация в продължение на 365 дни.

Заедно те ви дават набора от акаунти, които все още влизат с парола, кога последно са го направили и откъде.

Вторият и третият въпрос са по-сложни. Snowflake не може да ви каже кой е поискал сервизен акаунт, коя система зависи от него или на кого да се обадите, когато спре да работи. Тази информация живее в паметта на този, който го е настроил, в тикет от 2022 г. или (вероятно) никъде.

Инвентаризация, сглобена през октомври само защото крайният срок я е наложил, не е управление. Тя улавя един единствен момент и започва да остарява в момента, в който някой създаде нов акаунт.

Стъпка 2: Прикачете именуван собственик към всеки акаунт

Записът за собственост е това, което предпазва следващия сервизен акаунт от това да остане непроверен в продължение на години. Собствеността обаче не може да бъде просто ред в електронна таблица.

Кой приема предупреждението, когато автентикацията на този акаунт се провали в 2 часа сутринта? Ако отговорът е „никой“, акаунтът няма собственик и въпросът вече не е как да бъде мигриран, а дали изобщо трябва да съществува.

Собствеността означава отговорност за извеждане от експлоатация толкова, колкото и за времето на работа.

Там, където собствеността остава неясна, използвайте контролиран прозорец на деактивиране преди изтриване.

Следете за грешки, възстановете акаунта, ако е необходимо, и го изведете от експлоатация едва след валидиране на неговите зависимости.

Стъпка 3: Изберете метод за всеки акаунт, а не един общ за цялата инфраструктура

Snowflake предоставя на потребителите от тип SERVICE четири начина за автентикация без парола, всеки с различни оперативни разходи.

  • OAuth / Федерирана идентичност: Препоръчителната опция на Snowflake. Без тайни, така че няма какво да се съхранява или ротира. Изисква работното натоварване да се изпълнява някъде, където може да представи федеративна идентичност.
  • Външен OAuth: Сигурен метод, който изисква опит за конфигуриране на външен доставчик на идентичност (IdP) като сървър за оторизация.
  • Ключове за достъп (KeyPair): Автентикация без парола при заявката, но все пак е дълготрайна тайна и единственият метод без вградени предпазни ограничения. Snowflake препоръчва мрежови политики и стратегия за ротация, но не изисква нито едно от двете и няма принудително изтичане на валидността, както е при токените.
  • Ключове за достъп с принудителни правила: Най-директният заместител на паролата. За потребители от тип SERVICE Snowflake изисква мрежова политика и ограничение на ролите по подразбиране, въпреки че политиките за автентикация могат да смекчат и двете. Ротацията не проверява повторно тези предпоставки при извършването си.