О системе — лицензия, версионирование и обновления

Раздел О системе имеет две вторичные вкладки: Лицензия и Обновление. (Вкладки Тенанты у него больше нет — она переехала в Федерацию.) Этот раздел также объясняет, как SOARForge версионируется и как boot-time schema guard защищает инсталляцию при обновлениях.

7.1. Лицензия

Маршрут: /settings/about/license · Право: settings.view

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

Детали: Cluster ID (копируемый), Product version (+ короткий git SHA), Issued to, Status (active / expired / lockdown / none), Expires at, Days remaining. Licensed Modules — теги с галочкой (лицензирован) или замком (не лицензирован) для cases, threat_intel, multi_tenancy и grc. Бары использования Analysts и Events today. Кнопка Upload New (только админ) — активировать новую лицензию (вставить ключ). Предупреждение, когда до истечения остаётся <30 дней.

Лицензирование — Ed25519 + привязка по fingerprint. Только EdDSA (без RS256); лицензия без payload.fingerprint невалидна. Лицензия проприетарная — не меняйте метаданные license без согласования с владельцем.

7.2. Модель релизов и версионирование

Почему это важно. SOARForge поставляется набором неизменяемых образов с проставленной версией. Знание того, что версия зафиксирована до следующего деплоя — рестарт не может её тихо сменить — делает обновления предсказуемыми, а откаты безопасными.

• Одна проставленная версия на инсталляцию. Каждый продуктовый образ помечен тегом vX.Y.Z и несёт свою продуктовую версию, git SHA, Prisma migration head и метку времени сборки. GET /api/v1/system/version (только админ) возвращает { version, gitSha, migrationHead, builtAt }; те же значения рисуются на вкладках «Лицензия» и «Обновление».
• Неизменяемые теги — рестарт не меняет версию. Манифесты Kubernetes пинят наши образы soarforge-* на явный :vX.Y.Z (никогда :latest), поэтому рестарт пода не может подтянуть более новую сборку. На Compose закреплённый релиз запускается через SOAR_VERSION=vX.Y.Z docker compose pull && up -d (обычный docker compose up собирает локальный dev-образ). Версия сдвигается только когда оператор деплоит следующий релиз.
• Синхрон frontend/backend. Фронтовый бандл несёт свою версию сборки; если она отличается от backend, вкладка «Обновление» показывает бейдж mismatch — завершите раскатку (передеплой / set image фронтенда).

7.3. О системе → Обновление — советник по обновлению

Маршрут: /settings/about/upgrade · Право: platform-admin (тот же гейт, что и GET /system/version); действия (Check now, Upload manifest, тумблер) требуют settings.manage.

Почему это важно. Вкладка «Обновление» — «кабина» оператора для поддержания актуальности: показывает, что вы запускаете сейчас, какие релизы доступны (и что каждый мигрирует), и даёт копируемый runbook обновления под вашу модель развёртывания — всегда с напоминанием «сначала бэкап».

На странице четыре карточки:

1. This installation. Продуктовая версия (+ короткий git SHA, тег dev build для сборок без штампа), DB migration head, версия Frontend bundle (с бейджем mismatch, когда она отличается от backend) и — при федерации — Federation nodes (connected / known).

2. Available updates.

• Check now — немедленно перечитать ленту релизов (админ, settings.manage).
• Upload manifest — путь для air-gap (см. ниже).
• Строка «Last checked … (feed / manual upload)» или «The release feed has not been checked yet.»
• Если вы актуальны: «You are on the latest release.» Для dev-сборки показана инфо-заметка, что все выпущенные версии перечислены как более новые.
• Каждый доступный релиз — карточка: версия, дата публикации, дельта миграций («Applies N migration(s): …» или «No schema changes»), опциональная ссылка Release notes и — когда прыжок напрямую не разрешён — бейдж «stepwise upgrade required» с «Upgrade to first before jumping to .»

3. Upgrade runbook. Выберите целевую версию и модель развёртывания (Kubernetes / Compose / Swarm — запоминается в браузере); страница рисует точные копируемые команды с подставленной версией и кнопкой Copy. Первая строка всегда — напоминание о бэкапе («BACK UP THE DATABASE FIRST — take a verified snapshot before applying migrations.»). По моделям:

• Kubernetes — пересоздать migration Job soar-db-bootstrap, запиненный на целевой тег, дождаться его завершения, затем kubectl set image для каждого продуктового deployment (soar-core: case-api, indicator-extraction, playbook, ingest, outbox, outbox-extraction, frontend; soar-automation: integration-runtime, listener-host).
• Compose — SOAR_VERSION=vX.Y.Z docker compose pull && up -d (сервис soar-db-bootstrap авто-применяет миграции до старта case-api).
• Swarm — docker stack deploy или per-service docker service update на целевой тег.

4. Daily update check (тумблер). Когда включён, SOARForge проверяет подписанную ленту релизов раз в день. Когда выключен — ноль исходящих вызовов, используйте вместо этого air-gap-загрузку манифеста. По умолчанию включён.

Air-gap-загрузка манифеста. Для отключённых инсталляций Upload manifest принимает содержимое подписанного release-vX.Y.Z.json. Подпись проверяется по Ed25519 против встроенного релизного ключа; неподписанные, чужие или подделанные манифесты отвергаются. Проверенная ручная загрузка имеет приоритет над фоновой проверкой ленты.

Как это читать. Советник только советует — он никогда не изменяет кластер. Runbook вы по-прежнему выполняете сами (kubectl / compose / swarm). Всегда сначала делайте проверенный бэкап БД и идите пошагово, если релиз этого требует.

7.4. Boot-time schema guard — страж схемы при старте

Почему это важно. Schema guard — страховка за обновлениями: даже если развёрнут «съехавший» образ, процесс отказывается обслуживать несогласованную схему вместо выдачи 500-ок. Он превращает «забыл накатить миграцию» в громкий, очевидный crash-loop.

При старте каждый процесс, поднимающий приложение (case-api и воркеры из образа case-api), сравнивает свой встроенный migration head с применённым head в БД до приёма трафика или потребления очереди. Исходы:

• DB behind образа (the DATABASE IS BEHIND this image) — образ новее схемы. Фикс: запустить migration Job (k8s/Swarm) или дать завершиться soar-db-bootstrap (Compose); затем под поднимается. Job/сервис soar-db-bootstrap выполняет prisma migrate deploy и никогда не блокируется guard-ом.
• DB ahead образа (the DATABASE IS AHEAD of this image) — образ старше схемы (риск отката). Фикс: задеплоить более новую версию или восстановить бэкап, совпадающий с этим образом — не форсируйте старт.

SCHEMA_GUARD_MODE по умолчанию strict (отказ стартовать при любом дрейфе); warn громко логирует и продолжает (осознанное окно временного дрейфа); off пропускает проверку (крайний случай, не для устойчивого прода). Детали для оператора: docs/ops/01-deployment-guide.md §4.4 и docs/ops/04-runbook.md («Schema guard refusal»).

---