Patch Management 修補管理：企業更新政策怎麼訂？
修補管理（Patch Management）是企業有系統地取得、評估、測試、部署並確認軟體更新的流程，目的是在攻擊者利用漏洞之前把它修好。一份可執行的更新政策要寫清楚四件事：哪些設備屬於哪個維護群組、一般與緊急修補各有多少時限、更新前怎麼測試，以及無法更新時的例外處理。
多數公司其實有在更新，只是靠 IT 人員的記憶與空檔，遇到要重開機的伺服器就一拖再拖。美國國家標準與技術研究院（NIST）在 SP 800-40 第 4 版直接指出，例行修補因為不緊急又會中斷作業，最常被延後，反而給攻擊者更多機會。下面依政策、流程、例外、指標的順序說明怎麼訂；若想先知道公司有哪些漏洞沒修，可以從 弱點掃描服務 開始。
為什麼企業需要修補管理？
企業需要修補管理，是因為漏洞從公開到被利用的時間越來越短，而沒有制度的更新永遠排在其他工作後面。NIST SP 800-40 第 4 版把修補定位為「預防性維護」，是營運的必要成本，而不是有空才做的資安專案。
2026 年 10 月的 PHP2Shell 就是例子：PHP 官方公開修補前，攻擊者已經開始嘗試利用，國內約有 2 萬 8 千多個相關網站需要盤點更新。平常就知道每台主機跑什麼版本、由誰負責更新的公司，一天內就能完成；沒有清單的公司，光是找出受影響的系統就要好幾天。過程可以參考 PHP 漏洞 的處理步驟。
台灣法規也有對應要求。《資通安全責任等級分級辦法》附表十「資通系統防護基準」要求系統的漏洞修復應測試有效性及潛在影響並定期更新，防護需求等級「高」的系統還要定期確認漏洞修復狀態；ISO/IEC 27001:2022 附錄 A 的 8.8「技術脆弱性管理」，也要求及時取得漏洞資訊、評估暴露程度並採取措施。
修補政策要寫什麼？以維護群組訂時限
修補政策的核心是「分群訂時限」：把設備依重要性與特性分成維護群組，每個群組各自訂出一般修補與緊急修補的時限。NIST SP 800-40 第 4 版建議，連無法更新的設備也要歸入一個群組，而不是列為例外後就不管。
下表是一份可以直接改寫的政策範例，時限請依公司的風險與人力調整：
| 維護群組 | 例子 | 一般修補時限 | 緊急修補時限 | 測試要求 |
|---|---|---|---|---|
| 對外服務主機 | 官網、電商、VPN、郵件閘道 | 每月修補週期內 | 已遭利用或重大漏洞：72 小時內先緩解，14 天內完成修補 | 測試環境驗證後部署，保留回復方案 |
| 內部伺服器 | ERP、檔案伺服器、AD | 每月修補週期內 | 14 天內 | 先更新一台非核心主機觀察 |
| 員工端點 | 筆電、桌機 | 發布後 14 天內自動更新 | 7 天內 | 先推給 IT 與試行群組 |
| 網路與資安設備 | 防火牆、交換器、無線基地台 | 每季 | 依原廠公告，已遭利用者優先 | 排定維護時段，備份組態 |
| 無法更新的設備 | 停止支援的系統、產線或醫療設備 | 不適用 | 隔離與補償措施 | 每季檢視是否能汰換 |
緊急修補的參考是美國網路安全暨基礎設施安全局（CISA）的「已知遭利用漏洞」（KEV）清單：依其 BOD 22-01 指令，聯邦機關對清單上 2021 年後指派編號的漏洞須在兩週內修補。台灣企業不受這項指令約束，但把 KEV 當成「一定要排第一」的清單，是很實用的做法。
修補流程怎麼跑？例行與緊急分開處理
修補流程要分兩條：例行修補跟著廠商的發布週期走，例如微軟每月第二個星期二發布的安全性更新；緊急修補則在漏洞遭利用或極為嚴重時啟動，跳過一般排程。NIST 另外列出兩種情境：修補程式還沒推出時的緊急緩解，以及無法修補的資產。
例行修補可以拆成 6 個步驟：
- 盤點：維護最新的軟硬體清冊，清冊外的設備永遠不會被修補。
- 取得資訊：訂閱原廠公告、TWCERT/CC 與資安署警訊，並對照 KEV 清單。
- 評估優先順序：依漏洞嚴重度、是否已遭利用與資產重要性排序，判讀方式可參考 弱點掃描報告 的優先順序原則。
- 測試：在測試環境或試行群組驗證，確認不會中斷業務，並準備回復方案。
- 部署：依維護群組與維護時段分批更新。
- 確認與紀錄：確認更新確實生效，必要時以掃描複驗，保存變更紀錄。
緊急修補最常卡在核准。建議在政策中預先寫好緊急核准鏈，例如由資訊主管與系統負責人共同核准，不必等每週的變更會議。
例外處理：無法更新的系統怎麼辦？
無法更新時，企業仍要回應風險，不能只在清單上註記「例外」。NIST SP 800-40 第 4 版列出四種風險回應：接受、緩解、轉移與避免。實務上最常用的是緩解，例如網路隔離、關閉有漏洞的功能、加強監控；其次是避免，也就是移除或汰換有漏洞的軟體。
每一筆例外都應該記錄四件事：無法更新的原因、採取的補償措施、核准的主管，以及下次檢視日期。停止支援的系統要特別處理，例如 Windows 10 已在 2025 年 10 月 14 日終止支援，之後不再有一般安全性更新；繼續使用的電腦應列入汰換計畫，或改用原廠的延伸支援方案，在汰換前隔離或限制用途。
實務上我們最常看到的例外，是產線電腦、醫療設備與舊版會計系統：原廠不再支援，換掉又牽涉整條產線或作業流程。這類設備的重點不是硬要更新，而是讓它們看不到網際網路、只能和必要的系統連線，並定期 弱點掃描 確認周邊沒有新的破口。
修補管理要看哪些指標？
修補管理最實用的指標，是「在時限內完成修補的比例」與「修補所需時間」。NIST SP 800-40 第 4 版的範例，就是依漏洞重要性與資產重要性交叉分組，分別計算在期限內修補的比例、平均修補天數與中位數天數。
這組數字比「本月安裝了多少個更新」有意義得多。如果對外主機的期限內修補率長期偏低，代表時限訂得不切實際或人力不足，管理層就有依據調整；如果端點的中位數很快、平均數卻很長，代表有一小群設備長期沒更新，應該去找出是哪些。
指標也要給不同的人看不同的層次：系統管理員看自己負責群組的明細，管理層看各群組的期限內修補率趨勢。每季在管理會議中檢討一次，比每天盯著儀表板更容易持續。
訂好政策後，第一個月先做什麼？
第一個月先完成三件事：整理一份包含作業系統與主要軟體版本的資產清冊、把設備分進維護群組並寫下時限、跑一次弱點掃描找出已經逾期的漏洞。有了這三份資料，下個月的例行修補就能照政策執行，也能算出第一組期限內修補率。
如果想知道目前有多少漏洞已經超過合理的修補時限，可以 預約一次免費諮詢，由顧問協助評估。
修補管理常見問題
系統自動更新可以嗎？
員工端點與一般應用程式適合開啟自動更新，搭配先推給 IT 與試行群組的分批設定，能大幅縮短修補時間。伺服器、資料庫與業務系統則不建議完全自動更新，因為更新可能需要重開機或影響相容性，應在維護時段經測試後部署。不論哪一種，都要定期確認更新是否真的成功安裝。
停止支援的系統怎麼辦？
停止支援的系統不再有安全性更新，應列入汰換計畫並訂出期限；汰換前要以網路隔離、限制連線、關閉不必要服務與加強監控作為補償措施，並把例外原因、措施與核准主管記錄下來。部分產品原廠提供付費的延伸支援，可以作為過渡方案，但不宜當成長期解法。
參考資料
- NIST SP 800-40 Rev. 4 Guide to Enterprise Patch Management Planning – 維護群組、風險回應情境與修補指標。NIST · 2022 年 4 月
- 資通安全責任等級分級辦法 – 附表十「資通系統防護基準」漏洞修復。數位發展部 · 民國 115 年 1 月 7 日修正
- BOD 22-01: Reducing the Significant Risk of Known Exploited Vulnerabilities – KEV 清單漏洞的修補期限。CISA · 2021 年 11 月 3 日
- Windows 10 Home and Pro 生命週期 – 2025 年 10 月 14 日終止支援。Microsoft Learn
