Утечки персональных данных: почему растут масштабы и частота инцидентов

Это история о том, что отдельные инциденты могут затрагивать огромные массивы данных.

InfoWatch приводит другую статистическую серию: 592 инцидента с персональными данными и 1,58 млрд скомпрометированных записей за 2024 год против 1,2 млрд записей годом ранее. Разница между оценками объясняется тем, что источники ведут независимый учёт и используют собственные подходы. Их цифры нельзя складывать или считать взаимозаменяемыми.

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

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

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

Масштаб растёт быстрее числа подтверждённых утечек

Статистика Роскомнадзора и InfoWatch описывает разные массивы наблюдений. Её полезно читать рядом, но не смешивать в одну общую оценку.

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

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

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

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

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

Big Data концентрирует риск

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

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

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

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

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

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

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

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

Ритейл и маркетплейсы в структуре утечек

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

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

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

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

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

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

Внешние атаки и внутренние нарушения

Оценки, приведённые в исходных данных, относят более 80% утечек к внешним кибератакам. На внутренние нарушения приходится около 18,5% инцидентов, причём 98% таких случаев названы умышленными. Эти показатели описывают конкретную статистику и не должны автоматически переноситься на любую компанию или год.

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

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

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

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

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

Зачем базы публикуют в открытом доступе

По оценке F6 за 2024–2025 годы, значительная часть баз публиковалась злоумышленниками открыто и бесплатно, в том числе в Telegram-каналах. Среди целей такой публикации назывались репутационный ущерб и дальнейшее использование данных для фишинга.

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

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

У опубликованных данных есть несколько потенциальных сценариев использования:

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

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

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

Что следует из статистики для защиты

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

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

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

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

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

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

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

Масштаб отдельного инцидента важнее эффектной версии

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

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

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