跳至主要內容

從地端 RADIUS (NPS) 遷移至 RADIUS-as-a-Service

這份權威指南詳細介紹了從地端 Microsoft Network Policy Server (NPS) 遷移至雲端原生 RADIUS-as-a-Service 模型的技術架構、實作方法和業務影響。它為 IT 主管和網路架構師提供了實用的框架,以減少營運開銷、消除單一故障點,並在分散的場所中維護企業驗證的安全。

📖 5 分鐘閱讀📝 1,066 字數🔧 2 範例3 練習題📚 8 關鍵定義

收聽此指南

查看播客逐字稿
PODCAST SCRIPT: Migrating from On-Premises RADIUS (NPS) to RADIUS as a Service Duration: ~10 minutes | Voice: UK English, Male, Senior Consultant tone --- SEGMENT 1: INTRODUCTION AND CONTEXT 歡迎收聽 Purple WiFi 技術簡報系列。今天我們要探討的是一個目前正列在許多企業 IT 團隊規劃藍圖上的轉移專案:從地端 RADIUS (特別是 Microsoft 的 Network Policy Server) 移轉到雲端託管的 RADIUS-as-a-Service 模式。 如果您正在管理飯店集團、零售物業、體育場館或公共部門園區的 WiFi 驗證,這與您直接相關。地端 NPS 模式在過去近二十年中為我們提供了良好的服務,但其維運開銷、單一故障點風險以及擴充限制正變得越來越難以合理化 - 尤其是現在雲端原生替代方案能以極低的總擁有成本提供企業級的可靠性。 在接下來的十分鐘內,我們將涵蓋這兩種架構的技術架構、逐步介紹結構化的移轉方法、探討兩個實際的部署情境,並以協助您充滿信心做出決策的關鍵決策框架來結束這段簡報。 讓我們開始吧。 --- SEGMENT 2: TECHNICAL DEEP-DIVE 首先,讓我們確保我們對 RADIUS 在您的網路堆疊中實際扮演的角色有一致的認知。RADIUS (遠端驗證撥入使用者服務) 是 RFC 2865 中定義的協定,用於處理網路存取的驗證、授權與計費。在 WiFi 情境中,它是 IEEE 802.1X 埠型存取控制的主幹。當裝置連線到 WPA2-Enterprise 或 WPA3-Enterprise SSID 時,無線基地台會充當 RADIUS 用戶端 (也就是我們所說的網路存取伺服器),並將驗證請求轉發給 RADIUS 伺服器。伺服器通常會針對 Active Directory 或 LDAP 目錄驗證憑證,並傳回 Access-Accept 或 Access-Reject 回應。這就是基本的流程。 現在,在地端 NPS 模式中 - Network Policy Server 是隨 Windows Server 綑綁銷售的 Microsoft RADIUS 實作 - 您是在您擁有的硬體上、在您維護的資料中心或伺服器主機房中執行該驗證邏輯。NPS 伺服器保存著您的網路原則、用於 EAP-TLS 或 PEAP-MSCHAPv2 的憑證基礎架構,以及您的連線請求原則。它確實可行。它很成熟。但它伴隨而來的是一系列隨著時間推移而累積的維運現實。 第一個是硬體依賴。您的 NPS 伺服器是實體或虛擬機器,需要修補、容量規劃以及最終的硬體汰換。在多站點部署中 - 例如在英國各地擁有物業的飯店集團 - 您要麼執行具有 WAN 依賴性的集中式 NPS,要麼在每個站點部署 NPS 執行個體並單獨管理它們。這兩種方式都不夠優雅。 第二是可用性。單一 NPS 執行個體是您整個驗證基礎架構的單一失敗點。是的,您可以將 NPS 部署為容錯移轉配對,但這會使您的硬體和授權開銷加倍,而且它仍然無法提供雲端服務原生提供的地理備援。 第三是擴充性。NPS 是專為企業區域網路(LAN)環境所設計的。當您在體育場活動或會議中心高峰期間處理數千個並行驗證請求時,單一 NPS 執行個體的吞吐量限制會變得非常明顯。驗證延遲激增,且使用者恰好在您最無法承受的時刻遇到連線失敗。 RADIUS-as-a-Service 從架構上解決了這所有三個限制。雲端 RADIUS 提供商運作一個分散式、地理備援的 RADIUS 伺服器叢集。您的存取點指向雲端託管的 RADIUS 端點,而不是內部部署伺服器。驗證請求在整個叢集之間進行負載平衡,且容錯移轉是自動且透明的。提供商負責處理修補程式、容量擴充和憑證管理。從您作為網路營運商的角度來看,RADIUS 變成了使用的服務,而不是管理的元件。 驗證協定本身並不會改變。您仍然執行 802.1X 以及 EAP-TLS、PEAP-MSCHAPv2 或 EAP-TTLS,具體取決於您的用戶端裝置組合。區別在於 RADIUS 伺服器的位置以及誰負責其營運持續性。 這裡有一個重要的安全性考量我想直接說明,因為這幾乎在每次與客戶的對話中都會被提起。將 RADIUS 搬移到雲端意味著您的驗證流量正在透過公共網際網路傳輸以到達雲端 RADIUS 端點。這可以透過兩種機制來緩解。第一,網路存取伺服器與 RADIUS 伺服器之間的 RADIUS 流量使用共用密鑰與基於 MD5 的訊息驗證進行保護。第二,對現代部署更重要的是,您應該執行 RadSec - 基於 TLS 的 RADIUS,定義於 RFC 6614 - 它將整個 RADIUS 對話封裝在 TLS 隧道中。這為您提供了相當於 HTTPS 的傳輸層加密,消除了 MD5 漏洞,並在 NAS 與 RADIUS 伺服器之間提供相互驗證。任何值得考慮的雲端 RADIUS 提供商都應該將支援 RadSec 作為標準配置。 在識別身分整合方面,雲端 RADIUS 服務通常支援連回您內部部署 Active Directory 的 LDAP 和 LDAPS 連線,或者透過 SAML 或 SCIM 與 Azure Active Directory 和 Microsoft Entra ID 進行原生整合。這意味著您不需要遷移您的使用者目錄 - 雲端 RADIUS 服務會查詢您現有的識別身分儲存庫,維持您現有的使用者生命週期管理程序。 對於注重合規性的組織 - 這包括任何根據 PCI-DSS 處理付款卡資料,或根據 GDPR 處理個人資料的組織 - 獲得 SOC 2 Type II 認證和 ISO 27001 認證的雲端 RADIUS 提供商,比大多數組織透過自行管理的 NPS 基礎架構所能實現的合規性姿態更為強大。 --- 區段 3:實作建議與常見陷阱 好的,讓我們來談談如何在不讓驗證基礎架構離線的情況下,實際執行此移轉。 我推薦的方法是五階段法。第一階段是審計與盤點。記錄每個 RADIUS 用戶端 - 每個存取點、每個交換器、每個 VPN 集中器 - 以及其目前的共用金鑰、其使用的 EAP 方法,以及 NPS 策略中任何特定廠商的屬性。這是吃力不討好的工作,但跳過它卻是移轉失敗的首要原因。 第二階段是試點部署。建立您的雲端 RADIUS 執行個體,並將非生產環境的 SSID 或單一測試站點指向它。驗證您的 EAP 方法是否可以端到端正常運作、身分識別整合是否正常執行,以及您的計費資料是否正確流動。 第三階段是平行運行。這是關鍵的風險緩釋步驟。將您的存取點配置為同時將內部部署的 NPS 伺服器和雲端 RADIUS 伺服器作為驗證目標,並以雲端服務為主,NPS 為備份。在整個業務週期內以這種配置運行至少兩週。監控驗證成功率、延遲和任何策略差異。 第四階段是轉換。移除 NPS 備份配置,並將雲端 RADIUS 作為您唯一的驗證基礎架構。在計劃的維護視窗期間執行此操作,並記錄且測試復原程序。 第五階段是淘汰。在轉換後確認穩定運行三十天後,淘汰 NPS 伺服器並收回硬體或虛擬機資源。 我最常看到的陷阱包括:憑證信任鏈問題 - 具體來說,是用戶端裝置不信任雲端 RADIUS 伺服器的憑證,因為 CA 不在其信任的儲存庫中。在轉換之前,請透過您的 MDM 或群組原則解決此問題。第二個常見的陷阱是防火牆規則。雲端 RADIUS 需要從您的存取點到雲端端點的輸出 UDP 1812 和 1813,或者為 RadSec 開放 TCP 2083。請確保您的網路周界允許此流量。第三:共用金鑰的複雜性。如果您現有的 NPS 共用金鑰強度不足,請利用這次移轉的機會輪替為具有加密強度的金鑰,或者更好的是,轉向使用 RadSec 並完全消除共用金鑰。 --- 區段 4:快速問答 讓我解答一下我最常收到關於這個主題的問題。 我們能保留內部部署的 Active Directory 嗎?是的,當然可以。雲端 RADIUS 透過 LDAPS 連接到您的內部部署 AD。您的目錄仍然保留在原處。 如果我們的網路連線中斷了會怎樣?這是關鍵的依賴關係轉移。採用雲端 RADIUS,網路連線能力會成為驗證的依賴條件。您可以透過備援 WAN 連結或在斷線期間為已知裝置快取驗證資訊的本地 RADIUS Proxy 來減輕此問題。 這會影響我們的 PCI-DSS 合規性嗎?遷移到經認證的雲端 RADIUS 提供商通常會改善您的合規狀況。請確保您的提供商能提供 SOC 2 Type II 報告,並將其納入您的年度 QSA 評估範圍中。 完整遷移需要多長時間?對於單一場域,需要二到四週。對於擁有五十個或更多位置的多場域資產,請規劃三到六個月並進行分階段部署。 - - 第 5 區段:總結與後續步驟 總結來說:從地端 NPS 遷移到 RADIUS-as-a-Service 的理由在營運、財務和合規性方面都非常令人信服。在以結構化的平行運作階段執行時,遷移本身的風險很低。關鍵的技術決策是您的 EAP 方法選擇、您的身分識別整合方法,以及是否實作 RadSec 來加強傳輸安全 - 我強烈建議對任何新部署採用此方法。 您眼前的後續步驟:對您目前的 RADIUS 用戶端和原則進行稽核、與您的雲端 RADIUS 提供商聯繫以建立試用環境,並在開始之前審查您的防火牆規則和憑證信任鏈。 對於執行 Purple WiFi 訪客存取平台的組織,RADIUS-as-a-Service 功能可直接與訪客 WiFi 驗證流程整合,為您提供適用於企業 802.1X 驗證和訪客網路存取管理的單一控制介面 - 並內建分析和合規性報告。 感謝您的聆聽。完整的技術參考指南可在 Purple 網站上取得,如果您準備好繼續前進,我們的解決方案團隊可隨時與您進行範疇評估對話。 - - 指令碼結束

header_image.png

執行摘要

近二十年來,Microsoft 的 Network Policy Server (NPS) 一直是企業網路預設的 RADIUS 實作方案。然而,隨著場域營運商在分散的地點(從零售連鎖店到全球餐旅集團)進行擴展,管理地端身分驗證基礎架構的營運負擔已成為重大隱憂。

遷移到 RADIUS-as-a-Service 可將身分驗證從託管的硬體元件轉變為訂閱制的雲端服務。這種架構轉變消除了獨立 NPS 部署固有的單點故障,免除了硬體汰換週期,並提供了體育場和會議中心等高密度環境彈性擴展所需的能力。對於 IT 經理和網路架構師,本指南提供了一套中立於供應商、結構化的方法論,用於將 802.1X 身分驗證遷移到雲端,且不影響生產環境流量,同時確保符合 PCI-DSS 和 GDPR,並可減少高達 80% 的身分驗證基礎架構營運成本(OpEx)。

技術深入剖析:架構與標準

要了解此遷移,我們必須首先檢視 IEEE 802.1X 基於連接埠之存取控制在交付方式上的架構轉變。

地端 NPS 的限制

在傳統部署中,存取點充當網路存取伺服器(NAS),將身分驗證請求轉發到地端 NPS 伺服器。NPS 伺服器評估連線請求原則,比對身分儲存庫(通常是透過 LDAP 進行 Active Directory 驗證)驗證憑證,並傳回 Access-Accept 或 Access-Reject 訊息。

此模式對現代網路帶來三個關鍵限制:

  1. 硬體依賴與維護:NPS 需要專用的實體或虛擬機器,需要持續的修補程式更新、容量規劃和生命週期管理。
  2. 高可用性的複雜性:實現備援需要部署容錯移轉對的 NPS,這會使授權成本加倍,卻無法提供真正的地理備援。
  3. 吞吐量瓶頸:在高峰並行期間(例如體育場入場或零售業尖峰營業時間),單一 NPS 執行個體可能會成為瓶頸,導致身分驗證逾時和使用者體驗下降。

Cloud RADIUS 架構

RADIUS-as-a-Service 將身分驗證層抽象化。雲端供應商營運分散式、具備地理備援的 RADIUS 伺服器叢集。NAS 指向這些雲端端點,且請求會自動進行負載平衡。

architecture_comparison.png

傳輸安全:RadSec 的角色 當 RADIUS 移至雲端時,驗證流量會穿越公開網際網路。雖然傳統的 RADIUS 依賴共享金鑰和 MD5 雜湊,但現代部署必須實置 RadSec(RADIUS over TLS, RFC 6614)。RadSec 將整個 RADIUS 對話封裝在 TLS 通道(通常為 TCP 伺服器埠 2083)中,提供相當於 HTTPS 的傳輸層加密,並在 NAS 與雲端 RADIUS 端點之間進行雙向驗證。

身分識別整合 雲端 RADIUS 不需要您移轉使用者目錄。服務通常支援連回內部部署 Active Directory 的 LDAPS 連線,或是透過 SAML 或 SCIM 與 Azure Active Directory (Entra ID) 進行原生 API 整合。這可確保您現有的使用者生命週期管理程序保持不變。

對於使用 Guest WiFi 平台的場所,雲端 RADIUS 可以直接整合,為企業 802.1X 驗證和訪客網路存取提供統一的控制面板,並配有先進的 WiFi Analytics

實置指南:5 階段方法論

在不中斷服務的情況下執行移轉需要結構化、分階段的方法。

migration_checklist.png

第 1 階段:稽核與盤點

在進行任何變更之前,請記錄目前狀態:

  • RADIUS 用戶端:識別每個 NAS(無線存取點、交換器、VPN 集中器)。
  • 原則:記錄現有的 NPS 連線要求和網路原則,包括用於 VLAN 指派的廠商專屬屬性 (VSA)。
  • EAP 方法:識別正在使用哪些可延伸驗證協定方法(例如 EAP-TLS、PEAP-MSCHAPv2)。

第 2 階段:試行部署

佈建雲端 RADIUS 執行個體並設定非生產用的 SSID 或單一測試站台。驗證身分目錄整合(例如 Entra ID 同步),並確認 EAP 方法端到端正常運作。

第 3 階段:平行運作(風險緩釋)

將生產環境的 NAS 裝置設定為同時使用雲端 RADIUS 伺服器(主要)和舊型 NPS 伺服器(備用)。維持此設定至少兩週。監控驗證成功率、延遲指標和會計資料流,以在轉換前識別任何原則差異。

第 4 階段:轉換

在排定的維護時段內,從 NAS 裝置中移除舊型的 NPS 備用設定。完全過渡到雲端基礎架構。確保您的復原程序已記錄並經過測試。

第 5 階段:除役

穩定運作 30 天後,安全地將舊型 NPS 伺服器除役,並回收運算資源。

最佳實踐與合規性

在設計您的雲端 RADIUS 架構時,請遵循以下標準:

  • 強制執行 RadSec:如果您的 NAS 硬體支援 RadSec (TCP 2083),切勿使用標準 UDP 1812/1813 透過公用網際網路傳送 RADIUS 流量。
  • 憑證信任鏈:確保用戶端裝置信任核發雲端 RADIUS 伺服器憑證的憑證授權單位 (CA)。在移轉前,透過 MDM 或群組原則將根 CA 推送到受管理的裝置。
  • 合規性狀態:選擇維持 SOC 2 Type II 證明和 ISO 27001 認證的雲端 RADIUS 供應商。這可大幅簡化您的年度 PCI-DSS 評估,特別是對於 零售餐旅 環境。

如需更廣泛的網路設計原則,請參閱我們的指南: 為企業設定 WiFi:2026 年指南 以及 了解 RSSI 與訊號強度以實現最佳頻道規劃

疑難排解與風險緩釋

故障模式 根本原因 緩釋策略
驗證逾時 防火牆封鎖輸出 UDP 1812/1813 或 TCP 2083。 驗證周邊防火牆規則,允許輸出流量傳送到雲端 RADIUS 供應商的特定 IP 範圍。
憑證信任錯誤 用戶端裝置的信任存放區中缺少根 CA。 在第 3 階段 (平行運作) 之前,透過 MDM/GPO 部署根 CA。
VLAN 指派失敗 廠商特定屬性 (VSA) 未在雲端原則中正確對應。 在第 1 階段期間,將 NPS 中完全相同的 VSA 字串格式複製到雲端 RADIUS 原則引擎中。
WAN 中斷影響 網際網路連線中斷導致無法存取雲端 RADIUS。 部署備援 WAN 連結,或實作可在本機快取已識別裝置認證的本機 RADIUS 代理伺服器。

投資報酬率與商業影響

移轉到 RADIUS-as-a-Service 可帶來顯著的業務成效:

  • 降低成本:免除硬體採購、Windows Server 授權,以及用於修補和維護的工程工時。一般的營運費用 (OpEx) 可降低 60-80%。
  • 可靠性 SLA:與單一站點 NPS 部署通常只有 97-98% 的可用性相比,雲端供應商提供有財務保障的 99.99% 可用性 SLA。
  • 敏捷性:無需佈署本機驗證硬體,即可立即讓新站點上線,縮短 交通運輸 樞紐和 醫療保健 機構的部署時程。

請聆聽我們的資深顧問團隊在 10 分鐘的簡報中討論策略性影響:

關鍵定義

RADIUS (Remote Authentication Dial-In User Service)

一種網路協定,為連接和使用網路服務的使用者提供集中式的驗證、授權和計費 (AAA) 管理。

企業 WiFi 網路在授予網路存取權限之前用於驗證使用者憑證的核心協定。

NPS (Network Policy Server)

Microsoft 對 RADIUS 伺服器和代理程式的實作,作為 Windows Server 中的一個角色隨附。

組織正積極遷出的舊型地端基礎架構,以減少維護開銷。

NAS (Network Access Server)

作為網路閘道並將驗證請求傳遞給 RADIUS 伺服器的裝置。

在無線環境中,NAS 通常是指 WiFi 基地台或無線區域網路控制器。

RadSec (RADIUS over TLS)

RFC 6614 中定義的一種協定,透過使用 TLS 加密的 TCP 連線傳輸 RADIUS 封包。

這對於雲端 RADIUS 部署至關重要,可確保憑證資料在通過公共網際網路時被加密。

EAP (Extensible Authentication Protocol)

一種常用於無線網路和點對點連線的驗證框架。

決定用戶端和伺服器如何安全地交換憑證(例如,透過 EAP-TLS 的憑證,或透過 PEAP 的密碼)。

VSA (Vendor-Specific Attribute)

硬體廠商在 RADIUS 協定中定義的自訂屬性,以支援專有功能。

在遷移過程中至關重要;VSA 通常用於將已驗證的使用者動態分配給特定的網路 VLAN。

LDAPS (Lightweight Directory Access Protocol over SSL)

一種用於查詢和修改目錄服務(如 Active Directory)的安全通訊協定。

雲端 RADIUS 服務使用此通訊協定安全地查詢地端身分識別儲存庫,而無需將使用者目錄遷移至雲端。

802.1X

一種用於基於連接埠之網路存取控制(PNAC)的 IEEE 標準。

使用 RADIUS 確保只有通過驗證的裝置才能將流量傳輸到企業 LAN 或 WLAN 的底層標準。

範例

一家擁有 200 家物業的酒店集團目前在每個站點運行本地 NPS 伺服器,用於員工的 802.1X 驗證。他們正在遷移到 Microsoft Entra ID 並且希望淘汰本地伺服器。他們應該如何進行遷移?

  1. 部署一個雲端 RADIUS 服務,該服務透過 SAML/SCIM 與 Microsoft Entra ID 進行原生整合。
  2. 設定雲端 RADIUS 原則,將 Microsoft Entra ID 群組(例如「前台」、「管理層」)對應到特定的 VLAN VSA。
  3. 在試點物業中,設定基地台使用 RadSec 連接到雲端 RADIUS 端點。
  4. 透過 Microsoft Intune 將雲端 RADIUS 伺服器的根 CA 推送到所有員工裝置。
  5. 在試點站點運行並行驗證,然後在剩餘的 199 家物業中分階段推出。
考官評語: 此方法從資產中移除了 200 台實體或虛擬伺服器,大幅減少了攻擊面和維護開銷。直接與 Microsoft Entra ID 整合消除了建立回到中央 Active Directory 的複雜站點對站點 VPN 的需求。

一個容納 50,000 人的體育場在重大活動期間,其企業 SSID 發生驗證失敗,因為其地端 NPS 伺服器無法處理數千台裝置同時漫遊的吞吐量。

  1. 審計現有的 NPS 原則和 EAP 方法。
  2. 佈署一個雲端 RADIUS 服務,該服務能夠自動調整大小以處理每秒高驗證量 (APS)。
  3. 建立從雲端 RADIUS 服務到體育場地端 Active Directory 的 LDAPS 連線。
  4. 更新體育場的高密度無線區域網路控制器,將其指向雲端 RADIUS 端點作為主要驗證伺服器。
考官評語: 透過將 RADIUS 處理卸載到雲端叢集,體育場可以利用彈性運算資源,在活動入場期間動態擴充,從而解決瓶頸,而無需場所超額配置昂貴的本地硬體。

練習題

Q1. 貴組織正在遷移至 Cloud RADIUS。安全性團隊強制規定,不得透過網際網路以明文或使用已棄用的雜湊演算法(如 MD5)傳送任何驗證流量。您必須在無線 LAN 控制器上設定什麼協定?

提示:尋找在 TLS 通道中封裝 RADIUS 的通訊協定。

查看標準答案

您必須設定 RadSec(RADIUS over TLS)。RadSec 在 NAS 與雲端 RADIUS 伺服器之間的 TCP 連接埠 2083 上建立 TLS 通道,提供傳輸層加密和雙向驗證,滿足安全性團隊的要求。

Q2. 在遷移的第 3 階段(平行運作)期間,您注意到使用者成功對雲端 RADIUS 伺服器進行驗證,但未被放置在正確的網路區段中。最可能的設定缺失是什麼?

提示:RADIUS 伺服器如何告訴存取點要使用哪個網路區段?

查看標準答案

雲端 RADIUS 原則中尚未正確設定用於動態 VLAN 指派的廠商專屬屬性(VSA)。您必須確保舊版 NPS 伺服器中使用的確切 VSA 字串已在雲端環境中複製,以便 NAS 知道要為使用者指派哪個 VLAN。

Q3. 用戶端裝置對新的雲端 RADIUS 服務重複發生 EAP-TLS 驗證失敗,但對舊版 NPS 伺服器運作正常。裝置記錄顯示「不受信任的伺服器」錯誤。您該如何解決此問題?

提示:EAP-TLS 要求用戶端信任伺服器的身分。

查看標準答案

用戶端裝置的受信任根憑證授權單位存放區中,沒有簽發雲端 RADIUS 伺服器憑證的根憑證授權單位(CA)。您必須使用行動裝置管理(MDM)解決方案或群組原則將根 CA 部署到用戶端裝置。