什麼是 802.1X 請求項（Supplicant）？用戶端類型與裝置設定

以英式英語口音，伴隨自信、權威且口語化的語調進行說明 - 就像一位資深網路安全顧問在向客戶進行簡報。節奏沉穩、發音清晰、專業而不生硬。適時自然停頓以示強調： 歡迎來到 Purple 技術簡報系列。今天我們要探討的是 enterprise WiFi 安全的核心關鍵 - 802.1X 請求方 (supplicant)。如果您曾想過為什麼有些裝置可以無需密碼提示就連上您的企業網路，而其他裝置卻會彈出憑證錯誤並產生求助桌工單，那麼這一集就是為您準備的。 [中等停頓] 讓我們從基礎開始。802.1X 請求方是終端裝置 - 筆記型電腦、智慧型手機、平板電腦 - 上的軟體元件，當該裝置嘗試加入受 IEEE 802.1X 保護的網路時，它會負責處理身分驗證交握。您可以把它想像成裝置的出示身分證人員。網路不會隨便讓任何人進入。它需要憑證。請求方就是主動上前並說：這是我，這是我的憑證，請讓我進去的角色。 此標準本身 - IEEE 802.1X - 定義了基於連接埠的網路存取控制。在身分驗證成功之前，存取點 (access point) 或交換器只允許非常特定且狹窄的流量通過：也就是 EAPOL 訊框 (代表區域網路上的可延伸驗證協定)。其他所有流量都會被阻擋。一旦請求方透過驗證器向 RADIUS 伺服器證明了其身分，連接埠就會開啟，正常流量便隨之流動。 [中等停頓] 現在，這場戲中有三個角色。第一，請求方 - 客戶端裝置。第二，驗證器 - 您的存取點或交換器，例如 Cisco Meraki、HPE Aruba、Ruckus 或 Juniper Mist 等硬體。第三，驗證伺服器 - 幾乎總是 RADIUS 伺服器，它會根據 Microsoft Entra ID 或 Okta 等目錄來驗證憑證。 請求方藉由發送 EAPOL-Start 訊息來啟動此程序。驗證器會回覆 EAP-Request 以要求身分。請求方則回覆其身分。該身分會被轉發到 RADIUS 伺服器，接著伺服器會使用約定的 EAP 方法向請求方發出挑戰。如果一切無誤，RADIUS 伺服器就會發送 Access-Accept，連接埠開啟，裝置便會被分配到正確的 VLAN。 [中等停頓] 讓我們來談談 EAP 方法，因為這是大多數部署決策的核心所在。 EAP-TLS - 亦即具有傳輸層安全性的可延伸驗證通訊協定 - 是業界的金科玉律。它要求用戶端和伺服器雙方都必須出示憑證。這是雙向驗證。無需密碼。用戶端憑證可證明裝置的身分；伺服器憑證則可證明網路的合法性，進而防範惡意基地台試圖竊取憑證的邪惡雙生攻擊。EAP-TLS 的完成步驟共有 12 個，且全程使用公鑰 - 私鑰密碼學。這是 WPA3-Enterprise 處於最高安全模式時所要求的編譯方法，且符合 NIST SP 800-171 對裝置身分驗證的要求。 PEAP - 受保護的 EAP - 對於尚未建置完整 PKI 的企業組織而言，是更常見的起步選擇。PEAP 將基於密碼的內部方法（通常為 MSCHAPv2）封裝在 TLS 通道中。伺服器會出示憑證，但用戶端不會。這意味著部署更加簡單 - 您不需要配置用戶端憑證 - 但安全性也相對較低。MSCHAPv2 使用 MD4 雜湊演算法，而該演算法自 1995 年起就已被視為存在安全漏洞。如果使用者連線到呈現看似可信憑證的惡意基地台，其認證資訊就可能被攔截。因此，在使用 PEAP 時，用戶端進行伺服器憑證驗證是絕對不容妥協的必要步驟。 [medium pause] 現在，讓我們深入探討請求端（supplicant）本身 - 尤其是原生作業系統請求端與第三方用戶端軟體之間的選擇。 每個主流作業系統都內建了 802.1X 請求端。Windows 自 XP 起就透過 Wireless AutoConfig 和 Wired AutoConfig 服務原生支援此功能。macOS 和 iOS 透過其網路設定設定檔來處理 802.1X。Android 則透過 WiFi 設定面板提供支援。這些原生請求端在所有當前平台上均支援 EAP-TLS 和 PEAP-MSCHAPv2。 原生請求端的優勢顯而易見：無需部署額外的軟體、無授權費用、可自動進行作業系統安全性更新，且與作業系統的憑證儲存區緊密整合。對於受管理的裝置群 - 例如註冊於 Microsoft Intune 的 Windows 裝置，或透過 Jamf 管理的 Mac - 您可以透過 MDM 背景推送 802.1X 設定檔，使用者完全不會收到任何提示。每當裝置進入收訊範圍時，就會自動進行驗證。 在特定情境中會使用到第三方 Supplicant。如果您執行的是 Cisco 基礎設施並希望使用 EAP-FAST（Cisco 專有的 EAP 方法），則需要 Cisco 的用戶端軟體，在過去通常是 Secure Services Client 或 AnyConnect Network Access Manager。如果您需要在混合作業系統的資產中進行一致的組態管理，並希望鎖定 Supplicant 設定以防止使用者不小心誤設，第三方用戶端就能為您提供這種控制能力。像 SecureW2 的 JoinNow 套件這類工具也可以作為引導代理程式 - 它們會設定原生 Supplicant，而不是將其替換，藉此引導使用者完成憑證註冊與設定檔安裝。 [medium pause] 讓我帶您了解兩個實際案例，以便更具體地說明。 第一個案例是一間擁有 400 間客房的飯店。該物業目前在 WPA2-Enterprise 上使用 PEAP-MSCHAPv2 執行員工網路。IT 團隊希望遷移到 EAP-TLS，以消除基於密碼的驗證並降低認證遭竊的風險。面臨的挑戰是：員工裝置包含透過 Intune 管理的 Windows 筆記型電腦、用於物業管理軟體的個人 Android 手機，以及後台少數舊有的 Windows 7 電腦。 這裡的做法是分階段進行。首先從受管理的 Windows 裝置開始。發送一個 Intune 組態設定檔，以安裝 RADIUS 伺服器的根 CA 憑證、為 EAP-TLS 設定 WiFi 設定檔，並觸發來自內部 PKI 且基於 SCEP 的憑證註冊。這些裝置從第一天起就會自動進行驗證。對於 Android 攜帶型裝置（BYOD），則佈署一個自助式引導入口網站 - 使用者造訪 URL、下載組態設定檔，系統就會為他們設定好 Supplicant。舊有的 Windows 7 電腦則維持在使用 PEAP 並執行嚴格的伺服器憑證驗證，且隔離到存取受限的獨立 VLAN，直到它們退役為止。 [medium pause] 第二個案例：擁有 200 家門市的大型零售連鎖店。每家門市都有收銀終端機（POS）、員工平板電腦和客用 WiFi 網路。PCI-DSS 要求持卡人資料環境必須與其他網路區段隔離。該零售商在員工和 POS 網路上使用 802.1X，並由憑證屬性驅動 VLAN 分配。POS 終端機會出示包含組織單位為 "POS" 的裝置憑證 - RADIUS 策略會將其分配到 PCI VLAN。員工平板電腦則會出示包含 "Staff" 的憑證 - 它會進入員工 VLAN。客用裝置則完全連接到另一個 SSID，並由 Captive Portal 解決方案處理。 POS 終端機上的 Supplicant 組態已透過 MDM 鎖定，不需要任何使用者互動，終端機在開機時就會安靜地完成驗證。憑證更新是透過 SCEP 自動執行的，因此憑證過期時不需要手動介入。 [medium pause] 接下來是實作陷阱。讓我為您介紹四個最常見的陷阱。 第一：在 PEAP 部署中缺少伺服器憑證驗證。如果您沒有設定要求者來驗證 RADIUS 伺服器的憑證並檢查伺服器名稱，使用者很容易連線到惡意存取點。請務必在要求者設定檔中指定受信任的根 CA 和伺服器名稱。 第二：憑證過期導致大規模驗證失敗。用戶端憑證具有有效期限。如果您沒有透過 SCEP 或 NDES 建立自動更新，您將面臨數百部裝置同時停止驗證的懸崖式突發事件。請在正式上線前建立更新自動化。 第三：要求者行為不一致的 BYOD 裝置。特別是 Android 在不同製造商之間的 802.1X 支援非常碎片化。某些版本要求使用者在 WiFi 設定檔接受憑證之前，手動安裝 CA 憑證。處理此步驟的註冊入口網站可顯著減少服務台的工作量。 第四：Windows 11 功能更新破壞了要求者設定。Microsoft 在數個 Windows 11 更新中變更了 802.1X 的行為。具體而言，24H2 更新引入了原生要求者處理 EAP-TLS 回退方式的變更。在將要求者設定檔推播到生產環境之前，請先針對新的作業系統版本進行測試。 [中頓] 現在進行快速問答。 IoT 裝置可以支援 802.1X 嗎？大多數不支援。IoT 裝置通常完全缺少要求者。回退方案是 MAC 驗證略過 - MAB - 此時 RADIUS 伺服器會根據裝置的 MAC 位址來驗證裝置。MAC 位址可以被偽造，因此 MAB 裝置應一律放置在具有嚴格防火牆規則的隔離 IoT VLAN 上。 我需要 PKI 才能運作 802.1X 嗎？對於 PEAP，不需要 - 您只需要在 RADIUS 伺服器上安裝伺服器憑證。對於 EAP-TLS，需要 - 您需要 PKI 來發行用戶端憑證。雲端 PKI 服務可顯著減少基礎架構開銷。 802.1X 如何與 Purple 的網路存取平台互動？Purple 以雲端重疊的方式運作在您現有的硬體之上 - 包括 Cisco Meraki、HPE Aruba、Ruckus、Juniper Mist 等。在員工 WiFi 網路上，Purple 的 SecurePass 附加元件可與您的身分識別提供者（Microsoft Entra ID、Okta 或 Google Workspace）整合，以強制執行 802.1X 驗證並套用每位使用者的 VLAN 原則，而不需要內部部署的 RADIUS 基礎架構。 [中頓] 總結一下：802.1X 要求者是裝置端的代理程式，可讓基於連接埠的網路存取控制正常運作。您對 EAP 方法的選擇 - 用於最高安全性的 EAP-TLS，或作為過渡選項的 PEAP - 會驅動您的 PKI 需求和要求者設定方法。透過 MDM 部署時，原生作業系統要求者可涵蓋大部分的託管裝置情境。第三方用戶端在特定情況下可增加價值：專有 EAP 方法、需要一致設定的混合作業系統資產，或自助式 BYOD 註冊。 三個需要記住的重點：在每個請求方設定檔上驗證您的 RADIUS 伺服器憑證、在您大規模部署 EAP-TLS 之前自動化憑證更新，以及將無法支援 802.1X 的裝置 - IoT、舊型硬體 - 隔離到專用的 VLAN，並以 MAC 驗證繞過作為備用方案。 如需深入了解 Purple 如何與您的網路存取架構整合，請造訪 purple.ai。感謝您的收聽。