メインコンテンツへスキップ
ステージングで信頼しているファイアウォールポリシーがすでに あり、本番用にルールを 2 つ変えた 2 つ目が欲しい — あるいは何が変わったかを見失わずに ライブポリシーを締めたい。どちらもポリシーのライフサイクルの動きです：開始点として 2 つ目のポリシーを立ち上げ、すべての更新でインクリメントするバージョンに頼って 変更が伝播したことを知ります。 このページはライフサイクルリファレンスです — 分岐、バージョン、デフォルト、 有効化/無効化/削除。初回セットアップについては 作成 & アタッチを；ルール文法については ファイアウォールルールを参照してください。
すべてのポリシー管理はコンソール（または /api/workspace/firewall/* 管理ルート。 これらはセッション / アクセストークンで認証し、リレーの sk-orca-… キー ではありません）で行われます。エージェントの /v1/* 呼び出しのみがリレーキーを 使います。ポリシーの作成、編集、デフォルト化は Developer+ のアクションです； ポリシーリストとそのバージョンの読み取りはすべての Member に開放されています。

​
1. 姿勢を 2 つ目のポリシーに分岐する

「フォーク」判定もコピーボタンもありません — ポリシー名はワークスペースごとに一意なので、 パターンは独立してバージョン管理される 2 つ目のポリシーを立ち上げ、元に触れずに 自由に発散させることです。それをシードする 2 つの方法：
1

新しいポリシーを作成し、それからルールを作成する

Security → Firewall → Policies → New policy を開きます。新しいポリシーは ルールなしとあなたが選んだ default_verdict で作成されます — そのルールを エディタで作成します（または元のポリシーからいくつかを手でコピーします）。 ワークスペース内で一意の名前を付けます（例：staging-firewall の隣に prod-firewall）。
2

またはユースケーステンプレートを適用する

Templates ギャラリー（POST /api/workspace/firewall/templates/apply）は、 1 つの新しいポリシーに加えてそのすべてのルールを単一のトランザクションで作成 します — Coding、Support、RAG、Data、DevOps、Browser、または Baseline。 テンプレートがマッチするとき、手作成より高速です。
3

発散させてアタッチする

新しいポリシーのルールを編集します — 破壊的シェルの deny を締める、egress 許可 リストのホストを入れ替える — それから firewall_policy_id 経由で本番キーにアタッチ するか、ワークスペースデフォルトにマークします。元のポリシーは手を加えられません。
2 つ目のポリシーは、よりリスクのある姿勢をテストする安全な方法です。1 つを立ち上げ、 それでシャドウモードをオンにし、1 つのカナリア キーにアタッチし、events フィードを監視します — 他のすべてのキーの本番ポリシーは変更 なく強制し続けます。
各ポリシーは独自の来歴、独自のアタッチ済みキー数、独自のバージョン行を運びます。

​
2. すべての更新でインクリメントするバージョン

すべてのファイアウォールポリシーは version 整数を持ちます。ポリシーが作成される ときに 1 から始まり、すべての更新で 1 ずつインクリメントします — ルール編集、 デフォルト判定の変更、有効化/無効化の切り替え、シャドウモードの切り替え。それは単調で、 決してリセットされません。 
// 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 は変更カウンタであり、復元ポイントではありません。 それは ポリシーが変わったことを教え、ゲートウェイが編集を伝播できるようにします — それは バージョンごとの diff やロールバックではありません。diff とワンクリックリバートを 伴う完全なバージョン履歴については、その機能はガードレールに 存在します：GET /api/guardrail/:id/history、…/history/diff、 POST /api/guardrail/:id/revert（リバートは Developer+）。ファイアウォールポリシーに ついては、監査証跡と、降格された既知の良好なポリシーをリストに保つことが、復元ポイントを 保つ方法です — §5 を参照。

​
3. ワークスペースデフォルトを設定して移動する

ワークスペースは1 つのポリシーをデフォルトにマークできます。独自の firewall_policy_id のないすべてのキーがそれに解決します （解決順序）。
  • ポリシーを編集し、それをワークスペースデフォルトに設定します。新しいデフォルトの プロモートは同じトランザクション内で古いものを降格します — 2 つのデフォルトが ある窓も、入れ替え途中で 1 つもない窓も決してありません。
  • 2 つ目のポリシーを立ち上げることは、デフォルトを前に転がすクリーンな方法です： 新しいポリシーを構築し、調整し、シャドウモードのもとで検証し、それからプロモート します。古いデフォルトは降格されてリストに残り、フォールバックになります。
デフォルトの移動は、すべてのアタッチされていないキーの強制を一度に変えます。新しい デフォルトが default_verdict を deny に締めると、ルールが明示的に許可しない呼び出しは 即座にブロックを開始します。新しいデフォルトはシャドウモードの 背後でロールアウトし、プロモートする前にEventsを 監視してください。

​
4. 有効化、無効化、削除

Enabled をオフに切り替えると、ポリシーが解決するのを止めます。しかし ファイアウォールのフォールスルーを忘れないでください：アタッチ済みポリシーが 無効化されたキーはワークスペースデフォルトにフォールバックします — 無効化は キーをファイアウォールのスコープから外しません。キーを強制から取り除くには、それを デタッチします（firewall_policy_id を 0 に設定）、ポリシーをただ無効に するのではなく。（これはガードレールとは異なります。ガードレールでは無効化された アタッチメントはnone に解決されます。）
DELETE /api/workspace/firewall/policies/:id（Developer+）はポリシーを削除します — しかし、いずれかのキーがまだそれを参照している場合 409 を返します。それらの キーを先にデタッチまたは再ポイントし、それから削除します。このガードが、インプレースの 書き換えではなく 2 つ目のポリシーを立ち上げることが、ライブキーが依存するポリシーを 進化させるより安全な方法である理由です。
ポリシー名はワークスペース内で一意なので、2 つ目のポリシーは新しい名前を必要と します。policy-copy-2 ではなく、ライフサイクルを生き延びる規約 — staging-firewall / prod-firewall、または日付サフィックス — を使います。

​
5. 監査証跡

すべてのポリシーの作成、更新（デフォルトプロモートやシャドウモードの切り替えを含む）、 削除は、変更がコミットされた後に監査行 — ワークスペース行とセントラル管理者行の 両方 — を書き込みます。失敗した保存（重複名、無効な判定）は何も書き込みません。ルール blob とシークレットは決して監査ログに書き込まれません。 そのため、ファイアウォールポリシーが独自の diff-and-revert 履歴を運ばなくても、監査 証跡は誰がどのポリシーをいつ変えたかを教え、単調な version は何回変わったかを 教えます。それを、降格された既知の良好なポリシーをリストに保つことと組み合わせれば、 実践的な復元パスが手に入ります。

​
6. ライフサイクル概観

アクションルートロール
ポリシーをリスト（+ バージョン、カウント）GET /api/workspace/firewall/policiesMember
1 つのポリシーを読み取り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 タブでそれをドライランします — 何もディスパッチせずに判定、マッチしたルール、理由を 返します。ルールのテストを参照。

​
次に進む場所

作成 & アタッチ

初回セットアップのパス — ポリシーを作成し、キーをそれに向けます。

シャドウモード

新しいまたは再デフォルト化されたポリシーを、ライブトラフィックを変えずにロール アウト。

ファイアウォール + ガードレール

アクションポリシーがテキストガードレールとどう合成されるか — そしてバージョン管理 されたリバートがどこに存在するか。

スコープ：キー、ポリシー、ワークスペース

アタッチメントとワークスペースデフォルトがどう解決するか。