在 NAC 環境中利用 OCSP 與 CRL 自動化憑證撤銷

在 NAC 環境中利用 OCSP 與 CRL 自動化憑證撤銷 Purple 技術簡報 — 約 10 分鐘 --- 簡介與背景說明 — 約 1 分鐘 歡迎來到 Purple 技術簡報系列。我是您的主持人，今天我們將深入探討自動化憑證撤銷的運作機制 — 具體說明 OCSP 與 CRL 在網路存取控制（NAC）環境中如何運作，以及為什麼做好這項工作是企業 Wi-Fi 部署中最容易被忽視的安全決策之一。 如果您正在營運飯店連鎖、零售物業、體育場館或擁有成千上萬台連線裝置的公共部門網路，憑證生命週期管理絕非可有可無。它決定了您的網路是能即時執行策略，還是默默容留本應在數週前就被切斷連線的已撤銷憑證裝置。 我們將介紹技術架構、逐步解析兩個實際部署場景，最後並提供您的團隊在進行任何實際生產環境部署前應該詢問的問題。 讓我們開始吧。 --- 技術深度解析 — 約 5 分鐘 首先，讓我們確立我們要解決的問題。在任何以 IEEE 802.1X 驗證的網路（這是企業 Wi-Fi、有線 NAC 以及大多數現代訪客存取架構的基礎標準）中，裝置會使用憑證或認證資訊進行驗證。憑證是較佳的選擇，因為它們不依賴共享金鑰、與裝置綁定，且能透過 SCEP 等協定與 MDM 平台無縫整合。但憑證是有生命週期的。它們會過期、會遭到洩露，裝置也會退役。當這些情況發生時，您需要一種機制來告訴您的網路基礎設施：此憑證已不再有效，請停止信任它。 該機制有兩種形式：CRL（憑證撤銷清單，Certificate Revocation List）與 OCSP（線上憑證狀態協定，Online Certificate Status Protocol）。 讓我們從 CRL 開始。憑證撤銷清單正如其名 — 它是一份由您的憑證機構（CA）發行並簽署的清單，其中包含所有已撤銷憑證的序號。您的 NAC 基礎設施 — 通常是 FreeRADIUS、Cisco ISE 或 Aruba ClearPass 等 RADIUS 伺服器 — 會定期從 CRL 發佈點（通常只是一個 HTTP 或 LDAP 端點）下載此清單。RADIUS 伺服器會在本地快取該清單，並在 EAP-TLS 握手期間比對傳入的憑證序號。 CRL 的運作優勢在於簡單性與離線韌性。一旦下載了清單，即使您的 CA 無法連線，撤銷檢查仍能正常運作。缺點則是延遲性。如果您在上午 9 點撤銷了某張憑證，而您的 CRL 更新間隔是 24 小時，那麼該裝置在下一次排程下載之前仍能進行驗證。在高度安全的環境中 — 如醫院、金融服務後勤部門、政府網路 — 這樣的時間差是無法接受的。 OCSP 解決了延遲問題。您的 RADIUS 伺服器不會維護本機快取列表，而是向 OCSP 回應程式（這是在您 CA 前端的服務）發送即時查詢，以驗證每個所需的憑證。回應程式會返回以下三種答案之一：良好、已撤銷或未知。整個交換過程是在 EAP-TLS 握手期間以內聯方式進行的，在配置良好的基礎架構上，通常耗時不到 100 毫秒。 OCSP 的權衡在於對可用性的依賴。如果您的 OCSP 回應程式斷線，或者您的 RADIUS 伺服器因網路分割而無法連線到它，您就必須做出策略決定：您是要開啟失敗（允許繼續進行驗證），還是關閉失敗（在可連線到回應程式之前拒絕存取）？開啟失敗可維持運行時間，但會產生安全漏洞。關閉失敗可維持安全態勢，但在基礎架構發生事件期間可能會將合法使用者阻擋在外。 還有第三個值得了解的選項：OCSP 裝訂（OCSP Stapling）。在這種模式下，憑證持有者（用戶端裝置）會定期從回應程式獲取經簽署的 OCSP 回應，並將其附加到 TLS 握手中。RADIUS 伺服器會驗證裝訂的回應，而不是自行進行 OCSP 查詢。這減輕了 OCSP 回應程式的負載，消除了將憑證序號暴露給外部服務的隱私疑慮，並提高了彈性。缺點是並非所有的 EAP 請求方（supplicant）都支援裝訂，因此在依賴它之前，您需要驗證用戶端的相容性。 現在，這如何融入 NAC 架構？您的 NAC 策略引擎 — 無論是 Cisco ISE、Aruba ClearPass、Juniper Mist，還是圍繞 FreeRADIUS 和 PacketFence 建置的開源堆疊 — 都介於請求方和網路之間。當裝置嘗試連線時，RADIUS 伺服器會收到 Access-Request、進行 EAP-TLS 協商、驗證用戶端憑證鏈、透過 OCSP 或 CRL 檢查撤銷狀態，然後發送帶有 VLAN 分配的 Access-Accept，或者發送 Access-Reject。 自動化部分在兩個層面上進行。首先，在憑證發放層：您的 MDM 平台（Jamf、Intune、Workspace ONE）使用 SCEP 自動向受管裝置部署憑證。當裝置取消註冊或退役時，MDM 會觸發對 CA 的撤銷呼叫，CA 會更新 CRL 並通知 OCSP 回應程式。其次，在 NAC 執行層：您的 RADIUS 伺服器設定為按照定義的時程查詢 OCSP 或重新整理其 CRL 快取，確保撤銷決定在無需人工干預的情況下傳播到存取策略。 此處關鍵的整合點在於 CA 到 NAC 的通訊管道。在設計良好的部署中，撤銷是一個完全自動化的鏈路：MDM 停用裝置、觸發 CA 撤銷、CA 更新 OCSP 回應程式並發佈新的 CRL、RADIUS 伺服器取得此變更（不論是透過 OCSP 立即取得，還是在下一次 CRL 重新整理時間內取得），接著該裝置在下一次驗證嘗試時就會被拒絕存取。 --- 實作建議與常見陷阱 — 約 2 分鐘 讓我提供一些實用指南，以避免部署過程出錯。 第一：在選擇機制之前，先定義您對撤銷延遲的容忍度。如果您營運的是飯店顧客 WiFi 網路，其主要風險在於已停用的員工裝置，那麼 4 小時的 CRL 重新整理間隔可能就足夠了。如果您營運的是醫療保健網路，其中受損的裝置可能會存取病患資料，您會需要採用 Fail-Closed（預設關閉）策略的 OCSP 以及高可用性的回應程式叢集。 第二：切勿在生產環境中執行單一 OCSP 回應程式。請至少在負載平衡器後方部署兩個，並搭配健康監測。導致 Fail-Closed 行為的 OCSP 回應程式中斷，其產生的支援工單速度會比幾乎任何其他基礎架構故障都還要快。 第三：注意您的 CRL 大小。在大型部署中（我們指的是數萬張憑證），CRL 檔案可能會成長到數個 MB。RADIUS 伺服器每小時透過 WAN 連結下載 5MB 的 CRL，是個隨時可能發生的吞吐量問題。請考慮使用增量 CRL（僅包含自上一次完整 CRL 以來的變更），或在商務量龐大的環境中移轉至 OCSP。 第四：定期測試您的撤銷管道。光是設定 OCSP 並假設它能正常運作是不夠的。請自動化每月測試：發行憑證、撤銷憑證、嘗試驗證、確認遭拒。如果您的監測系統無法偵測到故障的 OCSP 回應程式，那麼您的撤銷機制就只是花拳繡腿。 第五：讓您的憑證有效期與您的撤銷策略保持一致。短期憑證（24 到 72 小時）可縮短憑證受損的暴露時間，並可完全降低您對撤銷基礎架構的依賴。這是產業發展的趨勢，值得在新的部署中進行評估。 --- 快速問答 — 約 1 分鐘 問：我可以同時使用 OCSP 和 CRL 嗎？ 可以。大多數 RADIUS 實作都支援遞補鏈路：先嘗試 OCSP，若無法連線至回應程式，則遞補至 CRL。這能在正常情況下為您提供即時檢查，並在發生中斷時提供離線復原能力。 問：Purple 的顧客 WiFi 平台是否與憑證架構的 NAC 整合？ Purple 的平台運作於訪客存取層，處理 Captive Portal 驗證、數據擷取和分析。針對使用憑證驗證執行 802.1X 的企業員工網路，Purple 是與底層網路基礎架構（無線存取點、控制器和 RADIUS 伺服器）進行整合，而非取代憑證管理堆疊。訪客和員工網路通常是分割的，並各自採用適合的驗證機制。 問題：合規性方面的考量是什麼？ PCI DSS 4.0 要求存取持卡人資料環境必須使用強式驗證。GDPR 要求採取適當的技術措施來保護個人資料。這兩個框架都可以透過具備自動撤銷功能的憑證型 802.1X 來滿足——前提是您必須證明撤銷是及時且經過測試的。您的稽核軌跡需要顯示憑證何時被撤銷，以及該撤銷何時傳播到網路執行端。 --- 摘要與後續步驟 — 約 1 分鐘 總結來說：在 NAC 環境中自動化憑證撤銷是一個三層架構的問題。您需要一個支援自動化撤銷觸發器的 CA、一個高可用性且規模適當的 OCSP 回應程式或 CRL 散發點，以及一個設定為將撤銷狀態強制納入其存取原則的 RADIUS 伺服器。 在 OCSP 和 CRL 之間做選擇並非二分法——這是一個風險承受度的決策，應根據您環境的安全需求、網路拓撲和維運成熟度來制定。 如果您正在建置或審查 NAC 部署，並希望了解 Purple 的訪客 WiFi 和分析平台如何融入更廣泛的網路架構，節目資訊中的連結將帶您前往相關的技術指南。 感謝您的收聽。我們下次簡報再見。 --- 指令碼結束