在任何營運超過三到五年的企業機房裡，翻開邊界防火牆的設定檔，往往能看見一本活生生的「維運地質沉積學」。

數百甚至數千條規則中，充斥著「Temp_Allow_Vendor（備註日期是三年前）」、「Test_Any_Any」、「DB_Sync_Hotfix」，或是來源與目的都寫著 Any、只有 Service 稍微限縮的龐雜項目。很多工程師即便明知這些是潛在破口，也不敢輕易按下刪除鍵——因為沒有人知道停用這條規則後，明天會不會有哪套核心系統突然停擺。

這種「能通就好、只增不減」的歷史包袱，在資安領域被稱為「安全債（Security Debt）」。

當邊界設備堆滿了冗餘、重疊與寬鬆的陳年政策時，不僅大幅消耗防火牆的 ASIC/CPU 查表運算效能，更直接違反了 ISO 27001（A.8.20 網路安全控制） 與 CISSP 最小特權原則（Least Privilege）。Day 20，我們將從一線維運視角出發，解析如何利用工具與審計手法，安全地替 Palo Alto 與 FortiGate 的規則庫完成瘦身減磅。

一、 盤點安全債：三大高風險特徵

在動手清理之前，必須先對現有的 Policy 庫進行風險畫像。陳年規則通常具備以下三種壞味道：

寬鬆過度（Permissive Any-Any）：

早期除錯時為求快速連通而建立，例如 Source: Any -> Dest: Any -> Service: Any -> Action: Allow。即便後續有針對特定服務限縮，只要這條規則排在上位，下方的安全檢測直接被繞過。

影子規則（Shadowed / Redundant Rules）：

上方存在一條更大範圍的規則，導致下方較小範圍的特定規則「永遠無法被命中（Hit Count 為 0）」，形同無效代碼；或是兩條規則的目的完全一致，純粹是不同時期人員重複建立。

殭屍規則（Dormant / Stale Rules）：

專案早已結案、伺服器已下線拆除，但當初申請開通的對外 NAT 或存取規則卻從未伴隨資產下線流程一併撤除，留下無人看管的隱形後門。

二、 實戰清理手法：讓命中率（Hit Count）與日誌為證據說話

清除安全債最忌諱「憑直覺盲刪」。成熟的維運作法，是用客觀數據取代人為推測。

1. Palo Alto Networks：活用 Policy Optimizer 與 Rule Usage

Palo Alto 的 PAN-OS 提供了強大的內建審計工具 Policy Optimizer，是一線減磅的利器：

No App / Any Service 清理：

在 Policy Optimizer 介面中，直接過濾「仍在使用 Port 放行、未轉化為 App-ID」的傳統規則。系統會展示過去 30 天內該規則實際跑過哪些合法應用（如 web-browsing, ssl），一鍵協助你將寬鬆的 Service: 80, 443 收斂為精準的 App-ID，並將未使用的應用剔除。

Unused Apps / Zero Hit Rules：

篩選「Rule Usage 為 0」且時間超過 90 天的規則。若該規則是針對特定 IP/服務，而這段期間完全沒有任何 Session 觸發，即可列入優先除役名單。

2. FortiGate：Policy Hit Count 與 Object Usage 追蹤

在 FortiGate 上，同樣具備完整的排查邏輯：

檢視 Hit Count 與 Last Used：

在 GUI 的 Policy & Objects -> Firewall Policy 欄位中，調出 Count 與 Last Used。對於一年以上未被命中的政策，或 Hit Count 始終為 0 的項目進行標記。

反查無效物件（Unused Address Objects）：

透過 CLI 指令 diagnose firewall iprope list 或在 GUI 位址庫檢視「Reference（引用次數）」。若某個 IP 物件的引用次數為 0，代表該物件已是無效垃圾，應先清理物件庫，降低組態複雜度。

3. 保底機制：從「停用」到「刪除」的三階段退場法

為了避免誤刪造成非預期的營運中斷，我要求團隊遵循嚴格的三階段安全下線 SOP：

第一階段（標籤警示）：

在規則 Description 註記下線計畫、申請人與預計停用日期，並加上 Pending_Decommission 標籤。

第二階段（停用觀察 30 天）：

不要直接刪除，而是將規則 Disable（停用）。若停用期間引發業務異常，可在 10 秒內按鍵啟用復原；若 30 天內無人反映且日誌未見阻斷客訴，代表該連線確已消亡。

第三階段（歸檔備份並刪除）：

匯出防火牆配置快照存檔，正式將停用的規則自設備中永久移除。

三、 治理架構：建立規則的「生命週期管理（Lifecycle）」

清理安全債是體力活，但若不從源頭建立制度，半年後龐雜的垃圾規則又會捲土重來。在 ISO 27001 的變更管理（A.8.32） 要求下，每一條防火牆規則的誕生與消滅，都必須納入制度化循環：

強制指定「規則到期日（Expiration Date）」：

所有的臨時性開通（如廠商遠端維護、滲透測試），在申請表單上必須載明有效期限，並直接在 FortiGate 或 Palo Alto 上設定「排程生效（Schedule）」，時間一到自動失效。

所有者綁定（Ownership Attribution）：

規則備註欄位一律嚴格格式化：

[工單編號] - [申請部門/專案名稱] - [負責人] - [開通目的]。找不到負責人的規則，直接列入季度審計的排查對象。

季度定期稽核（Periodic Policy Review）：

每季由資安窗口會同網路管理員，匯出所有寬鬆規則清單，要求各業務單位重新簽核「業務存續必要性」，將防火牆維護從網管的單向負擔，轉化為組織共擔的資安治理流程。

結語：減法維運，才是高段位的安全修煉

剛入行的工程師往往熱衷於「加法」——買更貴的設備、開更多的防護功能、寫更複雜的規則；然而真正資深的資安維運專家，更懂得如何做「減法」。

每一條多餘的 Any 規則，都是留給攻擊者的幸運之門；每一次對規則庫的審計與瘦身，都是在壓縮企業的受攻擊面（Attack Surface）。

將清理安全債從被動推拖的苦差事，轉化為有數據依據、有安全防護欄的日常維運常態，我們守護的不僅是防火牆的健康度，更是讓企業邊界在歷經數年風雨侵蝕後，依然能維持最初那份純粹而嚴密的防守初心。