跳至主要內容

如何為 WiFi 驗證設定 RADIUS 伺服器

這份具權威性的指南為 IT 主管與網路架構師提供了部署企業級 WiFi 驗證 RADIUS 伺服器的完整藍圖。內容涵蓋了在地端與雲端託管部署之間的架構權衡、EAP 方法選擇、Active Directory 整合以及動態 VLAN 分配。場域營運商與 IT 團隊將獲得具體的實作步驟、真實案例研究與風險緩解策略,以便在木季從不安全的 PSK 環境過渡到強固的 802.1X 基礎架構。

📖 8 分鐘閱讀📝 532 字數🔧 2 範例3 練習題📚 9 關鍵定義

收聽此指南

查看播客逐字稿
歡迎來到 Purple 的技術簡報。今天我們要探討的是任何企業 IT 領導者都必須面對的關鍵基礎架構決策:如何為 WiFi 驗證設定 RADIUS 伺服器。如果您正在管理大規模的部署 - 無論是連鎖酒店、零售網路還是龐大的大學校園 - 依賴簡單的預共用金鑰都是重大的安全風險。我們需要 802.1X,這意味著我們需要 RADIUS。 首先讓我們來了解背景脈絡。RADIUS(遠端使用者撥入驗證服務)扮演著您網路的守門人角色。當裝置嘗試連接到 WiFi 存取點(AP)時,該存取點會作為驗證器,並將憑證轉發給 RADIUS 伺服器。伺服器會比對目錄(例如 Active Directory 或 LDAP 資料庫)來檢查這些憑證,然後返回接受或拒絕的訊息。它是企業級 WiFi 安全的基石,也是讓您能夠在大規模環境下實施細粒度存取策略的機制。 現在讓我們進入技術深潛。您將面臨的第一個主要架構決策,是在地端(On-premise)RADIUS 伺服器與雲端託管解決方案之間做出選擇。在過去,地端解決方案(如 Microsoft 的網路原則伺服器 NPS,或開源的 FreeRADIUS)是業界標準。它們提供對基礎架構的完全控制,且驗證時不依賴外部網路連線。然而,它們需要專用硬體、持續維護以及手動設定備援。如果您擁有單一資料中心和編制完善的 IT 團隊,這是一個完全可行的方法。 另一方面,雲端 RADIUS 解決方案已變得越來越受歡迎,特別是對於零售連鎖店或餐旅場所等分散式環境。雲端 RADIUS 完全免除了硬體管理的負擔,提供內建的高可用性,並與 Azure Active Directory 或 Okta 等雲端身分識別提供者無縫整合。權衡之處在於,驗證需要可靠的網路連線,且會產生持續的訂閱費用。對於管理 50 個或 100 個據點的場域營運商而言,因無需在每個站點部署和維護地端伺服器所節省的營運成本,幾乎肯定會超過該訂閱費用。 在部署 RADIUS 時,可延伸驗證協定 - EAP - 是關鍵的核心。它定義了用戶端與伺服器如何進行交涉並執行驗證。EAP-TLS 是安全性方面的黃金標準,因為它在用戶端和伺服器上都使用數位憑證,完全免除了密碼的需求。這意味著即使攻擊者攔截了驗證交換過程,也沒有憑證可供竊取。然而,部署用戶端憑證在管理上可能會很沉重。您需要公開金鑰基礎架構(PKI)和 MDM 解決方案,才能將憑證推送到每台裝置。 PEAP-MSCHAPv2 是最常見的替代方案。它使用伺服器端憑證來建立加密的 TLS 通道,使用者在通道內使用帳號和密碼進行驗證。這比 EAP-TLS 更容易部署,因為您只需要管理一個憑證 - 即伺服器的憑證。然而,這點至關重要 - 如果用戶端沒有嚴格設定為驗證伺服器的憑證,它們就容易受到惡意存取點的攻擊。攻擊者可以架設虛假存取點,出示欺詐性憑證,並擷取認證資訊。這不是理論上的攻擊。這是已有詳盡記錄的真實世界威脅。 讓我們來談談實作建議和陷阱。第一個建議是在每個用戶端裝置上實施嚴格的憑證驗證。對 Windows 裝置使用群組原則物件,對 macOS 和行動裝置使用 MDM 設定檔(無論是 Intune、Jamf 還是其他解決方案)。該設定檔必須準確指定要信任哪個憑證授權單位,以及預期的伺服器名稱是什麼。不要留給終端使用者手動設定。 第二個建議是實作動態 VLAN 分配。不要將所有已驗證的使用者放在同一個扁平網路中,而是設定 RADIUS 伺服器,指示存取點根據使用者在目錄中的群組成員身分將其置於特定的 VLAN。這對於將公司裝置與 BYOD 或訪客裝置進行區隔至關重要。財務團隊的員工應該與當天來訪的承包商處於不同的網路區段。 第三個建議涉及訪客存取。對於需要向訪客提供 WiFi 的場所(飯店、零售店、會議中心),將您的 RADIUS 架構與 Captive Portal 解決方案(例如 Purple 的 Guest WiFi 平台)相結合是一個強大的組合。員工和公司裝置透過 802.1X 進行無感驗證,而訪客則被引導至品牌入口網頁進行驗證。Purple 的平台隨後會收集第一方數據,並提供訪客行為分析,將您的網路從成本中心轉變為商業智慧資產。 現在進入快速問答環節。第一個問題:我需要為 RADIUS 準備專用伺服器嗎?對於地端部署,是的,強烈建議在專用的虛擬機上運行,而不是與網域控制站共享資源。驗證是高度敏感於延遲的作業,資源競爭可能會導致難以診斷的間歇性故障。第二個問題:RADIUS 可以處理印表機或 IoT 感測器等無介面設備(headless devices)的驗證嗎?可以,透過 MAC 驗證繞過(MAC Authentication Bypass),即 MAB。這允許不具備 802.1X 功能的設備根據其 MAC 位址進行驗證。然而,由於 MAC 位址很容易被偽造,通過 MAB 驗證的設備應始終放置在高度受限的 VLAN 中。第三個問題:我該如何處理 RADIUS 伺服器的備援?請務必部署至少兩台 RADIUS 伺服器 - 主伺服器與備用伺服器。配置所有無線基地台,以便在無法連線到主伺服器時,容錯移轉至備用伺服器。對於雲端 RADIUS,這種備援通常已內建並由供應商管理。 總結今天簡報的重點:預共用金鑰不適用於企業級 WiFi。請實施 802.1X。根據您的 IT 資源、管理的據點數量以及現有的身分識別基礎架構,選擇您的部署模式 - 地端或雲端。如果您是分佈式且雲端優先的架構,雲端 RADIUS 幾乎無疑是正確的選擇。在用戶端上強制執行嚴格的憑證驗證,這是不可妥協的。使用動態 VLAN 分配來實行網路分段。最後,思考您的驗證基礎架構如何與更廣泛的平台整合,以提供超越單純控制存取的商業價值。 如需進一步閱讀,我們建議參閱 Purple 關於配置 802.1X WiFi 驗證以及利用強效 DNS 策略保護網路安全的指南。感謝您的收聽。

📚 核心系列的一部分:Enterprise WiFi Security Guide

header_image.png

執行摘要

對於企業環境而言 - 無論是廣闊的大學校園、高密度的體育場館,還是分散的連鎖零售店 - 依賴預共用金鑰 (PSK) 進行 WiFi 存取都是重大的安全隱患。單一憑證遭破解就會暴露整個網路,且撤銷存取權限需要更改該區域內每台裝置的密碼。透過 RADIUS (遠端用戶撥入驗證服務) 伺服器實施 802.1X 驗證可完全解決此問題:每個使用者進行獨立驗證、可立即撤銷存取權限,並動態執行網路分段。

本指南為 IT 經理和網路架構師部署 RADIUS 驗證提供了明確的藍圖。我們涵蓋了地端與雲端託管部署之間的架構權衡、可延伸驗證協定 (EAP) 方法的設定,以及與 Active Directory 等目錄服務的整合。我們還展示了強大的驗證層如何與 Guest WiFi 解決方案整合,為訪客提供無縫存取,同時擷取能將您的網路轉化為商業智慧資產的 WiFi Analytics


技術深入探討

802.1X 架構

IEEE 802.1X 標準定義了基於連接埠的網路存取控制 (PNAC)。在無線網路環境中,它涉及三個協同工作的核心角色:

角色 元件 職責
Supplicant (用戶端) 用戶端裝置 (筆記型電腦、智慧型手機) 提供憑證以請求網路存取
Authenticator (驗證器) WiFi 存取點 (AP) 或控制器 執行存取控制;轉發 EAP 訊息
Authentication Server (驗證伺服器) RADIUS 伺服器 驗證憑證;傳回接受/拒絕和原則屬性

當用戶端與存取點建立關聯時,AP 會阻擋除 EAP (可延伸驗證協定) 訊息之外的所有資料流量。AP 將這些 EAP 訊息封裝在 RADIUS 封包中,並將其轉發給 RADIUS 伺服器。伺服器根據後端資料庫 (通常是 LDAP 或 Active Directory) 驗證憑證,並傳回 Access-AcceptAccess-Reject 訊息。如果接受,AP 將解除連接埠阻擋,用戶端的流量即可自由流動。

architecture_overview.png

選擇 EAP 方法

RADIUS 部署的安全強度很大程度上取決於所選擇的 EAP 方法。企業部署中最常見的兩種方法是:

EAP-TLS (Transport Layer Security) 是黃金標準。它需要在 RADIUS 伺服器和每台用戶端裝置上安裝數位憑證,從而完全免除密碼。即使攻擊者擷取了完整的驗證互動,也沒有可以提取的認證資料。折衷之處在於管理開銷:部署與管理用戶端憑證需要運作正常的公開金鑰基礎建設 (PKI) 以及 MDM 解決方案(例如 Microsoft Intune、Jamf)來將憑證發布到端點。

PEAP-MSCHAPv2 (Protected EAP) 是實務中部署最廣泛的方法。它使用伺服器端憑證來建立加密的 TLS 通道,用戶端在該通道內使用使用者名稱和密碼進行驗證。這比 EAP-TLS 容易部署得多,因為只需要管理一個憑證(即伺服器的憑證)。然而,這帶來了一個關鍵的警告:如果用戶端裝置未被明確設定為驗證 RADIUS 伺服器的憑證,它們很容易受到透過惡意存取點進行的中間人 (MitM) 攻擊。

關鍵安全性說明:未能對用戶端裝置強制執行嚴格的憑證驗證,實際上會使 PEAP-MSCHAPv2 的安全性優勢蕩然無存。攻擊者可以部署惡意 AP、提供欺詐憑證,並以明文形式擷取使用者認證資料。這不是理論上的風險 - 這是一個在現實環境中已被利用、記錄完善的攻擊途徑。


實作指南

步驟 1:架構決策 - 本地部署 vs. 雲端 RADIUS

第一個決策是將 RADIUS 基礎建設託管在哪裡。這主要是營運和成本問題,而不是安全性問題 - 兩種模式都可以安全地部署。

comparison_chart.png

本地部署 RADIUS(例如 Microsoft NPS、FreeRADIUS、Cisco ISE)適用於擁有專職 IT 人員、現有本地目錄基礎建設以及嚴格的資料主權或合規性要求的組織。它不依賴網路連線進行驗證,這對於無法保證網路正常運作時間的環境來說是一個顯著的優勢。

對於分佈式環境 - 像是 零售 連鎖店、 旅宿 集團和 交通 樞紐等在每個位置部署伺服器在營運上不切實際的環境,雲端 RADIUS 越來越成為首選模式。雲端 RADIUS 與雲端身分識別提供者(Azure AD、Google Workspace、Okta)原生整合,並提供內建的高可用性和全球擴充性。

步驟 2:安裝並設定 RADIUS 伺服器

對於使用 Microsoft NPS(以 Windows 為中心的環境中最常見的選擇)的本地部署:

  1. 透過伺服器管理員安裝網路原則伺服器角色。
  2. 在 Active Directory 中註冊 NPS 伺服器,以允許其讀取使用者撥入屬性。
  3. 為每個無線基地台或無線控制器建立 RADIUS Client 項目,並指定 AP 的 IP 地址和強大且唯一的共用金鑰 (Shared Secret)。
  4. 設定 網路原則 (Network Policy),定義存取的條件 (例如,使用者群組成員身份) 和限制 (例如,EAP 方法、工作階段逾時)。
  5. 設定 連線要求原則 (Connection Request Policy) 以在本機處理要求。

對於 Linux 上的 FreeRADIUS

  1. 透過套件管理員安裝:sudo apt-get install freeradius freeradius-ldap
  2. 設定 /etc/freeradius/3.0/clients.conf 以定義 RADIUS 用戶端 (AP) 及其共用金鑰。
  3. 設定 /etc/freeradius/3.0/mods-available/ldap 中的 LDAP 模組,使其指向您的 Active Directory 或 LDAP 伺服器。
  4. 啟用 LDAP 模組:sudo ln -s /etc/freeradius/3.0/mods-available/ldap /etc/freeradius/3.0/mods-enabled/
  5. /etc/freeradius/3.0/mods-available/eap 中定義 EAP 方法。

步驟 3:設定無線基地台

在您的無線控制器或個別無線基地台上:

  1. 定義 RADIUS 伺服器 IP 地址和驗證連接埠 (預設:UDP 1812)。
  2. 設定 共用金鑰 (Shared Secret) - 使用至少 22 個字元,混合字母、數字和特殊字元。每個位置或 AP 群組使用唯一的金鑰。
  3. 將 SSID 設定為使用具有 802.1X 金鑰管理的 WPA2-Enterprise 或 WPA3-Enterprise 安全性模式。
  4. 設定次要 RADIUS 伺服器以進行容錯移轉。

步驟 4:目錄整合

對於內部部署的 AD 整合,RADIUS 伺服器必須加入網域或具有 LDAP 讀取權限。確保用於 LDAP 繫結的服務帳戶具有所需的最低權限。對於雲端 RADIUS,請設定與您的 IdP 進行基於 API 的同步或 SAML/OIDC 整合。

在您的目錄中定義明確的使用者群組,因為這些群組將驅動授權原則。建議的群組結構:

群組 VLAN 存取權限層級
Corp_Staff VLAN 10 完整內部網路
Corp_Contractors VLAN 20 網際網路 + 特定內部資源
Corp_IoT VLAN 30 僅限隔離的、裝置專屬的連接埠
Corp_Guests VLAN 100 僅限透過 Captive Portal 存取網際網路

步驟 5:用戶端設定與憑證驗證

這是營運上最關鍵的步驟。使用 Windows 的群組原則 (GPO) 以及 macOS/iOS/Android 的 MDM 設定檔,將 WiFi 設定自動推送到受管裝置。該設定檔必須指定:

  • 發行 RADIUS 伺服器憑證的 Root CA
  • 預期的伺服器名稱 (伺服器憑證的 CN 或 SAN)。
  • EAP 方法和內部驗證協定。

對於非受管的 BYOD 裝置,請提供明確的自助註冊說明,最好是透過網路存取控制 (NAC) 入口網站。

步驟 6:實作動態 VLAN 分配

設定 RADIUS 伺服器以在 Access-Accept 回應中傳回 VLAN 分配屬性:

  • Tunnel-Type = VLAN (13)
  • Tunnel-Medium-Type = IEEE-802 (6)
  • Tunnel-Private-Group-Id = <VLAN ID>

無線基地台會讀取這些屬性,並將已通過驗證的用戶端置於指定的 VLAN 中 - 當使用者變更角色或位置時,無需手動重新設定。


最佳實踐

容錯移轉是不可妥協的。 部署至少兩台 RADIUS 伺服器(主要和次要),並將所有無線基地台設定為自動進行容錯移轉。對於本地部署,請考慮將次要伺服器放置在不同的實體位置或可用區。RADIUS 服務中斷意味著沒有人可以進行驗證,這對受 802.1X 保護的 SSID 來說是完全的網路中斷。

主動監控憑證過期。 RADIUS 伺服器憑證過期是導致突然、大規模驗證失敗最常見的原因之一。實施監控以在過期前至少 30 天提醒管理員。這適用於伺服器憑證以及鏈中的任何中繼 CA 憑證。

將共用金鑰視為關鍵認證憑據。 AP 與 RADIUS 伺服器之間的共用金鑰用於加密 RADIUS 封包。請為每個位置或 AP 群組使用唯一的共用金鑰,將其儲存在金鑰管理器中,並定期進行輪替。請參閱我們的 透過強大的 DNS 和安全性保護您的網路 指南,以獲取更廣泛的網路安全衛生建議。

符合合規架構。 對於受 PCI DSS 約束的環境(例如零售支付網路),802.1X 驗證直接支援網路存取控制和稽核記錄的要求。為了符合 GDPR,RADIUS 記帳記錄(連接埠 1813)提供了誰在何時何地存取網路的詳細稽核追蹤 - 這對於事件回應非常有用。對於 醫療保健 環境,透過動態 VLAN 分配進行網路分割支援 HIPAA 保護電子受保護健康資訊 (ePHI) 的要求。


疑難排解與風險緩釋

失敗模式 徵兆 解決方案
憑證過期 突然發生大規模驗證失敗 監控過期情況;更新並重新部署憑證
NTP 時間不同步 間歇性 EAP-TLS 失敗 確保 RADIUS 伺服器和網域控制站 (DC) 同步到相同的 NTP 來源
LDAP 連線中斷 無法存取 AD 時驗證失敗 部署備份網域控制站;設定 RADIUS 快取最近的驗證
共用金鑰不正確 AP 記錄顯示 RADIUS timeoutBad authenticator 驗證 AP 和 RADIUS 伺服器上的共用金鑰是否一致
用戶端憑證不符合 特定裝置的 EAP-TLS 失敗 驗證用戶端憑證是否由信任的 CA 核發;檢查憑證有效期
未分配 VLAN 使用者已通過驗證,但處於錯誤的網路區段 驗證 RADIUS 屬性是否正確傳回;檢查 AP VLAN 設定
若要深入瞭解 802.1X 設定程序本身, 如何設定 802.1X WiFi 驗證:逐步指南 提供了詳盡且針對特定廠商的設定逐步說明。

投資報酬率與企業影響

從 PSK 轉換至以 RADIUS 為基礎的 802.1X 需要在設定上進行初期投資,並可能涉及雲端解決方案的授權或地端部署的硬體費用。其投資報酬率分析非常直觀:

降低風險:英國資料外洩的平均成本超過 300 萬英鎊(根據 IBM 資料外洩成本報告)。一個遭到破解的 PSK 可能會使整個網路暴露在風險中。802.1X 將受波及範圍限制在單一被破解的使用者帳戶,且該帳戶可在數秒內透過目錄服務予以停用。

營運效率:動態 VLAN 分配消除了因員工職務變更而需要手動重新設定網路的麻煩。新員工入職只需將其加入正確的 AD 群組 - 網路存取權限便會自動跟隨套用。

合規態勢:對於須遵守 PCI-DSS、ISO 27001 或 Cyber Essentials Plus 的企業組織而言,802.1X 是稽核人員預期會看到的直接控制措施。部署此措施可強化您的合規態勢並降低稽核改善成本。

訪客體驗與數據分析:對於場域營運商而言,將用於員工驗證的 RADIUS 與用於訪客存取的 Purple Guest WiFi 平台整合,可建立一個統一的分層存取模型。員工透過 802.1X 進行無感驗證;訪客則透過品牌專屬的 Captive Portal 連線。接著,Purple 的 WiFi Analytics 平台便能即時呈現訪客停留時間、回訪率及互動指標等數據 - 這些數據將直接為行銷支出與場域營運決策提供依據。


延伸閱讀請參閱 Como Configurar a Autenticação 802.1X WiFi: Um Guia Passo a Passo 取得葡萄牙語的實作指引,以及 什麼是專線?企業專用網際網路 取得關於確保基礎連線能力符合企業需求的指引。

關鍵定義

RADIUS (Remote Authentication Dial-In User Service)

一種網路協定,為連接到網路服務的使用者提供集中式的驗證、授權和計費 (AAA) 管理。定義於 RFC 2865。

在授予 WiFi 存取權限之前,對照目錄驗證使用者憑證的核心伺服器組件。每個使用 802.1X 的企業 WiFi 部署都需要 RADIUS 伺服器。

802.1X

一項針對基於連接埠的網路存取控制 (PNAC) 的 IEEE 標準。它為希望連接到 LAN 或 WLAN 的裝置提供驗證機制,在驗證成功之前,阻擋所有非 EAP 流量。

定義 Supplicant、Authenticator 與 Authentication Server 之間如何進行通訊的整體架構標準。當 IT 團隊提到「企業級 WiFi 安全性」時,他們通常指的是搭配 802.1X 的 WPA2/WPA3-Enterprise。

Supplicant

用戶端裝置 - 或更準確地說,是該裝置上的 802.1X 軟體堆疊 - 藉由向網路出示憑證來啟動驗證程序。

在 Windows 上,內建的 supplicant 是 Wireless AutoConfig 服務。在 macOS 和 iOS 上,它是作業系統原生的。確保 supplicant 設定正確(特別是針對憑證驗證)是部署問題中最常見的根源。

Authenticator

網路裝置 - 通常是 WiFi 存取點或無線控制器 - 充當 Supplicant 和 RADIUS 伺服器之間的媒介,並根據驗證結果執行存取控制。

AP 會阻擋該連接埠上的所有數據流量,直到收到來自 RADIUS 伺服器的 Access-Accept。它還會從 Access-Accept 回應中讀取 RADIUS 屬性(例如 VLAN 分配)並將其套用於該工作階段。

EAP (Extensible Authentication Protocol)

定義於 RFC 3748 的驗證架構,為 Supplicant 與 Authentication Server 之間的各種驗證方法(TLS、PEAP、TTLS 等)提供標準化的傳輸機制。

EAP 是用戶端與 RADIUS 伺服器之間「溝通的語言」。EAP 方法(EAP-TLS 與 PEAP)的選擇決定了驗證系統的安全強度和部署複雜度。

PEAP (Protected EAP)

一種 EAP 方法,首先使用伺服器憑證建立 TLS 通道,然後在該加密通道內進行二次驗證(通常是搭配使用者名稱/密碼的 MSCHAPv2)。

由於其在安全性和部署簡易性之間取得了平衡,因此是最常見的企業級 WiFi 驗證方法。僅需要伺服器端憑證,這使得它比 EAP-TLS 更容易推廣部署。

Dynamic VLAN Assignment

一種 RADIUS 功能,伺服器在 Access-Accept 回應中包含特定 VLAN 的屬性(Tunnel-Type、Tunnel-Medium-Type、Tunnel-Private-Group-Id),指示 AP 將已驗證的用戶端置於特定的 VLAN 上。

使單一 SSID 能夠為具有不同安全性需求的多個使用者群體提供服務。無需為不同的使用者群組廣播多個 SSID,從而減少射頻開銷並簡化使用者體驗。

Shared Secret

僅有 Authenticator (AP) 和 RADIUS 伺服器知道的預先設定文字字串,用於對 RADIUS 封包進行簽章和加密,以確保通訊的完整性和真實性。

關鍵的安全設定要素。如果共用金鑰強度不足或遭到破解,攻擊者可能會偽造 RADIUS Access-Accept 回應,從而授予未授權的網路存取權限。請為每個位置使用專屬的唯一金鑰,並將其儲存在金鑰管理器中。

MAC Authentication Bypass (MAB)

一種備用驗證機制,將裝置的 MAC 位址用作其身分憑證,從而為不支援 802.1X supplicant 的裝置啟用網路 survival 存取。

用於無螢幕裝置(印表機、IoT 感測器、IP 攝影機)。由於 MAC 位址公開可見且易於偽造,因此 MAB 提供的是裝置識別而非強效驗證。請務必搭配限制性的 VLAN 分配。

範例

一家擁有 500 家分店的連鎖零售商需要為店長平板電腦和 POS 終端機實施安全的 WiFi。他們目前在所有商店中使用單一的 PSK,該密碼經常被分享給未授權的員工和承包商。他們使用 Azure AD 進行身分識別管理,且各分店沒有編制專職的 IT 人員。

部署與 Azure AD 直接整合的 Cloud RADIUS 解決方案。這免除了在 500 個據點部署和管理地端 RADIUS 伺服器的需求。IT 團隊使用 Microsoft Intune 將配置了 PEAP-MSCHAPv2 的 WiFi 設定檔推送到所有店長平板和 POS 終端機,嚴格強制執行 Cloud RADIUS 伺服器憑證的驗證。Cloud RADIUS 策略在授予存取權限前,會先檢查使用者的 Azure AD 群組成員身分:「Store_Managers」群組分配到 VLAN 10(完整的 POS 與後台存取權限),「Contractors」群組分配到 VLAN 20(僅限網際網路)。當承包商的合約結束時,將其從 Azure AD 群組中移除即可立即同時撤銷其在所有 500 個據點的 WiFi 存取權限 - 無需更改 PSK。

考官評語: 此方法解決了核心安全性弱點(共用 PSK),同時考慮到了營運上的限制(分店無 IT 人員、Azure AD 環境)。Cloud RADIUS 提供了所需的擴充性,並與現有的識別提供者原生整合。使用動態 VLAN 分配可確保即使承包商的裝置在合約結束後仍留在現場,也只需從目錄群組中移除該成員,即可完成撤銷存取權限的唯一操作。

一家擁有 400 間客房的市中心飯店需要為員工(前台、房務、管理層)和顧客提供安全的 WiFi。員工需要存取物業管理系統(PMS)和內部伺服器。顧客則僅需要網際網路連線。該飯店擁有一套單一的地端 Windows Server 環境。

在專用的 Windows Server 虛擬機器上部署 Microsoft NPS。在無線基礎架構上設定兩個 SSID:「Hotel_Staff」(WPA2-Enterprise802.1X)和「Hotel_Guest」(開放式或 WPA2-Personal,重新導向至 Captive Portal)。針對員工 SSID,NPS 會對照 Active Directory 驗證認證,並傳回動態 VLAN 分配:「Management」AD 群組 → VLAN 10(完整存取權限),「FrontDesk」 → VLAN 20(PMS 存取權限),「Housekeeping」 → VLAN 30(僅限網際網路 + 排班應用程式)。針對顧客,將 Captive Portal 與 Purple 的 Guest WiFi 平台整合,以提供品牌專屬的登入體驗、收集第一方數據(電子郵件、行銷同意書),並獲取關於停留時間和回訪次數的分析數據。雙 SSID 模式可將員工與顧客的流量在網路層上完全隔離。

考官評語: 在這種情況下,雙 SSID 模式是正確的方法,而非採用單一 SSID 配合複雜的策略路由。它提供了清晰的營運隔離並簡化了疑難排解。針對顧客 SSID 整合 Purple 是商業上的明智決定:它將顧客網路從成本中心轉化為數據收集與行銷管道,透過回訪率和電子郵件行銷參與度帶來可衡量的投資報酬率。

練習題

Q1. 您的組織正在將 2,000 台 Windows 筆記型電腦從共享的 PSK 遷移到採用 PEAP-MSCHAPv2 的 802.1X。您的安全性團隊指出,PEAP 容易受到透過惡意存取點進行憑證收集的攻擊。要降低此風險,最重要的一個設定步驟是什麼?您又該如何進行大規模部署?

提示:思考是什麼防止了用戶端去信任出示自我簽署憑證的欺詐性 RADIUS 伺服器。

查看標準答案

關鍵步驟是在每個用戶端裝置上強制執行嚴格的伺服器憑證驗證。使用群組原則物件 (GPO),將一個 WiFi 設定檔推送到所有 2,000 台筆記型電腦,該設定檔需指定:(1) 核發 RADIUS 伺服器憑證的確切根 CA 憑證,(2) 預期的伺服器名稱 (CN/SAN),以及 (3) 用戶端絕對不能提示使用者信任新憑證。這能確保即使攻擊者部署了帶有偽造憑證的惡意 AP,用戶端也會拒絕 TLS 握手並拒絕傳送憑證。若沒有此設定,PEAP 無法針對惡意 AP 攻擊提供任何實質保護。

Q2. 醫院 IT 總監需要為 300 台不支援 802.1X 的醫療 IoT 裝置(輸液幫浦、監測設備)提供網路存取權。這些裝置與員工工作站位於同一個無線基礎架構上。RADIUS 基礎架構應如何處理這些裝置?且必須部署哪些網路控制措施?

提示:思考一下無螢幕 (headless) 裝置可用的驗證方法,以及如何彌補其固有的弱點。

查看標準答案

在 RADIUS 伺服器上為這些特定裝置設定 MAC 驗證旁路 (MAB)。將每個裝置的 MAC 位址註冊在專用的 Active Directory 群組或 RADIUS 資料庫中。由於 MAC 位址極易被偽造,RADIUS 伺服器必須使用動態 VLAN 分配,將所有通過 MAB 驗證的裝置放入專用且高度受限的 VLAN(例如 VLAN 30 - IoT)。此 VLAN 應設置防火牆,僅允許與特定的醫療伺服器 IP 位址通訊,並阻擋所有其他流量(包括網際網路存取以及向員工 VLAN 的橫向移動)。員工工作站則透過 802.1X 進行驗證並放入獨立的 VLAN。此架構符合 HIPAA 對 ePHI 相關裝置的網路隔離要求。

Q3. 您是一家擁有 50 家分店的連鎖餐廳的網路架構師。使用 Cloud RADIUS 時,有 49 家分店的驗證運作正常,但有一家特定的分店回報所有裝置皆無法驗證。Cloud RADIUS 管理入口網站顯示,來自該分店的驗證請求數量為零。您的診斷方法為何?

提示:如果 RADIUS 伺服器完全沒有收到任何請求,問題出在驗證器 (Authenticator) 與伺服器之間的通訊路徑上,而非驗證邏輯本身。

查看標準答案

由於 RADIUS 伺服器收到來自該分店的請求數為零,故障點位於存取點與 Cloud RADIUS 伺服器之間。診斷步驟依序為:(1) 驗證在該分店的 AP 或無線控制器上設定的 RADIUS 伺服器 IP 位址與連接埠 (UDP 1812) - 此處輸入錯誤是最常見的原因。(2) 檢查該分店的本地防火牆或路由器規則,以確認允許向外的 UDP 1812 流量傳送到 Cloud RADIUS 的 IP 範圍。(3) 驗證 AP 上設定的共用秘密 (Shared Secret) 是否與 Cloud RADIUS 入口網站中為該分店設定的秘密相符 - 不相符會導致 RADIUS 伺服器直接捨棄封包而不產生任何回應。(4) 檢查該分店的網際網路連線是否正常運作 - Cloud RADIUS 需要可靠的網際網路連線。在 AP 或上游路由器上執行封包擷取,將能確認是否正在傳送 RADIUS 封包以及是否收到回應。