企業級 SCEP 設定指南：適用於高等教育與大型網路的憑證架構 WiFi 驗證

企業 SCEP 設定指南：適用於高等教育與大型網路的憑證式 WiFi 驗證 Purple 技術簡報 - 播客腳本 (長度約 10 分鐘) --- 前言與背景說明 - 約 1 分鐘 歡迎收聽 Purple 技術簡報系列。我今天要談的是一個常出現在許多 IT 收件匣中，但很少得到直接解答的話題：如何在大型網路 (無論是大學校園、多據點酒店集團，還是大型公共部門資產) 中，使用 SCEP 大規模部署憑證式 WiFi 驗證？ 我們將涵蓋完整的架構。包括 SCEP 的實際功能、它如何融入 802.1X 架構、大多數團隊常出錯的部署順序、兩個實際的執行情境，以及如果您沒有提前規劃，將會浪費您一整個週末時間的常見陷阱。 這是一份顧問簡報，而不是新手教學。我預設您已經知道什麼是 RADIUS 伺服器，且可能已經決定要擺脫預先共用金鑰。您現在需要的是部署規劃藍圖。 讓我們開始吧。 --- 技術深度剖析 - 約 5 分鐘 首先，基本原理。SCEP 代表簡單憑證登錄協定 (Simple Certificate Enrollment Protocol)。它在 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 完全相容。事實上，WPA3-Enterprise 搭配 EAP-TLS 是 Wi-Fi Alliance 針對政府和金融網路所推薦的組合。 - 摘要與後續步驟 - 約 1 分鐘 總結來說，對於擁有超過 50 台託管裝置的任何網路，SCEP 憑證 WiFi 驗證是最適當的架構。它消除了共用認證，提供您單一裝置的辨識，並實現動態 VLAN 區段，同時能直接與您的身分識別提供者整合以進行自動撤銷。部署順序 - Trusted Root、接著 SCEP 設定檔、然後 WiFi 設定檔 - 是固定不變的。群組定位必須保持一致。CRL 的可用性並非可選，而是不可或缺。 特別是針對高等教育機構，將針對教職員裝置的 SCEP，與針對使用個人裝置學生的獨立客用 WiFi 分層結合，既能兼顧安全性，又能提供卓越的用戶體驗，完全不需妥協。 如果您想深入了解，Purple 的「無 Active Directory 或地端伺服器的企業級 WiFi 驗證指南」介紹了雲端原生途徑。如果您正在考慮員工離職時的情況，我們的「撤銷 WiFi 存取權限指南」將帶您走過完整的撤銷工作流程。 感謝您的聆聽。我是 Purple 技術團隊，我們下一個簡報見。 - 劇本結束