在 NAC 環境中透過 OCSP 與 CRL 自動化憑證撤銷

在 NAC 環境中利用 OCSP 與 CRL 自動化憑證撤銷 Purple 技術簡報 — 閱讀時間約 10 分鐘 --- 簡介與背景 — 閱讀時間約 1 分鐘 歡迎收看 Purple 技術簡報系列。我是您的主持人，今天我們將深入探討自動化憑證撤銷的機制，特別是 OCSP 和 CRL 在網路存取控制（NAC）環境中是如何運作的，以及為什麼正確處理此機制是企業 WiFi 部署中最常被忽視的安全決策之一。 如果您正在營運連鎖飯店、零售物業、體育場館，或是有著成千上萬台連線裝置的公共部門網路，憑證生命週期管理絕非可有可無。它決定了您的網路是能即時執行策略，還是默默容留著幾週前就該被切斷連線的已撤銷憑證裝置。 我們將介紹技術架構、逐步說明兩個實際的部署情境，並在最後提出您的團隊在進行任何實際生產環境部署前應該詢問的問題。 讓我們開始吧。 --- 技術深挖 — 閱讀時間約 5 分鐘 首先，讓我們確定我們要解決的問題。在任何以 802.1X 驗證的網路中（這是支援企業 WiFi、有線 NAC 以及大多數現代訪客存取架構的標準），裝置會使用認證資訊或憑證進行驗證。憑證是較佳的選擇，因為它們不依賴共享金鑰、與裝置綁定，並能透過 SCEP 等協定與 MDM 平台無縫整合。但是憑證是有生命週期的。它們會過期、會被洩露，裝置也會退役。當這些情況發生時，您需要一種機制來告訴您的網路基礎設施：此憑證已不再有效，停止信任它。 這種機制有兩種形式：CRL（代表憑證撤銷清單）與 OCSP（代表線上憑證狀態協定）。 我們首先來看 CRL。憑證撤銷清單正如其名，它是由您的憑證授權單位（CA）發佈並簽署的清單，其中包含所有已被撤銷的憑證序號。您的 NAC 基礎設施（通常是 RADIUS 伺服器，例如 FreeRADIUS、Cisco ISE 或 Aruba ClearPass）會定期從 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 應答器。請至少在負載平衡器後方部署兩個應答器，並進行健康狀況監控。因 OCSP 應答器中斷而導致的 Fail-Closed 行為，其產生支援工單的速度將快過幾乎任何其他基礎架構故障。 第三：注意您的 CRL 大小。在大型部署中（我們指的是數萬張憑證），CRL 檔案可能會成長到數個 MB。RADIUS 伺服器每小時透過 WAN 連結下載一個 5MB 的 CRL，是一個遲早會發生的吞吐量問題。請考慮使用 Delta 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 和分析平台如何融入更廣泛的網路架構，節目資訊中的連結將引導您前往相關的技術指南。 感謝您的收聽。我們下次簡報再見。 --- 指令碼結束