如何針對安全 BYOD 與 802.1X 網路驗證設定 SCEP

您好，歡迎收看 Purple 的技術簡報。我是您的主持人，今天我們將深入探討 SCEP - 簡單憑證註冊協定 - 以及如何正確配置它以實現安全的 BYOD 和 802.1X 網路驗證。 如果您是負責飯店集團、零售物業、體育場館或公共部門組織的 WiFi 基礎架構的 IT 經理、網路架構師或 CTO，這與您直接相關。我們今天不做理論探討，而是專注於架構與決策。 讓我們開始吧。 [SECTION: Introduction and Context - approximately 1 minute] 以下是您可能面臨的問題。您的員工裝置、承包商筆記型電腦和個人手機都需要網路存取權。您可能混合了託管和非託管裝置。而在您的基礎架構中，某處仍有一個共用的 WPA2 預先共用金鑰，有 12 個人知道，其中 3 個人去年就離職了。 這不是安全態勢，而是一個隱患。 解決方案是 802.1X - 用於基於連接埠之網路存取控制的 IEEE 標準。它能確保在裝置通過明確驗證之前，不會傳輸任何流量。但 802.1X 只是框架，真正的問題在於其中使用何種驗證方法。對於大規模的 BYOD 而言，答案是透過 SCEP 配置憑證的 EAP-TLS。 這就是我們今天要做的主題。 [SECTION: Technical Deep-Dive - approximately 5 minutes] 讓我們從 SCEP 的實際功能開始。 SCEP - 簡單憑證註冊協定 - 最初由 VeriSign 於 1999 年作為 IETF 的網際網路草案發佈，隨後在 RFC 8894 中正式化。它的工作非常直接：自動化大規模向裝置發行 X.509 數位憑證的程序，而無需人工手動產生和安裝每一個憑證。 以下是四個步驟的流程。 第一步：裝置連線到 SCEP 端點 - 這是一個透過 Windows Server 角色 NDES（網路裝置註冊服務）託管於內部部署，或是透過雲端 PKI 供應商託管的 URL。此 URL 是通往您的憑證授權單位（CA）的閘道。 第二步：裝置提供 SCEP 挑戰 - 這是一個證明其有權要求憑證的共用密碼。在像 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 Attacks）的保護機制。 現在我們來談談 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 Application Proxy 發行 NDES URL。這可以避免開啟輸入防火牆連接埠，並可讓您將條件式存取原則套用到註冊流程。 對於想要完全消除地端基礎架構的組織，雲端 PKI 提供者 - Microsoft 在 Intune 中自有的 Cloud PKI 或第三方選項 - 則完全移除了對 NDES 的相依性。 [SECTION: 實作建議與常見陷阱 - 約 2 分鐘] 讓我為您介紹我們最常遇到的三種失敗模式。 失敗模式一：群組目標不匹配。這是 Intune 中 WiFi 設定檔部署失敗最常見的原因。如果您的 Trusted Root 設定檔分配給使用者群組，您的 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。它強制執行受保護的管理框架，可防止去驗證攻擊。所有來自 Cisco Meraki、HPE Aruba、Ruckus 和 Juniper Mist 的硬體均支援此功能。 問題：那些不支援 802.1X 的裝置該怎麼辦 - 例如 IoT 感測器或舊型印表機？使用 MAC 驗證略過作為備用方案，但將這些裝置放在受到嚴格限制且無法存取公司資源的 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 按嚴格順序部署：先是 Trusted Root，然後是 SCEP 設定檔，最後是 WiFi 設定檔，且全部針對相同的群組。透過應用程式 Proxy 發佈 NDES，或遷移至雲端 PKI。在您的 RADIUS 伺服器上強制執行 CRL 或 OCSP 檢查。並且務必在用戶端 supplicant 上設定伺服器憑證驗證。 如果您目前仍在使用共用的預共用金鑰作為員工 WiFi，這就是本季度最需要做出的改變。憑證基礎架構在前期需要投入較多工作，但部署完成後，它能徹底消除一整類的身分憑證型攻擊，並通常能減少 70% 到 80% 與 WiFi 相關的技術支援工單。 如需完整的技術指南、架構圖和操作範例，請造訪 purple dot ai。感謝您的收聽。