Найти и обезвредить: зачем искать утечки данных своей компании в даркнете

За последние три года хакеры похитили в России свыше 4,5 млрд записей персональных данных. Часто записи перепродают на теневых площадках — как следствие, у компаний даже появилась специальная практика по отслеживанию даркнета. Рассказываем, какие схемы чаще всего используют для взлома и почему мониторинг утечек — не единственный выход.

Как устроен рынок данных в даркнете

На чёрном рынке данные — такой же товар, как и любой другой. Здесь продают логины и пароли, целые клиентские базы, платёжные данные и доступы к системам — включая внутренние CRM компаний. Отдельно выделяют так называемые combo lists — огромные списки пар «логин–пароль», собранные из разных утечек.

Чёрный рынок не ограничивается «классическим даркнетом» и Tor-форумами: на файлообменниках могут выкладывать «пробники», ва Telegram-каналах — анонсы новых «сливов». Наиболее высоко ценятся свежие данные, которые ранее не публиковались — а значит, ими еще никто не успел воспользоваться. На цену также влияют полнота данных и, в случае систем, уровень доступа (user vs admin).

Самые критичные и дорогие позиции:

• Сканы документов: паспорта, удостоверения личности и фотографии с ними. Многие сервисы (банки, финтех, криптоплатформы) используют KYC-проверки, где достаточно загрузить фото документа. Если у злоумышленника уже есть этот файл, он проходит половину пути.
• Авторизационные данные: пары «логин–пароль» и сведения для входа в государственные системы (СНИЛС, номера телефонов).
  ● Корпоративные секреты: базы клиентов, исходный код и внутренняя документация.

Иногда данные продают не только хакеры, но и сами сотрудники компаний. Еще существует понятие ransomware-as-a-service (RaaS) — взлом системы компании через вредоносное ПО или с использованием ранее украденных ключей доступа. Данные копируются и шифруются, после чего компания получает требование выкупа. Нет выкупа — данные уходят дальше и продаются в даркнете. Именно эта модель стала причиной взрывного роста угроз: за 2025 год число RaaS-атак по всему миру выросло на 45%. Другое название техники — LOTL (Living off the Land). Такая атака выглядит как обычная работа администратора, и антивирус ее просто не видит.

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

Как правильно мониторить утечки

В последние пять лет мониторинг даркнета стал частью стратегии безопасности крупных компаний. В марте Google даже выпустил решение на базе Gemini, которое автоматически отслеживает даркнет и упоминания компании в нём. Часто этим занимаются внутренние специалисты по ИБ, иногда компании подключают сервисы, у которых уже есть доступ к закрытым базам. В мире эта практика называется: Dark Web Threat Intelligence — разведка угроз в даркнете.

Для поиска используют ключевые индикаторы: домен компании (в том числе как часть корпоративных e-mail-адресов), бренды и названия продуктов, IP-адреса и домены инфраструктуры, упоминания топ-менеджмента.

Важный момент: поиск вручную почти не работает. Да, теоретически ИБ-специалисты могут читать Tor-форумы и каналы в Telegram, но на практике закрытые сообщества не пускают всех подряд, объем данных колоссальный, а пропустить важный сигнал очень легко. К тому же не всё попадает в даркнет: часть данных продаётся в узком кругу или вовсе используется без публикации.

Типы рисков, которые можно выявить с помощью мониторинга даркнета, включают:

• утечки у третьих сторон;
• публикации данных на хакерских форумах и в криминальных чатах;
• утечки через P2P-сети;
• случайные утечки;
• неправомерное использование бренда;
• выдачу себя за компанию (impersonation);
• подмену доменов (domain spoofing).

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

Важно помнить, что мониторинг даркнета — реактивная мера. Она помогает «потушить пожар», когда утечка уже произошла, но редко предотвращает её.

Откуда утекают данные и как себя обезопасить

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

Классическая проблема — устаревшая инфраструктура и небезопасное хранение учётных данных. Показательный пример — инцидент компании «Аэрофлот» в 2025 году: злоумышленники получили удаленный доступ с правами администратора к инфраструктуре авиакомпании и инициировали массовое удаление данных на рабочих станциях — всего было затронуто около 10 тысяч компьютеров. Такие кейсы хорошо показывают, что проблема — не только в атаках, но и в архитектуре хранения и доступа к данным.

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

Главная идея в том, что данные остаются пригодными для работы, но перестают быть чувствительными. При этом корректное обезличивание — такое, при котором исходные данные невозможно восстановить — является прямым требованием Роскомнадзора (приказ №140).

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

Как обезличивание защищает базы от копирования

Есть два ключевых сценария, где деперсонализация особенно эффективна.

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

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

Второй сценарий — разграничение доступа внутри продакшна. Например, HR должен видеть полные данные сотрудников, а аналитик — только агрегированную или частично скрытую информацию. Маскирование позволяет показывать разным ролям разные представления одних и тех же данных: где-то скрывать часть строки («jo***@mail.com»), где-то полностью подменять значения.

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

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

Почему маскирование данных внедряется медленно

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

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

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

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

Альтернативой могут быть синтетические данные — полностью сгенерированные с нуля. Они безопаснее, но их создание — это отдельный сложный проект: необходимо моделировать поведение пользователей, бизнес-логику и зависимости. Это долго, дорого и требует экспертизы, которой у многих команд нет.

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

Какие еще превентивные меры работают

• Всё начинается с базового принципа: хранить только необходимые данные. Чем меньше информации компания собирает (и удаляет лишнее), тем ниже ущерб при компрометации.
• Не менее важен строгий контроль доступа. Большая часть утечек происходит не из-за внешнего взлома, а из-за избыточных прав внутри компании — когда сотрудники или подрядчики получают доступ к данным, который им не нужен для работы.
• Следующий слой — обезличивание и шифрование. В тестовых и аналитических средах не должно быть реальных персональных данных. Даже при наличии всех этих мер данные должны быть криптографией.
• Отдельное внимание стоит уделять своевременным обновлениям систем — многие атаки используют давно известные уязвимости.
• Не стоит недооценивать и человеческий фактор: фишинг остаётся одной из главных точек входа, поэтому обучение сотрудников напрямую влияет на уровень безопасности.
• Наконец, важна готовность к инцидентам: наличие резервных копий и понятного плана реагирования позволяет снизить последствия, если утечка всё же произошла.

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

Автор: владелец продукта «Датасан» Василий Жидков, компания «Перфоманс Лаб».