science-review.ru
Введение
Многофункциональный межсетевой экран (ММЭ) уровня сети – это программно-аппаратный комплекс, предназначенный для защиты информационных систем путем фильтрации сетевого трафика, обнаружения и блокирования угроз, а также обеспечения контроля доступа [1]. Согласно требованиям ФСТЭК, такие экраны должны соответствовать строгим требованиям, включая сертификацию по классам защиты (4–6), и объединять функции классического межсетевого экрана с дополнительными модулями безопасности, такими как:
− Глубокая проверка пакетов (DPI) – технология глубокого анализа сетевых пакетов, позволяющая идентифицировать, классифицировать и управлять трафиком на основе его содержимого в реальном времени [2].
− Системы обнаружения/предотвращения вторжений (IDS/IPS) – системы, анализирующие трафик для выявления атак, используя сигнатуры или аномалии. IDS только предупреждает об угрозах, а IPS также блокирует их [3].
− Антивирусная защита.
− Веб-фильтрация и контроль приложений.
В состав ММЭ должны входить компоненты, обеспечивающие возможность централизованного управления несколькими экземплярами ММЭ, эксплуатируемых в одной информационной (автоматизированной) системе, в соответствии с ролями пользователей ММЭ. Основным компонентом является система управления [4].
Система управления многофункциональным межсетевым экраном – это комплексное программное решение, предназначенное для централизованного контроля и администрирования функций межсетевого экрана. Оно обеспечивает согласованное взаимодействие между пользовательскими интерфейсами и модулями безопасности, отвечающими за фильтрацию трафика, мониторинг угроз и применение политик доступа. Система выступает в роли посредника, обрабатывая пользовательские команды и настройки и пересылая их модулям безопасности, а также собирает и анализирует данные о работе экрана для последующей отчетности.
Согласно требованиям ФСТЭК: «В случае удаленного доступа к ММЭ от имени пользователей ММЭ защита информации должна обеспечиваться путем защиты каналов связи от несанкционированного физического доступа (подключения) к ним и (или) применения в соответствии с законодательством РФ средств криптографической защиты информации или иными методами».
Цель исследования – разработка модуля централизованного управления, соответствующего требованиям ФСТЭК, для системы управления многофункциональным межсетевым экраном.
Материалы и методы исследования
В ходе экспериментального исследования решались следующие задачи:
1. Сравнение задержки и пропускной способности при управлении одним и группой (N = 1, 5, 10) подчиненных ММЭ.
2. Тестирование устойчивости WebSocket-соединений при разрывах канала и восстановлении связи.
3. Оценка масштабируемости (увеличение числа управляемых узлов до 20) и отказоустойчивости (имитация отказа управляющего ММЭ).
Эксперименты проводились на виртуальной инфраструктуре на базе VMware vSphere 7.0:
− управляющий ММЭ: 4 vCPU, 8 ГБ RAM, Astra Linux Special Edition версии 1.7;
− подчиненные ММЭ (до 20 экз.): 2 vCPU, 4 ГБ RAM, Astra Linux Special Edition версии 1.7;
− клиентское рабочее место: генерация нагрузки через утилиты wrk2 и k6;
− все узлы объединены в изолированную VPN-сеть (WireGuard) с ограничением полосы 1 Гбит/с, RTT 10 мс [5].
Для сбора метрик производительности использовались wrk2 (задержки, RPS) и k6 (сценарное тестирование). Профилирование потребления ресурсов CPU и памяти выполнялось штатными средствами ОС (perf, py-spy), а верификация защищенных соединений (TLS, WebSocket) проводилась путем анализа трафика в Wireshark.
Нормативно-правовые требования к реализации централизованного управления ММЭ определены в Требованиях Федеральной службы по техническому и экспортному контролю по безопасности информации к многофункциональным экранам уровня сети [1].
Разработана модель угроз и матрица верификации, фрагмент которой представлен в таблице.
− Активы: конфигурации ММЭ, журналы аудита, ключевая информация, трафик управления.
− Нарушитель: внешний (попытка перехвата/модификации трафика) и внутренний низкопривилегированный администратор.
− Векторы атак: перехват HTTP-сессий, подделка JWT, разрыв WS-соединений, DoS управляющего модуля.
Матрица верификации требований ФСТЭК
|
Требование ФСТЭК |
Архитектурное решение |
Метод проверки |
Артефакт |
|
Защита каналов связи |
TLS 1.3, взаимная аутентификация |
Анализ handshake в Wireshark |
Отчет о тестировании TLS |
|
Разграничение доступа |
JWT + Ролевая модель |
Тестирование API с разными ролями |
Журнал аудита |
|
Регистрация событий |
Логирование в формате ГОСТ Р 59548 [6] |
Инспекция БД аудита |
Снимок экрана журнала |
|
Централизованное управление |
Прокси / Командный API |
Сравнительное нагрузочное тестирование |
Графики latency/rps |
Методика измерений и критерии успешности (SLO):
− латентность (P99): не более 100 мс для 95 % запросов при 1000 RPS;
− пропускная способность: не менее 5000 запросов/с;
− устойчивость WebSocket: автоматическое переподключение не более 3 с при обрыве связи;
− масштабируемость: рост потребления CPU не более O(log N) при N ≤ 20;
− повторяемость: каждый тест выполнялся 5 раз, доверительный интервал 95 %.
Для разработки централизованного управления были использованы следующие технологии:
– Протокол HTTP и его защищенная версия HTTPS – сетевые протоколы прикладного уровня, с помощью которых осуществляется обмен данных в формате Запрос – Ответ. HTTPS поддерживает шифрование протоколов TLS в целях повышения безопасности [7].
– Протокол WebSocket (WS) и его защищенная версия WebSocket Secure (WSS) работают поверх TCP. Установление защищенного соединения и обмен сертификатами выполняются на этапе инициализации HTTPS-соединения с использованием TLS [8], что обеспечивает шифрование на транспортном уровне модели OSI [9].
– JSON Web Token – стандарт создания токена доступа, хранящего данные в формате JSON. JWT используется для аутентификации мастер-пользователя на управляемом ММЭ [10].
Для организации централизованного прямого управления применяются проксирование HTTP-запросов и установление цепочки WebSocket-соединений по схеме «Клиент → Управляющий ММЭ → Управляемый ММЭ». Для командного управления организуется REST API [11] и цепочка WS-соединений «Управляемый ММЭ → Управляющий ММЭ → Клиент». Взаимодействие между управляющим и подчиненным организуется по схеме «клиент-сервер», где клиентом выступает головная система управления, а сервером – подчиненная СУ [12].
Результаты исследования и их обсуждение
В ходе реализации проекта была разработана и протестирована архитектура модуля централизованного управления многофункциональными межсетевыми экранами, соответствующая требованиям ФСТЭК.
В качестве сервера, обрабатывающего пользовательские запросы, выступает другой многофункциональный экран, оснащенный собственной системой управления. Аутентификация и авторизация запросов выполняются при помощи JWT, при этом конфиденциальность и целостность передачи обеспечивается протоколом TLS 1.3. Токен хранит те же данные, что и JWT при стандартном подключении к системе управления. Хранение ключей и информации о подчиненных ММЭ осуществляется в защищенном виде в базе данных с применением необратимого хэширования с «солью» для паролей и шифрованием для симметричных ключей [13].
Реализация командного управления на СУ решает задачи получения статистики и состояния работы подчиненных ММЭ и управления их политиками. Получение состояния модулей безопасности и собранной с них статистики в реальном времени осуществляется с помощью WebSocket-соединения.
Новый вариант с прямым подключением к подчиненному ММЭ представляет собой проксирование запросов на управляющей системе управления [14]. Этот режим подключения предоставляет полноценный доступ к конфигурированию подчиненного ММЭ, как если бы пользователь управлял в интерфейсе основной СУ.
1. Прямое проксирование запросов (прозрачное управление)
После авторизации в системе управления многофункционального межсетевого экрана пользователь может подключиться к подчиненному ММЭ, используя данные лицензии последнего.
Рис. 1. Прозрачное управление подчиненным ММЭ Примечание: составлен авторами по результатам данного исследования
На основе идентификатора пользователя и лицензии подчиненного ММЭ формируется токен доступа, хранящийся на управляющем сервере. При каждом новом запросе пользователя управляющий инициализирует проверку, находится ли администратор в режиме управления подчиненным ММЭ. Если да, то проксирует его запрос на подчиненный сервер. Получив ответ от управляемого сервера, управляющий сервер передает его пользователю без дополнительной обработки. Вариант организации централизованного управления ММЭ через прямое проксирование запросов представлен на рис. 1.
При прямом проксировании управляющий ММЭ выступает прозрачным HTTP-прокси, перенаправляя запросы GUI/REST API к подчиненному узлу без обработки. Это обеспечивает минимальную задержку (latency P99 ≤ 50 мс при 1000 RPS), но требует строгой синхронизации API между узлами. Подход не позволяет централизованно валидировать команды и усложняет аудит.
Рис. 2. Управление подчиненным ММЭ при помощи команд Примечание: составлен авторами по результатам данного исследования
2. Командный подход (абстрактное управление через эндпоинты)
Управляемый ММЭ при регистрации управляемого многофункционального межсетевого экрана устанавливает с ним WebSocket-соединение, по которому передается статистика и состояние подчиненного в реальном времени. Для передачи политик безопасности и команд на изменение состояния модулей безопасности используется REST API управляющего ММЭ, который отправляет HTTP-запросы подчиненному. Диаграмма последовательности архитектуры абстрактного управления подчиненными ММЭ изображена на рис. 2.
При командном подходе управляющий ММЭ предоставляет унифицированные REST-эндпоинты, инкапсулирующие логику взаимодействия с подчиненными узлами. Пользователь отправляет команды в стандартизированном формате, а управляющий узел преобразует их в API-вызовы конкретных ММЭ. Это обеспечивает единый интерфейс для GUI [15] и позволяет реализовать централизованную валидацию, кеширование, агрегацию данных и аудит. Однако цена унификации – дополнительная задержка: latency P99 возрастает до 120 мс (против 50 мс при проксировании) при 1000 RPS за счет обработки команд на управляющем узле.
Заключение
В ходе проведенного исследования была разработана архитектура модуля централизованного управления многофункциональным межсетевым экраном, соответствующая требованиям ФСТЭК. Предложенное решение основано на двух ключевых подходах: прямом проксировании запросов и командном управлении через REST API. Оба метода обеспечивают безопасное и эффективное администрирование распределенных ММЭ, но различаются по степени абстракции и гибкости.
Прямое проксирование позволяет минимизировать задержки за счет сквозной передачи запросов между управляющим и подчиненными ММЭ, что особенно важно для оперативного управления в реальном времени. Однако этот подход требует строгой синхронизации API и усложняет централизованный аудит изменений. В свою очередь, командный подход обеспечивает унифицированный интерфейс для управления разнородными ММЭ, позволяя агрегировать данные, валидировать команды и вести единый журнал событий. Это повышает удобство администрирования, но может вносить дополнительную задержку из-за необходимости преобразования запросов.
Важным аспектом реализации является обеспечение безопасности. Взаимодействие между узлами защищается с помощью JWT-аутентификации, HTTPS-шифрования и WebSocket-соединений с TLS, что соответствует требованиям регуляторов. Кроме того, хранение ключей и конфигураций в зашифрованном виде снижает риск утечки критичных данных.
Разработанная система упрощает администрирование крупных сетевых инфраструктур за счет:
− централизованного управления политиками безопасности,
− мониторинга состояния подчиненных ММЭ в реальном времени,
− автоматизации рутинных задач через REST API.
В перспективе исследование методов централизованного управления будет продолжено с акцентом на следующее:
1. Повышение функциональности – интеграцию новых модулей анализа угроз и машинного обучения для прогнозирования атак.
2. Улучшение пользовательского интерфейса – разработку интуитивно понятных дашбордов с расширенной визуализацией данных.
3. Усиление безопасности – внедрение постквантовой криптографии и более строгих механизмов аутентификации.
Конфликт интересов
Библиографическая ссылка
Ширяев А. И., Нажимова Н. А. АРХИТЕКТУРА МОДУЛЯ ЦЕНТРАЛИЗОВАННОГО УПРАВЛЕНИЯ МНОГОФУНКЦИОНАЛЬНЫМ МЕЖСЕТЕВЫМ ЭКРАНОМ В СООТВЕТСТВИИ С ТРЕБОВАНИЯМИ ФЕДЕРАЛЬНОЙ СЛУЖБЫ ПО ТЕХНИЧЕСКОМУ И ЭКСПОРТНОМУ КОНТРОЛЮ // Научное обозрение. Технические науки. 2026. № 1. С. 19-24;URL: https://science-engineering.ru/ru/article/view?id=1527 (дата обращения: 28.04.2026).
DOI: https://doi.org/10.17513/srts.1527