Cloud RADIUS vs on-premise RADIUS：IT 團隊決策指南

第 1 部分 — 介紹與背景 歡迎來到 Purple 技術簡報。我是您的主持人，今天我們要探討一個針對多據點場域的關鍵基礎架構決策：Cloud RADIUS 對比 On-Premises RADIUS。如果您是管理飯店集團、零售連鎖店或大型公共場域驗證機制的 IT 總監或網路架構師，本次簡報將為您提供做出正確決策所需的實用評估框架。 讓我們來設定背景脈絡。RADIUS - Remote Authentication Dial-In User Service - 是您網路的守門人。每當訪客登入您的 WiFi，或是員工透過 802.1X 連線到企業 SSID 時，RADIUS 就是負責對照您的目錄確認其憑證並授權存取的引擎。在傳統上，這意味著要在您的資料中心上架實體伺服器、安裝 FreeRADIUS 或專有的網路原則伺服器，並自行管理整個技術堆疊。如今，Cloud RADIUS 服務提供了託管式、全球分佈式的替代方案。但哪一個才適合您的具體部署？讓我們深入探討技術上的權衡。 第 2 部分 — 技術深入探討 首先，讓我們談談架構和延遲。在 On-Premises 部署中，您的存取點會直接與本地的 RADIUS 伺服器通訊。對於單一大型體育場或獨立醫院，這提供了極低的延遲。驗證請求透過本地 LAN 傳輸 - 也就是低於毫秒級的來回時間。然而，如果您是多據點零售連鎖店，將所有驗證流量導回中央的 On-Premises 伺服器會引入 WAN 延遲，並形成單一故障點。如果該 WAN 連結中斷，您的遠端據點將完全無法驗證使用者。 Cloud RADIUS 完全翻轉了這種模式。RADIUS 基礎架構在全球多個可用區域中託管。當使用者在分部據點連線時，請求會被路由到最近的雲端邊緣節點。與回傳到中央的 On-Premises 伺服器相比，這顯著降低了分佈式部署的延遲。此外，雲端服務商預設就建置了高可用性。如果一個節點發生故障，流量會自動容錯移轉到下一個最近的節點。要在 On-Premises 達到這種程度的備援，您需要在多個地理分佈的資料中心部署主動 - 主動（active-active）叢集 - 這需要極大的工程努力和資本支出。現在，讓我們來看看維護開銷和擴充性。地端 RADIUS 需要您的團隊管理作業系統、套用安全性修補程式、管理 SSL 憑證，並全天候監控伺服器健全狀況。當您需要為大型活動（例如可容納 70,000 人的體育館音樂會）進行擴充時，您必須提前佈署新的硬體或虛擬機器。這無法進行彈性擴充。Cloud RADIUS 則是作為一種 SaaS 服務來提供。供應商會自動處理底層基礎架構、修補程式和擴充。您只需透過網頁儀表板或 API 管理原則與整合。這能將您的資深工程師從日常維護中解放出來，讓他們專注於策略性計畫，而不是僅僅維持系統運作。 讓我們討論與識別提供者（Identity Providers）的整合。如果您的使用者目錄已經在雲端（使用 Azure Active Directory、Google Workspace 或 Okta），Cloud RADIUS 解決方案就是最自然契合的選擇。它能透過 API 或安全連接器進行無縫整合。相反地，如果您擁有因安全性或合規性原因而無法暴露於網際網路的舊型地端 Active Directory，地端 RADIUS 伺服器可能是您唯一可行的選擇。它可以在不穿透防火牆的情況下直接查詢本地 AD，這在對資料主權有嚴格要求的醫療保健環境或政府機構中特別有用。 現在我們來談談合規性。PCI-DSS 要求持卡人資料環境必須使用強式驗證。GDPR 要求妥善處理個人資料（包括驗證記錄）。Cloud RADIUS 供應商通常會提供 SOC 2 Type II 認證、GDPR 資料處理協定以及區域資料落地選項。地端部署則讓您對資料存放位置擁有完全的控制權，這在高度受監管的行業中可能非常有利。然而，這也意味著合規性的責任將完全落在您的團隊身上。 讓我深入剖析每種方法的技術架構，因為了解運作機制將有助於您做出更明智的決定。 在傳統的地端 RADIUS 佈署中，您通常會有一台或多台伺服器，執行 Microsoft 的網路原則伺服器（通常稱為 NPS）或開源的 FreeRADIUS 平台。這些伺服器位於您的網路邊界之內，並透過 UDP 與您的存取點進行通訊，通常使用連接埠 1812 進行驗證，並使用連接埠 1813 進行計帳。存取點與 RADIUS 伺服器之間的共用金鑰是一項關鍵的安全要素，它必須夠長、隨機且定期輪替。 FreeRADIUS 是全球部署最廣泛的 RADIUS 伺服器，為全球數億用戶提供驗證支援。它具有高度可配置性，支援廣泛的 EAP 方法，並能與幾乎任何後端目錄整合。然而，這種靈活性是有代價的：它需要專業的系統管理。配置錯誤是驗證失敗的常見原因，而偵錯 FreeRADIUS 日誌則需要豐富的經驗。 Cloud RADIUS 平台簡化了所有這些複雜性。在底層，它們在多個雲端區域運行分散式 RADIUS 架構，但您只需透過簡潔的網頁介面或 API 與其進行互動。您定義您的驗證原則 - 哪些 SSID 對應到哪些用戶群組、允許哪些 EAP 方法、如何處理未知裝置 - 平台會處理其餘的一切。 在需要極高驗證吞吐量並結合嚴格延遲限制的環境中，地端 RADIUS 仍然保有明顯的優勢。以一個大型交通樞紐為例 - 如機場或火車站 - 當旅客抵達時，成千上萬的裝置會同時嘗試進行驗證。在這種情境下，本地 RADIUS 叢集可以在不到一毫秒內處理驗證請求，而 Cloud RADIUS 請求必須在網際網路上往返，這會根據服務供應商最近的邊緣節點增加 5 到 50 毫秒不等的延遲。 第 3 部分 - 導入建議與常見陷阱 讓我透過兩個真實世界的情境來為您具體說明。 情境一：一家在六個國家擁有 45 家飯店的歐洲飯店集團。其 IT 團隊是集中式的，只有三名網路工程師管理整個資產。他們原本在每家飯店的虛擬機器上運行 FreeRADIUS - 有 45 個獨立的執行個體需要進行修補、監控和維護。當其中一家飯店的憑證過期時，在一場大型會議期間導致了整個賓客 WiFi 斷線。他們隨後移轉到 Cloud RADIUS 服務，將原則管理集中化，並消除了單一站點的維護工作。這支三名工程師的團隊省回了先前花在 RADIUS 維護上大約 40% 的時間。 情境二：一個擁有 68,000 個座位之國家體育場。其 IT 團隊對數據主權有嚴格的要求 - 所有驗證日誌必須保留在英國境內。他們部署了主動 - 主動設定的雙地端 RADIUS 叢集，並在 20 英里外的共用主機代管設施中設有次要叢集。這為他們提供了本地控制、低於一毫秒的驗證，以及在不依賴網際網路連線的情況下處理高載流量的能力。 部署 Cloud RADIUS 時，最常見的陷阱是忽略了現場的本地網際網路連線。Cloud RADIUS 完全依賴 WAN 連線。為了減輕這種風險，請實施本地生存力策略 - 在本地網路控制器上快取關鍵員工的憑證，或使用 SD-WAN 以確保網際網路連線的高可用性。 對於地端部署而言，最大的營運風險是憑證管理。如果您地端 RADIUS 伺服器上的憑證過期，每一個用戶端裝置都會拒絕連線，導致完全的身分驗證中斷。Cloud RADIUS 供應商會自動進行憑證輪替，完全消除這一風險。 第 4 部分 — 快速問答 問題一：Cloud RADIUS 是否支援印表機和 IoT 感測器等無螢幕裝置的 MAC Authentication Bypass（MAB）？答案：是的。大多數企業級 Cloud RADIUS 平台都支援 MAB。您可以透過其儀表板或 API 管理 MAC 地址白名單，這使得處理橫跨數百個位置的 IoT 裝置變得更加容易。 問題二：五年的總體擁有成本相比如何？答案：地端部署屬於資本支出（CapEx）導向 - 需要硬體、授權、電力、冷卻和工程師時間。Cloud RADIUS 則屬於營運費用（OpEx） - 通常按每年每用戶或每裝置計價。對於快速增長的多站點部署，雲端可預測的營運費用通常更具成本效益。擁有超過 10 個站點且網路工程師少於 5 人的組織，幾乎總能在 18 個月內從雲端獲得正向的投資報酬率（ROI）。 問題三：您可以執行混合模式嗎？答案：絕對可以。訪客和 IoT SSID 使用 Cloud RADIUS，而企業 SSID 則使用地端進行內部 Active Directory 的身分驗證。Purple WiFi 原生支援這種混合模式。 問題四：當雲端供應商中斷時會發生什麼事？答案：信譽良好的 Cloud RADIUS 供應商會提供 99.99% 可用性的 SLA，並以多區域備援作為後盾。請務必為您的存取點配置降級容錯策略 - 無論是開放存取受限的 VLAN，還是使用本地快取的認證資料 - 以優雅地處理這種情況。 第 5 部分 — 總結與後續步驟 總結關鍵的決策架構：當您擁有單一大型位置、且有嚴格的資料主權要求、實體隔離（air-gapped）的安全環境，或是無法連接雲端的傳統地端目錄時，請選擇地端 RADIUS。當您擁有分散式多站點足跡、雲端原生身分識別供應商（例如 Okta 或 Azure AD）、小型中央 IT 團隊，或者需要在沒有硬體採購前置時間的情況下跨新站點進行快速部署時，請選擇 Cloud RADIUS。 歸根結底：對於當今大多數多站點場域營運商而言，Cloud RADIUS 是營運上更優越的選擇。地端部署的延遲優勢已在很大程度上被全球分佈的雲端基礎架構所抵消。在您做出決定之前，請審計三件事：您目前的身分識別供應商及其是否為雲端原生、您各個站點的 WAN 彈性，以及您團隊管理持續維護的能力。這三個因素將告訴您哪條路徑最適合您的組織。 感謝您參與本次 Purple 技術簡報。如需深入瞭解企業 WiFi 架構，請造訪 Purple.ai 的指南庫。