ГЛАВА 3. ПРОЕКТИРОВАНИЕ И РЕАЛИЗАЦИЯ ЗАЩИЩЁННОЙ АВТОМАТИЗИРОВАННОЙ ИНФРАСТРУКТУРЫ И КЛИЕНТСКОЙ ЧАСТИ

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

3.1 Целевая архитектура платформы

Архитектура платформы построена как четырёхуровневая система с чёткими контрактами между уровнями.

Уровень виртуализации реализован на базе гипервизора Proxmox VE (Type-1), который обеспечивает ресурсную изоляцию и управление тремя виртуальными машинами: gitlab-vm (GitLab CE с Container Registry и GitLab Runner), database-vm (PostgreSQL - реляционное хранилище состояний платформы), k8s-vm (узел Kubernetes, на котором размещаются все прикладные рабочие нагрузки). Terraform управляет жизненным циклом VM-ресурсов в декларативном режиме.

Инфраструктурный уровень включает поддерживающие сервисы, развёрнутые внутри кластера K8s: RabbitMQ (асинхронная очередь задач развёртывания), Keycloak (IAM и OIDC-провайдер), а также сервисы наблюдаемости (Prometheus, Grafana, Loki).

Прикладной уровень состоит из FastAPI backend - REST API сервера, реализующего бизнес-логику платформы, и Celery Workers - отдельного Kubernetes Deployment, являющегося единственным компонентом, авторизованным на обращение к Kubernetes API. FastAPI backend публикует задачи в RabbitMQ и не имеет прямого доступа к K8s API. Celery Workers получают задачи из очереди, генерируют K8s-манифесты и применяют их через Kubernetes API. Nginx Ingress Controller обеспечивает TLS-терминацию и маршрутизацию входящего трафика.

Клиентский уровень представляет собой приложение на базе Nuxt 4 / Vue 3, предоставляющее отдельные capability-driven интерфейсы для ролей «администратор», «преподаватель» и «студент».

Принципиальное архитектурное ограничение: прямой доступ учебных контейнеров к инфраструктурному и прикладному уровню запрещён сетевыми политиками. Цепочка прохождения задачи управления лабораторной средой: FastAPI backend → RabbitMQ → Celery Workers → Kubernetes API.

Рисунок 3. Общая архитектура платформы (четырёхуровневая модель с контурами пространств имён).

3.2 Модель пространств имён и сегментация

Принята семиконтурная модель пространств имён Kubernetes, разделённая по функциональному назначению. Таблица 3.2 описывает каждый контур, его назначение и характер сетевого доступа.

Таблица 3.2 - Пространства имён кластера и их функциональная роль

Для пространства имён labs применён принцип запрета по умолчанию: межсессионная связность отсутствует, доступ к infrastructure, messaging, platform и auth по умолчанию запрещён на уровне NetworkPolicy. Разрешаются только явно объявленные каналы, необходимые для конкретного учебного сценария. Эта модель локализует потенциальный инцидент в границах одной сессии и существенно снижает вероятность горизонтального перемещения в случае компрометации учебного контейнера.

Рисунок 4. Namespace-модель кластера и направления разрешённого сетевого трафика.

3.3 Модель жизненного цикла лабораторной сессии

Жизненный цикл лабораторной сессии формально описан как конечный автомат (FSM). Формально FSM определяется кортежем ⟨S, Σ, δ, s₀, F⟩, где S: множество состояний, Σ: множество событий-триггеров, δ: функция переходов, s₀: начальное состояние, F: множество терминальных состояний.

Множество состояний: S = {PENDING, PROVISIONING, RUNNING, STOPPING, STOPPED}. Начальное состояние: s₀ = PENDING; терминальное состояние: F = {STOPPED}.

Переходы и их семантика:

• PENDING - задача create_lab_pod опубликована FastAPI backend в очередь RabbitMQ; Celery Workers ещё не приступили к выполнению. Клиент получает немедленный ответ 202 Accepted со статусом PENDING.
• PROVISIONING - Celery Worker извлёк задачу из очереди, генерирует K8s-манифест через Jinja2-шаблон и применяет его через Kubernetes API; Pod переходит в состояние Pending → ContainerCreating.
• RUNNING - Pod перешёл в состояние Ready; URL подключения записан в PostgreSQL; студенту доступна рабочая среда. Фиксируется метка времени started_at.
• STOPPING - получен триггер завершения: либо ручная команда пользователя, либо публикация задачи delete_lab_pod планировщиком Celery Beat по истечении TTL. Celery Worker выполняет удаление Pod и связанных ресурсов через K8s API.
• STOPPED - Pod удалён, ресурсы освобождены. Запись LabInstance в PostgreSQL обновляется; сессия доступна для аудита, но недоступна для возобновления.

Рисунок 5. Конечный автомат (FSM) жизненного цикла лабораторной сессии.

Каждый переход состояния журналируется с фиксацией субъекта, времени и типа события. Наличие формальной FSM-модели исключает «зависшие» промежуточные состояния (PROVISIONING без перехода в RUNNING), упрощает операционное сопровождение и является основой аудируемости, требуемой НФТ-5.

3.4 Контроль доступа и доверенные границы

Прикладная авторизация реализована через гибридную трёхслойную модель, сочетающую RBAC, capability bundles и ABAC.

Слой 1 - RBAC (грубозернистая классификация, Keycloak). Keycloak хранит три неизменяемые системные роли: admin, teacher, student. Роли задают базовую классификацию субъекта, но не являются достаточным основанием для доступа к конкретному ресурсу. Аутентификация реализована как backend-owned OIDC flow 18; frontend не хранит токены.

Слой 2 - Capability bundles (платформенный каталог прав). Backend хранит каталог platform capabilities в формате <section>.<resource>.<action> (например, education.courses.manage, permissions.users.manage). Capability группируются в bundles (teacher.base, admin.permissions и др.), которые назначаются пользователям через access groups. По результату вычисления backend возвращает фронту итоговый массив effective_capabilities через единственный bootstrap-endpoint GET /api/v1/auth/me. Фронт строит меню и маршруты исключительно на его основе.

Слой 3 - ABAC (ресурсно-ориентированная авторизация, backend). Наличие capability является необходимым, но не достаточным условием. Для операций с конкретными объектами backend дополнительно проверяет контекстуальные атрибуты субъекта и ресурса: преподаватель может редактировать тему только если является её создателем или явным соавтором; студент видит тему только если активно состоит в группе с действующей group_topics-связью. Доступ к файлам проверяется через связанный учебный ресурс (Topic, Question, Subsection), а не по прямому URL. Таким образом, финальное решение принимается по формуле: capability ∈ effective_capabilities AND resource-scope ABAC check.

Kubernetes RBAC управляет правами сервисных аккаунтов на обращение к K8s API через ClusterRole / Role и Binding-ресурсы 13. Сетевые политики (NetworkPolicy) задают допустимые направления трафика между пространствами имён.

Принципиальное архитектурное ограничение доступа к Kubernetes API: единственным компонентом, авторизованным на операции с K8s-ресурсами, являются Celery Workers (Deployment в пространстве имён platform). FastAPI backend не имеет сервисного аккаунта с правами на K8s API и не выполняет прямых обращений к kube-apiserver. Это сужает привилегированную поверхность атаки: компрометация публичного API endpoint не предоставляет доступа к управляющей плоскости кластера.

Доверенная вычислительная база включает управляющую плоскость кластера и пространства имён infrastructure, messaging, auth, platform. Учебные контейнеры (пространство имён labs) рассматриваются как недоверенная зона: они лишены сервисного аккаунта с правами на K8s API и изолированы сетевыми политиками.

3.5 Безопасность выполнения контейнеров

Для лабораторных рабочих нагрузок применяется комплекс ограничений SecurityContext. Параметр runAsNonRoot: true запрещает запуск процессов от имени root-пользователя. Параметр allowPrivilegeEscalation: false блокирует возможность повышения привилегий через двоичные файлы с флагом setuid. Набор привилегий (capabilities) контейнера сокращён до минимально необходимого для конкретного учебного сценария через механизм drop: ALL с явным добавлением только необходимых привилегий. Применяется seccomp-профиль runtime/default, ограничивающий системные вызовы до набора, типичного для штатного контейнерного приложения 14. Там, где это применимо по учебному сценарию, используется файловая система корня в режиме «только для чтения». Дополнительно применяются лимиты CPU/RAM на уровне пода и квоты namespace (ResourceQuota), препятствующие атаке на истощение ресурсов (атака типа DoS изнутри).

3.6 Наблюдаемость и аудит

Архитектурно заложены три канала наблюдаемости в соответствии с концепцией триады наблюдаемости. Метрики собираются Prometheus с экспозицией через конечную точку /metrics каждого компонента и визуализируются в Grafana. Отслеживаются: задержка (p50/p95/p99), доля ошибок, ресурсная утилизация (ЦП/ОЗУ по пространствам имён), число активных сессий и время запуска. Пороговые значения алертов: значение p95 задержки > 400 мс, доля ошибок > 0,5%, ЦП пространства имён > 80%. Логи агрегируются через Promtail в Loki в структурированном JSON-формате с обязательными полями: субъект (идентификатор пользователя, роль), тип операции, статус, временная метка. Срок хранения составляет 30 суток. Распределённая трассировка реализована через SDK OpenTelemetry с экспортом в Jaeger, что позволяет отслеживать сквозной путь запроса через Ingress → FastAPI backend → RabbitMQ → Celery Workers → K8s API.

3.7 Отказоустойчивость, масштабирование и управление жизненным циклом сессий

3.7.1 Отказоустойчивость

Отказоустойчивость достигается комбинацией четырёх механизмов: репликации критичных сервисов (FastAPI backend и Celery Workers работают в режиме не менее двух реплик с Horizontal Pod Autoscaler по метрике CPU), проверок работоспособности (пробы liveness и readiness для каждого компонента), асинхронной очереди задач развёртывания через RabbitMQ (буферизация пиков нагрузки - задача не теряется при временной недоступности Celery Workers) и автоматических перезапусков Pod с политикой экспоненциально увеличиваемой задержки повтора.

3.7.2 Управление жизненным циклом сессий через Celery Beat

Автоматическое завершение лабораторных сессий по TTL реализовано через планировщик Celery Beat, работающий как отдельный Pod в пространстве имён platform. Celery Beat каждые 5 минут опрашивает записи LabInstance в PostgreSQL и публикует задачу delete_lab_pod в очередь RabbitMQ для каждого Pod, у которого started_at + TTL < now(). Celery Workers получают задачу из очереди и выполняют удаление K8s-ресурсов. Значение TTL по умолчанию составляет 120 минут и может быть переопределено преподавателем при назначении задания. Такая схема разгружает HTTP API от фоновых операций и гарантирует очистку ресурсов даже при отсутствии явного запроса на завершение со стороны студента.

3.7.3 Фазы масштабирования инфраструктуры

Платформа проектируется в трёх фазах масштабирования, обеспечивающих постепенный переход от учебной установки к производственной:

• MVP (однouзловой кластер) - Kubernetes развёрнут на одной k8s-vm в составе Proxmox VE; все пространства имён размещаются на единственном узле. Обеспечивает разработку, тестирование и учебную нагрузку до 30 параллельных сессий.
• Production (трёхузловой кластер) - три control plane узла и N рабочих узлов; Celery Workers масштабируются до 3–5 реплик через HPA; PostgreSQL переводится в режим репликации. Обеспечивает высокую доступность и нагрузку > 100 параллельных сессий.
• Enterprise (управляемый K8s) - миграция на управляемый Kubernetes (Managed K8s) с multi-zone репликацией; Terraform управляет всем облачным уровнем. Предназначен для развёртывания на базе вузовского или облачного ЦОД с SLA.

3.8 Кибериммунная архитектура развёртывания лабораторных окружений

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

3.8.1 Модель доверенных доменов

Платформа разбита на три домена доверия, реализованных через соответствующие пространства имён Kubernetes, с явно заданными контрактами взаимодействия:

• инфраструктурный домен (infrastructure, messaging, auth) - базовые сервисы хранения (PostgreSQL, MinIO), очередей (RabbitMQ) и IAM (Keycloak); взаимодействует исключительно с прикладным доменом через строго определённые порты; исходящие соединения за пределы домена запрещены;
• прикладной домен (platform) - FastAPI backend и Celery Workers; является единственным авторизованным посредником между пользовательским запросом и учебным окружением; Celery Workers - единственный компонент с доступом к Kubernetes API;
• учебный домен (labs) - динамически создаваемые изолированные Pod'ы сессий; не имеют сетевого пути ни к infrastructure, ни к platform, за исключением явно разрешённых точек управления жизненным циклом.

Обращения из labs в platform или infrastructure блокируются NetworkPolicy на уровне ядра Linux (eBPF/iptables через Calico CNI). Прямой доступ учебного контейнера к PostgreSQL, RabbitMQ или Keycloak технически невозможен вне зависимости от действий внутри контейнера.

3.8.2 Минимизация поверхности атаки контейнера

Таблица 3.1 описывает параметры SecurityContext, применяемые к каждому учебному Pod.

Таблица 3.1 - Параметры SecurityContext для учебных окружений

Данная конфигурация гарантирует, что даже при эксплуатации уязвимости внутри учебного контейнера злоумышленник не получает привилегий на уровне узла кластера.

3.8.3 Контроль цепочки поставки артефактов

Для исключения внедрения недоверенных образов реализован конвейер верификации из четырёх шагов:

1. образ собирается в контролируемом GitLab CI/CD конвейере с применением лучших практик Dockerfile;
2. после сборки выполняется автоматическое сканирование на известные CVE; обнаружение уязвимостей HIGH/CRITICAL блокирует публикацию образа;
3. подпись образа выполняется ключом Cosign с записью в Rekor transparency log 43;
4. при развёртывании admission webhook проверяет подпись до создания Pod; образы без валидной подписи отклоняются на уровне кластера.

Это обеспечивает криптографически верифицируемое происхождение каждого компонента системы.

3.8.4 Аудит и обнаружение аномалий в реальном времени

Кибериммунная структура дополняется непрерывным мониторингом безопасности:

• Kubernetes Audit Log фиксирует все обращения к API-серверу с указанием субъекта, ресурса, времени и результата операции;
• runtime-мониторинг выявляет аномальное поведение контейнеров: нетипичные системные вызовы, попытки записи в защищённые пути, нестандартные сетевые соединения;
• алерты направляются в систему наблюдаемости (Grafana / Alertmanager) для оперативного реагирования дежурного администратора.

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

3.9 Проектирование клиентской части платформы

3.9.1 Выбор технологического стека

Клиентская часть реализована как Nuxt universal app - современная методология разработки, при которой одно приложение на базе Nuxt 4 / Vue 3 поддерживает как SSR (серверный рендеринг), так и CSR-режим без изменения кода. Организация проекта следует слоёной архитектуре: Domain - Application - Infrastructure - App, что обеспечивает явные границы ответственности и тестируемость каждого слоя независимо. Выбор компонентов стека обоснован следующими факторами:

• Nuxt 4 / Vue 3 обеспечивает файловую маршрутизацию (app/pages/), Composition API, встроенный SSR/CSR-режим и строгую типизацию через TypeScript; встроенный Vite обеспечивает быстрый режим разработки (HMR) и оптимизированные production-бандлы;
• Nuxt useState реализует реактивное управление состоянием через встроенный SSR-совместимый composable - внешний стейт-менеджер (Pinia и аналоги) не используется; состояние сессии хранится под ключом auth.session и восстанавливается при гидратации;
• @nuxt/ui предоставляет headless UI-компоненты (навигация, формы, диалоги), интегрированные с Nuxt без дополнительной конфигурации;
• Zod выполняет schema-first валидацию входных данных и ответов API на уровне Infrastructure layer;
• Vue Router (встроен в Nuxt) обеспечивает клиентскую маршрутизацию; защита маршрутов реализована через глобальный Nuxt middleware auth.global.ts по capability-контексту пользователя.

Принципиальная особенность архитектуры - аутентификация полностью backend-owned: фронт не владеет OIDC code exchange и не хранит токены как первичный источник доступа. Браузер перенаправляется на GET /api/v1/auth/login, backend выполняет полный Keycloak-обмен, формирует серверную сессию и устанавливает opaque-сессионную cookie. Фронт получает только эту cookie и вызывает GET /api/v1/auth/me для bootstrap access context.

3.9.2 Архитектура приложения

Приложение организовано по слоёной архитектуре с явными границами ответственности между четырьмя уровнями:

domain/                      # Типы и контракты (не зависит ни от чего)
├── auth.ts                  # AuthBootstrapPayload, AuthPrincipal, capability definitions
├── user.ts, group.ts        # Доменные модели пользователей и групп
└── index.ts                 # Экспорт всех доменных типов

application/                 # Бизнес-логика (зависит только от domain)
├── auth/
│   ├── bootstrap.ts         # Парсинг и валидация ответа /auth/me
│   └── browserFlow.ts       # Построение URL auth flow (login, logout, account security)
├── services/
│   ├── authService.ts       # Auth бизнес-логика (bootstrapSession, clearSession)
│   └── validationService.ts # Валидация через Zod-схемы
└── onboarding/              # Логика создания пользователей и групп

infrastructure/              # Доступ к данным (зависит от domain + application)
├── repositories/
│   ├── authRepository.ts    # GET /api/v1/auth/me, clearLocalSession
│   ├── userRepository.ts    # CRUD пользователей
│   └── permissionsRepository.ts # Чтение capability catalog и bundles
├── httpClient.ts            # $fetch wrapper: headers, timeout, logging, credentials
└── utils/
    └── sessionEvidence.ts   # Отслеживание состояния сессии через localStorage-флаг

app/                         # Nuxt UI-слой (зависит от всех нижних слоёв)
├── layouts/
│   └── default.vue          # Sidebar с capability-driven навигацией
├── pages/
│   ├── auth/callback.vue    # Post-OIDC bootstrap: вызывает /auth/me
│   ├── education/           # Курсы, группы, библиотека, question bank
│   ├── monitoring/          # Логи, системная информация, K8s-диагностика
│   ├── permissions/         # Пользователи, группы, роли, организации
│   ├── settings/            # Настройки, безопасность аккаунта
│   └── profile/             # Профиль пользователя
├── composables/
│   ├── useAuth.ts           # Auth state (useState), bootstrap, logout, capability checks
│   └── useOnboarding.ts     # Создание пользователей и групп через onboarding API
├── middleware/
│   └── auth.global.ts       # Глобальный guard: bootstrap + resolveRouteAccess()
└── utils/auth/
    └── access-control.ts    # satisfiesAccessRule(), filterNavigationItems(), appNavigation

Страницы (pages/) не содержат прямых вызовов API - они используют composables, которые делегируют в application-сервисы и infrastructure-репозитории. Это разделяет слой представления, бизнес-логику и транспортный слой.

3.9.3 Модель доступа: capability-driven UI

Фронт не использует роль как единственный источник доступа. После bootstrap через GET /api/v1/auth/me backend возвращает:

• principal - идентификатор пользователя;
• realm_roles - системные роли (admin, teacher, student);
• access - runtime-контекст (access_group, legacy_role или unassigned);
• effective_capabilities - итоговый набор разрешений, уже рассчитанных backend;
• bundles - сгруппированные наборы capabilities.

На основе effective_capabilities принимаются решения о видимости пунктов меню, доступности маршрутов и активности кнопок. Это позволяет добавлять новые разделы без изменения структуры ролей - достаточно добавить capability в каталог и проверить её наличие в UI.

Состояния unassigned / no access являются валидными backend-состояниями и рендерятся как таковые, а не как ошибки интерфейса.

3.9.4 Ролевые сценарии взаимодействия

Администратор получает доступ к следующим разделам:

• управление пользователями: onboarding преподавателей, bulk-создание студентов, lifecycle через disable/offboarding (не delete);
• управление учебными группами и назначением в них через education/groups;
• просмотр permissions/roles - read-only карта системных ролей; future custom-role shell;
• permissions/groups - snapshot/read-only метаданные; write-операции access-groups - через backend /api/v1/access-groups;
• settings/security - backend-owned self-service shell для account security;
• мониторинг инфраструктуры и аудит событий.

Преподаватель работает с разделами:

• каталог тем, разделов и тестов (education/);
• назначение заданий группам с установкой сроков и TTL лабораторных сессий;
• панель мониторинга активных сессий студентов;
• просмотр результатов выполненных заданий.

Студент взаимодействует с:

• личным кабинетом со списком назначенных работ;
• запуском лабораторной среды и индикатором прогресса provisioning;
• таймером оставшегося TTL сессии;
• инструкцией и кнопкой досрочного завершения.

Компоненты и маршруты, для которых отсутствует соответствующая capability, не отображаются. При этом backend повторно проверяет каждый action - скрытие кнопки не является механизмом защиты.

3.9.5 Auth flow и logout semantics

Canonical browser auth flow:

1. Фронт перенаправляет браузер на GET /api/v1/auth/login.
2. Backend перенаправляет браузер в Keycloak.
3. Keycloak возвращает браузер на GET /api/v1/auth/callback (backend).
4. Backend выполняет code exchange, формирует серверную сессию, устанавливает opaque-cookie и перенаправляет браузер на фронт.
5. Фронт вызывает GET /api/v1/auth/me и получает полный access context.

Фронт не парсит JWT как основной источник разрешений и не хранит токены в клиентском состоянии.

Logout различается на два сценария: local logout (завершение app-сессии; SSO-сессия Keycloak может оставаться живой) и full platform logout (завершение и app-сессии, и SSO-сессии; следующий вход требует нового login flow). Кнопка «Выйти» в продукте соответствует full platform logout через POST /api/v1/auth/logout 40.

3.9.6 Меры безопасности клиентской части

• Backend-owned session: фронт не хранит access/refresh-токены в cookie или localStorage как canonical auth source; cookie является opaque session key;
• HTTPS обязателен: сессионная cookie передаётся только по зашифрованному каналу;
• Content Security Policy ограничивает загрузку внешних скриптов;
• XSS-защита обеспечивается встроенным экранированием Vue; использование v-html без санитизации исключено;
• CORS настроен на стороне API с ограниченным списком допустимых origin 41;
• SameSite=Strict для session cookie предотвращает CSRF.

3.10 Вывод по главе

Спроектированная архитектура обеспечивает все ключевые свойства целевой системы. Изоляция достигается семиконтурной сегментацией пространств имён с запрещающей по умолчанию NetworkPolicy: пространство имён labs не имеет сетевого пути к infrastructure, messaging, auth или platform. Управляемость обеспечивается FSM жизненного цикла из пяти состояний (PENDING → PROVISIONING → RUNNING → STOPPING → STOPPED) и гибридной трёхслойной моделью авторизации: RBAC (Keycloak) для классификации, capability bundles для исчисления effective_capabilities, ABAC для ресурсно-ориентированных проверок на стороне backend. Воспроизводимость гарантируется GitOps-процессом и Helm-чартами. Наблюдаемость реализована триадой метрик / журналов / распределённых трассировок.

Принципиальное архитектурное решение - разделение обязанностей между FastAPI backend и Celery Workers: backend управляет бизнес-логикой и не имеет доступа к Kubernetes API; Celery Workers являются единственным авторизованным компонентом для операций с K8s-ресурсами. Celery Beat автоматизирует очистку истёкших сессий по TTL без участия HTTP API.

Кибериммунная структура развёртывания локализует возможный ущерб от компрометации в границах единственной сессии благодаря трём доменам доверия, SecurityContext с отброшенными capabilities и верификации цепочки поставки образов через Cosign. Клиентская часть реализована как Nuxt universal app на базе Nuxt 4 / Vue 3 со слоёной архитектурой (Domain / Application / Infrastructure / App), управлением состоянием через Nuxt useState без внешнего стейт-менеджера, валидацией через Zod и UI на @nuxt/ui. Capability-driven интерфейс полностью делегирует авторизационные решения серверной стороне через backend-owned OIDC flow. Принятые решения формируют основу для практической апробации, результаты которой представлены в главе 4.