企業級 SCEP 設定指南：適用於高等教育與大型網路的憑證式 Wi-Fi 驗證

企業級 SCEP 設定指南：適用於高等教育與大型網路的憑證式 WiFi 驗證 Purple 技術簡報 - 播客腳本（約 10 分鐘） --- 引言與背景 - 約 1 分鐘 歡迎收聽 Purple 技術簡報系列。我今天想聊聊一個經常出現在許多 IT 收件匣中，卻很少得到直接解答的話題：如何在大規模網路中，使用 SCEP 實際部署憑證式 WiFi 驗證？無論是大學校園、多據點飯店集團，還是大型公共部門資產，這都適用。 我們將為您呈現全景。包括 SCEP 的實際作用、它如何融入 802.1X 架構、大多數團隊都會搞錯的部署順序、兩個真實世界的實作場景，以及如果您不提前規劃，將會浪費您整個週末時間的陷阱。 這是一份顧問簡報，而不是教學課程。我假設您已經知道什麼是 RADIUS 伺服器，並且可能已經決定要淘汰預共用金鑰。您現在需要的是實作藍圖。 讓我們開始吧。 --- 技術深入探討 - 約 5 分鐘 首先是基本原理。SCEP 代表簡單憑證登冊協定。它於 2020 年被 IETF 正式確立為 RFC 8894，儘管在此之前它已經在企業中廣泛使用了十多年。它的工作非常簡單：自動將數位憑證安裝到託管裝置上，而無需人工手動操作每台機器。 在 WiFi 驗證的背景下，SCEP 是傳輸機制。您所針對的實際驗證協定是 EAP-TLS（可延伸驗證協定 - 傳輸層安全性），它位於 802.1X 架構中。EAP-TLS 被廣泛認為是企業無線網路最安全的驗證方法，因為它要求用戶端裝置和 RADIUS 伺服器都必須出示有效的憑證。在沒有密碼學證明的情況下，雙方都不會信任對方。這種雙向驗證可以保護您免受邪惡雙生（evil twin）攻擊——即攻擊者架設偽造的存取點來收集憑證。 以下是完整鏈結的運作方式。託管裝置（例如學生的筆記型電腦、員工的手機、飯店的 POS 終端機）需要加入企業無線網路。您的 MDM 平台（可能是 Microsoft Intune 或 Jamf）會向該裝置推送 SCEP 承載資料。該承載資料包含兩樣東西：指向您的 NDES 伺服器或雲端 SCEP 閘道的 SCEP URL，以及挑戰密碼或共用金鑰。裝置會在本地產生自己的公鑰和私鑰組。這非常關鍵。私鑰永遠不會離開裝置。它是在裝置上產生、儲存在安全飛地或 TPM 中，且絕不會透過網路傳輸。接著，裝置會建立一個憑證簽署請求 (CSR) 並將其傳送到 SCEP 閘道。閘道驗證該挑戰，將 CSR 轉發給您的憑證授權單位 (CA)，CA 對其進行簽署並將公用憑證傳回給裝置。從那時起，當裝置連線到您的 WiFi SSID 時，它會向 RADIUS 伺服器出示該憑證。RADIUS 伺服器會根據您 CA 的信任鏈驗證該憑證，檢查憑證撤銷清單以確認憑證未被撤銷，如果一切正常，則向存取點傳送接受訊息。裝置便成功連上網路。整個過程對使用者來說是完全無感的。 現在，讓我們談談 SCEP 與另一種選擇 PKCS 的對比。PKCS（公鑰密碼學標準）是 Intune 等平台支援的另一種憑證傳輸方法。使用 PKCS 時，CA 會在集中端產生公鑰和私鑰，然後憑證連接器將該金鑰組推送到裝置。這意味著私鑰會在網路上傳輸，從而引入了理論上的攻擊面。PKCS 適用於像 S/MIME 電子郵件加密這樣實際上需要金鑰託管的案例。對於 WiFi 驗證，SCEP 才是正確的選擇。私鑰會保留在裝置上，就這麼簡單。 現在來看硬體層。SCEP 和 EAP-TLS 是與廠商無關的標準，這意味著它們適用於 Cisco Meraki、HPE Aruba、Ruckus、Juniper Mist、Ubiquiti UniFi、Cambium、Extreme 和 Fortinet 的存取點。您的 RADIUS 設定（無論是 Windows NPS、FreeRADIUS 還是雲端 RADIUS 服務）是您定義憑證驗證原則的地方，而且至關重要的是，也是您設定動態 VLAN 分配的地方。動態 VLAN 是您根據身分分割網路的方式。學生裝置分配到 VLAN 20（僅限網際網路存取）。教職員裝置分配到 VLAN 10（可存取內部研究系統）。設施管理裝置分配到 VLAN 30（可存取建築管理系統）。所有這些都由憑證屬性和 RADIUS 原則驅動，無需對每台裝置進行手動干預。 對於身分識別提供者整合，SCEP 憑證屬性（特別是主體替代名稱）可以攜帶來自 Microsoft Entra ID、Okta 或 Google Workspace 的使用者主體名稱。這將憑證與特定身分綁定，這意味著當您在 Entra ID 中停用帳戶且 MDM 取消註冊裝置時，憑證會被撤銷，WiFi 存取權限也會自動中斷。這是預共用金鑰根本無法實現的撤銷機制。 --- 實作建議與陷阱 - 約 2 分鐘 好的，讓我們來談談部署順序，因為這是大多數團隊出錯的地方。 這個順序是不可妥協的：首先是信任的根憑證，其次是 SCEP 憑證設定檔，第三是 WiFi 設定檔。Intune 和 Jamf 都強制執行設定檔相依性。如果您的 WiFi 設定檔引用了尚未部署到裝置的 SCEP 憑證，WiFi 設定檔將會失敗，並顯示一個看起來像設定錯誤但實際上只是時間差問題的晦澀錯誤。 第二個陷阱是群組目標定位。所有這三個設定檔（信任的根憑證、SCEP 和 WiFi）都必須部署到完全相同的 Azure AD 或 Jamf 群組。如果 SCEP 設定檔針對使用者群組，而 WiFi 設定檔針對裝置群組，Intune 將無法解析相依性，且 WiFi 設定檔將顯示為「不適用」。這經常讓團隊措手不及。 第三：NDES 伺服器的可達性。您的 NDES 伺服器需要能夠從網際網路存取，以便裝置在到達現場之前進行註冊。正確的做法是透過 Azure AD Application Proxy，而不是在防火牆上開孔。App Proxy 為您提供安全的遠端存取，無需開放輸入連接埠，並允許您將條件式存取原則套用到註冊流程中。 第四：CRL 可用性。您的 RADIUS 伺服器在每次裝置驗證時都會檢查憑證撤銷清單。如果您的 CRL 發佈點不可用（因為伺服器當機或 URL 已變更），網路上所有裝置的驗證將同時失敗。這會導致全校性的網路中斷。請確保您的 CRL 端點具有高可用性，並在正式上線前測試撤銷功能。 對於大型網路（任何超過 500 台裝置的環境），請考慮使用雲端 SCEP 閘道，而不是地端的 NDES。雲端閘道消除了 NDES 的單點故障，可水平擴充，且通常直接與雲端 RADIUS 服務整合，從而移除了另一個基礎架構相依性。 --- 快速問答 - 約 1 分鐘 SCEP 可以處理未在 MDM 註冊的 BYOD 裝置嗎？無法直接處理。SCEP 需要 MDM 註冊才能推送憑證承載資料。對於未託管的 BYOD，您需要不同的方法——使用自我服務引導入口網站，或使用帶有身分驗證的 Captive Portal 的獨立 SSID。Purple 的平台可以乾淨俐落地處理訪客和 BYOD 層，與您經過憑證驗證的員工網路並行運作。 iOS 和 Android 呢？這兩個平台都原生支援 SCEP。iOS 自 iOS 4 起就支援 SCEP。Android Enterprise 透過 Intune 和其他 MDM 支援 SCEP。每個平台的設定略有不同，但底層協定是完全相同的。 EAP-TLS 可以與 WPA3 搭配使用嗎？可以。WPA3-Enterprise 針對敏感環境強制要求 192 位元安全性模式，而 EAP-TLS 完全相容。事實上，搭配 EAP-TLS 的 WPA3-Enterprise 是 Wi-Fi Alliance 針對政府和金融網路推薦的組合。 --- 總結與後續步驟 - 約 1 分鐘 總結來說。對於任何擁有超過 50 台託管裝置的網路，SCEP 憑證 WiFi 驗證都是正確的架構。它消除了共用憑證，為您提供每台裝置的身分識別，啟用動態 VLAN 分割，並直接與您的身分識別提供者整合以實現自動撤銷。部署順序（信任的根憑證，接著是 SCEP 設定檔，最後是 WiFi 設定檔）是固定的。群組目標定位必須保持一致。CRL 可用性是不可或缺的。 特別是對於高等教育，將適用於教職員裝置的 SCEP 與適用於學生個人裝置的獨立訪客 WiFi 層相結合，可同時為您提供安全性和絕佳的使用者體驗，而無需妥協。 如果您想深入瞭解，Purple 關於無 Active Directory 或地端伺服器的企業 WiFi 驗證指南涵蓋了雲端原生路徑。如果您正在思考員工離職時會發生什麼事，我們的撤銷 WiFi 存取權限指南將帶您瞭解完整的撤銷工作流程。 感謝您的收聽。我是來自 Purple 技術團隊的成員，我們在下一次簡報中再見。 --- 腳本結束