Совместимость средств защиты БД и сетевых брокеров в ВКР: от отраслевой новости к проектной главе
В марте 2026 года вендоры объявили о подтверждённой совместимости системы защиты баз данных «Гарда DBF» и брокера сетевых пакетов DS Integrity EVO. Само по себе это событие узкое: два российских продукта договорились работать в связке. Но для выпускника ИТ-направления оно ценнее, чем кажется — здесь виден целый пласт инженерных задач, которые отлично ложатся в структуру ВКР: сегментация сетевого доступа к СУБД, контроль запросов на уровне протокола, отказоустойчивость точки интеграции, подтверждение совместимости как отдельный вид испытаний. Если вы ищете тему, в которой есть и архитектура, и измеримые метрики, и нормативка, — этот кейс даёт готовый каркас. Ниже разберём, как развернуть новость в три полноценные темы диплома и чем наполнить каждую главу.
Что вообще произошло и почему это важно для дипломника
Система защиты баз данных (СЗБД, она же database firewall) стоит на пути между приложением и СУБД и фильтрует запросы: отсекает попытки инъекций, ловит аномальные выборки, разграничивает доступ по учёткам. Брокер сетевых пакетов решает другую задачу — управляет сетевым взаимодействием, обеспечивает контролируемую доставку трафика между сегментами, часто с функциями шифрования и микросегментации.
Пока эти два элемента живут раздельно, между ними остаётся «серая зона»: часть трафика к базе может обходить прикладной контроль, а часть — сетевой. Подтверждённая совместимость означает, что вендоры протестировали совместную работу, зафиксировали порядок развёртывания и сняли часть рисков интеграции. Для ВКР это повод не пересказывать пресс-релиз, а исследовать: какая архитектура доступа к СУБД считается корректной, какие метрики доказывают, что связка не деградировала производительность, и как оформить результаты испытаний так, чтобы их приняла комиссия.
Три темы ВКР, которые вырастают из этой новости
Тема 1. Проектирование защищённого контура доступа к СУБД на базе СЗБД и брокера сетевых пакетов
- Актуальность: компании переходят от «плоской» сети к микросегментации, и защита базы перестаёт быть задачей одного средства. Событие с подтверждённой совместимостью «Гарда DBF» и DS Integrity EVO показывает, что рынок движется к связкам «сетевое + прикладное» средство защиты.
- Цель: разработать архитектуру контролируемого доступа к СУБД, в которой сетевой брокер и СЗБД работают как единый контур.
- Задачи: проанализировать модели защищённого доступа и концепцию Zero Trust; выбрать схему размещения компонентов (inline, out-of-band, прокси); спроектировать схему потоков данных между приложением, брокером, СЗБД и СУБД; оценить влияние на задержку и пропускную способность.
- Структура: Глава 1 — анализ угроз БД, обзор классов СЗБД и брокеров, нормативная база (приказы ФСТЭК, ГОСТ 34.602-89 на ТЗ); Глава 2 — проектирование контура, диаграммы развёртывания и последовательностей, обоснование точек контроля; Глава 3 — стенд, сценарии проверки, метрики, экономика внедрения.
Тема 2. Оценка производительности и отказоустойчивости связки «СЗБД + брокер» при росте нагрузки
- Актуальность: любое средство защиты на пути к базе — это дополнительная задержка. Заказчик всегда спросит: «а на сколько медленнее станет?». Ответ должен быть в цифрах, а не в обещаниях вендора.
- Цель: построить методику нагрузочного тестирования защищённого контура и определить границы применимости.
- Задачи: определить профиль нагрузки (OLTP/OLAP, доля чтения/записи, конкурентные сессии); выбрать инструменты генерации нагрузки; снять базовые метрики без средств защиты и с ними; рассчитать деградацию и найти точку насыщения.
- Структура: Глава 1 — обзор подходов к нагрузочному тестированию и стандарта ISO/IEC 25010 (блок «производительность»); Глава 2 — проектирование стенда и методики замеров; Глава 3 — результаты, графики, выводы о допустимых режимах, расчёт RTO/RPO для отказоустойчивого варианта.
Тема 3. Методика подтверждения совместимости отечественных средств защиты информации
- Актуальность: импортозамещение породило задачу, которой раньше почти не было: проверять, что два российских продукта корректно работают вместе. Такую методику можно построить на примере публично заявленной совместимости СЗБД и брокера пакетов.
- Цель: разработать и апробировать методику функционального и нагрузочного тестирования совместимости двух СЗИ.
- Задачи: формализовать критерии совместимости; составить матрицу проверок; описать протокол испытаний и форму отчёта; провести демонстрационные испытания на стенде.
- Структура: Глава 1 — теория совместимости, реестр отечественного ПО, требования регуляторов; Глава 2 — проектирование методики, тест-кейсы, шаблоны протоколов; Глава 3 — апробация, оценка трудоёмкости, шаблон итогового отчёта для аттестации.
Аналитическая глава: как обосновать выбор, а не перечислить вендоров
Самая частая беда первой главы — список продуктов с описанием из маркетинговых буклетов. Комиссия это видит сразу. Вместо перечисления сделайте сравнение по архитектурным признакам, которые влияют на решение.
| Критерий сравнения | СЗБД (класс «Гарда DBF») | Брокер сетевых пакетов (класс DS Integrity EVO) | Что это даёт диплому |
|---|---|---|---|
| Уровень контроля (OSI / логика СУБД) | Прикладной: разбор SQL, правила доступа к объектам | Сетевой и транспортный: сегментация, фильтрация потоков | Материал для схемы «эшелонированная защита» |
| Режим включения | Inline-прокси или зеркалирование трафика | Inline, шлюз между сегментами | Обоснование схемы размещения на стенде |
| Влияние на задержку | Зависит от сложности правил и объёма разбора | Зависит от глубины инспекции и шифрования | Гипотезы для нагрузочного эксперимента |
| Отказоустойчивость | Кластеризация, резервирование узлов | Резервирование каналов, балансировка | Расчёт RTO/RPO в третьей главе |
| Нормативные требования | Требования к защите СУБД по приказам ФСТЭК | Требования к сегментации и защите каналов | Раздел «соответствие требованиям» |
Обратите внимание: подтверждённая совместимость двух средств — это самостоятельный критерий выбора, который в академической работе описывается через понятие интероперабельности. Хорошо работает отсылка к ISO/IEC 25010: в этой модели качества интероперабельность и защищённость стоят рядом, что даёт вам законное право рассматривать их совместно, а не по отдельности.
Обоснование стека: шаблон рассуждения
- Функциональное требование — что система обязана делать (например, блокировать запросы к таблице вне разрешённого окна).
- Нефункциональное требование — с каким качеством (задержка не выше X мс, доступность не ниже Y%).
- Критерий выбора средства — какое свойство продукта закрывает требование.
- Риск — что будет, если средство не справится (обход контроля, деградация сервиса).
Такая логика превращает «я выбрал этот продукт, потому что он российский» в защищаемое инженерное обоснование.
Проектная часть: схемы, алгоритмы, интеграция
Здесь новость превращается в вашу собственную работу. Не нужно воспроизводить вендорскую схему — спроектируйте свой контур под конкретную задачу: интернет-магазин, вузовская АИС, медицинская система, любая учебная предметная область.
Минимальный набор диаграмм
- Диаграмма развёртывания — где физически/виртуально стоят приложение, брокер, СЗБД, СУБД, средства мониторинга.
- Диаграмма последовательности — путь одного запроса от клиента до базы и обратно, с указанием точек контроля.
- Схема потоков данных — что именно фильтруется на сетевом уровне, а что на прикладном, и почему не возникает двойной фильтрации.
- Схема отказоустойчивости — что происходит при падении брокера или узла СЗБД (fail-open или fail-close — это отдельный вопрос для обсуждения).
Алгоритм контроля доступа: пример описания
1. Клиент инициирует соединение с приложением.
2. Приложение открывает сессию к СУБД через адрес брокера.
3. Брокер проверяет: источник в разрешённом сегменте,
порт соответствует политике, соединение проходит по защищённому каналу.
4. Трафик передаётся на узел СЗБД.
5. СЗБД разбирает SQL, применяет правила:
- белый список объектов (таблицы, представления);
- ограничения на массовые выборки;
- запрет DDL от прикладной учётной записи.
6. При нарушении — блокировка и запись события в журнал.
7. Событие уходит в SIEM/систему мониторинга.
8. Приложение получает либо результат, либо ошибку доступа.
Такой псевдокод допустим даже в работах, где не требуется программирование: он показывает, что вы понимаете порядок взаимодействия, а не просто нарисовали прямоугольники.
Тестирование и метрики: чем доказать работоспособность
Раздел, который чаще всего проваливают. Студент пишет «система работает корректно» — и получает вопрос: «а как вы это измерили?». Ниже — минимальный, но убедительный набор.
| Группа метрик | Показатель | Как снимать | Куда идёт в тексте |
|---|---|---|---|
| Производительность | Задержка запроса, транзакций в секунду, время отклика p95 | Генератор нагрузки + сбор статистики СУБД | Сравнительная таблица «без защиты / с защитой» |
| Функциональность защиты | Доля заблокированных запрещённых запросов, ложные срабатывания | Набор тест-кейсов с заранее известным ответом | Раздел «результаты испытаний» |
| Отказоустойчивость | RTO, RPO, поведение при отказе узла | Сценарии аварийного отключения компонентов | Выводы о пригодности для продуктивной среды |
| Наблюдаемость | Полнота журналов, задержка доставки события в мониторинг | Сбор метрик и логов, сопоставление времени | Схема мониторинга в проектной главе |
Если полноценный стенд недоступен, честно опишите ограничения и используйте имитационное моделирование — но обязательно укажите, какие допущения вы приняли. Комиссия уважает прозрачность больше, чем красивые, но непроверяемые цифры.
Чему вы научитесь на такой теме
- Проектировать эшелонированную защиту. Поймёте разницу между сетевым и прикладным контролем и научитесь распределять зоны ответственности между средствами.
- Обосновывать выбор технологии. Через функциональные и нефункциональные требования, а не через «популярность» продукта.
- Строить методику испытаний. От гипотезы до протокола с фиксированными метриками.
- Работать с нормативкой. Требования к ТЗ по ГОСТ 34.602-89, к оформлению документации, к составу испытаний.
- Собирать доказательную базу. Таблицы, графики, скриншоты конфигураций, журналы — всё, что защищает выводы.
- Пересказ вендорских материалов. Пресс-релиз — не источник выводов. Используйте его как повод, а анализ стройте на требованиях и архитектуре. Как избежать: после каждого абзаца о продукте задавайте вопрос «какое требование это закрывает?».
- Отсутствие метрик эффективности. «Стало безопаснее» — не результат. Как избежать: до начала работы зафиксируйте 4–6 измеримых показателей и способ их снятия.
- Терминологическая путаница. Смешивание уровней SaaS/PaaS/IaaS, а также сетевого и прикладного контроля без пояснений. Как избежать: заведите глоссарий в начале работы и ссылайтесь на него.
- Игнорирование ГОСТ при оформлении ТЗ. Структура технического задания задана ГОСТ 34.602-89, и отклонение от неё — формальный повод снизить оценку.
Частые вопросы
Обязательно ли писать код в такой ВКР?
Не обязательно в объёме «разработать продукт». Достаточно: скриптов генерации нагрузки, конфигурационных файлов, скриптов разбора логов, запросов к системе мониторинга. Если код есть — он должен быть вашим, с комментариями и описанием в приложении. Работа чисто аналитического плана тоже принимается, но тогда глубина анализа должна быть выше.
Как измерить производительность, если нет выделенного сервера?
Соберите стенд из виртуальных машин на ноутбуке: СУБД, приложение, прокси-компонент. Ограничьте нагрузку и честно укажите это в разделе «условия эксперимента». Абсолютные значения не так важны, как относительная деградация «до/после» и корректность методики. Именно методику и защищают.
Где брать тестовые данные?
Три законных варианта: синтетические генераторы данных, открытые учебные наборы, собственный датасет, сгенерированный скриптом под структуру вашей предметной области. Никогда не используйте реальные персональные данные — это отдельная ошибка, за которую снимают баллы.
Как оформить диаграммы, чтобы их приняли?
Любой распространённый нотационный язык (UML, IDEF, BPMN) с легендой и пояснением. Главное — единообразие: если начали в UML, не переходите на произвольные схемы в третьей главе. Каждая диаграмма должна быть упомянута в тексте и иметь вывод: «из схемы следует, что…».
Чек-лист перед сдачей работы
- Каждая задача из введения закрыта выводом в соответствующей главе — проверьте построчно.
- Все заимствованные факты и цифры имеют ссылку на источник, включая отраслевые новости.
- Есть минимум одна сравнительная таблица и одна схема архитектуры.
- Метрики сопровождаются условиями замера: среда, объём данных, число сессий, длительность.
- Техническое задание и ведомости оформлены по ГОСТ (34.602-89, 19.201-78).
- Термины употреблены единообразно по всему тексту; глоссарий на месте.
- Ограничения исследования описаны прямо, а не спрятаны.
- Приложения содержат конфигурации, листинги и протоколы испытаний с подписями.
Такой набор проверок закрывает большинство вопросов комиссии ещё до того, как они прозвучат. А если тема сформулирована через конкретную инженерную задачу, а не через общие слова, защита превращается в обычный технический разговор — что, собственно, и есть цель.
Источник: Подтверждена совместимость системы защиты баз данных «Гарда DBF» и брокера сетевых пакетов DS Integrity EVO (опубликовано 2026-03-25)