什麼是 Cloud RADIUS？RADIUS as a Service 完整指南

什麼是 Cloud RADIUS？RADIUS 軟體即服務 (SaaS) 的全方位指南。 歡迎收聽 Purple WiFi 智慧播客（Intelligence Podcast）。我是您的主持人。今天我們將深入探討 Cloud RADIUS：包括它的定義、後台運作機制，以及最關鍵的：如何評估它是否為您的組織本季的正確決策。無論您是管理飯店集團、零售店面、體育場還是公共部門網路，這集內容都非常適合您。 讓我們拉開序幕。 前言與背景。 如果您曾向董事會解釋為什麼網路驗證伺服器在凌晨 2 點當機，且為何花了三個小時才恢復運作，那麼您就已經了解 Cloud RADIUS 所解決的核心痛點了。傳統的自建（on-premises）RADIUS 基礎架構功能強大，但帶來了龐大的維運成本：需要採購硬體、管理修補程式生命週期、手動規劃備援架構，而且您的機房中還存在著單一故障點。 Cloud RADIUS（或稱為 RADIUS as a Service，RADIUS 軟體即服務）將驗證層移至受託管、高可用性的雲端環境中。通訊協定本身（遠端用戶撥入驗證服務）並未改變。它仍是 IEEE 802.1X 網路存取控制的骨幹，依然是您的無線基地台（Access Point）用來驗證誰能存取網路的機制。但運行該架構的基礎設施現在改由服務商負責維運。這在企業 IT 領域中是一項重大轉變。 接著，讓我們進入技術細節。 技術深度剖析。 RADIUS 最初定義於 2000 年發布的 RFC 2865，且至今仍出奇地耐用。該通訊協定採用主從式架構（Client-Server model）運作。您的網路存取設備（不論是 Wi-Fi 無線基地台、VPN 集中器還是有線交換器）皆扮演 RADIUS 用戶端（也稱為網路存取伺服器，簡稱 NAS）的角色。當使用者嘗試連線時，NAS 會將「存取請求」（Access-Request）封包轉發給 RADIUS 伺服器，伺服器會比對使用者目錄（通常是 Active Directory、LDAP 或雲端身分識別提供者）來驗證憑證，並回傳「存取核准」（Access-Accept）或「存取拒絕」（Access-Reject）。 這就是核心的互動機制。但真正的複雜度在於其周邊流程：EAP 方法、VLAN 分配、策略執行、帳務記錄以及憑證管理。 在傳統的自建部署中，您需要在專用硬體上執行 FreeRADIUS 或 Microsoft NPS、自行管理憑證、設定容錯轉移，並維護自己的使用者資料庫同步。對於擁有優秀 IT 團隊的單一據點部署而言，這還算應付得來。但對於在多個國家擁有 50 個據點的零售業或飯店集團來說，這將會成為極為沉重的營運負擔。Cloud RADIUS 將這一切抽象化。驗證邏輯、憑證基礎架構、備援機制以及策略引擎，全部都以託管服務的形式提供。您的存取點會指向雲端託管的 RADIUS 端點（通常是主要和次要 IP 位址），而該服務會處理背後的一切。 現在，讓我們來談談驗證方法，因為這正是技術決策真正至關重要的關鍵。 企業 WiFi 中最常見的 EAP 方法是 PEAP（受保護的 EAP），它在 TLS 工作階段內建立 MSCHAPv2 通道。它受到廣泛支援、原生支援 Active Directory，並且是大多數 Windows 和 Android 裝置的預設設定。然而，PEAP 存在已知的安全性漏洞，特別是圍繞在憑證驗證方面。如果您的用戶端裝置未設定為驗證伺服器憑證，您就會暴露於透過惡意存取點進行憑證竊取的攻擊風險中。 EAP-TLS 是黃金標準。它使用雙向憑證驗證（伺服器和用戶端皆出示憑證），從而完全消除了密碼攻擊面。其代價是用戶端憑證的部署，這需要 PKI 基礎架構和 MDM 整合。對於託管的裝置群，這絕對是正確的選擇。而對於 BYOD 環境，情況則較為複雜。 EAP-TTLS 和 EAP-FAST 也值得了解。TTLS 在需要支援各種用戶端裝置（包括 Linux 系統）的環境中特別常見。EAP-FAST 是由 Cisco 開發的，作為 PEAP 的替代方案，它使用「受保護的存取憑證」（Protected Access Credentials）來避免對憑證驗證的依賴。 架構完善的 Cloud RADIUS 服務支援所有這些方法，並允許您設定個別 SSID 策略 — 因此您的企業 SSID 使用帶有憑證驗證的 EAP-TLS，您的員工 SSID 使用帶有 Active Directory 的 PEAP，而您的訪客網路則使用與 RADIUS 堆疊完全獨立的 Captive Portal 或社群登入流程。 說到這裡 — RADIUS 和訪客 WiFi 經常被混為一談，但它們的用途不同。RADIUS 是您針對已知使用者和裝置的驗證與授權層。訪客 WiFi 通常使用 Captive Portal 流程，這完全是另一種不同的機制。例如，Purple 的平台透過獨立的身分識別層處理訪客驗證，收集第一方數據並實現行銷自動化，而 RADIUS 則處理企業和員工的網路存取控制。這些是互補而非競爭的系統。 現在，讓我們來談談「雲端代管」在實務上的真正含意。一個架構完善的 Cloud RADIUS 服務會在多個可用區（Availability Zones）中運作，並具備自動容錯移轉功能。驗證請求會在多個節點之間進行負載平衡，且即使在尖峰負載下，該服務仍能保持低於 100 毫秒的響應時間。對於在活動期間需要處理 40,000 個並行連線的體育館來說，這種低延遲與高吞吐量表現至關重要。單一地端伺服器根本無法提供如此彈性。 從合規性的角度來看，在英國和歐盟營運的 Cloud RADIUS 供應商，在處理驗證記錄和使用者資料時必須符合 GDPR 規範。對於同時處理付款卡資料的零售和餐飲旅宿環境，有關網路分段和存取控制的 PCI DSS 要求具有直接相關性 —— RADIUS 是您控制環境的一部分，而您的合格安全性評估人員（QSA）會希望看到妥善設定與稽核記錄的證據。 WPA3 也值得探討。從 WPA2 到 WPA3 的過渡，為個人網路引進了等效同時驗證（SAE），並為企業環境引進了 WPA3-Enterprise。WPA3-Enterprise 強制要求最高安全等級的 192 位元安全模式，這需要特定的 EAP 方法與加密套件。Cloud RADIUS 服務需要支援這些設定，才能與時俱進。 實作建議與常見陷阱。 好，讓我們切入實際層面。如果您正在評估本季部署 Cloud RADIUS，以下是我建議關注的重點。 第一，與您的身分驗證提供者整合。您的 Cloud RADIUS 服務需要與您使用者實際存在的平台進行同步 —— 無論是 Microsoft Entra ID（前身為 Azure AD）、Google Workspace、Okta，或是透過 LDAP 代理整合的地端 Active Directory。此整合的品質決定了您的營運開銷。原生 SAML 或 SCIM 佈建遠比手動匯入 CSV 來得理想。 第二，憑證管理。如果您正在部署 EAP-TLS，您需要明確掌握用戶端憑證是如何發行、更新和撤銷的。最優秀的 Cloud RADIUS 服務會包含整合式 PKI，或能與您現有的憑證授權單位（CA）無縫整合。憑證過期是企業 WiFi 中最常導致驗證失敗的原因之一 —— 這透過適當的自動化是完全可以避免的。 第三，網路設備相容性。您的無線基地台（AP）必須支援 RADIUS 驗證 —— 幾乎所有企業級 AP 都支援 —— 但您需要根據 AP 廠商的實作情況，驗證您所選服務支援的特定 EAP 方法和 RADIUS 屬性。Cisco、Aruba、Juniper Mist 和 Ruckus 在處理 RADIUS 屬性和 CoA（授權變更）訊息時，都各有其細微差異。第四，備援設定。請務必同時設定主要與次要的 RADIUS 伺服器 IP。您 NAS 裝置上的容錯移轉逾時設定至關重要 — 如果設定得太長，當主要伺服器無法連線時，使用者將會面臨 30 秒的驗證延遲。對於大多數環境而言，3 到 5 秒的逾時並立即進行容錯移轉才是正確的設定。 第五 — 也是最容易被忽略的一點 — 計費機制（Accounting）。RADIUS 計費記錄是您的稽核軌跡。它們會告訴您是誰從哪台裝置、在什麼時間連線，以及連線了多長時間。出於合規性目的（特別是在醫療保健和公共部門環境中），這些記錄需要予以保留並可供存取。請確保您的 Cloud RADIUS 供應商為您提供計費數據的存取權限，而不僅僅是驗證記錄。 常見陷阱：共享密鑰（Shared Secret）的複雜度。您的 RADIUS 共享密鑰 — 即 NAS 與 RADIUS 伺服器之間的預先共用金鑰 — 必須既長且隨機。簡短或易遭猜測的共享密鑰是實際存在的攻擊媒介。請使用至少 32 個字元的隨機產生字串，並定期進行輪替。 另外也要注意 IP 白名單。許多 Cloud RADIUS 服務要求您將 NAS 裝置的來源 IP 列入白名單。在您的 AP 管理平台可能使用 NAT 的動態雲端環境中，這可能會導致非預期的驗證失敗。在部署之前，請先確認您網路的 NAT 行為。 快速問答。 讓我快速解答幾個我經常被問到的問題。 Cloud RADIUS 是否支援多租戶環境？是的 — 大多數企業級 Cloud RADIUS 服務都支援租戶隔離，因此託管服務供應商（MSP）可以從單一平台為多個客戶執行獨立的 RADIUS 策略。 Cloud RADIUS 驗證的典型延遲是多少？對於架構良好的服務，延遲低於 100 毫秒。802.1X 握手本身會增加一些額外開銷，但對於大多數 EAP 方法，端到端的總驗證時間應在 500 毫秒以內。 Cloud RADIUS 是否適用於 OpenRoaming？是的。OpenRoaming（無線寬頻聯盟的漫遊架構）的核心採用了 RADIUS 聯盟（RADIUS Federation）。支援 Hotspot 2.0 和 OpenRoaming 的 Cloud RADIUS 服務可讓您的使用者在全球參與該網絡的各個網路中自動進行驗證。Purple 在其 Connect 授權下支援 OpenRoaming，在該聯盟中扮演身分識別提供者的角色。 Cloud RADIUS 是否適用於高安全性環境？對於大多數企業環境而言，是的。對於含有機密數據或特定政府安全等級的環境，您可能需要評估託管雲端服務是否符合您特定的認證要求。 總結與後續步驟。 總結來說：Cloud RADIUS 是一種成熟、可直接投入生產環境的網路存取控制方法。它在不妥協安全性和功能的前提下，免除了維護地端 RADIUS 基礎架構的營運負擔。對於擁有多個據點的企業而言，其投資報酬率相當直觀 —— 您可以免去硬體資本支出、降低 IT 負擔、獲得內建的備援機制，並擁有一項能隨企業規模同步擴展的服務。 關鍵的決策在於：哪種 EAP 方法最適合您的裝置群、如何與您現有的身分驗證提供者進行整合，以及您所選擇的服務是否具備企業所需的合規與稽核功能。 如果您正在營運飯店集團、零售連鎖店，或管理公共部門網路，我建議先從單一據點的概念驗證 (PoC) 開始 —— 調整好您的 RADIUS 設定，驗證與身分驗證提供者的整合，並在全系統部署前測試驗證延遲。 如欲深入瞭解 WiFi 分析、訪客網路管理，以及 Purple 的平台如何與基於 RADIUS 的驗證進行整合，請造訪 purple.ai。感謝您的聆聽。