RADIUS as a Service 針對混合工作模式員工的安全優勢

摘要

混合工作模式的轉變暴露了傳統網路安全的一個根本弱點：本地部署的 RADIUS 伺服器是為員工坐在同一棟大樓、連接同一個網路的世界而設計的。那個世界已不復存在。如今，您的員工從飯店客房、零售賣場、遠端辦公室和活動場地進行身分驗證。您的身分識別提供者託管在雲端。您的存取點跨越數百個位置。然而，許多企業仍然依賴實體 RADIUS 伺服器，這些伺服器需要手動修補，無法原生整合 Microsoft Entra ID 或 Google Workspace，且在硬體出錯時會無聲無息地失效。

RADIUS as a Service 透過雲端原生身分驗證引擎取代了該基礎設施。您只需將存取點指向雲端端點。供應商負責管理伺服器、修補程式和高可用性。您則負責管理原則。對於 旅宿 集團、 零售 連鎖店和公共場所的 IT 團隊而言，這種轉變消除了硬體開銷，實施了基於身分的網路區段隔離，並提供了 PCI DSS 和 GDPR 所要求的稽核追蹤。

技術深入剖析

為何本地部署的 RADIUS 面臨困境

在 RFC 2865 中定義的 RADIUS 為網路存取提供了集中式的驗證、授權和計費 (AAA)。每個執行 WPA2-Enterprise 或 WPA3-Enterprise WiFi 的企業都依賴它。協定本身是完善的，問題在於圍繞其發展的基礎設施模型。

Linux 上的 FreeRADIUS 需要大量的專業知識來部署、強化和維護。Microsoft 網路原則伺服器 (NPS) 與 Active Directory 緊密結合，且不原生支援 Microsoft Entra ID、Okta 或 Google Workspace。Cisco 身分服務引擎 (ISE) 提供了企業級的原則功能，但需要專用硬體、授權複雜，且需要專業團隊來操作。這三者都需要您手動建立和維護高可用性，通常是透過執行兩台具有資料庫同步功能的伺服器，並在前方加上負載平衡器。

對於擁有穩定 Active Directory 的單一站點企業而言，這種模式是可行的。但對於擁有 50 家物業的飯店集團、擁有 400 家門市的零售連鎖店，或擁有分散式校園的大學來說，這將變得難以運作。您要麼集中管理 RADIUS 伺服器並承受來自遠端站點的身分驗證延遲，要麼在每個位置部署伺服器並進行個別管理。這兩種方案都無法進行規模擴充。

RADIUS as a Service 的架構

RADIUS as a Service 是一種基於雲端的 RADIUS 協定傳遞模式。協定本身保持不變，遵循 RFC 2865 及其延伸標準。改變的是由誰來維護基礎設施。

當裝置連接到您的 WiFi 網路時，存取點（RADIUS 用戶端）會透過安全、加密的通道，將驗證請求轉發給雲端 RADIUS 端點。此雲端服務會比對您的身分識別提供者驗證憑證，並傳回「Access-Accept」（接受存取）或「Access-Reject」（拒絕存取）訊息，以及動態 VLAN 分配等原則屬性。從存取點的角度來看，此驗證流程與地端（on-premise）RADIUS 完全相同。

雲端服務供應商在多個地理位置分佈的資料中心內運行 RADIUS 伺服器。容錯移轉為自動進行。若某個端點變得無法使用，流量會在無需您的小組進行任何干預的情況下，自動路由至下一個運作正常的端點。對於在多個地區設有據點的組織，驗證會在最近的雲端端點進行，無論地理位置如何，皆能保持低延遲。

IEEE 802.1X 與 EAP 方法

IEEE 802.1X 是基於連接埠的網路存取控制（NAC）標準。它會強制裝置在獲得 IP 位址並允許傳輸流量之前進行驗證。在 802.1X 部署中，RADIUS 即為驗證伺服器。

可延伸驗證通訊協定（EAP）定義了憑證的交換方式。雲端 RADIUS 支援完整的 EAP 方法：

在 RFC 5216 中定義的 EAP-TLS 是黃金標準。用戶端裝置和 RADIUS 伺服器都會向對方出示數位憑證。這種雙向驗證將密碼完全自網路存取程序中移除。憑證在密碼學上與裝置綁定，無法像密碼那樣被網路釣魚、猜測或竊取。對於曾遭受憑證型資安漏洞危害的組織而言，這是最直接可行的技術緩解措施。

動態 VLAN 分配

除了驗證之外，RADIUS 伺服器還會執行授權。當它接受連線時，會將原則屬性傳回給存取點，其中包括要分配給裝置的 VLAN ID。此動態 VLAN 分配即為實現「身分識別導向網路」（Identity-Based Networks）的機制。

飯店接待人員通過驗證後，會被分配到前台 VLAN 並獲得物業管理系統的存取權限。房務清潔人員則被分配到僅具備網際網路存取權限的受限 VLAN。訪客裝置會被分配到訪客 WiFi VLAN，與所有企業資源完全隔離。IoT 裝置（例如安全監視器）則會被分配到專用的 IoT VLAN。這一切都會根據 RADIUS 伺服器驗證的身份自動進行，無需對每台裝置進行任何手動 VLAN 設定。

這就是應用於網路存取的最小權限原則。您不應僅因為裝置連接到特定的 SSID 就信任它。您是根據已驗證的身份授予存取權限，並將該存取權限限制在該身份所需的範圍內。若要深入瞭解這如何融入更廣泛的網路存取控制策略，請參閱我們的 網路存取控制系統 指南。

原生雲端身份整合

雲端 RADIUS 在營運上最顯著的優勢在於其與現代身份識別提供商的原生整合。雲端 RADIUS 透過 OIDC、SAML 和 LDAP 等標準協定，直接連接到 Microsoft Entra ID、Okta 和 Google Workspace。當您在身份識別提供商中設定新員工時，他們可以立即對 WiFi 網路進行驗證。當您辦理員工離職時，只要在目錄中停用其帳戶，其 WiFi 存取權限就會在每個據點的每個存取點立即被撤銷。

這種即時同步消除了企業 WiFi 中最頑固的安全漏洞之一：仍擁有共享 PSK 的前員工，或在其離職時未手動刪除其 RADIUS 帳戶。透過雲端 RADIUS 和雲端身份識別提供商，離職作業只需單一執行，即可立即在整個網路生效。

實作指南

步驟 1：連接您的身份識別提供商

將雲端 RADIUS 服務連接到您的身份識別提供商。對於 Microsoft Entra ID 或 Google Workspace，這通常涉及透過 OAuth 授權企業應用程式，或設定 LDAP 連接器。將您的目錄群組對應到特定的網路原則。在開始之前定義您的角色分類：哪些群組對應到哪些 VLAN，以及每個 VLAN 攜帶哪些存取權限。在開始時做好這一點可以避免日後大量繁重的重做工作。

步驟 2：為企業裝置部署憑證

對於企業擁有的裝置，請設定您的行動裝置管理（MDM）平台（例如 Microsoft Intune 或 Jamf），以將用戶端憑證推送至裝置。這可以啟用 EAP-TLS 驗證。確保簽發 RADIUS 伺服器憑證的根憑證授權單位（Root CA）受所有用戶端裝置信任。受損的信任鏈是導致無聲驗證失敗最常見的原因。

步驟 3：設定您的網路硬體

將雲端 RADIUS IP 位址和共用金鑰新增至您的無線控制器或存取點（AP）。請務必同時設定主要和次要端點，以利用供應商內建的備援機制。確保 UDP 連接埠 1812（驗證）和 1813（計費）已從您的存取點對外開放至雲端 RADIUS 端點。在正式上線前驗證此設定。防火牆規則設定錯誤是部署失敗的第二大常見原因。

雲端 RADIUS 支援 Cisco Meraki、HPE Aruba、Ruckus、Juniper Mist、Ubiquiti UniFi、Cambium、Extreme 和 Fortinet。設定步驟因廠商而異，但 RADIUS 協定是標準化的，因此核心參數（伺服器 IP、共用金鑰、驗證連接埠）皆一致。

步驟 4：定義 VLAN 原則

在您的 RADIUS 原則引擎中設定動態 VLAN 指派。將每個使用者角色或裝置類型對應到特定的 VLAN ID。在部署至生產環境之前測試每項原則。一個簡單的測試矩陣（每個角色一部裝置、每個角色一個 VLAN，並驗證配置位置）能在配置錯誤影響使用者之前，捕獲大部分的錯誤。

最佳實踐

對所有企業裝置強制執行 EAP-TLS。 在您的 MDM 部署允許的情況下，儘快停用 PEAP-MSCHAPv2。PEAP 依賴容易遭洩露的密碼；EAP-TLS 則依賴無法被洩露的憑證。

進行全面區隔。 切勿將員工、訪客和 IoT 裝置放置在同一個子網路中。使用 RADIUS 強制執行嚴格的 VLAN 邊界。這對於在 PCI DSS 規範下處理付款卡資料的 零售 環境，以及保護病患資料的 醫療保健 環境至關重要。

與 WPA3-Enterprise 保持一致。 WPA3-Enterprise 是目前的 WiFi 安全標準，需要進行 802.1X 驗證。確保您的存取點支援 WPA3-Enterprise，並將其設定為員工網路的最低安全性標準。

定期稽核您的 RADIUS 日誌。 雲端 RADIUS 提供集中式稽核日誌。每週審查驗證失敗事件。來自特定裝置或位置的失敗次數急遽增加，是設定錯誤或潛在攻擊的早期指標。

測試容錯移轉（Failover）。 至少每季模擬一次主要 RADIUS 端點故障，並驗證驗證程序是否能透過次要端點繼續進行。記錄測試結果。這是一個簡單的測試，但大多數團隊在真正需要之前從未執行過。

對於在包括海洋或偏遠地區等複雜環境中部署 WiFi 的場域，請參閱我們的 在 Starlink 上設定 Captive Portal 指南，以瞭解有關 WAN 依賴性的注意事項。

疑難排解與風險緩釋

驗證逾時

若裝置無法通過驗證，請先檢查您的存取點（Access Points）與雲端 RADIUS 端點之間的連線。確認 UDP 連接埠 1812 與 1813 對外開放。現代防火牆上的深層封包檢測（DPI）可能會延遲或丟棄 RADIUS 封包。若您發現逾時，請檢查防火牆原則，查看是否有規則可能正在檢測或限制流向 RADIUS 端點的 UDP 流量。

憑證信任鏈失敗

如果使用 EAP-TLS，請確保用戶端裝置信任簽發 RADIUS 伺服器憑證的根憑證授權單位（Root CA）。若信任鏈斷裂，裝置將會無聲無息地拒絕連線，以防止中間人攻擊。這會呈現為連線失敗且無明顯的錯誤訊息。請檢查 RADIUS 伺服器記錄中的 EAP-TLS 交握失敗。請透過 MDM 將根憑證授權單位憑證部署到所有受管理的裝置。

廣域網（WAN）依賴性

雲端 RADIUS 需要運作中的網路連線。若 WAN 連結中斷，驗證請求將無法到達伺服器。對於關鍵任務的本機資源，請評估支援本機存活能力或驗證快取的存取點。對於大多數部署而言，對 WAN 的依賴是可以接受的，因為沒有網路的站點無論如何都無法存取雲端應用程式。

共享金鑰不匹配

每個存取點或無線控制器都必須配置為具有正確共享金鑰的 RADIUS 用戶端。不匹配會導致來自該裝置的所有驗證請求被無聲無息地丟棄。如果特定存取點失敗而其他存取點運作正常，請驗證該裝置上的共享金鑰配置。

投資報酬率（ROI）與業務影響

RADIUS as a Service 的商業效益建立在三大支柱之上：降低資本支出、減少營運開銷以及提升安全性。

在資本支出方面，您無需再支付購買、授權與更新實體伺服器的費用。最低可行性的地端 RADIUS 部署需要兩部伺服器以實現高可用性、作業系統授權，且每三到五年就要進行一次硬體更新。對於擁有 50 家物業的飯店集團而言，這代表了整個資產中重大的硬體投資。

在營運開銷方面，您的工程團隊不再需要花時間為 Windows Server 修補安全性更新、疑難排解 FreeRADIUS 配置，或是在實體基礎設施上管理憑證更新。這些時間可以重新分配到直接改善安全性架構的安全原則工作上。

在安全性方面，轉向 EAP-TLS 與動態 VLAN 分配能實質減少受攻擊面。憑證竊取是網路入侵的首要原因。從網路驗證過程中消除密碼可直接解決該風險。集中式稽核記錄支援符合 PCI DSS v4.0 和 GDPR，從而降低合規稽核的成本與複雜度。 對於管理 交通 樞紐或高人流量場所的組織而言，能夠從單一儀表板在所有地點執行一致的安全策略，是一項可衡量的營運提升。Purple 目前在 80,000 多個實體場所運作，並在 2024 年處理了 4.4 億次登入（Purple 內部數據，2024 年）。支援如此龐大規模的基礎架構，在設計上即為雲端原生。

欲深入瞭解 WiFi 分析和網路智慧如何與業務成果相結合，請參閱我們的 WiFi 分析平台 。

參考資料

[1] IEEE Standard for Local and metropolitan area networks - Port-Based Network Access Control. IEEE Std 802.1X-2020. [2] IETF. Remote Authentication Dial In User Service (RADIUS). RFC 2865. 1997. [3] IETF. The EAP-TLS Authentication Protocol. RFC 5216. 2008. [4] IronWiFi. Benefits of a Cloud RADIUS Server: Why Enterprises Are Moving Authentication Online. February 2026. [5] SecureW2. Cloud vs. On-Site RADIUS: Which is Better? May 2026. [6] Portnox. RADIUS as a Service. 2026. [7] PCI Security Standards Council. PCI DSS v4.0. March 2022. [8] Purple. 內部平台數據：4.4 億次登入，80,000+ 個場所。2024 年。