Chuyển đến nội dung chính
Bạn đã có một chính sách firewall mà bạn tin ở staging, và bạn muốn một cái thứ hai cho production với hai quy tắc thay đổi — hoặc bạn muốn siết chặt chính sách live mà không mất dấu cái gì đã thay đổi. Cả hai là các động tác vòng-đời chính sách: dựng một chính sách thứ hai làm điểm khởi đầu, và dựa vào version tăng trên mỗi cập nhật để biết thay đổi của bạn đã lan truyền. Trang này là tham chiếu vòng đời — phân nhánh, version, mặc định, và bật/tắt/xóa. Để biết thiết lập lần-đầu, xem Tạo & gắn; để biết ngữ pháp quy tắc, xem Quy tắc Firewall.
Toàn bộ quản lý chính sách xảy ra trong console (hoặc các route quản lý /api/workspace/firewall/*, vốn xác thực bằng session / access token của bạn — không phải một relay key sk-orca-…). Chỉ các cuộc gọi /v1/* của agent bạn dùng relay key. Tạo, chỉnh sửa, và đặt-mặc-định một chính sách là các hành động Developer+; đọc danh sách chính sách và version của nó mở cho mọi Member.

​
1. Phân nhánh tư thế của bạn thành một chính sách thứ hai

Không có verdict “fork” hay nút copy — một tên chính sách là duy nhất theo workspace, nên mẫu là dựng một chính sách thứ hai, được version độc lập và cho nó rẽ nhánh tự do mà không động đến cái gốc. Hai cách để gieo nó:
1

Tạo chính sách mới, rồi soạn các quy tắc của nó

Mở Security → Firewall → Policies → New policy. Một chính sách mới được tạo với không quy tắc và default_verdict bạn chọn — soạn các quy tắc của nó trong trình chỉnh sửa (hoặc copy vài cái từ chính sách nguồn bằng tay). Đặt cho nó một tên duy-nhất-theo-workspace (vd: prod-firewall bên cạnh staging-firewall).
2

Hoặc áp dụng một template tình huống dùng

Gallery Templates (POST /api/workspace/firewall/templates/apply) tạo một chính sách mới cộng mọi quy tắc của nó trong một transaction duy nhất — Coding, Support, RAG, Data, DevOps, Browser, hoặc Baseline. Nhanh hơn soạn-tay khi một template khớp.
3

Rẽ nhánh và gắn

Chỉnh sửa các quy tắc của chính sách mới — siết chặt deny destructive-shell, đổi một host egress allow-list — rồi gắn nó vào key production qua firewall_policy_id, hoặc đánh dấu nó làm mặc định workspace. Chính sách nguồn không bị động đến.
Một chính sách thứ hai là cách an toàn để test một tư thế rủi ro hơn. Dựng một cái, bật shadow mode trên nó, gắn nó vào một canary key, và quan sát events feed — chính sách production trên mọi key khác vẫn thực thi không đổi.
Mỗi chính sách mang xuất xứ riêng, số đếm key-được-gắn riêng, và dòng version riêng.

​
2. Version tăng trên mỗi cập nhật

Mỗi chính sách firewall có một số nguyên version. Nó bắt đầu ở 1 khi chính sách được tạo và tăng một trên mỗi cập nhật — một lần chỉnh quy tắc, một thay đổi verdict-mặc-định, một toggle bật/tắt, một lần lật shadow-mode. Nó đơn điệu và không bao giờ reset. 
// 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 là tín hiệu lan truyền của bạn: gateway cache các chính sách đã phân giải trong thời gian ngắn, và mỗi lần lưu vô hiệu hóa cache đó nên chỉnh sửa của bạn có hiệu lực trên các key được gắn trong vài giây — không redeploy, không đổi code agent. version không điều khiển cache; nó là một bộ đếm thay đổi đơn điệu mà bạn đọc lại. Khi bạn lưu một chính sách và muốn xác nhận thay đổi là live, đọc lại chính sách và kiểm tra rằng version đã tiến.
version của chính sách là một bộ đếm thay đổi, không phải một điểm khôi phục. Nó cho bạn biết rằng chính sách đã thay đổi và để gateway lan truyền chỉnh sửa — nó không phải một diff hay rollback theo-từng-version. Để có lịch sử có version với diff và revert một-cú-nhấp, khả năng đó nằm ở Guardrails: GET /api/guardrail/:id/history, …/history/diff, và POST /api/guardrail/:id/revert (revert là Developer+). Với các chính sách firewall, audit trail của bạn và việc giữ một chính sách đã-hạ-cấp known-good trong danh sách là cách bạn bảo toàn một điểm khôi phục — xem §5.

​
3. Đặt và di chuyển mặc định workspace

Một workspace có thể đánh dấu một chính sách làm mặc định. Mọi key không có firewall_policy_id riêng phân giải về nó (thứ tự phân giải).
  • Chỉnh sửa một chính sách và đặt nó làm mặc định workspace. Thăng cấp một mặc định mới hạ cấp cái cũ trong cùng transaction — không bao giờ có một cửa sổ với hai mặc định, và không bao giờ một cửa sổ với không cái nào giữa-lúc- đổi.
  • Dựng một chính sách thứ hai là một cách sạch để lăn mặc định về phía trước: xây chính sách mới, điều chỉnh, xác nhận dưới shadow mode, rồi thăng cấp nó. Mặc định cũ ở lại danh sách, đã hạ cấp, làm fallback của bạn.
Di chuyển mặc định thay đổi việc thực thi cho mọi key chưa-gắn cùng lúc. Nếu mặc định mới siết chặt default_verdict thành deny, các cuộc gọi mà các quy tắc của bạn không allow tường minh bắt đầu bị block ngay lập tức. Triển khai một mặc định mới đằng sau shadow mode và quan sát Events trước khi bạn thăng cấp nó.

​
4. Bật, tắt, và xóa

Bật Enabled off dừng một chính sách khỏi phân giải. Nhưng nhớ fall-through của firewall: một key mà chính sách được gắn của nó bị tắt rơi về mặc định workspace — tắt không đưa key ra khỏi phạm vi firewall. Để loại bỏ một key khỏi việc thực thi, gỡ nó (đặt firewall_policy_id thành 0), đừng chỉ tắt chính sách của nó. (Cái này khác với guardrails, nơi một liên kết bị tắt phân giải về không có.)
DELETE /api/workspace/firewall/policies/:id (Developer+) gỡ một chính sách — nhưng trả về 409 nếu bất kỳ key nào vẫn tham chiếu nó. Gỡ hoặc trỏ-lại các key đó trước, rồi xóa. Bảo vệ này là lý do tại sao dựng một chính sách thứ hai, không phải viết-lại-tại-chỗ, là cách an toàn hơn để tiến hóa một chính sách mà các key live phụ thuộc.
Một tên chính sách là duy nhất trong một workspace, nên một chính sách thứ hai cần một tên mới. Dùng một quy ước sống sót qua vòng đời — staging-firewall / prod-firewall, hoặc một hậu tố ngày — thay vì policy-copy-2.

​
5. Audit trail

Mỗi lần tạo, cập nhật (vốn bao gồm một lần thăng-cấp-mặc-định hoặc một lần lật shadow-mode), và xóa chính sách ghi một dòng audit — cả một dòng workspace và một dòng admin trung tâm — sau khi thay đổi commit. Một lần lưu thất bại (trùng tên, verdict không hợp lệ) không ghi gì. Các blob quy tắc và secret không bao giờ được viết vào audit log. Vậy nên dù các chính sách firewall không mang lịch sử diff-và-revert riêng, audit trail cho bạn biết ai thay đổi chính sách nào, khi nào, và version đơn điệu cho bạn biết nó đã thay đổi bao nhiêu lần. Ghép cái đó với việc giữ một chính sách đã-hạ-cấp, known-good trong danh sách, và bạn có một đường khôi phục thực tế.

​
6. Vòng đời trong nháy mắt

Hành độngRouteVai trò
Liệt kê chính sách (+ version, số đếm)GET /api/workspace/firewall/policiesMember
Đọc một chính sáchGET /api/workspace/firewall/policies/:idMember
Tạo chính sách (không quy tắc)POST /api/workspace/firewall/policiesDeveloper+
Áp dụng một template (chính sách + quy tắc)POST /api/workspace/firewall/templates/applyDeveloper+
Cập nhật (tăng version)PUT /api/workspace/firewall/policiesDeveloper+
Xóa (409 nếu có key được gắn)DELETE /api/workspace/firewall/policies/:idDeveloper+
Trước khi dựa vào một chính sách mới hoặc vừa-thăng-cấp, chạy thử nó trong tab sandbox Test — nó trả về verdict, quy tắc đã khớp, và lý do mà không dispatch gì. Xem Test quy tắc.

​
Đi đâu tiếp theo

Tạo & gắn

Đường thiết lập lần-đầu — tạo một chính sách và trỏ một key vào nó.

Shadow mode

Triển khai một chính sách mới hoặc đặt-lại-mặc-định mà không thay đổi traffic live.

Firewall + Guardrails

Cách các chính sách hành động kết hợp với guardrail văn bản — và nơi revert có-version nằm.

Phạm vi: key, chính sách, workspace

Cách liên kết và mặc định workspace phân giải.