如何使用 Cloud RADIUS 實作 802.1X 驗證

如何使用 Cloud RADIUS 實作 802.1X 驗證 Purple WiFi 智慧簡報 --- 導言與背景（約 1 分鐘） --- 歡迎來到 Purple WiFi 智慧簡報。我是您的主持人，今天我們將深入探討使用 Cloud RADIUS 進行 802.1X 驗證的細節——它是什麼、為什麼現在很重要，以及如何在多站點資產中實際部署它。 如果您正在為飯店集團、零售連鎖店、體育場或公共部門組織管理 WiFi 基礎架構，這是一個經常被提及的話題——而且理由充分。威脅形勢已經發生變化。共享的 PSK 網路越來越被視為合規性責任，而不僅僅是安全上的不便。監管機構、稽核員和網路保險公司都在對網路存取控制提出更嚴格的問題。好消息是，雲端交付的 RADIUS 已使 802.1X 真正能夠大規模部署，而無需本地基礎架構開銷，這在以前曾使分散式資產的部署變得不切實際。 那麼，讓我們開始吧。 --- 技術深挖（約 5 分鐘） --- 首先，讓我們確保我們都在同一個定義下工作。IEEE 802.1X 是一種基於連接埠的網路存取控制標準。它定義了一個位於 OSI 模型第 2 層的驗證架構——因此它在裝置被授予任何 IP 連線之前運行。這是與應用層驗證的關鍵區別。使用 802.1X，裝置在通過積極驗證之前無法進入網路。 該協定有三個組成部分。用戶端（supplicant）——這是終端裝置，無論是筆記型電腦、智慧型手機還是銷售點終端機。驗證器（authenticator）——通常是您的 WiFi 存取點或您的受管理交換器。以及驗證伺服器（authentication server）——在現代部署中，這就是您的 Cloud RADIUS 服務。 流程是這樣的。裝置嘗試與存取點建立關聯。存取點不會立即授予完整的網路存取權限。相反，它會開啟一個受控連接埠，並與裝置啟動 EAP 交換——這就是可延伸驗證協定。裝置呈現其憑證，這可以是使用者名稱和密碼、數位憑證或基於 SIM 的身分。存取點使用 UDP 上的 RADIUS 協定將該交換轉發到 RADIUS 伺服器，通常在連接埠 1812 用於驗證，1813 用於計費。RADIUS 伺服器根據身分識別存放區（Active Directory、Azure AD 或 LDAP 目錄）驗證憑證，並傳回 Access-Accept 或 Access-Reject 訊息。如果接受，存取點將開啟連接埠，裝置即可獲得網路存取權限。如果拒絕，它將保持受阻狀態。原理很簡單，但實作細節極其重要。 現在，EAP 方法的選擇是許多部署出錯的地方。有幾種常用的 EAP 方法，它們具有非常不同的安全設定檔和營運要求。 EAP-TLS 是黃金標準。它需要雙向憑證驗證——伺服器和用戶端都呈現憑證。這完全消除了憑證被盜的風險，因為沒有密碼可供竊取。但它需要 PKI 基礎架構以及將用戶端憑證推送至裝置的機制，這通常意味著 MDM 解決方案。對於企業 BYOD 環境和高安全性部署，這是正確的答案。 PEAP 搭配 MSCHAPv2 是企業環境中部署最廣泛的方法。它只需要伺服器端憑證，並在 TLS 內封裝憑證交換。它原生與 Active Directory 相容，這使得營運變得簡單。風險在於，如果使用者連線到具有自我簽署憑證的惡意存取點，它很容易受到憑證收集的攻擊——因此用戶端側的憑證驗證是不可妥協的。 EAP-TTLS 與 PEAP 類似，但在內部驗證方法上更具彈性。它在混合裝置環境中特別有用，在這些環境中，您擁有具有不同用戶端能力的 Windows、macOS、iOS 和 Android 裝置的組合。 對於舊型裝置支援——想想較舊的銷售點硬體或物聯網感測器——EAP-FAST 可以是一個務實的選擇，因為它不需要憑證，而是使用受保護的存取憑證（PAC）。 現在，談談 Cloud RADIUS 部分。傳統上，RADIUS 是一項本地服務——Linux 伺服器上的 FreeRADIUS，或 Windows Server 上的 Microsoft NPS。該模型可行，但它具有實際的營運成本：硬體維護、高可用性設定、修補，以及在每個需要低延遲驗證的站點都需要本地基礎架構。Cloud RADIUS 顯著改變了這一計算方式。 Cloud RADIUS 服務由供應商託管和管理。您的存取點透過網際網路將 RADIUS 請求傳送到雲端服務，雲端服務會針對您的身分識別提供者進行驗證。對延遲的擔憂是真實存在的，但可以管理——現代 Cloud RADIUS 服務是全球分散式的，驗證往返通常在 100 毫秒內完成，這對終端使用者來說是察覺不到的。 與身分識別提供者的整合是關鍵的依賴關係。大多數 Cloud RADIUS 平台支援 LDAP、LDAPS、SAML 2.0 以及直接的 Azure AD 或 Okta 整合。對於已經運行 Microsoft 365 的組織，Azure AD 整合是自然而然的途徑——您可以獲得單一登入、條件式存取原則和 MFA 強制執行，所有這些都饋入您的網路存取控制層。 對於在員工網路之外部署客用 WiFi 的場所，該架構通常將這些網路分隔為具有不同驗證原則的獨立 SSID。員工網路使用具有企業憑證的 802.1X。客用網路使用 Captive Portal 或社群登入流程。Purple 的平台支援這兩種模型，且 WiFi 分析層橫跨兩者，讓您能夠在不損害安全分段的情況下，洞察裝置行為、停留時間和網路利用率。 --- 實作建議與陷阱（約 2 分鐘） --- 讓我為您提供實際的部署順序，並指出我最常看到的失敗模式。 首先從您的身分識別提供者整合開始。在您接觸任何單一存取點之前，請確認您的 Cloud RADIUS 服務可以針對您的目錄進行驗證。使用服務帳戶進行測試，驗證 LDAP 綁定，並確認群組成員資格屬性是否正確傳回——因為您將需要這些屬性來進行 VLAN 分配原則。 第二，規劃您的憑證策略。如果您要使用 EAP-TLS，您需要一個 CA，您需要決定是使用公共 CA 還是內部 CA，並且您需要一個用於用戶端憑證的 MDM 推廣計劃。如果您要使用 PEAP，您需要一個來自受信任 CA 的伺服器憑證——而不是自我簽署的——並且您需要將 CA 憑證推送至所有用戶端裝置，以便憑證驗證正常運作。這是最容易被跳過並導致安全事件的步驟。 第三，使用正確的共用金鑰和伺服器 IP 或主機名稱設定您的 RADIUS 用戶端（即您的存取點和控制器）。使用強大的、隨機產生的共用金鑰，而不是字典單字。如果您的 Cloud RADIUS 供應商支援 TLS 上的 RADIUS（即 RadSec），請使用它。它會加密傳輸中的 RADIUS 流量，當該流量穿過公共網際網路時，這一點尤為重要。 第四，在全面推廣之前先與試點小組進行測試。大規模的驗證失敗具有破壞性，且在壓力下很難診斷。使用十到二十台裝置進行試點，驗證驗證記錄，確認 VLAN 分配正常運作，並檢查計費記錄是否已正確寫入。 我最常看到的失敗模式包括：用戶端上停用了憑證驗證，導致中間人漏洞；共用金鑰太短或在各站點間重複使用；未設定 RADIUS 伺服器 IP 允許清單，導致來自新站點的驗證請求被默默丟棄；以及在憑證過期時未更新 MDM 設定檔，導致在更新日發生大規模驗證失敗。 --- 快速問答（約 1 分鐘） --- 一些我經常被問到的問題。 我是否可以在同樣擁有不支援 EAP 的物聯網裝置的網路上運行 802.1X？可以——對於無法運行用戶端的裝置，使用 MAC 驗證繞過作為備用方案，但要將這些裝置放在具有嚴格防火牆規則的受限 VLAN 上。 802.1X 是否取代了 WPA2 或 WPA3 加密？不——802.1X 處理驗證。WPA2-Enterprise 或 WPA3-Enterprise 處理加密。您兩者都需要。對於新部署，支援 802.1X 的 WPA3-Enterprise 是目前的最佳實踐。 驗證的延遲影響是什麼？透過設定良好的 Cloud RADIUS 服務，預計每次驗證需要 50 到 150 毫秒。對於漫遊場景，802.11r 快速 BSS 轉換可以顯著減少重新驗證的開銷。 這是否符合 PCI DSS？在適當分段的網路上使用帶有 EAP-TLS 或 PEAP 的 802.1X 可滿足 PCI DSS 對網路存取控制的要求 1 和要求 8。請儘早讓您的 QSA 參與進來。 --- 總結與後續步驟（約 1 分鐘） --- 總結一下：對於任何需要向稽核員展示網路存取控制、減少憑證遭破解的波及範圍，或在分散式資產中集中管理驗證的組織而言，使用 Cloud RADIUS 的 802.1X 是正確的答案。 部署並非易事，但只要做好充分準備，絕對是可以管理的。首先搞定您的身分識別提供者整合。根據您的裝置資產和管理憑證的營運能力選擇您的 EAP 方法。如果您的基礎架構支援，請使用 RadSec。並在大規模推廣之前進行測試。 如果您正在運行混合的客用和員工網路（大多數餐旅和零售營運商都是如此），像 Purple 這樣的平台可以讓您從單一控制台管理這兩種驗證模型，且分析層橫跨整個資產。 對於您的後續步驟：稽核您目前的網路存取控制狀況，識別哪些站點仍在運行共享 PSK，並制定分階段遷移計劃。從風險最高的站點（屬於 PCI DSS 範圍或處理敏感資料的站點）開始，然後向外擴展。 感謝您的收聽。更多技術簡報可在 purple.ai 取得。