1.1 與聯邦機構相關的零信任努力的歷史#

早在「零信任」一詞被創造之前，零信任的概念就已經存在於網路安全中。國防資訊系統局 (DISA) 和國防部發布了有關更安全的企業戰略的研究成果，稱為「黑核心」[BCORE]。黑核涉及從基於邊界的安全模型轉變為專注於單一交易安全的模型。 Jericho 論壇 2004 年的工作公開了去邊界化的想法 — — 限制基於網絡位置的隱式信任以及依賴大型網段上的單一靜態防禦的局限性 [JERICHO]。去邊界化的概念演變並改進為更大的零信任概念，後來由John Kindervag[1] 在 Forrester 時提出[2]。隱含信任的網路位置，而是專注於評估每筆交易的信任。私人產業和高等教育也經歷了從基於邊界的安全到基於零信任原則的安全策略的演變。

十多年來，聯邦機構一直被敦促轉向基於零信任原則的安全，建立能力和政策，例如聯邦資訊安全現代化法案（Federal Information Security Modernization Act, FISMA）、風險管理框架（Risk Management Framework, RMF）、聯邦身分、憑證和存取管理 (Federal Identity, Credential, and Access Management, FICAM)、可信任網路連線（Trusted Internet Connections, TIC）、持續診斷和緩解（Continuous Diagnostics and Mitigation, CDM）計劃。所有這些計劃都旨在限制授權方存取資料和資源。這些項目啟動時，受到資訊系統技術能力的限制。安全策略基本上是靜態的，並在企業可以控制的大型「瓶頸」處執行，以獲得最大的工作效果。隨著技術的成熟，以動態和精細的方式持續分析和評估存取請求，以「需要存取」為基礎，以減輕由於帳戶受損、攻擊者監控網路和其他威脅而導致的資料外洩成為可能。

[1] https://go.forrester.com/blogs/next-generation-access-and-zero-trust/

[2] NIST 文件中提及的任何商業產品或服務僅供參考；它並不意味著 NIST 的推薦或認可。

1.2 本文件的結構#

該文件的其餘部分組織如下：

• 第 2 章定義了 ZT 和 ZTA，並列出了為企業設計 ZTA 時的一些假設。本節還包括 ZT 設計原則的清單。
• 第 3 章記錄了 ZT 的邏輯元件或建構塊。獨特的實作可能以不同的方式組成 ZTA 組件，但提供相同的邏輯功能。
• 第 4 章列出了一些可能的用例，其中 ZTA 可以使企業環境更加安全且不易被成功利用。其中包括擁有遠端員工、雲端服務和訪客網路的企業。
• 第 5 章討論使用 ZTA 的企業面臨的威脅。其中許多威脅與任何架構的網路相似，但可能需要不同的緩解技術。
• 第 6 章討論 ZTA 原則如何適應和/或補充聯邦機構的現有指南。
• 第 7 章介紹了企業（例如聯邦機構）轉型為 ZTA 的起點。這包括在 ZT 原則指導下規劃和部署應用程式和企業基礎設施所需的一般步驟的描述。

2.1 零信任原則#

ZT 的許多定義和討論都強調消除廣域外圍防禦（例如企業防火牆）這一概念。然而，大多數這些定義繼續以某種方式（例如微分段或微周界；參見第 3.1 節）將其定義為與周界相關，作為 ZTA 功能的一部分。下面嘗試從應該涉及而不是排除的基本原則來定義 ZT 和 ZTA。這些原則是理想的目標，但必須承認，對於給定的策略，並非所有原則都以其最純粹的形式充分實施。

零信任架構的設計和部署遵循以下零信任基本原則：

1. **所有資料來源和計算服務都被視為資源。**網路可以由多類設備組成。網路還可能具有向聚合器、儲存發送資料的小型設備、軟體即服務 (SaaS)、向執行器發送指令的系統以及其他功能。此外，如果個人擁有的設備可以存取企業擁有的資源，企業可能會決定將個人擁有的設備分類為資源。
2. **無論網路位置如何，所有通訊都是安全的。**網路位置本身並不意味著信任。來自位於企業擁有的網路基礎設施（例如，傳統網路邊界內）上的資產的存取請求必須滿足與來自任何其他非企業擁有的網路的存取請求和通訊相同的安全要求。換句話說，不應根據設備位於企業網路基礎設施上自動授予信任。所有通訊都應以最安全的方式進行，保護機密性和完整性，並提供來源身份驗證。
3. **各個企業資源的存取權限是按每個會話授予的。**在授予存取權限之前會評估對請求者的信任。也應該以完成任務所需的最少權限授予存取權限。對於該特定事務，這可能僅意味著「最近的某個時間」，並且可能不會在啟動會話或使用資源執行事務之前直接發生。但是，對一種資源的身份驗證和授權不會自動授予對不同資源的存取權限。
4. **對資源的存取由動態策略決定，包括客戶端身分、應用程式、服務和請求資產的可觀察狀態，並且可能包括其他行為和環境屬性。**組織透過定義它擁有哪些資源、其成員是誰（或對來自聯合社群的使用者進行身份驗證的能力）以及這些成員需要對資源的哪些存取權來保護資源。對於零信任，用戶端身分可以包括使用者帳戶（或服務身分）以及企業指派給該帳戶的任何關聯屬性或用於驗證自動化任務的工件。請求資產狀態可以包括設備特徵，例如安裝的軟體版本、網路位置、請求的時間/日期、先前觀察到的行為和安裝的憑證。行為屬性包括但不限於自動主題分析、設備分析以及與觀察到的使用模式的測量偏差。策略是基於組織分配給主題、資料資產或應用程式的屬性的一組存取規則。環境屬性可以包括請求者網路位置、時間、報告的主動攻擊等因素。資源存取和操作權限策略可能會根據資源、資料的敏感度而有所不同。應用最小權限原則來限制可見性和可訪問性。
5. **企業監控和測量所有擁有和相關資產的完整性和安全狀況。**沒有任何資產本質上是值得信賴的。企業在評估資源請求時評估資產的安全狀況。實施 ZTA 的企業應建立持續診斷和緩解 (CDM) 或類似系統來監控設備和應用程式的狀態，並應根據需要應用修補程式/修復。被發現被破壞、存在已知漏洞和/或不由企業管理的資產可能會受到與被視為屬於企業擁有或與企業相關的設備不同的對待（包括拒絕與企業資源的所有連接）。的狀態。這也可能適用於可能被允許存取某些資源但不允許存取其他資源的關聯設備（例如，個人擁有的設備）。這也需要一個強大的監控和報告系統來提供有關企業資源當前狀態的可操作數據。
6. **所有資源身份驗證和授權都是動態的，並且在允許存取之前嚴格執行。**這是獲取存取權限、掃描和評估威脅、適應並不斷重新評估持續通訊中的信任的持續循環。實施 ZTA 的企業預計將擁有身分、憑證和存取管理 (ICAM) 以及資產管理系統。這包括使用多重身份驗證 (MFA) 來存取部分或全部企業資源。在根據策略（例如，基於時間、請求新資源、資源修改、偵測到的異常主題活動）定義和執行的整個使用者交易過程中，持續監控可能的重新驗證和重新授權，力求實現安全性、可用性、可用性、和成本效益。
7. **企業收集盡可能多的有關資產、網路基礎設施和通訊當前狀態的信息，並利用這些資訊來改善其安全狀況。**企業應該收集有關資產安全狀況、網路流量和存取請求的數據，處理這些數據，並利用獲得的任何見解來改善策略的創建和執行。這些數據也可用於為受試者的訪問請求提供上下文（請參閱第 3.3.1 節）。

上述原則試圖與技術無關。例如，「使用者識別 (ID)」可能包括多個因素，例如使用者名稱、密碼、憑證和一次性密碼。這些原則適用於組織內部或與一個或多個合作夥伴組織合作完成的工作，不適用於匿名公眾或面向消費者的業務流程。組織不能將內部策略強加於外部參與者（例如客戶或一般網路使用者），但可以對與組織有特殊關係的非企業使用者（例如註冊客戶、員工家屬等）實施一些基於 ZT 的策略。

2.2 網路的零信任視圖#

對於在網路規劃和部署中使用 ZTA 的任何組織，網路連線都有一些基本假設。其中一些假設適用於企業擁有的網路基礎設施，有些適用於在非企業擁有的網路基礎設施（例如公共 Wi-Fi 或公有雲供應商）上運行的企業擁有的資源。這些假設用於指導 ZTA 的形成。實施 ZTA 的企業中的網路應根據上述 ZTA 原則和以下假設進行開發。

1. **整個企業私有網路不被視為隱式信任區域。**資產應始終表現得就像企業網路上存在攻擊者一樣，並且應以最安全的方式進行通訊（請參閱上面的原則 2）。這需要對所有連線進行身份驗證和對所有流量進行加密等操作。
2. **網路上的設備可能不是企業擁有或配置的。**訪客和/或合約服務可能包括需要網路存取才能履行其職責的非企業擁有的資產。這包括允許企業主體使用非企業擁有的裝置存取企業資源的自帶裝置 (BYOD) 策略。
3. **沒有任何資源本質上是可信的。**在向企業擁有的資源授予請求之前，每項資產都必須透過 PEP 評估其安全狀況（類似於上面針對資產和主體的原則 6）。只要會議持續，這種評估就應該持續進行。企業擁有的設備可能具有啟用身份驗證的工件，並提供比來自非企業擁有的設備的相同請求更高的置信等級。僅憑主體憑證不足以對企業資源進行設備身份驗證。
4. **並非所有企業資源都位於企業擁有的基礎設施上。**資源包括遠端企業主體以及雲端服務。企業擁有或管理的資產可能需要利用本地（即非企業）網路來實現基本連接和網路服務（例如 DNS 解析）。
5. **遠端企業主體和資產不能完全信任其本地網路連線。**遠端主體應假設本地（即非企業擁有的）網路是敵對的。資產應假設所有流量都受到監控並可能被修改。所有連接請求都應經過身份驗證和授權，並且所有通訊都應以盡可能最安全的方式進行（即提供機密性、完整性保護和來源身份驗證）。請參閱上面的 ZTA 原則。
6. **在企業和非企業基礎設施之間移動的資產和工作流程應具有一致的安全策略和狀態。**資產和工作負載在移入或移出企業擁有的基礎設施時應保持其安全狀態。這包括從企業網路移動到非企業網路的設備（即遠端用戶）。這也包括從本地資料中心遷移到非企業雲端實例的工作負載。

3.1 零信任架構方法的變體#

企業可以透過多種方式為工作流程製定 ZTA。這些方法在使用的組件和組織的策略規則的主要來源方面有所不同。每種方法都實現了 ZT 的所有原則（請參閱第 2.1 節），但可以使用一到兩個（或一個元件）作為政策的主要驅動力。完整的 ZT 解決方案將包括所有三種方法的要素。這些方法包括增強的身份治理驅動、邏輯微分段和基於網路的分段。

某些方法比其他方法更適合某些用例。希望為其企業開發 ZTA 的組織可能會發現其選擇的用例和現有策略指向一種方法而不是其他方法。這並不意味著其他方法不起作用，而是其他方法可能更難以實施，並且可能需要對企業目前進行業務流程的方式進行更根本的改變。

3.1.1 ZTA 使用增強身分治理#

發展 ZTA 的增強型身分治理方法使用參與者的身分作為政策創建的關鍵組成部分。如果不是主體請求存取企業資源，則無需建立存取策略。對於這種方法，企業資源存取策略是基於身分和指派的屬性。資源存取的主要要求是基於授予給定主體的存取權限。其他因素（例如使用的設備、資產狀態和環境因素）可能會改變最終的置信水準計算（以及最終的存取授權）或以某種方式自訂結果，例如根據網路位置僅授予對給定資料來源的部分存取權限。單一資源或保護資源的 PEP 元件必須有一種方法將請求轉送至策略引擎服務或對主體進行驗證並在授予存取權限之前批准請求。

針對企業的增強型基於身分治理的方法通常使用開放網路模型或具有訪客存取權限的企業網路或網路上頻繁的非企業設備（例如下面第 4.3 節中的用例）。網路存取權限最初授予所有資產，但企業資源的存取權限僅限於具有適當存取權限的身份。授予基本網路連線有一個缺點，因為惡意行為者仍然可以嘗試網路偵察和/或使用網路在內部或針對第三方發動拒絕服務攻擊。企業仍需要在此類行為影響工作流程之前對其進行監控和回應。

身分驅動的方法與資源入口網站模型（請參閱第 3.2.3 節）配合良好，因為裝置身分和狀態為存取決策提供了輔助支援資料。其他模型也有效，取決於現行政策。身份驅動的方法也適用於使用基於雲端的應用程式/服務的企業，這些應用程式/服務可能不允許使用企業擁有或經營的 ZT 安全元件（例如許多 SaaS 產品）。企業可以使用請求者的身分在這些平台上製定和執行策略。

3.1.2 ZTA 使用微分段#

企業可以選擇將單一或一組資源放置在受網關安全元件保護的唯一網段上來實施 ZTA。在這種方法中，企業放置智慧交換器（或路由器）或新一代防火牆（NGFW）或專用網關設備等基礎設施設備來充當保護每個資源或一小組相關資源的PEP。或者（或另外），企業可以選擇使用軟體代理（請參閱第 3.2.1 節）或端點資產上的防火牆來實現基於主機的微分段，這些網關設備動態地授予對來自客戶端的各個請求的存取權限、資產或服務。根據模型的不同，網關可能是唯一的 PEP 元件，也可能是由閘道器和用戶端代理程式組成的多部分 PEP 的一部分（請參閱第 3.2.1 節）。

此方法適用於各種用例和部署模型，因為保護設備充當 PEP，而對所述設備的管理充當 PE/PA 元件。此方法需要身分治理程序 (IGP) 才能充分發揮作用，但依賴網關元件可作為 PEP，保護資源免遭未經授權的存取和/或發現。

這種方法的關鍵必要性是 PEP 元件是受管理的，並且應該能夠根據需要做出反應和重新配置，以回應工作流程中的威脅或變更。透過使用不太先進的網關設備甚至無狀態防火牆來實現微分段企業的某些功能是可能的，但管理成本和快速適應變化的難度使得這是一個非常糟糕的選擇。

3.1.3 使用網路基礎設施和軟體定義邊界的 ZTA#

最後一種方法是使用網路基礎架構來實現 ZTA。 ZTA 實作可以透過使用覆蓋網路（即第 7 層，但也可以設定在 OSI 網路堆疊的較低層）來實現。這些方法有時被稱為軟體定義邊界 (SDP) 方法，並且經常包含軟體定義網路 (SDN) [SDNBOOK] 和基於意圖的網路 (IBN) [IBNVN] 中的概念。在此方法中，PA 可作為網路控制器，根據 PE 所做的決策來設定和重新配置網路。客戶端繼續透過 PEP 請求訪問，這些 PEP 由 PA 元件管理。

當此方法在應用網路層（即第 7 層）實現時，最常見的部署模型是代理/網關（請參閱第 3.2.1 節）。在此實作中，代理和資源閘道（充當單一 PEP 並由 PA 配置）建立用於客戶端和資源之間通訊的安全通道。此模型可能還有其他變體，也適用於雲端虛擬網路、非基於 IP 的網路等。

3.2 抽象架構的部署變體#

上述所有元件都是邏輯元件。它們不一定需要是獨特的系統。單一資產可以執行多個邏輯元件的職責，同樣，邏輯元件可以由多個硬體或軟體元素組成來執行任務。例如，企業管理的 PKI 可能由一個負責為裝置頒發憑證的元件和另一個用於向最終使用者頒發憑證的元件組成，但兩者都使用由同一企業根憑證授權單位所頒發的中間憑證。在目前市場上提供的一些 ZT 產品中，PE 和 PA 組件被組合在一項服務中。

此架構的選定組件的部署有多種變體，下面各節概述了這些變體。根據企業網路的設定方式，企業中的不同業務流程可能會使用多個 ZTA 部署模型。

3.2.1 基於設備代理/網關的部署#

在此部署模型中，PEP 分為兩個元件，它們駐留在資源上或作為直接位於資源前面的元件。例如，每個企業發行的資產都有一個安裝的設備代理來協調連接，每個資源都有一個直接放置在前面的元件（即網關），這樣資源只與網關通信，本質上充當了代理資源。代理程式是一個軟體元件，它將部分（或全部）流量引導至適當的 PEP，以便評估請求。網關負責與策略管理員進行通信，並僅允許策略管理員配置的核准的通訊路徑（請參閱圖 3）。

圖 3：設備代理/網關模型

在典型場景中，擁有企業發行的筆記型電腦的主體希望連接到企業資源（例如，人力資源應用程式/資料庫）。存取請求由本機代理程式接收，並將請求轉送給策略管理員。策略管理員和策略引擎可以是企業本地資產或雲端託管服務。策略管理員將請求轉送給策略引擎進行評估。如果請求被授權，則策略管理員透過控制平面配置裝置代理程式和相關資源閘道之間的通訊通道。這可能包括網際網路通訊協定 (IP) 位址、連接埠資訊、會話金鑰或類似的安全工件等資訊。然後設備代理和網關連接，加密的應用程式/服務資料流開始。當工作流程完成或因安全事件（例如會話逾時、重新驗證失敗）而由策略管理員觸發時，裝置代理程式和資源閘道之間的連線將會終止。

此模型最適合擁有強大的設備管理程序以及可與網關通訊的離散資源的企業。對於大量使用雲端服務的企業來說，這是雲端安全聯盟 (CSA) 軟體定義邊界 (SDP) [CSA-SDP] 的客戶端-伺服器實作。此模型也適用於不希望實施 BYOD 政策的企業。只能透過設備代理進行訪問，設備代理可以放置在企業擁有的資產上。

3.2.2 基於飛地的部署#

此部署模型是上述設備代理/網關模型的變體。在此模型中，網關元件可能不會駐留在資產或單一資源前面，而是駐留在資源飛地（例如本地資料中心）的邊界處，如圖4 所示。單一資源。這種部署模型對於使用基於雲端的微服務進行單一業務流程（例如，使用者通知、資料庫查找、工資支付）的企業也可能很有用。在此模型中，整個私有雲位於網關後面。

圖 4：Enclave 網關模型

此模型有可能與設備代理/網關模型混合。在此模型中，企業資產具有用於連接到飛地網關的裝置代理，但這些連接是使用與基本設備代理/網關模型相同的流程建立的。

此模型對於擁有舊應用程式或無法擁有單獨網關的本地資料中心的企業非常有用。企業需要一個強大的資產和組態管理程式來安裝/設定設備代理。缺點是網關保護一組資源，可能無法單獨保護每個資源。這也可以允許主體查看他們無權存取的資源。

3.2.3 基於資源入口網站的部署#

在此部署模型中，PEP 是充當主題請求網關的單一元件。網關入口網站可以用於單一資源，也可以用於單一業務功能的資源集合的安全飛地。一個範例是包含遺留應用程式的私有雲或資料中心的網關門戶，如圖 5 所示。

圖 5：資源門戶模型

與其他模型相比，此模型的主要優點是不需要在所有客戶端設備上安裝軟體元件。此模式對於 BYOD 政策和組織間協作專案也更加靈活。企業管理員無需確保每台設備在使用前都有合適的設備代理。然而，從請求存取的設備中可以推斷出有限的資訊。此模型只能在連接到 PEP 入口網站後掃描和分析資產和設備，並且可能無法持續監控它們是否存在惡意軟體、未修補的漏洞和適當的配置。

此模型的主要區別是沒有處理請求的本地代理，因此企業可能無法對資產具有完全可見性或任意控制，因為它只能在資產連接到入口網站時查看/掃描它們。企業可以採取瀏覽器隔離等措施來緩解或補償。在這些會話之間，這些資產對企業來說可能是看不見的。此模型還允許攻擊者發現並嘗試存取入口網站或嘗試對入口網站進行拒絕服務 (DoS) 攻擊。門戶系統應經過充分配置，以提供針對 DoS 攻擊或網路中斷的可用性。

3.2.4 設備應用沙箱#

代理/網關部署模型的另一個變體是在資產上劃分運行經過審查的應用程式或流程。這些隔間可以是虛擬機器、容器或其他一些實現，但目標是相同的：保護應用程式或應用程式實例免受可能受損的主機或資產上運行的其他應用程式的影響。

圖 6：應用程式沙箱

在圖 6 中，主題裝置在沙箱中執行經過批准、審查的應用程式。應用程式可以與 PEP 通訊以請求存取資源，但 PEP 將拒絕資產上其他應用程式的請求。在此模型中，PEP 可以是企業本地服務或雲端服務。

此模型變體的主要優點是單一應用程式與資產的其餘部分分開。如果無法掃描資產是否存在漏洞，則可以保護這些單獨的沙盒應用程式免受主機資產上潛在的惡意軟體感染。該模型的缺點之一是企業必須為所有資產維護這些沙盒應用程序，並且可能無法完全了解客戶資產。企業還需要確保每個沙盒應用程式都是安全的，這可能比簡單地監控設備需要更多的努力。

3.3 信任演算法#

對於部署ZTA的企業來說，策略引擎可以被認為是大腦，PE的信任演算法是其主要思考過程。信任演算法 (TA) 是策略引擎用於最終授予或拒絕對資源的存取的過程。策略引擎從多個來源取得輸入（請參閱第 3 節）：策略資料庫，其中包含有關主體、主體屬性和角色、歷史主體行為模式、威脅情報來源和其他元資料來源的可觀察資訊。過程可分為幾大類並如圖 7 所示。

圖 7：信任演算法輸入

在圖中，輸入可以根據它們向信任演算法提供的內容分為幾類。

• 存取請求：這是來自主題的實際請求。所請求的資源是所使用的主要訊息，但也使用有關請求者的信息。這可以包括作業系統版本、使用的軟體（例如，請求的應用程式是否出現在核准的應用程式清單中？）以及修補程式層級。根據這些因素和資產安全狀況，對資產的存取可能會受到限製或拒絕。
• 主題資料庫：這是請求存取資源的「誰」[SP800–63]。這是企業或合作者的主體（人員和流程）集合以及指派的主體屬性/權限的集合。這些主題和屬性構成了資源存取策略的基礎 [SP800–162] [NISTIR 7987]。使用者身分可以包括邏輯身分（例如帳戶 ID）和 PEP 執行的身份驗證檢查結果的組合。可以在推導置信水準時考慮的身份屬性包括時間和地理位置。授予多個主體的特權集合可以被視為一個角色，但特權應該基於個體分配給主體，而不僅僅是因為它們可能適合組織中的特定角色。該集合應該被編碼並儲存在ID管理系統和策略資料庫中。這也可能包括過去在某些 (TA) 變異中觀察到的受試者行為的數據（請參閱第 3.3.1 節）。
• 資產資料庫（和可觀察狀態）：這是包含每個企業擁有（以及可能已知的非企業/BYOD）資產（在某種程度上是實體和虛擬）的已知狀態的資料庫。這與發出請求的資產的可觀察狀態進行比較，並且可以包括作業系統版本、存在的軟體及其完整性、位置（網路位置和地理位置）和修補程式等級。根據與此資料庫相比的資產狀態，對資產的存取可能會受到限製或拒絕。
• 資源需求：這組策略補充了使用者 ID 和屬性資料庫 [SP800–63]，並定義了存取資源的最低要求。要求可能包括身份驗證器保證級別，例如 MFA 網路位置（例如，拒絕來自海外 IP 位址的存取）、資料敏感度和資產配置請求。這些要求應由資料保管人（即負責資料的人員）和負責使用資料的業務流程的人員（即負責任務的人員）共同製定。
• 威脅情報：這是有關互聯網上運行的一般威脅和活動惡意軟體的一個或多個資訊來源。這還可能包括有關從可能可疑的設備看到的通訊的特定資訊（例如對可能的惡意軟體命令和控制節點的查詢）。這些來源可以是外部服務或內部掃描和發現，並且可以包括攻擊特徵和緩解措施。這是唯一一個最有可能受到服務而不是企業控制的元件。

每個資料來源的重要性權重可以是專有演算法或可以由企業配置。這些權重值可以用來反映資料來源對企業的重要性。

最終決定將傳遞給 PA 執行。 PA 的工作是設定必要的 PEP 以啟用授權通訊。根據 ZTA 的部署方式，這可能涉及將驗證結果和連線設定資訊傳送到網關和代理或資源入口網站。 PA 還可以暫停或暫停通訊會話，以根據策略要求重新驗證和重新授權連線。 PA 也負責根據政策發出終止連線的命令（例如，在逾時後、由於安全警報而導致工作流程完成時）。

3.3.1 信任演算法變體#

實施 TA 的方法有多種。不同的實施者可能希望根據這些因素的重要性來不同地權衡上述因素。還有另外兩個主要特徵可以用來區分 TA。第一個是如何評估因素，無論是作為二元決策還是整個「分數」或置信水準的加權部分。第二個是如何相對於同一主題、應用程式/服務或裝置的其他請求來評估請求。

• 標準與基於分數：基於標準的 TA 假定在授予資源存取權限或允許執行操作（例如讀取/寫入）之前必須滿足一組合格屬性。這些標準由企業配置，並且應該為每個資源獨立配置。只有在滿足所有條件時，才會授予存取權限或對資源套用操作。基於分數的 TA 根據每個資料來源的值和企業配置的權重計算置信度。如果分數大於為資源配置的閾值，則授予存取權限，或執行操作。否則，請求將被拒絕，或存取權限將被降低（例如，授予檔案的讀取存取權限，但不授予寫入存取權限）。
• 單一與上下文：單一的助教單獨處理每個請求，並且在評估時不考慮主題歷史。這可以實現更快的評估，但如果攻擊停留在主體允許的角色範圍內，則存在未被偵測到的風險。上下文 TA 在評估存取請求時會考慮主體或網路代理的最近歷史記錄。這意味著 PE 必須維護所有主題和應用程式的一些狀態信息，但更有可能檢測到攻擊者使用被破壞的憑證以非 PE 所看到的給定主題的模式存取資訊。這也意味著 PE 必須透過主體在通訊時與之互動的 PA（和 PEP）來了解使用者行為。主體行為的分析可用於提供可接受的使用模型，而偏離此行為可能會觸發額外的身份驗證檢查或資源請求拒絕。

這兩個因素並不總是相互依賴。 TA 可以為每個主體和/或裝置分配置信級別，並且仍然獨立考慮每個存取請求（即單一）。然而，上下文、基於分數的 TA 將能夠提供更動態和更精細的存取控制，因為分數為請求帳戶提供了當前的置信水平，並且比人工管理員修改的靜態策略更快地適應不斷變化的因素。

理想情況下，ZTA 信任演算法應該是上下文相關的，但對於企業可用的基礎設施元件來說，這可能並不總是可行。上下文 TA 可以緩解攻擊者接近受感染主題帳戶或內部攻擊的「正常」存取請求集時的威脅。在定義和實現信任演算法時，平衡安全性、可用性和成本效益非常重要。持續提示主體針對符合其任務功能和組織內角色的歷史趨勢和規範的行為進行重新驗證可能會導致可用性問題。例如，如果機構人力資源部門的員工通常在一個典型工作日存取 20 到 30 筆員工記錄，那麼如果一天內的存取請求突然超過 100 筆記錄，上下文 TA 可能會發送警報。如果有人在正常工作時間之後發出存取請求，則上下文 TA 也可能會發送警報，因為這可能是攻擊者使用受損的 HR 帳戶竊取記錄。在這些例子中，上下文 TA 可以偵測到攻擊，而單一 TA 可能無法偵測到新行為。在另一個範例中，通常在正常工作時間存取財務系統的會計師現在試圖在半夜從無法識別的位置存取系統。情境 TA 可能會觸發警報，並要求受試者滿足更嚴格的置信水準或 NIST 特別出版物 800–63A [SP800–63A] 中概述的其他標準。

為每種資源製定一組標準或權重/閾值需要進行規劃和測試。企業管理員在 ZTA 的初始實施過程中可能會遇到問題，應批准的存取請求因配置錯誤而被拒絕。這將導致部署的初始“調整”階段。可能需要調整標準或評分權重，以確保策略得到執行，同時仍允許企業的業務流程正常運作。此調整階段持續多長時間取決於企業定義的進度指標以及對工作流程中使用的資源的錯誤存取拒絕/批准的容忍度。

3.4 網路/環境組件#

在 ZT 環境中，用於控制和配置網路的通訊流和用於執行組織實際工作的應用/服務通訊流應該分離（邏輯上或可能物理上）。這通常被分解為用於網路控制通訊的控制平面和用於應用程式/服務通訊流的資料平面[Gilman]。

控制平面由各種基礎設施組件（企業擁有的和來自服務提供者的）使用來維護和配置資產；判斷、授予或拒絕對資源的存取；並執行任何必要的操作以在資源之間建立通訊路徑。數據平面用於軟體組件之間的實際通訊。在透過控制平面建立路徑之前，該通訊通道可能是不可能的。例如，PA 和 PEP 可以使用控制平面來建立主體和企業資源之間的通訊路徑。然後，應用程式/服務工作負載將使用已建立的資料平面路徑。

3.4.1 支援 ZTA 的網路要求#

1. **企業資產具備基本的網路連結性。**區域網路 (LAN)，無論是否由企業控制，都提供基本的路由和基礎設施（例如 DNS）。遠端企業資產可能不一定使用所有基礎設施服務。
2. **企業必須能夠區分企業擁有或管理哪些資產以及設備目前的安全狀況。**這是由企業頒發的憑證決定的，而不是使用無法驗證的資訊（例如，可以欺騙的網路 MAC 位址）。
3. **企業可以觀察所有網路流量。**企業記錄在資料平面上看到的資料包，即使它無法對所有資料包執行應用層檢查（即 OSI 第 7 層）。企業過濾掉有關連線的元資料（例如目的地、時間、裝置身分）以動態更新策略並在評估存取要求時通知 PE。
4. **如果不存取 PEP，則不應存取企業資源。**企業資源不接受來自 Internet 的任意傳入連線。僅在客戶端經過身份驗證和授權後，資源才會接受自訂配置的連線。這些通訊路徑由 PEP 設定。如果不存取 PEP，資源甚至可能無法發現。這可以防止攻擊者透過掃描和/或對 PEP 後面的資源發動 DoS 攻擊來識別目標。請注意，並非所有資源都應該以這種方式隱藏；某些網路基礎架構元件（例如 DNS 伺服器）必須可存取。
5. **資料平面和控制平面在邏輯上是分開的。**策略引擎、策略管理員和 PEP 在邏輯上獨立且企業資產和資源無法直接存取的網路上進行通訊。資料平面用於應用程式/服務資料流量。策略引擎、策略管理員和 PEP 使用控制平面進行通訊並管理資產之間的通訊路徑。 PEP 必須能夠從資料平面和控制平面發送和接收訊息。
6. **企業資產可以到達PEP組件。**企業主體必須能夠存取 PEP 元件才能存取資源。這可以採用支援連接的企業資產上的入口網站、網路設備或軟體代理的形式。
7. **PEP 是作為業務流程一部分存取策略管理員的唯一元件。**在企業網路上運行的每個 PEP 都與策略管理員連接，以建立從客戶端到資源的通訊路徑。所有企業業務流程流量都會經過一個或多個 PEP。
8. **遠端企業資產應該能夠存取企業資源，而無需先遍歷企業網路基礎設施。**例如，不應要求遠端主體使用返回企業網路（即虛擬私人網路 [VPN]）的連結來存取企業使用的並由公有雲供應商託管的服務（例如電子郵件）。
9. 用於支援 ZTA 存取決策過程的基礎設施應具有可擴展性，以適應製程負載的變化。 ZTA 中使用的 PE、PA 和 PEP 成為任何業務流程中的關鍵元件。延遲或無法聯繫 PEP（或 PEP 無法聯繫 PA/PE）會對執行工作流程的能力產生負面影響。實施 ZTA 的企業需要為預期工作負載配置元件，或能夠快速擴展基礎架構以在需要時處理增加的使用量。
10. **由於政策或可觀察因素，企業資產可能無法達到某些PEP。**例如，可能有一項政策規定，如果請求的資產位於企業所在國家/地區之外，則行動資產可能無法存取某些資源。這些因素可能基於位置（地理位置或網路位置）、設備類型或其他標準。

4.1 擁有衛星設施的企業#

最常見的場景涉及具有單一總部和一個或多個地理上分散的位置的企業，這些位置不透過企業擁有的實體網路連接連接（參見圖 8）。遠端位置的員工可能沒有完整的企業擁有的本地網絡，但仍需要存取企業資源來執行其任務。企業可能具有到企業總部網路的多協定標籤交換（MPLS）鏈路，但可能沒有足夠的頻寬來處理所有流量，或者可能不希望發送到基於雲端的應用程式/服務的流量穿過企業總部網路。同樣，員工可能會遠端辦公或在遠端位置並使用企業擁有或個人擁有的設備。在這種情況下，企業可能希望授予對某些資源（例如，員工行事曆、電子郵件）的存取權限，但拒絕存取或限制對更敏感資源（例如，人力資源資料庫）的操作。

在此用例中，PE/PA 通常作為雲端服務託管（通常提供卓越的可用性，並且不需要遠端工作人員依賴企業基礎設施來存取雲端資源），終端資產安裝有代理（請參閱第3.2.1 節）或存取資源入口網站（請參閱第3.2.3 節）。將 PE/PA 託管在企業本地網路上可能不是最敏感的，因為遠端辦公室和工作人員必須將所有流量發送回企業網路才能到達雲端服務託管的應用程式/服務。

圖 8：擁有遠距員工的企業

4.2 多雲/雲端企業#

部署 ZTA 的一種日益常見的用例是利用多個雲端供應商的企業（請參閱圖 9）。在此用例中，企業擁有本地網絡，但使用兩個或更多雲端服務提供者來託管應用程式/服務和資料。有時，應用程式/服務託管在與資料來源分離的雲端服務上。為了提高效能和易於管理，雲端供應商 A 中託管的應用程式應該能夠直接連接到雲端提供者 B 中託管的資料來源，而不是強制應用程式透過企業網路隧道返回。

圖 9：多雲案例

此用例是 CSA 軟體定義邊界 (SDP) 規範 [CSA-SDP] 的伺服器伺服器實作。隨著企業轉向更多雲端託管應用程式和服務，依賴企業邊界來確保安全顯然成為一種負擔。如第 2.2 節所討論的，ZT 原則認為企業擁有和營運的網路基礎設施與任何其他服務提供者擁有和營運的基礎設施之間不應有任何區別。多雲使用的零信任方法是將 PEP 放置在每個應用程式/服務和資料來源的存取點。 PE 和 PA 可以是位於雲端甚至第三方雲端提供者中的服務。然後，用戶端（透過入口網站或本機安裝的代理程式）直接存取 PEP。這樣，即使託管在企業外部，企業仍然可以管理對資源的存取。一項挑戰是不同的雲端供應商有獨特的方法來實現類似的功能。企業架構師需要了解如何與他們使用的每個雲端供應商一起實施企業 ZTA。

4.3 擁有合約服務和/或非員工存取權限的企業#

另一個常見的場景是，企業中包括現場訪客和/或簽約服務供應商，他們需要有限的訪問企業資源才能完成工作（請參閱圖 10）。例如，企業擁有自己的內部應用程式/服務、資料庫和資產。其中包括外包給偶爾在現場提供維護的提供者的服務（例如，由外部提供者擁有和管理的智慧暖氣和照明系統）。這些訪客和服務提供者將需要網路連線來執行他們的任務。零信任企業可以透過允許這些設備和任何來訪的服務技術人員存取互聯網，同時隱藏企業資源來促進這一點。

圖 10：具有非員工存取權限的企業

在此範例中，該組織還有一個會議中心，訪客可以在其中與員工互動。同樣，透過 SDP 的 ZTA 方法，員工設備和主體是有區別的，並且可能能夠存取適當的企業資源。園區訪客可以上網，但無法存取企業資源。他們甚至可能無法透過網路掃描發現企業服務（即阻止主動網路偵察/東西向移動）。

在此用例中，PE 和 PA 可以託管為雲端服務或託管在 LAN 上（假設很少或根本不使用雲端託管服務）。企業資產可以安裝代理程式（請參閱第 3.2.1 節）或透過入口網站存取資源（請參閱第 3.2.3 節）。 PA 確保所有非企業資產（未安裝代理或無法連接到入口網站的資產）無法存取本地資源，但可以存取網際網路。

4.4 跨企業邊界的協作#

第四個用例是跨企業協作。例如，有一個專案涉及企業A和企業B的員工（見圖11）。這兩個企業可能是獨立的聯邦機構（G2G），甚至可能是聯邦機構和私人企業（G2B）。企業A營運專案所使用的資料庫，但必須允許企業B的某些成員存取資料。很快就會變得難以管理。讓兩個組織都註冊到聯合 ID 管理系統將允許更快地建立這些關係，前提是兩個組織的 PEP 都可以對聯合 ID 社群中的主體進行身份驗證。

圖 11：跨企業協作

此場景可能類似於用例 1（第 4.1 節），因為兩家企業的員工可能都不位於其組織的網路基礎架構上，而他們需要存取的資源可能位於一個企業環境內或託管在雲端。這意味著不需要複雜的防火牆規則或企業範圍的存取控制清單（ACL）來允許屬於企業B的某些IP位址根據企業A的存取策略存取企業A中的資源。如何實現這種訪問取決於所使用的技術。與用例 1 類似，作為雲端服務託管的 PE 和 PA 可以向所有當事人提供可用性，而無需建立 VPN 或類似裝置。企業 B 的員工可能會被要求在其資產上安裝軟體代理程式或透過 Web 閘道存取必要的資料資源（請參閱第 3.2.3 節）。

4.5 提供面向公眾或客戶的服務的企業#

許多企業的共同特徵是面向公眾的服務，可能包括或不包括使用者註冊（即使用者必須建立或已獲得一組登入憑證）。此類服務可以面向公眾、一組具有現有業務關係的客戶或一組特殊的非企業用戶（例如員工家屬）。在所有情況下，所要求的資產很可能不屬於企業所有，企業在可以執行哪些內部網路安全策略方面受到限制。

對於不需要登入憑證即可存取的一般面向公眾的資源（例如公開網頁），ZTA 的原則並不直接適用。企業無法嚴格控制請求資產的狀態，且匿名公共資源（例如公共網頁）不需要憑證即可存取。

企業可以為註冊公共用戶，例如客戶（即具有業務關係的用戶）和特殊用戶（例如員工家屬）制定政策。如果要求使用者出示或頒發憑證，企業可以製定有關密碼長度、生命週期和其他詳細資訊的策略，並可以提供 MFA 作為選項或要求。然而，企業針對此類使用者可以實施的政策是有限的。有關傳入請求的資訊可能有助於確定公共服務的狀態並偵測偽裝成合法使用者的可能攻擊。例如，已知註冊用戶入口網站可以由註冊客戶使用一組常見網頁瀏覽器中的一個來存取。來自未知瀏覽器類型或已知過時版本的存取請求突然增加可能表示某種類型的自動攻擊，企業可以採取措施限制來自這些已識別客戶端的請求。企業還應了解有關可以收集和記錄有關請求使用者和資產的哪些資訊的任何法律或法規。

5.1 ZTA決策流程的顛覆#

在ZTA中，策略引擎和策略管理器是整個企業的關鍵元件。除非得到 PE 和 PA 的批准並可能進行配置，否則企業資源之間不會發生通訊。這意味著必須正確配置和維護這些組件。任何有權配置 PE 規則的企業管理員都可能執行未經批准的變更或犯下可能擾亂企業營運的錯誤。同樣，受損的 PA 可能允許存取原本不會被批准的資源（例如，被破壞的個人擁有的設備）。降低相關風險意味著必須正確配置和監控 PE 和 PA 組件，並且必須記錄任何配置變更並接受審核。

5.2 拒絕服務或網路中斷#

在ZTA中，PA是資源存取的關鍵元件。如果沒有 PA 的許可以及可能的配置操作，企業資源無法相互連接。如果攻擊者破壞或拒絕對 PEP 或 PE/PA 的存取（即 DoS 攻擊或路由劫持），可能會對企業營運產生不利影響。企業可以透過將策略執行駐留在適當安全的雲端環境中或遵循網路彈性指南 [SP 800–160v2] 在多個位置進行複製來減輕這種威脅。

這減輕了風險，但並沒有消除風險。 Mirai 等殭屍網路對主要網路服務供應商發動大規模 DoS 攻擊，並中斷數百萬網路使用者的服務[5]。 分支機構甚至單一遠端員工）。在這種情況下，只有部分企業主體受到影響。這在傳統遠端存取 VPN 中也是可能的，並且並非 ZTA 獨有。

託管提供者也可能會意外地使基於雲端的 PE 或 PA 離線。雲端服務過去曾經歷過中斷，無論是基礎設施即服務 (IaaS)[6] 還是 SaaS[7]。

也存在 PA 可能無法存取企業資源的風險，因此即使授予主體存取權限，PA 也無法配置來自網路的通訊路徑。這可能是由於 DDoS 攻擊或僅由於意外的大量使用而發生的。這與任何其他網路中斷類似，因為某些或所有企業主體由於某種原因不可用而無法存取特定資源。

[5]https://blog.cloudflare.com/inside-mirai-the-infamous-iot-botnet-a-retrospective-analysis/

[6] https://aws.amazon.com/message/41926/

[7] https://www.nzherald.co.nz/business/news/article.cfm?c_id=3&objectid=12286870

5.3 憑證被竊/內部威脅#

正確實施 ZT、資訊安全和彈性策略以及最佳實踐可以降低攻擊者透過被盜憑證或內部攻擊獲得廣泛存取權限的風險。基於網路位置的無隱式信任的 ZT 原則意味著攻擊者需要破壞現有帳戶或設備才能在企業中獲得立足點。正確開發和實施的 ZTA 應防止受感染的帳戶或資產存取其正常權限或存取模式以外的資源。這意味著針對攻擊者感興趣的資源製定存取策略的帳戶將成為攻擊者的主要目標。

攻擊者可能會使用網路釣魚、社會工程或攻擊組合來獲取有價值帳戶的憑證。根據攻擊者的動機，「有價值」可能有不同的意義。例如，企業管理員帳戶可能很有價值，但對經濟利益感興趣的攻擊者可能會考慮有權存取同等價值的財務或支付資源的帳戶。對存取請求實施 MFA 可以降低因帳戶受損而導致資訊遺失的風險。但是，具有有效憑證的攻擊者（或惡意內部人員）仍然可能能夠存取該帳戶已被授予存取權限的資源。例如，擁有有效人力資源員工的憑證和企業擁有的資產的攻擊者或受感染的員工可能仍然能夠存取員工資料庫。

ZTA 降低了風險並防止任何受損的帳戶或資產在整個網路中橫向移動。如果洩漏的憑證無權存取特定資源，他們將繼續被拒絕存取該資源。此外，與傳統的基於邊界的網路中發生的攻擊相比，上下文信任演算法（請參閱第 3.3.1 節）更有可能偵測到這種攻擊並快速回應。情境 TA 可以偵測異常行為的存取模式，並拒絕受損帳戶或內部威脅對敏感資源的存取。

5.4 網路可見性#

如第 3.4.1 節所述，所有流量都會在網路上進行檢查和記錄，並進行分析，以識別針對企業的潛在攻擊並做出反應。然而，如也所提到的，企業網路上的一些（可能是大部分）流量可能對第 3 層網路分析工具不透明。此流量可能源自非企業擁有的資產（例如，使用企業基礎設施存取網際網路的合約服務）或抵抗被動監控的應用程式/服務。無法執行深度資料包檢查或檢查加密流量的企業，必須使用其他方法來評估網路上可能的攻擊者。

這並不意味著企業無法分析其在網路上看到的加密流量。企業可以收集有關加密流量的元資料（例如來源位址和目標位址等），並使用它來偵測網路上通訊的活躍攻擊者或可能的惡意軟體。機器學習技術[Anderson]可用於分析無法解密和檢查的流量。採用這種類型的機器學習將允許企業將流量分類為有效或可能惡意並進行修復。

5.5 系統和網路資訊的存儲#

對企業網路流量監控和分析的一個相關威脅是分析元件本身。如果儲存監控掃描、網路流量和元資料用於建立上下文策略、取證或後續分析，則該資料將成為攻擊者的目標。就像網路圖、設定檔和其他各種網路架構文件一樣，這些資源應該受到保護。如果攻擊者能夠成功存取此訊息，他們也許能夠深入了解企業架構並識別資產以進行進一步的偵察和攻擊。

ZT企業中攻擊者偵察資訊的另一個來源是用來編碼存取策略的管理工具。與儲存的流量一樣，此元件包含對資源的存取策略，並且可以向​​攻擊者提供有關哪些帳戶最容易受到攻擊的資訊（例如，有權存取所需資料資源的帳戶）。

對於所有有價值的企業數據，應採取足夠的保護措施，以防止未經授權的存取和存取嘗試。由於這些資源對於安全性至關重要，因此它們應該具有最嚴格的存取策略，並且只能透過指定或專用的管理員帳戶進行存取。

5.6 對專有資料格式或解決方案的依賴#

ZTA 依賴多個不同的資料來源來做出存取決策，包括有關請求主體、所使用的資產、企業和外部情報以及威脅分析的資訊。通常，用於儲存和處理這些資訊的資產對於如何互動和交換資訊沒有通用的、開放的標準。這可能會導致企業因互通性問題而被鎖定在部分提供者的情況下。如果一個提供者有安全問題或中斷，企業可能無法在不付出極高成本（例如，更換多項資產）或經歷長期過渡計畫（例如，將策略規則從一種專有格式轉換為一種專有格式）的情況下遷移到新的提供者。與 DoS 攻擊一樣，這種風險並非 ZTA 所獨有，但由於 ZTA 嚴重依賴資訊的動態存取（企業和服務提供者），因此中斷可能會影響企業的核心業務功能。為了降低相關風險，企業除了考慮效能、穩定性等更典型的因素外，還應考慮供應商安全控制、企業轉換成本和供應鏈風險管理等因素，對服務提供者進行整體評估。

5.7 在 ZTA 管理中使用非人實體 (NPE)#

正在部署人工智慧和其他基於軟體的代理來管理企業網路上的安全問題。這些元件需要與 ZTA 的管理元件（例如策略引擎、策略管理員）進行交互，有時取代人工管理員。這些元件如何在實施 ZTA 的企業中驗證自身身分是一個懸而未決的問題。假設大多數自動化技術系統在使用 API 來取得資源元件時將使用某種方式進行身份驗證。

使用自動化技術進行配置和策略實施時，最大的風險是誤報（誤認為攻擊的無害行為）和漏報（誤認為正常活動的攻擊）可能會影響企業的安全狀況。透過定期重新調整分析來糾正錯誤決策並改善決策過程可以減少這種情況。

相關風險是攻擊者將能夠誘導或強制 NPE 執行攻擊者無權執行的某些任務。與人類使用者相比，軟體代理執行管理或安全相關任務的身份驗證門檻可能較低（例如，API 金鑰與 MFA）。如果攻擊者可以與代理交互，理論上他們可以誘騙代理允許攻擊者進行更大的訪問或代表攻擊者執行某些任務。也存在攻擊者可能取得軟體代理憑證並在執行任務時冒充代理程式的風險。

6.1 ZTA 和 NIST 風險管理框架#

ZTA 部署涉及圍繞指定任務或業務流程的可接受風險制定存取策略（請參閱第 7.3.3 節）。可以拒絕對資源的所有網路存取並僅允許透過連接的終端進行訪問，但這在大多數情況下限制性過大，並且可能會阻礙工作的完成。對於聯邦機構履行其使命而言，存在可接受的風險等級。必須識別和評估與執行給定任務相關的風險，並接受或減輕這些風險。為此，開發了 NIST 風險管理框架 (RMF) [SP800–37]。

ZTA規劃和實施可能會改變企業定義的授權邊界。這是由於增加了新元件（例如策略引擎、策略管理員和 PEP）以及減少了對網路外圍防禦的依賴。 RMF 中所述的整體流程在 ZTA 中不會改變。

6.2 零信任與 NIST 隱私框架#

保護使用者隱私和私人資訊（例如個人識別資訊）是組織的首要關注點。隱私和資料保護包含在 FISMA 和健康保險流通與責任法案 (HIPAA) 等合規計畫中。作為回應，NIST 制定了供組織使用的隱私框架 [NISTPRIV]。本文檔提供了一個描述隱私風險和緩解策略的框架，以及企業識別、衡量和緩解組織儲存和處理的使用者隱私和私人資訊風險的流程。這包括企業用於支援 ZTA 操作的個人資訊以及存取請求評估中使用的任何生物識別屬性。

ZT 的部分核心要求是企業應檢查和記錄其環境中的流量（或至少在處理監控系統無法解密的流量時記錄和檢查元資料）。其中一些流量可能包含私人資訊或具有相關的隱私風險。組織需要識別與攔截、掃描和記錄網路流量相關的任何可能的風險 [NISTIR 8062]。這可能包括通知使用者、取得同意（透過登入頁面、橫幅或類似內容）以及教育企業使用者等操作。 NIST 隱私框架 [NISTPRIV] 可以協助開發正式流程來識別和減輕開發零信任架構的企業所面臨的任何與隱私相關的風險。

6.3 ZTA 和聯邦身分、憑證和存取管理架構#

主題配置是 ZTA 的關鍵組成部分。如果 PE 沒有足夠的資訊來識別關聯的主體和資源，則策略引擎無法確定嘗試的連線是否被授權連接到資源。在轉向更加零信任的部署之前，需要製定強大的主題配置和身份驗證策略。企業需要一套清晰的主題屬性和策略，PE 可以使用它們來評估存取請求。

管理和預算辦公室 (OMB) 發布了關於改善聯邦政府身分管理的 M-19–17。該政策的目標是製定「…作為國家任務交付、信任和安全推動者的共同願景」[M-19–17]。該備忘錄呼籲所有聯邦機構成立 ICAM 辦公室來管理與身分發放和管理相關的工作。其中許多管理策略應使用 NIST SP 800–63–3，數位身分指南 [SP800–63] 中的建議。由於 ZTA 嚴重依賴精確的身分管理，任何 ZTA 工作都需要整合該機構的 ICAM 政策。

6.4 ZTA 和可信任網路連線 3.0#

TIC 是一項聯邦網路安全計劃，由 OMB、DHS 和總務管理局 (GSA) 共同管理，旨在建立整個聯邦政府的網路安全基線。從歷史上看，TIC 是一種基於邊界的網路安全策略，要求各機構整合和監控其外部網路連接。 TIC 1.0 和 TIC 2.0 固有的假設是邊界內部是“受信任的”，而 ZTA 則假設網絡位置不能推斷“信任”（即機構的內部網絡上不存在“信任”）。 TIC 2.0 提供了一系列基於網路的安全功能（例如內容過濾、監控、身份驗證等），可部署在機構週邊的 TIC 接入點；其中許多功能都符合 ZT 原則。

TIC 3.0 已更新以適應雲端服務和行動裝置 [M-19–26]。在 TIC 3.0 中，人們認識到「信任」的定義可能會因特定的計算環境而異，並且各機構對於定義信任區域具有不同的風險承受能力。此外，TIC 3.0也更新了TIC安全能力手冊，定義了兩類安全能力：（1）應用於企業級的一般安全能力，（2）應用於網路層級的PEP安全能力多個策略執行點(PEP) ，如TIC 用例中所定義。 PEP 安全功能可以應用於沿著給定資料流定位的任何適當的 PEP，而不是應用於機構週邊的單一 PEP。其中許多 TIC 3.0 安全功能直接支援 ZTA（例如，加密流量、強式身分驗證、微分段、網路和系統清單等）。 TIC 3.0 定義了特定的用例，描述跨特定應用程式、服務和環境的信任區域和安全功能的實施。

TIC 3.0 專注於基於網路的安全保護，而 ZTA 是一個更具包容性的架構，可解決應用程式、使用者和資料保護問題。隨著 TIC 3.0 不斷發展其用例，很可能會開發 ZTA TIC 用例來定義要在 ZTA 執行點部署的網路保護。

6.5 ZTA 與 EINSTEIN（NCPS－國家網路安全保護系統）#

NCPS（操作上稱為 EINSTEIN）是一個整合的系統系統，可提供入侵偵測、進階分析、資訊共享和入侵防禦功能，以保護聯邦政府免受網路威脅。 NCPS 的目標與零信任的總體目標一致，即管理網路風險、改善網路保護並幫助合作夥伴保護網路空間。愛因斯坦感測器使 CISA 的國家網路安全和通訊整合中心 (NCCIC) 能夠保護聯邦網路並回應聯邦機構的重大事件。

用於 DHS 態勢感知的 NCPS 感測器的放置是基於聯邦政府的周邊網路防禦，而 ZTA 將保護措施移至更靠近資產、數據和所有其他資源的位置。 NCPS 計劃正在不斷發展，以確保透過利用有關基於雲端的流量的安全資訊來保留態勢感知，從而幫助為 ZTA 系統擴展態勢感知遙測奠定基礎。 NCPS 入侵防禦功能也需要不斷發展，以便能夠為當前 NCPS 位置以及 ZTA 系統的策略執行提供資訊。隨著 ZTA 在聯邦政府中被採用，NCPS 的實施需要不斷發展，或者需要部署新的功能來實現 NCPS 的目標。事件回應者可能會利用已實施零信任架構的聯邦機構可用的身份驗證、流量檢查和機構流量記錄的資訊。 ZTA 中產生的資訊可以更好地為事件影響量化提供資訊；機器學習工具可以使用 ZTA 資料來改善檢測；並且可以保存來自 ZTA 的其他日誌，以便事件回應人員進行事後分析。

6.6 ZTA 和 DHS 持續診斷和緩解 (CDM) 計劃#

DHS CDM 計劃旨在改善聯邦機構資訊科技 (IT)。對於這種姿態至關重要的是機構對自身資產、配置和主題的洞察力。為了保護系統，各機構需要建立流程來發現和了解其基礎設施中的基本組件和參與者：

• 連結了什麼？組織使用哪些裝置、應用程式和服務？這包括在發現漏洞和威脅時觀察和改進這些工件的安全狀況。
• 誰在使用網路？哪些使用者是組織的一部分或外部的並被允許存取企業資源？其中包括可能執行自主操作的 NPE。
• 網路上發生了什麼事？企業需要深入了解系統之間的流量模式和訊息。
• 資料如何受到保護？企業需要製定一套策略來保護靜態、傳輸和使用中的資訊。

強而有力的 CDM 計畫實施是 ZTA 成功的關鍵。例如，要遷移到 ZTA，企業必須擁有一個系統來發現和記錄實體和虛擬資產，以建立可用的庫存。 DHS CDM 計劃已發起多項努力，以建立聯邦機構內轉向 ZTA 所需的能力。例如，DHS 硬體資產管理 (HWAM) [HWAM] 計畫旨在協助各機構識別其網路基礎架構上的裝置以部署安全性配置。這類似於製定 ZTA 路線圖的第一步。機構必須了解網路上活動的資產（或遠端存取資源的資產），以對網路活動進行分類、配置和監控。

6.7 ZTA、雲端智慧與聯邦資料策略#

雲端智慧[8]策略、更新的資料中心最佳化計畫 [M-19–19] 政策和聯邦資料策略[9]都會影響規劃 ZTA 的機構的一些要求。這些政策要求各機構盤點並評估他們如何在本地和雲端收集、儲存和存取資料。

此清單對於確定哪些業務流程和資源將從實施 ZTA 中受益至關重要。主要基於雲端或主要由遠端工作人員使用的資料資源以及應用程式和服務是ZTA 方法的良好候選者（請參閱第7.3.3 節），因為主題和資源位於企業網路邊界之外，並且可能會觀看到在使用、可擴展性和安全性方面具有最大的優勢。

聯邦數據戰略的另一項考慮是如何使其他機構或公眾可以存取機構數據資產。這與跨企業協作 ZTA 用例相對應（請參閱第 4.4 節）。對這些資產使用 ZTA 的機構在製定策略時可能需要考慮協作或發布要求。

[8] 聯邦雲端運算策略：https://cloud.cio.gov/strategy/

[9] 聯邦資料策略：https://strategy.data.gov/

7.1 純粹的零信任架構#

在全新方法中，可以從頭開始建立零信任架構。假設企業知道它想要用於其操作的應用程式/服務和工作流程，它可以為這些工作流程產生基於零信任原則的架構。一旦確定了工作流程，企業就可以縮小所需元件的範圍，並開始規劃各個元件如何互動。從那時起，這是建立基礎設施和配置組件的工程和組織練習。這可能包括額外的組織變革，具體取決於企業目前的設置和運作方式。

實際上，對於聯邦機構或任何擁有現有網路的組織來說，這很少是一個可行的選擇。然而，有時組織可能會被要求履行新的職責，需要建立自己的基礎設施。在這些情況下，也許可以在某種程度上引入 ZT 概念。例如，一個機構可能被賦予一項新的職責，需要建立新的應用程式、服務或資料庫。該機構可以圍繞 ZT 原則和安全系統工程 [SP8900–160v1] 設計新需要的基礎設施，例如在授予存取權限之前評估主體的信任度並圍繞新資源建立微邊界。成功程度取決於新基礎設施對現有資源（例如 ID 管理系統）的依賴程度。

7.2 混合 ZTA 和基於邊界的架構#

任何重要的企業都不可能在單一技術更新周期內遷移到零信任。 ZTA工作流程與非ZTA工作流程在企業中共存的時間可能是無限期的。企業向 ZTA 方法的遷移可能一次只發生一個業務流程。企業需要確保通用元素（例如 ID 管理、設備管理、事件日誌記錄）足夠靈活，能夠在 ZTA 和基於邊界的混合安全架構中運作。企業架構師可能還希望將 ZTA 候選解決方案限制為能夠與現有元件互動的解決方案。

將現有工作流程遷移到 ZTA 可能需要（至少）部分重新設計。如果企業尚未針對工作流程採取安全系統工程 [SP800–160v1] 實踐，則可以藉此機會採用。

7.3 將 ZTA 引入基於外圍的架構網路的步驟#

遷移到 ZTA 要求組織詳細了解其資產（實體和虛擬）、主題（包括使用者權限）和業務流程。 PE 在評估資源請求時存取這些知識。不完整的知識通常會導致業務流程失敗，其中 PE 由於資訊不足而拒絕請求。如果組織內存在未知的「影子 IT」部署，這尤其是一個問題。

在嘗試將 ZTA 引入企業之前，應該對資產、主題、資料流和工作流程進行調查。這種意識構成了 ZTA 部署之前必須達到的基本狀態。如果不了解目前的營運狀態，企業就無法確定需要採用哪些新流程或系統。這些調查可以並行進行，但兩者都與組織業務流程的檢查有關。這些步驟可以對應到 RMF [SP800–37] 中的步驟，因為 ZTA 的任何採用都是降低機構業務職能風險的過程。實施 ZTA 的路徑如圖 12 所示。

圖 12：ZTA 部署週期

建立初始庫存後，就會有一個定期的維護和更新週期。此更新可能會改變業務流程，也可能不會產生任何影響，但應對業務流程進行評估。例如，數位憑證提供者的變更可能不會產生重大影響，但可能涉及憑證根儲存管理、憑證透明度日誌監控以及其他一開始並不明顯的因素。

7.3.1 辨識企業中的參與者#

零信任企業要經營，PE必須具備企業主體知識。主題可以包含人類和可能的 NPE，例如與資源互動的服務帳戶。

具有特殊權限的使用者（例如開發人員或系統管理員）在指派屬性或角色時需要進行額外的審查。在許多傳統安全架構中，這些帳戶可能具有存取所有企業資源的全面權限。 ZTA應該允許開發人員和管理員有足夠的靈活性來滿足他們的業務需求，同時使用日誌和稽核操作來識別存取行為模式。 ZTA 部署可能要求管理員滿足 NIST SP 800–63A 第 5 節 [SP800–63A] 中概述的更嚴格的置信水準或標準。

7.3.2 識別企業擁有的資產#

如2.1節所述，ZTA的關鍵要求之一是識別和管理設備的能力。 ZTA 還需要能夠識別和監控可能位於企業擁有的網路基礎架構上或存取企業資源的非企業擁有的設備。管理企業資產的能力是ZTA成功部署的關鍵。這包括硬體元件（例如筆記型電腦、手機、物聯網設備）和數位工件（例如使用者帳戶、應用程式、數位憑證）。不可能對所有企業擁有的資產進行完​​整的普查，因此企業應該考慮建立快速識別、分類和評估企業擁有的基礎設施上新發現的資產的能力。

這不僅僅是簡單地編目和維護企業資產資料庫。這也包括組態管理和監控。觀察資產目前狀態的能力是評估存取請求過程的一部分（請參閱第 2.1 節）。這意味著企業必須能夠配置、調查和更新企業資產，例如虛擬資產和容器。這還包括其物理位置（根據最佳估計）和網路位置。該資訊應在 PE 做出資源存取決策時告知。

非企業擁有的資產和企業擁有的「影子IT」也應該盡可能地進行編目。這可能包括企業可見的任何內容（例如，MAC 位址、網路位置）並透過管理員資料輸入進行擴充。這些資訊不僅用於存取決策（因為協作者和 BYOD 資產可能需要聯繫 PEP），還用於企業的監控和取證日誌記錄。影子 IT 有一個特殊問題，就是這些資源屬於企業所有，但不像其他資源那樣管理。某些 ZTA 方法（主要基於網路）甚至可能導致影子 IT 元件變得不可用，因為它們可能不為人所知且不包含在網路存取策略中。

許多聯邦機構已經開始識別企業資產。已經建立 CDM 計劃能力的機構，例如 HWAM [HWAM] 和軟體資產管理 (SWAM) [SWAM]，在製定 ZTA 時擁有豐富的數據可供借鑒。機構還可能有一份涉及高價值資產 (HVA) [M-19–03] 的 ZTA 候選流程列表，這些流程已被確定為機構任務的關鍵。在使用 ZTA（重新）設計任何業務流程之前，這項工作需要在企業或機構範圍內進行。這些程式必須設計為可擴展並適應企業的變化，不僅在遷移到 ZTA 時，而且在考慮成為企業一部分的新資產、服務和業務流程時也是如此。

7.3.3 識別關鍵流程並評估與執行流程相關的風險#

機構應進行的第三個清單是對業務流程、資料流及其與機構任務之間的關係進行識別和排序。業務流程應告知資源存取請求被授予和拒絕的情況。企業可能希望在首次過渡到 ZTA 時從低風險業務流程開始，因為中斷可能不會對整個組織產生負面影響。一旦獲得足夠的經驗，更關鍵的業務流程就可以成為候選人。

利用基於雲端的資源或由遠端工作人員使用的業務流程通常是 ZTA 的良好候選者，並且可能會看到可用性和安全性的改善。企業客戶可以直接要求雲端服務，而不是將企業邊界投射到雲端或透過 VPN 將用戶端引入企業網路。企業的 PEP 確保在向客戶端授予資源存取權限之前遵循企業策略。規劃人員還應考慮效能、使用者體驗方面的潛在權衡，以及在為給定業務流程實施 ZTA 時可能出現的工作流程脆弱性增加的情況。

7.3.4 制定ZTA候選政策#

識別候選服務或業務工作流程的過程取決於幾個因素：該過程對組織的重要性、受影響的主題群組以及工作流程所用資源的當前狀態。可以使用 NIST 風險管理框架 [SP800–37] 評估基於資產或工作流程風險的資產或工作流程價值。

識別資產或工作流程後，識別所有使用的上游資源（例如 ID 管理系統、資料庫、微服務）、下游資源（例如日誌記錄、安全監控）和實體（例如主題、服務帳戶）或受工作流程影響。這可能會影響首次遷移到 ZTA 的候選者選擇。被識別的企業主題子集（例如，採購系統）使用的應用程式/服務可能優於對企業的整個主題庫（例如，電子郵件）至關重要的應用程式/服務。

然後，企業管理員需要為候選業務流程中使用的資源確定一組標準（如果使用基於標準的 TA）或置信度權重（如果使用基於分數的 TA）（請參閱第 3.3.1 節）。管理員可能需要在調整階段調整這些標準或值。這些調整對於確保政策有效但不阻礙資源的取得是必要的。

7.3.5 確定候選解決方案#

一旦開發了候選業務流程列表，企業架構師就可以編寫候選解決方案列表。一些部署模型（請參閱第 3.1 節）更適合特定的工作流程和目前的企業生態系統。同樣，某些供應商解決方案比其他解決方案更適合某些用例。以下是一些需要考慮的因素：

• 該解決方案是否要求在客戶端資產上安裝元件？這可能會限制使用或需要非企業擁有的資產的業務流程，例如 BYOD 或跨機構協作。
• 當業務流程資源完全位於企業內部時，該解決方案是否有效？一些解決方案假設請求的資源將駐留在雲端（所謂的南北流量），而不是在企業邊界內（東西流量）。候選業務流程資源的位置將影響候選解決方案以及流程的 ZTA。
• 此解決方案是否提供了記錄互動以進行分析的方法？ ZT 的關鍵組成部分是收集和使用與流程相關的數據，這些數據在做出存取決策時會回饋到 PE。
• 該解決方案是否為不同的應用程式、服務和協定提供廣泛的支援？一些解決方案可能支援廣泛的協定（Web、安全性外殼 [SSH] 等）和傳輸（IPv4 和 IPv6），而其他解決方案可能僅適用於狹窄的焦點，例如 Web 或電子郵件。
• 該解決方案是否需要改變受試者的行為？某些解決方案可能需要額外的步驟來執行給定的工作流程。這可能會改變企業主體執行工作流程的方式。

一種解決方案是將現有業務流程建模為試點計劃，而不僅僅是替代方案。此試點計畫可以普遍適用於多個業務流程，也可以針對一個用例。在將主題過渡到 ZTA 部署並遠離遺留流程基礎設施之前，該試點可以用作 ZTA 的「試驗場」。

7.3.6 初始部署和監控#

一旦選擇了候選工作流程和 ZTA 元件，就可以開始初始部署。企業管理員必須使用選定的元件來實施制定的策略，但可能希望先以觀察和監控模式進行操作。很少有企業策略集在第一次迭代中是完整的：重要的使用者帳戶（例如管理員帳戶）可能會被拒絕存取他們所需的資源，或者可能不需要他們分配的所有存取權限。

新的ZT業務工作流程可以在僅報告模式下運行一段時間，以確保政策有效且可行。這也允許企業了解基線資產和資源存取請求、行為和通訊模式。僅報告意味著應為大多數請求授予存取權限，並且應將連線日誌和追蹤與最初制定的策略進行比較。應強制執行並記錄拒絕MFA 失敗或來自已知、攻擊者控製或破壞的IP 位址的請求等基本策略，但在初始部署後，存取策略應更加寬鬆，以從ZT 工作流程的實際互動中收集數據。一旦建立了工作流程的基線活動模式，就可以更輕鬆地識別異常行為。如果無法採取更寬鬆的操作，企業網路業者應密切監控日誌，並準備根據操作經驗修改存取策略。

7.3.7 擴展ZTA#

當獲得了足夠的信心並細化了工作流程規則集後，企業就進入了穩定營運階段。網路和資產仍然受到監控，並且流量被記錄（參見第 2.1 節），但回應和策略修改以較低的速度完成，因為它們不應該很嚴重。所涉及資源和流程的主體和利害關係人也應提供回饋以改善營運。在此階段，企業管理員可以開始規劃下一階段的ZT部署。與先前的推出一樣，需要確定候選工作流程和解決方案集並制定初始策略。

然而，如果工作流程發生變化，則需要重新評估執行的 ZT 架構。系統的重大變更（例如新裝置、軟體重大更新（尤其是 ZT 邏輯元件）以及組織結構的變更）可能會導致工作流程或策略變更。實際上，應該在假設某些工作已經完成的情況下重新考慮整個過程。例如，購買了新設備，但尚未建立新的使用者帳戶，因此只需要更新設備庫存。

B.1 技術調查#

多家供應商受邀展示他們的產品和對零信任的看法。本次調查的目的是找出阻礙機構現在轉向基於零信任的企業基礎設施或維護現有 ZTA 實施的缺失部分。這些差距可以分為立即部署（立即或短期）、影響維護或操作的系統性差距（短期或中期）以及缺失的知識（未來研究的領域）。表 B-1 對它們進行了總結。

表 B-1：已確定的部署差距摘要

B.2 阻礙立即轉向 ZTA 的差距#

這些都是目前阻礙 ZTA 採用的問題。這些被歸類為迫在眉睫的問題，並且沒有考慮此類問題的未來維護或遷移。有遠見的企業也可能認為維護類別是阻止 ZTA 元件初始部署的直接關注點，但這些問題在本次分析中被視為一個單獨的類別。

B.2.1 ZTA 設計、規劃和採購缺乏通用術語#

零信任作為企業基礎設施設計和部署的策略仍然是一個正在形成的概念。業界尚未統一一套術語或概念來描述 ZTA 組件和操作。這使得組織（例如聯邦機構）很難制定一致的要求和政策來設計零信任企業基礎設施和採購組件。

第 2.1 節和第 3.1 節的驅動因素是形成描述 ZTA 的中立術語和概念基礎的初步嘗試。開發抽象 ZTA 組件和部署模型作為思考 ZTA 的基本術語和方法。目標是在開發企業需求和執行市場調查時提供一種查看、建模和討論 ZTA 解決方案的通用方法。隨著聯邦機構在 ZTA 方面獲得更多經驗，上述部分可能被證明是不完整的，但它們目前作為通用概念框架的基礎。

B.2.2 ZTA 與現有聯邦網路安全政策衝突的看法#

人們有一種誤解，認為 ZTA 是一個單一框架，包含一組與現有網路安全觀點不相容的解決方案。相反，零信任應該被視為當前網路安全策略的演變，因為許多概念和想法已經流傳了很長時間。鼓勵聯邦機構透過現有指南對網路安全採取更零信任的方法（請參閱第 6 節）。如果一個機構擁有成熟的 ID 管理系統和強大的 CDM 能力，那麼它就正在走向 ZTA（請參閱第 7.3 節）。這種差距是基於對 ZTA 以及它如何從先前的網路安全範式演變而來的誤解。

B.3 影響 ZTA 的系統性差距#

這些差距會影響 ZTA 的初始實施和部署以及持續營運/成熟度。這些差距可能會減緩 ZTA 在機構中的採用，或導致 ZTA 組件產業的分散。系統性差距是開放標準（由標準開發組織 [SDO] 或產業聯盟制定）可以提供幫助的領域。

B.3.3 組件之間介面的標準化#

在技​​術調查期間，很明顯沒有一家供應商提供能夠提供零信任的單一解決方案。此外，可能不希望使用單一供應商解決方案來實現零信任，從而帶來供應商鎖定的風險。這不僅在購買時而且隨著時間的推移也實現了組件內部的互通性。

更廣泛的企業內的組件範圍很廣，許多產品專注於零信任內的單一利基市場，並依賴其他產品向另一個組件提供資料或某些服務（例如，整合 MFA 以進行資源存取）。供應商常常依賴合作夥伴公司提供的專有 API，而不是標準化的、獨立於供應商的 API 來實現這種整合。這種方法的問題在於這些 API 是專有的且由單一供應商控制。控制供應商可以更改 API 行為，整合商需要更新其產品作為回應。這需要供應商社群之間的密切合作，以確保儘早通知 API 內的修改，這可能會影響產品之間的相容性。這給供應商和消費者增加了額外的負擔：供應商需要花費資源來改變他們的產品，而當供應商對其專有API進行更改時，消費者需要將更新應用到多個產品。此外，供應商還需要為每個合作夥伴組件實施和維護包裝器，以實現最大程度的相容性和互通性。例如，許多 MFA 產品供應商需要為每個雲端提供者或身分識別管理系統建立不同的包裝器，以便可在不同類型的用戶端組合中使用。

在客戶方面，這在開發產品採購需求時會產生額外的問題。購買者沒有可以依賴的標準來識別產品之間的兼容性。因此，建立轉向 ZTA 的多年路線圖非常困難，因為不可能確定組件的最低相容性要求集。

B.3.4 解決對專有 API 過度依賴問題的新興標準#

由於開發 ZTA 沒有單一的解決方案，因此零信任企業也沒有單一的工具或服務集。因此，不可能有單一協定或框架使企業能夠遷移到 ZTA。目前，有各種各樣的模型和解決方案試圖成為ZTA的領先權威。

這表明有機會開發一套開放的標準化協議或框架來幫助組織遷移到 ZTA。像互聯網工程任務組 (IETF) 這樣的 SDO 已經指定了可能有助於交換威脅資訊的協定（稱為 XMPP-Grid [1]）。雲端安全聯盟 (CSA) 制定了軟體定義邊界 (SDP) [2] 的框架，該框架在 ZTA 中也可能有用。應努力調查 ZTA 相關框架或有用的 ZTA 所需的協議的當前狀態，並確定需要工作的地方來製定或改進這些規範。

B.4 ZTA 的知識差距與未來的研究領域#

此處列出的差距並不妨礙組織為其企業採用 ZTA。這些是有關操作 ZTA 環境的知識中的灰色地帶，大多數是由於缺乏成熟的零信任部署的時間和經驗而產生的。這些是研究人員未來工作的領域。

B.4.5 攻擊者對 ZTA 的回應#

與傳統的基於網路邊界的安全相比，為企業正確實施 ZTA 將改善企業的網路安全狀況。 ZTA 的宗旨旨在減少資源對攻擊者的暴露，並在主機資產受到損害時最大限度地減少或防止企業內的橫向移動。

然而，堅定的攻擊者不會袖手旁觀，而是在 ZTA 面前改變行為。懸而未決的問題是攻擊將如何改變。一種可能性是，旨在竊取憑證的攻擊將擴大到針對 MFA（例如網路釣魚、社會工程）。另一種可能性是，在混合 ZTA/基於邊界的企業中，攻擊者將專注於尚未應用 ZTA 原則的業務流程（即遵循傳統的基於網路邊界的安全性），實際上，目標是輕鬆實現目標試圖在ZTA 業務流程中獲得一些立足點。

隨著ZTA的成熟、更多的部署、經驗的積累，ZTA在縮小資源攻擊面方面的有效性可能會變得明顯。還需要製定 ZTA 相對於舊網路安全策略的成功衡量標準。

B.4.6 ZTA 環境中的使用者體驗#

尚未對最終用戶在使用 ZTA 的企業中的行為進行嚴格的檢查。這主要是由於缺乏可供分析的大型 ZTA 用例。然而，已經有關於使用者如何對 ZTA 企業中的 MFA 和其他安全操作做出反應的研究，這項工作可以構成預測在企業中使用 ZTA 工作流程時最終使用者體驗和行為的基礎。

一組可以預測 ZTA 如何影響最終用戶體驗的研究是針對企業中 MFA 的使用和安全疲勞所做的工作。安全疲勞 [3] 是一種現象，最終用戶面臨如此多的安全策略和挑戰，以至於他們開始對他們的生產力產生負面影響。其他研究表明，MFA 可能會改變使用者行為，但整體變化是好壞參半的 [4] [5]。如果流程簡化並且涉及他們習慣使用或隨身攜帶的設備（例如智慧型手機上的應用程式），則一些用戶很容易接受 MFA。然而，一些用戶對必須使用個人擁有的設備進行業務流程感到不滿，或者感覺他們正在不斷受到監控，以防止可能違反 IT 策略的行為。

B.4.7 ZTA 對企業和網路中斷的復原能力#

對 ZTA 供應商生態系統的調查顯示了部署 ZTA 的企業需要考慮的廣泛基礎設施。如前所述，目前還沒有一家提供完整的零信任解決方案的提供者。因此，企業將購買多種不同的服務和產品，這可能會導致組件的依賴網路。如果一個重要元件中斷或無法訪問，可能會出現一系列故障，影響一個或多個業務流程。

受訪的大多數產品和服務都依賴雲端來提供穩健性，但即使是雲端服務也會因攻擊或簡單錯誤而變得無法存取。發生這種情況時，用於做出存取決策的關鍵元件可能無法存取或可能無法與其他元件通訊。例如，在分散式阻斷服務 (DDoS) 攻擊期間，可以存取位於雲端中的 PE 和 PA 元件，但可能無法存取擁有資源的所有 PEP。需要研究發現 ZTA 部署模型可能存在的瓶頸，以及當 ZTA 組件不可達或可及性有限時對網路運作的影響。

採用 ZTA 時，企業的營運連續性 (COOP) 計畫可能需要修訂。 ZTA 讓許多 COOP 因素變得更容易，因為遠端工作人員可以像在本地一樣存取資源。然而，如果使用者沒有經過適當的培訓或缺乏經驗，MFA 等政策也可能會產生負面影響。在緊急情況下，使用者可能會忘記或無法存取令牌和企業設備，這將影響企業業務流程的速度和有效性。

B.5 參考文獻#

[1] Cam-Winget N（編輯）、Appala S、Pope S、Saint-Andre P (2019) 使用可擴展訊息傳遞和狀態協定 (XMPP) 進行安全資訊交換。 （互聯網工程任務小組 (IETF)），IETF 徵求意見 (RFC) 8600。

[2] 軟體定義邊界工作小組「SDP 規格 1.0」雲端安全聯盟。 2014 年 4 月。

[3] Stanton B、Theofanos MF、Spickard Prettyman S、Furman S (2016) 安全疲勞。 IT 專業人員 18(5):26–32。 https://doi.org/10.1109/MITP.2016.84

[4] Strouble D、Shechtman GM、Alsop AS (2009) 使用雙重安全系統的生產力和可用性影響。 SAIS 2009 會議記錄（AIS，查爾斯頓，南卡羅來納州），第 37 頁。

[5] Weidman J、Grossklags J (2017) 我喜歡它，但我討厭它：員工對 BYOD 第二因素身份驗證的製度轉型的看法。第 33 屆電腦安全應用年度會議 (ACSAC 2017)（ACM，佛羅裡達州奧蘭多）論文集，第 212–224 頁。 https://doi.org/10.1145/3134600.3134629