В оптовой торговле число компрометаций данных выросло на 43%

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

Векторы, которые в статистике выше отмечены как фишинг, смишинг и компрометация деловой переписки (12,5% кибератак), на практике не абстракция. На крупных маркетплейсах неоднократно фиксировались случаи, когда продавцам приходило сообщение в мессенджере — канале, которому селлеры доверяют, поскольку через него часто идет официальная коммуникация от площадки — со ссылкой на сайт-клон, внешне неотличимый от настоящего портала продавцов. Введя логин и подтвердив вход кодом из SMS или push-уведомления, продавец сам передавал доступ мошенникам, которые затем выводили деньги с баланса и распродавали чужой товарный остаток по демпинговым ценам.

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

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

Оптовая компания занимает промежуточное положение между производителем, перевозчиком, складским оператором, розничной сетью и конечным корпоративным заказчиком. Через ее информационные системы проходят сведения о поставках, ценах, объемах закупки, остатках, маршрутах, контрагентах и условиях расчетов. В одной инфраструктуре часто объединены ERP, WMS, TMS, CRM, электронный документооборот, личные кабинеты партнеров и интеграции с маркетплейсами. Для злоумышленника такой контур ценен не только объемом данных. Полученный доступ позволяет вмешиваться в реальные хозяйственные операции, менять реквизиты в документах, перенаправлять платежи, создавать фиктивные заказы или использовать доверенные каналы связи для атак на партнеров.

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

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

В общей структуре зарегистрированных компрометаций 69,7% связаны с кибератаками. Среди раскрытых векторов на фишинг, смишинг и компрометацию деловой переписки приходится 12,5% кибератак, на программы-вымогатели – 6,1%, на атаки с использованием украденных или скомпрометированных учетных данных – 0,9%, на вредоносное ПО – 0,8%, на подстановку учетных данных (credential stuffing) – 0,7%, на эксплуатацию уязвимостей нулевого дня – около 1,1%. Точный способ проникновения не установлен или не раскрыт в 77,4% случаев, поэтому фактическое распределение может заметно отличаться от видимой статистики. Отдельно выделяются системные и человеческие ошибки, на которые приходится 6,9% всех событий, более половины таких инцидентов связаны с электронной почтой.

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

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

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

Снижать риск необходимо с инвентаризации связей, а не только серверов и рабочих станций. Компании требуется видеть все внешние кабинеты, интеграционные учетные записи, API, каналы электронного документооборота и права подрядчиков. Доступ партнеров следует ограничивать конкретными системами и сроками договора, а административные и сервисные аккаунты защищать многофакторной аутентификацией, отдельными секретами и контролем аномальной активности. Общие учетные записи необходимо исключить, поскольку они не позволяют установить, кто выполнил действие и откуда поступил запрос. Опыт крупных платформ добавляет к инвентаризации еще один пункт: нужно проверять не только права подрядчиков и сервисных аккаунтов, но и то, не связаны ли между собой разные роли одного пользователя через общий идентификатор – номер телефона, почту или единый механизм подтверждения входа. Если компрометация одной роли (покупателя, рядового сотрудника, гостевого доступа) автоматически открывает доступ к другой, более чувствительной роли (продавца, администратора, финансиста), это тот же класс риска, что и общие учетные записи, описанные выше. 

Финансовые операции требуют независимой проверки изменений реквизитов и нетипичных платежных поручений. Подтверждение по ранее согласованному каналу, разделение полномочий и лимиты на переводы снижают вероятность успешной BEC-атаки. Почтовые домены нужно защищать с помощью SPF, DKIM и DMARC, а сотрудников закупок, бухгалтерии и логистики обучать на сценариях, связанных с их реальной работой: счетами, накладными, уведомлениями перевозчиков и запросами контрагентов.

Для складских и учетных систем необходимы сегментация, централизованное журналирование и резервные копии, недоступные из основного домена. План восстановления должен проверяться на практике и учитывать потерю сразу нескольких связанных сервисов. В договоры с поставщиками программного обеспечения и логистическими подрядчиками следует включать сроки уведомления об инцидентах, требования к защите удаленного доступа и порядок экстренного отзыва учетных записей. Рост компрометаций на 43,5% – точка на растущей кривой: пока ERP, WMS и почта оптовиков живут в одном слабо контролируемом контуре, каждый следующий взлом одной компании по инерции станет чужой проблемой — производителя, перевозчика или розничной сети, которые узнают об этом не из отчета по безопасности, а по звонку от партнера с испорченным счетом. Опыт крупных маркетплейсов показывает и обратную сторону: даже площадка с миллионами пользователей способна заметно снизить число взломов личных кабинетов не увеличением бюджета на безопасность вообще, а точечным устранением конкретной архитектурной слабости – разделением ролей покупателя и продавца в системе аутентификации. Для оптовой торговли это главный практический вывод: искать нужно не абстрактные «уязвимости», а конкретные точки, где одна скомпрометированная роль тихо открывает доступ к другой.