將 RADIUS-as-a-Service 與雲端目錄（Azure AD 和 Google Workspace）整合

執行摘要

對於投資於雲端身分識別生態系統的現代企業而言，將雲端目錄與實體無線網路連接起來是至關重要的安全任務。過去，WiFi 驗證依賴於內部部署的 Active Directory Domain Services 和 Windows Network Policy Server (NPS)。隨著組織遷移至 Microsoft Entra ID 和 Google Workspace，該內部部署的驗證架構已成為一種負擔 - 維護成本高、難以擴充，且與零信任安全模型不相容。

RADIUS as a Service (RADIUSaaS) 改變了這一局面。雲端託管的 RADIUS 伺服器直接與您的雲端目錄整合，即時驗證驗證請求，並將存取決定返回給您的存取點 - 無需內部部署伺服器、無需修補程式更新週期，且無單點故障。結合基於憑證的 EAP-TLS 驗證，此架構可消除憑證遭竊取的風險、支援符合 PCI-DSS 和 GDPR 規範，並為每個場所的員工提供無縫的使用體驗。

本指南涵蓋了內部部署 NPS 與雲端原生 RADIUS 之間的架構決策、透過 Microsoft Intune 和 Google Admin Console 部署 EAP-TLS，以及維護飯店、零售物業、體育場館和公共部門場地無線存取安全的營運最佳實踐。如需更廣泛的網路存取控制介紹，請參閱 網路存取控制系統指南 。

技術深入探討：架構與標準

RADIUS 與 IEEE 802.1X 的角色

安全企業 WiFi 的基礎是 IEEE 802.1X 標準，它提供了基於連接埠的網路存取控制。當用戶端裝置（** supplicant ）嘗試連接到 WPA2-Enterprise 或 WPA3-Enterprise 網路時，無線存取點（ authenticator **）會阻擋除 EAP（可延伸驗證通訊協定）封包以外的所有流量。存取點會將這些封包轉發給 RADIUS 伺服器。RADIUS 伺服器會比對目錄服務驗證身分，並返回 Access-Accept 或 Access-Reject 訊息。只有在此時，存取點才會授予網路存取權限。

這種由用戶端、驗證器、驗證伺服器組成的三方模型是企業無線安全的基石，並在 IEEE 802.1X 中定義。自推出以來，它並未發生根本性的改變。改變的是 RADIUS 伺服器所處的位置，以及它與您的目錄通訊的方式。

雲端原生 RADIUS 架構

雲端原生 RADIUS 架構消除了對地端 NPS 或 FreeRADIUS 伺服器的需求。第三方 Cloud RADIUS 提供商透過 Microsoft Graph API 直接與 Microsoft Entra ID 整合，或透過 Google Secure LDAP 或 SAML/OAuth 與 Google Workspace 整合。身分驗證完全在雲端進行。這符合零信任網路存取原則，並能顯著減少營運開銷。

下表比較了兩種主要的架構方法：

EAP-TLS 與 PEAP-MSCHAPv2：關鍵抉擇

EAP 方法的選擇是此部署中最具決定性的安全性決策。PEAP-MSCHAPv2 依賴使用者輸入其網域憑證。這很容易受到憑證竊取和中間人攻擊。如果用戶端裝置沒有嚴格驗證 RADIUS 伺服器憑證 - 許多裝置預設不會進行驗證 - 攻擊者就可以部署一個帶有您的 SSID 的惡意存取點，攔截 EAP 握手並擷取憑證。這就是「邪惡雙生仔」（Evil Twin）攻擊，且已有詳盡的文獻記載。

EAP-TLS (Transport Layer Security) 使用安裝在用戶端裝置上的數位憑證進行雙向驗證。用戶端與伺服器均透過密碼學證明其身分。不需要輸入或竊取密碼。在 Microsoft 環境中，憑證會透過 Microsoft Intune，使用 SCEP (Simple Certificate Enrollment Protocol) 或 PKCS 設定檔，在背景靜默部署。這是所有新部署的推薦路徑，且對於符合 PCI-DSS v4.0（關於強式驗證的要求 8.3）和 GDPR 資料保護義務至關重要。

Google Workspace：架構差異

Microsoft Entra ID 和 Google Workspace 在 RADIUS 整合方面有一個重要的不同之處。Microsoft NPS 原生與 Active Directory 整合，而 Cloud RADIUS 提供商則透過 Microsoft Graph API 連線到 Entra ID。然而，Google 並不提供原生 RADIUS 服務。您始終需要一個中介。 Google Secure LDAP 是主要的整合路徑。此服務適用於 Cloud Identity Premium 和 Google Workspace Enterprise 版本，為您的雲端目錄提供傳統的 LDAP 介面。您的 Cloud RADIUS 伺服器會使用 Google 為您產生的用戶端憑證，透過連接埠 636 連線至 ldap.google.com。從此步驟開始，RADIUS 伺服器會查詢 Google 的目錄以驗證憑證或群組成員身份，就如同查詢內部部署的 Active Directory 一樣。

另一種替代路徑是使用基於 SAML 的整合，其中 Cloud RADIUS 供應商在 Google 管理控制台中註冊為 SAML 應用程式，並在驗證時執行 OAuth 查詢，以即時驗證使用者的身分和群組成員身份。

實作指南

實作支援 EAP-TLS 的 RADIUS-as-a-Service 需要協調身分識別、裝置管理和網路基礎架構。以下五個階段的方法同時適用於 Microsoft Entra ID 和 Google Workspace 環境。

階段 1：準備身分識別與裝置管理基礎架構

針對 Microsoft Entra ID：請確認您的租戶擁有 Microsoft 365 E3/E5 或 Enterprise Mobility + Security (EMS) E3/E5 授權。這包括 Microsoft Intune 和條件式存取。若沒有 Intune，將無法執行自動化憑證部署。

針對 Google Workspace：請確認您擁有 Cloud Identity Premium 或 Google Workspace Enterprise，以存取 Google Secure LDAP。如果您計劃在受管理的 Chromebook 上使用 EAP-TLS，請確保已設定 Google 管理控制台以管理裝置憑證。

建立您的公開金鑰基礎建設 (PKI)。對於新部署，強烈建議使用 Cloud RADIUS 廠商提供的雲端原生 PKI。其他替代方案包括 Microsoft Cloud PKI (隨附於 Intune Suite 授權) 或透過 Microsoft Intune 憑證連接器連線的現有內部部署 ADCS 部署。

階段 2：設定憑證部署

Microsoft Intune 路徑：在 Intune 系統管理中心中，建立 受信任的憑證 組態設定檔。上傳根 CA 憑證並將其部署至您的目標裝置群組。這可確保用戶端裝置信任 RADIUS 伺服器在 TLS 握手期間提供的憑證。接下來，建立 SCEP 憑證 設定檔。針對基於使用者的驗證，將主體名稱設為 CN={{UserPrincipalName}}。針對基於裝置的驗證，使用 CN={{DeviceName}}。將主體替代名稱設定為包含使用者主體名稱或裝置 ID。

Google 管理控制台路徑：導覽至「裝置」，接著到「網路」，然後到「憑證」。上傳您的根 CA。設定憑證發行機制 - 可以是支援與 Google Workspace 進行 SCEP 整合的雲端 PKI，或是將要求代理傳送至內部部署 Microsoft 憑證授權單位的 Google Cloud 憑證連接器。將根 CA 和用戶端憑證設定檔部署到相應的組織單位。

階段 3：設定 Cloud RADIUS 整合

在您的目錄租戶中授予 Cloud RADIUS 提供商所需的 API 權限。對於 Entra ID，這需要至少透過 Microsoft Graph API 取得 User.Read.All 和 GroupMember.Read.All。某些提供商還需要 Device.Read.All 以進行裝置合規性檢查。對於透過安全 LDAP 進行的 Google Workspace，請從 Google 管理控制台下載用戶端憑證和金鑰，並將其安裝在 RADIUS 服務上。

在 Cloud RADIUS 管理入口網站中定義您的驗證原則。適用於企業環境且結構良好的原則為：「如果憑證是由 [Trusted CA] 核發，且使用者為 [Corporate-WiFi-Users] 群組的成員，且裝置在 Intune 中被標記為合規，則允許存取。」這將同時強制執行身分識別、群組成員資格和裝置健康狀況。

步驟 4：設定無線基礎設施

在您的無線 LAN 控制器或雲端管理儀表板 - Cisco Meraki、HPE Aruba、Ruckus、Juniper Mist、Ubiquiti UniFi、Cambium、Extreme 或 Fortinet - 中，將 Cloud RADIUS 伺服器 IP 位址和共用秘密新增為 RADIUS 驗證伺服器。設定主要和次要伺服器以進行備援。將 RADIUS 逾時設定為至少五秒，以適應雲端來回延遲。

建立一個設定為 WPA2-Enterprise 或 WPA3-Enterprise 的新 SSID。對於 飯店 部署，請確保企業 SSID 與任何 Guest WiFi 網路位於不同的 VLAN 上。對於 零售 環境，請考慮僅在後台區域部署企業 SSID。

步驟 5：透過 MDM 部署 WiFi 設定檔

Microsoft Intune：建立 WiFi 組態設定檔。將 SSID 設定為與您的基礎設施設定完全一致。選擇 WPA2-Enterprise 或 WPA3-Enterprise。在 EAP 設定下，選擇 EAP-TLS。將 SCEP 憑證設定檔連結為用戶端憑證，並指定「受信任的根 CA」設定檔。將此 WiFi 設定檔指派給接收憑證設定檔的相同裝置群組。裝置會在下一次 Intune 同步期間，靜默接收憑證和 WiFi 設定。

Google 管理控制台：導覽至「裝置」，接著是「網路」，然後是「Wi-Fi」。建立新的 WiFi 網路設定檔。設定 SSID，選擇 WPA3-Enterprise，選擇 EAP-TLS，然後將受信任的根 CA 憑證推送到裝置。將此設定檔套用到您的組織單位。Chromebook 會靜默且安全地連線。

最佳實踐

在所有新部署中強制執行 EAP-TLS。 請勿使用 PEAP-MSCHAPv2 部署新網路。其安全性風險已記錄在案，且使用現代 MDM 工具的移轉路徑非常簡單。

**強制執行嚴格的伺服器憑證驗證。**如果您必須在舊版裝置上使用 PEAP，請將裝置設定為驗證 RADIUS 伺服器的憑證。在 Intune WiFi 設定檔和 Google Admin Console WiFi 設定檔中，都有一個欄位可以用來指定用於伺服器驗證的受信任 CA。請勿將此欄位留空。這一個設定決定，就是安全部署與易受攻擊部署之間的差別。

**使用動態 VLAN 分配進行網路區隔。**使用您的 RADIUS 伺服器來檢查 Entra ID 或 Google Workspace 中的使用者群組成員資格，並動態將其分配至不同的 VLAN。RADIUS 伺服器會將 Tunnel-Private-Group-Id 屬性傳回給存取點，進而將用戶端置於正確的 VLAN 上。這可以在發生入侵時限制橫向移動，並符合 PCI-DSS 網路區隔的要求。

**將企業與訪客驗證分開。**針對企業託管的裝置使用 EAP-TLS。針對 BYOD 和訪客裝置，則使用結合單一登入（SSO）的 captive portal。嘗試在非託管裝置上以手動方式設定 EAP-TLS 會產生過多的支援開銷。Purple 的 Guest WiFi 平台可分開處理訪客上網流程，維持員工與訪客流量之間的乾淨區隔。

**主動監控憑證過期。**在憑證過期前 90 天、30 天和 7 天設定監控與告警。如果您的 RADIUS 伺服器憑證過期，所有裝置將同時失去連線。在您的 PKI 支援的情況下，請自動執行更新。

**測試 RADIUS 逾時設定。**雲端 RADIUS 會引入地端 NPS 所沒有的網路來回延遲。請將您存取點上的 RADIUS 逾時設定為至少 5 秒。預設設定中常見的 2 秒逾時，將會導致間歇性的驗證失敗。

疑難排解與風險緩釋

遭阻擋的防火牆連接埠是初始部署失敗的首要原因。RADIUS 驗證需要從您的無線基礎架構向外連線至雲端 RADIUS 服務的 UDP 連接埠 1812。RADIUS 計費則需要 UDP 連接埠 1813。在進行任何其他疑難排解之前，請先確認這些連接埠已開放。

憑證驗證失敗會表現為沒有明顯原因的驗證拒絕。請依序檢查以下項目：用戶端與 RADIUS 伺服器上的憑證是否過期；用戶端裝置與 RADIUS 伺服器之間的時鐘偏差（EAP-TLS 依賴精確的時間同步）；以及 Root CA 憑證是否已透過 MDM 成功部署至裝置。

群組成員資格未強制執行是 RADIUS 策略參照 Entra ID 或 Google Workspace 群組時常見的問題。請驗證雲端 RADIUS 供應商是否具有讀取群組成員資格的正確 API 權限。在 Entra ID 中，確認服務主體具有 GroupMember.Read.All。在 Google Workspace 中，確認 Secure LDAP 用戶端具有讀取群組資訊的權限。 VLAN assignment not working typically indicates a mismatch between the RADIUS attribute values and the VLAN IDs configured on the wireless infrastructure. Confirm that Tunnel-Type is set to VLAN (value 13), Tunnel-Medium-Type is set to 802 (value 6), and Tunnel-Private-Group-Id matches the VLAN ID configured on the switch or controller.

BYOD devices failing EAP-TLS usually indicates the client certificate was not successfully deployed. For Intune-managed devices, check the device's certificate store in the Intune admin centre. For Google-managed Chromebooks, verify the certificate profile is assigned to the correct Organisational Unit and that the device has synced recently.

ROI and business impact

Moving to Cloud RADIUS delivers measurable operational savings. On-premise RADIUS requires at minimum two servers for high availability, ongoing OS patching, certificate management, and specialist engineering time. A single engineer's time spent on RADIUS maintenance over a year typically exceeds the annual cost of a Cloud RADIUS subscription.

The business case extends beyond cost reduction. By tying network access to verified cloud identities, you gain:

Instant offboarding. Disabling a user in Entra ID or Google Workspace immediately revokes their network access at all sites. There is no lag, no manual process, and no risk of a former employee retaining WiFi access. This directly supports GDPR obligations around data access rights.

Richer analytics. Platforms like Purple's WiFi Analytics provide richer data on space utilisation and visitor journeys when network access is tied to authenticated identities. You move from anonymous MAC addresses to named, authenticated users, which transforms the quality of insight available to operations and marketing teams.

Compliance evidence. EAP-TLS authentication generates detailed access logs - who connected, from which device, at which location, and at what time. This audit trail supports PCI DSS Requirement 10 (logging and monitoring) and GDPR accountability obligations.

Multi-site consistency. A single Cloud RADIUS service authenticates all your sites with consistent policies, managed from one dashboard. Adding a new hotel, store, or venue means adding its access points to the RADIUS configuration - not shipping and configuring another server. For organisations managing large estates, this is a significant operational advantage.

For Transport operators and Healthcare venues where network uptime is operationally critical, Cloud RADIUS providers typically offer 99.999% uptime SLAs with multi-region failover built in. Purple operates at 99.999% uptime across 80,000+ live venues, with 440 million logins processed in 2024 (Purple internal data, 2024).

若要閱讀更多相關主題的資訊，請參閱 WAN 電腦定義：2026 年實用指南 與 2026 年世界 WiFi 日：您的場地如何協助消除數位落差 。