Chuyển đến nội dung chính
Khi hai quy tắc cùng có thể khớp một cuộc gọi tool, ưu tiên quy tắc firewall quyết định cái nào thắng. Một chính sách firewall là một danh sách quy tắc có thứ tự — engine duyệt chúng theo thứ tự ưu tiên, dừng ở cái đầu tiên khớp, và áp dụng verdict của nó. Sắp đúng thứ tự thì một bộ canh rộng cộng một ngoại lệ hẹp cùng tồn tại sạch sẽ; sắp sai thì quy tắc rộng nuốt mất ngoại lệ bạn định khoét ra. Trang này là tham chiếu tập trung cho việc sắp thứ tự. Để biết toàn bộ ngữ pháp quy tắc, xem Quy tắc Firewall; để biết các verdict mà một quy tắc có thể tạo ra, xem Verdict.

​
1. Thứ tự: ưu tiên tăng dần, match đầu tiên thắng

Trong một chính sách, các quy tắc được đánh giá theo thứ tự priority ASC, id ASC:
  1. priority thấp hơn chạy trước. Một quy tắc với priority: 0 được kiểm tra trước một cái với priority: 10. Hãy nghĩ về nó như một vị trí trong hàng đợi, không phải một điểm sức mạnh — số nhỏ hơn được nói trước.
  2. Hòa thì phân giải theo rule id. Hai quy tắc ở cùng priority chạy theo thứ tự tạo (rule id tăng dần), nên quy tắc cũ hơn thắng lúc hòa. Dùng các ưu tiên riêng biệt khi thứ tự thực sự quan trọng thay vì dựa vào phân-giải-hòa theo id.
  3. Match đầu tiên thắng. Engine dừng ở quy tắc đầu tiên mà các điều kiện của nó tất cả đúng và áp dụng verdict của nó. Các quy tắc xa hơn trong danh sách không bao giờ được hỏi cho cuộc gọi đó.
  4. Không match → verdict mặc định. Nếu không gì khớp, default_verdict của chính sách áp dụng — audit trừ khi bạn đã đổi nó.
Một quy tắc chỉ khớp khi mọi điều kiện được khai báo đúng cùng lúc: bề mặt, glob tên-tool, glob skill tùy chọn, các mệnh đề argument tùy chọn, và phạm vi egress (chỉ quy tắc egress). Một match một phần là không-match, và việc đánh giá chuyển sang quy tắc kế tiếp.

​
2. Một ví dụ cụ thể: cụ thể trước rộng

Công việc sắp-thứ-tự điển hình là để một allow hẹp sống sót qua một deny rộng. Đặt quy tắc cụ thể ở một ưu tiên thấp hơn để nó được tới trước: 
// Rule A — priority 10: trust this one exact tool.
{ "label": "allow safe shell", "priority": 10,
  "tool_name_glob": "shell.echo", "verdict": "allow" }

// Rule B — priority 20: block the rest of the shell family.
{ "label": "block shell family", "priority": 20,
  "tool_name_glob": "shell.*", "verdict": "deny" }
Một cuộc gọi tới shell.echo chạm Rule A trước (priority 10), khớp, và được allow — engine không bao giờ tới Rule B. Một cuộc gọi tới shell.exec rơi qua A (glob không khớp), chạm Rule B, và bị deny. Lật các ưu tiên và deny shell.* rộng ở priority 10 sẽ bắt shell.echo trước, và allow của bạn ở priority 20 sẽ là dead code. Quy tắc kinh nghiệm: cụ thể nhất trước, rộng nhất cuối.
Đừng phụ thuộc vào phân-giải-hòa theo id cho việc này. Nếu allow và deny chia sẻ cùng priority, người thắng là quy tắc nào bạn tạo trước — một thứ tự mong manh âm thầm lật nếu bạn xóa và tạo lại một quy tắc. Cho quy tắc cụ thể một priority thấp hơn và ý định là tường minh.

​
3. Xác minh thứ tự trước khi bạn phụ thuộc vào nó

Suy luận về ưu tiên trên giấy dễ sai một khi một chính sách có hơn một nhúm quy tắc. Sandbox Test chạy engine thật trên một cuộc gọi tool mẫu và cho bạn biết không chỉ verdict mà còn quy tắc nào thắng — nên bạn có thể xác nhận quy tắc bạn mong đợi thực sự kích hoạt:
1

Mở tab Test của chính sách

Trong console, mở chính sách và chuyển sang Test (Developer+).
2

Gửi một cuộc gọi mẫu

Nhập một tên tool (và đối số, nếu các quy tắc của bạn kiểm tra chúng) và chạy nó. Không gì được dispatch và không gì được lưu — đó là một chạy thử.
3

Đọc quy tắc đã khớp

Kết quả nêu tên verdict, quy tắc đã khớp (theo nhãn/id), và lý do. Nếu một quy tắc rộng thắng ở nơi bạn mong đợi một cái hẹp, hạ priority của quy tắc hẹp và test lại.
Xem Test quy tắc để biết toàn bộ sandbox, và Quản lý chính sách để chỉnh sửa thứ tự quy tắc tại chỗ.

​
4. Thực thi skill chồng lên trên

Ưu tiên quy tắc quyết định verdict của quy tắc thắng — nhưng đó không phải lúc nào cũng là câu trả lời cuối. Nếu cuộc gọi tool thuộc về một skill được quản trị, chế độ thực thi của skill được áp dụng chồng lên trên verdict thắng, sau khi phân giải match-đầu-tiên:
Chế độ skillHiệu ứng lên verdict thắng
allowKhông đổi — verdict quy tắc đứng vững.
quarantineLeo thang bất cứ thứ gì chưa tới deny thành pending_approval; một deny hiện có được để nguyên.
blockÉp một deny bất kể verdict quy tắc.
Vậy một skill quarantine có thể biến một allow của quy tắc thành một cuộc gọi được giữ, và một skill block deny một cuộc gọi ngay cả khi không quy tắc nào nêu tên các tool của nó. Quarantine chỉ leo thang — nó không bao giờ hạ cấp một deny thành thứ mềm hơn. Đây là lý do tại sao một skill được tự-phát- hiện là rủi ro ở lại cách ly cho đến khi bạn xem xét nó, bất kể các quy tắc của bạn rộng rãi đến đâu.
Chế độ skill không phải một quy tắc, nên nó không có priority và bạn không thể sắp-lại-thứ-tự nó so với các quy tắc của bạn. Nó luôn đánh giá sau khi verdict thắng được chọn. Nếu chế độ của một skill được quản trị đang block các cuộc gọi bạn mong đợi allow, sửa nó trên skill, không phải bằng cách thêm một quy tắc allow ưu-tiên-cao-hơn — quy tắc không thể ghi đè chế độ.

​
5. Những thứ không đi theo match-đầu-tiên

Một vài cơ chế nằm ngoài lượt duyệt ưu tiên theo-từng-quy-tắc — biết chúng đáp xuống đâu để bạn không cố sắp thứ tự chúng:
Một quy tắc cap_cost dưới trần của nó được xử lý như không-khớp, nên việc đánh giá tiếp tục đến quy tắc kế tiếp thay vì để nó thắng match-đầu-tiên như một cấp phép. Trên trần nó phân giải về một deny. Nó không bao giờ đoản mạch một quy tắc ưu-tiên-thấp-hơn chỉ vì được tới.
Một quy tắc chuỗi khớp một chuỗi cuộc gọi qua một cửa sổ thời gian, nên nó được thực thi phản ứng bởi một bộ khớp bất đồng bộ thay vì trên cuộc gọi đơn hoàn tất chuỗi. Nó làm sáng events feed nhưng không thắng lượt match-đầu-tiên cho một cuộc gọi riêng lẻ.
Shadow mode không thay đổi quy tắc nào thắng — nó hạ cấp verdict thực thi thắng thành audit (lý do thêm tiền tố [shadow] would …) sau khi phân giải match-đầu-tiên, nên bạn có thể đo tác động của một chính sách trước khi nó thay đổi traffic.

​
6. Ghép lại với nhau

Với bất kỳ cuộc gọi tool nào, phân giải đầy đủ là:
  1. Phân giải chính sách — cái được gắn vào key đang gọi, hoặc mặc định workspace. Xem phạm vi.
  2. Duyệt các quy tắc theo priority ASC, id ASC — match đầu tiên thắng; không match → default_verdict.
  3. Áp dụng thực thi skill — chế độ của một skill được quản trị chồng lên trên verdict thắng (block ép deny, quarantine leo thang).
  4. Áp dụng shadow mode — nếu bật, hạ cấp các verdict thực thi thành audit.
  5. Ghi event — verdict, bề mặt, tool, và quy tắc đã khớp đáp xuống events feed.
Chỉnh sửa ưu tiên của một quy tắc có hiệu lực trên cuộc gọi kế tiếp cho mọi key được gắn vào chính sách — không redeploy, không đổi code agent. Chạy lại sandbox Test sau khi sắp-lại-thứ-tự để xác nhận người thắng mới trước khi traffic live phụ thuộc vào nó.

​
Đi đâu tiếp theo

Verdict

Mỗi verdict thắng thực sự làm gì.

Cú pháp glob

Cách khớp tên-tool quyết định liệu một quy tắc có là một ứng cử viên.

Test quy tắc

Chạy thử một chính sách và xem quy tắc nào thắng.

Allow-list tool

Mẫu default-deny dựa nhiều nhất vào việc sắp thứ tự.
Để biết ngôn ngữ so khớp đằng sau một quy tắc, xem tham chiếu Quy tắc Firewall đầy đủ; để biết cách các skill chồng lên trên, xem Firewall Skills và chế độ thực thi.