Опубликовано: 26.09.2026 | Источник: SecurityLab (RSS)

**Семантический анализ** | Элемент | Значения | |---|---| | **Primary keyword** | мониторинг даркнета в ВКР / Google Threat Intelligence в дипломе | | **LSI-запросы** | threat intelligence, утечки учётных данных, OSINT-разведка, STIX/TAXII, MITRE ATT&CK, Kafka, Elasticsearch, SIEM, NLP-классификация текста, риск-скоринг | | **Вопросы студентов** | «Нужно ли реально собирать данные из даркнета?», «Как измерить эффективность системы мониторинга?», «Где брать тестовый датасет утечек?», «Обязательно ли писать код для такой темы?», «Как оформить архитектуру по ГОСТ?» | | **Ключевые сущности** | ГОСТ 34.602-89, ГОСТ 19.701-90, ISO/IEC 25010, Kubernetes, OpenTelemetry, CI/CD-пайплайн, Elastic Stack, Apache Kafka | ---

Анализ даркнет-мониторинга для ВКР: архитектура Threat Intelligence и метрики эффективности

В марте 2026 года Google вывел на рынок инструмент Google Threat Intelligence, который автоматически сканирует и анализирует около 10 млн публикаций в даркнете, пытаясь предупредить владельца учётных данных раньше, чем ими воспользуются злоумышленники. Для выпускника ИТ-направления это не просто новость — это готовый каркас темы диплома. Задача «собирать, нормализовать и оценивать риск утечки» включает сбор данных, потоковую обработку, NLP-классификацию, визуализацию и расчёт метрик. Всё это покрывается стандартными главами ВКР: анализ, проектирование, тестирование. Ниже — как разложить такой проект на разделы, чтобы комиссия увидела инженерное решение, а не пересказ пресс-релиза.

Три темы ВКР, которые вырастают из этой новости

Тема 1. Система автоматизированного мониторинга утечек учётных данных на основе потоковой обработки

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

• Цель: разработать прототип системы, которая собирает публикации из открытых источников, выявляет упоминания учётных данных и присваивает им уровень риска.
• Задачи: обзор методов threat intelligence; проектирование конвейера «сбор → нормализация → обогащение → скоринг»; реализация модуля классификации; нагрузочное тестирование.
• Структура: Глава 1 — анализ рынка и подходов (включая кейс Google из статьи); Глава 2 — архитектура и схемы; Глава 3 — тестирование, метрики, оценка экономии.

Тема 2. Оценка риска утечки данных методом риск-скоринга и её автоматизация

Актуальность. Новость подчёркивает «раньше остальных» — то есть ценность не в факте утечки, а во времени реакции. Это отличная рамка для исследования метрик.

• Цель: построить модель расчёта риска и проверить её на исторических инцидентах.
• Задачи: выбор признаков; формализация шкалы; реализация сервиса скоринга; сравнение с базовой экспертной оценкой.
• Структура: теория риска → проектирование модели и API → верификация на датасете.

Тема 3. Интеграция модуля мониторинга утечек в корпоративный SIEM-контур

Актуальность. Автоматизация Google бесполезна в вакууме: результат должен попадать в существующие процессы реагирования. Здесь уместно говорить о STIX/TAXII и форматах обмена.

• Цель: спроектировать интеграционный слой, передающий инциденты в SIEM и систему тикетов.
• Задачи: анализ протоколов обмена; проектирование коннекторов; развёртывание в Kubernetes; расчёт RTO/RPO.
• Структура: стандарты обмена → архитектура интеграции → отказоустойчивость и эксплуатация.

Аналитическая глава: как превратить новость в обоснование выбора

Самая частая слабость первого раздела — обзор ради обзора. Сделайте его спорным. Сравните три класса решений: коммерческие платформы (Google Threat Intelligence, аналоги), open-source-стеки (Elastic Stack, MISP, TheHive) и самописные скрипты на Python. Критерии берите из ISO/IEC 25010: функциональная полнота, производительность, сопровождаемость, безопасность.

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

Проектная часть: схемы, которые ждёт комиссия

Конвейер обработки

Классическая композиция: агенты сбора → брокер сообщений → нормализатор → модуль обогащения → хранилище → сервис скоринга → API и веб-интерфейс. Брокер (Kafka или Redpanda) снимает пиковые нагрузки, когда источник отдаёт burst-поток. Хранилище делится на «горячее» (Elasticsearch, поиск по инцидентам) и «холодное» (S3-совместимое, архив сырых публикаций).

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

{
  "source": "forum_x",
  "collected_at": "2026-03-25T10:14:00Z",
  "leak_type": "credentials",
  "domain": "example.ru",
  "records_count": 15234,
  "confidence": 0.87,
  "risk_score": 74
}

Развёртывание и воспроизводимость

Современная комиссия ценит не «у меня работает на ноутбуке», а воспроизводимость. Опишите Helm-чарты или docker-compose, конфигурацию в Git, CI/CD-пайплайн со стадиями lint → test → build → deploy в тестовый контур. Это тот пункт, где ВКР на заказ часто проваливается, потому что исполнитель экономит на инфраструктурной части. Не повторяйте эту ошибку.

Тестирование и метрики: где большинство работ теряет баллы

Формулировка «система работает корректно» недопустима. Нужны числа. Соберите их минимум по четырём группам.

• Производительность: пропускная способность (публикаций в секунду), p95 и p99 времени обработки одной записи, потребление памяти при пиковой нагрузке.
• Качество классификации: precision, recall, F1 по размеченной выборке; отдельно — доля ложных срабатываний, потому что аналитик не должен тонуть в шуме.
• Надёжность: RTO и RPO при отказе брокера и хранилища, поведение при потере соединения с источником.
• Экономика: стоимость обработки одной публикации, сравнение с подпиской на коммерческий сервис за год.

Инструментарий: нагрузочный генератор (k6, Locust), сбор телеметрии через OpenTelemetry, дашборды в Grafana. Ссылайтесь на статью как на отраслевой ориентир по масштабу: если Google обрабатывает миллионы публикаций, ваш прототип должен как минимум показать линейное масштабирование при добавлении потребителей.

Чему вы реально научитесь на такой теме

• Проектировать потоковые конвейеры данных и обосновывать выбор брокера сообщений.
• Формализовывать требования по ГОСТ и переводить их в архитектурные решения.
• Настраивать наблюдаемость: метрики, логи, трассировки через единый стандарт телеметрии.
• Считать экономику внедрения — навык, который отличает инженера от кодера.
• Защищать технические компромиссы: почему именно эта СУБД, именно такой формат обмена, именно такая модель риска.

Частые вопросы студентов

Неужели придётся реально лезть в даркнет за данными?

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

Обязательно ли писать код, если тема аналитическая?

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

Как оформить диаграммы архитектуры?

Используйте нотацию C4 (уровни контекста и контейнеров) либо UML-диаграммы компонентов по ГОСТ 19.701-90. Каждая схема должна иметь подпись, ссылку в тексте и объяснение принятых решений. Схема без пояснения — просто картинка.

Где брать данные для тестирования?

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

Источник: Ваши данные уже могут продаваться в даркнете. Google предлагает узнать об этом первыми — автоматически (опубликовано 2026-03-25)