ГЛАВА 1. АНАЛИЗ ПРЕДМЕТНОЙ ОБЛАСТИ И ТРЕБОВАНИЙ К АВТОМАТИЗИРОВАННОЙ ИНФРАСТРУКТУРЕ

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

1.1 Предметная область и постановка проблемы

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

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

Аналогичные задачи решаются в международных проектах: KYPO Cyber Range Platform (Масариков университет, Чехия) 24, платформа EDU CTF от HackTheBox 23, а также инструментарий CyRIS для автоматизированного создания киберполигонов 25. Однако большинство из них предназначены для внешнего использования в режиме облачного сервиса или не предусматривают локального развёртывания с требованиями к суверенности данных, актуальными для российских вузов. Настоящая работа ориентирована именно на автономную платформу с самостоятельным размещением, соответствующую требованиям внутренней политики безопасности учебного заведения.

1.2 Анализ существующих подходов

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

Таблица 1. Сравнение архитектурных подходов к построению учебных киберполигонов

Физические стенды обеспечивают наибольшую реалистичность, однако стоимость одного рабочего места с необходимым оборудованием составляет от 500 тысяч рублей, а время восстановления после инцидента составляет от 2 до 4 часов ручного труда администратора. Виртуальные серверные фермы на базе VMware vSphere улучшают управляемость, но накладные расходы гипервизора составляют 15–20% оперативной памяти, а время старта виртуальной машины составляет от 60 до 90 секунд. Внешние облачные полигоны снижают эксплуатационную нагрузку, однако создают полную зависимость от внешнего провайдера и не позволяют обеспечить требования к локализации данных, актуальные для ряда образовательных стандартов.

Контейнерный подход с локальным развёртыванием на базе Kubernetes является рациональным выбором для данной задачи: он сочетает автономность, гибкость, приемлемую ресурсную эффективность (накладные расходы менее 5%) и скорость старта среды от 2 до 20 секунд при условии корректной реализации многоуровневой защиты.

1.3 Заинтересованные стороны и их цели

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

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

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

Рисунок 1. Схема логических связей объектов и ролей платформы.

1.4 Функциональные требования

На основании анализа ролей и сценариев использования сформулированы семь ключевых функциональных требований (ФТ). ФТ-1: ролевая аутентификация и авторизация для ролей «администратор», «преподаватель», «студент». ФТ-2: управление учебными курсами, заданиями и назначениями. ФТ-3: автоматизированный запуск и остановка лабораторных сред трёх типов по запросу пользователя: CLI-based (консольный доступ по SSH/Web-терминалу), Web-based (веб-приложение, открываемое в браузере через Ingress), GUI-based (графический рабочий стол, доступный через браузерный VNC/RDP-клиент). ФТ-4: изоляция каждой лабораторной сессии в выделенном пространстве имён с применением сетевых политик. ФТ-5: мониторинг статуса лабораторной среды в реальном времени через веб-интерфейс. ФТ-6: автоматическое завершение сессии по TTL и освобождение ресурсов без участия администратора. ФТ-7: централизованный аудит операций управления и переходов жизненного цикла сессий с фиксацией субъекта, времени и типа действия.

1.5 Нефункциональные требования

Нефункциональные требования (НФТ) сформулированы в измеримой форме для возможности последующей верификации. НФТ-1 (производительность): медианное время запуска среды не более 20 секунд при штатной нагрузке без прогретого кэша образов. НФТ-2 (масштабируемость): одновременный запуск не менее 30 лабораторных сессий без деградации SLA и появления ошибок API. НФТ-3 (безопасность): отсутствие сетевой связности между изолированными учебными пространствами имён; целевое значение числа успешных межсессионных соединений равно нулю. НФТ-4 (надёжность): отказ отдельного пода не приводит к потере управляемости платформы, восстановление осуществляется автоматически средствами оркестратора. НФТ-5 (аудит): все критичные действия фиксируются с субъектом, временем и типом операции. НФТ-6 (сопровождаемость): инфраструктурные изменения выполняются исключительно через GitOps-процесс, прямые правки в кластере заблокированы.

1.6 Модель угроз и рисков

Для систематизации рисков применена методология STRIDE 13. В таблице 2 приведена расширенная матрица угроз с оценкой вероятности, ущерба и архитектурных контрмер.

Таблица 2. Матрица угроз по методологии STRIDE

Приоритизация рисков показала критичность трёх векторов: Раскрытие информации (утечка данных между сессиями), Отказ в обслуживании (исчерпание ресурсов) и Повышение привилегий (выход из контейнера). Именно эти векторы определили архитектурные контрмеры, детально рассмотренные в главах 2 и 3: запрещающая по умолчанию сетевая политика, SecurityContext с запретом повышения привилегий, ресурсные квоты пространств имён, seccomp-профили, подпись образов и централизованный аудит.

1.7 Научно-практический вывод по главе

Анализ предметной области подтверждает, что целевая платформа должна рассматриваться не как «набор контейнеров», а как контролируемая учебно-инфраструктурная система с формальными контрактами безопасности. Выбранный контейнерный подход на базе Kubernetes обоснован результатами сравнительного анализа (таблица 1) и является рациональным при условии реализации строгой сегментации, управления жизненным циклом среды как конечного автомата, безопасности цепочки поставки артефактов и измеримой эксплуатационной наблюдаемости. Дальнейшие главы фокусируются на методах и архитектуре, обеспечивающих эти свойства.