Морозов Д.О., Картунчиков А.М.
КОНТЕЙНЕР-МОДУЛЬНАЯ АРХИТЕКТУРА СИСТЕМ АУДИТА БЕЗОПАСНОСТИ: КОМПРОМИСС МЕЖДУ МОНОЛИТОМ И МИКРОСЕРВИСАМИ *
Аннотация:
в работе рассматривается эволюция архитектурных подходов к построению прикладных систем аудита информационной безопасности и обосновывается выбор контейнер-модульной архитектуры как равновесного решения между «тяжёлым» монолитом и высокодисперсными микросервисами.
Ключевые слова:
аудит информационной безопасности, контейнеризация, микросервисная архитектура, модульность, автоматизация
Развёртывание средств контроля защищённости в госсекторе традиционно сопряжено с жёсткими требованиями к управляемости, валидации кода и регуляторному соответствию. Первые корпоративные продукты аудита создавались как монолитные приложения: вся бизнес-логика, слой данных и пользовательский интерфейс поставлялись единой исполняемой единицей. Такая модель выгодна в связи с выполнением в одном процессе ― шина данных отсутствует, а коллизии версий API невозможны, подготавливается единый пакет документов и один объект оценки безопасности, также снижен накладной сетевой расход: вызовы функций внутрипроцессные, что особенно важно для вычислительно интенсивных проверок. Однако по мере роста управляемых узлов выявились слабые места монолитов:Вертикальное масштабирование ограничено ресурсами одного сервера.Критическая ошибка в модуле парсинга журналов обрушивает всю систему аудита.Жёсткая связность усложняет выпуск инкрементных обновлений, когда даже тривиальный патч отчётного шаблона требует пересборки и повторного прохождения регуляторных тестов. Такой недостаток приводит к «заморозке» функционала, тогда как число CVE-записей растёт экспоненциально.Под влиянием облачных провайдеров и DevOps-культуры появился полярный подход — микросервисы, когда каждая доменная функция вычленяется в самостоятельный сетевой сервис с собственным циклом жизни, БД и репозиторием. Главные плюсы такого подхода:Ресурсоёмкий модуль (например, эластичный поиск логов) горизонтально клонируется независимо от ядра.Команда разработки сканера выпускает патч независимо от других команд.Однако такой подход приводит к сложности оркестрации и эксплуатационным издержка. Также каждый сервис — отдельный ООБ, при обновлении одной зависимости необходимо переаттестовывать весь каскад служб.Практика показывает, что микросервисная модель оправдывает себя при глобальных SaaS-платформах, но для изолированных сегментов КИИ оказывается избыточной.Контейнер-модульная архитектура (КМА) предлагает промежуточный путь: бизнес-значимые компоненты упаковываются в изолированные контейнеры, разрабатываются и сопровождаются раздельно, но их количество ограничено (5–10 модулей), а взаимодействие стандартизовано. Такой подход допускает формальную оценку как единого комплекса, снижает совокупный объём межсервисных протоколов и упрощает эксплуатацию в защищённых сегментах.Таблица 1. Сравнение архитектурных подходов. КМА выделяет крупные бизнесроли (агентколлектор, брокер сообщений, анализатор, хранилище, APIшлюз, UI) в самостоятельные контейнеры, число которых ограничено. При этом допускается оценка комплекса как единого продукта [4]. Каждый контейнер общается с другими по унифицированному шлюзу, таким образом достигаются следующие преимущества:- Баланс обновляемости и сертифицируемости.- Контейнер остаётся атомарной единицей поставки.- Предсказуемые SLA.- Умеренные требования к DevOps-инфраструктуре.Для лабораторных стендов, НИИ и ведомственных ЦОДов КМА позволяет «сборку-по-кнопке» без дорогостоящего штата DevSecOps. Для публичных облаков (IaaS) микросервисы дают более гибкое масштабирование по узлам-арендаторам, но требуют сервис-меша и zero-trust-политик. Для решений, требующих установку всех компонентов на одном устройстве КИИ монолит быстрее проходит аттестацию, однако дальнейшее развитие продукта будет затруднено.Таким образом, контейнер-модульная схема демонстрирует устойчивое «золотое сечение» между простотой поддержки монолита и гибкостью микросервисов - особенно там, где на один экземпляр продукта приходится до более сотни управляемых хостов и где критична регуляторная отчётность, особенно это актуально при соблюдении отечественных ГОСТ 34 и требований ФСТЭК: наибольшие сложности вызывают доказуемость неизменности функционала после обновления.Переход к контейнер-модульной архитектуре переносит в сферу ответственности команды разработки и эксплуатации не только жизненный цикл кода, но и всю инфраструктуру сборки, доставки и исполнения образов. С 2022 г. требования к таким средам в национальном регулировании формализованы приказом ФСТЭК № 118 [5], который вводит шесть классов защиты для средств контейнеризации и детализирует меры контроля (аудит действий, доверенная загрузка, изоляция сетей и т. д.)Для проектов в КИИ это означает, что каждый контейнер как самостоятельная единица поставки должен иметь подтверждённый уровень доверия, а взаимодействие модулей в составе комплекса — проходить единую процедуру оценки.С технической точки зрения минимальной базой надёжности исполнения служат механизмы ядра Linux — пространства имён, cgroups, AppArmor/SELinux и seccomp. Для КМА это упрощает сертификацию: одной декларацией политики можно охватить сразу весь «слой исполнения», а в паспорт безопасности заносится единый шаблон настроек.Вторая ось угроз — цепочка поставок ПО. При использовании сторонних базовых образов и библиотек критично поддерживать доказуемость происхождения компонентов. ГОСТ Р 57580.1 для финансового сектора напрямую требует наличия реестра компонентов и процедуры их проверки [6]. На практике это реализуется формированием SBOM-файлов (CycloneDX или SPDX) и сопровождающих отчётов VEX. Открытый сканер Trivy автоматически извлекает метаданные из Docker-образов, формирует SBOM и сопоставляет содержимое с базой CVE. Начиная с 2024 года инструмент поддерживает генерацию независимых VEX-файлов для уточнения статуса уязвимостей [9, 10]. Интеграция Trivy [11] или его аналогов в этапы CI-pipeline позволяет обеспечить непрерывную валидацию: перед публикацией модуля в реестр каждый контейнер проходит статический анализ, а при деплое Admission Webhook блокирует запуск образа, если его хэш не зарегистрирован в реестре доверенных.Таким образом, формализованное управление безопасностью контейнеров и их цепочкой поставок замыкает «бреши» между уровнем кода и уровнем инфраструктуры, что особенно важно для систем аудита, где компрометация одного модуля может привести к искажению результатов проверки всей ИТ-среды. Внедрение описанного процесса добавляет к трудоёмкости DevSecOps всего один дополнительный шаг SBOM-сканирования, но на уровне регуляторных требований позволяет оформить КМА как единую доверенную платформу и тем самым сохранить главное преимущество архитектуры — баланс между гибкостью обновлений и консервативной аттестацией.
Номер журнала Вестник науки №5 (86) том 4
Ссылка для цитирования:
Морозов Д.О., Картунчиков А.М. КОНТЕЙНЕР-МОДУЛЬНАЯ АРХИТЕКТУРА СИСТЕМ АУДИТА БЕЗОПАСНОСТИ: КОМПРОМИСС МЕЖДУ МОНОЛИТОМ И МИКРОСЕРВИСАМИ // Вестник науки №5 (86) том 4. С. 1372 - 1378. 2025 г. ISSN 2712-8849 // Электронный ресурс: https://www.вестник-науки.рф/article/23441 (дата обращения: 12.07.2025 г.)
Вестник науки © 2025. 16+