Утечки персональных данных при онлайн-платежах: статистика и масштаб угроз

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

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

Масштабы компрометации в мировом и российском ритейле

Российские оценки показывают высокую долю торговли среди инцидентов с данными. На ритейл, маркетплейсы и интернет-магазины приходится более четверти всех утечек информации и свыше трети зарегистрированных инцидентов с компрометацией персональных данных. Более половины случаев в отрасли связаны с онлайн-торговлей. По данным сервиса разведки утечек DLBI, доля электронной коммерции составляла 39–40% от общего числа зафиксированных инцидентов с данными российских пользователей.

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

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

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

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

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

Структура похищенных сведений: почему учётные записи ценнее реквизитов

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

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

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

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

Полные реквизиты карты и учётные данные магазина при этом требуют разного подхода к защите. Стандарт PCI DSS запрещает хранить код проверки карты CVV/CVC после авторизации. Это не значит, что данные карты вообще невозможно перехватить, и не гарантирует, что любой магазин соблюдает требования без нарушений. Реквизиты могут оказаться под угрозой при подмене платёжной страницы, атаке на сайт или компрометации другого компонента платёжной цепочки.

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

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

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

Экономика инцидентов: стоимость ликвидации и жизненный цикл угроз

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

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

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

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

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

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

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

Регуляторные требования и сроки уведомления

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

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

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

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

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

Что может сделать пользователь

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

• Использовать уникальный пароль для каждого магазина и платёжного сервиса. Менеджер паролей помогает не переиспользовать одну и ту же комбинацию и хранить сложные пароли без попытки запомнить их все.
• Включить двухфакторную аутентификацию там, где она доступна. Приложение-аутентификатор или аппаратный ключ обычно устойчивее к фишингу, чем SMS-код, хотя ни один способ не отменяет внимательность при входе.
• Перед оплатой смотреть на адрес сайта и проверять, совпадает ли домен с ожидаемым. Значок замка говорит о защищённом соединении, но сам по себе не подтверждает, что сайт принадлежит нужному магазину.
• Для покупок на площадках, которым пользователь пока не доверяет, рассмотреть виртуальную карту с отдельным лимитом. Она не защищает от фишинга и не заменяет проверку сайта, но может ограничить последствия компрометации реквизитов.
• Относиться к письмам и сообщениям о заказах как к неподтверждённым, даже если в них есть имя, телефон или сведения о недавней покупке. Вместо перехода по ссылке можно открыть сайт магазина привычным способом и проверить состояние заказа там.
• Если пароль оказался в утёкшей базе, сменить его на соответствующем сервисе. Если та же комбинация использовалась где-то ещё, заменить её и на этих площадках, начиная с почты и финансовых аккаунтов.

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

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