當員工離職時如何撤銷 WiFi 存取權限

歡迎閱讀這份關於員工離職時撤銷 WiFi 存取權限的技術簡報。 這個問題看起來往往比實際更簡單。有人在星期五離職，其主管停用了電子郵件並收回筆記型電腦。然而，他們的行動電話或個人裝置在星期一仍然可以加入員工 WiFi。在飯店中，這可能會讓前員工接近營運系統。在零售門市中，這可能會讓其擁有跨多家商店的員工網路存取權限。在體育場或會議中心，這可能會使繁忙的活動日更加難以管理。眼前的問題不是離職者是否知道密碼，而是您的 WiFi 能否將該人員識別為一個獨立的身分，並在不影響其他所有人的情況下拒絕該身分的存取。 單一共享的 WPA2 複雜密碼無法做到這一點。每個人都擁有相同的憑證。一旦與離職者共享了該複雜密碼，網路就沒有乾淨的方法來區分該離職者與同樣知道該密碼的每個授權員工。實際的應對措施是在全公司範圍內輪換複雜密碼，然後在每台核准的裝置上進行更新。這在營運上成本高昂，會產生支援工單，且往往會被推遲。對於分散式場館資產來說，這不是一個可靠的當日離職控制措施。 有三種可靠的模式。第一種是使用 EAP-TLS 的每人 802.1X。第二種是 iPSK，有時稱為個人預先共用金鑰。第三種是使用 SCIM、由身分識別提供者驅動的取消佈署。您可以結合這些模式。核心的設計選擇仍然相同：使存取憑證可歸因於個人或受控裝置，然後使移除成為一個受控且有記錄的事件。 讓我們從 802.1X 和 EAP-TLS 開始。IEEE 802.1X 是網路存取控制架構。它將請求加入的裝置、網路邊緣的驗證器以及後端驗證服務分開。EAP-TLS 是一種可延伸驗證通訊協定方法，使用憑證進行相互驗證和金鑰衍生。簡單來說，在同一次驗證交換中，裝置證明其擁有憑證，而網路也證明其自身的身分。 此模式適用於受控的員工裝置和高安全保障網路。離職者的處理動作不是變更共用密碼，而是停用該身分並撤銷、拒絕或以其他方式移除憑證的驗證權限。您的 RADIUS 和憑證驗證設計必須能夠在裝置進行驗證時識別該變更。請勿將憑證過期與憑證撤銷混淆。過期是排定的。撤銷則是您在排定的結束日期之前採取的離職處理動作。時機至關重要。基於憑證的 WiFi 存取權限是在驗證時進行檢查。因此，您的實際目標很明確：防止憑證在下一次驗證嘗試時通過，並測試該結果。如果員工已經擁有一個啟動中的工作階段，請另外決定您的原則是否需要中斷該工作階段。這是網路營運的選擇，不能取代撤銷身分。在設計和測試過程中，還必須考慮快速重新連線行為和快取工作階段。如果您的生產驗證路徑未能如預期驗證該變更，那麼在實驗室中看起來正確的設計可能會產生盲點。 EAP-TLS 的營運檢查清單非常簡單。首先，確認該人員的身分記錄和最後工作時間。第二，停用來源身分。第三，根據您的憑證授權單位和 RADIUS 流程，撤銷或拒絕相關憑證。第四，如果您的原則需要，請移除或終止啟動中的工作階段。第五，使用前員工的託管裝置或受控的等效裝置嘗試進行新的連線。最後，保留請求、變更、結果、時間和負責的主辦人員。 第二種模式是 iPSK。與整個員工團隊共用一個密碼不同，每個人或裝置在同一個員工 WiFi 網路上都擁有一個獨特的金鑰。這使得移除更具針對性。刪除與離職者關聯的金鑰，確認新的加入嘗試失敗，並保持所有其他金鑰不變。在您擁有無法使用憑證的裝置、託管裝置計畫仍在發展中，或者您需要從單一共享密碼實用過渡的情況下，iPSK 可以發揮很好的作用。 iPSK 與換了名稱的一般員工密碼不同。金鑰必須與一個身分或裝置記錄綁定。請保存金鑰擁有者、核發日期、裝置或人員關聯、網路角色以及移除狀態的清單。使金鑰具備足夠的區別性，以便能將刪除事件追溯到離職員工。如果同一個 iPSK 被團隊、承包商群組或班別重複使用，您只是在較小的範圍內重新製造了共享秘密的問題。 第三種模式是 SCIM 驅動的停用流程。SCIM 是一種標準的、基於 HTTP 的協定，用於跨系統配置和管理身分資料。在良好的新進 - 異動 - 離職流程中，HR 或 IT 在身分識別提供者中停用帳戶，停用狀態會同步到 WiFi 存取服務，隨後的 WiFi 驗證就會被拒絕。Purple 透過 SCIM 將 WiFi 存取與身分識別提供者連結。相關的身分識別提供者包括 Microsoft Entra ID、Okta 和 Google Workspace。營運上的優勢並非魔法，而是一個單一的信任來源：結束僱用關係的事件同時也啟動了 WiFi 移除流程。 將 SCIM 視為控制路徑，而非宣傳口號。您需要一個不重複識別碼，用來將身分識別提供者帳戶對應到 WiFi 存取記錄。您需要一個雙方同意的停用事件。您需要知道當停用請求失敗時，接收服務會產生什麼錯誤。此外，您還需要一個測試身分來證明您的監控機制能捕獲該失敗。 現在從設計進入實作階段。首先進行存取清查。列出每個員工 WiFi 網路、其安全模式、身分來源、RADIUS 路徑（若有）、憑證授權單位（若有）、iPSK 擁有者記錄（若有）、工作階段中斷連線能力以及記錄檔目的地。請按場地群組進行，而非整合為單一扁平的公司清單。飯店、實體商店與體育場可以在使用不同營運團隊與硬體的同時，共用相同的安全性原則。 接下來，選擇最能減少離職流程中手動操作的控制措施。對於受管的公司裝置，在您的憑證授權單位、RADIUS 設計與裝置管理支援的情況下，請使用搭配 EAP-TLS 的 802.1X。對於混合資產與無法使用憑證的裝置，僅在每個金鑰皆由不重複個體擁有且可刪除時，才使用 iPSK。對於已在使用 Microsoft Entra ID、Okta 或 Google Workspace 的資產，請使用 SCIM 驅動的撤銷帳戶功能，將停用帳戶作為移除 WiFi 的觸發條件。Purple 可以將該身分識別事件與 WiFi 存取狀態相連結。除非是例外路徑，否則請勿增加第二張手動工單。 建立當天離職的執行指南。HR 確認離職時間。身分擁有者停用帳戶。網路擁有者確認相關憑證、iPSK 或 WiFi 存取記錄已不再有效。營運部門決定是否需要中斷作用中的工作階段。指定測試人員進行新的驗證嘗試。只有在記錄結果後，該案件才會關閉。這過程特意設計得枯燥乏味，但這也是評估人員可以重建的關鍵環節。 對於 ISO 27001 或 SOC 2 的證明，請保留精簡但完整的鏈結：授權的離職請求、身分識別提供者變更、WiFi 變更、驗證結果、時間戳記以及每個步驟的負責人。避免收集超過控制措施所需的個人資料。存取記錄可能屬於個人資料，因此請將其納入您的保留與存取控制決策中。如果員工 WiFi 可能影響付款系統，請與負責 PCI-DSS 的團隊討論範圍與區隔，而不要將撤銷 WiFi 視為獨立的合規聲明。 注意四種失敗模式。第一，被遺忘的 SSID 上仍在使用共用密碼。第二，WiFi 記錄與易變的電子郵件地址對應，而非持久的身分識別。第三，停用事件已到達身分識別提供者，但未到達 WiFi 存取服務。第四，您只測試了儀表板狀態，而沒有測試實際的新加入嘗試。只要您清查、監控並測試控制措施，每種失敗模式都是可以預防的。 快問快答。可以單獨撤銷已離職員工的共享 WPA2 密碼嗎？不行。您必須為所有人輪替密碼，或是改用針對每個身分進行控制的機制。EAP-TLS 存取權限的撤銷速度有多快？在下一次進行驗證時，前提是您的憑證與 RADIUS 驗證設計能識別該撤銷。SCIM 會清除作用中的工作階段嗎？本身不會。請將工作階段控制視為獨立的營運決策。iPSK 適合所有裝置嗎？不適合。它是在不適合使用憑證驗證時，一種實用的身分綁定金鑰模式。 下一步是進行簡短的設計審查。挑選一個員工 WiFi 網路。追蹤一次從人力資源部門通知到拒絕驗證的離職事件。找出其中的手動步驟，然後將其移除。WiFi 認證應該在員工離職時便同步失效，而不是等到下一次密碼輪替專案時才處理。