СУБД Jatoba и Dallas Lock в ВКР: проектирование импортонезависимого защищённого контура
24 марта 2026 года «Газинформсервис» и «Конфидент» объявили о создании комплексного импортонезависимого стека: СУБД Jatoba подтвердила совместимость с продуктами линейки Dallas Lock. Для выпускника ИТ-специальности это не просто новость — это готовая тема для ВКР с реальными сущностями, тестируемыми гипотезами и метриками, которые можно посчитать. Забудьте абстрактные «разработка веб-приложения»: комиссия гораздо благосклоннее к работе, где на защите вы сравниваете две конфигурации защиты, приводите журналы аудита и показываете, как СУБД ведёт себя под нагрузкой при мандатном доступе. Разберём, как превратить этот тренд в защищаемую работу — от формулировки задач до оформления схем по ГОСТ 34.
FAQ: что студенты спрашивают до начала работы
Где брать данные и материалы, если нет доступа к коммерческим дистрибутивам?
Во-первых, у Jatoba и Dallas Lock есть публичные демо-стенды и техническая документация производителей. Во-вторых, официальное подтверждение совместимости и методики тестирования часто публикуются в виде релизов партнёрской программы. В-третьих, ничто не мешает построить эмуляцию: развернуть PostgreSQL (Jatoba совместима с ним на уровне протокола и синтаксиса), а поверх — открытый аналог механизмов Dallas Lock (например, SELinux/AppArmor в качестве модели мандатного доступа) и честно указать это ограничение в главе 1.
Что именно тестировать? Просто факт совместимости?
Нет. ВКР уровня «работает / не работает» не тянет на диплом. Нужны измеримые сценарии: пропускная способность транзакций при включённом TDE, задержка ответа при ролевом разграничении доступа, корректность журналирования событий доступа к строкам таблиц. Минимум — 3 метрики из ISO/IEC 25010: производительность, безопасность, надёжность.
Как оформлять схемы взаимодействия СУБД и средства защиты?
Базово — C4-диаграммы (Context + Container) плюс UML Deployment Diagram. Если руководитель требует строго по ГОСТ 34.201-89 — тогда функциональная схема и схема информационных потоков. Ни в коем случае не вставляйте скриншоты интерфейсов вместо схем: комиссия это видит сразу.
Сколько данных нужно прогнать для «статистической значимости»?
Для инженерной ВКР достаточно 30 прогонов на сценарий (правило 30 — условный порог нормальности) с фиксацией медианы, 95-го перцентиля и стандартного отклонения. Не гонитесь за большими выборками: лучше стабильные 30 прогонов на 5 сценариях, чем 1000 «на глазок».
Темы ВКР, вырастающие из кейса Jatoba + Dallas Lock
-
Тема 1. Оценка влияния мандатного разграничения доступа Dallas Lock на производительность СУБД Jatoba.
Актуальность: статья прямо подтверждает совместимость, но не публикует метрики деградации. Это белое пятно — идеальный вклад ВКР.
Цель: получить количественную оценку влияния защитных механизмов на TPS и латентность.
Задачи: (1) обзор моделей доступа RBAC/ABAC/мандатной; (2) развёртывание тестового стенда; (3) сценарии нагрузочного тестирования; (4) анализ метрик и выводы.
Структура: Гл.1 — теория моделей доступа и обзор стека; Гл.2 — стенд, схемы, конфигурация; Гл.3 — эксперименты, таблицы с 95-м перцентилем, рекомендации. -
Тема 2. Проектирование журнала аудита доступа к данным в импортонезависимом контуре.
Актуальность: приказ ФСТЭК №17 требует регистрации событий безопасности; в связке Jatoba + Dallas Lock источников логов минимум два, и их надо корреллировать.
Цель: спроектировать и прототипировать централизованный сбор и корреляцию событий.
Задачи: анализ требований ФСТЭК к регистрации; выбор схемы сбора (syslog / OpenTelemetry); маппинг событий; проверка полноты покрытия.
Структура: Гл.1 — нормативка и требования; Гл.2 — архитектура сборщика (C4 + BPMN процесса реагирования); Гл.3 — валидация логов на тестовых инцидентах. -
Тема 3. Методика аттестационного тестирования импортонезависимого стека.
Актуальность: типовых методик под конкретную связку СУБД + средства защиты почти нет, а заказчики госсектора их требуют.
Цель: разработать воспроизводимую методику проверки стека на соответствие требованиям безопасности.
Задачи: изучить оценочный уровень доверия (ОУД); составить чек-лист проверок; автоматизировать часть через OWASP ASVS; оформить протокол испытаний.
Структура: Гл.1 — нормативная база; Гл.2 — структура методики и тест-планов; Гл.3 — пилотное применение и оценка трудозатрат. -
Тема 4. Анализ импортозамещения СУБД в защищённом сегменте: миграционные риски.
Актуальность: перейти с зарубежной СУБД на Jatoba — задача куда сложнее, чем «поставить пакет».
Цель: построить карту рисков миграции и предложить меры снижения.
Задачи: инвентаризация несовместимостей синтаксиса; оценка объёма переписывания; модель TCO на 3 года; рекомендации.
Структура: Гл.1 — состояние рынка и реестр отечественного ПО; Гл.2 — методика оценки рисков (PMBOK 7 + ISO 31000); Гл.3 — расчёты, диаграмма Исикавы, выводы.
Как встроить кейс в главы ВКР: пошагово
Глава 1. Аналитическая — куда положить новость
Не пересказывайте пресс-релиз. Ваша задача — показать, что вы понимаете контекст. Разместите таблицу сравнения моделей разграничения доступа (DAC / MAC / RBAC / ABAC) с указанием, какая из них реализуется в Dallas Lock, и почему для конкретной предметной области это оправдано. Ниже — шаблон структуры таблицы, которую вы наполните своими данными:
| Модель | Принцип | Где реализована | Плюсы | Минусы |
|---|---|---|---|---|
| DAC | Владелец назначает права | Классические ОС | Гибко | Нет защиты от инсайдера |
| MAC (мандатная) | Метки уровней | Dallas Lock, SELinux | Строгая изоляция | Сложная адми |
| RBAC | Роли → права | Jatoba, PostgreSQL | Удобно масштабировать | Role explosion |
| ABAC | Атрибуты контекста | Современные IAM | Тонко настраивается | Требует политик |
Рядом поставьте C4 Context-диаграмму: пользователь → приложение → Jatoba (внутри — Dallas Lock как средство защиты). Опишите словами взаимодействие: какой компонент аутентифицирует, какой фильтрует SQL, где пишется журнал.
Глава 2. Проектная — стенд и конфигурация
Здесь вы разворачиваете лабораторию. Минимальный набор — виртуальная машина (KVM/Docker), СУБД, средство защиты, генератор нагрузки (pgbench или sysbench для совместимых СУБД). Ниже — пример скрипта инициализации тестового окружения и базовой настройки разграничения доступа Jatoba через SQL (для PostgreSQL-совместимых СУБД синтаксис сохраняется):
-- Создание роли приложения и ограничение по IP
CREATE ROLE app_user LOGIN PASSWORD 'Strong#P@ss2026';
CREATE DATABASE diploma_db OWNER app_user;
ALTER ROLE app_user SET default_transaction_read_only = off;
ALTER ROLE app_user CONNECTION LIMIT 50;
-- Разграничение по схемам
REVOKE ALL ON SCHEMA public FROM PUBLIC;
GRANT USAGE ON SCHEMA app TO app_user;
-- Аудит доступа к чувствительной таблице
CREATE TABLE app.clients (
id bigint PRIMARY KEY,
fio text NOT NULL,
passp text NOT NULL
);
REVOKE ALL ON app.clients FROM PUBLIC;
GRANT SELECT, INSERT ON app.clients TO app_user;
-- Журнал аудита (минимальный прикладной слой над штатным)
CREATE TABLE audit.access_log (
ts timestamptz DEFAULT now(),
user_name text,
action text,
obj text
);
Поясните, как это сочетается с мандатными метками Dallas Lock: снизу — уровни конфиденциальности, сверху — ролевая настройка СУБД. Нарисуйте UML Deployment Diagram: узлы, артефакты, протоколы (TLS 1.3, SCRAM-SHA-256), точки контроля.
Глава 3. Экспериментальная — метрики
Это самый весомый раздел. Забудьте «сравним на глаз». Вы фиксируете три группы метрик:
| Группа | Метрика | Инструмент | Как трактовать |
|---|---|---|---|
| Производительность | TPS, p95 latency | pgbench / JMeter | Деградация ≤ 15% — приемлемо |
| Безопасность | Число отказов доступа по мандату | Журнал Dallas Lock | 100% попыток обхода → отказ |
| Надёжность | RTO/RPO при переключении | Сценарий kill + restore | RTO ≤ 5 мин, RPO = 0 (sync) |
Обязательно сохраняйте сырые логи: комиссия любит видеть не только вывод, но и воспроизводимость. Приложите скрипты и CSV-выгрузки в приложение к ВКР.
Глава 3 (бонус). Экономический раздел
Считайте TCO на 3 года: лицензии импортонезависимых решений vs зарубежных (с учётом рисков отзыва). Не путайте с «окупаемостью»: у госсектора это вопрос непрерывности, а не прибыли. Ссылайтесь на реестр отечественного ПО и требования регулятора — это снимает половину вопросов комиссии.
- Все схемы (C4, UML) подписаны и имеют ссылки в тексте — не «висят» без упоминания.
- Каждая задача из введения закрыта конкретным выводом в главе 3.
- Метрики имеют источник: скрипт, дату прогона, объём выборки (≥30 прогонов).
- Список литературы содержит официальные документы ФСТЭК и техдокументацию производителей, а не только статьи из интернета.
- Оформление по ГОСТ 7.32-2017 (или требуемому вузом), включая оформление рисунков и таблиц.
- Уникальность текста ≥ 70% и отсутствие дословных фрагментов пресс-релизов.
- Приложения: скрипты, CSV-логи, протоколы тестирования — с оглавлением.
- Пересказ пресс-релиза вместо анализа. Комиссия мгновенно ловит «воду» про партнёрство компаний. Замените на техническое сравнение моделей доступа и замеры, как показано выше.
- Игнорирование нормативной базы. В теме про импортозамещение и защиту незаверенным выглядит ВКР без ссылок на приказы ФСТЭК и ГОСТ. Добавьте их в главу 1, но не вместо технической части, а в связке с ней.
- Отсутствие воспроизводимости. Если ваши цифры нельзя повторить по описанным шагам — это не инженерный результат. Давайте конфиги, версии, команды, аппаратные характеристики стенда.
Чему вы научитесь на такой ВКР
- Проектировать архитектуру защищённого контура по C4 и UML с обоснованием точек контроля.
- Настраивать разграничение доступа на уровне СУБД (RBAC + мандатные метки) и валидировать политики.
- Снимать метрики производительности и надёжности корректно: медиана, перцентили, доверительные интервалы.
- Готовить документацию по ГОСТ 7.32 и 34.201, включая протоколы испытаний.
- Считать TCO и обосновывать выбор импортонезависимого решения не только «по патриотическим соображениям», а по требованиям непрерывности.
Источник: Создан импортонезависимый стек на основе совместимости СУБД Jatoba с продуктами линейки Dallas Lock (опубликовано 2026-03-24)