跳轉到主要內容
你已經有一個你在 staging 中信任的防火牆政策, 而你想要第二個給生產用、改動兩條規則——或者你想收緊即時政策而不 失去對改了什麼的追蹤。兩者都是政策生命週期的動作:立起第二個 政策作為起點,並倚賴每次更新都遞增的版本來知道你的變更傳播了。 本頁是生命週期參考——分支、版本、預設值,以及啟用/停用/刪除。關於 初次設定,參見建立與綁定; 關於規則文法,參見防火牆規則。
所有政策管理都發生在主控台中（或 /api/workspace/firewall/* 管理路由,後者以你的工作階段／存取權杖驗證——而非一個中繼 sk-orca-… 金鑰）。只有你代理的 /v1/* 呼叫使用中繼金鑰。建立、 編輯與設定一個政策的預設值是 Developer+ 動作;讀取政策清單與 它的版本對每個 Member 開放。

​
1. 把你的姿態分支成第二個政策

沒有「fork」裁決或複製按鈕——一個政策名稱在每個工作區內唯一,所以 這套模式是立起第二個獨立版本控制的政策,並自由地讓它分歧而不 觸及原本的那個。播種它有兩種方式：
1

建立新政策,然後撰寫它的規則

開啟 Security → Firewall → Policies → New policy。一個新政策會 以沒有規則與你選擇的 default_verdict 建立——在編輯器中撰寫 它的規則（或從來源政策手動複製幾條過來）。給它一個工作區內唯一的 名稱（例如 prod-firewall 旁邊有 staging-firewall）。
2

或套用一個使用情境範本

Templates 圖庫（POST /api/workspace/firewall/templates/apply） 在單一交易中建立一個新政策加上它所有的規則——Coding、Support、 RAG、Data、DevOps、Browser,或 Baseline。當一個範本相符時比手動 撰寫更快。
3

分歧並綁定

編輯新政策的規則——收緊破壞性 shell 的 deny、換掉一個 egress 允許清單主機——然後透過 firewall_policy_id 將它綁定到生產金鑰, 或將它標記為工作區預設值。來源政策不受觸動。
第二個政策是測試一個風險較高姿態的安全方式。立起一個、在它上面 開啟影子模式、把它綁定到一個 金絲雀金鑰,並觀察事件動態——其他每個金鑰上的生產政策都不變地繼續 強制執行。
每個政策攜帶它自己的來源、它自己的已綁定金鑰計數,以及它自己的 版本線。

​
2. 每次更新都遞增的版本

每個防火牆政策都有一個 version 整數。它在政策被建立時從 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. 設定並移動工作區預設值

一個工作區可以標記一個政策作為預設值。每個沒有自己 firewall_policy_id 的金鑰都解析到它 （解析順序）。
  • 編輯一個政策並將它設為工作區預設值。晉升一個新的預設值會在 同一交易中降級舊的那個——絕不會有一個有兩個預設值的窗口,也絕不 會有一個在交換中途沒有預設值的窗口。
  • 立起第二個政策是把預設值向前滾動的一個乾淨方式:建構新政策、 調整、在影子模式下驗證,然後晉升它。舊的預設值留在清單中、被降級, 作為你的回退。
移動預設值會一次改變每個未綁定金鑰的強制執行。如果新的預設值 把 default_verdict 收緊為 deny,你的規則未明確允許的呼叫會立即 開始被封鎖。在影子模式後方 推出一個新的預設值,並在你晉升它之前觀察 Events。

​
4. 啟用、停用與刪除

把 Enabled 切換為關閉會停止一個政策解析。但記住防火牆的 落空行為:一個其綁定政策被停用的金鑰會回退到工作區預設值 ——停用不會把該金鑰移出防火牆範圍。要把一個金鑰從強制執行中 移除,解除它的綁定（將 firewall_policy_id 設為 0）,不要只是 停用它的政策。（這與防護欄不同,後者中一個已停用的綁定會解析 為無。）
DELETE /api/workspace/firewall/policies/:id（Developer+）會移除 一個政策——但如果任何金鑰仍參照它,會傳回 409。先解除那些 金鑰的綁定或將它們重新指向,然後刪除。這個防護就是為什麼立起 第二個政策,而非就地改寫,是演進一個即時金鑰所依賴的政策的更 安全方式。
一個政策名稱在一個工作區內唯一,所以第二個政策需要一個新名稱。 使用一個能在生命週期中存活的慣例——staging-firewall / prod-firewall,或一個日期後綴——而非 policy-copy-2。

​
5. 稽核軌跡

每一次政策建立、更新（包含一次預設值晉升或一次影子模式翻轉)與 刪除,都會在變更提交之後寫入一筆稽核列——一筆工作區列與一筆 中央 admin 列。一次失敗的儲存（重複名稱、無效裁決）什麼都不寫。 規則 blob 與密鑰絕不被寫入稽核記錄。 所以即使防火牆政策不攜帶它們自己的 diff-and-revert 歷史,稽核軌跡 也會告訴你誰在何時改了哪個政策,而單調的 version 告訴你它已 改變多少次。把那與在清單中保留一個被降級的已知良好政策搭配, 你就有了一條實用的還原路徑。

​
6. 生命週期一覽

動作路由角色
列出政策（+ 版本、計數）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 分頁中乾跑它——它 傳回裁決、匹配到的規則與原因,而不派發任何東西。參見 測試規則。

​
接下來去哪裡

建立與綁定

初次設定路徑——建立一個政策並把一個金鑰指向它。

影子模式

推出一個新的或重新設為預設的政策而不改變即時流量。

防火牆 + 防護欄

動作政策如何與文字防護欄組合——以及版本化還原存在於哪裡。

範圍：金鑰、政策、工作區

綁定與工作區預設值如何解析。