如何設定 SCEP 以實現自動化企業級 WiFi 憑證登錄
本指南說明如何設定 SCEP (簡單憑證註冊協定) 以進行自動化企業級 WiFi 憑證登錄，內容涵蓋從 PKI 和 NDES 到 MDM 設定檔部署以及 RADIUS 驗證的完整架構。本指南專為飯店、零售連鎖、體育場、會議中心及公共部門機構的 IT 經理、網路架構師和 CTO 設計，旨在協助他們淘汰預先共用金鑰，並實施具擴展性、基於身分的 802.1X EAP-TLS 驗證。Purple 獨立於硬體的雲端重疊平台可與此架構直接整合，提供與憑證驗證員工網路並行的訪客和 BYOD WiFi 層。
收聽此指南
查看播客逐字稿
📚 核心系列的一部分：Enterprise WiFi Security Guide →
執行摘要
對於企業空間 - 無論是擁有 200 間客房的飯店、擁有 50 個據點的零售連鎖店，還是大型會議中心 - 依賴預共用金鑰來管理員工的 WiFi 都是一種安全風險和營運瓶頸。單一洩露的密碼就會暴露整個網路。透過 802.1X 和 EAP-TLS（可延伸驗證通訊協定 - 傳輸層安全性）進行基於憑證的驗證，可完全消除此風險。在存取點授予其網路存取權限之前，每個裝置都會以加密方式證明其身分。
挑戰在於分發。在數千台 Windows、iOS 和 Android 裝置上手動部署專屬的用戶端憑證是不可行的。SCEP（簡單憑證登冊協定）（由 IETF 於 2020 年正式確立為 RFC 8894）解決了這個問題。它透過您的 MDM 平台，在受管理裝置上自動執行申請、核發和安裝數位憑證的流程 - 無需任何使用者互動。
本指南涵蓋了整個架構：SCEP 的功能、它如何與 Microsoft Intune、Jamf 和其他 MDM 平台整合、大多數團隊常犯錯的確切部署順序，以及導致服務中斷的營運陷阱。我們還介紹了飯店業和零售業的兩個實際部署案例，並解釋了 Purple 的 Guest WiFi 平台如何與您經過憑證驗證的員工網路並行運作。
收聽補充的資訊性 Podcast：
深入技術分析：SCEP、PKI 與 802.1X
SCEP 的實際功能
SCEP 並非取代您的 PKI（公開金鑰基礎建設）。它是位於其上的自動化登冊層。您的 PKI（通常是包含離線根 CA 和線上發行 CA 的雙層階層）仍然是信任錨。SCEP 自動執行裝置向該 CA 要求憑證的步驟，從而消除手動產生 CSR 和安裝憑證的需求。
在 WiFi 驗證的背景下，目標協定是 EAP-TLS。這是 802.1X 驗證方法，要求用戶端裝置和 RADIUS 伺服器都必須提供有效的 X.509 憑證。在沒有密碼學證明的狀況下，雙方都不會信任彼此。這種雙向驗證模型消除了認證資料被盜取的風險，並能防範「邪惡雙生仔（evil twin）」攻擊 - 攻擊者會建立偽造的存取點以收集使用者名稱和密碼。
如需 EAP-TLS 握手程序的詳細分析，請參閱我們的指南： WiFi Certificate Authentication: Secure Network Access 。
逐步了解 SCEP 註冊流程
完整註冊鏈的運作方式如下。您的 MDM 平台 - Microsoft Intune、Jamf 或其他 MDM - 會將 SCEP 承載資料（payload）傳送至受管理裝置。該承載資料包含兩樣東西：指向您 NDES（網路裝置註冊服務）伺服器或雲端 SCEP 閘道的 SCEP URL，以及挑戰密碼或共用金鑰。
裝置會在本地端自行產生其公鑰與私鑰對。這是 SCEP 的關鍵安全特性：私鑰是在裝置上產生，儲存於安全孤島（secure enclave）或 TPM 晶片中，且絕對不會在網路中傳輸。裝置接著會建立憑證簽署要求（CSR）並將其傳送至 SCEP 閘道。閘道會驗證挑戰密碼，將 CSR 轉發給您的憑證授權單位（CA），CA 簽署後將公開憑證傳回給裝置。
從此時起，當裝置連線到您的 WiFi SSID 時，就會向 RADIUS 伺服器出示該憑證。RADIUS 伺服器會根據其 CA 信任鏈驗證憑證，檢查憑證撤銷清單（CRL）以確認憑證未被撤銷，若一切無誤，則會向存取點傳送 Access-Accept 訊息。裝置便順利連上網路。整個過程對使用者而言是完全無感的。
SCEP 與 PKCS：WiFi 該使用哪一個
像 Intune 這樣的 MDM 平台支援兩種憑證傳遞機制：SCEP 與 PKCS（公開金鑰密碼學標準）。兩者的架構差異顯著。
使用 SCEP 時，私鑰是在裝置上產生，且絕對不會離開裝置。使用 PKCS 時，憑證授權單位會集中產生公鑰和私鑰，並由憑證連接器透過網路將金鑰對傳送至裝置。這意味著私鑰會被傳輸，因而引入了理論上的攻擊面。 PKCS 適用於需要金鑰託管的案例（例如 S/MIME 郵件加密）。對於 WiFi 驗證，SCEP 才是正確的選擇。其私鑰會保留在裝置上。
| 屬性 | SCEP | PKCS |
|---|---|---|
| 私鑰產生 | 在裝置上 (TPM/Secure Enclave) | 集中式 (CA) |
| 私鑰傳輸 | 從不 | 透過網路 |
| 需要 NDES 伺服器 | 是 (或雲端閘道) | 否 |
| 建議用於 WiFi | 是 | 否 |
| 建議用於 S/MIME | 否 | 是 |
硬體相容性
SCEP 和 EAP-TLS 是獨立於廠商的標準。它們適用於 Cisco Meraki、HPE Aruba、Ruckus、Juniper Mist、Ubiquiti UniFi、Cambium、Extreme Networks 和 Fortinet 的存取點。您是在 RADIUS 設定（不論是 Windows NPS、FreeRADIUS 還是雲端 RADIUS 服務）中定義憑證驗證原則和動態 VLAN 分配。
動態 VLAN 分配是您透過裝置識別來區隔網路的方式。員工裝置會分配到 VLAN 10 以存取內部系統。承包商裝置會分配到 VLAN 20 且僅能存取網際網路。銷售點終端機分配到 VLAN 30 且僅能存取付款處理系統。這一切都由憑證屬性和 RADIUS 原則管理，不需要針對每個裝置進行任何手動介入。
若要深入瞭解 WiFi Analytics 如何與基於識別的網路分段整合，請參閱我們的分析平台概觀。
部署指南：部署順序
成功設定企業級 SCEP WiFi 需要嚴格遵循特定的部署順序。MDM 平台會強制執行設定檔相依性：在裝置上存在該憑證之前，無法套用參照 SCEP 憑證的 WiFi 設定檔。違反此順序是部署失敗最常見的原因。
順序為：第一是信任根 (Trusted Root)，第二是 SCEP 設定檔，第三是 WiFi 設定檔。此順序不可變更。
步驟 1：部署信任根 (Trusted Root) 憑證設定檔
在任何裝置可以申請用戶端憑證或信任您的 RADIUS 伺服器之前，它必須先信任核發的憑證授權單位 (CA)。將您的根 CA 憑證（以及任何中繼 CA 憑證）匯出為 .cer 檔案。在您的 MDM 管理中心中，建立一個信任憑證設定檔，上傳 .cer 檔案，並將其部署到您的目標裝置群組。
如果您擁有雙層 PKI 階層（建議），則需要部署根 CA 和發行 CA 憑證，這可以作為個別的信任憑證設定檔，或作為單一設定檔中的鏈結，具體取決於您的 MDM 平台。
步驟 2：設定 SCEP 憑證設定檔
建立信任後，請設定 SCEP 設定檔以指示裝置如何取得其用戶端憑證。
建立新的組態設定檔，然後選擇 SCEP 憑證設定檔類型。設定主體名稱（Subject name）格式。對於基於使用者驗證，預設值為 CN={{UserPrincipalName}}。對於裝置驗證（共用裝置、IoT、POS 終端），請使用 CN={{AAD_Device_ID}}。將金鑰使用方法（Key usage）設定為數位簽章與金鑰加密。將延伸金鑰使用方法（Extended Key Usage）設定為用戶端驗證（OID：1.3.6.1.5.5.7.3.2）。將此設定檔與步驟 1 中建立的受信任根憑證設定檔相連結。提供 NDES 伺服器的外部 URL。特別針對 Microsoft Intune，NDES 伺服器必須透過 Azure AD Application Proxy 發行，以允許遠端裝置在進入現場之前進行登冊。請勿將 NDES 直接暴露於網際網路。
步驟 3：部署 802.1X WiFi 設定檔
最後一個步驟是發送將憑證與網路 SSID 連結的 WiFi 組態。建立一個 Wi-Fi 組態設定檔。輸入與您的存取點廣播完全一致的網路名稱（SSID）。選擇 WPA2-Enterprise 或 WPA3-Enterprise 作為安全性類型。將 EAP 類型設定為 EAP-TLS。在驗證設定中，選擇在步驟 2 中建立的 SCEP 憑證設定檔作為用戶端驗證憑證。指定用於伺服器驗證的 Trusted Root 憑證 - 這可確保裝置僅連線到您合法的 RADIUS 伺服器，而非惡意存取點。
身分識別提供者整合
SCEP 憑證屬性（特別是主體替代名稱 (SAN)）可以包含 Microsoft Entra ID、Okta 或 Google Workspace 的使用者主要名稱。這會將憑證與特定身分識別連結。當您在 Entra ID 中停用帳戶，且 MDM 移除裝置註冊時，憑證將被撤銷，且 WiFi 存取權會自動切斷。這種自動化撤銷是預先共用金鑰無法比擬的安全優勢。
若要深入了解 EAP Method WiFi: A Guide to Secure Network Access ，包括 PEAP-MSCHAPv2 轉移路徑，請參閱我們的專屬指南。
最佳實踐與業界標準
NDES 伺服器部署位置
NDES 伺服器必須能從網際網路存取，以便裝置在到達現場之前進行註冊。請透過 Azure AD Application Proxy 發布 NDES 的 URL。這可提供安全的遠端存取，而無需開啟輸入防火牆連接埠，並允許您對註冊流程套用條件式存取原則。切勿將 NDES 直接暴露於網際網路。
對於管理超過 500 台裝置的網路，請考慮使用雲端 SCEP 閘道，而不是本地的 NDES。雲端閘道可消除 NDES 的單一故障點，實現水平擴充，且通常能與雲端 RADIUS 服務直接整合。
CRL 可用性
您的 RADIUS 伺服器在每次裝置驗證時都會檢查憑證撤銷清單 (CRL)。如果您的 CRL 散發點 (CDP) 無法使用 - 因伺服器故障或 URL 變更 - 網路上的所有裝置將同時驗證失敗。請設定您的 NPS 或 RADIUS 伺服器以執行嚴格的 CRL 檢查，並使您的 CRL 端點具有高可用性。在正式上線前測試撤銷功能。
PCI DSS 4.0 的要求 8.6 規定持卡人資料環境的網路層必須使用多因素驗證。使用透過 SCEP 部署憑證的 EAP-TLS 滿足了 Retail 和 Hospitality 環境中無線網路的此項要求。
WPA3 相容性
EAP-TLS 與 WPA3-Enterprise 完全相容。採用 192 位元安全性套件 (Suite B) 的 WPA3-Enterprise 需要 EAP-TLS，且是 Wi-Fi Alliance 針對政府、金融和醫療網路推薦的組合。如果您是在具有嚴格合規要求的 Saúde 或 Transportes 環境中進行部署，採用 EAP-TLS 的 WPA3-Enterprise 是正確的目標架構。
BYOD 與訪客 WiFi
SCEP 需要 MDM 註冊才能傳送憑證承載資料。它不適用於未受管理的 BYOD 裝置或訪客。對於這些使用案例，您需要一個獨立的 SSID，並搭配 Captive Portal 和身分驗證。Purple 的平台能乾淨地處理該層級，與您透過憑證驗證的員工網路共存。我們的 Guest WiFi 平台支援主動同意選擇、第一方數據收集，並與 Microsoft Entra ID、Okta 和 Google Workspace 整合以進行身分驗證。
疑難排解與風險緩釋
WiFi 設定檔套用失敗
症狀： 裝置接收到 Trusted Root 和 SCEP 憑證，但 WiFi 設定檔在 MDM 中顯示為「錯誤」或「不適用」。
**根本原因：**群組指派不相容。如果 SCEP 設定檔的目標是使用者群組，而 WiFi 設定檔的目標是裝置群組，MDM 將無法解析此相依性。
**解決方案：**稽核您的指派。確保信任的根憑證 (Trusted Root)、SCEP 和 WiFi 設定檔的目標都完全指向相同的目錄群組。
NDES 403 Forbidden 錯誤
**症狀：**裝置無法取得 SCEP 憑證。NDES 的 IIS 記錄顯示 HTTP 403 錯誤。
**根本原因：**MDM Certificate Connector 的服務帳戶在憑證範本上沒有「讀取」和「註冊」(Read and Enroll) 權限，或者防火牆的 URL 篩選封鎖了 SCEP 的查詢字串參數。
**解決方案：**確認連接器帳戶在 CA 範本上具有「讀取」和「註冊」權限。檢查防火牆記錄，確保未封鎖包含 ?operation=GetCACaps 的 URL。
CRL 到期後的大規模驗證失敗
**症狀：**網路上所有裝置同時驗證失敗。
**根本原因：**CRL 已到期或無法存取 CDP URL。RADIUS 伺服器無法確認憑證是否有效，並預設為失敗 (fails closed)。
**解決方案：**設定 CRL 監控與警示。發布 CRL 時，其有效期應顯著大於發布間隔。在部署前，從 RADIUS 伺服器測試 CDP 的可達性。
憑證到期導致的無聲失敗
**症狀：**個別裝置斷斷續續地連線失敗，沒有明顯的規律。
**根本原因：**用戶端憑證已到期，且 MDM 未能成功更新。
**解決方案：**將憑證更新設定為在憑證壽命達 80% 時觸發。監控 MDM 註冊狀態報告，找出有憑證錯誤的裝置。根據您的裝置更新週期設定適當的憑證有效期 - 對於受管端點，通常為一到兩年。
ROI 與企業影響
過渡到基於 SCEP 的 802.1X 憑證驗證，可在安全、營運和合規性方面帶來可衡量的回報。
**減少支援票證：**基於密碼的 WiFi 會產生大量的支援票證 - 包括密碼過期、鎖定和拼寫錯誤。基於憑證的驗證對使用者而言是無感的。企業在移轉後，通常會看到與 WiFi 相關的支援票證量減少 70-80%。
**安全態勢：**EAP-TLS 消除了憑證收集和中間人攻擊 (Man-in-the-Middle)。這直接支援了零售和餐旅業網路符合 PCI-DSS 4.0 標準，以及符合 GDPR 第 32 條關於適當技術安全措施的要求。
**自動化撤銷：**當員工離職時，在 Microsoft Entra ID 中停用其帳戶會觸發自動證書撤銷與 MDM 解除關聯。無需網路團隊進行任何手動干預，即可立即切斷 WiFi 存取權限。
**網路分段：**透過 RADIUS 證書屬性進行動態 VLAN 分配，為您提供加密強制的網路分段。裝置會根據證書屬性進入正確的網路分段，而不是依賴 SSID 選擇或 MAC 地址過濾（這兩者都極易被繞過）。
Purple 在超過 80,000 個運作中的場所運作，擁有 99.999% 的正常執行時間，且我們的平台已獲得 ISO 27001、GDPR、CCPA 和 Cyber Essentials 認證。我們與硬體無關的雲端疊加層可與 Cisco Meraki、HPE Aruba、Ruckus、Juniper Mist、Ubiquiti UniFi、Cambium、Extreme 和 Fortinet 整合 - 讓您經過證書驗證的員工網路與我們的訪客 WiFi 層在同一個基礎架構上運作。
欲深入了解行為分析（ Behavioral Analytics: Insights for WiFi Networks ）如何輔助您的安全網路部署，請參閱我們的分析指南。
參考資料
[1] RFC 8894: Simple Certificate Enrollment Protocol - IETF [2] Configure infrastructure to support SCEP with Intune - Microsoft Learn [3] PCI DSS Wireless Guidelines - PCI Security Standards Council
關鍵定義
SCEP (Simple Certificate Enrollment Protocol)
在 RFC 8894 中定義的標準協定，允許受管理裝置透過 HTTP 自動向憑證授權單位要求並接收 X.509 數位憑證，並使用共用的挑戰密碼進行初始驗證。私鑰在裝置上產生，絕不傳輸。
MDM 平台（如 Microsoft Intune 與 Jamf）用於向託管終端大規模部署 WiFi 驗證憑證的標準機制。
EAP-TLS (Extensible Authentication Protocol - Transport Layer Security)
最安全的 802.1X 驗證方法，要求用戶端裝置與 RADIUS 伺服器雙方皆須出示有效的 X.509 憑證。雙向驗證意味著在沒有密碼學證明的情況下，雙方互不信任。
企業級 WiFi 的目標驗證協定。PCI DSS 4.0、WPA3-Enterprise 192-bit (Suite B) 以及 HIPAA 針對處理敏感資料的無線網路強制要求或強烈建議使用此協定。
NDES (Network Device Enrollment Service)
一種 Microsoft Windows Server 角色，在支援 SCEP 的裝置與憑證授權單位之間充當登冊授權單位 (RA)。它負責驗證挑戰密碼，並代表缺乏網域認證的裝置將 CSR 轉發給 CA。
搭配 Microsoft Intune 進行 SCEP 部署所需的基礎架構。應透過 Azure AD Application Proxy 發行，而非直接公開至網際網路。
PKI (Public Key Infrastructure)
用於發行、管理和撤銷數位憑證的憑證授權單位、政策和程序之階層架構。雙層 PKI 包含一個離線根 CA（主要信任錨點）和一個線上發行 CA（負責日常憑證發行）。
部署 EAP-TLS 與 SCEP 不可妥協的前置需求。根 CA 應保持實體隔離（Air-gapped）；其私鑰是您整個憑證信任鏈的基礎。
CSR (Certificate Signing Request)
由裝置產生的訊息，其中包含其公鑰與識別資訊，傳送至憑證授權單位以要求已簽署的數位憑證。在 SCEP 中，CSR 在傳輸前於裝置上產生並封裝在 PKCS 套件中。
在 SCEP 註冊流程中由裝置自動產生。用於簽署 CSR 的私鑰絕不會離開裝置。
CRL (Certificate Revocation List)
由憑證授權單位發佈的名單，其中包含在到期日之前已被撤銷的憑證序號。RADIUS 伺服器會在每次身分驗證嘗試時檢查 CRL，以確保被撤銷的憑證無法存取網路。
CRL 發佈點 (CDP) 的可用性至關重要。如果 RADIUS 伺服器無法連線至 CRL，它會採取防失誤關閉機制並拒絕所有身分驗證，進而導致整個網路中斷。
RADIUS (Remote Authentication Dial-In User Service)
一種網路協定，為網路存取提供集中式的驗證、授權和計費 (AAA)。在 802.1X WiFi 中，RADIUS 伺服器會驗證用戶端憑證、檢查 CRL，並向存取點傳回 Access-Accept 或 Access-Reject 訊息。
在 802.1X 要求項-驗證項-伺服器模型中的驗證伺服器。常見的實作包括 Windows NPS、FreeRADIUS 和雲端 RADIUS 服務。
動態 VLAN 指派
一項 RADIUS 功能，可根據憑證屬性或目錄群組成員資格，將通過驗證的裝置放入特定的 VLAN，而不是依賴 SSID 選擇或 MAC 位址篩選。透過裝置識別身分強制執行網路分段。
允許單一 SSID 為具有不同網路存取權限的多種裝置類型提供服務。員工裝置獲得 VLAN 10 (內部存取)；承包商裝置獲得 VLAN 20 (僅限網際網路)；POS 終端機獲得 VLAN 30 (僅限支付系統)。
MDM (Mobile Device Management)
IT 團隊用於註冊、設定、保護和管理智慧型手機、平板電腦和筆記型電腦的軟體。Microsoft Intune 和 Jamf 等 MDM 平台使用 SCEP 設定檔將憑證註冊指令推送到受管理的裝置，無需使用者進行任何互動。
基於 SCEP 的憑證部署的前提條件。裝置必須先註冊 MDM，然後才能接收 SCEP 和 WiFi 設定檔。未受管理的 BYOD 裝置需要採用不同的上網註冊方式。
範例
一家擁有 200 間客房的 Premier Inn 飯店需要為其收銀點 (POS) 平板電腦和房務智慧型手機確保員工 WiFi 的安全。他們目前使用已被洩露給承包商的預先共用金鑰。他們透過 Microsoft Intune 管理裝置，並擁有 iOS 和 Android 裝置。該飯店使用 HPE Aruba 存取點。
- 部署內部的 Microsoft AD CS 雙層 PKI。在專用的 Windows Server 上設定 NDES，並透過 Azure AD Application Proxy 發行。
- 在 Intune 中，建立一個包含根憑證授權單位 (Root CA) 和發行 CA (Issuing CA) 憑證的信任根憑證設定檔。部署到「Property Staff Devices」Azure AD 群組。
- 在 Intune 中建立一個指向 NDES 外部 URL 的 SCEP 憑證設定檔。由於這些是共用裝置，將主體名稱格式設定為 CN={{AAD_Device_ID}}。將金鑰用途設定為數位簽章與金鑰加密，將延伸金鑰用途設定為用戶端驗證。部署到「Property Staff Devices」。
- 為員工 SSID 建立 Wi-Fi 設定檔，設定 WPA2 企業級和 EAP-TLS。選擇 SCEP 設定檔進行用戶端驗證，並選擇根憑證授權單位進行伺服器驗證。部署到「Property Staff Devices」。
- 設定 HPE Aruba RADIUS 設定以指向 Windows NPS。在 NPS 上，設定一項要求 EAP-TLS 的網路原則，並為員工裝置指派 VLAN 10。
- 裝置收到設定檔並成功連線後，在舊的 SSID 上輪替 PSK，並排定停用時間。
一家擁有 50 個據點的零售連鎖店希望在所有據點為公司筆記型電腦部署 802.1X。他們使用 Cisco Meraki 存取點和 Microsoft Intune。他們不想在各個據點或其資料中心部署和維護地端的 NDES 伺服器或 AD CS 基礎架構。
- 實作雲端 PKI 與 SCEP 閘道服務，並透過 SCEP 協定與 Intune 整合。雲端 CA 發行憑證；雲端 SCEP 閘道處理 CSR 驗證。
- 在 Cisco Meraki 管理控制台的「無線 > 存取控制」下，針對企業 SSID 設定由 PKI 廠商提供的雲端 RADIUS 服務。將安全設定為 WPA2-Enterprise，並將 RADIUS 指向該雲端服務。
- 在 Intune 中，建立一個包含雲端 CA 根憑證的「受信任的根憑證」設定檔。部署至「Corporate Laptops」裝置群組。
- 建立一個指向雲端 SCEP 閘道 URL 的 SCEP 憑證設定檔。將主體名稱設定為 CN={{UserPrincipalName}} 以進行使用者型驗證。部署至「Corporate Laptops」。
- 針對具有 EAP-TLS 的企業 SSID 建立 Wi-Fi 設定檔，並參照 SCEP 設定檔與雲端 CA 根憑證。部署至「Corporate Laptops」。
- 當筆記型電腦註冊到 Intune 時，它們會自動透過雲端 SCEP 閘道向雲端 CA 要求憑證。這 50 個據點均不需要任何內部部署基礎架構。
練習題
Q1. 您的組織正在從 PEAP-MSCHAPv2 轉移到 EAP-TLS。您已成功將「受信任的根憑證」和 SCEP 設定檔部署到 Intune 中的「企業使用者」Azure AD 群組。您將 WiFi 設定檔部署到「所有企業裝置」。使用者回報無法連線，且 WiFi 設定檔顯示為「不適用」。
提示：請檢查設定檔相依性與群組定位規則。Intune 會根據指派的群組來解析設定檔相依性。
查看標準答案
此問題是群組定位不匹配所致。WiFi 設定檔取決於 SCEP 設定檔，而 SCEP 設定檔定位於使用者群組 (「企業使用者」)。WiFi 設定檔則定位於裝置群組 (「所有企業裝置」)。Intune 無法跨群組類型解析相依性。修正方法是將所有這三個設定檔指派 - 「受信任的根憑證」、SCEP 和 WiFi - 變更為定位於同一個群組。根據您的驗證模型 (基於使用者或基於裝置) 決定要使用使用者群組還是裝置群組，並在所有這三個設定檔中一致地套用。
Q2. 安全稽核顯示，當員工離職且其 Microsoft Entra ID 帳戶被停用時，他們的企業智慧型手機在離職後仍可連線至員工 WiFi 網路長達一週。
提示：請考慮 RADIUS 伺服器在帳戶停用後如何判斷憑證是否仍然有效。傳達撤銷狀態的機制是什麼？
查看標準答案
RADIUS 伺服器未進行嚴格的憑證撤銷清單（CRL）檢查，或者 CRL 發佈頻率不夠高。當員工離職時，MDM 應取消註冊裝置，且 CA 應撤銷憑證。然而，如果 RADIUS 伺服器未在每次驗證嘗試時檢查 CRL - 或者 CRL 僅每週發佈一次 - 則被撤銷的憑證仍會繼續被接受。修正方法包含三個步驟：設定 RADIUS 伺服器在每次驗證時強制執行嚴格的 CRL 檢查；設定 CA 以較短的間隔（每天或更頻繁）發佈 CRL；並確保 MDM 設定為在裝置取消註冊時觸發憑證撤銷。
Q3. 您需要為無法執行 MDM 代理程式且無法顯示 Captive Portal 的無螢幕 IoT 裝置（智慧恆溫器、數位看板播放器）提供安全的 WiFi 存取。您能為這些裝置使用 SCEP 嗎？如果不行，推薦的替代方案是什麼？
提示：請考慮 SCEP 註冊的前置條件，以及對於無法進行 MDM 註冊或無法與瀏覽器互動的裝置有哪些替代方案。
查看標準答案
這些裝置無法使用 SCEP。SCEP 需要 MDM 代理程式來接收註冊 URL 和驗證密碼、產生金鑰組並安裝產生的憑證。無法執行 MDM 代理程式的無螢幕 IoT 裝置無法參與 SCEP 註冊流程。推薦的替代方案為：(1) MAC 驗證繞過（MAB）結合嚴格的 VLAN 隔離 - RADIUS 伺服器根據裝置的 MAC 位址允許其連線，並將其放入無法存取企業系統的隔離 IoT VLAN 中；(2) 如果裝置支援，EST（安全傳輸註冊，RFC 7030）可以向支援 HTTPS 但不支援 MDM 的裝置配置憑證；(3) 對於具有管理介面的裝置，部分廠商支援直接透過裝置韌體進行 SCEP 註冊，而無需 MDM 代理程式。在所有情況下，無論使用何種驗證方法，IoT 裝置都應隔離在專屬的 VLAN 上。
繼續閱讀本系列
深入理解 Cisco SUDI：安全網路存取控制中的硬體錨定身分驗證
本指南說明 Cisco SUDI 如何為企業網路基礎設施提供硬體錨定且具密碼編譯安全性的身分。了解如何以不可變的 802.1AR 憑證取代易遭偽造的 MAC 位址，以確保您場域的網路存取控制安全。
如何實施 SCEP 以實現自動化 WiFi 憑證登錄
本指南說明了如何在企業場域中實施 SCEP（簡單憑證註冊協定），以實現自動化 WiFi 憑證登錄。內容涵蓋完整的架構藍圖 - 從 PKI 設計、MDM 整合到強制性的三步驟部署順序 - 並向 IT 經理和網路架構師展示如何消除共用認證、自動化憑證生命週期管理，以及在大規模環境下滿足 PCI-DSS 和 GDPR 的要求。
深入理解 Cisco SUDI：網路存取控制中以硬體為基礎的裝置識別
本指南詳細介紹 Cisco SUDI 的技術架構，說明以硬體為錨點的身份識別如何保障網路存取控制的安全。它為 IT 主管提供了具體的實作步驟，以便在企業場域中部署 802.1X EAP-TLS 驗證並自動化零接觸部署 (Zero Touch Provisioning)。