Опубликовано: 22.09.2026 | Источник: CNews (новости)

Кибербезопасность в ВКР: как тренд закупок ПО превратить в защищаемый диплом

Свежие данные аналитиков фиксируют устойчивый сдвиг: каждый третий тендер на закупку программного обеспечения в России так или иначе касается кибербезопасности. Компании перестают покупать «защиту вообще» и переходят к целевым проектам — SIEM-контуры, средства защиты конечных точек, контроль доступа, аудит подрядчиков. Для выпускника ИТ-специальности это не абстрактная новость, а готовый каркас для практической части работы. Тема перестала быть «про культуру безопасности» и стала инженерной: есть архитектура, метрики, бюджет, сроки внедрения.

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

Три темы ВКР, которые опираются на этот тренд

Тема 1. Проектирование SIEM-контура для распределённой инфраструктуры среднего бизнеса

Актуальность. Рост доли закупок в категории «специализированное ПО безопасности» означает, что заказчики массово внедряют системы сбора и корреляции событий. Значит, инженер, умеющий спроектировать такой контур и посчитать его стоимость владения, востребован прямо сейчас.

• Цель: разработать архитектуру SIEM-решения с обоснованным выбором компонентов и оценкой нагрузки.
• Задачи: классифицировать источники событий; выбрать модель нормализации логов; рассчитать объём хранения и пропускную способность; спроектировать правила корреляции под MITRE ATT&CK; оценить совокупную стоимость владения.
• Структура: Глава 1 — анализ угроз и обзор SIEM-платформ; Глава 2 — логическая и физическая архитектура, схемы потоков данных; Глава 3 — нагрузочное тестирование, расчёт TCO, внедрение.

Тема 2. Защищённый CI/CD-пайплайн: встраивание контроля безопасности в DevSecOps

Актуальность. Значительная часть тендеров связана с безопасностью разработки — сканеры кода, управление зависимостями, секретами. Тема автоматизации этих проверок напрямую бьётся с реальными закупками.

• Цель: спроектировать пайплайн, который блокирует релиз при критических уязвимостях без потери скорости поставки.
• Задачи: сравнить SAST/DAST/SCA-инструменты; определить точки встраивания проверок; описать политику контроля секретов; измерить влияние на время сборки.
• Структура: Глава 1 — модели угроз для цепочки поставки ПО; Глава 2 — архитектура пайплайна, схемы стадий; Глава 3 — метрики, тестовый прогон, экономика.

Тема 3. Мониторинг защищённости контейнерной платформы на базе Kubernetes

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

• Цель: построить систему наблюдаемости и контроля политик безопасности для кластера.
• Задачи: описать модель разграничения прав; настроить сбор телеметрии через OpenTelemetry; сформулировать сетевые политики; провести эксперимент по обнаружению аномалий.
• Структура: Глава 1 — анализ рисков оркестраторов; Глава 2 — проектирование контроля доступа и сетевых политик; Глава 3 — эксперимент, метрики обнаружения, оценка накладных расходов.

Аналитическая глава: сравнение решений и обоснование стека

Первая глава — то место, где студенты чаще всего теряют баллы. Вместо таблицы «продукт А круче продукта Б» нужна матрица критериев, привязанная к требованиям. Критерии берите из ISO/IEC 25010 (функциональная полнота, производительность, сопровождаемость) и добавляйте отраслевые: соответствие ГОСТ Р 57580, наличие сертификата ФСТЭК, поддержка MITRE ATT&CK, стоимость лицензии на узел.

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

Проектная часть: схемы, алгоритмы, интеграция

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

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

stages:
  - build
  - sast
  - sca
  - deploy

sast_scan:
  stage: sast
  script:
    - scanner --format sarif --output report.sarif
  rules:
    - if: $CI_COMMIT_BRANCH == "main"
      allow_failure: false

Такой фрагмент закрывает вопрос «а вы вообще код писали?» ещё до вопросов комиссии. Плюс он естественно ложится в раздел про автоматизацию контроля качества.

Тестирование и метрики: где брать цифры

Самый частый провал на защите — отсутствие измеримых результатов. Не пишите «система работает быстро». Пишите конкретно:

• Нагрузочные характеристики: событий в секунду на входе, задержка между появлением события и записью в индекс, объём хранения за сутки.
• Метрики обнаружения: доля истинно положительных срабатываний на подготовленном наборе атак (можно взять публичные сценарии MITRE ATT&CK в тестовом стенде).
• Доступность и восстановление: RTO и RPO для узла сбора и для хранилища — с обоснованием, почему именно такие значения.
• Накладные расходы: прирост времени сборки пайплайна после добавления сканеров, процент процессорного времени на агенте.

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

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

• Обосновывать выбор архитектуры, а не выбирать «что понравилось».
• Работать с нормативной базой: ГОСТ 34.602-89 для технического задания, ГОСТ Р 57580 для финансового сектора, ISO/IEC 27001 для системы управления.
• Строить схемы развёртывания, диаграммы последовательностей и компонентов так, чтобы они читались без пояснений автора.
• Считать метрики производительности и стоимости владения — навык, который напрямую переносится в работу.
• Оформлять техническую документацию по стандарту, а не «как получилось».

Вопросы, которые задают чаще всего

Обязательно ли писать работающий код в дипломе по безопасности?

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

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

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

Как оформлять UML-диаграммы и схемы архитектуры?

Единый нотацией на всю работу: либо UML, либо ГОСТ-овские схемы, но не смесь. Каждая диаграмма — со ссылкой в тексте и кратким пояснением. Не дублируйте одну и ту же схему в трёх главах в разных вариантах — это верный признак компиляции.

Насколько сложно сделать такую ВКР за один семестр?

Реально, если сузить область: не «защита предприятия», а, например, «контроль сетевых политик в кластере из десяти узлов». Узкая тема с глубокой проработкой всегда выигрывает у широкой и поверхностной.

Источник: Каждый третий тендер на ПО связан с кибербезопасностью (опубликовано 2026-03-25)