WiFi 憑證驗證：數位憑證如何保障無線網路安全

WiFi 憑證驗證：數位憑證如何保障無線網路安全。Purple 技術簡報。 引言與背景。 歡迎收看 Purple 技術簡報系列。我是您的主持人，今天我們將深入探討企業網路安全中最重要、也最常被誤解的主題之一：WiFi 憑證驗證。 如果您經營的是飯店集團、零售連鎖店、會議中心，或任何員工與訪客都需要連接到您無線基礎設施的組織，這份簡報將與您目前的安全性架構直接相關。 讓我來為您說明背景。傳統保護企業 WiFi 的方法是使用共享的預共用金鑰（Pre-Shared Key）——這是一個每個人都知道的密碼，會被寫在白板上、在 Slack 頻道中分享，而且坦白說，永遠不會更改，因為更改密碼意味著必須更新園區內的每一台裝置。這種模式已經失效了，而且它一直以來都有漏洞。憑證型驗證是大型企業網路十多年來一直採用的方式，如果您還沒有進行轉換，這份簡報將為您提供明確的方向來做出決定。 那麼——究竟什麼是 WiFi 憑證驗證？它為什麼重要？您又該如何實際部署它？讓我們開始深入探討。 技術深度剖析。 讓我們從基本原理開始。在 WiFi 驗證的背景下，數位憑證是一種 X.509 數位憑證——本質上是一個經過加密簽署的文件，用以證明裝置或使用者的身分。您可以把它想像成網路端點的護照。密碼是一種可以被竊取、猜測或洩露的共享秘密，而憑證則不同，它在數學上與一個永遠不會離開裝置的特定私鑰綁定。您無法對憑證進行網路釣魚，也無法對其進行暴力破解。最關鍵的是，一旦裝置遺失或員工離職，您可以立即撤銷該憑證。 使這一切運作的底層框架稱為 PKI（公開金鑰基礎建設）。PKI 是一種信任階層。最頂端是根憑證授權單位（Root Certificate Authority）——終極的信任錨點。在此之下，通常會有一或多個中介憑證授權單位（Intermediate Certificate Authorities），負責實際向裝置和使用者核發終端實體憑證。這種階層結構非常重要，因為這意味著您的根憑證授權單位可以完全保持離線並進行實體隔離（Air-gapped），從而大幅減少受攻擊面。如果中介憑證授權單位遭到入侵，您可以在不影響根憑證的情況下將其撤銷。 現在，這在 WiFi 網路上究竟是如何運作的？其協定堆疊是 IEEE 802.1X（基於連接埠的網路存取控制標準）結合 EAP-TLS（傳輸層安全可延伸驗證協定）。這是企業 WiFi 安全的黃金標準。 以下是驗證流程。當用戶端裝置嘗試連線到您的企業 SSID 時，無線基地台（即 802.1X 中所稱的「驗證器」）不會立即授予網路存取權限。相反地，它會在用戶端與您的 RADIUS 伺服器（802.1X 術語中的「驗證伺服器」）之間代理 EAP 交涉。用戶端會出示其憑證，RADIUS 伺服器則會針對您的 PKI 驗證該憑證，檢查簽章鏈結、有效期限和撤銷狀態。與此同時（這也是 EAP-TLS 真正優於大多數其他 EAP 方法之處），用戶端也會驗證伺服器的憑證。這種雙向驗證可防止惡意無線基地台攻擊（攻擊者架設虛擬的 WiFi 網路以收集憑證）。透過 EAP-TLS，雙方在傳輸任何單一位元組的資料之前，都必須先證明自己的身分。 雙向驗證成功後，RADIUS 伺服器會向無線基地台傳送 Access-Accept 訊息，並將用戶端放入適當的網路區段，無論是企業 VLAN、受限的訪客區段，還是基於憑證屬性的特定原則群組。 接下來談談憑證生命週期，因為這是許多部署遇到營運摩擦的地方。憑證在核發後具有有效期限（裝置憑證通常為一到三年），且必須在過期前進行更新。如果裝置遭竊或報廢，憑證也可以在過期前撤銷。撤銷機制有兩種：CRL（憑證撤銷清單，定期發佈的已撤銷憑證序號清單）以及 OCSP（線上憑證狀態協定，可進行即時撤銷檢查）。對於大型企業部署，強烈建議使用 OCSP，因為 CRL 檔案可能會變得非常龐大並導致延遲。 憑證註冊（首先將憑證安裝到裝置上）是透過 SCEP（簡單憑證註冊協定）或 EST（安全傳輸註冊，較現代的替代方案）等協定來處理。在 Microsoft 環境中，您通常會搭配群組原則使用 Active Directory 憑證服務，將憑證自動註冊到已加入網域的電腦。對於行動裝置管理情境，您的 MDM 平台（無論是 Intune、Jamf 還是其他解決方案）會將憑證發送處理為裝置設定設定檔的一部分。 那麼，這與訪客 WiFi 的交集在哪裡？這是一個重要的區別。憑證驗證主要是一項企業網路控制措施。您的訪客不會擁有由您企業 PKI 核發的憑證。對於訪客存取，您是在不同的驗證模型下運作 — 通常是具有社群登入、電子郵件註冊的 Captive Portal，或者越來越多使用 Passpoint 和 OpenRoaming，這些技術在基礎架構層級使用憑證，以實現跨場域的無縫、安全漫遊。Purple 的平台正定位於該訪客 WiFi 領域，在安全的無線基礎架構之上提供身分識別擷取、分析和互動層。 關鍵的架構原則是網路分段：您進行憑證驗證的企業 SSID 與您的訪客 WiFi SSID 在邏輯上是分開的，且兩者之間設有適當的防火牆原則。如果您在無線基礎架構附近處理卡片付款，這對於 PCI DSS 合規性是不可妥協的，且鑑於您在兩個網路上處理的數據，強烈建議以此符合 GDPR 合規性。 實作建議與常見陷阱。 讓我為您提供實用的部署指南 — 以及我看到企業一再陷入的陷阱。 首先，在接觸任何單一存取點之前，先規劃您的 PKI。最常見的錯誤是使用扁平的單層 CA 結構來部署憑證驗證。請務必實作至少雙層階層架構，並配備離線 Root CA。營運開銷極小，但安全性效益卻非常顯著。 第二，搞定您的 RADIUS 基礎架構。單一 RADIUS 伺服器就是單一故障點。請至少在主動-被動（active-passive）或主動-主動（active-active）配置中部署兩台 RADIUS 伺服器，並測試您的容錯移轉。我曾見過企業正確部署了 802.1X，卻在發生停機時發現其存取點上並未設定 RADIUS 容錯移轉。 第三，憑證有效期需要與您的 MDM 更新週期保持一致。如果您的 MDM 以 90 天為週期推送憑證更新，但您的憑證有效期為 12 個月，您將會面臨空窗期。請將更新自動化，並在到期前 60 天建立警示。 第四 — 這常讓人措手不及 — iOS 和 Android 處理憑證信任的方式不同。iOS 要求使用者在首次連線時明確信任 Root CA 憑證，除非該憑證是透過 MDM 推送的。Android 的行為則因版本和製造商而異。在正式上線前，請在每種裝置類型上測試您的用戶端體驗。 第五個陷阱是 OCSP 可用性。如果您的 OCSP 回應程式位於內部，且用戶端在驗證期間無法存取它 — 可能是因為他們是首次連線且尚未取得網路存取權限 — 驗證可能會失敗或退回到 CRL。請將您的 OCSP 基礎架構設計為可在預先驗證狀態下存取，或適當設定您的 RADIUS 伺服器以快取 OCSP 回應。 快速問答。 讓我為您解答最常被問到的問題。 問題：我們可以在現有的訪客 WiFi 門戶旁使用憑證驗證嗎？絕對可以。它們是具有獨立驗證機制的獨立 SSID。您的企業用戶透過 EAP-TLS 進行驗證；您的訪客則透過 Captive Portal 流程。Purple 處理訪客端；您的 RADIUS 基礎架構則處理企業端。 問題：當裝置遺失或被盜時會發生什麼事？您立即透過 CA 管理主控台撤銷該憑證。下一次該裝置嘗試連線時，RADIUS 伺服器會檢查撤銷狀態並拒絕連線。使用 OCSP，這幾乎可以達到近乎即時。使用 CRL，則取決於您的 CRL 發佈間隔 — 通常為數小時。這就是為什麼高安全性環境更偏好 OCSP 的原因。 問題：EAP-TLS 是否與 WPA3 相容？是的。WPA3-Enterprise 強制要求在最敏感的部署中使用 192 位元安全性模式，而 EAP-TLS 完全相容。事實上，搭配 EAP-TLS 的 WPA3-Enterprise 是目前企業 WiFi 可用的最高安全性配置。 問題：這對我們的 PCI DSS 合規性狀況有何影響？有正面影響。PCI DSS 要求 1 和要求 8 都受益於基於憑證的驗證。消除共享的預共用金鑰（PSK）移除了重大的稽核發現，且每個裝置的識別代表您擁有清晰的稽核軌跡，記錄了哪台裝置在何時存取了哪個網路區段。 摘要與後續步驟。 總結來說：透過 802.1X 和 EAP-TLS 進行 WiFi 憑證驗證，是任何重視網路安全性的組織的正確方法。它消除了共享秘密、提供雙向驗證、實現細粒度的存取控制，並與您現有的身分識別基礎架構無縫整合。 部署路徑非常明確：設計您的 PKI 階層、部署備援 RADIUS 基礎架構、與您的 MDM 整合以進行憑證分發、為 802.1X 配置您的存取點（AP），並在您的裝置資產中進行徹底測試。 至於您的訪客網路，那是另一個獨立的主題 — 這也是像 Purple 這樣的平台發揮真正價值的地方，為您提供安全、合規的訪客引導，並具備分析與互動功能，將您的 WiFi 基礎架構轉化為業務資產，而不僅僅是公用程式。 如果您正在評估目前的身分驗證狀況，正確的起點是稽核您現有的 SSID 配置，並審查您的憑證基礎架構準備情況。從那裡開始，分階段推出 — 從受管裝置的試點小組開始 — 是全面部署風險最低的路徑。 感謝收聽本次 Purple 技術簡報。如需進一步閱讀，請造訪 Purple 官方網站 purple.ai，查看我們關於企業 WiFi 安全性和最安全 WiFi 驗證方法的指南。