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

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

Оценка InfoWatch за 2024 год еще выше: 1,581 млрд записей против 1,202 млрд годом ранее. Эти показатели нельзя напрямую свести в одну шкалу: у источников разные подходы к учету и разные массивы данных. Они показывают общий масштаб проблемы, но сами по себе не объясняют, сколько инцидентов осталось неизвестным и какова вероятность утечки для конкретного человека.

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

Масштабы компрометации: статистика Роскомнадзора и InfoWatch

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

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

Числа Роскомнадзора и InfoWatch описывают масштаб проблемы с разных сторон. Их полезно читать рядом, но не складывать в одну статистическую историю.

Positive Technologies приводит другой показатель: утечка конфиденциальной информации становилась прямым следствием от 52% до 54% успешных кибератак на коммерческие и государственные организации. Это не означает, что остальные атаки обязательно заканчиваются шифрованием или DDoS. У одного инцидента могут быть разные последствия, а доступная статистика не задает универсального сценария для каждой успешной атаки.

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

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

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

Централизация данных увеличивает возможный ущерб

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

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

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

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

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

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

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

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

Внешние векторы: фишинг и уязвимости веб-сервисов

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

Фишинг учетных записей

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

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

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

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

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

Уязвимости публичных приложений и API

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

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

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

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

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

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

Инсайдеры: умышленные и случайные действия

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

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

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

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

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

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

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

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

Ритейл и e-commerce: почему сектор торговли заметен в статистике

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

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

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

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

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

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

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

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

Что меняет статистика для компаний и пользователей

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

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

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

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

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

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

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

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