員工 WiFi Captive Portal：員工入網與身分驗證

員工 WiFi Captive Portal：員工入網與身分驗證 Purple 企業 WiFi 智慧簡報 [引言 - 約 1 分鐘] 歡迎收看 Purple 企業 WiFi 智慧系列。今天我們將探討一個處於安全、HR 營運和網路架構交界處的主題：員工 WiFi Captive Portal。 我知道你們中有些人可能會想：員工也需要 Captive Portal 嗎？那不是給訪客用的嗎？這正是我們需要首先澄清的誤解。員工 WiFi Captive Portal 不是換了標誌的訪客登入頁面。它是一個結構化的入網閘道，在授予營運網路存取權限之前，先對個別員工進行驗證、強制接受政策並註冊裝置。如果做對了，您就能消除大多數企業 WiFi 部署中最大的單一漏洞：共享的預先共用金鑰。如果做錯了，前員工、承包商和個人裝置就會無限期地留在您的員工網路中。 讓我們深入探討其架構。 [技術深挖 - 約 5 分鐘] 大多數員工 WiFi 部署的根本問題在於共享密碼。單一的 WPA2 預先共用金鑰，寫在後勤辦公室的便利貼上，在 WhatsApp 群組中分享，且在有人離職時從未變更。在一個擁有 200 間客房、80 名員工的飯店中，該密碼已被分享給大約 80 個人、他們借用手機的伴侶，以及至少三名前員工。這不是網路。這是一扇敞開的大門。 員工 WiFi Captive Portal 透過將共享憑證替換為經過身分驗證的入網流程來解決此問題。以下是它在實務中的運作方式。 當新員工首次將其裝置連線到員工網路時，他們會進入一個配置 SSID。這是一個開放網路，但它是一個圍牆花園（Walled Garden）——它僅路由到入網入口網站和您的身分識別提供者。沒有其他地方。員工會被重定向到 Captive Portal，並在該處使用其企業身分進行驗證。在當今的大多數企業環境中，這意味著透過 Microsoft Entra ID、Okta 或 Google Workspace 進行單一登入 (SSO)。 一旦身分識別提供者確認該員工處於啟用狀態且位於正確的群組中，入口網站就會根據您的驗證架構執行以下兩項操作之一。在基於憑證且使用 PEAP 和 MSCHAPv2 的部署中，入口網站會驗證憑證並發放網路存取權杖。在基於憑證且使用 EAP-TLS 的部署中，入口網站會觸發憑證產生。由您的憑證授權單位 (CA) 發放一個針對特定裝置的 X.509 憑證，並將其封裝到設定設定檔中（iOS 上的 .mobileconfig 檔案，或 Android 上的 Passpoint 設定檔），然後推送到裝置。裝置安裝該設定檔，斷開與配置 SSID 的連線，並使用該憑證自動連線到安全的員工 SSID 以進行 EAP-TLS 驗證。 從那時起，每當裝置連線到員工網路時，RADIUS 伺服器都會驗證該憑證。沒有密碼提示。無需手動登入。裝置只會靜默且安全地連線。 現在讓我們談談為什麼 EAP-TLS 是大多數企業部署的目標狀態。IEEE 802.1X 標準定義了架構，但 EAP-TLS 是完全從驗證路徑中消除憑證遭竊的方法。沒有密碼可供網路釣魚。沒有雜湊值可供暴力破解。憑證與裝置綁定。如果裝置遺失或遭竊，您可以在憑證授權單位中撤銷該憑證，RADIUS 伺服器將在下一次連線嘗試時拒減存取。如果員工離職，您可以在身分識別提供者中停用其帳戶，且由於憑證是針對該身分發放的，SCIM 整合將自動傳播取消配置。人員離職，存取權限即終止。 這正是像 Premier Inn 和 Whitbread 這樣的組織在管理分散式資產中數百個物業和數千台員工裝置時所需的架構。您無法透過共享密碼和手動撤銷來進行大規模管理。 我們也來探討一下 BYOD 的維度，因為這正是 Captive Portal 變得特別有價值的地方。在大多數餐飲旅宿、零售和活動環境中，很大比例的員工使用個人裝置執行營運任務。房務人員在自己的智慧型手機上檢查客房分配。零售店員使用個人平板電腦進行庫存查詢。體育場營運團隊使用個人手機進行溝通。這些都是未託管的裝置。您無法控制其作業系統版本、防毒狀態或安裝了哪些其他應用程式。它們充其量只能被視為半信任裝置。 員工 WiFi Captive Portal 透過在驗證後將這些裝置放置在專用 VLAN 中來處理 BYOD。該 VLAN 僅授予他們存取所需特定內部應用程式的權限（例如物業管理系統、銷售點介面、排班應用程式），而無其他權限。他們無法存取您的企業伺服器、財務系統或託管裝置網路。這是在 RADIUS 層級強制執行的 VLAN 區隔，也是零信任原則的具體實踐：驗證身分，然後授予所需的最小權限。 還有一個值得探討的架構元素：合理使用政策（AUP）。Captive Portal 是強制接受 AUP 的天然執行點。在員工獲得員工網路存取權限之前，入口網站會呈現該政策（涵蓋合理使用、監控、資料處理以及濫用的後果），並要求明確確認。這會建立一個帶有時間戳記、可供稽核的政策接受記錄。在 GDPR 規範下，這很重要。在 PCI DSS 規範下，對於任何接觸持卡人資料的網路，這都很重要。而在涉及網路濫用的紀律調查中，這更是至關重要。 現在，談談頻寬。這正是 Purple Shield 直接發揮作用的地方。在高密度的員工環境中（例如客滿週末的飯店、黑色星期五的零售店、比賽日的體育場），員工網路上的頻寬爭用是一個真實存在的營運問題。Purple Shield 在 DNS 層級運作，在廣告負載、追蹤指令碼和惡意軟體網域到達裝置之前將其封鎖。根據 Purple 的自有數據，實際效果是使整個網路的總下載數據量減少高達 40%。對於員工裝置而言，這意味著更快的網頁載入速度、更低的裝置電池消耗，以及更多可用於營運流量的頻寬。當典型廣告密集型網頁中常見的 120 多個 DNS 查詢在進入網路前被剝離時，網頁載入速度最多可提高 3.5 倍。您無需更動硬體、無需重新設定存取點，也無需進行任何單一裝置設定，即可獲得此項改善。 [實施建議與陷阱 - 約 2 分鐘] 讓我為您介紹實施順序和需要注意的故障模式。 在設定任何一個存取點之前，先從您的 VLAN 架構開始。至少定義三個 VLAN：員工、訪客和 IoT。規劃您的防火牆政策。取得安全團隊的核准。WiFi 部署中最昂貴的錯誤往往是先建構網路，事後才加入安全架構。 第二，部署具備備援能力的 RADIUS 基礎架構。單一 RADIUS 伺服器故障會同時將所有員工鎖在網路之外。在飯店中，這意味著櫃台無法處理入住手續。在零售店中，這意味著銷售點系統無法進行驗證。請以主動-被動（active-passive）配置部署至少兩台 RADIUS 伺服器，並在正式上線前測試容錯移轉。 第三，透過 LDAP 或 SAML 將您的 RADIUS 伺服器與身分識別提供者整合。這正是實現自動取消配置的關鍵。當員工在 Microsoft Entra ID 或 Okta 中被停用時，RADIUS 伺服器將在下一次連線嘗試時停止接受其憑證或憑證。無需手動步驟，無需工單排隊，離職與取消存取權限之間毫無時間差。 第四，為您團隊中技術能力最低的使用者設計 Captive Portal 入網流程。不是 IT 經理。而是從未安裝過設定設定檔的季節性倉庫操作員。在每個畫面上提供清晰的說明、品牌化介面和技術支援聯絡電話。 現在來談談陷阱。最常見的故障模式是圍牆花園（Walled Garden）過於寬鬆。如果您的配置 SSID 允許一般網際網路存取，員工將只會留在該網路上，而不會完成入網流程。請將其鎖定在入口網站、身分識別提供者端點和憑證下載伺服器。沒有其他地方。 第二個陷阱是 Android 碎片化。iOS 處理 .mobileconfig 設定檔的方式非常一致。Android 則不然。不同的製造商和作業系統版本處理憑證安裝的方式不同。在推出之前，請在您員工實際使用的特定 Android 裝置上測試您的入網流程。Passpoint（也稱為 Hotspot 2.0）透過在初始設定後啟用自動網路探索和驗證，顯著改善了 Android 體驗。 第三個陷阱是憑證過期。發放短期憑證——對於 BYOD 裝置， 90 天是一個合理的預設值。當憑證過期時，裝置必須透過入口網站重新入網。這自然會從網路中移除過期裝置，並強制針對目前的身分識別提供者狀態進行重新驗證。屬於六個月前帳戶已被停用的前員工的裝置，將自動無法重新入網。 [快速問答 - 約 1 分鐘] 一些我們經常聽到的問題。 「我們可以使用 iPSK 代替完整的 802.1X 嗎？」可以，適用於無法部署憑證的環境。iPSK（即識別預先共用金鑰）為每個使用者或裝置分配唯一的 WiFi 密碼。它比共享 PSK 更安全，因為每個憑證都是獨立且可撤銷的。但它不如 EAP-TLS 安全，因為它仍然是基於密碼的。請將其作為過渡方案，而非終極目標。 「如果我們已經在使用 WPA2-Enterprise，還需要 WPA3 嗎？」如果您的硬體支援，是的。WPA3-Enterprise 引入了對等同時驗證（SAE），消除了針對交握的離線字典攻擊。在支援的硬體上，遷移成本僅為設定變更。而安全性的提升是實質性的。 「我們該如何處理沒有企業身分的承包商？」使用 iPSK 或透過入口網站發放具時效限制的訪客憑證。設定與合約結束日期相符的到期日。Purple 的平台原生支援具時效限制的存取憑證。 [總結與後續步驟 - 約 1 分鐘] 讓我做個總結。員工 WiFi Captive Portal 不是一項便利功能。它是您營運網路上進行身分驗證、政策接受、裝置註冊和存取控制的強制執行點。共享的預先共用金鑰是一項合規責任，也是一個安全漏洞。請將其替換為經過身分驗證的入網流程、VLAN 區隔和基於 RADIUS 的驗證。 您眼前的後續步驟：稽核您目前的員工網路驗證方法。如果您正在執行共享 PSK，這是您最高優先級的補救措施。如果您使用的是基於憑證的 802.1X，請評估轉向基於憑證的 EAP-TLS 的路徑。如果您尚未在員工網路上部署 Purple Shield，單是頻寬的減少就足以證明進行此討論的價值。 如需實施指南、架構範本以及 Purple 在全球 80,000 個實體場域部署的案例研究，請造訪 purple.ai。感謝您的收聽。