Вопросы защиты персональных данных: утечки в цифрах

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

За период 2023–2025 годов в России было скомпрометировано порядка 4,5 млрд записей персональных данных. В мировом масштабе за тот же период речь идет более чем о 100 млрд записей. Эти цифры не описывают число уникальных людей: одна и та же запись могла попасть в несколько баз, а разные источники могли учитывать один инцидент по разным методикам. Но масштаб они показывают точно: вопросы защиты персональных данных давно вышли за пределы настройки приватности в одном приложении.

Снижение числа инцидентов не означает, что данных стало утекать меньше. В 2025 году рынок увидел обратное: атак стало меньше на бумаге, а массивы скомпрометированной информации — крупнее.

Масштаб цифровой компрометации: от 457 млн до 1,8 петабайта

Статистика утечек персональных данных состоит из нескольких разных измерений. Одни исследователи считают строки в опубликованных базах, другие — общий объем файлов, третьи — подтвержденные инциденты организаций. Поэтому 767 млн строк у одного аналитического центра и 1,76–1,8 петабайта данных у другого нельзя механически складывать. Это показатели разных срезов одного рынка.

Компания F6 оценила объем утечек данных российских пользователей в базах даркнета и Telegram в 2025 году в 767 млн строк. В 2024 году показатель составлял 457 млн строк. Рост — примерно на две трети, хотя количество зарегистрированных инцидентов сократилось с 455 до 230.

«Солар» использует другую единицу измерения — объем данных, утекших из российских организаций. В 2025 году он достиг 1,76–1,8 петабайта, что примерно в 17 раз больше уровня 2023 года. Петабайт — это не количество людей и не число записей, а объем цифровой информации. В него могут входить таблицы, резервные копии, документы, логи, фотографии, выгрузки из CRM и другие файлы.

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

Средний объем утечки в 2025 году составил 3,27 млн записей — на 25,8% больше, чем годом ранее. Это важнее, чем само снижение количества событий. Средний показатель отражает изменение экономики атаки: злоумышленнику все чаще выгоднее получить доступ к одному крупному хранилищу или резервной копии, чем собирать небольшие массивы из множества слабозащищенных сервисов.

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

Почему меньше инцидентов не означает больше безопасности

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

В 2025 году сокращение числа инцидентов сопровождалось ростом объема баз. Здесь работают сразу несколько механизмов.

Укрупнение баз

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

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

Повторная публикация старых данных

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

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

Переход в закрытые каналы

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

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

Автоматизация атак

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

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

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

Ритейл и коммерческая тайна: почему ценность утечки выше числа строк

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

В типичной инфраструктуре торговой компании могут находиться:

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

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

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

Отдельный слой риска — коммерческая тайна. По статистике InfoWatch, персональные данные составляют около 74% всех утечек конфиденциальной информации, а коммерческая тайна присутствует в 32,3% случаев. Эти категории пересекаются, но не совпадают.

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

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

Нужны разные уровни защиты:

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

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

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

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

5. Контроль выгрузок. Необычный экспорт большого числа записей должен фиксироваться и требовать дополнительного подтверждения.

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

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

Новые реалии ответственности: штраф зависит от масштаба

С 30 мая 2025 года в КоАП РФ действуют изменения, связывающие ответственность за утечки персональных данных с количеством пострадавших субъектов и наличием повторного нарушения. Для юридических лиц максимальный штраф при утечке более 100 тыс. субъектов или 1 млн идентификаторов может достигать 15 млн рублей.

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

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

За первое полугодие 2026 года российские суды назначили административные штрафы за утечки персональных данных на общую сумму 2 195 000 рублей; зарегистрировано 35 штрафов. Эта сумма превысила показатель за весь 2025 год. Само по себе увеличение штрафов не доказывает, что организации стали защищать данные хуже. Оно показывает, что регуляторная практика становится заметнее и быстрее превращается в финансовый фактор.

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

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

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

Что скрыто за цифрами Роскомнадзора и публичных баз

В январе 2024 года произошла крупнейшая подтвержденная утечка из одной российской организации — около 500 млн записей персональных данных. Название организации и точный вектор компрометации официально не раскрывались. Этот пример показателен не только размером.

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

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

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

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

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

Практический минимум для пользователя выглядит так:

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

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

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

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

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

6. Разделять рабочие и личные учетные записи. Это снижает последствия компрометации одного устройства или почтового адреса.

7. Осторожно использовать ИИ-сервисы. Документы с паспортными данными, договорами, медицинской информацией и внутренней перепиской не следует загружать в модель без понимания условий хранения и обработки.

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

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

Вопросы защиты персональных данных: где меняется реальный риск

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

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

Наиболее уязвимы системы, где:

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

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

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

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

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

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

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

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

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