После атаки, затронувшей более 165 клиентских организаций, Snowflake окончательно взялась за старую проблему: сервисные аккаунты Snowflake больше не смогут жить на паролях. Для компаний это не просто еще одна миграция в IAM, а неприятная инвентаризация всего, что годами работало «как-то само» и внезапно оказалось критичным для аналитики, интеграций и внутренних пайплайнов.
Как пишет BleepingComputer, повод более чем предметный. Канадец Коннор Мука и его сообщники не взламывали уязвимость в Snowflake, а заходили в клиентские окружения по валидным учетным данным, часть которых утекла за годы до инцидента. Результат оказался показателен: доступ получили к более чем 165 организациям, были похищены миллиарды записей, включая данные о звонках и сообщениях почти всех беспроводных абонентов AT&T. 5 августа 2026 года Мука признал вину по обвинениям в компьютерном мошенничестве, wire fraud, краже личности при отягчающих обстоятельствах и сговоре. История неприятна не тем, что кто-то снова украл пароль, а тем, что пароль, похоже, вообще слишком долго оставался рабочим.
Именно по этой причине Snowflake добивает тип учетных записей LEGACY_SERVICE. В третьей фазе своей схемы перевода аутентификации компания переводит старые сервисные учетные записи в тип SERVICE, а он уже не поддерживает хранение пароля. График у миграции не вчерашний. С сентября 2025 по январь 2026 года Snowflake обязала обычных пользователей проходить второй фактор в Snowsight, но сервисные аккаунты тогда не трогала. С мая по июль 2026 года все новые non-human users уже должны были создаваться только как SERVICE, то есть без паролей. Теперь, в интервале с августа по октябрь 2026 года, дошла очередь до старых записей, которые еще держатся на password-based authentication.
На бумаге задача выглядит почти скучно: выбрали новый способ входа, переключили интеграцию, удалили пароль, закрыли тикет. На практике сервисные аккаунты Snowflake часто оказываются наследием того самого «временного» решения, которое пережило три реорганизации, двух админов и одну смену BI-стека. В материале Token Security справедливо указывает, что главная проблема не в замене пароля как таковой. Сначала нужно ответить на три вопроса: какие аккаунты вообще аутентифицируются в Snowflake, кто за каждый из них отвечает и что сломается, когда пароль перестанет работать. Первый вопрос Snowflake еще помогает закрыть: в ACCOUNT_USAGE можно увидеть типы пользователей, а история логинов за 365 дней показывает, кто входил по паролю, когда именно и с какого клиента или IP. Дальше начинается уже не платформа, а внутренняя археология компании.
С владельцами особенно показательно. Формально можно занести имя в таблицу и успокоиться, но реальное владение выглядит иначе: кто получит алерт в два часа ночи, если аутентификация этого аккаунта упадет, и кто имеет право этот доступ отключить навсегда, если выяснится, что он больше не нужен. Если ответа нет, у аккаунта нет владельца, а значит, вопрос не в способе миграции, а в том, почему такая сущность вообще все еще существует. Практика с controlled disable window, которую рекомендуют в источнике, здесь звучит вполне рационально: временно выключить запись, посмотреть на ошибки и зависимости, при необходимости вернуть, а потом уже удалять окончательно. Для российских команд это знакомый сюжет: половина «технического долга» в доступах обнаруживается только после того, как кто-то попробовал что-то выключить.
Отдельный слой проблемы связан с тем, что passwordless в корпоративной инфраструктуре не равно secretless. Для SERVICE-аккаунтов Snowflake предлагает четыре варианта: workload identity federation, External OAuth, key-pair authentication и programmatic access tokens. Рекомендуемый вариант самой Snowflake — федерация workload identity, потому что там не нужно хранить и ротировать секреты, если среда умеет предъявлять федеративную идентичность. External OAuth дает сильную схему, но требует аккуратной настройки внешнего провайдера идентификации как authorization server. Key-pair authentication технически избавляет от пароля в запросе, но по смыслу оставляет длинноживущий секрет, только в другом формате. Programmatic access tokens ближе всего к прямой замене пароля, причем для SERVICE-пользователей Snowflake по умолчанию требует сетевую политику и ограничение ролей, хотя это можно ослабить authentication policy. Иными словами, плохую практику можно мигрировать в чуть более модный контейнер, не меняя сути.
Самое неприятное в этой истории — не дедлайн третьей фазы, а то, что старый секрет нельзя считать «нормальным до момента отключения». По данным Mandiant и Snowflake, как минимум 79,7% учетных записей, использованных в кампании UNC5537, имели признаки предыдущей компрометации учетных данных. Самый ранний infostealer-инцидент, связанный с одним из таких логинов, датировался ноябрем 2020 года. То есть украденный пароль мог оставаться рабочим примерно три с половиной года. Поэтому замена механизма входа без ревизии всех мест, где старый секрет мог остаться, дает ложное чувство закрытой задачи. Секреты в CI-переменных, старых runbook, хранилищах секретов и локальных окружениях никто магическим образом не удалит только потому, что в Snowflake кнопка миграции уже нажата.
Для разработчиков, платформенных команд и ИТ-руководителей тут есть вполне практический вывод. История про сервисные аккаунты Snowflake на самом деле не про Snowflake, а про стоимость бесхозной машинной идентичности. Пока сервисный пользователь воспринимается как безличный «технический» объект, у него почти гарантированно будет избыточная роль, неочевидный владелец и слишком долгий срок жизни. А дальше неважно, как называется платформа: data warehouse, CI/CD, SaaS для продаж или агентная AI-система. В материале отдельно упоминается новый тип SERVICE_AGENT для автоматизированных ИИ-агентов, и это уже намек на следующий раунд. Если компании не научатся разбирать зависимости, назначать хозяев и ограничивать права non-human identities сейчас, то с агентами они просто масштабируют тот же бардак, только быстрее и дороже.
Главный вопрос теперь даже не в том, успеют ли организации уложиться в окно августа-октября 2026 года. Интереснее другое: сколько компаний обнаружат, что у них годами работали доступы, про которые никто толком не мог сказать ни кто их создал, ни зачем они все еще нужны, ни какие системы рухнут после отключения. Snowflake просто убирает пароль из уравнения. Все остальное, включая владельцев, роли, ротацию и сетевые ограничения, как и прежде остается на совести тех, кто любит считать сервисный аккаунт «небольшой технической деталью».