如何實施零信任而不干擾日常營運

在英國，98% 的組織表示他們計劃或已經實施了零信任，然而僅有 15% 的組織報告已完全實施。落差不在於意識，而是在於執行。英國的零信任研究顯示，許多團隊已經開始規劃、分段或孤立的身分專案，卻沒有將這些控制措施連結成一個單一的維運模式。

實際的問題不在於零信任是否重要。而是如何在不中斷線上服務、不讓使用者感到沮喪，或是不建立另一套零散的安全產品的情況下實施零信任。答案是圍繞著身分、裝置狀態、目錄生命週期、安全 WiFi、分段和持續驗證來安排轉移順序。

為何企業的零信任實作會停滯不前

51% 的組織仍處於早期規劃階段，而只有 15% 聲稱已完全實作，且 80% 面臨過技術或營運障礙。這份英國組織報告顯示了選擇方向與實際運作所需控制措施之間的落差。團隊通常從孤立的專案開始，隨後便會發現身分識別、裝置、目錄、應用程式與網路之間其實相互依賴。

零信任消除了系統、網路和服務中固有的信任。內部連線不應提供廣泛的存取權限。在人員或供應商不再需要權限後，舊帳戶不應保留權限。服務不應因為通過了一次驗證檢查就無限期地保持受信任狀態。

英國國家網路安全中心將零信任框架視為一個階段性的移轉過程，而非購買單一產品。其架構指引定義了八大設計原則，包括由身分導向的存取決策以及受保護的通訊。NCSC 零信任系列指引於 2021 年發布，並於同年 9 月擴展了實作指引。NCSC 架構設計原則 非常實用，因為它們要求團隊在選擇技術之前，先確定架構和信任決策。

產品優先的失敗模式

失敗的模式通常始於購買平台。團隊部署了身分識別產品、分段工具或 ZTNA 閘道器，隨後卻發現服務帳戶、非受管裝置、舊版應用程式、無線驗證和目錄離職流程從未被規劃納入對應之中。

其結果是例外清單不斷增加。使用者獲得因應措施，管理員保留共用認證，而安全性團隊無法判斷原則是否得到一致執行。WiFi 會迅速暴露這一弱點。網路分割可以隔離流量，但如果使用者仍透過共用密碼加入，或者裝置仍處於未知狀態，它就無法建立基於身分的存取。無密碼 WiFi 搭配基於憑證的驗證，並與裝置記錄和目錄狀態連結，可為原則提供可靠的身分訊號。當帳戶被停用時，自動目錄撤銷應立即移除其存取權，而不是等待手動清理。

傳統的邊界控制措施仍扮演著一定角色，但它們無法解決所有的存取問題。傳統 IT 安全為何失敗 說明了雲端服務、遠端存取和分散式裝置如何削弱了內部網路自動安全的假設。

實用規則： 在了解原則可能會中斷哪些身分、裝置、WiFi 及服務相依性之前，切勿編寫執行原則。

可行的遷移順序如下：

• 探索資產：識別使用者、裝置、應用程式、服務和資料流。
• 定義界限：決定哪些資源需要隔離，以及哪些存取路徑是合法的。
• 建立控制平面：連結身分、MFA、基於憑證的裝置存取、狀態檢查以及目錄生命週期。
• 在邊緣執行：將原則套用至應用程式、網路和 WiFi，而不僅僅是 VPN 工作階段。
• 觀察並擴大：從受控的工作負載開始，審查存取決定並逐步擴展模型。

此順序使零信任成為一種營運模式，而非工具的堆砌。它也讓營運團隊在身分控制、安全 WiFi 和區段劃分走向成熟的同時，能夠保護可用性。

透過探索與信任邊界奠定基礎

首先應建立一份反映組織實際運作方式的資產清單，而非僅依據網路架構圖。NCSC 建議識別出使用者、所需權限、裝置與服務，然後圍繞這些發現來設計身分識別與存取管理。NCSC 移轉指南 也指出，團隊在部署前應先對舊有依賴關係進行盤點，並對提議的架構進行威脅建模。

輸出結果應為運作中的目錄，而非靜態試算表。為每個重要資源記錄擁有者、業務目的、驗證方法、相依性、資料敏感度、預期使用者和失敗影響。

建立四個清冊

使用者和身分排在第一位。這包括員工、承包商、特權管理員、服務帳戶和自動化身分。將一個人的僱用狀態與其存取需求分開。承包商可能在特定期限內需要存取某個應用程式，而服務帳戶可能需要機器驗證，但不需要互動式登入。

裝置需要其專屬的分類。記錄受控的筆記型電腦、行動裝置、共用終端機、印表機、相機、建築物系統及其他 IoT 設備。記下哪些裝置支援憑證、現代加密和安全狀態報告。舊型設備通常無法滿足員工驗證要求，因此它需要一個明確的遏制策略，而不是未經追蹤的例外情況。

應用程式和服務應與其身分識別和傳輸需求進行對應。記錄每個應用程式是否支援 SSO、MFA、現代協定、憑證、代理存取，或僅支援舊版使用者名稱和密碼。識別上游目錄、資料庫、DNS 服務、API 和記錄相依關係。

資料流和業務流程揭示了信任邊界。繪製員工如何存取臨床系統、合約人員如何存取維護入口網站，或銷售點設備如何與經批准的服務進行通訊。如果未說明的相依關係迫使跨區段進行無限制的存取，則該區段就沒有意義。

在制定策略前先定義邊界

信任邊界應該回答三個問題：保護的對象是什麼、誰需要存取，以及在哪些條件下存取。條件可包括身分保證、裝置健康狀況、網路情境、應用程式敏感度以及有時間限制的核准。

訪客 WiFi、IoT 和多租戶場域需要特別注意。訪客絕不應依賴員工的網路憑證。IoT 裝置應僅與其功能所需的服務進行通訊。租戶可以在共享實體基礎設施的同時，保有邏輯隔離與獨立的身分管理。

安全傳輸在每個邊界都至關重要。如果團隊需要關於憑證、加密和瀏覽器信任的通俗語言複習，在記錄應用程式和 WiFi 傳輸假設之前，Adwave Digital 的 SSL 指南 是一個有用的參考。

以威脅模型結束搜索。測試當目錄帳戶遭到入侵、受管理設備變得不健康、憑證被撤銷、無線控制器無法使用，或舊版服務無法向新的身分識別提供者驗證時會發生什麼事。這些失敗路徑應該會決定部署的順序。

將身分與裝置狀態建立為您的控制平面

零信任決策需要一個單一事實來源。在大多數企業資產中，這意味著選擇管理人員、群組和生命週期事件的目錄，例如 Microsoft Entra ID、Google Workspace 或 Okta。重要的設計選擇不單是品牌，而是每個存取系統是否都能使用相同的身分狀態，並在該狀態變更時做出反應。

離開組織的使用者應在所有重要的位置失去存取權限。合約人員的任務結束後，不應因為管理員忘記移除獨立帳戶，而繼續在無線系統中保持啟用狀態。自動佈署和撤銷功能可將目錄變更轉化為營運控制，而非行政提醒。

驗證人員與裝置

首先從員工應用程式的 SSO 與 MFA 開始。MFA 能提高安全保障，而 SSO 則能減少使用者與服務台必須管理的認證資料數量。NCSC 特別建議圍繞 MFA 來設計 IAM，並考慮在合適的情況下採用無密碼驗證。無密碼方法能同時提升安全性與可用性，但需要具備復原程序、裝置註冊控制，以及針對遺失主要驗證器存取權限的使用者提供支援。

對於員工 WiFi，在維運上，基於憑證的身分驗證通常比共享密碼更強大。透過 WPA2 或 WPA3-Enterprise 以及 802.1X，網路可以將存取權限與已註冊的身分或裝置憑證進行繫結。這消除了分發通用金鑰的需求，並使撤銷操作更加精確。

裝置狀態評估補足了決策的後半部分。檢查裝置是否已託管、已加密、已修補、符合合規性並使用經過核准的憑證。使用未託管筆記型電腦的有效使用者，不應自動獲得與使用健康企業裝置的同一使用者相同的存取權限。

身分證明了是誰在請求存取。裝置安全狀態則決定了該存取請求是否足夠安全以予以核准。

設計生命週期事件，而非僅限於登入

入職流程應透過自動化工作流程建立目錄身分、分配正確的群組、註冊裝置並發行所需的憑證。離職流程則應停用身分、撤銷工作階段與憑證並移除網路存取權限，而無需等待個別的 WiFi 管理員進行處理。

合約人員需要不同的路徑。為他們提供範圍狹窄的群組成員資格、到期或審查程序，並且僅允許他們存取其工作所需的應用程式和網路區段。不要透過將合約人員放入廣泛的員工網路中來解決其便利性問題。

舊版裝置需要進行控制。當印表機、感測器或專用終端機無法使用憑證型身分驗證時，請使用專屬網段、嚴格定義的防火牆規則，以及受控的身分識別機制（例如個別預先共用金鑰）。這樣可以保持例外的可視性，並限制其影響範圍。

評估身分綁定網路存取的團隊可以將 identity-based networking 作為一種實施模式進行檢視。無論平台為何，架構原則都保持不變：目錄狀態、驗證強度和裝置狀態必須共同影響存取決策。

執行策略的區段劃分與安全 WiFi

網路分段是必要的，但它本身無法強制執行基於身分的存取。92% 受訪的英國組織表示他們在某種程度上對其網路進行了分段，而 98% 的組織表示他們計劃或已經實施了零信任。這項英國研究指出，網路分區非常普遍，但身分確認、持續驗證和原則強制執行仍需要關注。

VLAN 用於隔離流量。它並不會決定某個人員、裝置或工作階段是否應該保留存取權限。如果使用者從符合規範的筆記型電腦換到非受管裝置，除非存取系統重新評估身分與安全狀態，否則該裝置可能會留在同一個區段中。

比較成熟度層級

將 WiFi 視為身分邊界

WiFi 通常是裝置面臨的第一個企業存取決策。如果拖到專案後期才處理，將會導致目錄策略與實體連線之間產生落差。

針對員工，請使用搭配 802.1X 的 WPA2 或 WPA3-Enterprise，並以憑證或其他強身分識別方法為後盾。無密碼 WiFi 從使用者體驗中移除了共用秘密，而基於憑證的驗證則將連線能力與註冊的身分和裝置進行綁定。Passpoint 和 OpenRoaming 可以透過允許已註冊的裝置進行驗證而無需重複輸入密碼，進而支援安全漫遊。

目標是從第一個封包開始，就建立起加密且綁定身分的連線。在使用者接受條款後即授予廣泛存取權限的 Captive Portal，並無法提供這種控制力。

如需實用的 企業 WiFi 安全性 審查，請評估憑證分發、身分識別提供者整合、撤銷處理以及控制器相容性。該設計必須在整個場域中運作，包括 Meraki、Aruba、Ruckus、Mist 或 UniFi 設備。

訪客需要獨立的體驗與策略。提供不具備員工權限的網際網路存取。IoT 裝置則需要受限的策略，僅允許存取其運作所需的目標端與服務。

持續重新評估存取權限

NCSC 強調將持續重新評估、可觀測性和彈性作為明確的零信任要求。其 ZTNA 實施指南 支援在情境發生變化時變更存取權限，而不是在工作階段的生命週期內讓權限保持不變。

目錄整合必須支援自動撤銷。停用的帳戶、移除的群組成員資格或撤銷的憑證，都應該觸發原則更新，而無需等待個別的 WiFi 管理員進行介入。結果可能是升級驗證、移動到受限網路、應用程式封鎖或立即撤銷存取權限。

網路分割可圍堵資安事件。身分、裝置狀態和即時遙測資料將決定是否繼續允許存取。這種結合縮小了網路隔離與真正基於身分控制之間的差距。

部署監控並驗證每項存取決策

安全的部署是受控、可觀測且可逆的。不要一開始就在每個使用者、站點和裝置類別中強制執行新策略。先選擇一個低風險的群組或位置（但仍包含足夠的實際複雜度以暴露問題），在擴大範圍之前驗證該存取路徑。

在技術支援的情況下，從監控模式開始。擷取原則將允許和拒絕的內容，將這些決策與業務需求進行比較，並調查未知的相依關係。監控模式不能替代強制執行。這是在強制執行影響生產環境之前，消除可避免的意外的方法。

使用階段式遷移

實際的步驟順序如下所示：

1. 選擇界定明確的試點：選擇一個風險低、擁有者明確且支援管道清晰的應用程式、站點或使用者群組。
2. 記錄基準線：擷取成功與失敗的驗證、裝置狀態、憑證狀態、網路位置、原則結果以及應用程式結果。
3. 測試拒絕路徑：確認 MFA 失敗、已撤銷的憑證、已停用的目錄身分以及不合規的裝置皆會被阻擋。
4. 嚴格限制執行範圍：將原則套用至試點，並附帶已記錄的復原條件以及可還原變更的管理員。
5. 按相依性逐步擴大：只有在上一階段擁有穩定的記錄檔與經同意的支援流程之後，才新增群組、站點或服務。

試點應包含失敗測試。停用測試身分、移除其群組成員資格、將裝置標記為不合規，並撤銷其憑證。確認網路存取、應用程式存取和活動中的工作階段皆按設計做出反應。

讓遙測數據發揮作用

收集能解釋決策的事件，而不僅僅是證明連線已發生的事件。至少要將請求身分、裝置識別碼、驗證結果、憑證狀態、安全狀態評估結果、網路區段、目的資源、原則版本與最終決策進行關聯分析。

尋找需要人工審查的模式：

• 非預期的身分識別使用：使用者存取了超出其正常角色或核准群組範圍的資源。
• 合規狀態變更：原先合規的裝置失去了管理、加密或憑證狀態。
• 重複失敗：在多個帳戶或位置發生驗證或合規狀態失敗。
• 原則例外狀況：舊有裝置或服務重複依賴寬鬆的規則。
• 撤銷延遲：已停用的目錄身分識別仍繼續獲得網路或應用程式的存取權限。

在評估基於身分的 WiFi 平台如何處理存取資料、安全控制和營運可見度時，請參考 Purple 的資料與安全概述。無論您選擇什麼工具，儀表板都應該支援決策。無人審查的日誌無法改善強制執行。

復原條件：當策略阻礙了關鍵業務流程、建立不安全的相依關係或產生無法解釋的存取失敗時，請還原該策略。保留證據、修正設計並重新測試。切勿讓緊急例外狀況永久處於開放狀態。

將保護可用性視為安全性的一環

零信任取決於目錄、憑證服務、策略引擎、網路控制器和連線能力。請為每個相依關係建立復原能力。定義當身分識別提供者無法連線、憑證無法驗證、控制器故障或策略服務無法使用時的應對措施。

請謹慎使用故障安全（fail-safe）服務設計。某些環境需要現有的工作階段在身分服務中斷期間短暫保持連線。其他環境則應針對敏感資源立即限制存取。正確的選擇取決於資源、威脅模型和維運後果。

在強制執行前進行溝通。告知使用者將會發生哪些變更、他們將使用哪些登入方法、裝置註冊如何運作，以及在何處報告失敗。在每個階段之後追蹤客服中心的主題和存取分析。減少手動帳戶管理、減少共享憑證以及更快的撤銷，都是營運模式正在改善的實際指標。

您的零信任實作檢核表與後續步驟

一個可行的實施計劃應該要能列入下一次架構會議的議程中：

• 探索：盤點人員、服務帳戶、裝置、應用程式和服務。
• 繪製依賴關係圖：記錄資料流、身分驗證方法、舊版系統限制和維運擁有者。
• 定義界限：根據資源需求區分員工、訪客、IoT 和租戶存取權限。
• 強化身分識別：選擇目錄單一真實來源，強制執行 MFA 並導入 SSO。
• 採用更強大的身分驗證：引導適合的使用者和裝置走向無密碼與憑證型存取。
• 自動化生命週期：從目錄群組進行佈署，並在身分或憑證變更時撤銷存取權限。
• 評估安全狀態：在授予敏感存取權限之前，檢查管理、健康狀況和合規性。
• 保護 WiFi 安全：使用綁定身分的企業級驗證，取代共享的員工密碼。
• 控制舊版裝置：將例外裝置置於受限網段，並採用範圍狹窄的原則。
• 先監控：在觀察模式下執行試點原則，然後搭配復原標準強制執行。
• 持續驗證：測試拒絕存取、撤銷、安全狀態變更和服務故障。
• 審慎擴展：僅在記錄、所有權和支援流程準備就緒時，才新增站點和工作負載。

最關鍵的實作決策是順序安排。不要從最顯眼的產品或最大的網路區段開始。應從一個您可以理解、衡量和還原的流程開始。對於旅宿業和零售業，這可能意味著在營運場所中將員工、訪客與營運裝置進行隔離。對於醫療保健業，這可能意味著優先針對敏感應用程式周圍的身分識別與裝置控制進行強化。對於多住戶住宅，這可能意味著在提供簡便的住戶存取之餘，同時保持住戶與大樓系統之間的隔離。

當一個平台能夠消除真正的轉移障礙時，請選擇該平台。如果您的環境需要無密碼 WiFi、與目錄整合的員工存取、自動撤銷，並減少對本地 RADIUS 的依賴，請評估像是 Purple 這樣的平台是否符合現有的身分和網路架構。請讓這項決定與您的控制目標、整合需求和維運所有權保持一致。

透過證據而非部署公告來衡量進度。您應該要能夠顯示哪些身分擁有存取權限、哪些裝置是受信任的、哪些原則拒絕了請求、撤銷生效的速度有多快，以及在哪些地方仍存在例外情況。這就是零信任如何成為一種營運能力，而不是另一個停滯不前的安全計劃。

Purple 提供基於身分的 WiFi 和網路功能，可將員工和裝置連接到現有的目錄，支援無密碼和憑證級別的存取，並可在目錄狀態變更時自動執行佈建與撤銷。請造訪 Purple，評估其 WiFi 驗證、裝置安全狀態和網路整合如何支援階段式的零信任部署。