Кампания по краже учётных данных Snowflake и границы общей ответственности

Краткое содержание

• Подтверждённые границы кампании:Mandiant отнесла финансово мотивированную кампанию к группировке UNC5537 и заявила, что все инциденты кампании, которыми она непосредственно занималась, были вызваны скомпрометированными учётными данными клиентов. Специалисты не нашли доказательств того, что несанкционированный доступ клиентов возник из-за взлома корпоративной среды Snowflake. Сама Snowflake также сообщила, что не обнаружила признаков уязвимости, ошибки конфигурации или взлома своей платформы, которые привели бы к этой активности.
• Наблюдаемая цепочка контроля:на скомпрометированных аккаунтах не была включена многофакторная аутентификация (MFA), использовались учётные данные, ранее утёкшие в исторических записях инфостилеров, и отсутствовали сетевые списки разрешений. Затем злоумышленники с помощью поддерживаемых клиентов Snowflake и SQL-операций перечисляли данные, подготавливали их, сжимали и скачивали. Уведомления о потенциальной угрозе получили примерно 165 организаций; это не число подтверждённых взломов, пострадавших или записей.
• Вывод об общей ответственности:клиенты контролировали своих пользователей, роли, ротацию паролей, включение MFA, сетевые политики, гигиену конечных точек и минимизацию данных. Snowflake контролировала, какие защиты существовали, как они представлялись и какие значения были заданы по умолчанию, какие межклиентские сигналы могла видеть платформа и как быстро предупреждения и более строгое базовое поведение доходили до установленной базы. Эти обязанности действуют одновременно, а не исключают друг друга.
• Вывод о суверенитете:выбор региона Snowflake определяет, где находятся хранение и вычисления аккаунта; документация Snowflake прямо говорит, что регион не ограничивает доступ пользователей. В этой кампании действительная учётная запись могла превратить регионально хранимый набор данных в скачанную копию. Локализация данных без контроля над идентификацией, исходящим трафиком и доказательствами — это решение о размещении, а не полноценный контроль суверенитета.

Взлом платформы не был доказан, но отношения с сервисом прошли проверку

Первая дисциплина в этом деле — терминология. Экземпляр Snowflake клиента — не то же самое, что собственная корпоративная среда Snowflake или общая производственная платформа. Человек с действительными учётными данными мог войти в аккаунт одного клиента, не пересекая границу другого арендатора, не эксплуатируя уязвимость ПО, не получая учётную запись администратора провайдера и не ломая инфраструктуру, разделяющую клиентов. Публичные доказательства подтверждают компрометацию клиентских аккаунтов. Они не подтверждают техническую компрометацию платформы в целом.

Отчёт Mandiant о кампанииUNC5537необычно прямолинеен в этом вопросе. Для каждого инцидента кампании, которым Mandiant занималась сама, первопричиной были скомпрометированные учётные данные клиента. Расследование не нашло доказательств того, что несанкционированный доступ к клиентским аккаунтам стал следствием взлома корпоративной среды Snowflake. В собственномуведомлении о расследовании и мерах защитыSnowflake также отделила скомпрометированные клиентские аккаунты от производственной платформы и предоставила клиентам запросы и индикаторы для проверки собственных сред. CISA усилила эти рекомендации впредупреждении от 3 июня 2024 года.

Этот негативный вывод важен. Называть событие взломом платформы Snowflake можно, если подразумевать, что дефект в общем коде или инфраструктуре открыл всех арендаторов или что Snowflake потеряла главные учётные данные, открывавшие аккаунты клиентов. Изученные материалы не устанавливают ни того, ни другого. Такая формулировка также скрыла бы действия, которые клиентам нужно было предпринять немедленно: выявить пользователей, входящих только по паролю, сменить учётные данные, проверить историю входов и запросов, ограничить сети, сократить привилегии ролей и сохранить доказательства.

Обратная ошибка — считать, что отсутствие взлома платформы означает отсутствие вопроса об ответственности провайдера. Облачный сервис — это не просто нейтральный диск, на который клиент случайно кладёт биты. Snowflake построила и эксплуатировала конечные точки аутентификации, которые принимали учётные данные, интерфейсы, которыми пользовались злоумышленники, механизм запросов, обрабатывавший их команды, телеметрию, записывавшую сеансы, и продуктовые средства контроля, которые могли потребовать второй фактор или ограничить сетевой источник.

Snowflake также обладала видимостью между клиентами, которой не мог располагать ни один отдельный клиент.

То, что решающий контроль мог настроить клиент, определяет, у кого была операционная обязанность его настроить. Это не отвечает на вопрос, были ли настройки по умолчанию, предупреждения, обнаружение и принудительные меры провайдера соразмерны концентрации данных в его сервисе.

Форма10-KSnowflake за 2025 финансовый год закрепляет её позицию. В ней говорится, что Snowflake отвечает за безопасность платформы и базовой облачной инфраструктуры, а клиенты выбирают и настраивают средства контроля для своих сред. В документе доступ в мае 2024 года связывается с невыполнением клиентами таких обязательств, как MFA и сетевые политики, и одновременно фиксируются судебные иски, регуляторные расследования, запросы законодателей, репутационный ущерб и возможность споров о компенсации. Это существенные корпоративные доказательства заявленной модели Snowflake и её деловых рисков.

Это не независимое решение о том, что вся ответственность или все юридические претензии лежат на стороне клиента.

Поэтому полезный вопрос уже, чем «Кто был взломан?», но шире, чем «У кого украли пароль?» Он звучит так: на каждом шаге от украденного секрета до скачанных данных какой участник мог предотвратить, обнаружить, прервать, восстановить или предупредить о действии? Ответственность следует за контролем над этими шагами.

Кампания соединила старую кражу с конечных устройств с нынешними полномочиями в облаке

Mandiant впервые получила разведданные об угрозах в апреле 2024 года относительно записей базы данных, которые позже были связаны с экземпляром Snowflake одной из жертв. Эта жертва привлекла Mandiant, и та пришла к выводу, что злоумышленник использовал учётные данные, ранее похищенные вредоносным ПО-стилером. На соответствующем аккаунте не была включена MFA. 22 мая, после выявления признаков более широкой кампании, Mandiant связалась со Snowflake и начала уведомлять потенциальных жертв. 30 мая Snowflake опубликовала для клиентов рекомендации по обнаружению и защите.

К моменту выхода июньского отчёта Mandiant и Snowflake уведомили примерно 165 организаций, которые потенциально оказались под угрозой.

Каждый термин в последнем предложении нужно защищать от преувеличений. «Примерно» указывает на оценку. «Потенциально оказались под угрозой» описывает круг уведомлённых, а не 165 завершённых судебно-экспертных выводов. «Организации» — это не аккаунты, базы данных, люди или записи. У некоторых организаций может быть несколько аккаунтов Snowflake, и в одном аккаунте могут храниться данные о гораздо большем числе людей. В отчёте нет общих по всей кампании цифр подтверждённых организаций, пострадавших лиц, выгруженных байтов или выплат за выкуп.

История учётных данных объясняет, почему облачный вход в 2024 году мог начинаться с заражения конечного устройства много лет назад. Mandiant установила, что большинство использованных UNC5537 учётных данных присутствовало в исторических выводах стилеров, а самое раннее связанное заражение наблюдалось в ноябре 2020 года. По крайней мере 79,7\u00A0% аккаунтов, использованных группировкой, ранее имели утечку учётных данных. Этот процент относится к аккаунтам, использованным группировкой в проанализированной кампании, а не ко всем клиентам Snowflake и не ко всем 165 уведомлённым организациям.

Три условия снова и снова превращали раскрытые секреты в рабочий доступ. На затронутых аккаунтах не была настроена MFA. Пароли из записей стилеров оставались действительными, иногда годами. В затронутых экземплярах клиентов не было сетевых списков разрешений, которые ограничивали бы подключения доверенными источниками. Ни одно из этих условий не является новой эксплуатацией уязвимости.

Вместе они создавали устойчивый путь авторизации: узнать локатор аккаунта, имя пользователя и всё ещё действительный пароль; подключиться с системы, контролируемой злоумышленником; получить сеанс; унаследовать назначенную роль; запрашивать всё, что эта роль может читать.

Измерение конечных устройств также оказалось более распределённым, чем предполагает привычный сюжет о ноутбуке сотрудника. В нескольких расследованиях Mandiant обнаружила более раннее заражение стилером на системах подрядчиков, которые также использовались для личных целей, включая игры или пиратские загрузки. Устройство подрядчика может находиться за пределами управляемого парка конечных устройств клиента, но при этом хранить учётные данные для нескольких клиентов. На нём может быть и административный аккаунт, потому что профильных подрядчиков часто нанимают для создания или эксплуатации платформ данных.

Клиент, создавший пользователя, по-прежнему отвечает за эту учётную запись и её привилегии, но сама утечка может быть невидима для собственных инструментов управления конечными устройствами клиента.

Это мультипликатор облачной зависимости. Учётные данные украдены с одного конечного устройства, возможно, за пределами парка устройств как Snowflake, так и владельца данных. Учётные данные принимает глобальный сервис. Роль может получить доступ к консолидированному хранилищу, содержащему годы записей из нескольких бизнес-систем. Злоумышленнику больше не нужно взламывать эти исходные системы по одной. Аналитическая ценность, делавшая хранилище полезным для клиента, сделала успешный доступ ценным и для вымогателя.

Злоумышленники несут прямую ответственность за кражу, покупку, проверку и использование учётных данных; за несанкционированный вход в среды клиентов; за вынос данных и за попытки продажи или вымогательства. Описание сбоев контроля, сделавших эти преступления возможными, не ослабляет этой ответственности. Оно объясняет, почему одна и та же преступная техника сработала в массовом масштабе и где можно снизить повторяемость.

Поддерживаемые функции стали путём выноса данных

Кампания не остановилась на аутентификации. Mandiant наблюдала доступ через Snowsight, SnowSQL, драйверы и инструменты работы с базами данных. Группировка перечисляла пользователей, роли, сеансы, названия организаций, базы данных, схемы и таблицы. Она использовала привычные SQL-операции для выборки данных, создания временных стадий, копирования результатов запросов в сжатые файлы и скачивания этих файлов на локальную машину. В нескольких случаях похожие команды появлялись в разных клиентских средах.

Эта последовательность делает инцидент читаемым как обычная функциональность, использованная под несанкционированной учётной записью:

1. Действительные имя пользователя и пароль клиента устанавливали сеанс.
2. Сеанс наследовал роли и привилегии объектов, назначенные клиентом.
3. Разведка выявляла ценные таблицы и доступные стадии.
4. Запросы выбирали записи, которые роль имела право читать.
5. Временное создание стадий иCOPY INTOпревращали результаты в скачиваемые файлы.
6. GETперемещал файлы на управляемый злоумышленником клиент.

Ни на одном шаге этой цепочки база данных не должна была давать сбой. Вот почему шифрование при хранении, будучи необходимым, не было решающим контролем. Вдокументации Snowflake по сквозному шифрованиюсказано, что данные клиентов шифруются при хранении и под TLS при передаче, но также объясняется, что Snowflake расшифровывает данные при выполнении преобразований или операций с таблицами и позволяет пользователям выгружать и скачивать результаты. Шифрование защищает файлы и передачу от сторон, у которых нет авторизации или ключей. Оно не мешает принятой учётной записи с разрешённой ролью попросить сервис вернуть читаемые результаты.

Тот же принцип относится к ключам, управляемым клиентом. Контроль ключей может решить сценарии, связанные с провайдером, хранением и отзывом, но работающий аккаунт должен использовать свою иерархию ключей для обслуживания авторизованных запросов. Если политика ключей не связана с отдельным решением, отклоняющим сеанс или операцию, база данных не может отличить владельца аккаунта от злоумышленника, который выполнил настроенную владельцем политику аутентификации.

Поэтому дизайн ролей контролировал радиус действия после входа. В текущеймодели контроля доступаSnowflake поддерживаются ролевое и дискреционное управление доступом, владение, иерархия ролей и привилегии на объекты. Учётная запись, которой назначен только узкий доступ к базе данных или представлению, даёт иной результат, чем учётная запись с рольюACCOUNTADMIN, широким использованием виртуальных складов или доступом на чтение к необработанным наборам данных. Сервисный аккаунт, используемый интеграцией, не должен наследовать исследовательский охват администратора-человека. Временная роль подрядчика должна истекать вместе с завершением работ, а не оставаться бездействующей с действительным паролем.

Политики защиты данных могут сузить результат, даже если роль скомпрометирована.Документация по классификации чувствительных данныхSnowflake связывает обнаружение персональных и чувствительных колонок с политиками маскирования и доступа к строкам. Это описание текущих возможностей, а не доказательство того, что каждый затронутый клиент в 2024 году классифицировал или маскировал свои данные. Оно ставит проектный вопрос: предоставлял ли клиент полные исторические таблицы учётным записям, которым нужны были только агрегаты, свежие партиции, токенизированные поля или утверждённые представления?

Экспорт — это сама по себе привилегированная бизнес-функция, и управлять ею нужно соответственно. Хранилищу данных часто требуются массовые выгрузки для легитимных конвейеров, резервных копий, обучения моделей и нижестоящих систем. Полный запрет редко реалистичен. Но создание стадии, выгрузка необычно большого результата или использование незнакомого клиента и сетевого источника должны быть наблюдаемыми, а для наборов данных повышенного риска могут оправдывать согласование, лимиты скорости, ограничения назначения, кратковременное повышение привилегий или отдельную роль для экспорта.

Команды кампании были достаточно обычными, чтобы выполниться, но достаточно необычными по контексту, чтобы заслуживать быстрого решения службы безопасности.

Клиент отвечал за настройку, Snowflake — за базовый уровень

MFA — самый острый тест общей ответственности, потому что обе стороны могут сказать правду. Администратор клиента мог и должен был её включить. Snowflake предлагала MFA с 2015 года, а сетевые политики — с 2016 года. В то же время успешные аккаунты 2024 года могли проходить аутентификацию без MFA, а значит, эффективный базовый уровень сервиса допускал для этих аккаунтов путь только по паролю.

Разница между доступностью и принудительным применением — не семантика. Функция безопасности может быть бесплатной, документированной и рекомендованной и всё равно отсутствовать в значимых сеансах. Администраторы сталкиваются со старыми интеграциями, неинтерактивными сервисными пользователями, подрядчиками, аварийными аккаунтами, несколькими клиентами и страхом блокировки. Эти ограничения объясняют сопротивление внедрению; они не оправдывают оставление привилегированного человеческого доступа зависимым от многоразового пароля.

Они также дают провайдеру информацию, необходимую для создания инструментов миграции, разделения человеческих и сервисных учётных записей и оформления исключений явным образом.

После кампании публичный курс Snowflake сместился от рекомендаций к более строгим настройкам по умолчанию. Вобъявлении о присоединении к инициативе Secure by Designот июля 2024 года Snowflake подчеркнула политики управления MFA и проверки Trust Center. В сентябре 2024 года Snowflake сообщила, чтоMFA будет применяться по умолчаниюдля пользователей-людей в аккаунтах, созданных с октября 2024 года, и порекомендовала SSO с MFA у поставщика удостоверений для людей и OAuth или key-pair аутентификацию для сервисов. Различие между новыми и существующими аккаунтами важно. Безопасное значение по умолчанию защищает будущие создания; оно не устраняет автоматически все унаследованные пути входа по паролю в установленной базе.

Позже Snowflake представилазащиту от утёкших паролей, которая использует каналы threat intelligence для проверки сообщённых утёкших паролей в процессе, сохраняющем конфиденциальность, и отключает пароль, когда подтверждается, что он всё ещё действителен. Этот контроль на стороне провайдера напрямую устраняет одно из преимуществ UNC5537: старые учётные данные стилеров, которые оставались рабочими. Это также доказательство того, что общая ответственность может развиваться. Клиентам по-прежнему нужно управлять учётными записями и ротацией, но провайдер может использовать межсервисную аналитику, чтобы украденный пароль перестал работать до того, как каждый клиент найдёт его самостоятельно.

Текущаядокументация по политикам аутентификациипозволяет администраторам контролировать разрешённые методы и клиенты и требовать MFA на уровне аккаунта или пользователя. В ней также говорится, что ограничения по типам клиентов действуют по принципу «best effort» и не должны быть единственной границей безопасности. В текущихрекомендациях по key-pair аутентификациисервисным пользователям предлагается альтернатива статическим паролям. Эти страницы описывают возможности, доступные к 2026 году; их нельзя читать задним числом как доказательство точного набора функций, настроек по умолчанию или состояния принудительного применения у каждого клиента в апреле 2024 года.

Стандарты помогают объяснить, почему настройки провайдера по умолчанию должны быть частью анализа. В действующихрекомендациях NIST по аутентификации и управлению аутентификаторамипароли рассматриваются как не обладающие устойчивостью к повторному использованию, а устойчивость к фишингу определяется как свойство протокола, не зависящее от бдительности пользователя. Вобязательстве CISA Secure by Design 2024 годапрямо названы MFA по умолчанию, постоянные напоминания в продукте, базовая поддержка SSO и публикация метрик внедрения как способы, которыми производители ПО могут измеримо повысить использование MFA. Snowflake подписала это добровольное обязательство после кампании.

Обязательство — не юридический вердикт о дизайне Snowflake 2024 года, но оно отвергает идею, что предложение флажка исчерпывает роль провайдера.

Подотчётный базовый уровень различает типы учётных записей. Администраторы-люди должны использовать устойчивую к фишингу MFA или строго управляемую федеративную идентичность. Сервисные рабочие нагрузки должны использовать рабочие учётные данные, которые можно ограничивать, ротировать и атрибутировать, не притворяясь, что робот может ответить на push-уведомление. Аварийный доступ должен быть редким, отслеживаемым, ограниченным по времени и проверяемым. Учётные записи подрядчиков должны иметь владельца, срок действия, одобренный профиль устройства и отсутствие повторного использования учётных данных между клиентами.

Каждое исключение должно появляться на панели мониторинга, знаменатель которой — все учётные записи, а не только действующие сотрудники.

Сетевая политика была вторым барьером, а не заменой идентификации

Третий повторяющийся фактор Mandiant — отсутствие сетевых списков разрешений. Действительные учётные данные можно было использовать из инфраструктуры, у которой не было деловых причин подключаться к хранилищу клиента. Сетевые ограничения не исправили бы украденный пароль, но могли бы сделать этот пароль недостаточным из недоверенного источника.

В текущейдокументации Snowflake по сетевым политикамзначение по умолчанию указано прямо: без политики пользователи могут подключаться с любого компьютера или устройства. Клиенты могут разрешать или блокировать диапазоны IP и частные конечные точки, применять контроль на уровне аккаунта или пользователя и дополнительной настройкой ограничивать доступ к внутренним стадиям. Частное подключение и контроль публичного доступа могут дополнительно усилить аккаунты с высокими требованиями к чувствительности.

Клиент знает свои утверждённые офисы, облачные рабочие нагрузки, VPN, подрядчиков и точки интеграции, поэтому именно клиент должен определить рабочий список разрешений. Snowflake не может вывести все легитимные источники, не нарушая бизнес. При этом провайдер контролирует доступность по умолчанию, синтаксис политики, возможность симуляции изменения, защиту от блокировки, журналирование и то, предупреждается ли администратор, когда политика аккаунта отсутствует. Платформа может сохранять выбор клиента, делая неограниченный публичный доступ заметным временным исключением, а не тихим состоянием по умолчанию.

У сетевых правил есть и пределы. Злоумышленники могут получить сеанс с одобренного устройства подрядчика, пройти через разрешённый корпоративный VPN, скомпрометировать рабочую нагрузку внутри разрешённого облака или украсть токен после аутентификации. У крупных предприятий могут меняться адреса исходящего трафика, что затрудняет статические списки. Частное подключение может исключать SaaS-инструменты, которые его не поддерживают. Это причины сочетать сетевой контроль с сильной идентификацией и обнаружением поведения, а не отказываться от него.

Кампания демонстрирует ценность независимых барьеров. Ротация паролей сделала бы исторические учётные данные недействительными. MFA потребовала бы дополнительный фактор. Сетевая политика отклонила бы незнакомые источники. Минимальные привилегии уменьшили бы видимые данные. Контроль экспорта мог бы прервать создание стадий. Обнаружение могло бы сократить время пребывания в системе. Ни одна мера не идеальна; злоумышленник преуспел там, где несколько мер одновременно отсутствовали или были слишком разрешительными.

Для подотчётности у каждого барьера должны быть владелец и показатель эффективности. «Сетевая политика поддерживается» — это факт о продукте. «У каждого производственного аккаунта есть проверенная политика, охватывающая сервис и внутренние стадии» — операционный результат. «MFA доступна» — факт о продукте. «Ни один привилегированный человек не может установить сеанс только с многоразовым паролем» — результат. Общая ответственность становится осмысленной, только когда обе стороны могут показать результаты на своей границе.

Провайдер видел кампанию, которую каждый клиент видел только как инцидент

Отдельный клиент мог проверять свои неудачные и успешные входы, клиенты, IP-адреса, текст запросов, роли, стадии и перемещение данных. Snowflake могла сопоставлять закономерности между аккаунтами: одна и та же инфраструктура, необычные клиенты, повторяющаяся разведка, похожие команды создания стадий, всплеск входов только по паролю или учётные данные, совпадающие с каналами threat intelligence. Эта асимметрия — самая важная недоговорная обязанность провайдера. Она возникает из эксплуатации сервиса в масштабе.

В текущем представлении SnowflakeLOGIN_HISTORYхранится один год попыток входа, включая пользователя, исходный IP, указанный клиент, первый и второй факторы, успех и связанные данные о риске, с документированной задержкой.QUERY_HISTORYхранит один год активности запросов и связывает запрос с событием аутентификации, сеансом, пользователем, ролью, текстом, байтами результата, выгруженными строками и байтами, отправленными по сети. Клиенты Enterprise могут использоватьACCESS_HISTORYдля восстановления доступов к таблицам, представлениям, колонкам, стадиям, политикам и изменённым объектам. Эти схемы дают сырой материал для качественного расследования.

Сырая история — не то же самое, что обнаружение. Клиент должен предоставить аналитикам доступ, выгрузить или запросить данные, понять нормальное поведение, написать предупреждения, настроить их маршрутизацию, при необходимости хранить дольше нативных окон и обеспечить персонал для реагирования. Задержка телеметрии в два часа может быть приемлема для ретроспективной проверки, но слишком велика для некоторых решений о массовой выгрузке. Ограничение истории доступа к колонкам на уровне редакции Enterprise также может влиять на то, насколько точно клиент может оценить масштаб воздействия.

Эти продуктовые и операционные факты нужно проверять при закупке, а не обнаруживать после кражи.

ТекущийTrust CenterSnowflake проверяет охват MFA, сетевую политику аккаунта, привилегированные роли, неактивных пользователей, рискованные входы, необычные IP-адреса и крупные передачи данных через сканеры безопасности и threat intelligence. В текущей документации также указаны ограничения: некоторые пакеты нужно включить; некоторые обнаружения могут приходить в течение часа; наличие настроенной политики не доказывает, что её содержимое достигает поставленной цели. И снова: текущие возможности — не доказательство того, что конкретный клиент или Snowflake обнаружили весной 2024 года.

Это показывает, что провайдер может превратить в продукт, если поймёт повторяющийся межклиентский сбой.

Система предупреждений должна работать на двух уровнях. На уровне арендатора клиентам нужны немедленные, экспортируемые события и средства контроля для блокировки или приостановки активности. На уровне провайдера Snowflake нужна аналитика кампаний и отработанный процесс уведомления клиентов с достаточными доказательствами для действий.

Полезное уведомление включает идентификаторы аккаунта и пользователя, метки времени в UTC, исходную инфраструктуру, фактор аутентификации, идентификаторы сеанса и запроса, команды, затронутые объекты и колонки, действия на стадиях, оценочный объём передачи, статус сдерживания и уровень уверенности. «Потенциально под угрозой» — подходящая начальная формулировка, только если за ней следуют доказательства, необходимые для разрешения этой потенциальной угрозы.

Вмешательство провайдера тоже требует управления. Автоматическая блокировка сеанса клиента может прервать производство и выйти за пределы договорных полномочий провайдера. Бездействие может позволить продолжить кражу. Поэтому дизайн должен заранее определять пороги риска, временные приостановки, каналы эскалации для клиента, аварийные контакты и быстрый процесс отмены. Клиенты должны назначить людей, которые могут в любой час получить предупреждение высокой степени серьёзности и санкционировать приостановку.

Провайдер должен измерять время от межклиентского сигнала до контакта с клиентом, время до сдерживания и долю уведомлённых клиентов, которые могут получить полный пакет доказательств.

Локализация данных не делала доступ локальным

Snowflake продаёт и документирует региональное развёртывание, потому что у клиентов есть требования к задержке, отказоустойчивости, конфиденциальности, регулированию и суверенитету. Вдокументации по поддерживаемым регионамSnowflake сказано, что каждый аккаунт размещается в одном регионе и данные остаются в этом регионе, если пользователи явно не копируют, не перемещают или не реплицируют их. На той же странице содержится критическое ограничение: регионы определяют, где хранятся данные и предоставляются вычислительные ресурсы; они не ограничивают доступ пользователей к Snowflake.

Это различие превращает цепочку UNC5537 в кейс о суверенитете. До вторжения таблицы клиента могли храниться и обрабатываться в выбранной стране или региональном облаке. После успешной аутентификации злоумышленник мог запрашивать региональный аккаунт откуда угодно, подготавливать результаты и скачивать их на свой клиент. Mandiant наблюдала техническую схему локального скачивания с временных стадий. Публичная запись кампании не устанавливает страну источника, страну назначения или правовой статус передачи для каждой жертвы, поэтому универсальное утверждение о незаконной трансграничной передаче не поддерживается.

Тем не менее архитектура показывает, что локальность хранения сама по себе не могла обеспечить локальность пользователей.

Кросс-региональный обмен и репликация создают отдельный легитимный путь перемещения.Руководство Snowflake по кросс-региональному обменупредписывает организациям проверять правовые и регуляторные ограничения перед репликацией данных в другой регион или страну. Это запланированное перемещение под управлением клиента. Вынос данных через учётные данные — другое: он может создать неконтролируемую копию за пределами выбранной среды, не меняя местоположение исходного аккаунта. Инвентаризация данных, фиксирующая только регион источника, будет продолжать говорить «ЕС» или «Канада», даже после того, как злоумышленник вынес копию.

Поэтому суверенитет данных имеет как минимум четыре слоя:

• Размещение:где предоставлены ресурсы хранения и вычислений.
• Доступ:какие человеческие и машинные учётные записи могут подключаться, с каких устройств, сетей и из каких юрисдикций.
• Перемещение:какие запросы, выгрузки, обмены, репликации, коннекторы и скачивания могут создавать ещё одну копию.
• Доказательства и восстановление:может ли организация доказать, откуда возник доступ, что ушло, какие люди или регулируемые записи были затронуты и как быстро она может сдержать и уведомить.

Провайдер контролирует важные части всех четырёх слоёв, даже когда политику выбирает клиент. Он предлагает регионы и хранит данные аккаунтов в них. Он аутентифицирует запросы и предоставляет сетевые средства контроля. Он выполняет команды экспорта и записывает метаданные запросов. Он обладает межклиентской видимостью угроз и может отключать утёкшие пароли. Клиент решает, каковы его правовые основания, категории данных, роли, разрешённые источники, маскирование, сроки хранения и одобренное перемещение.

Обязательство регионального размещения без этих дополняющих контролей может удовлетворить узкое требование о месте размещения дата-центра, оставляя при этом практическую возможность копировать данные по всему миру открытой.

Поэтому шифрование и суверенитет не следует смешивать. Шифрование может защитить хранимый объект от оператора инфраструктуры или неавторизованного читателя на уровне хранения. Приложение, которому нужно анализировать объект, неизбежно делает данные доступными авторизованному контексту запроса. Если гарантии идентификации и объём ролей слабы, криптографическая локальность может сосуществовать с операционным выносом данных.

Раскрытия клиентов показывают разные последствия, а не единый взлом

Кампанию часто описывают через громкие имена клиентов, но публичная запись каждого клиента имеет собственные масштаб, даты, данные, терминологию и уровень уверенности. Переносить факты одной компании на другую или превращать заявление на криминальном форуме в подтверждённую цифру пострадавших небезопасно.

Вформе 8-KLive Nation от 31 мая 2024 года говорится, что 20 мая компания выявила неавторизованную активность в сторонней облачной среде базы данных, содержащей корпоративные данные, в основном из Ticketmaster. В ней сказано, что 27 мая преступник предложил на продажу предположительно данные пользователей компании и что Live Nation уведомляет правоохранительные органы, регуляторов и пользователей по мере необходимости. Файл не называл Snowflake, не приводил подтверждённое число пострадавших и не объяснял путь аутентификации.

Настранице инцидента Ticketmaster Canadaуровень детализации иной. Там описан неавторизованный доступ к изолированной облачной базе данных, размещённой сторонним поставщиком услуг обработки данных, сказано, что база содержала ограниченную персональную информацию некоторых покупателей билетов в Северной Америке, и перечислены возможные поля, включая электронную почту, номер телефона, зашифрованные данные карт и другую информацию, предоставленную покупателями. Там также сказано, что аккаунты пользователей Ticketmaster не были затронуты.

Эта последняя граница важна: компрометация внутреннего хранилища данных не является доказательством того, что злоумышленник получил логин каждого человека в Ticketmaster или мог совершать операции через потребительский аккаунт.

Впарламентской справке Управления уполномоченного по вопросам конфиденциальности Канадыот октября 2025 года Snowflake названа сторонним провайдером, использовавшимся Ticketmaster, указано окно инцидента для Ticketmaster Canada со 2 апреля по 18 мая 2024 года и сказано, что была затронута персональная информация миллионов людей, включая канадцев. Там также сказано, что расследование остаётся открытым и что Ticketmaster Canada как контролёр данных по PIPEDA является субъектом расследования. Это полезный регуляторный контекст, но не окончательный вывод, разрешающий вопрос об адекватности мер защиты, сроках уведомления или ответственности.

Форма8-KAT&T от 12 июля 2024 года иллюстрирует, почему границы источников важны, даже когда инциденты обсуждаются вместе. AT&T сообщила, что неустановленное лицо незаконно получило доступ к рабочему пространству AT&T на сторонней облачной платформе и вынесло файлы с 14 по 25 апреля. Файлы содержали записи о взаимодействиях по звонкам и сообщениям почти всех беспроводных клиентов AT&T и соответствующих клиентов виртуальных операторов мобильной связи за определённые периоды 2022 года и один день 2023 года. AT&T сообщила, что в файлах не было содержания звонков и сообщений, номеров социального страхования, дат рождения или иной персональной информации в том значении, в котором AT&T использует этот термин.

Сам файл не называет Snowflake или UNC5537. Он подтверждает факты инцидента AT&T, но сам по себе не является атрибуцией кампании.

Эти записи дают четыре правила дисциплины. Первое: используйте раскрытие клиента только для этого клиента. Второе: различайте базу данных, корпоративный аккаунт и потребительский логин. Третье: различайте поля данных и число людей, которых эти поля представляют. Четвёртое: сохраняйте негативные факты, такие как «никакого содержания сообщений» или «потребительский аккаунт не затронут», наряду с воздействием. Подотчётность становится менее убедительной, когда анализ раздувает драматичные заявления и отбрасывает ограничения.

Клиенты оставались ответственными за данные и учётные записи, которые они делегировали

Сторона клиента в общей ответственности существенна. Организация создавала или одобряла пользователей Snowflake, выбирала пути аутентификации, назначала роли, загружала данные, хранила историю, выбирала регион, включала интеграции и решала, какие сотрудники и подрядчики могут обращаться к хранилищу. Она также имела основные отношения с людьми, чьи данные в нём представлены, и обычно сохраняла обязанности контролёра по применимому законодательству о конфиденциальности.

Клиент мог прервать наблюдаемую кампанию в нескольких точках. Он мог ротировать пароли после утечки конечного устройства, запретить сервисные аккаунты с паролями, требовать MFA для людей, федерализовать доступ через управляемого поставщика удостоверений, ограничить сети, аннулировать пользователей-подрядчиков, сократить назначения ролей, классифицировать и маскировать чувствительные поля, изолировать привилегию экспорта, отслеживать историю входов и запросов и отрепетировать уведомления облачного провайдера.

Для регулируемых наборов данных или данных с высоким воздействием это базовые операционные обязанности, а не опциональные улучшения, передаваемые закупкам.

Управление конечными устройствами и подрядчиками заслуживает особого внимания. Пользователь с высоковлиятельной облачной ролью не должен проходить аутентификацию с неуправляемого личного компьютера. Подрядчики должны по возможности использовать управляемые клиентом виртуальные рабочие столы или устройства с мониторингом конечных точек. Их учётная запись должна быть уникальной для каждого клиента, связана со спонсором и автоматически истекать.

Организация должна проверять каналы утечек учётных данных на предмет паттернов своего аккаунта Snowflake и принудительно ротировать учётные данные при появлении признаков, не дожидаясь подтверждённого злоупотребления.

Минимальные привилегии нужно проверять по данным, а не по должности. «Аналитик» может звучать неадминистративно, но при этом сохранять доступ на чтение к каждой строке таблицы клиентов, сотрудников или транзакций. Проверка ролей должна спрашивать, какие строки и колонки могут быть возвращены, нужны ли необработанные идентификаторы, могут ли массовые наборы результатов записываться на стадии и может ли учётная запись создавать новые учётные данные или интеграции. Пробные запросы под этой ролью — более сильное доказательство, чем аккуратное название роли.

Клиенты также отвечают за готовность к реагированию. Они должны уметь сопоставить пользователя Snowflake с сотрудником или подрядчиком, запрос — с затронутыми субъектами данных, вынос — с юрисдикцией и анализом необходимости уведомления. Нативных окон истории в один год может не хватить для более длительного юридического хранения или позднего обнаружения, поэтому клиентам с высоким риском следует передавать релевантные события в независимое хранилище безопасности. Предупреждения провайдера должны иметь проверенный путь к команде безопасности клиента, офису по конфиденциальности, владельцу бизнеса и руководителю, принимающему решения.

Вруководстве NIST по цепочке поставок в рамках Cybersecurity Frameworkрекомендуется определять и доводить до поставщиков требования в зависимости от критичности. Применительно к этому случаю клиент Snowflake должен закрепить в договоре сроки уведомления об инцидентах, поля доказательств, хранение, эскалацию поддержки, региональную обработку, видимость субпроцессоров, уведомления об изменениях контроля и доступ к гарантиям. Он также должен иметь план выхода или изоляции для тех функций обработки данных, потеря или компрометация которых была бы недопустима. Общая ответственность должна быть прописана как проверяемые интерфейсы, а не как абзац, который появляется только после инцидента.

Snowflake сохраняла ответственность за снижение риска на уровне сервиса

Snowflake не контролировала вредоносное ПО на личном устройстве подрядчика или решение клиента оставить MFA отключённой. Она контролировала, мог ли старый пароль оставаться единственным фактором, были ли неограниченные источники тихим значением по умолчанию, вызывали ли рискованные конфигурации постоянные предупреждения и что делал провайдер, заметив закономерность между клиентами.

Ответственность провайдера в этом случае состоит из шести частей.

Безопасный базовый уровень.Привилегированный человеческий доступ не должен зависеть только от многоразового пароля. Сервисные учётные записи должны иметь отдельный тип и поддерживаемые беспарольные методы. Новые настройки по умолчанию должны достигать существующих аккаунтов с высоким риском через поэтапное принудительное применение, явные исключения и помощь с миграцией, а не защищать только новые арендаторы.

Видимость конфигурации.Провайдер должен показывать администраторам безопасности полный знаменатель: людей без MFA, унаследованные сервисные пользователи с паролями, неактивные аккаунты, пользователи без сетевых ограничений, привилегированные роли и аккаунты, допускающие публичный вход. Результаты должны быть видны на уровне организации и экспортируемы для аудита.

Межклиентское обнаружение.Повторное использование инфраструктуры, утёкшие учётные данные, необычные клиенты, последовательности разведки, создание временных стадий и крупные выносы могут формировать сигнал кампании. Провайдер должен обнаруживать на уровне сервиса, связываться с вероятными жертвами и определять, когда активность с высокой уверенностью вызывает временную блокировку.

Действенная телеметрия.Клиентам нужны доказательства аутентификации, запросов, объектов, стадий и передачи с достаточным сроком хранения и достаточно низкой задержкой, чтобы сдержать активную кражу. Доказательства с более высоким разрешением не должны становиться недоступными именно там, где сервис хранит данные с самым высоким воздействием.

Предупреждение и координация.Предупреждение клиенту должно идти по известному аварийному маршруту и нести доказательства, а не просто совет просмотреть журналы. Провайдер должен отслеживать подтверждение получения, сдерживание и повторяемость уязвимости, а также поддерживать запросы правоохранительных органов и регуляторов, не превращая неопределённые наблюдения в подтверждённые цифры жертв.

Пост-инцидентная проверка.Анонсированные функции и настройки по умолчанию нуждаются в метриках внедрения и эффективности. Поздние изменения Snowflake — MFA по умолчанию, отключение утёкших паролей, результаты Trust Center и более строгие типы учётных записей — направлены на наблюдаемый путь. Оставшийся вопрос подотчётности — охват: какие пользователи и клиенты фактически защищены, какие исключения остаются и как часто контроль останавливает реальную или смоделированную попытку?

Такое распределение не делает Snowflake контролёром данных для каждого набора данных клиента и не делает провайдера ответственным за каждую конфигурацию клиента. Оно признаёт, что облачная компания получает выгоду от концентрации данных и эксплуатации границы безопасности. Масштаб создаёт обязанности, которые может выполнить только провайдер, особенно межарендаторную корреляцию и базовую инженерию.

Позднейшие судебные разбирательства проверяют ту же границу, пока не разрешая её

После инцидентов Snowflake и затронутые компании столкнулись с консолидированными гражданскими исками. Вопределении федерального судаот 29 октября 2025 года окружной суд Монтаны счёл, что истцы — финансовые учреждения — достаточно изложили некоторые теории небрежности против Snowflake и Ticketmaster, чтобы ходатайства об отклонении иска не были удовлетворены. Суд счёл предполагаемое отсутствие MFA по умолчанию и предсказуемость релевантными для вопроса об обязанности, нарушении и причинно-следственной связи на этой процессуальной стадии.

Это определение не является судебным выводом о небрежности Snowflake или Ticketmaster. При рассмотрении ходатайства об отклонении суд проверяет, излагают ли хорошо сформулированные утверждения правдоподобное требование; он не разрешает спорные доказательства, не определяет окончательный механизм инцидента для каждого истца и не распределяет ущерб. Snowflake оспаривала утверждения и утверждала, что вред причинили сами клиенты, не внедрившие MFA, сетевые политики и другие меры защиты. Определение важно, потому что показывает: описание MFA как настройки клиента не завершало автоматически любой иск об обязанности провайдера.

Оно не заменяет окончательный материал по существу дела.

Канадское расследование конфиденциальности несло иное распределение. OPC заявило, что Ticketmaster Canada остаётся контролёром и является субъектом расследования, а офис связался со Snowflake для получения информации. Это отражает распространённый принцип конфиденциальности: передача хранения на аутсорсинг не передаёт обязанность контролёра защищать и уведомлять. Это не означает, что у поставщика услуг нет собственных договорных, технических или установленных законом обязанностей.

В собственной форме 10-K Snowflake признала многочисленные судебные иски, регуляторные расследования и запросы законодателей, но не сообщила об окончательном универсальном распределении ответственности. По состоянию на дату публикации рассмотренные здесь открытые источники не позволяют утверждать, что Snowflake юридически оправдана, что каждый клиент юридически виноват или что окончательный суд или регулятор принял операционное распределение, предложенное в этой статье.

Операционную подотчётность можно оценивать до окончательной юридической ответственности. Была ли предсказуема аутентификация только по паролю? Да. Мог ли клиент требовать MFA и сетевые политики? Да. Могла ли Snowflake проектировать настройки по умолчанию и обнаруживать межклиентскую активность? Да. Использовали ли преступники возникший путь намеренно? Да. Эти утверждения могут сосуществовать. Деликтное, договорное, законодательство о конфиденциальности и о ценных бумагах может назначать последствия по-разному в зависимости от юрисдикции и истца, но инженерия не должна ждать, пока победит один лозунг.

Измеримый тест общей ответственности

Самая сильная реакция — не очередная схема с «клиентом» на одной стороне и «провайдером» на другой. Это набор средств контроля, чей охват и поведение при сбое можно продемонстрировать.

Советы директоров должны получать результаты, а не перечни функций. Полезные показатели: доля пользователей-людей, защищённых устойчивой к фишингу MFA; число сервисных пользователей с возможностью пароля; возраст каждого аварийного исключения; доля аккаунтов с проверенными сетевыми политиками; число привилегированных учётных записей подрядчиков с истёкшим сроком; медианное время до предупреждения о незнакомых источниках; время до приостановки сеанса с высокой уверенностью; и время до подготовки пакета доказательств на уровне полей.

Snowflake должна публиковать агрегированный прогресс там, где это можно сделать, не раскрывая клиентов. Обязательство CISA прямо предусматривает статистику внедрения по пользователям и типам MFA. Утверждение, что MFA доступна, менее информативно, чем распределение входов только по паролю во времени. Утверждение, что Trust Center включён, менее информативно, чем сколько критических выводов остаются открытыми дольше определённого периода. Утверждение, что подозрительные клиенты были уведомлены, менее информативно, чем задержка уведомления и полнота пакета доказательств.

Клиенты должны требовать такой же строгости от себя. Провайдер не может спасти организацию, которая создаёт широкие роли, игнорирует выводы, сохраняет старых пользователей-подрядчиков и не имеет никого у аварийного контакта. Смысл более строгих настроек по умолчанию — не передать ответственность за безопасность клиента Snowflake. Он в том, чтобы предсказуемые упущения реже превращались в массовую кражу данных.

Чего публичная запись по-прежнему не устанавливает

Доказательств достаточно, чтобы реконструировать схему кампании, но не каждый инцидент каждой жертвы.

Публичная запись не называет все уведомлённые организации, не подтверждает, что все 165 пострадали от неавторизованного доступа, и не даёт итоговых цифр по кампании: затронутых лиц, таблиц, записей или скачанных байтов. Она не показывает, какие жертвы платили вымогателям и произошло ли обещанное удаление данных.

Она не публикует для каждой организации тип пользователя, иерархию ролей, историю MFA, сетевую конфигурацию, владельца конечного устройства, последовательность сеансов, затронутые колонки или объём выноса. Выводы об устройствах подрядчиков из нескольких расследований нельзя приписывать каждой жертве. Статистику об утечке учётных данных в 79,7\u00A0% случаев нельзя превращать в процент жертв.

Она не устанавливает уязвимость ПО, выход за пределы арендатора, компрометацию производственной платформы Snowflake, кражу главных учётных данных провайдера или доступ к каждому клиенту Snowflake. Наблюдаемое использование поддерживаемых клиентов и команд — доказательство злоупотребления учётными данными, а не признак эксплуатации кода продукта.

Она не доказывает, что в каждом инциденте региональные данные пересекали государственную границу. Архитектура допускала удалённый доступ и локальное скачивание; правовой анализ передачи потребовал бы для каждого клиента фактов об источнике, назначении, субъектах данных, договоре и юрисдикции.

Она не позволяет обобщать возможные поля Ticketmaster, охват данных о звонках AT&T или любые подсчёты с криминальных форумов на других клиентов. Раскрытие Live Nation не называло Snowflake. Раскрытие AT&T не называло Snowflake или UNC5537. Внешняя ассоциация может быть важна для дальнейшего расследования, но файлы следует цитировать за то, что они действительно устанавливают.

Наконец, текущая документация Snowflake не доказывает работу средств контроля в апреле и мае 2024 года. Более поздние MFA по умолчанию, защита от утёкших паролей, обнаружение Trust Center, политики аутентификации и изменения типов учётных записей могут снизить повторяемость, но публичных доказательств внедрения, охвата исключений, эффективности обнаружения и независимой проверки по-прежнему меньше, чем описаний функций.

Общая ответственность должна пережить момент, когда рекомендацию проигнорировали

Кампанию Snowflake лучше всего понимать не как состязание двух абсолютных историй. Одна история говорит, что платформу взломали и подвёл только провайдер. Доказательства её не поддерживают. Другая говорит, что клиенты потеряли пароли и поэтому вопрос к провайдеру закрыт. Технически это неполно.

UNC5537 нашла масштабируемое соединение между компрометацией конечных устройств и концентрацией в облаке. Исторические пароли оставались действительными. Человеческие и сервисные учётные записи не всегда разделялись. Барьеры MFA и сетевых политик отсутствовали. Поддерживаемые функции запросов и стадий быстро перемещали данные. Провайдер мог видеть закономерность между арендаторами, тогда как каждый клиент видел только свой аккаунт. Выбранный регион хранения мог удерживать исходные данные на месте, даже когда аутентифицированный сеанс создавал неконтролируемую копию в другом месте.

У клиентов была самая очевидная обязанность управлять своими пользователями, ролями, конечными устройствами, подрядчиками и данными. У Snowflake была самая очевидная обязанность защищать и наблюдать за границей сервиса, делать ценные меры защиты простыми и всё более неизбежными, обнаруживать поведение кампании и предоставлять доказательства. Прямую ответственность за преступные действия несут злоумышленники. Регуляторы и суды должны оценивать юридические обязанности по фактам и праву, применимым к каждой организации. Эти распределения пересекаются, потому что пересекаются средства контроля.

Последующее продуктовое направление неявно признаёт разрыв между возможностью и результатом. MFA по умолчанию для новых пользователей-людей, отключение утёкших паролей, более строгие политики аутентификации, миграция сервисных пользователей и выводы Trust Center приближают безопасность к базовому уровню провайдера. Они не стирают ответственность клиента. Они делают общую систему менее зависимой от того, найдёт ли и включит ли каждый администратор все правильные опции до того, как украденный пароль будет проверен.

Это и есть устойчивый тест подотчётности для облачной платформы данных. Предположите, что клиент пропустит предупреждение, устройство подрядчика будет заражено, учётные данные останутся действительными, а злоумышленник воспользуется обычными функциями продукта. Затем спросите, блокирует ли значение по умолчанию вход, отклоняет ли другой барьер источник, мало ли показывает роль, вызывает ли экспорт вмешательство и доходят ли доказательства до клиента вовремя.

Общая ответственность заслуживает доверия только тогда, когда сервис остаётся защитимым после предсказуемой ошибки одной стороны и когда обе стороны могут доказать, что они сделали до неё и после.