В январе 2024 года из одной российской организации утекло 500 млн записей. Роскомнадзор подтвердил факт, но ни название компании, ни вектор компрометации до сих пор не раскрыты. Один инцидент - больше трети всего годового объёма. За три года (2023–2025) из российских компаний суммарно ушло 4,5 млрд записей персональных данных - это данные исследования ЭАЦ ГК InfoWatch «Россия: утечки информации ограниченного доступа, 2024–2025».
Для инженера ИБ цифра означает конкретную вещь: у большинства операторов ПДн detection и response не соответствуют реальным угрозам. А с мая 2025 года за это прилетает оборотный штраф. Не 60 тысяч рублей - а процент от выручки.
Статистика утечек персональных данных Россия 2023–2025: что стоит за цифрами
За 2025 год из российских организаций утекло 1,581 млрд записей - рост более 30% по сравнению с 2024 годом (1,202 млрд записей), согласно исследованию ЭАЦ ГК InfoWatch. Число зарегистрированных инцидентов при этом почти стабильно: 592 утечки ПДн в 2024 году против 569 в 2023-м.Расхождение между стабильным числом инцидентов и взрывным ростом объёма записей говорит о простом: инциденты стали масштабнее. Один мегаслив перекрывает сотню мелких утечек.
Отраслевое распределение и типы скомпрометированных данных
По данным InfoWatch, 74% утечек - персональные данные, 32,3% - коммерческая тайна. Отраслевая картина за 2024 год:| Отрасль | Доля утечек информации | Доля утечек ПДн |
|---|---|---|
| Торговля и ритейл | 27,8% | 35,1% |
| Промышленность | 5,5% (рост с 3,7%) | - |
| Финансы, госсектор, IT | Снижение | Снижение |
Почти треть скомпрометированных записей - аутентификационная информация: логины, пароли, номера телефонов, email-адреса. Эти данные моментально уходят в credential stuffing. InfoWatch также фиксирует рост случайных утечек через облачные хранилища до 10%.
В 48,3% случаев утечек ПДн за 2025 год не удалось установить точное количество скомпрометированных записей. Реальный масштаб компрометации персональных данных, скорее всего, значительно больше публичных цифр.
Глобальный контекст: Россия на фоне мировой статистики
По данным Surfshark за Q1 2024 (требует верификации по первоисточнику), Россия предположительно лидировала с 33,5 млн скомпрометированных аккаунтов за квартал. В World Cybercrime Index (PLOS ONE, апрель 2024, Bruce, Lusthaus, Kemp et al.) Россия - на первом месте среди стран-источников киберпреступности.Для калибровки: по IBM Cost of a Data Breach Report 2024, средний глобальный ущерб от одной утечки - $4,88 млн. Среднее время обнаружения - порядка 194 дней, сдерживания - около 64 дней, итого жизненный цикл инцидента - около 258 дней. Организации с AI-автоматизацией ИБ, по оценкам IBM, экономили в среднем $1,9 млн на инциденте (данные за 2024 год; цифры отчёта 2025 года могут отличаться). Без AI и автоматизации средний ущерб, предположительно, оставался значительно выше.
По Verizon DBIR 2025: 68% утечек включают человеческий фактор (ошибки, социальную инженерию, злоупотребление доступом), а 44% всех утечек связаны с ransomware - рост с 32% годом ранее. По оценкам IBM (2025), около 30% утечек связаны с третьими сторонами - значительно больше, чем годом ранее.
Штрафы за утечки данных Роскомнадзор: оборотные штрафы и уголовная ответственность
Что изменил 420-ФЗ для операторов персональных данных
До 420-ФЗ штрафы были смешными. В 2025 году шесть организаций получили штрафы на общую сумму 570 тыс. рублей: РЖД и «Почта России» - по 150 тыс., ещё четыре компании - от 60 до 75 тыс. по ст. 13.11 КоАП. Такие суммы спокойно закладывались в бюджет как операционные расходы - дешевле, чем один инженер ИБ в штате.С 30 мая 2025 года (Федеральный закон от 30.11.2024 №420-ФЗ) шкала ответственности по КоАП 13.11 изменилась принципиально:
- Фиксированные штрафы - от 3 до 15 млн руб. в зависимости от объёма и категории скомпрометированных данных.
- За повторное нарушение - оборотный штраф от 1% до 3% совокупной суммы выручки за календарный год, предшествующий году выявления правонарушения, но не менее 25 млн и не более 500 млн руб.
Уголовная ответственность: статья 272.1 УК РФ
С 11 декабря 2024 года УК РФ дополнен статьёй 272.1 (Федеральный закон от 30.11.2024 №421-ФЗ) - ответственность за незаконные использование и (или) передачу, сбор и (или) хранение компьютерной информации, содержащей персональные данные, полученной незаконным путём. Максимальная санкция - до 10 лет лишения свободы со штрафом.Уведомление об утечке Роскомнадзор: сроки
Оператор обязан:- В течение 24 часов после обнаружения утечки - первичное уведомление в Роскомнадзор.
- В течение 72 часов - провести внутреннее расследование и направить развёрнутый отчёт: причины, меры устранения, оценка вреда, сведения об ответственных.
Как данные утекают: TTPs атакующих и insider threat
Три основных вектора компрометации
На основе анализа публичных инцидентов 2023–2025 годов и статистики InfoWatch выделяются три устойчивых вектора нарушения конфиденциальности данных.Внешняя атака через веб-приложение. Основная мишень - небольшие интернет-магазины и сервисы с базовым уровнем ИБ. Kill chain: разведка внешнего периметра (Shodan, поиск открытых портов) → эксплуатация уязвимости в CMS или API (SQLi, RCE) → дамп базы данных → публикация или продажа на даркнет-форумах. Ритейл занимает 35,1% инцидентов с ПДн именно из-за низкого порога входа для атакующего. Условный интернет-магазин на битом WordPress - это не «если сломают», а «когда».
Инсайдерская угроза (insider threat). По данным InfoWatch, около трети мировых штрафов за утечки назначены за случайные внутренние нарушения: незащищённый сервер с базой данных, потеря носителя, неправильная рассылка. Но есть и умышленные сливы. Кейс начала 2025 года: трое сотрудников ФНС в Новосибирске продали данные более 40 тыс. юридических лиц и ИП за 150 тыс. рублей. Привилегированный доступ, финансовая мотивация, нулевой мониторинг - классический insider threat. 150 тысяч за 40 тысяч записей. Цена вопроса - меньше, чем месячная зарплата.
Компрометация через подрядчика. IBM (2025) фиксирует: 30% утечек связаны с третьими сторонами. В российской судебной практике Верховный Суд в 2026 году закрепил позицию: утечка у подрядчика не снимает ответственности с оператора. Оператор обязан доказать, что контролировал защиту персональных данных у подрядчика и принимал реальные технические меры. Формулировка «мы передали данные, и они утекли не у нас» - больше не работает.
Kill chain утечки и точки детекции
В терминах MITRE ATT&CK эксфильтрация данных - финальный этап, но точки для срабатывания detection-правил распределены по всей цепочке:| Этап | Тактика | Что детектирует SOC |
|---|---|---|
| Разведка | Reconnaissance | Сканирование портов, fingerprinting CMS |
| Начальный доступ | Initial Access | Аномальные запросы к API, попытки SQLi, brute-force |
| Закрепление | Persistence | Web shell, новые учётные записи в БД |
| Сбор данных | Collection | Массовые SELECT к таблицам с ПДн, аномальная частота API-вызовов |
| Эксфильтрация | Exfiltration | Аномальный исходящий трафик, передача архивов на внешние хосты |
258 дней среднего жизненного цикла инцидента (по оценкам IBM) - это сотни возможностей для детекции. Вопрос не в том, есть ли шанс поймать - вопрос в том, настроены ли правила корреляции на каждом этапе. В большинстве случаев, по моему опыту, - нет.
Detection утечек данных в SIEM: правила корреляции для защиты от утечек
Пример Sigma-правила для детекции массовой выгрузки вне рабочего времени (пример для демонстрации концепции;
event.hour - не стандартное поле ECS/Sigma, определение нерабочих часов лучше реализовать через функции работы со временем на стороне SIEM backend):
YAML:
title: Bulk data export outside business hours
status: experimental
logsource:
product: database
service: audit
detection:
selection:
event.action|contains:
- 'export'
- 'select_into_outfile'
- 'copy_to'
time_late:
event.hour|gte: 20
time_early:
event.hour|lte: 6
condition: selection AND (time_late OR time_early)
level: highSELECT INTO OUTFILE». Но у него есть ограничение: если инсайдер выгружает данные через легитимный отчёт в рабочее время, но аномальным объёмом - нужен baseline по объёму, а не по времени. Два правила в связке работают лучше, чем одно.Мониторинг облачных хранилищ
Рост случайных утечек через облака (до 10% по InfoWatch) требует отдельного трека мониторинга. Типичный сценарий: бакет с данными клиентов (S3, MinIO, Yandex Object Storage) настроен с публичным доступом. Детекция:- Регулярная проверка IAM-политик на наличие
"Principal": "*"- контроль идентификации и доступа (PR.AA-01 по NIST CSF 2.0) - Мониторинг изменений ACL бакетов через CloudTrail или аналог
- Автоматизированные сканы конфигурации с помощью
s3scannerили встроенных инструментов облачного провайдера
Incident response при утечке данных: чеклист для SOC и IR-команды
По данным экспертов TAdviser (март 2026), главная ошибка компаний - неподготовленность. Нет регламента, нет распределения ролей, нет процедуры фиксации цифровых следов. Когда прилетает алерт - начинается хаос. Ниже - чеклист, который можно передать в SOC или включить в IR-playbook.Первые 24 часа
- Изолировать скомпрометированную систему от сети. НЕ выключать - сохранить содержимое RAM для форензики.
- Снять дамп памяти, скопировать логи (веб-сервер, СУБД, SIEM), зафиксировать timestamp обнаружения.
- Определить scope: какие таблицы, какие субъекты ПДн, какой объём записей.
- Назначить ответственного за расследование с полномочиями запрашивать логи, ограничивать доступ, привлекать внешних экспертов.
- Направить первичное уведомление в Роскомнадзор (24-часовое окно).
72 часа: расследование и отчёт
- Установить вектор компрометации: SQLi, brute-force, инсайдер, скомпрометированный подрядчик.
- Оценить масштаб - точное или приблизительное число скомпрометированных записей.
- Задокументировать все принятые меры по прекращению утечки и предотвращению повторения.
- Направить развёрнутый отчёт в Роскомнадзор: причины, меры, оценка вреда, ответственные.
- Уведомить субъектов ПДн при наличии риска ущерба.
Критические ошибки, которые фиксируют суды
- Перекладывание ответственности на подрядчика - суды не снимают вину с оператора персональных данных.
- Нефиксированные доказательства - DLP-логи и журналы событий не оформлены для использования в суде.
- Разрыв между ИБ и юридическим отделом - процессуальные нарушения ведут к отказам суда или дополнительным штрафам.
- Занижение объёма - регулятор расценивает как отягчающее обстоятельство.
За три года работы с расследованиями утечек в российских компаниях я вижу устойчивый паттерн: DLP стоит, но правила не обновлялись два года. SIEM собирает логи, но аудит на уровне СУБД не включён - массовый
SELECT на 500 тыс. строк уходит незамеченным. Оборотные штрафы от 1% до 3% выручки наконец заставляют бизнес обратить внимание на ИБ, но штраф приходит после утечки, а baseline и detection-правила нужны до.Самый недооценённый вектор - insider threat. Кейс с сотрудниками ФНС - не аномалия, а системная проблема: привилегированные пользователи с прямым доступом к БД, нулевой мониторинг нерабочих часов, отсутствие baseline по объёмам выгрузок. Пока SOC фокусируется на внешнем периметре, данные уходят через легитимные каналы экспорта.
В 2026 году число штрафов вырастет кратно - не из-за увеличения инцидентов, а из-за накопления судебной практики по 420-ФЗ. Кто сейчас не включит аудит СУБД, не настроит корреляцию DLP-событий с SIEM и не отработает IR-playbook на tabletop-учениях - заплатит дважды: штраф регулятору и стоимость реагирования в режиме паники. Если настраиваете связку DLP + SIEM для детекции инсайдерских выгрузок или обкатываете IR-playbook под требования 420-ФЗ - на codeby.net коллеги разбирают конкретные Sigma-правила и грабли интеграции российских DLP с разными SIEM-стеками в профильном треде.
