企業 SCEP 指南：部署簡單憑證登錄協定以實現自動化校園 WiFi 安全

大家早。如果您正在管理飯店集團、零售物業、體育場或大學校園的 WiFi 基礎架構，那麼本次簡報非常適合您。我們將介紹 SCEP（簡單憑證登錄協定），特別是它如何解決企業 WiFi 中最令人頭痛的持續性問題之一：自動將憑證部署到數千台設備上，而不會讓您的客服中心淹沒在支援工單中。 [short pause] 讓我來為大家說明背景。您已經做出了正確的決定，即員工 WiFi 不再接受預共用金鑰。單一密碼遭到破解就會暴露您的整個網路區段。您已經或正在轉向 802.1X 驗證。這是 IEEE 標準，要求每台設備在獲得網路存取權限之前證明其身分。802.1X 最安全的版本是 EAP-TLS（具有傳輸層安全性的可延伸驗證協定），它使用數位憑證而非密碼。憑證在密碼學上對每台設備都是唯一的，無法共享，且如果設備遺失或員工離職，可以立即撤銷。 [short pause] 到目前為止，一切都很順利。問題在於分發。您如何將唯一的憑證部署到您資產中的每台筆記型電腦、每部手機、每台平板電腦上（涵蓋 Windows、iOS、Android、macOS），而無需技術人員逐一操作設備？這正是 SCEP 所解決的問題。 [medium pause] SCEP 於 2020 年由網際網路工程任務組在 RFC 8894 中正式確立，儘管自 2000 年代初期以來它就已在企業環境中使用。這是一種允許託管設備使用預先設定的 URL 和挑戰密碼，直接向您的憑證授權單位請求其專屬憑證的協定。這裡的核心安全要點是：私鑰在設備本身上產生，儲存在設備的安全記憶體中（即 Windows 設備上的 TPM 晶片，或 Apple 硬體上的 Secure Enclave），且絕不會跨網路傳輸。設備會產生憑證簽署請求，將其傳送到 SCEP 閘道，閘道驗證挑戰，將請求轉發給您的憑證授權單位，CA 對其進行簽署，然後簽署後的憑證會傳回設備。整個過程對終端使用者而言是完全無感的。 [short pause] 現在，在 Microsoft 環境中，SCEP 閘道通常是 NDES（網路裝置登錄服務），這是一個 Windows Server 角色，充當您的 MDM 平台與 CA 之間的媒介。Microsoft Intune 將 SCEP 設定檔推送到託管設備，告知它們 NDES URL 和挑戰密碼。設備會自動完成其餘的工作。 [medium pause] 讓我帶您了解實際部署的情況。以一家擁有 150 家物業的飯店集團為例（想像一下 Premier Inn 的規模）。他們混合使用了供前台員工使用的 Windows 筆記型電腦、供房務主管使用的 iOS 設備，以及餐廳銷售點的 Android 平板電腦。在採用 SCEP 之前，他們運行的是 WPA2-Personal，並每季輪換一次共享密碼。每次輪換都會引發一波客服中心電話。透過 SCEP 和 Intune，他們依序部署了三個設定檔。首先是「受信任的根憑證」設定檔，這會告知每台設備信任公司的憑證授權單位。其次是「SCEP 憑證」設定檔，這會指示設備去收集其唯一的用戶端憑證。第三是「WiFi」設定檔，這會設定 SSID，將安全性類型設定為 WPA2-Enterprise 或 WPA3-Enterprise，並指向用於驗證的 SCEP 憑證。將這三個設定檔部署到 Intune 中的同一個設備群組，每台託管設備就會自動連線到企業 SSID，並擁有唯一的憑證，完全不需要使用者互動。 [short pause] The RADIUS 伺服器（通常是 Microsoft NPS 或雲端 RADIUS 服務）接收 EAP-TLS 驗證請求，根據 CA 驗證憑證，檢查憑證撤銷清單，並授予或拒絕存取。如果員工離職，您可以在 CA 中撤銷其憑證。他們的設備將在下一個驗證週期失去 WiFi 存取權限。無需重設密碼，也無需等待每季的輪換。 [medium pause] 現在，人們經常詢問 SCEP 與 PKCS（公鑰加密標準）之間的差異。兩者都適用於 Intune。關鍵差異在於私鑰產生的位置。使用 SCEP，私鑰是在設備上產生的。使用 PKCS，CA 會集中產生這兩個金鑰，並將私鑰推送到設備。這意味著私鑰會跨網路傳輸，從而引入了理論上的攔截風險。PKCS 有其適用場景，它更適合需要金鑰託管的 S/MIME 電子郵件加密。對於 WiFi 驗證，SCEP 每次都是正確的選擇。 [short pause] 讓我給您第二個場景：零售物業。想像一家在全英國擁有 200 家門市的時尚零售商，每家門市都運行 Cisco Meraki 存取點。他們的銷售點系統是基於 Windows 的，並透過 Intune 進行管理。他們需要符合 PCI DSS 合規性，這意味著對任何處理持卡人資料的設備進行網路分割和強式驗證。基於 SCEP 的 EAP-TLS 為他們在員工 SSID 上提供了設備級驗證，並由 RADIUS 策略驅動 VLAN 分配。POS 終端會自動進入符合 PCI 範圍的 VLAN。Guest WiFi（透過 Purple 等平台單獨處理）在完全隔離的 SSID 上運行，並有其專屬的驗證流程。這兩個網路永遠不會接觸。稽核人員很滿意，安全團隊也睡得更安穩。 [medium pause] 好的，讓我們來談談陷阱，因為有一些陷阱會讓團隊措手不及。 [short pause] 最常見的失敗模式是 Intune 中的群組目標不匹配。您的「受信任的根憑證」設定檔、您的 SCEP 設定檔以及您的 WiFi 設定檔都必須指向同一個 Azure AD 群組。如果 SCEP 設定檔指向「使用者」群組，而 WiFi 設定檔指向「設備」群組，Intune 將無法解決相依性，且 WiFi 設定檔會顯示為錯誤。請先檢查您的指派，這幾乎總是罪魁禍首。 [short pause] 第二個陷阱：NDES 伺服器可用性。您的 NDES 伺服器需要能從網際網路存取，以便遠端設備在到達現場之前進行登錄。安全的方法是透過 Azure AD Application Proxy，這可以讓您在不開啟輸入防火牆連接埠的情況下進行遠端存取。切勿將 NDES 直接暴露於網際網路。 [short pause] 第三：CRL 可用性。您的 RADIUS 伺服器在每次設備驗證時都會檢查憑證撤銷清單。如果 CRL 發佈點無法存取（可能是伺服器故障或防火牆規則變更），所有人的驗證都會失敗。請確保您的 CRL 端點具有高可用性，並定期進行測試。 [short pause] 第四：憑證範本權限。如果您的 NDES 連接器服務帳戶對憑證範本沒有「讀取」和「登錄」權限，設備在嘗試收集其憑證時會收到 HTTP 403 錯誤。這是一個簡單的權限修正，但在初始設定期間很容易被忽略。 [medium pause] 現在進入快速問答環節。 [short pause] SCEP 可以與非 Microsoft MDM 搭配使用嗎？可以。適用於 Apple 設備群的 Jamf、VMware Workspace ONE 以及大多數企業 MDM 平台都支援 SCEP 設定檔。該協定是與廠商無關的。 [short pause] SCEP 支援雲端 PKI 嗎？支援。Microsoft 在 Intune Suite 中自有的雲端 PKI 完全消除了對內部部署 NDES 伺服器的需求。SecureW2 和 Keyfactor 等第三方雲端 PKI 供應商也提供雲端 SCEP 端點。 [short pause] 那麼 WPA3-Enterprise 呢？WPA3-Enterprise使用相同的 802.1X 和 EAP-TLS 驗證堆疊。由 SCEP 核發的憑證運作方式完全相同。升級是在無線協定層，而不是憑證層。 [short pause] 憑證的有效期是多久？通常為一年，但您可以設定更短的有效期。Intune 會在到期前處理自動續期，因此使用者絕不會遇到中斷。 [medium pause] 總結來說。SCEP 實現了大規模的自動化憑證分發，消除了跨大型設備群部署 PKI 的手動開銷。私鑰保留在設備上，這是 EAP-TLS 的安全基礎。請依序部署：先部署「受信任的根憑證」，其次是「SCEP 設定檔」，第三是「WiFi 設定檔」，且全部指向同一個群組。透過 Application Proxy 安全地發佈您的 NDES 端點。保持您的 CRL 端點高可用性。如果您是從頭開始，請評估雲端 PKI，以完全消除對內部部署 NDES 的相依性。 [short pause] 對於 Guest WiFi（獨立的、面向訪客的網路），基於憑證的驗證並不是合適的模型。訪客沒有託管設備。這正是 Purple 等平台處理驗證流程的地方：Captive Portal、社群登入、電子郵件收集或簡訊驗證，所有這些都會匯入您的行銷團隊可以實際使用的第一方資料層。這兩種方法相輔相成：針對您的託管員工資產使用 SCEP，針對您的訪客網路使用 Purple。兩者都在相同的硬體上運行，並透過 VLAN 進行乾淨的分割。 [short pause] 以上是關於 SCEP 企業 WiFi 上網引導的簡報。完整的書面指南（包含架構圖、逐步 Intune 設定以及實際範例）可在 Purple 網站上取得。感謝您的收聽。