部署 SCEP 實現高等教育機構安全 BYOD 與 WiFi 驗證

歡迎來到 Purple 技術簡報。我是您的主持人，今天我們要探討高等教育 IT 領域中經常出現的主題：部署 SCEP 以實現安全的 BYOD 與 WiFi 驗證。 如果您一直在校園網路中執行 PEAP-MSCHAPv2，那麼這場簡報與您息息相關。如果您已經計劃遷移到基於憑證的驗證，我們將為您提供架構、常見陷阱以及實現此目標的部署順序。 讓我們從問題開始。大學在設計上是開放式環境。學生在九月入學時，會攜帶兩部、三部，有時甚至是五部個人裝置。他們期望能立即、安全地連線，且無需聯絡服務台。對大多數機構而言，現實情況是，在開學後的四十八小時內，服務台的工單量就達到了兩千張。這不是人員配置的問題，而是架構的問題。 根本原因幾乎總是相同的：基於密碼的 WiFi 驗證。當您執行帶有 PEAP 和 MSCHAPv2 的 WPA2-Enterprise 時，您是在要求學生在每部裝置上手動配置 802.1X 設定。只要一個設定錯誤，他們就容易受到中間人攻擊。更糟糕的是，當大學每九十天強制重設一次密碼時，校園內的所有裝置都會同時失去 WiFi 連線。這是一場可以預測且可以避免的災難。 解決方案是使用 EAP-TLS 的憑證型驗證，而使其具備擴充性的機制就是 SCEP：簡單憑證註冊協定。IETF 於 2020 年在 RFC 8894 中將 SCEP 正式化，儘管它自 2000 年代初期就已開始使用。它使在裝置上請求和安裝 X.509 數位憑證的過程自動化，而無需對每部裝置進行任何手動的 IT 干預。 以下是它的高階運作原理。不論是 Microsoft Intune 還是 Jamf，您的 MDM 平台都會將 SCEP 承載資料（payload）推送到每部已註冊的裝置。該承載資料包含兩樣東西：SCEP 閘道 URL 和共用挑戰密碼。裝置會產生一個憑證簽署請求（CSR），將其傳送至 SCEP 閘道，閘道會驗證挑戰密碼，並將請求轉發給您的憑證授權單位（CA）。CA 會簽署憑證並將其傳回給裝置。從那時起，裝置會使用 EAP-TLS 向您的 WiFi 網路進行驗證：憑證向 RADIUS 伺服器證明裝置的身分，而 RADIUS 伺服器的憑證向裝置證明網路的身分。雙向驗證，無需透過無線傳輸交換密碼。 雙向驗證這點至關重要。使用 PEAP，當學生連線到廣播您的 SSID 的惡意存取點時，會很樂意交出他們的憑證。而使用 EAP-TLS，裝置在繼續操作之前會先檢查 RADIUS 伺服器憑證。如果它與信任的 CA 不相符，連線就會在背景無聲無息地失敗。您剛剛就消除了一整類的邪惡雙生攻擊。 現在我們來談談架構。適用於大學的生產環境 SCEP 部署有六個核心元件。第一，您的身分識別提供者：Microsoft Entra ID、Okta 或 Google Workspace。第二，您的 MDM 平台：適用於 Windows 與 Android 的 Intune，以及適用於 macOS 與 iOS 的 Jamf。第三，您的憑證授權單位 (CA)：可以是本地部署的 Microsoft Active Directory 憑證服務，或是雲端 PKI。第四，您的 SCEP 閘道：接收憑證請求的 HTTP 端點。第五，用於驗證的 RADIUS 伺服器。第六，您的存取層：設定為 802.1X 的 Cisco Meraki、HPE Aruba、Ruckus 或 Juniper Mist 基地台。 信任鏈的運作方式如下：CA 核發根憑證。該根憑證透過 MDM 發行至每台裝置，以建立信任。接著，CA 透過 SCEP 向裝置核發用戶端憑證。當裝置連線時，它會向 RADIUS 伺服器出示其用戶端憑證，而 RADIUS 伺服器也會向裝置出示其伺服器憑證。雙方皆對照受信任的根憑證進行驗證。系統會根據憑證的有效性而非密碼來允許或拒絕存取。 讓我為您說明實作順序。這是最行之有效的順序。 第一步：清理您的身分識別存放區。確保您的 Active Directory 或 Entra ID 具有定義明確的學生、教職員與訪客群組。憑證原則和 VLAN 指派將與這些群組綁定。 第二步：部署您的憑證授權單位。如果您使用的是 Microsoft ADCS，請建立雙層架構：離線根 CA 與線上發行 CA。初始設定完成後，根 CA 應進行實體隔離 (air-gapped)。 第三步：設定您的 SCEP 閘道。這是您的 MDM 將裝置導向的 HTTP 端點。確保從裝置執行初始註冊的網路區段（通常是您的 onboarding SSID）可以存取該端點。 第四步：設定您的 RADIUS 伺服器。將發行 CA 憑證匯入為受信任的 CA。將 EAP-TLS 設定為您的驗證方法。設定 VLAN 回傳屬性，以便 RADIUS 可以動態地將學生指派到正確的網路區段。 第五步：設定您的 MDM 設定檔。在 Intune 中，先建立一個「受信任的憑證」設定檔，接著建立一個「SCEP 憑證」設定檔，然後再建立一個參照該 SCEP 憑證的 WiFi 設定檔。請嚴格按照此順序進行部署。每個設定檔皆依賴於前一個設定檔的就位。 第六步：設定您的基地台。在 Cisco Meraki、HPE Aruba、Ruckus 或 Juniper Mist 上，將您的安全 SSID 設定為 WPA2-Enterprise 或 WPA3-Enterprise。將 RADIUS 逾時時間設定為至少五秒，以因應註冊高峰期時的憑證驗證延遲。 接下來，談談常見的陷阱。我曾多次看到這些問題導致部署失敗。 第一個是部署 MDM 設定檔的順序錯誤。如果 WiFi 設定檔在 SCEP 憑證設定檔之前抵達裝置，裝置將沒有可用於驗證的憑證。連線將會失敗，使用者就得向服務台求助。 第二個陷阱是遺漏了 BYOD 裝置。Intune 和 Jamf 可管理您機構所屬的裝置，但學生的個人裝置並未註冊到您的 MDM 中。針對這些裝置，您需要一個自助式的引導上線入口網頁。學生透過其大學憑證進行單一登入（Single Sign-On）驗證，然後入口網頁會使用 SCEP 來配置憑證。Purple 的平台將此引導上線流程直接整合到 Captive Portal 體驗中，讓學生在無需 IT 人員參與的情況下，於兩分鐘內完成註冊。 第三個陷阱是高峰上線期間的 RADIUS 逾時失敗。請在 9 月之前（而非 9 月期間）對您的 RADIUS 基礎架構進行壓力測試。在至少兩個 RADIUS 節點之間實施負載平衡。 第四個陷阱是憑證廢止。當學生離校、或者裝置遺失或被盜時，您需要立即廢止憑證。確保您的 CA 發佈了憑證廢止清單（CRL），並且您的 RADIUS 伺服器在每次驗證時都會進行檢查。 接下來是針對我們最常聽到的問題進行快速問答。 SCEP 在沒有 MDM 的情況下可以運作嗎？技術上可以，但實際上不行。如果沒有 MDM 來推送 SCEP 承載資料和 WiFi 設定檔，您就必須回到手動設定裝置的狀態。 憑證有效期應該是多久？對於學生裝置，一到兩年是標準做法。這段時間足夠撐過一整個學年而不會產生更新摩擦，同時也足夠短，以便在憑證遭受破解時限制曝露風險。 對於不支援 802.1X 的 IoT 裝置該怎麼辦？請將 MAC 驗證繞過（MAB）與自助服務裝置註冊入口網頁結合使用。學生註冊其遊戲主機或智慧電視的 MAC 位址，然後您的 NAC 系統會將其放入正確的 VLAN 中。 這適用於 eduroam 嗎？是的。eduroam 聯盟完全支援 EAP-TLS。由您校園 CA 核發的憑證可以在全球任何參與該計畫的機構中驗證 eduroam 學生身份。 最後，以下是決定 SCEP 部署成功的的三個關鍵決策。 第一：首先選擇您的 CA 架構。地端 ADCS 讓您擁有完全的主導權，雲端 PKI 則為您帶來營運簡化。這裡如果選錯，會花費您數個月的時間重新修改。 第二：從第一天起就自動化 BYOD 引導上線。不要假設學生會手動設定他們的個人裝置。他們不會這麼做。在學期開始之前，建置好自助服務入口網頁。 第三：在 9 月之前測試您 RADIUS 在負載下的承載能力。學期第一天發生 RADIUS 斷線是完全可以預防的。 Purple 的平台支援以上所有三項：雲端重疊 PKI 整合、透過我們 Captive Portal 實現的自助式 BYOD 引導上線，以及在 8 萬個實際場域進行過測試、達到 99.999% 可用性運作時間的 RADIUS 基礎架構。 感謝您加入 Purple 技術簡報。如需進一步指導，請造訪 purple.ai。