Опубликовано: 01.10.2026 | Источник: CNews (новости)

```html

Контейнерные платформы в ВКР: сертификация ФСТЭК как кейс безопасной оркестрации

26 марта 2026 года специальная редакция российской контейнерной платформы «Штурвал» получила сертификат ФСТЭК России №5045. За этой новостью стоит не маркетинг, а реальный технологический сдвиг: впервые отечественный оркестратор контейнеров официально признан пригодным для применения в защищённых контурах — от государственных ИС до КИИ. Для выпускника ИТ-специальности это прямой сигнал: тема «безопасность контейнерной инфраструктуры» перестала быть умозрительной. Она подкреплена конкретным кейсом, который можно взять в основу главы 1 и 2 диплома, а также превратить в защищаемый практический результат.

Что чаще всего спрашивают студенты

Можно ли использовать «Штурвал» вместо Kubernetes в дипломе?

Да, если тема связана с импортозамещением или защищёнными контурами. Платформа совместима с CRI/OCI, поддерживает Helm-чарты и привычные примитивы Kubernetes. Для ВКР по DevOps/SRE это отличный «второй стенд» — показать переносимость манифестов между двумя оркестраторами.

Где брать данные для главы «Анализ»?

Опорные источники: реестр ФСТЭК, документация вендора, требования ГОСТ Р 56939-2016 (безопасная разработка), OWASP Kubernetes Top 10, ISO/IEC 25010 (модель качества). Не выдумывайте цифры «утечек» — ссылайтесь на методологию.

Хватит ли C4-диаграммы вместо UML?

Зависит от требований кафедры. Обычно: C4 Context + Container — для описания платформы, UML Deployment — для физического размещения, DFD — для модели угроз. Комбинация закрывает и архитектуру, и ИБ.

Как защищать работу, если нет доступа к сертифицированной сборке?

Разворачивайте open-source-аналог (k3s, Minikube) и описывайте, какие контроли Strauhval-класса вы бы применили: RBAC, Pod Security Standards, аудит-политики. Оценивайте по метрикам, а не по логотипу вендора.

Три темы ВКР, которые реально защитить

• Тема 1. Моделирование угроз для контейнерной платформы на основе OWASP Kubernetes Top 10.

  Актуальность: сертификация «Штурвала» задаёт эталон требований ИБ к оркестратору. Цель: построить модель угроз и набор компенсирующих мер. Задачи: (1) обзор OWASP K8s Top 10, (2) классификация рисков по ISO/IEC 25010, (3) применение Pod Security Standards и Network Policy, (4) стенд и отчёт валидации.

  Структура: Гл. 1 — теория угроз контейнеров, Гл. 2 — проектирование политик и RBAC, Гл. 3 — тестирование (kube-hunter, Trivy, Falco).

• Тема 2. Встраивание отечественной контейнерной платформы в корпоративный CI/CD-контур.

  Актуальность: спрос на импортозамещённые решения подкреплён регуляторикой. Цель: спроектировать пайплайн сборки-доставки с подписью образов. Задачи: (1) сравнить Kubernetes и «Штурвал» по CRI-совместимости, (2) настроить GitLab CI + Argo CD, (3) внедрить Cosign/Sigstore, (4) измерить время сборки и деплоя.

  Структура: Гл. 1 — обзор рынка, Гл. 2 — архитектура пайплайна, Гл. 3 — нагрузочные и security-тесты.

• Тема 3. Оценка TCO перехода на сертифицированный оркестратор в ИТ-инфраструктуре средней компании.

  Актуальность: ФСТЭК-сертификат расширяет рынок, но стоимость лицензий и обучения — критична. Цель: построить модель TCO и оценить срок окупаемости. Задачи: (1) собрать требования к защищённому контуру, (2) составить сметы на 3 года, (3) рассчитать TCO через NPV, (4) смоделировать сценарий «без сертификации».

  Структура: Гл. 1 — ИТ-роль сертификации, Гл. 2 — финансовая модель, Гл. 3 — анализ чувствительности.

Как интегрировать кейс в главы диплома

Глава 1. Кейс «Штурвала» как обоснование темы

Откройте раздел «Анализ предметной области» и вставьте абзац с датой сертификата и номером №5045. Постройте диаграмму «Контекст C4» (System Context), где в центре — оркестратор, а вокруг — акторы: DevOps-инженер, ИБ-офицер, реестр образов, ФСТЭК-требования. Не растекайтесь по вендорскому маркетингу — фиксируйте функции: планирование, распределение подов, изоляция, аудит.

Глава 2. Проектирование защищённого контура

Здесь уместна UML Deployment-диаграмма: control plane (API-server, etcd, scheduler), worker-ноды, сервис-меш, хранилище секретов. Ниже — пример политики Pod Security и RBAC:

apiVersion: v1
kind: Namespace
metadata:
  name: thesis-demo
  labels:
    pod-security.kubernetes.io/enforce: restricted
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: thesis-demo
  name: reader-only
rules:
  - apiGroups: [""]
    resources: ["pods", "pods/log"]
    verbs: ["get", "list"]

Для главы «ИБ» добавьте DFD-модель: внешние сущности, процессы, хранилища данных, потоки. На её основе стройте таблицу угроз и мер (STRIDE).

Глава 3. Метрики и валидация

Считайте не «сферических коней», а конкретику: время запуска пода (P95), доля отклонённых политикой манифестов, MTTR инцидентов, стоимость часа простоя. Если внедряете OpenTelemetry — покажите трейсы, агрегируйте в Grafana и приложите скриншот дашборда в приложение.

Нормоконтроль и оформление

Ссылки на источники — по ГОСТ Р 7.0.5-2008. Архитектурные решения — по ГОСТ 34.601-90 (стадии) и ГОСТ 19.701-90 (схемы алгоритмов). Метрики качества — маппинг на ISO/IEC 25010 (функциональная полнота, надёжность, защищённость). Не забудьте про список сокращений: CRI, OCI, RBAC, K8s.

Чему вы научитесь на этой теме

• Проектировать отказоустойчивые контейнерные контуры с учётом требований регуляторов.
• Строить модели угроз по STRIDE и OWASP Kubernetes Top 10, а не «на глазок».
• Настраивать RBAC, Pod Security Standards, Network Policy, аудит-логи.
• Встраивать подпись и проверку образов (Cosign/Sigstore) в CI/CD.
• Считать TCO и метрики производительности: P95, MTTR, throughput деплоя.

Источник: Контейнерная платформа «Штурвал» получила сертификат ФСТЭК (опубликовано 2026-03-26)

```