Перейти к основному содержанию
У вас уже есть политика firewall, которой вы доверяете в staging, и вы хотите вторую для production с двумя изменёнными правилами — или вы хотите ужесточить живую политику, не потеряв из виду, что изменилось. Оба — ходы жизненного цикла политики: поднять вторую политику как стартовую точку и опереться на version, который увеличивается при каждом обновлении, чтобы знать, что ваше изменение распространилось. Эта страница — справочник жизненного цикла — ответвление, version, default и включение/отключение/удаление. О первичной настройке см. Создание и привязку; о грамматике правил см. Правила Firewall.
Всё управление политиками происходит в консоли (или через управляющие маршруты /api/workspace/firewall/*, которые аутентифицируются вашей сессией / access-токеном — не ретрансляционным ключом sk-orca-…). Только вызовы вашего агента /v1/* используют ретрансляционный ключ. Создание, редактирование и установка default’ом политики — действия Developer+; чтение списка политик и его version открыто каждому Member.

​
1. Ответвите свою позицию во вторую политику

Нет вердикта «fork» или кнопки копирования — имя политики уникально на рабочее пространство, так что паттерн — поднять вторую, независимо версионируемую политику и расходиться с ней свободно, не трогая оригинал. Два способа её засеять:
1

Создайте новую политику, затем создайте её правила

Откройте Security → Firewall → Policies → New policy. Новая политика создаётся без правил и с выбранным вами default_verdict — создайте её правила в редакторе (или скопируйте несколько из исходной политики вручную). Дайте ей уникальное на рабочее пространство имя (например, prod-firewall рядом с staging-firewall).
2

Или примените шаблон use-case

Галерея Templates (POST /api/workspace/firewall/templates/apply) создаёт одну новую политику плюс все её правила в одной транзакции — Coding, Support, RAG, Data, DevOps, Browser или Baseline. Быстрее, чем создание вручную, когда шаблон совпадает.
3

Разойдитесь и привяжите

Отредактируйте правила новой политики — ужесточите deny деструктивного shell, поменяйте хост egress allow-list — затем привяжите её к production-ключу через firewall_policy_id или пометьте её default рабочего пространства. Исходная политика нетронута.
Вторая политика — безопасный способ протестировать более рискованную позицию. Поднимите одну, включите на ней shadow-режим, привяжите её к одному canary-ключу и наблюдайте за лентой событий — production-политика на каждом другом ключе продолжает применять без изменений.
Каждая политика несёт собственное происхождение, собственный счётчик привязанных ключей и собственную линию version.

​
2. Version, который увеличивается при каждом обновлении

Каждая политика firewall имеет целочисленный version. Он начинается с 1, когда политика создана, и увеличивается на один при каждом обновлении — правка правила, изменение default-вердикта, переключение включения/отключения, переключение shadow-режима. Он монотонен и никогда не сбрасывается. 
// GET /api/workspace/firewall/policies/:id  → (abridged)
{
  "id": 42,
  "name": "prod-firewall",
  "enabled": true,
  "is_default": true,
  "default_verdict": "audit",
  "shadow_mode": false,
  "version": 7,          // bumped from 6 → 7 by your last save
  "rule_count": 11,
  "attached_key_count": 3
}
Version — это ваш сигнал распространения: шлюз кеширует разрешённые политики кратко, и каждое сохранение инвалидирует этот кеш, так что ваша правка вступает в силу на привязанных ключах за секунды — без передеплоя, без изменений в коде агента. version не управляет кешем; это монотонный счётчик изменений, который вы считываете обратно. Когда вы сохраняете политику и хотите подтвердить, что изменение живое, перечитайте политику и проверьте, что version продвинулся.
version политики — счётчик изменений, не точка восстановления. Он говорит вам, что политика изменилась, и позволяет шлюзу распространить правку — это не diff по версиям и не откат. Полная версионированная история с diff и откатом в один клик — эта возможность живёт на Guardrails: GET /api/guardrail/:id/history, …/history/diff и POST /api/guardrail/:id/revert (revert — Developer+). Для политик firewall ваш аудит-трейл и сохранение понижённой known-good политики в списке — это то, чем вы сохраняете точку восстановления — см. §5.

​
3. Задайте и переместите default рабочего пространства

Рабочее пространство может пометить одну политику как default. Каждый ключ без собственного firewall_policy_id разрешается к ней (порядок разрешения).
  • Отредактируйте политику и установите её default’ом рабочего пространства. Продвижение нового default’а понижает старый в той же транзакции — никогда нет окна с двумя default’ами и никогда окна без них в середине переключения.
  • Поднятие второй политики — чистый способ прокатить default вперёд: постройте новую политику, подстройте, валидируйте под shadow-режимом, затем продвиньте её. Старый default остаётся в списке, понижённый, как ваш fallback.
Перемещение default’а меняет применение для каждого непривязанного ключа сразу. Если новый default ужесточает default_verdict до deny, вызовы, которые ваши правила явно не разрешают, начинают блокироваться немедленно. Разверните новый default за shadow-режимом и понаблюдайте за Events, прежде чем продвигать его.

​
4. Включение, отключение и удаление

Переключение Enabled в «выкл» останавливает разрешение политики. Но помните о firewall fall-through: ключ, чья привязанная политика отключена, откатывается к default рабочего пространства — отключение не выводит ключ из области firewall. Чтобы убрать ключ из применения, отвяжите его (установите firewall_policy_id в 0), а не просто отключайте его политику. (Это отличается от guardrails, где отключённая привязка разрешается в none.)
DELETE /api/workspace/firewall/policies/:id (Developer+) удаляет политику — но возвращает 409, если какой-либо ключ всё ещё на неё ссылается. Сначала отвяжите или перенаправьте эти ключи, затем удаляйте. Эта защита — причина, почему поднятие второй политики, а не переписывание на месте, — более безопасный способ эволюционировать политику, от которой зависят живые ключи.
Имя политики уникально внутри рабочего пространства, так что второй политике нужно новое имя. Используйте конвенцию, которая переживает жизненный цикл — staging-firewall / prod-firewall или суффикс с датой — а не policy-copy-2.

​
5. Аудит-трейл

Каждое создание, обновление (которое включает продвижение default’а или переключение shadow-режима) и удаление политики пишет строку аудита — и строку рабочего пространства, и центральную admin-строку — после коммита изменения. Неудачное сохранение (дубликат имени, недействительный вердикт) не пишет ничего. Блобы правил и секреты никогда не пишутся в журнал аудита. Так что хотя политики firewall не несут собственной истории diff-and-revert, аудит-трейл говорит вам, кто изменил какую политику, когда, а монотонный version говорит вам, сколько раз она менялась. Сочетайте это с сохранением понижённой, known-good политики в списке, и у вас есть практический путь восстановления.

​
6. Жизненный цикл с одного взгляда

ДействиеМаршрутРоль
Список политик (+ version, счётчики)GET /api/workspace/firewall/policiesMember
Прочитать одну политикуGET /api/workspace/firewall/policies/:idMember
Создать политику (без правил)POST /api/workspace/firewall/policiesDeveloper+
Применить шаблон (политика + правила)POST /api/workspace/firewall/templates/applyDeveloper+
Обновить (увеличивает version)PUT /api/workspace/firewall/policiesDeveloper+
Удалить (409, если ключи привязаны)DELETE /api/workspace/firewall/policies/:idDeveloper+
Прежде чем полагаться на новую или свежепродвинутую политику, прогоните её вхолостую во вкладке песочницы Test — она возвращает вердикт, совпавшее правило и причину, ничего не диспетчеризуя. См. Тестирование правил.

​
Куда двигаться дальше

Создать и привязать

Путь первичной настройки — создайте политику и направьте на неё ключ.

Shadow-режим

Разверните новую или переназначенную default’ом политику без изменения живого трафика.

Firewall + Guardrails

Как политики действий компонуются с текстовыми guardrails — и где живёт версионированный откат.

Область: ключи, политики, рабочие пространства

Как разрешаются привязка и default рабочего пространства.