Skip to main content

什麼是 PKI?公開金鑰基礎架構如何驅動 WiFi 安全

這份權威的技術參考指南說明了公開金鑰基礎架構(PKI)及其在保護跨飯店、零售和公部門場域的企業 WiFi 網路中所扮演的關鍵角色。專為 IT 經理、網路架構師和技術長設計,提供有關憑證式驗證、使用 EAP-TLS 的 IEEE 802.1X 部署,以及 Purple 平台如何利用這些標準實現可擴展、合規的連線的可行動指引。讀者將獲得具體的部署路線圖、真實案例研究,以及對 PKI 如何消除共用密碼 WiFi 漏洞的清晰理解。

📖 6 min read📝 1,484 words🔧 2 worked examples3 practice questions📚 9 key definitions

Listen to this guide

View podcast transcript
歡迎收聽 Purple 技術簡報。我是您的主持人,今天我們要探討企業網路安全的一個基本組成部分:公開金鑰基礎架構,即 PKI,特別是如何透過憑證式驗證驅動安全 WiFi。 如果您是 IT 經理、網路架構師或場域營運總監,管理著飯店、零售連鎖店或大型公共場域的連線,您就知道傳統的預先共用金鑰——貼在牆上或寫在白板上的密碼——已經行不通了。這是一個巨大的安全風險。它無法提供個人責任歸屬,而輪替它是一場營運噩夢。 那麼,替代方案是什麼?答案是 IEEE 802.1X 搭配 PKI。 讓我們從基礎開始。什麼是 PKI? 公開金鑰基礎架構是建立、管理、散佈、使用、儲存和撤銷數位憑證所需的硬體、軟體、政策和程序的全面框架。用白話來說,它就是允許您為網路上的每個裝置和使用者簽發數位護照的系統。 使用者不需要輸入密碼,他們的裝置會出示一個數位憑證——一個格式為 X.509 標準的密碼學文件。此憑證將公開金鑰與一個身分綑綁,例如裝置的 MAC 位址或員工的電子郵件地址。 這個系統中的中央權威機構是憑證授權機構,即 CA。把 CA 想像成簽發護照的政府。如果您的網路信任該 CA,它就信任該 CA 簽發的憑證。 現在,這如何應用於 WiFi?這讓我們來到 802.1X 和 EAP-TLS。 802.1X 是用於埠型網路存取控制的 IEEE 標準。它本質上在您的網路入口——存取點——扮演保鑣的角色。它封鎖所有流量,直到裝置證明自己的身分。 EAP-TLS,代表具有傳輸層安全性的可擴展驗證協定,是這種證明的黃金標準方法。它要求相互驗證。這點絕對關鍵。 在 EAP-TLS 中,用戶端裝置將其憑證出示給 RADIUS 伺服器,說:我是一個有效的企業裝置。但接著,RADIUS 伺服器將其自己的憑證出示回給用戶端,說:而我是合法的企業網路,不是惡意存取點。 這種相互信任防止了安全專業人員所稱的邪惡雙胞胎攻擊,即惡意行為者設定一個具有相同網路名稱的惡意存取點來盜取憑證。由於惡意行為者沒有來自您內部憑證授權機構的有效憑證,用戶端裝置將拒絕連線。就是這樣。 讓我們更詳細地討論這些元件。 憑證授權機構階層通常有三層。在最頂端,您有根 CA。這是信任的最終來源。在一個設計良好的部署中,根 CA 保持完全離線——實體安全、與網路隔離。它只會簽署中繼 CA 憑證。 在其下方,您有一個或多個中繼 CA。這些在線上,處理簽發 CA 憑證的日常簽署工作。根 CA 與中繼 CA 的分離意味著即使一個中繼 CA 被入侵,您也可以撤銷它而不會毀掉整個 PKI。 在階層的最底層,簽發 CA 實際簽署終端實體憑證——那些安裝到您的筆記型電腦、平板電腦和智慧型手機上的憑證。 每個憑證包含幾個關鍵欄位:主體,識別憑證持有者;簽發者,識別簽署它的 CA;公開金鑰;有效期間,定義開始和結束日期;以及簽發 CA 的數位簽章。 現在,讓我們走過一個真實的實作情境。 想像一個擁有五百家門市的零售連鎖店。他們目前正在運行 WPA2-PSK——一個在所有地點共用的單一密碼。IT 團隊知道這是個問題。員工流動意味著密碼會被外部分享。無法審計誰在網路上。而且如果一家門市的密碼遭到入侵,攻擊者就能存取整個企業。 移轉到 PKI 的路徑看起來像這樣。 首先,選擇一個雲端管理的 PKI 提供者,並與現有的行動裝置管理解決方案整合。其次,設定 SCEP——簡單憑證註冊協定——自動將唯一的、裝置綁定的憑證推送至每個企業裝置。第三,部署雲端 RADIUS 服務,並將其設定為根據 PKI 驗證憑證。第四,重新設定每個門市的無線控制器,以在企業 SSID 上強制執行 802.1X 驗證。最後,淘汰 PSK 網路。 結果是什麼?每個裝置都有一個唯一的密碼學身分。如果一台平板電腦遭竊,其憑證會在 PKI 中撤銷,並在幾分鐘內,該裝置就無法再存取任何門市的任何網路。無需密碼輪替。無需停機。無營運混亂。 現在,讓我們談談一些常見的陷阱,因為這是許多部署會遇到的問題。 第一個也是最常見的問題是不良的撤銷管理。簽發憑證是簡單的部分。可靠地撤銷它們是團隊經常不足的地方。您的 RADIUS 伺服器必須設定為在每一次驗證嘗試時主動檢查憑證撤銷清單(CRL),或使用線上憑證狀態協定(OCSP)。不是一天一次。而是每次。如果裝置遭到入侵且其憑證被撤銷,但您的 RADIUS 伺服器每二十四小時才檢查一次 CRL,您就有二十四小時的暴露窗口。 第二個陷阱是時間同步。這比您預期的更常讓團隊措手不及。數位憑證對時間極其敏感。如果用戶端裝置的時鐘因 NTP 故障等原因差了幾分鐘,憑證驗證就會失敗。憑證將看似尚未有效或已經過期。確保您的整個網路基礎架構有強固的 NTP 組態。 第三個陷阱是信任鏈散佈。為了讓 EAP-TLS 相互驗證運作,用戶端裝置必須信任簽發 RADIUS 伺服器憑證的根 CA。在加入 Active Directory 的 Windows 裝置上,這通常透過群組原則自動處理。但對於 Android 裝置、iOS 裝置或 BYOD 設備,您必須透過 MDM 推送根 CA 憑證。如果您遺漏此步驟,那些裝置將拒絕 RADIUS 伺服器的憑證且無法連線。 讓我們轉向我最常被問到的快速問答。 我可以為訪客 WiFi 使用 EAP-TLS 嗎?技術上可以,但實際上不行。訪客裝置是未受管理的,所以您無法推送憑證給它們。訪客網路應使用帶有社群登入或電子郵件驗證的 Captive Portal,而企業 SSID 使用 EAP-TLS。像 Purple 這樣的平台能清楚處理這種分隔。 什麼是 OpenRoaming,以及 PKI 如何與它相關?OpenRoaming 是一種聯合 WiFi 標準,允許使用者使用預先佈建的設定檔——本質上是基於憑證的認證——無縫且安全地連接到參與網路。Purple 在 Connect 授權下作為 OpenRoaming 的免費身分提供者,意味著透過 Purple 佈建的使用者可以連接到任何啟用 OpenRoaming 的場域,無需 Captive Portal 或密碼。 憑證應該多久續約一次?最佳實務是將終端實體憑證的有效期設定為一年,並在有效期的百分之六十時自動續約。這樣即使續約流程失敗,您也有充足的緩衝時間。 總結今天的簡報。 PKI 以密碼學身分取代易受攻擊的共用密碼。每個裝置獲得一個唯一、不可偽造的數位憑證。EAP-TLS 提供相互驗證,確保裝置信任網路,且網路信任裝置。透過 MDM 自動化佈建對於可擴展的部署是不可或缺的。強固的撤銷檢查是安全部署與虛假安全感之間的區別。而對於面向公眾的場域,採用像 OpenRoaming 這樣受 PKI 支援的標準,可大規模提供無縫、安全的訪客體驗。 如果您正在規劃移轉到憑證式 WiFi,完整的技術參考指南可在 Purple 網站上取得,其中包含架構圖、部署檢查清單,以及適用於飯店、零售和醫療環境的實例演練。 感謝您收聽本次簡報。下次見。

header_image.png

執行摘要

對於管理飯店、零售或公部門場域大型佈建的企業 IT 主管而言,保護無線存取安全是基本需求——而非選擇性升級。傳統的預先共用金鑰(PSK)不適用於企業環境:它們無法提供個人責任歸屬、無法審計,且在輪替時造成顯著的營運負擔。公開金鑰基礎架構(PKI)提供了強固、可擴展網路安全所必需的密碼學基礎。本指南詳細說明什麼是 PKI、它如何透過憑證式驗證賦予企業 WiFi 安全能力,以及部署 IEEE 802.1X 與 EAP-TLS 所需的具體步驟。透過移轉至 PKI 支援的架構,組織可以消除憑證盜用、自動化裝置上線,並確保企業裝置與訪客都能獲得無縫、安全的存取——同時滿足 PCI DSS、GDPR 和 ISO 27001 的要求。


技術深入探討:理解企業 WiFi 中的 PKI

公開金鑰基礎架構(PKI)是建立、管理、散佈、使用、儲存和撤銷數位憑證,以及管理公開金鑰加密所需的硬體、軟體、政策和程序的框架。在企業 WiFi 的脈絡中,PKI 是驅動身分驗證和加密的引擎——以每個裝置或使用者獨有的密碼學身分取代本質上不安全的共用密碼。

PKI 的核心元件

PKI 的核心依賴非對稱式密碼學,其中使用兩個數學相關的金鑰:公開金鑰(公開分享)和私密金鑰(保密)。使用公開金鑰加密的資料只能由對應的私密金鑰解密,反之亦然。PKI 部署的主要元件如下。

元件 角色 企業 WiFi 情境
憑證授權機構 (CA) 簽發與簽署數位憑證 您網路的信任根源;所有裝置必須信任該 CA
數位憑證 (X.509) 將公開金鑰與身分繫結 安裝在每個企業裝置上;在 802.1X 驗證期間出示
RADIUS 伺服器 驗證憑證並授予網路存取權 決定接受或拒絕連線要求的決策引擎
註冊機構 (RA) 在憑證簽發前驗證身分 在自動化部署中通常由 MDM/UEM 處理
CRL / OCSP 檢查憑證是否已被撤銷 對於即時封鎖遭入侵或遺失的裝置至關重要

pki_architecture_overview.png

PKI 如何賦能 802.1X 和 EAP-TLS

企業 WiFi 安全依賴用於埠型網路存取控制的 IEEE 802.1X 標準。當與可擴展驗證協定(EAP),特別是 EAP-TLS(傳輸層安全性)結合時,PKI 提供了最高層級的無線安全:相互驗證

在 EAP-TLS 部署中,用戶端裝置向網路出示其數位憑證以證明其身分,而 RADIUS 伺服器則向用戶端出示其憑證,證明該網路是合法的,而非惡意的「邪惡雙胞胎」存取點。這種相互信任之所以能建立,是因為雙方都信任簽發憑證的根 CA。驗證完成後,工作階段會使用協商好的 TLS 加密套件進行加密,防止竊聽和中間人攻擊。

8021x_authentication_flow.png

EAP-TLS 流程橫跨四個邏輯實體:用戶端裝置(請求者)、存取點(驗證者)、RADIUS 伺服器(驗證伺服器)和憑證授權機構。存取點作為透明的中繼站——它本身不做驗證決策。該決策完全由 RADIUS 伺服器負責,它會驗證憑證鏈回溯到受信任的根 CA。


實作指南:部署憑證式 WiFi

移轉至 PKI 支援的 WiFi 架構需要跨四個階段仔細規劃。

階段 1:架構與 CA 選擇

決定是要建立內部 PKI(例如 Microsoft Active Directory 憑證服務)還是使用受管理的雲端 PKI 提供者。對於現代大規模部署,雲端 PKI 顯著降低管理負擔並提供內建的高可用性。確保所選的 CA 能與您的行動裝置管理(MDM)或統一端點管理(UEM)解決方案無縫整合。對於使用 Guest WiFi 的環境,請確保 RADIUS 基礎架構設計為能在不同的 SSID 上同時處理企業 802.1X 流量和訪客 Captive Portal 驗證。

階段 2:RADIUS 伺服器組態

部署強固的 RADIUS 伺服器——選項包括 FreeRADIUS、Cisco ISE、Aruba ClearPass 或雲端原生 RADIUS 即服務。使用您的 CA 簽發的伺服器憑證來設定 RADIUS 伺服器。這點至關重要:如果沒有有效的伺服器憑證,用戶端無法執行相互驗證,且容易受到邪惡雙胞胎攻擊。對於大型場域部署,請考慮 RADIUS 代理組態以支援站點間的漫遊。部署 WiFi Analytics 平台的場域應確保 RADIUS 計費資料饋送至分析管線,以便準確歸屬工作階段。

階段 3:自動化憑證佈建

手動憑證安裝無法擴展且容易出錯。透過您的 MDM 利用如 SCEP(簡單憑證註冊協定)或 EST(安全傳輸上的註冊)等協定,以無聲方式將憑證推送至企業裝置。對於 BYOD 情境,實作一個上線入口網站,在初始身分驗證後安全地將憑證佈建到使用者裝置上。對於無頭 IoT 裝置——例如醫療設備、銷售點終端機或數位看板——必須在部署前的裝置準備階段佈建憑證。

階段 4:網路政策強制執行

設定您的無線控制器和存取點,以在企業 SSID 上強制執行 802.1X。使用 RADIUS 屬性將憑證屬性(例如主體別名或 OU 欄位)對應到特定的 VLAN 或防火牆政策,確保最小權限的網路存取。對於使用特定供應商硬體的場域,請參閱製造商特定的指南,例如 您的 Ruckus 無線存取點指南 以了解平台特定的設定步驟。


企業 PKI 的最佳實務

保護根 CA。 如果使用內部 PKI,根 CA 必須保持離線且實體安全。只有中繼 CA 應在線上並主動簽發憑證。遭入侵的根 CA 會使您的整個 PKI 失效。

實作強固的撤銷檢查。 確保您的 RADIUS 伺服器在每次驗證嘗試時主動檢查 CRL 或使用 OCSP 來驗證憑證狀態。遭入侵的裝置必須立即撤銷其憑證以封鎖存取。將 RADIUS 設定為快取 CRL 回應過久會造成暴露窗口。

在到期前自動續約。 憑證會到期。實作在憑證有效期的 60–70% 時觸發的自動續約流程,以防止因憑證到期導致的網路中斷。憑證到期是企業環境中非計畫性 WiFi 中斷最常見的原因之一。

為公開場域採用 OpenRoaming。 對於 飯店零售運輸醫療 場域,參與 OpenRoaming 可大規模提供無縫、安全的訪客連線。Purple 在 Connect 授權下作為 OpenRoaming 的免費身分提供者,允許具有現有設定檔的使用者無需 Captive Portal 或密碼即可安全連線——其基礎正是本指南描述的相同 PKI 信任模型。


疑難排解與風險緩減

即使仔細規劃,PKI 部署仍會遇到可預測的故障模式。下表總結了最常見的問題及其解決方案。

故障模式 症狀 根本原因 解決方案
時間同步失敗 所有裝置出現憑證驗證錯誤 用戶端或 RADIUS 上的 NTP 組態錯誤 透過 MDM 和網路基礎架構強制實施 NTP 政策
信任鏈失敗 特定裝置類型(例如 Android)無法連線 根 CA 不在裝置的受信任根存放區中 透過 MDM 設定檔推送根 CA
CRL 無法連線 間歇性驗證失敗 防火牆封鎖 CRL/OCSP 端點 為 CA 發佈點開放防火牆規則
憑證到期 突然大量斷線 未設定續約自動化 在 60% 有效期時實作 MDM 觸發的續約
RADIUS 憑證不符 所有用戶端相互驗證失敗 RADIUS 伺服器憑證過期或 CA 錯誤 更新 RADIUS 伺服器憑證並重新部署

特別是對於網路中斷直接影響病患安全的醫療環境,請參閱 醫院中的 WiFi:安全臨床網路指南 以獲得臨床等級的韌性建議。


投資回報率與業務影響

為 WiFi 安全實作 PKI 可在三個面向提供可衡量的業務價值。

風險降低與合規性。 消除共用密碼移除了最常見的橫向網路移動途徑。憑證式驗證直接滿足 PCI DSS(要求 8.6)、GDPR(第 32 條技術措施)和 ISO 27001(附錄 A.9)的要求。當員工離職或裝置遭竊時,能夠立即撤銷憑證,提供了共用金鑰環境無法比擬的可審計、可證明的控制措施。

營運效率。 透過 MDM 自動化憑證佈建,大幅減少了與 WiFi 連線問題相關的 IT 服務台工單——密碼重設、金鑰輪替和上線延遲。在員工流動率高的零售環境中,這直接轉化為 IT 支援成本降低和更快的裝置部署時間。

增進的使用者與訪客體驗。 憑證式驗證對終端使用者而言是無形的。企業員工無需任何手動步驟即可自動、安全地連線。對於訪客,像 Purple 的 Guest WiFi 解決方案能處理受管理企業存取與訪客上線之間的分隔,確保每個族群獲得適當的驗證體驗,而不會在任一網路上損害安全性。

Key Definitions

公開金鑰基礎架構(PKI)

用於管理數位憑證和公開金鑰加密的角色、政策、硬體和軟體的全面框架。它建立信任關係,使裝置和伺服器能以密碼學方式驗證彼此的身分。

從共用密碼轉向基於身分的網路安全所需的基礎架構。每個使用 802.1X 的企業 WiFi 部署都依賴 PKI。

憑證授權機構(CA)

一個受信任的實體,負責簽發、簽署和管理數位憑證。它在 PKI 中作為信任根源:任何由 CA 簽署的憑證都會被所有信任該 CA 的一方所信任。

您網路安全的中心支柱。如果 CA 遭到入侵,其簽發的所有憑證都可能遭到入侵。保護根 CA 是 PKI 部署中最重要的安全控制措施。

X.509

定義公開金鑰憑證格式的 ITU-T 標準。X.509 憑證包含主體、簽發者、公開金鑰、有效期間和 CA 的數位簽章等欄位。

在設定 RADIUS 伺服器政策時,IT 團隊會將特定的 X.509 欄位——例如主體別名(SAN)或組織單位(OU)——對應到 VLAN 指派和存取政策。

IEEE 802.1X

用於埠型網路存取控制(PNAC)的 IEEE 標準。它提供一個驗證機制,在連線裝置的身分經過驗證伺服器驗證之前,封鎖存取點上的所有網路流量。

在無線存取點強制執行憑證式驗證的通訊協定。沒有 802.1X,裝置可以在不證明其身分的情況下連接到 SSID。

EAP-TLS(可擴展驗證協定 - 傳輸層安全性)

一種 EAP 方法,使用用戶端和伺服器憑證來建立相互驗證、加密的 TLS 工作階段。這是企業 WiFi 可用的最安全 EAP 方法。

企業 WiFi 驗證的黃金標準。與在 TLS 通道內使用密碼的 PEAP 或 EAP-TTLS 不同,EAP-TLS 完全消除密碼,以密碼學憑證取代。

RADIUS(遠端驗證撥入使用者服務)

一種提供集中式驗證、授權和計費(AAA)管理的網路協定。在 802.1X 部署中,RADIUS 伺服器從存取點接收用戶端的憑證,根據 CA 驗證它,並回傳存取決策。

企業 WiFi 驗證堆疊的決策引擎。RADIUS 也處理動態 VLAN 指派,實現基於裝置身分或使用者角色的網路區隔。

憑證撤銷清單(CRL)

由簽發 CA 定期發佈的清單,其中包含在排定到期日之前已被撤銷的憑證。RADIUS 伺服器檢查 CRL 以確保不會授予遭入侵或停用裝置的存取權。

對維護裝置遺失、遭竊或停用時的安全性至關重要。必須在 RADIUS 伺服器上設定 CRL 檢查——這不會自動發生。

相互驗證

一種安全程序,其中通訊連結的雙方同時相互驗證。在 EAP-TLS 中,用戶端向網路驗證,且網路向用戶端驗證。

防止「邪惡雙胞胎」攻擊,攻擊者會設定一個與企業網路相同 SSID 的惡意存取點來攔截憑證。沒有相互驗證,用戶端無法驗證它正在連接到合法的網路。

SCEP(簡單憑證註冊協定)

一種協定,透過 MDM 或網路裝置管理系統實現自動化、可擴展的數位憑證散佈到裝置。

使企業 PKI 部署在大規模下營運上可行的機制。沒有 SCEP 或類似的自動註冊協定,向數千個裝置佈建憑證將需要手動介入。

Worked Examples

一家擁有 500 家門市的大型零售連鎖店需要保護其企業 WiFi,供員工使用的銷售點(POS)平板電腦和庫存掃描器使用。他們目前在所有門市使用單一的 WPA2-PSK,經常與非員工分享且無法審計。他們應該如何重新設計其驗證架構?

該零售連鎖店必須移轉至使用 802.1X 和 EAP-TLS 的 WPA3-Enterprise。步驟 1:選擇雲端管理的 PKI 提供者,並與管理 POS 平板電腦和掃描器的現有 MDM 解決方案整合。步驟 2:設定 SCEP,透過 MDM 自動將唯一的、裝置綁定的數位憑證推送至每個企業裝置。步驟 3:部署雲端 RADIUS 服務,並將其設定為根據 PKI 驗證憑證,並啟用 OCSP 檢查。步驟 4:重新設定每家門市的無線控制器,以在企業 SSID 上強制執行 802.1X 驗證。步驟 5:淘汰 PSK 網路。步驟 6:透過 RADIUS 屬性設定 VLAN 指派,在網路層將 POS 裝置與一般員工裝置隔離。

Examiner's Commentary: 此方法徹底消除了共用密碼的漏洞。由於憑證是透過 MDM 部署並綁定到裝置硬體,因此無法被提取並對外分享。如果平板電腦遺失或遭竊,其特定憑證會透過 MDM/PKI 整合被撤銷,立即封鎖該裝置的網路存取,而不會影響任何其他門市或裝置。透過 RADIUS 屬性的 VLAN 隔離也滿足了 PCI DSS 對持卡人資料環境的網路區隔要求。

一家大型醫院網路正在三個院區部署新的無線醫療輸液幫浦。這些裝置缺乏使用者介面來輸入憑證或接受強制網路門戶提示。如何在不造成共用金鑰漏洞的情況下,安全地將它們連接到臨床 WiFi 網路?

為無頭 IoT 醫療裝置實作特定的 PKI 基礎架構。步驟 1:為每個輸液幫浦產生裝置特定的 X.509 憑證,使用裝置序號作為主體通用名稱。步驟 2:在臨床部署前的準備和佈建階段,將憑證安裝到幫浦上。步驟 3:為臨床 WiFi SSID 設定 802.1X EAP-TLS。步驟 4:將 RADIUS 伺服器設定為將裝置憑證的主體 CN 對應到專用於醫療裝置的特定 VLAN。步驟 5:實作 CRL 檢查,以便在裝置停用或召回時允許立即撤銷。

Examiner's Commentary: 這是臨床環境中安全 IoT 部署的標準方法,如 [醫院中的 WiFi:安全臨床網路指南](/blog/wifi-in-hospitals) 中詳述。它提供了強大的、基於身分的的安全性,無需使用者互動,這對無頭醫療裝置至關重要。透過 RADIUS 進行的 VLAN 指派確保即使幫浦的憑證不知何故遭到入侵,該裝置也僅能存取臨床裝置 VLAN——而非更廣泛的醫院網路。

Practice Questions

Q1. 您的組織正從 PEAP(使用者名稱/密碼)移轉到 EAP-TLS(憑證)用於企業 SSID。在測試期間,Windows 筆記型電腦成功連線,但 Android 裝置持續失敗。RADIUS 日誌顯示 Android 裝置在 TLS 交握期間拒絕伺服器的憑證。最可能的原因是什麼,以及如何解決?

Hint: 考慮相互驗證的概念和信任鏈。Android 裝置需要什麼才能信任 RADIUS 伺服器的憑證?

View model answer

Android 裝置未在其受信任根存放區中安裝根 CA 憑證。Windows 筆記型電腦會自動透過群組原則接收根 CA,但 Android 裝置需要透過 MDM 設定檔推送根 CA。若受信任存放區中沒有根 CA,Android 裝置無法驗證 RADIUS 伺服器的憑證鏈,導致其拒絕伺服器憑證並中止 TLS 交握。解決方案:建立一個 MDM 設定檔,將根 CA 憑證安裝到所有受管理 Android 裝置的受信任根存放區中,然後重新測試。

Q2. 一名剛離職員工的企業筆記型電腦,在其 Active Directory 帳戶被停用兩天後,仍然成功連接到企業 WiFi 網路。該網路使用 EAP-TLS。為什麼會發生這種情況,必須做些什麼來防止它?

Hint: 停用 Active Directory 帳戶不會自動失效密碼學憑證。考慮 RADIUS 伺服器實際驗證的是什麼。

View model answer

RADIUS 伺服器正在驗證憑證,而非 Active Directory 帳戶狀態。由於憑證在數學上仍然有效且未被撤銷,RADIUS 伺服器授予存取權。要立即解決,必須在憑證授權機構中撤銷簽發給該筆記型電腦的特定憑證。為了系統性地防止此情況,將人力資源離職流程與 MDM 和 PKI 整合:當員工被解僱時,MDM 應自動撤銷裝置憑證並取消註冊裝置。此外,確保 RADIUS 伺服器設定為在每次驗證嘗試時檢查 OCSP 或 CRL——而不只是定期檢查——以便撤銷立即生效。

Q3. 您正在為一個大型體育場設計網路架構,該體育場希望為 60,000 名參加者提供無縫、安全的 WiFi,而不需要每個人通過 Captive Portal。場館還希望支援需要為其 POS 設備提供 802.1X 安全存取的企業參展商。PKI 如何同時滿足這兩項要求?

Hint: 考慮有兩個具有不同驗證需求的獨立族群。OpenRoaming 處理其中一個;具有 802.1X 的專屬企業 SSID 處理另一個。

View model answer

需要兩個獨立的 SSID。對於 60,000 名參加者,實作 OpenRoaming。體育場的網路必須設定為信任 OpenRoaming 根 CA。當訪客的裝置——由像 Purple 或行動電信商等身分提供者佈建——連線時,它會出示一個憑證。RADIUS 伺服器根據 OpenRoaming 信任鏈驗證此憑證,並授予安全、加密的存取權,無需 Captive Portal。對於有 POS 設備的企業參展商,部署一個使用 EAP-TLS 的獨立 802.1X SSID。參展商在認證過程中被簽發臨時裝置憑證,這些憑證在活動結束後自動撤銷。RADIUS 屬性將 POS 裝置指派到專屬 VLAN,滿足 PCI DSS 網路區隔要求。

什麼是 PKI?公開金鑰基礎架構如何驅動 WiFi 安全 | Technical Guides | Purple