Кампания с токенами Drift сделала согласие OAuth границей ответственности Salesforce

Кратко

• Google Threat Intelligence Group сообщила, что в период с 8 по как минимум 18 августа 2025 года UNC6395 атаковала инстансы клиентов Salesforce, используя скомпрометированные OAuth-токены стороннего приложения Salesloft Drift.
• В уведомлении доверия Salesforce говорилось, что Salesloft совместно с Salesforce аннулировала активные токены доступа и токены обновления и удалила Drift из AppExchange; проблема не была вызвана уязвимостью в базовой платформе Salesforce.
• Центр доверия Salesloft позднее сообщил, что Mandiant расследовала предполагаемое вторжение, затронувшее продукт Drift, и что в ходе расследования оценивались основная причина, масштаб, локализация, устранение последствий и сегментация между приложениями Drift и Salesloft.
• Инцидент показывает, что согласие OAuth — не административный фон. Интеграция с широкими правами может стать путём доступа к данным CRM клиентов, обращениям в поддержку, учётным данным в записях и связанным облачным системам.
• Ответственность следует за контролем. Salesloft контролировала продукт Drift и хранение токенов. Salesforce контролировала управление подключёнными приложениями платформы, реакцию AppExchange, каналы уведомления клиентов, видимость аудита и экстренный отзыв токенов. Клиенты контролировали одобрение подключённых приложений и гигиену данных, но часто лишь после того, как платформа и вендор сделали интеграцию доступной.

Публичная хронология начинается с делегированных полномочий

Аналитическая записка Google Threat Intelligence Group«Массовая кража данных из инстансов Salesforce через Salesloft Drift»— центральный технический источник. GTIG сообщила, что в период с 8 по как минимум 18 августа 2025 года субъект, отслеживаемый как UNC6395, атаковал инстансы клиентов Salesforce через скомпрометированные OAuth-токены стороннего приложения Salesloft Drift. По данным GTIG, злоумышленник экспортировал большие объёмы данных из многочисленных корпоративных инстансов Salesforce и искал секреты, такие как ключи доступа AWS, пароли и токены Snowflake.

Собственноеуведомление о безопасностиSalesforce обозначило границу платформы. Salesforce заявила, что инцидент связан с приложением Drift, опубликованным Salesloft, что Salesloft совместно с Salesforce аннулировала активные токены доступа и токены обновления, а Drift была удалена из AppExchange. В уведомлении также говорилось, что проблема не была вызвана уязвимостью в базовой платформе Salesforce. Это заявление важно, и его следует сохранить. Инцидент не является доказательством того, что злоумышленники использовали уязвимость в базовом ПО Salesforce.

Центр доверия Salesloftпозднее описал расследование Mandiant по подозреваемому вторжению, затронувшему продукт Drift. Там сообщалось, что Mandiant была привлечена 26 августа 2025 года для определения основной причины и масштаба, содействия локализации и устранению последствий, а также проверки сегментации между приложениями Drift и Salesloft. Этот источник важен, поскольку он помещает расследование на уровень вендора, а не только на уровень платформы Salesforce.

Последовательность публичных действий важна. Google и Salesforce описывают активность в начале и середине августа. В уведомлении Salesforce говорится, что токены были аннулированы, а Drift удалена из AppExchange. Ванализе взлома Drift-Salesforceот AppOmni также зафиксировано, что Salesloft и Salesforce отозвали OAuth-токены Drift, а пострадавшие организации были напрямую уведомлены Salesforce. Ваналитической запискеUnit 42 кампания описывается как использование скомпрометированных учётных данных OAuth для вывода данных из затронутых сред Salesforce.

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

Это не обычная кража паролей

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

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

Уведомление ФБР и IC3 уровня TLP:CLEAR —«Киберпреступные группы UNC6040 и UNC6395 взламывают платформы Salesforce»— предупреждало, что UNC6395 использовала скомпрометированные OAuth-токены приложения Salesloft Drift и что механизм доступа отличался от других кампаний, нацеленных на Salesforce. Впредупреждении FINRA о кибербезопасности в связи с атакой на цепочку поставок ИИ Salesloft Driftинцидент был описан для регулируемых финансовых компаний: похищенные OAuth-токены позволяли злоумышленникам выдавать себя за доверенное приложение Drift и получать несанкционированный доступ к средам клиентов.

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

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

Области доступа превратили доверие в радиус поражения

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

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

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

В анализе AppOmni подчёркивается предотвращение атак между SaaS-сервисами и сложность обеспечения видимости подключённых приложений. Вбюллетене безопасностиArctic Wolf событие также описано в контексте скомпрометированных OAuth-токенов Salesloft Drift и кражи данных Salesforce. Это анализы вендоров, но они подтверждают один и тот же контрольный пункт: SaaS-интеграции создают нечеловеческие идентичности, которые требуют управления на протяжении всего жизненного цикла.

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

Маркетплейс подключённых приложений — часть цепочки контроля

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

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

Из публичных материалов видно, что Salesforce использовала эту роль платформы: в уведомлении сказано, что она работала с Salesloft, аннулировала токены, удалила приложение и уведомила пострадавшие организации. Вопрос ответственности в том, насколько быстро это произошло относительно первой подозрительной активности и был ли у клиентов достаточный доступ к журналам, чтобы определить собственный уровень раскрытия. GTIG сообщила об активности кампании начиная с 8 августа; об отзыве токенов было объявлено 20 августа. Публика видит приблизительный интервал, но не внутренний процесс принятия решения об обнаружении.

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

Поэтому инцидент не следует рассматривать как простое распределение вины между тремя сторонами. Это цепочка: Salesloft должна была защищать Drift и её токены; Salesforce — управлять доверием к подключённым приложениям и экстренным отзывом; клиенты — ограничивать доступ приложений и убирать секреты из данных CRM; злоумышленники использовали эту цепочку.

Данные CRM стали поверхностью для поиска секретов

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

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

В публичном уведомлении GTIG говорится, что организациям следует искать секреты и ротировать учётные данные. Этот совет дорог с операционной точки зрения, потому что клиентам приходится искать в собственных данных то, что там никогда не должно было храниться. Инцидент вскрывает провал гигиены данных на уровне клиентов. Но триггером стала компрометация доверенной интеграции. Клиенты могли не осознавать, что интеграция чат-бота или коммерческого процесса может получить доступ к записям с учётными данными.

Salesforce и клиенты могут снизить этот риск, если будут рассматривать сканирование секретов как элемент контроля CRM. Записи следует сканировать на предмет ключевых паттернов. Процессы поддержки должны препятствовать вставке паролей и токенов. Чувствительные поля следует маскировать. Области доступа приложений не должны включать ненужные объекты. Экспорт следует отслеживать. Это не экзотические меры, а практическая реакция на реальность: в CRM-системах хранятся неструктурированные операционные данные.

Этот риск объясняет и важность уведомления клиентов. Если пострадала организация-клиент, её команда безопасности должна была узнать достаточно быстро, чтобы проверить записи, ротировать раскрытые секреты, проверить журналы связанных облачных систем и при необходимости предупредить собственных клиентов. Задержка или расплывчатое уведомление могли позволить украденным секретам остаться действительными.

Отзыв токенов был необходим, но сам по себе не означал восстановление

Отзыв токенов закрывает непосредственный путь делегированного доступа. В уведомлении Salesforce и в материалах GTIG описывается отзыв или аннулирование токенов доступа и обновления Drift. Это было необходимо. Но само по себе это не удалило уже экспортированные данные или собранные секреты. Восстановление должно было продолжаться в средах клиентов.

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

Второй шаг — ротация секретов. Если в записях хранились ключи AWS, токены Snowflake, VPN-учётные данные, ключи API, пароли или webhook-секреты, их нужно было найти и заменить. Это сложно, потому что секреты могут находиться в свободных текстовых полях, вложениях, комментариях к обращениям, чат-логах или настраиваемых объектах. Автоматический поиск помогает, но может пропустить нестандартные форматы. Ручная проверка медленна.

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

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

Маркировка «ИИ» не изменила проблему ответственности

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

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

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

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

Инцидент вскрыл асимметрию видимости

Платформы видят паттерны, которые отдельные клиенты видеть не могут. Отдельный клиент может заметить странное поведение API в своём org Salesforce. Salesforce видит установки приложений из AppExchange, аннулирование токенов и межклиентские паттерны. Salesloft видит телеметрию продукта Drift и хранение токенов. Google Threat Intelligence видит угрозную активность у разных клиентов и собственные расследования. Ни один клиент не видит кампанию целиком.

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

Публичная картина говорит о скоординированных действиях, но не показывает точную скорость внутренней эскалации. GTIG сообщила, что кампания началась уже 8 августа. В уведомлении Salesforce указаны действия по аннулированию и удалению. Центр доверия Salesloft сообщает, что Mandiant была привлечена 26 августа. Эти даты показывают движение, но не показывают, когда каждая сторона впервые узнала достаточно для действий и какие сигналы были доступны раньше.

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

Чему стоит научиться клиентам — без обвинений в их адрес

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

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

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

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

Стандарты OAuth объясняют, почему токены доступа требуют особой дисциплины

OAuth разработан для делегированной авторизации. Базовая спецификация OAuth 2.0,RFC 6749, позволяет клиенту получать токены доступа к ресурсам с авторизацией владельца ресурса. Эта схема мощная, потому что пользователю не нужно передавать клиенту свой пароль. Риск в том, что токен доступа часто является предъявительским (bearer): тот, кто им владеет, может использовать его в пределах области доступа, пока он не истечёт или не будет отозван.

Модель угроз и рекомендации по безопасности OAuth вRFC 6819предупреждают об утечке токенов, хранении токенов, повторном использовании, фишинге, злоупотреблении редиректами и необходимости ограничивать область доступа и срок жизни. Более новая передовая практика безопасности OAuth 2.0 —RFC 9700— продолжает это направление, делая акцент на современных защитных моделях. Эти стандарты — не отчёты об инцидентах Salesforce. Они объясняют, почему кампания Drift была структурно опасной.

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

ТехникаSteal Application Access Tokenв MITRE ATT&CK описывает кражу злоумышленниками токенов доступа приложений для доступа к удалённым системам и API. ТехникаUse Alternate Authentication Materialохватывает более широкий паттерн использования действительных аутентификационных артефактов вместо паролей. Эти фреймворки помогают назвать класс атаки, не преувеличивая факты по Salesforce: проблема заключалась в действительном делегированном материале в чужих руках.

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

Гигиена подключённых приложений требует владельца, а не таблицы после инцидента

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

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

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

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

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

Журналы должны отвечать на вопросы, по которым клиент может действовать

Рекомендации по инцидентам часто советуют клиентам просматривать журналы. Этот совет полезен только в том случае, если журналы отвечают на правильные вопросы. Для кампании Drift клиентам нужно было знать, какие токены приложений использовались, какие объекты Salesforce запрашивались, какие записи экспортировались, с каких IP-адресов, в каком пользовательском контексте, в каком временном окне и искали ли запросы строки, похожие на секреты.

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

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

Уведомление ФБР/IC3 и рекомендации GTIG направляют клиентов к подобным действиям, но исполнение сильно различается. У крупной финансовой компании может быть команда эксплуатации безопасности и озеро журналов. У небольшой SaaS-компании может быть администратор Salesforce, управляемый поставщик услуг безопасности и бэклог. Одна и та же кампания создаёт неравную нагрузку по восстановлению.

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

Секреты в записях CRM — предотвратимая, но распространённая ошибка

Неудобный урок в том, что клиентам нужно перестать относиться к CRM как к безопасному месту для операционных секретов. Команды поддержки и продаж часто вставляют ключи API, учётные данные, предъявительские токены, webhook-секреты, данные VPN или скриншоты в обращения и заметки, потому что пытаются решить проблему. CRM превращается в архив удобства. Когда интеграция может его читать, архив удобства становится хранилищем секретов.

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

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

Salesforce и вендоры интеграций могут помочь, создавая функции обнаружения секретов и предупреждая клиентов, когда широкие области доступа приложений включают объекты, которые, вероятно, содержат чувствительные операционные данные. Но клиенты по-прежнему отвечают за гигиену данных в своих org. Инцидент Drift не создал вредную практику хранения секретов в CRM; он показал, как эта практика может усилить компрометацию токена третьей стороны.

В публичной картине важно сохранить то, чего не произошло

Не менее важно зафиксировать, чего публичные источники не показывают. Источники не показывают, что злоумышленники использовали базовую уязвимость Salesforce. Они не показывают, что пострадали все клиенты Salesforce. Они не показывают, что из каждого клиента, подключённого к Drift, были экспортированы одни и те же данные. Они не показывают, что каждая экспортированная запись содержала секреты. Они не показывают, что более широкий набор продуктов Salesloft был скомпрометирован за пределами того, что описало расследование Salesloft.

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

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

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

Какие доказательства могли бы изменить оценку

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

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

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

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

Учения по отзыву токенов должны стать рутиной

Самый быстрый способ проверить, реально ли управление OAuth, — провести учения по отзыву до инцидента. Выберите некритичное подключённое приложение. Определите бизнес-владельца, области доступа, пользователей, токены, журналы, зависимые процессы и путь отката. Отзовите доступ в контролируемом окне и оцените, что сломалось. Затем зафиксируйте, кто одобрил восстановление и какие доказательства показали, что приложение безопасно подключать снова.

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

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

Критерий ответственности

Кампанию Drift-Salesforce следует оценивать по семи контрольным пунктам.

Первый — хранение токенов: защищала ли Salesloft токены доступа и обновления как особо чувствительные учётные данные и минимизировала ли её архитектура раскрытие токенов в Drift и других продуктах?

Второй — дизайн областей доступа: запрашивала ли интеграция Drift только те разрешения Salesforce, которые были ей нужны, и понимали ли клиенты радиус поражения при одобрении этих разрешений?

Третий — управление маркетплейсом: позволили ли проверка, мониторинг и процедура экстренного удаления в AppExchange достаточно быстро снизить риск для клиентов, когда приложение вендора стало небезопасным?

Четвёртый — межклиентское обнаружение: выявили ли Salesforce, Salesloft и партнёры по threat intelligence паттерны кампании достаточно быстро, чтобы отозвать токены до дальнейшего экспорта?

Пятый — доказательства для тенанта: получили ли пострадавшие клиенты достаточно журналов, доказательств доступа к объектам и рекомендаций, чтобы определить, что запрашивалось и были ли раскрыты секреты?

Шестой — гигиена секретов: хранили ли клиенты пароли, ключи API, облачные токены или VPN-учётные данные в записях Salesforce и ротировали ли они их после раскрытия?

Седьмой — публичная коммуникация: сохранили ли уведомления важное различие — что ядро Salesforce не было эксплуатировано, но при этом ясно говорилось, что к данным клиентов Salesforce получали доступ через доверенные токены приложений?

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