Snowflake сделала проверяемое устранение последствий критерием общей облачной ответственности

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

• Mandiant сообщила, что каждый инцидент кампании против Snowflake, который она вела напрямую, был вызван скомпрометированными учётными данными клиентов, и не нашла доказательств того, что несанкционированный доступ стал следствием взлома корпоративного окружения Snowflake. Отчёт о кампании доступен по ссылкеhttps://cloud.google.com/blog/topics/threat-intelligence/unc5537-snowflake-data-theft-extortion.
• Кампания тем не менее поставила под вопрос ответственность провайдера, поскольку Snowflake контролировала поверхности аутентификации, настройки продуктов по умолчанию, рекомендации по безопасности, телеметрию аккаунтов, инструменты сетевых политик, проверки Trust Center и пост-инцидентные изменения, которые ни один клиент не мог создать самостоятельно.
• Проверяемое исправление означает измеримые изменения: MFA по умолчанию для пользователей-людей в новых аккаунтах, более строгие правила для паролей, автоматическое отключение утёкших паролей, пакеты доказательств для клиентов, контроль сетевых источников и метрики внедрения, показывающие снижение риска на всей установленной базе.
• Ответственность клиентов остаётся существенной. Клиенты контролировали создание пользователей, выдачу ролей, ротацию паролей, включение MFA в существующих аккаунтах, доступ подрядчиков, списки разрешённых сетей, минимизацию данных, привилегии на экспорт и готовность к расследованию.

Взлом платформы не был доказан; исходная конфигурация оказалась излишне разрешительной

Первая дисциплина — точно соблюдать границы кампании. В отчёте Mandiant за июнь 2024 года говорилось, что несанкционированный доступ в инцидентах, которые она вела, стал следствием скомпрометированных учётных данных клиентов, и что она не нашла доказательств взлома корпоративного окружения Snowflake. Рекомендации Snowflake клиентам, продублированные CISA наисточник: cisa.gov, также призывали клиентов расследовать несанкционированный доступ пользователей и усилить контроль идентификации и сетей. Изученные материалы не устанавливают факт эксплуатации уязвимости платформы Snowflake, межтенантного перехода или кражи главных учётных данных провайдера.

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

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

В годовом отчёте Snowflake за 2025 финансовый год, доступном по ссылкеисточник SEC, изложена позиция компании о разделённой ответственности и описаны юридические, регуляторные и репутационные последствия после событий 2024 года. Отчёт — это заявление компании, а не судебное решение. Тем не менее он важен, потому что Snowflake сама раскрыла, что кампания повлияла на бизнес-риски за пределами отдельного клиентского тенанта. Разделённая ответственность стала вопросом публичной компании.

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

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

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

Это различие ключевое для исправления. Шифрование в состоянии покоя не было решающим барьером. Документация Snowflake о сквозном шифровании по ссылкеисточник: docs.snowflake.comописывает шифрование в состоянии покоя и при передаче, но также объясняет, что данные должны использоваться при табличных операциях и могут быть выгружены и загружены авторизованными пользователями. Злоумышленник, прошедший аутентификацию аккаунта и получивший роль, может запросить у сервиса читаемые результаты. Шифрование не заменяет подтверждение идентичности, проектирование ролей, контроль экспорта и обнаружение.

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

Классификация и маскирование данных могут снизить последствия. Документация Snowflake о классификации чувствительных данных по ссылкеисточник: docs.snowflake.comсвязывает обнаружение чувствительных столбцов с политиками маскирования и доступа к строкам. Это не доказывает, что у пострадавших клиентов были такие меры. Это показывает путь исправления: клиенты должны выявлять персональные и регулируемые поля, где возможно, предоставлять представления, а не необработанные таблицы, и разделять роли экспорта и обычные роли чтения.

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

Наличие MFA превратилось в измеримые результаты MFA

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

В анонсе Snowflake за сентябрь 2024 года по ссылкеисточник: snowflake.comпозиция продукта изменилась. Компания сообщила, что MFA будет принудительно включена по умолчанию для пользователей-людей в аккаунтах, созданных с октября 2024 года, и что это конкретное требование не будет распространяться на сервисных пользователей. Также были анонсированы более строгие требования к паролям для вновь создаваемых и изменяемых паролей пользователей. Это значимое исправление, потому что оно меняет путь по умолчанию для будущих аккаунтов.

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

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

Документация Snowflake о политиках аутентификации по ссылкеисточник: docs.snowflake.comдаёт администраторам контроль над методами аутентификации, клиентами, провайдерами идентификации и подключением MFA. Документация о парной аутентификации по ссылкеисточник: docs.snowflake.comпредлагает сервисным аккаунтам альтернативу статическим паролям. Эти средства возлагают обязанности на клиентов, но также определяют поверхность исправления для провайдера: продукт должен делать хорошие модели более простыми, плохие исключения — заметными, а миграцию — менее рискованной.

Руководство NIST по цифровой идентификации по ссылкеисточник: pages.nist.govпомогает сформулировать результат. Пароли не устойчивы к повторному использованию (replay). Устойчивые к фишингу или криптографически привязанные методы снижают ценность украденного пароля. Для клиентов Snowflake это означает, что администраторы-люди должны переходить на федеративную идентичность или строгую MFA, а сервисные пользователи — использовать ограниченные учётные данные рабочих нагрузок, которые ротируются и могут быть отключены без использования чужой личности.

Блокировка утёкших паролей сделала разделённую ответственность измеримой

Самое прямое исправление провайдера после кампании кражи учётных данных — не лекция о повторном использовании паролей. Это сделать так, чтобы известные украденные пароли перестали работать. В анонсе Snowflake за декабрь 2024 года по ссылкеисточник: snowflake.comговорилось, что компания будет автоматически отключать пароли, обнаруженные в даркнете, с помощью конфиденциально сохраняющего процесс, если подтверждено, что они утекли и остаются действительными. Этот механизм устраняет главное преимущество кампании: учётные данные, украденные задолго до 2024 года, по-прежнему принимались сервисом.

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

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

Вопрос доказательств — внедрение и эффективность. Сколько действующих утёкших паролей было найдено? Как быстро их отключили? Сколько из них принадлежало привилегированным пользователям? Сколько аккаунтов перешло с пароля на парные ключи или федеративный доступ? Сколько событий отключения паролей привели к трениям в поддержке или небезопасным обходным путям? У скольких клиентов всё ещё есть исключения? Без метрик защита от утёкших паролей остаётся хорошим анонсом. С метриками она становится проверяемым исправлением.

Обязательство CISA Secure by Design по ссылкеисточник: cisa.govзадаёт это различие. Оно призывает производителей выходить за рамки опциональных средств и двигаться к измеримым результатам, таким как MFA по умолчанию и метрики внедрения. Анонс Snowflake об обязательстве за июль 2024 года по ссылкеисточник: snowflake.comпоместил компанию в рамки этого публичного обязательства. Обязательство добровольное и не является юридическим вердиктом по кампании. Оно важно, потому что определяет, какие доказательства клиенты вправе ожидать после события.

Сетевая политика была вторым барьером

Mandiant назвала отсутствие списков разрешённых сетей одним из повторяющихся факторов. Документация Snowflake о сетевых политиках по ссылкеисточник: docs.snowflake.comконстатирует практичное умолчание: без политики пользователи могут подключаться с любого компьютера или устройства. Клиенты могут ограничить доступ по разрешённым или заблокированным сетевым адресам и использовать модели приватного подключения для более строгих границ.

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

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

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

Телеметрия — это граница доказательств

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

LOGIN_HISTORY по ссылкеисточник: docs.snowflake.comпредоставляет попытки входа с исходным IP-адресом, клиентом, статусом успеха и информацией о факторе. QUERY_HISTORY по ссылкеисточник: docs.snowflake.comпредоставляет активность запросов, пользователя, роль, текст запроса, размер результата, выгруженные строки и отправленные по сети байты. ACCESS_HISTORY по ссылкеисточник: docs.snowflake.comможет помочь восстановить доступ к объектам и столбцам для подходящих изданий. Документация Trust Center по ссылкеисточник: docs.snowflake.comописывает проверки состояния и детекции для MFA, сетевых политик, рискованных входов, необычных IP-адресов и крупных передач.

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

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

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

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

Выбор региона Snowflake может иметь значение для задержек, устойчивости, приватности и закупок. Документация о поддерживаемых регионах по ссылкеисточник: docs.snowflake.comговорит, что аккаунт размещается в одном регионе и что данные остаются там, если пользователи явно их не копируют, не перемещают и не реплицируют. Там также указано ключевое ограничение: выбор региона не ограничивает доступ пользователей к Snowflake.

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

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

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

Клиентские кейсы показывают последствия, а не единую общую цифру

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

В заявлении Live Nation за май 2024 года по ссылкеисточник SECговорилось, что компания выявила несанкционированную активность в сторонней облачной среде базы данных, содержащей преимущественно данные Ticketmaster, и что преступник позже предложил к продаже allegedly украденные пользовательские данные компании. В заявлении не называлась Snowflake и не приводилось подтверждённое число пострадавших.

На странице инцидента Ticketmaster Canada по ссылкеисточник: help.ticketmaster.caописывалась изолированная сторонняя облачная база данных, возможные поля для некоторых покупателей билетов в Северной Америке и граница, согласно которой аккаунты клиентов Ticketmaster не были затронуты. Канадский уполномоченный по вопросам приватности позже назвал Snowflake провайдером Ticketmaster в парламентском брифинге по ссылкеисточник: priv.gc.ca, одновременно указав, что расследование остаётся открытым и что Ticketmaster Canada остаётся контролёром, в отношении которого ведётся проверка.

В заявлении AT&T за июль 2024 года по ссылкеисточник SECописывался незаконный доступ к рабочему пространству AT&T на сторонней облачной платформе и выгрузка записей о вызовах и текстовых сообщениях. В заявлении не называлась Snowflake. Оно полезно для понимания одного раскрытого инцидента в стороннем облачном рабочем пространстве и его границ по полям, но не является самостоятельной атрибуцией.

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

Заметка о типографике для пакетов доказательств

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

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

Подотчётность через практический контроль

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

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

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

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

Регуляторы, страховщики и закупочные команды контролируют стимулы. Руководство NIST по цепочкам поставок по ссылкеисточник: csrc.nist.govподдерживает определение требований к поставщику пропорционально критичности. Для хранилища данных это означает, что контракты и продления должны запрашивать метрики внедрения MFA, реакцию на утёкшие пароли, состав пакетов доказательств, гарантии хранения, сроки уведомления, эскалацию поддержки и контроль перемещения между регионами. Анкета безопасности, спрашивающая только о том, существует ли MFA, после этой кампании слишком поверхностна.

Что докажет устойчивое исправление

Запись об исправлении должна включать как минимум десять результатов.

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

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

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

Судебные разбирательства могут влиять на картину, но не должны заменять доказательства контроля. Постановление на стадии рассмотрения ходатайств в многоокружном деле Snowflake по ссылкеисточник: govinfo.govпозволило отдельным утверждениям продолжиться, рассматривая их по процессуальным стандартам. Это не окончательный вывод о виновности. Это показывает, что суды могут изучать настройки по умолчанию провайдера, предсказуемость и причинно-следственную связь, даже если публичная история начинается с учётных данных клиентов.

Проблема установленной базы

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

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

В-шестых, интеграции могут ломаться, если правила паролей или сетевые политики меняются внезапно.

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

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

Запись об исправлении должна разделять три состояния: устранено, исключение, неизвестно. «Устранено» означает, что рискованное условие исчезло. «Исключение» означает, что владелец бизнеса принял его с компенсирующими мерами и датой пересмотра. «Неизвестно» означает, что никто не взял ответственность. Зрелая программа стремится свести число «неизвестно» к нулю. Публичные заверения часто пропускают это различие; проверяемое исправление зависит от него.

Доказательства клиента должны связывать технические журналы с людьми

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

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

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

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

Исправление не может опираться на публичное порицание клиентов

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

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

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

Закупки должны требовать телеметрию исправления

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

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

Следует спрашивать, какие выводы Trust Center доступны на согласованном тарифном уровне и как долго хранится соответствующая история.

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

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

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

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

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

Чего не следует предполагать

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

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

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

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