如何設定 SCEP 以實現安全的 BYOD 與 802.1X 網路驗證

哈囉，歡迎收聽來自 Purple 的技術簡報。我是您的主持人，今天我們將深入探討 SCEP（簡單憑證註冊協定）的細節，以及如何正確設定它以實現安全的 BYOD 和 802.1X 網路驗證。 如果您是負責飯店集團、零售物業、體育場或公共部門機構 WiFi 基礎架構的 IT 經理、網路架構師或 CTO，這與您息息相關。我們今天不談理論，我們談架構和決策。 讓我們開始吧。 [SECTION: 導言與背景 - 約 1 分鐘] 這可能是您目前面臨的問題：您有員工裝置、承包商筆記型電腦和個人手機都需要網路存取。您的環境中可能混合了託管和非託管裝置。而且在您的基礎架構中，某處仍在使用一個有 12 個人知道的 WPA2 共享金鑰，而其中有 3 個人去年就已經離職了。 這不是安全防護，這是一個安全隱患。 解決方案是 802.1X——基於連接埠網路存取控制的 IEEE 標準。它能確保在裝置經過明確驗證之前，無法傳輸任何流量。但 802.1X 只是框架，真正的關鍵在於其中採用何種驗證方法。對於大規模的 BYOD，答案是透過 SCEP 部署憑證的 EAP-TLS。 這就是我們今天要探討的內容。 [SECTION: 技術深挖 - 約 5 分鐘] 我們先從 SCEP 實際的作用開始談起。 SCEP（簡單憑證註冊協定）最初由 VeriSign 建立，並於 1999 年由 IETF 發佈為網際網路草案，隨後在 RFC 8894 中正式化。它的任務非常直接：自動化大規模向裝置核發 X.509 數位憑證的流程，而無需人工手動產生和安裝每個憑證。 以下是四個步驟的流程： 步驟一：裝置連線到 SCEP 端點——這是一個託管在內部部署（透過名為 NDES，即網路裝置註冊服務的 Windows Server 角色）或透過雲端 PKI 供應商提供的 URL。此 URL 是通往您的憑證授權單位的閘道。 步驟二：裝置出示 SCEP 挑戰（Challenge）——這是一個共享秘密，用以證明其有權請求憑證。在像 Microsoft Intune 這樣的 MDM 託管環境中，此挑戰是針對每台裝置動態且唯一發送的，這比在所有裝置之間共享靜態密碼要安全得多。 步驟三：裝置在本機產生自己的私鑰和公鑰組。它使用公鑰建立憑證簽署請求（CSR），並將其傳送到 SCEP 伺服器。這裡有一個關鍵的安全點：私鑰絕不會離開裝置。它是在本機產生，儲存在裝置的安全記憶體中（即 Windows 上的 TPM 或 iOS 上的 Secure Enclave），且絕不進行傳輸。這就是為什麼 SCEP 是網路驗證的正確選擇，而不是 PKCS（在 PKCS 中，CA 集中產生金鑰並必須將其推送到裝置）。 步驟四：憑證授權單位驗證 CSR，使用 CA 的私鑰對其進行簽署，並將簽署後的 X.509 憑證傳回給裝置。裝置現在擁有一個唯一的密碼學身分。 現在，該憑證如何用於 802.1X 驗證？ 當裝置連線到您的 WiFi SSID 時，無線基地台（無論是 Cisco Meraki、HPE Aruba、Ruckus、Juniper Mist 還是 Ubiquiti UniFi）將充當驗證者。它本身不做出驗證決策，而是將 EAP 交換轉發到您的 RADIUS 伺服器。這可以是 Microsoft NPS、Cisco ISE 或 Aruba ClearPass。 RADIUS 伺服器啟動 EAP-TLS 握手。裝置出示其透過 SCEP 部署的用戶端憑證。RADIUS 伺服器會驗證三件事：回溯到信任根 CA 的憑證鏈、憑證到期日，以及憑證是否已被撤銷（透過對照憑證撤銷清單 CRL，或透過線上憑證狀態協定 OCSP 進行檢查）。 如果這三項檢查全部通過，RADIUS 伺服器會傳送 EAP-Success 訊息，無線基地台隨即開啟連接埠。裝置便成功連上網路。 這是雙向驗證。裝置也會驗證 RADIUS 伺服器的憑證。如果有人架設了惡意無線基地台，裝置會拒絕連線，因為該伺服器憑證無法通過信任 CA 的驗證。這就是您防範邪惡雙生（Evil Twin）攻擊的保護機制。 現在我們來談談 Microsoft Intune 中的部署順序，因為這是我們在企業環境中最常見的 MDM 平台。 您需要按照嚴格的順序部署三個 Intune 設定設定檔。第一，「信任的根憑證」設定檔——這會將您的根 CA 憑證推送到每台裝置，以便它們信任您的 PKI。第二，「SCEP 憑證」設定檔——這會告知裝置 SCEP URL、主體名稱格式、金鑰用法以及用於用戶端驗證的延伸金鑰用法。用戶端驗證的 OID 為 1.3.6.1.5.5.7.3.2。第三，「WiFi 設定檔」——這會指定 SSID、將安全性類型設定為 WPA2-Enterprise 或 WPA3-Enterprise、將 EAP 類型設定為 EAP-TLS，並連結到 SCEP 憑證設定檔。 順序至關重要。WiFi 設定檔相依於 SCEP 設定檔，而 SCEP 設定檔又相依於信任的根憑證設定檔。如果不按順序部署，您將會收到錯誤。 您需要做出的其中一個架構決策是 NDES 伺服器的託管位置。它必須能從網際網路存取，以便裝置在到達現場之前進行註冊。安全的方法是透過 Microsoft Entra ID 應用程式 Proxy 發佈 NDES URL。這可以避免開啟防火牆的輸入連接埠，並允許您對註冊流程套用條件式存取原則。 對於希望完全消除內部部署基礎架構的組織，雲端 PKI 供應商（Microsoft 在 Intune 中自有的 Cloud PKI，或第三方方案）可以完全免除對 NDES 的相依性。 [SECTION: 實作建議與常見陷阱 - 約 2 分鐘] 讓我為您介紹我們最常遇到的三種失敗模式。 失敗模式一：群組目標指派不相符。這是 Intune 中 WiFi 設定檔部署失敗最常見的原因。如果您的信任根憑證設定檔指派給「使用者群組」，您的 SCEP 設定檔指派給「裝置群組」，而您的 WiFi 設定檔指派給另一個不同的「使用者群組」，Intune 將無法解析相依性鏈結。所有三個設定檔必須針對完全相同的 Azure AD群組（全為使用者或全為裝置）。選擇其中一個並保持一致。 失敗模式二：CRL 可用性。您的 RADIUS 伺服器會檢查 CRL 以驗證憑證是否已被撤銷。如果 CRL 發佈點（內嵌在憑證中的 CDP URL）無法存取，所有裝置的驗證都會失敗。這是網路變更後發生大規模中斷的常見原因。請確保您的 CDP 具備高可用性，最好同時發佈到內部 URL 和供遠端裝置使用的外部 URL。考慮將 OCSP 作為比 CRL 檢查更具彈性的替代方案。 失敗模式三：未在用戶端上強制執行伺服器憑證驗證。這是 802.1X 部署中影響最大、最單一的錯誤設定。如果您的 MDM 部署 WiFi 設定檔未指定信任的 CA 和預期的 RADIUS 伺服器名稱，裝置將會連線到任何出示任何憑證的伺服器。這違背了 EAP-TLS 的初衷。請務必在您的 WiFi 設定檔中設定伺服器驗證。 [SECTION: 快速問答 - 約 1 分鐘] 我們來進行幾個快速問答。 問題：我們需要 WPA3 嗎？是的。請移轉至 WPA3-Enterprise。它強制要求受保護的管理畫面（PMF），這可以阻擋取消驗證攻擊。來自 Cisco Meraki、HPE Aruba、Ruckus 和 Juniper Mist 的所有硬體皆支援此功能。 問題：那不支援 802.1X 的裝置（例如 IoT 感測器或舊型印表機）該怎麼辦？使用 MAC 驗證略過（MAB）作為備用方案，但請將這些裝置放置在受到嚴格限制且無法存取企業資源的 VLAN 上。 問題：Purple 在其中扮演什麼角色？Purple 的 Guest WiFi 平台處理訪客和來賓存取層——包括 Captive Portal、資料收集和分析。而您的 802.1X 和 SCEP 基礎架構則處理員工和託管裝置的存取。它們運行在不同的 SSID 和不同的 VLAN 上。Purple 與 Cisco Meraki、HPE Aruba、Ruckus、Juniper Mist、Ubiquiti UniFi、Cambium、Extreme 和 Fortinet 整合，因此能保護您的硬體投資。 [SECTION: 總結與後續步驟 - 約 1 分鐘] 總結一下。 SCEP 自動化大規模的憑證核發。私鑰保留在裝置上——這是相較於 PKCS 的安全優勢。透過 MDM 依嚴格順序部署：信任的根憑證，接著是 SCEP 設定檔，最後是 WiFi 設定檔，且全部針對同一個群組。透過應用程式 Proxy 發佈 NDES，或移轉至雲端 PKI。在您的 RADIUS 伺服器上強制執行 CRL 或 OCSP 檢查。並且務必在用戶端要求者上設定伺服器憑證驗證。 如果您目前仍在使用共享的預先共用金鑰來提供員工 WiFi，這就是您本季應該做出的改變。憑證基礎架構在前期需要較多工作，但它能消除整類基於認證的攻擊，且部署後通常能減少 70% 到 80% 與 WiFi 相關的客服工單。 如需完整的技術指南、架構圖和實際範例，請造訪 purple.ai。感謝您的收聽。