雲端 RADIUS 與地端 RADIUS：IT 團隊決策指南
本指南為 IT 主管、網路架構師和場地營運團隊提供了一個明確的框架，協助在雲端託管 RADIUS 服務與傳統地端 RADIUS 伺服器之間做出選擇。內容涵蓋了多站點飯店業、零售業和公部門部署的技術架構、延遲與可靠性權衡、總擁有成本以及合規考量。閱讀完畢後，讀者將獲得一個與其特定基礎設施限制和組織風險偏好一致的清晰決策模型。
Listen to this guide
View podcast transcript
執行摘要
RADIUS 驗證位於每個企業 WiFi 部署的核心。無論您是透過 IEEE 802.1X 保護員工存取，還是管理跨多個場地的訪客上線，託管 RADIUS 基礎設施的位置決策，將直接影響正常運行時間、營運負擔和總擁有成本。
雲端 RADIUS 服務提供管理式、全球分散式驗證基礎設施，內建高可用性、自動憑證輪替和彈性擴展能力，消除了困擾分散式地端部署的逐站點維護負擔。地端 RADIUS，無論執行 FreeRADIUS 或 Microsoft NPS，均可提供亞毫秒級的本機驗證、完整的資料主權以及獨立於 WAN 連線之外的優勢，這些優勢在特定的高密度或受監管環境中仍具有決定性。
對大多數多站點營運商而言——酒店集團、零售連鎖、會議中心——雲端 RADIUS 能夠以較低的五年總擁有成本提供優異的營運成效。例外情況已明確定義：氣隙隔離環境、嚴格的資料駐留法規，以及本機 LAN 效能至關重要的超大型單一站點部署。本指南提供框架，協助您判斷部署屬於何種類別，以及如何依該決策行動。
技術深入探討
RADIUS 協定及其在 802.1X 基礎設施中的角色
RADIUS（遠端驗證撥入使用者服務，RFC 2865）作為網路存取層與身分目錄之間的驗證中介。在 802.1X 部署中，存取點或交換器扮演網路存取伺服器 (NAS) 的角色，透過 UDP（驗證使用連接埠 1812，記帳使用連接埠 1813）將 EAP 驗證框架轉發至 RADIUS 伺服器。RADIUS 伺服器根據後端目錄（Active Directory、LDAP 或雲端身分提供者）驗證請求者的憑證，並回傳 Access-Accept 或 Access-Reject 回應，可選擇包含 VLAN 指定屬性。
無論您的 RADIUS 伺服器是伺服器機房中的機架式設備，還是全球分散式雲端服務，此架構在根本上並無不同。差異在於該伺服器所在位置、由誰維護，以及如何擴展。
地端 RADIUS：架構與權衡取捨
兩大主流地端 RADIUS 平台為 FreeRADIUS 與 Microsoft Network Policy Server (NPS)。FreeRADIUS 是全球部署最廣泛的 RADIUS 伺服器，支援廣泛的 EAP 方法，包括 EAP-TLS、PEAP-MSCHAPv2、EAP-TTLS 和 EAP-PWD。它可透過 LDAP、SQL 或 REST 幾乎整合任何後端目錄，且免授權費。然而，它需要熟練的管理：組態基於檔案，除錯需要日誌分析專業知識，跨數十個站點擴展則需要仔細的複寫和容錯移轉規劃。
Microsoft NPS 原生整合 Active Directory，是 Windows 中心化環境的預設選擇。它開箱即支援 PEAP-MSCHAPv2 和 EAP-TLS，並透過熟悉的 Windows Server 介面管理。其取捨是與 Windows Server 授權緊密耦合，且相較於 FreeRADIUS，EAP 方法集較為有限。
對於高可用性地端部署，組織通常會部署主動-主動或主動-被動 RADIUS 叢集。存取點設定主要和次要 RADIUS 伺服器位址；如果主要伺服器在設定的逾時時間（通常 3-5 秒）內未回應，NAS 便會容錯移轉至次要伺服器。此架構需要地理分散的伺服器——這本身會引入複雜性——或者在同一設施中的一對伺服器，卻無法防範站點層級的停機。
延遲概況：地端 RADIUS 可透過本機 LAN 提供低於 1 毫秒的驗證往返時間。對於處理數千個同時驗證的高密度環境——例如滿場活動中的 68,000 座位體育場——此本機處理能力確實是一項營運優勢。
雲端 RADIUS：架構與權衡取捨
雲端 RADIUS 平台將 RADIUS 基礎設施託管在多個地理分散的可用性區域中。當存取點發送驗證請求時，會被路由至最近的雲端邊緣節點，通常根據提供者的接取點與站點之鄰近程度，增加 5–50 毫秒的往返延遲。對大多數驗證使用案例而言，此延遲對終端使用者是難以察覺的。
高可用性模型與地端根本不同。雲端平台的負載平衡器會自動將請求從故障節點導開，而非設定主要/次要配對。企業雲端 RADIUS 提供者通常發布 99.99% 正常運行時間的 SLA，由多區域冗餘提供支援。要在地端實現同等的冗餘，需要跨多個地理分散的資料中心部署主動-主動叢集——這是一項重大的工程和資本投資。
雲端 RADIUS 平台原生整合雲端身分提供者。如果您的組織使用 Okta、Azure Active Directory 或 Google Workspace，雲端 RADIUS 服務可透過 SAML、LDAP-over-TLS 或專屬 API 連接器進行連接。有關 Okta 整合的詳細逐步說明，請參閱我們的指南： Okta 與 RADIUS：將您的身分提供者延伸至 WiFi 驗證 。
憑證管理是採用雲端 RADIUS 最有力的營運論據之一。EAP-TLS 和 PEAP 都依賴伺服器端的數位憑證。在地端，憑證到期是驗證中斷的主要原因——FreeRADIUS 伺服器上的憑證一旦到期，會導致所有連線用戶端拒絕伺服器的身分，造成全面的 WiFi 中斷，直到憑證更新並部署為止。雲端 RADIUS 提供者完全自動化憑證輪替，消除了此故障模式。
WPA3-Enterprise 與協定考量
Wi-Fi 聯盟的 WPA3-Enterprise 規格引入了 192 位元安全模式，強制要求使用 Suite B 密碼學（ECDHE、ECDSA、AES-256-GCM）的 EAP-TLS。這對於醫療保健、金融和政府部署日益重要。多數現代雲端 RADIUS 平台原生支援 WPA3-Enterprise。執行較舊 FreeRADIUS 版本（3.0.x 前）或舊版 NPS 組態的地端部署，可能需要升級才能部署 WPA3-Enterprise。若 WPA3-Enterprise 在您的規劃中，請在決定基礎設施路徑前，驗證您的 RADIUS 平台支援情況。
對於考慮支撐多站點雲端 RADIUS 部署的 SD-WAN 層之組織，我們關於 現代企業的核心 SD-WAN 優勢 的指南，提供了關於 WAN 韌性架構的補充脈絡。
實作指南
步驟 1：稽核您目前的驗證相依性
在選擇部署模型前，記錄您目前驗證基礎設施所涉及的所有 SSID、VLAN、EAP 方法和後端目錄。包含無頭裝置（印表機、IoT 感測器、銷售點終端機）的 MAC 驗證繞過 (MAB) 政策，因為這些在遷移過程中經常被忽略，且可能導致嚴重的切換後事件。
步驟 2：評估身分提供者準備度
若您的使用者目錄是地端 Active Directory，且無法同步至雲端 IdP，則您的雲端 RADIUS 選項將受限於支援 LDAP 代理至地端目錄的平台。若您可以部署 Azure AD Connect 或類似的同步工具，則整個雲端 RADIUS 平台範圍皆可使用。單一決策——雲端 IdP 與地端目錄——往往是雲端與地端 RADIUS 選擇的決定性因素。
步驟 3：評估每個站點的 WAN 韌性
雲端 RADIUS 的可靠性僅與每個站點的網際網路連線相當。在遷移之前，稽核每個地點的 WAN 連線。僅有單一 ISP 連線且無容錯移轉的站點，是重大風險。在部署雲端 RADIUS 作為主要驗證基礎設施前，請實作雙 ISP 連線或 SD-WAN 容錯移轉。對於銷售點系統依賴網路驗證的 零售 環境，WAN 韌性是不可妥協的。
步驟 4：規劃憑證遷移（地端部署）
若部署或維護採用 EAP-TLS 的地端 RADIUS，請建立憑證生命週期管理流程。在憑證到期前 90、60 和 30 天設定監控警示。考慮部署內部 PKI（如 Microsoft ADCS 或 HashiCorp Vault）以自動化憑證發放與續約。在生產環境中，切勿僅依賴行事曆提醒進行憑證管理。
步驟 5：設定生存性政策
對於雲端 RADIUS 部署，在無線控制器或存取點上設定本機生存性政策。選項包括：在一段可設定時間內快取上次已知的驗證狀態、退回至預先核准裝置清單的 MAC 驗證繞過，或透過次要驗證路徑路由關鍵員工 SSID。對於 飯店業 營運商，確保透過 Purple 的 Guest WiFi 等平台進行的訪客 WiFi 上線，在 RADIUS 不可用時具有定義的備援行為。
步驟 6：執行平行部署
將新的 RADIUS 平台與現有基礎設施平行部署。建立一個對應至新 RADIUS 伺服器的專用測試 SSID，並驗證所有 EAP 方法、VLAN 指定和政策執行，再遷移生產 SSID。此平行運作期間，單一站點部署至少應為兩週，多站點遷移則為四至六週。
步驟 7：執行分階段逐站點遷移
對於多站點部署，請依序遷移站點，而非同時。從風險較低的站點開始——流量較少且使用者容忍度較高的小型據點——再遷移旗艦店或會議密集型飯店物業等高優先級站點。在開始切換前，為每個站點記錄回滾程序。
最佳實務
共用密鑰衛生：存取點與 RADIUS 伺服器之間的 RADIUS 共用密鑰，長度至少需 32 個字元，且需隨機產生，每台 NAS 裝置應為唯一。在所有存取點重複使用共用密鑰，意味著一旦一台裝置遭到入侵，便會暴露整個驗證基礎設施。應每年或於任何可疑入侵後輪換共用密鑰。
VLAN 區隔：使用 RADIUS 指定的 VLAN（透過 Tunnel-Type、Tunnel-Medium-Type 和 Tunnel-Private-Group-ID 屬性），根據使用者角色動態區隔流量。訪客裝置應落入僅有網際網路存取的隔離 VLAN；公司裝置則在生產 VLAN 上；IoT 裝置則在專用的受限 VLAN 上。對於任何處理持卡人資料的網路，此區隔是 PCI DSS 的要求。
計費與稽核記錄：啟用 RADIUS 記帳（連接埠 1813），並將記帳日誌保留至少 12 個月。這些日誌記錄了工作階段開始/停止時間、資料量和指定的 IP 位址——對於安全性事件調查和 GDPR 合規至關重要。雲端 RADIUS 平台通常會透過 syslog 或 API 將記帳資料匯出至 SIEM 系統；地端部署則應將記帳資料路由至集中式日誌管理平台。
EAP 方法選擇：對於企業員工網路，EAP-TLS（憑證式）提供最強的安全性態勢，建議用於 PCI DSS 和醫療保健環境。PEAP-MSCHAPv2 對風險較低的環境而言是可接受的，但若伺服器憑證未經請求者正確驗證，則容易遭受憑證收集攻擊。完全避免使用 EAP-MD5——此方法已遭棄用，且不提供相互驗證。
RadSec（TLS 上的 RADIUS）：傳統 RADIUS 協定透過 UDP 傳輸資料，僅對 User-Password 屬性進行加密。RadSec (RFC 6614) 將 RADIUS 封裝在 TLS 中，提供完整的傳輸加密和 NAS 與 RADIUS 伺服器之間的相互驗證。多數現代雲端 RADIUS 平台支援 RadSec。對新部署而言，RadSec 應為預設的傳輸選擇。
對於 醫療保健 和 運輸 領域的部署，其在 GDPR 和特定領域法規下的資料處理義務特別嚴格，請確保您的 RADIUS 平台提供資料處理協議，並支援區域資料駐留。
疑難排解與風險緩解
常見故障模式 1：憑證到期（地端）
症狀：所有用戶端突然無法驗證；RADIUS 日誌顯示 TLS 握手失敗。
根本原因：RADIUS 伺服器上的伺服器端憑證已到期。用戶端請求者拒絕伺服器的身分。
緩解措施：實作自動化憑證監控，在 90/60/30 天時設定警示。使用具有自動續約功能的內部 CA。雲端 RADIUS 透過自動化憑證輪替，完全消除了此故障模式。
常見故障模式 2：WAN 中斷阻擋雲端 RADIUS
症狀：特定站點驗證失敗；其他站點未受影響。本機網路正常運作。
根本原因：該站點的網際網路連線中斷，導致存取點無法連線至雲端 RADIUS 服務。
緩解措施：部署雙 ISP 連線或具備自動容錯移轉功能的 SD-WAN。設定存取點生存性政策，以快取憑證或對關鍵裝置退回至 MAB。
常見故障模式 3：共用密鑰不符
症狀：驗證請求被靜默丟棄；RADIUS 日誌顯示「無效的驗證器」或「訊息驗證器」錯誤。
根本原因：存取點上設定的共用密鑰與 RADIUS 伺服器上設定的密鑰不符。
緩解措施：使用集中式密鑰管理系統（HashiCorp Vault、AWS Secrets Manager）以確保一致性。在任何 NAS 或 RADIUS 伺服器組態變更後驗證共用密鑰。
常見故障模式 4：請求者設定錯誤
症狀：個別裝置驗證失敗，但相同 SSID 上的其他裝置成功。
根本原因：故障裝置上的 802.1X 請求者未設定為信任 RADIUS 伺服器的憑證，或設定為不相容的 EAP 方法。
緩解措施：透過 MDM 或群組原則部署請求者設定，以確保一致性。對 BYOD 環境，提供清楚的上線指南。Purple 的 WiFi Analytics 平台可協助識別整個裝置資產中的驗證失敗模式。
常見故障模式 5：負載下的 RADIUS 逾時
症狀：尖峰時段（活動開始、換班）的驗證延遲或失敗。
根本原因：RADIUS 伺服器被同時的驗證請求淹沒；在收到回應前，NAS 逾時已被超過。
緩解措施：地端：在已知尖峰事件前擴充 RADIUS 伺服器容量；在存取點上實作連線速率限制。雲端 RADIUS：驗證您的訂閱層級支援您的尖峰驗證輸送量；多數企業雲端平台會自動擴展。
ROI 與業務影響
總擁有成本：五年比較
以下分析基於一個具代表性的 20 站點零售連鎖，每個站點約有 50 個存取點，尖峰時段每個站點有 200 個同時驗證的裝置。
| 成本組成 | 地端 RADIUS（20 站點） | 雲端 RADIUS（20 站點） |
|---|---|---|
| 硬體（伺服器、HA 配對） | £80,000–£120,000 | £0 |
| OS 與軟體授權 | £10,000–£30,000 | £0 |
| 年訂閱費 | £0 | £18,000–£40,000/yr |
| 電力和冷卻（5 年） | £15,000–£25,000 | £0 |
| 工程時間（5 年） | £60,000–£100,000 | £10,000–£20,000 |
| 5 年總計 | £165,000–£275,000 | £100,000–£220,000 |
工程時間差異是最顯著的因素。20 個站點的地端 RADIUS 需要持續的修補、憑證管理、監控和事件回應。雲端 RADIUS 將此減少為政策管理和整合維護——僅需一小部分心力。
衡量成功
您的 RADIUS 部署關鍵績效指標應包括：驗證成功率（目標：生產環境 >99.5%）、平均驗證延遲（目標：雲端 <100ms，地端 LAN <5ms）、從驗證中斷的平均恢復時間（目標：<15 分鐘），以及憑證到期事件（目標：零，可透過適當的自動化實現）。
對於使用 Purple Guest WiFi 平台的 飯店業 營運商，驗證基礎設施的可靠性直接影響旅客滿意度分數。在尖峰入住期間，2 秒的驗證延遲便可在旅客反饋中察覺。具有正確設定生存性政策的雲端 RADIUS，在此指標上始終優於臨時性的地端部署。
從分散式地端 FreeRADIUS 部署遷移至雲端 RADIUS 的組織，一致回報與驗證相關的 IT 事件減少了 30%–50%，且分配給 RADIUS 維護的工程時數顯著下降——這些時數被重新分配至策略性網路改善專案。Purple 平台整合了兩種部署模型，提供 WiFi Analytics 和 Sensors 資料，可根據遷移前擷取的基準指標量化這些改善。
對於考慮更廣泛網路現代化脈絡的場地營運商，Purple 的 Wayfinding 功能，以及驗證資料與人流分析的整合，代表了設計良好的 RADIUS 基礎設施所實現的下一層價值。驗證事件本質上即為客流資料——當透過 Purple 的分析層浮現時，它們便成為理解整個場地訪客行為、停留時間和回訪率的強大工具。
Key Definitions
RADIUS（遠端驗證撥入使用者服務）
一種網路協定 (RFC 2865)，可為連線至網路的使用者提供集中式驗證、授權和計費 (AAA) 功能。RADIUS 透過 UDP 運作，並作為網路存取設備（存取點、交換器）與身分目錄（Active Directory、LDAP、雲端 IdP）之間的中介。
IT 團隊在為 WiFi 或有線網路部署 802.1X 驗證時，便會接觸到 RADIUS。它是企業網路存取控制的基礎協定，且為 WPA2-Enterprise 和 WPA3-Enterprise 部署所必需。
802.1X
一項 IEEE 標準，用於基於連接埠的網路存取控制，定義了基於 EAP 的驗證框架。在 WiFi 環境中，802.1X 需要三個元件：請求者（客戶端裝置）、驗證器（存取點）和驗證伺服器（RADIUS）。存取點會阻擋來自客戶端的所有流量，直到 RADIUS 回傳 Access-Accept 為止。
802.1X 是 WPA2-Enterprise 和 WPA3-Enterprise 網路的驗證機制。IT 團隊使用它來確保只有授權的裝置和使用者能連線至企業 WiFi，並根據使用者身分動態指定 VLAN。
EAP（可延伸驗證協定）
在 802.1X 中使用的靈活驗證框架，支援多種驗證方法。常見的 EAP 方法包括 EAP-TLS（基於憑證，安全性最強）、PEAP-MSCHAPv2（基於密碼並驗證伺服器憑證）和 EAP-TTLS（通道式密碼驗證）。
EAP 方法的選擇直接影響安全姿態和部署複雜性。EAP-TLS 要求每個裝置上有用戶端憑證，使其部署更複雜，但顯著更能抵抗憑證盜竊攻擊。受監管行業（醫療保健、金融）的 IT 團隊應預設採用 EAP-TLS。
FreeRADIUS
全球部署最廣泛的開源 RADIUS 伺服器，為全球數億使用者提供驗證支援。FreeRADIUS 支援廣泛的 EAP 方法和後端整合，無需授權費用，並在 Linux 上執行。它需要熟練的管理和基於檔案的組態。
FreeRADIUS 是非 Microsoft 環境中地端 RADIUS 部署的預設選擇。評估雲端與地端決策的 IT 團隊應評估是否具備有效運作 FreeRADIUS 的內部專業知識，因為設定錯誤是驗證事件的主因。
NPS（網路原則伺服器）
Microsoft 內建的 RADIUS 伺服器，隨附於 Windows Server。NPS 原生整合 Active Directory，並支援 PEAP-MSCHAPv2 和 EAP-TLS。它透過 Windows Server 圖形介面管理，是 Microsoft 中心化環境的預設 RADIUS 選擇。
執行 Windows Server 基礎設施的 IT 團隊通常會部署 NPS 作為其地端 RADIUS 伺服器。NPS 與 Windows Server 授權和 Active Directory 緊密耦合，這簡化了 Microsoft 環境中的部署，但限制了在異質或雲原生環境中的靈活性。
MAC 驗證繞過 (MAB)
一種驗證方法，使用裝置的 MAC 位址作為其憑證，讓無法執行 802.1X 請求者的無頭裝置（印表機、IoT 感測器、銷售點終端機）能驗證至網路。該 MAC 位址會與 RADIUS 伺服器上的允許清單進行比對。
MAB 對於任何具有 IoT 裝置或舊型設備的網路至關重要。IT 團隊必須維護準確的 MAC 位址清單，並實作新增裝置的流程。雲端 RADIUS 平台通常提供集中式儀表板，以便跨所有站點管理 MAB 清單，這比 FreeRADIUS 上逐站點的組態檔案管理要高效得多。
RadSec（TLS 上的 RADIUS）
RADIUS 協定的一項擴展 (RFC 6614)，透過 TLS 而非 UDP 傳輸 RADIUS 封包。RadSec 提供完整的傳輸加密以及 NAS 與 RADIUS 伺服器之間的相互驗證，解決了傳統基於 UDP 的 RADIUS 協定中多個眾所周知的安全漏洞。
傳統 RADIUS 僅加密 User-Password 屬性；所有其他屬性，包括使用者名稱和工作階段資料，均以明文傳輸。RadSec 是 RADIUS 的現代安全傳輸機制，多數企業雲端 RADIUS 平台和現代存取點供應商皆支援。部署新 RADIUS 基礎設施的 IT 團隊應將 RadSec 評估為預設傳輸方式。
VLAN 指定（RADIUS 指定的 VLAN）
一項 RADIUS 功能，可根據驗證結果，動態將連線裝置指定到特定的 VLAN。RADIUS 伺服器在 Access-Accept 回應中回傳 Tunnel-Type (13=VLAN)、Tunnel-Medium-Type (6=802) 和 Tunnel-Private-Group-ID (VLAN ID) 屬性，存取點則將裝置放入指定的 VLAN。
動態 VLAN 指定是 IT 團隊根據使用者身分實作網路區隔的機制。單一 SSID 可服務多種使用者類型——訪客、員工、承包商、IoT 裝置——每種類型會根據其 RADIUS 驗證結果自動放置到適當的 VLAN 中。對於處理持卡人資料的網路，這是 PCI DSS 的要求。
高可用性 (HA) RADIUS
一種 RADIUS 部署架構，確保驗證服務即使在個別伺服器故障時仍保持可用。常見的 HA 模式包括主動-主動叢集（兩台伺服器同時處理流量，並進行負載平衡）、主動-被動容錯移轉（主要伺服器故障時，次要伺服器接手）以及地理分散式冗餘（伺服器位於不同的實體位置）。
HA 是任何生產 RADIUS 部署的關鍵設計考量。IT 團隊必須定義其復原時間目標 (RTO)——即故障後驗證必須恢復的速度——並據此設計其 HA 架構。雲端 RADIUS 提供者將 HA 作為內建服務提供；地端 HA 則需要明確的架構設計和持續維護。
Worked Examples
一家歐洲酒店集團在六個國家經營 45 家物業。每家物業擁有 150 至 400 間客房及會議設施。中央 IT 團隊由三名網路工程師組成。他們目前在每家物業的虛擬機器上執行 FreeRADIUS——共 45 個獨立執行個體。其中一家物業的憑證到期，導致重大會議期間的訪客 WiFi 全面中斷。技術長希望消除此類事件並減少維護負擔。建議的架構為何？
建議架構：整合 Purple Guest WiFi 的雲端 RADIUS
選擇一個雲端 RADIUS 提供者，需具備歐洲資料駐留（以滿足 GDPR 義務）及與您現有 IdP 的原生整合。若酒店集團使用 Azure AD 進行員工身分管理，請選擇支援 Azure AD LDAP 連接器的平台。
優先遷移訪客 WiFi SSID。訪客驗證是遷移量最大、風險最低的目標。設定 Purple 的強制門戶來處理訪客上線（資料擷取、同意、品牌化登入頁面），並將已驗證的工作階段傳遞至雲端 RADIUS 後端。這可立即免去訪客網路的每物業 FreeRADIUS 維護。
逐物業遷移員工 SSID，從較小的物業開始。對每個物業，在切換至生產流量前，先以測試 SSID 進行為期兩週的平行部署。
在每個物業設定 WAN 生存性。實作 SD-WAN 或雙 ISP 連線。設定無線控制器在本機快取員工憑證長達 8 小時，確保即使短暫的網際網路中斷，飯店營運人員仍可驗證。
遷移後，在每個物業停用 FreeRADIUS 虛擬機器。保留 VM 快照 30 天，作為回滾安全網。
透過雲端 RADIUS 儀表板集中管理政策。一次性定義 VLAN 指定政策，並套用至全部 45 家物業——這項工作以前需要編輯每個物業的組態檔案。
預期成果：消除憑證到期事件（自動輪替）、RADIUS 相關工程時間減少約 40%，以及雲端提供者在該國設有本地邊緣節點的物業，驗證延遲獲得改善。
一座擁有 68,000 個座位的國家級體育場，每年舉辦 30 場大型活動。在滿場比賽期間，尖峰同時上線 WiFi 使用者超過 25,000 人。該體育場擁有專屬 10Gbps 網際網路連線，但 IT 安全團隊有一項強制要求：所有驗證日誌必須保留在英國境內，且不得穿越公共網際網路。該體育場還營運一個符合 PCI DSS 標準的特許點銷售網路。適合採用哪種 RADIUS 架構？
建議架構：採用主動-主動叢集與共置災難復原的地端 RADIUS
在體育場內部的現場資料室部署主要主動-主動 RADIUS 叢集。使用兩台實體伺服器，以主動-主動組態執行 FreeRADIUS，透過無線控制器的 RADIUS 伺服器清單進行負載平衡。每台伺服器應能獨立處理完整的驗證負載——在活動尖峰入場時，每分鐘需能處理 3,000 次以上驗證。
在距離體育場 30 英里內的英國共置設施部署次要叢集，透過專用私有 WAN 連結（非公共網際網路）連接。這可在不違反資料主權要求的情況下提供站點層級的災難復原。
為 PCI DSS 環境區隔，針對銷售點 SSID 設定專用的 RADIUS 政策。透過 RADIUS 屬性將 POS 裝置指定至專用 VLAN。確保 POS 驗證的 RADIUS 記帳日誌至少保留 12 個月，並根據 PCI DSS 要求 10 存放於地端。
為所有員工和 POS 裝置驗證實作 EAP-TLS。部署內部憑證授權單位（Microsoft ADCS 或等效方案）以發放和管理用戶端憑證。設定自動化憑證續約，並在 90 天前發出預警。
在存取點與地端 RADIUS 叢集之間部署 RadSec（TLS 上的 RADIUS），以加密內部網路上的驗證流量——考量到高密度的公共環境，這點尤為重要。
在大型活動前預先配置容量。與體育場的活動營運團隊合作，於 72 小時前取得確認的出席人數，並根據預期的尖峰驗證率驗證 RADIUS 伺服器容量。
預期成果：活動尖峰入場期間的亞毫秒級驗證延遲、完全的資料主權合規性、符合 PCI DSS 標準的驗證記錄，以及透過主動-主動叢集架構實現 99.99% 以上的可用性。
Practice Questions
Q1. 一家全國性藥妝連鎖店在英國經營 320 家門市。每家門市僅有一條來自主要 ISP 的網際網路連線，且無容錯移轉。該連鎖店使用 Microsoft 365 和 Azure Active Directory 管理所有員工身分。由 8 名工程師組成的 IT 團隊，目前管理著每家門市虛擬機器上的 FreeRADIUS 執行個體。資訊安全長已指出，23% 的門市其 RADIUS 憑證將在 90 天內到期。技術長希望解決此問題並減少持續的維護負擔。您建議採用哪種 RADIUS 架構？遷移前最關鍵的基礎設施變更為何？
Hint: 請仔細考慮 WAN 韌性的要求——若部署雲端 RADIUS 後網際網路連線中斷，店內營運會發生什麼情況？
View model answer
建議架構：整合 Azure Active Directory 的雲端 RADIUS，取代 320 個 FreeRADIUS 執行個體。鑑於現有的 Microsoft 365 部署，Azure AD 整合是直接的，且雲端 RADIUS 透過自動輪替立即消除了憑證管理危機。
遷移前最關鍵的基礎設施變更：WAN 韌性。目前每家門市僅有一條 ISP 連線且無容錯移轉。雲端 RADIUS 完全依賴網際網路連線。在遷移任何門市之前，請實作具備雙 ISP 容錯移轉的 SD-WAN，或至少設定無線控制器在本機快取員工憑證 8-12 小時。若無此措施，失去網際網路連線的門市將無法驗證員工至公司網路——可能阻斷銷售點系統、庫存管理和其他依賴網路的營運之存取。
遷移順序：(1) 在所有 320 家門市部署 SD-WAN 或憑證快取。(2) 優先遷移憑證即將到期的 23% 門市——這可處理立即的風險。(3) 以每週 20-30 家為批次遷移其餘門市。(4) 遷移後停用 FreeRADIUS 虛擬機器。預期成果：零憑證到期事件、RADIUS 相關工程時間減少 60-70%、集中式政策管理涵蓋全部 320 家門市。
Q2. 一家會議中心營運商經營一個可容納 5,000 名與會者的單一旗艦場地。該場地每年舉辦 200 場活動，範圍從小型董事會議到大型國際會議。在大型活動期間，尖峰同時上線 WiFi 使用者達 4,500 人。該場地擁有 1Gbps 專屬網際網路連線，SLA 為 99.9%。IT 團隊由兩名網路工程師組成。沒有特定的資料主權要求。現有的地端 FreeRADIUS 伺服器已接近生命週期結束。他們應以新的地端部署取代，還是遷移至雲端 RADIUS？
Hint: 應同時考量尖峰負載概況與團隊規模。單一站點 4,500 個同時使用者是採用地的強烈論據嗎？還是團隊規模和管理負擔會使天平傾斜？
View model answer
建議架構：雲端 RADIUS。儘管是單一站點、高密度的概況，但結合了小型 IT 團隊（2 名工程師）、無資料主權要求以及可靠的專屬網際網路連線，使得雲端 RADIUS 成為更強勢的選擇。
理由：4,500 個同時使用者的尖峰負載完全在企業雲端 RADIUS 平台的輸送量容量範圍內，這些平台專為更高量而設計。雲端路由帶來的 5-20 毫秒額外延遲在會議環境中是難以察覺的。具有 99.9% SLA 的 1Gbps 專屬網際網路連線，為依賴雲端 RADIUS 提供了充足的 WAN 可靠性。
決定性因素是團隊規模。兩名工程師管理地端 FreeRADIUS 的更換——包括硬體採購、作業系統強化、憑證管理、EAP 組態和持續維護——對小型團隊而言是顯著的持續負擔。雲端 RADIUS 將此減少為政策管理，使兩名工程師能騰出時間處理場地更廣泛的網路基礎設施需求。
實作說明：在無線控制器上為場地營運人員 SSID 設定憑證快取，在短暫的網際網路中斷期間提供生存性。確保雲端 RADIUS 提供者在英國或歐洲設有邊緣節點，以最小化高密度活動情境中的驗證延遲。
Q3. 一個區域性 NHS 信託機構在一個郡內營運 12 家醫院。驗證要求包括：(1) 透過 802.1X 搭配 EAP-TLS 讓員工存取臨床網路，(2) 透過 Captive Portal 提供訪客/病患 WiFi，以及 (3) 透過 MAC 驗證繞過進行醫療裝置驗證。該信託機構的資訊治理團隊已強制規定，所有與病患相關的資料，包括驗證日誌，必須保留在英格蘭境內經 NHS 批准的資料中心內。信託機構使用地端 Active Directory，且目前沒有遷移至 Azure AD 的計畫。您建議採用何種架構？
Hint: 此情境具有多項剛性限制。分別辨識每一項，並判斷它是否完全或僅部分排除雲端 RADIUS。
View model answer
建議架構：混合式——臨床人員和醫療裝置驗證使用地端 RADIUS；訪客/病患 WiFi 使用符合 NHS 標準的雲端 RADIUS 或地端方案。
限制條件分析：
- 資料主權（經 NHS 批准的英格蘭資料中心）：這排除了大多數商業雲端 RADIUS 提供者，除非它們提供符合 NHS 標準的資料駐留。部分提供者提供 NHS 特定的部署；這些應進行評估。若無合規的雲端選項，則所有驗證皆需採用地面。
- 無雲端同步的地端 Active Directory：這是雲端 RADIUS 整合的剛性限制。若無 Azure AD Connect 或等效方案，雲端 RADIUS 無法查詢信託機構的員工目錄。員工驗證需要地面 RADIUS。
- 臨床人員的 EAP-TLS：地端 FreeRADIUS 和 NPS 均支援。需要內部 PKI（建議對 AD 整合環境使用 Microsoft ADCS）。
建議部署：在 12 家醫院站點各部署地端 RADIUS（NPS 或 FreeRADIUS）的主動-被動配對，並與信託機構的地端 Active Directory 整合。使用 RADIUS 指定的 VLAN 來區隔臨床、行政和醫療裝置流量。針對訪客/病患 WiFi，部署 Purple 的 Captive Portal 以進行符合 GDPR 的資料擷取和同意管理——這無需 RADIUS 進行訪客驗證，並完全避開了訪客網路的資料主權限制。醫療裝置 MAB 政策在地面 RADIUS 伺服器上管理，MAC 位址清單則透過組態管理工具集中維護。
需緩解的關鍵風險：跨 12 個站點的 EAP-TLS 憑證管理。部署 Microsoft ADCS，並透過群組原則自動化憑證註冊，以確保所有臨床裝置自動接收和續約憑證。