企業級 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 - 搭配傳輸層安全性的可延伸驗證協定（Extensible Authentication Protocol with Transport Layer Security），它包含在 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-bit 安全模式，而 EAP-TLS 完全相容。事實上，WPA3-Enterprise 搭配 EAP-TLS 是 Wi-Fi 聯盟針對政府與金融網路推薦的組合。 - - 總結與後續步驟 - 約 1 分鐘 總結來說，對於擁有超過 50 台託管設備的網路，SCEP 憑證 WiFi 驗證是最適當的架構。它消除了共用認證、為每台設備提供獨立身分、啟用動態 VLAN 劃分，並直接與您的身分識別提供者整合以進行自動撤銷。部署順序 - 受信任的根憑證、SCEP 設定檔，然後是 WiFi 設定檔 - 是固定不變的。群組定位必須保持一致。CRL 可用性是不可或缺的。 特別是針對高等教育環境，針對教職員設備使用 SCEP，並針對學生個人設備使用獨立的訪客 WiFi 層，這種組合能同時提供安全與優質的使用者體驗，無需做出妥協。 如果您想深入了解，Purple 關於無 Active Directory 或本地伺服器的企業級 WiFi 驗證指南，介紹了雲端原生的實現路徑。如果您正在考慮員工離職時的情況，我們關於撤銷 WiFi 存取權限的指南將逐步引導您完成整個撤銷工作流程。 感謝您的收聽。我是來自 Purple 技術團隊的成員，我們在下一次簡報中再見。 - - 指令稿結束