零信任架構
譯自NIST Special Publication 800-207 Zero Trust Architecture
1 簡介
傳統的企業基礎設施正在變得越來越複雜。一個企業可能維護多個內部網路、遠端辦公室的本地基礎設施、遠端以及/或移動人員、雲服務等。這種複雜性已經超過了傳統的基於外圍的網路安全方式，因為這種情況下企業中已經不存在單一的、易於識別的外圍網路，因此基於外圍的網路安全已經無法滿足企業的需求，因為一旦攻擊者攻破外圍防護，就可以暢通無阻地進行內網漫遊。
上述複雜場景衍生除了新的安全模型，稱為"零信任"(ZT)。一個ZT方式主要關注資料和服務安全，但可以(應該)擴充套件到所有企業資產(裝置、基礎設施元件、應用、虛擬和雲元件等)和物件(終端使用者、應用和其他請求資源資訊的非人類實體)。在本文中，除非指定的是人類終端使用者(此時會使用"使用者"來代指)，否則一律使用"物件"。零信任安全模型假設環境中也可能會出現攻擊者，即企業所有的環境和非企業所有的環境一樣不可信任。在這種模型下，企業必須假設不存在隱式信任，並持續分析和評估資產和業務功能中存在的風險，並制定相應的方式措施來降低這些風險。在零信任中，這些防護通常涉及最小化資源(如資料和計算資源，以及應用/服務)訪問，僅將資源授予需要訪問的物件或資產，並持續對每個訪問請求的身份進行認證和授權。
一個零信任架構(ZTA)是一個基於零信任原則的企業網路安全架構，用於防止資料違規以及限制內網漫遊。本文討論了ZTA，以及其邏輯元件、可能的部署場景和威脅等，併為期望遷移到零信任的組織提供了通用的線路圖，以及討論了可能會影響零信任架構的相關聯邦政策。
ZT不是一個單一的架構，而是用於提升安全等級和敏感級別 [FIPS199]的一系列指導原則。向Z他的轉換涉及組織如何來評價其任務中存在的風險，且不能簡單地通過批量技術替換來實現。組織應該根據使用場景來逐步實現零信任原則、處理變更以及技術方案來保護其資料資產和業務功能。大多數企業技術設施執行在零信任/基於周邊的混合模型中。
為了高效地使用零信任，組織需要實現全面的資訊保安和恢復實踐(resiliency practices)。當與現有的網路安全策略和指導、身份和訪問管理、持續監測和最佳實踐相平衡時，ZTA可以防護常見的威脅並使用風險管理方式來改善組織的安全現狀。
1.1 與聯邦機構有關的零信任歷史
零信任的概念早在"零信任"這個名詞出現之前就出現在了網路安全中。 Defense Information Systems Agency(DISA) 和 Department of Defense 釋出了一個更加安全的企業戰略，稱為"black core"[BCORE]。black core涉及從基於周邊的安全模型轉移到注重單獨事務的安全模型。Jericho Forum在2004年傳達了這種去邊界的觀點--限制基於網路位置的隱式信任，以及限制在大型網段中依賴單一的、靜態防護。這種去邊界的觀點逐步演化為零信任(由Forrester的John Kindervag創造)，再後來，零信任成為一個用於描述各種網路安全方案的術語，移除基於網路位置的隱式信任，並在每個事務中評估信任等級。目前，私有企業和高等教育都在對從基於周邊的安全向基於零信任原則的安全策略的演化進行評估。
聯邦機構很早就期望遷移到基於零信任原則的安全，並以此構築相關的能力和策略，如Federal Information Security Modernization Act (FISMA)，隨後是 Risk Management Framework (RMF)；Federal Identity, Credential 和 Access Management (FICAM)；Trusted Internet Connections (TIC); 和 Continuous Diagnostics 和 Mitigation (CDM) 等程式，這些程式的目的都用於限制資料和資源訪問授權方。由資訊系統來管控這些程式。安全策略大部分是靜態的，且在"咽喉處"強制執行，企業通過這種方式進行安全管控。隨著技術的成熟，可以以動態和顆粒的方式來持續分析和評估"需要"訪問的請求，以減輕由於賬戶洩露造成的資料曝光、攻擊者對網路的監控以及其他威脅。
1.2 文件結構
後續文件的結構如下：
- 第二章：定義了ZT和ZTA，並列出了為一個企業設計ZTA時的設想。本節也包含一系列ZT設計的原則。
- 第三章：記錄了ZT的邏輯元件或構成要素。特定的實現可能包含不同的ZTA元件，卻可以提供相同的邏輯功能。
- 第四章：列出了Z他的使用場景，以及ZTA如何使企業環境變得更加安全，減少漏洞的危害，這些場景包括企業的遠端員工、雲服務和客戶網路。
- 第五章：討論了使用ZTA對企業的威脅。大部分威脅與其他型別的網路架構類似，但可能需要不同的緩解技術。
- 第六章：討論了ZTA原則如何適合並完善聯邦機構現有的指導規則。
- 第七章：介紹了企業(如聯邦機構)向ZTA轉型的起點，包括常見的計劃步驟、應用部署以及企業基礎設施
2 零信任基礎
零信任是一個網路安全模型，主要注重資源防護，並禁止隱式授權，且需要持續對許可權進行評估。零信任架構是一個端到端的方法，企業資源和資料安全包括身份(人和非人類實體)、憑證、訪問管理、維護、後端、託管環境和內部連線的基礎設施等。一開始主要關注限制需要訪問的資源並授予最小許可權(如讀、寫、刪除等)。傳統機構(和企業網路)通常關注外圍防護，在內部網路中通過認證的物件可能會被授予大量資源的訪問許可權。最終，環境中未授權的內網漫遊成了聯邦機構最大的挑戰。
Trusted Internet Connections (TIC)和機構外圍防火牆提供了強大的網際網路閘道器，可以幫助阻止來自網際網路的攻擊者，但TICs和外圍防火牆缺乏探測和阻止來自內網的攻擊，且無法防護企業外圍以外(如遠端工作者、基於雲的服務、邊緣裝置等)的物件。
一個對零信任和零信任架構的操作性的定義如下：
零信任提供了一系列概念和想法，旨在當網路出現漏洞時，降低資訊系統和服務執行的不確定性，以及最小化請求訪問特權。零信任架構是一種利用了零信任概念、包含的元件關係、工作流計劃以及訪問策略的企業網路安全規劃。因此，一個零信任企業可以看作是網路基礎設施(物理和虛擬)和運營策略的結合體，將企業當成一個零信任架構產品。
當一個企業決定採用零信任作為其核心戰略並做出零信任架構規劃後，就需要依據零信任原則(2.1章節)進行開發。該規劃最終會發布為一個零信任環境，以供企業使用。
上述定義關注的重點問題為：阻止對資料和服務的未授權訪問，以及儘可能以粒度的方式執行訪問控制。即，授權並允許物件(使用者、應用或服務、裝置等)訪問資料，並排除其他物件(即攻擊者)的訪問請求。更進一步，可以使用"資源"來替換"資料"，這樣ZT和ZTA就需要關注資源訪問(如印表機、計算資源、IOT等)，而不僅僅是資料上的訪問。
為了降低不確定性(不確定性是無法消除的)，需要關注認證、授權、在保持可用性的同時收縮隱形信任域、降低授權機制中的(時間)延遲。對於需要執行的請求動作，儘量以粒度的方式來執行訪問規則，以此最小化特權。
圖1展示了簡單的訪問模型，當一個物件需要訪問企業資源時，通過決策節點(PDP)以及策略實施點(PEP)進行授權。
系統必須保證物件是可信的，且請求是有效的。PDP/PEP 會通過適當的判斷來允許物件訪問資源。這意味著零信任適用於兩個基本的領域：認證和授權。對於一個特定的請求，對該物件的信任程度有多少？鑑於物件身份的可信程度，是否可以訪問該資源？用於該請求的裝置是否足夠安全？在變更可信等級時(如時間、物件的位置、物件的安全態勢等)是否需要考慮其他因素？總之，企業需要開發和維護基於風險的動態資源訪問策略，並配置一個系統來保證這些策略能夠正確且持續處理各個資源的訪問請求。這意味著企業不能依賴隱式信任(如果一個物件滿足基本的認證級別(如，登入到一個資產)，所有後續的資源請求都應該是同樣有效的。)
"隱式信任域"表示在該域中的所有實體至少在上一個 PDP/PEP 閘道器級別上是可信的。例如，機場的旅客篩選模型，所有旅客都會通過機場的安全檢查點(PDP/PEP)到達登機口。旅客、機場員工、機組人員等都處於機場區，所有的個體都被認為是可信的。在該模型中，隱式信任域就是登機區域。
PDP/PEP使用了一組訪問控制，因此PEP之外的所有流量都具有相同的信任級別。PDP/PEP無法在流量的位置之外新增額外的策略。為了儘可能使PDP/PEP具體 ，應該儘可能減小隱式信任域。
零信任提供了一組原則和概念來讓PDP/PEP更靠近資源。目的是為了明確地對構成企業的所有物件、資產和工作流進行認證和授權。
2.1 零信任原則
ZT的很多定義和討論都強調去除廣域外圍防護(如企業防火牆)。然而，大部分定義仍然以某種外圍方式(如微分段或微-外圍，見3.1章節)來定義Z他的部分功能。下面內容嘗試定義了ZT和Z他的基本原則(注重涉及到的內容，而非排除掉的內容)。這些原則是理想目標，但不得不承認，對於一個給定的戰略，可能並不需要實現所有的原則。
一個零信任架構的設計和部署需要遵循如下零信任基本原則：
- 所有的資料來源和計算服務都被認為是資源。一個網路可能包含多種型別的裝置。一個網路也可能包含可以傳送資料到聚合器/儲存的小型裝置、SaaS、可以向執行器傳送指令的系統以及其他功能。當然，一個企業也可能將個人擁有的裝置作為資源(如果這些裝置可以訪問企業的資源)
- 所有通訊都必須是安全的，不受網路位置的限制。單獨的網路位置並不意味著是可信的。同來其非企業網路的訪問請求和通訊一樣，來自企業的網路基礎設施(如外圍代理網路中)中的資產的請求同樣需要符合安全要求。換言之，不能根據企業網路基礎設施的裝置來動態授權。所有通訊應該採用最安全的方式進行，保證機密性和完整性，並提供安全認證。
- 根據每個會話來授權訪問單獨的企業資源。在訪問授權前需要對請求者進行評估。為了完成任務，也可使用所需的最低特權進行訪問授權，這種情況可能意味著"最近有時"發生了該事務，且在發起會話之前可能不會直接發生或使用資源執行該事務。然而對一個資源的認證和授權並不會自動授權其對其他資源的訪問。
- 使用動態策略(包含可觀測的客戶身份狀態、應用/服務和請求的資產，也可能包含其他行為和環境屬性)來決定對資源的訪問。組織通過定義資源包含哪些內容、資源的成員有哪些(或能夠從聯合社群驗證使用者)以及這些成員需要訪問資源的哪些內容來保護資源。對於零信任，客戶身份可能包括使用者賬戶(或服務身份)以及企業授予給該賬戶(用於認證自動任務)的相關屬性。請求資產狀態可以包含裝置特徵，如安裝的軟體版本、網路位置、請求的時間/日期、先前觀察到的行為以及安裝的憑證等。行為屬性包括但不限於，自動物件分析、裝置分析以及使用模式中的測量偏差。策略是基於屬性的一組訪問規則，組織將策略授予物件、資料資產或應用，環境資料可能包括請求者的網路位置、時間、報告的活動估計等因素。需要根據業務流程和可接受的風險級別來分配這些規則和屬性。可以根據資源/資料的敏感程度來變更資源訪問和動作策略。最小特權原則可以同時限制可見性和可訪問性。
- 企業監控並權衡所擁有的(和相關的)資產的完整性和安全態勢。資產不能繼承信任屬性。在評估一個資源請求時，企業需要對資產的安全態勢進行評估。實現了Z他的企業應該建立一套持續診斷和緩解(CDM)或類似的系統來監控裝置和應用的狀態，並在需要時打上補丁(或修復問題)。當發現資產遭到破壞(出現漏洞)，且資產不歸企業管理時，對威脅的處理可能與資產歸企業所屬(這種情況下的資產被認為是最安全的)的情況不同。上述場景也適用於允許某些裝置(如個人裝置)訪問某些資源，但拒絕其他裝置對這些資源的訪問的場景。即，需要一個健壯的監控和報告系統來提供關於企業資源當前狀態的可運算元據。
- 所有資源的認證和授權都是動態的，且必須在訪問前嚴格執行。這是一個恆定的迴圈，獲取訪問、掃描並評估威脅、適配並持續評估正在進行的通訊的可信度。一個實現了Z他的企業應該具有身份、憑證和訪問管理(ICAM)以及資產管理系統。包括使用多因子認證來訪問所有或一部分企業資源。根據策略(如基於時間的新的資源請求、資源修改、探測到異常物件活動等)的定義和實施，在整個使用者事務中持續監控可能發生的重認證和重授權，力求實現安全性、可用性、可用性和成本效率的平衡。
- 企業應該儘可能多地採集當前資產、網路基礎設施和通訊的狀態，並使用這些狀態提升其安全態勢。一個企業應該採集關於資產安全態勢、網路流量和訪問請求的資料，處理並使用這些資料來改善策略的建立和實施。這些資料也可以為物件的訪問請求提供上下文(見3.3.1章節)。
上述原則與技術無關。例如"使用者ID"可以包括如使用者/密碼、證書和一次性密碼等因素。這些原則可以用於一個組織或一個或多個合夥組織，且不能用於匿名公開或面向消費者的業務流程。一個組織不能向外部參與者(如消費者或一般的網際網路使用者)暴露內部策略，但可能會為非企業使用者實現一些基於ZT的策略，進而將其與企業進行關聯(如註冊的消費者、員工家屬等)。
2.2 網路的零信任視角
對於任何在網路規劃和部署中使用Z他的企業來說，它們對網路連線都有一些基本的設想。一些設想會用於企業所有的網路基礎設施，而其他則會用於在非企業所有的網路基礎設施(如公共Wi-Fi或公有云供應商)上運作的企業所有的資源。這些設想構成了一個ZTA。實現了Z他的企業應該使用上述ZTA原則和下面設想來開發網路：
- 整個企業私有網路都不應該認為是一個可信域。應該假設攻擊者隨時可能會出現在企業網路上，且應該採用最安全的方式進行通訊(見上述原則2)。這些限制動作包括對所有連線進行認證，對所有流量進行加密。
- 網路上的裝置不應該由企業所有或由企業進行配置。訪客或承包服務可能包含非企業所有的資產，這些資產也需要接入網路。包括使用自己的裝置(BYOD)策略來允許企業物件使用非企業所有的裝置來訪問企業資源。
- 資源不能繼承信任。在授予一個請求訪問企業所有的資源之前，必須通過PEP來評估每個資產的安全態勢(類似上述原則6，適用於資源和物件)。只要會話存在，就應該持續進行評估。企業所有的裝置可能具有支援認證的部件，由此可以提供比來自非企業所有的裝置的請求更高的可信級別。僅僅憑物件憑據無法滿足對裝置(到企業資源)的認證。
- 不是所有的企業資源都在企業所有的基礎設施中。資源包括遠端企業物件以及雲服務。企業所有或管理的資產可能需要使用本地(即非企業)網路進行基本的連線和網路服務(如DNS解析)。
- 遠端企業物件和資產可能不會完全信任其本地網路連線。遠端物件可能會假設本地(即非企業所有的)網路是不友善的。資產應該假設所有的流量都有可能被監控或修改。所有連線請求都應該通過認證和授權，且應該儘可能使用最安全的方式進行通訊(即提供保密性、完整性保護和資料來源驗證)。參見上述ZTA原則。
- 在企業和非企業基礎設施上轉移的資產和工作流應該保持一致的安全策略和態勢。在轉移到(或轉移自)企業所有的基礎設施上時，資產和工作流應該維持其安全態勢。這包括將裝置從企業網路轉移到非企業網路(即遠端使用者)。也包括將工作流從本地資料中心遷移到非企業的雲例項上。
3 零信任架構的邏輯元件
在企業中，可以使用大量邏輯元件來構造ZTA。這些元件可能以一個本地服務或雲服務的方式執行。圖2展示了元件和元件間互動的框架概念模型。注意這是一個理想的模型。從圖1的決策節點(PDP)可以拆分出兩個邏輯元件：策略引擎和策略管理器(見下)。ZTA邏輯元件使用控制面進行通訊，資料則使用資料面進行通訊(見3.4章節)。
元件描述：
- 策略引擎(PE)：該元件負責最終決定是否授予特定物件的資源訪問許可權。PE使用企業策略和外部資源輸入(如CDM系統、威脅情報服務)作為信任演算法的輸入(更多參見3.3章節)來授權、拒絕或取消到該資源的請求。PE需要與策略管理器元件配對。策略引擎負責執行和記錄決策(通過或拒絕)，策略管理器負責執行該決策。
- 策略管理器(PA)：該元件負責建立和/或管理一個物件到資源的通訊(通過命令相應的PEP)。它會生成特定會話的認證和授權令牌，或為客戶端生成可以訪問企業資源的憑據。如果授權了一個會話，且請求通過認證，則PA會配置PEP，允許啟動該會話。如果會話被拒絕(或前面的批准被撤回)，PA會通知PEP關閉連線。有些實現會將PE和PA作為同一個服務，上面則將其劃分為了兩個邏輯元件。當建立通訊路徑時，PA會與PEP通過控制面進行通訊。
- 策略執行點(PEP)：該系統負責啟用、監控以及最終關閉一個物件到企業資源之間的連線。PEP通過與PA通訊來轉發請求以及/或接收PA的策略更新。在ZTA中，這是一個單獨的邏輯元件，但可以劃分為兩個不同的元件：客戶端(如膝上型電腦上的代理)和資源側(如資源前面負責控制訪問的閘道器)或通訊路徑上充當"守門人"的單個門戶元件。PEP以外是託管企業資源的信任域。
除了實現Z他的核心元件，在作訪問決策時，策略引擎還使用一些資料來源來提供輸入和策略規則。這些資料來源包括本地資料來源以及外部資料來源(即非企業控制或建立的)。它們可以包括：
- 持續診斷和緩解(CDM) 系統：該系統會收集關於企業資產當前狀態的資訊，並將其更新到配置和軟體元件。一個企業CDM系統提供了帶資產訪問請求資訊(如是否執行在正確的打上補丁的作業系統上、企業批准的軟體元件的完整性或出現了未批准的元件，以及資產是否出現了已知漏洞等)的策略引擎。CDM系統也負責在企業基礎設施上活動的非企業裝置上識別並(潛在地)執行一部分策略。
- 行業合規系統：這確保了企業仍然符合其歸屬的監管制度(如FISMA、醫療或金融行業資訊保安要求)。它包括所有為保證合規而開發的所有策略。
- 威脅情報供給：它提供了內部或外部源的資訊，用於幫助策略引擎作出訪問決策。可能有多個服務同時從內部或外部源獲取資料，並提供新發現的攻擊或漏洞資訊，也可能包括軟體中新發現的缺陷、最新識別的惡意軟體等，然後向其他資產報告這類攻擊，並通知策略引擎將拒絕來自企業資產的訪問。
- 網路和系統活動日誌：該系統會對實時(或近實時)反饋企業資訊系統安全態勢的資產日誌、網路流量、資源訪問動作和其他事件進行聚合。
- 資料訪問策略：企業資源訪問的屬性包括規則和策略。應該由策略引擎(通過管理介面)編碼或自動生成這些規則集。由於這些規則為企業的賬戶和應用/服務提供了最基本的訪問特權，因此它們是資源訪問授權的起點。這些策略應該基於組織定義的任務角色和需求。
- 企業公鑰基礎設施(PKI)：該系統負責生成並記錄企業為資源、物件、服務和應用釋出的證書。也包括全域性證書頒發機構生態系統以及Federal PKI(可能會，也可能不會整合到企業PKI中)。PKI有可能並不建立在X.509 證書之上。
- ID管理系統：負責建立、儲存和管理企業使用者賬戶和身份記錄(如LDAP服務)。該系統包含必要的物件資訊(如名稱、電子郵件地址、證書等)和其他企業特徵(如角色、服務屬性以及分配的資產)。該系統通常會使用其他系統(如PKI)作為部件來與使用者賬戶進行關聯。該系統可能是大型聯合社群的一部分，可能包含非企業員工或到非企業資產的連結(為了協同工作)。
- 安全資訊和事件管理(SIEM)系統：該系統會採集安全中心的資訊，用於後續分析。這些資料可以用於改善策略並在出現針對企業資產的攻擊時發出告警。
3.1 零信任架構方式的變種
企業有幾種方式來制定ZTA工作流。不同的方法在使用的元件和主要的策略規則來源上有所不同。每種方式都實現了所有的ZT原則(見2.1章節)，但可能使用其中一種或兩種(或一個元件)作為主要的策略驅動因素。一個完整的ZT會包含三種方式中的所有元素。這三種方式為：增強身份治理，邏輯微分段和基於網路的分段。
不同的方式有其特定的適用場景。一個企業在開發ZTA時，可能會發現某種方式更適用於其使用場景和現有的策略點。這並不意味著其他方式無法工作，僅意味著其他方式比較難以實現，且需要對企業現有的業務流程進行更多根本性的變更。
3.1.1 使用增強身份治理的ZTA
增強身份治理方式使用參與者的身份作為策略建立的主要元件來開發ZTA。如果物件的請求無法訪問企業資源，則無需建立訪問策略。使用這種方式時，企業資源訪問策略會基於身份來分配屬性。資源訪問的主要需求基於授予物件的訪問特權。其他因素，如使用的裝置，資產狀態和環境等可能會影響對最終的可信等級(以及最終訪問授權)的計算或以某種方式來定製結果，如基於網路位置來授權一部分到特定資料來源的訪問。單獨資源或保護資源的PEP元件必須能夠使用某種方式來將請求轉發到一個策略引擎服務，或在訪問授予前對物件進行認證，並批准該請求。
使用增強身份治理方式的企業會使用一個開放網路模型或使用支援外部訪問的企業網路或頻繁在網路上使用非企業裝置(見4.3章節)。一開始會授予所有資產網路訪問的許可權，但僅允許擁有訪問特權身份的資產訪問企業資源。這種方式有一個缺點，即對惡意參與者授予基礎網路連線的許可權，可能會導致攻擊者通過內部網路或第三方發起網路探查，以及/或服務拒絕攻擊(DOS)。在請求影響到工作流前，企業仍然需要監控並對這些行為作出響應。
由於裝置身份和狀態為訪問決策提供了輔助支援資料，因此身份驅動方式非常適用於資源門戶模型(見3.2.3章節)。身份驅動方式也適用於使用基於雲應用/服務的企業，這種場景下無法使用企業所有或維護的ZT安全元件(如很多SaaS)。企業可以使用請求者的身份在這些平臺上構造或執行策略。
3.1.2 使用微分段的ZTA
企業可能會基於受閘道器安全元件保護的特定網段上的資源或資源組來實現ZTA。這種方式下，企業可能會採用如智慧交換機(或路由器)或下一代防火牆(NGFWs)或專用閘道器裝置等基礎設施作為PEP來保護每個資源或相關資源組。此外，企業可能會選擇使用軟體代理(見3.2.1章節)或終端資產上的防火牆來實現基於主機的微分段。這些閘道器裝置會自動對來自客戶端、資產或服務的請求授予訪問許可權。取決於具體的模型，閘道器可能是單獨的PEP元件或包含閘道器和客戶端代理(見3.2.1)的多PEP元件。
該方法適用於多種場景和部署模型，因為保護裝置充當PEP，管理管理裝置的元件充當PE/PA。這種方式需要一個身份治理程式(IGP)來發揮完整功能，同時需要依賴一個閘道器元件作為PEP來阻止未授權的資源訪問。
這種方式關鍵是需要一個PEP元件，並且可以根據需要作出反應和重新配置來響應工作流中的威脅或更改。可以通過(不那麼高階的)閘道器裝置甚至無狀態網路來實現微分段的部分特性，但管理成本和難以快速適應變化使之成為一個非常糟糕的選擇。
3.1.3 使用網路基礎設施和網路定義周邊(SDP)的ZTA
最後一種方式是使用網路基礎設施來實現ZTA。可以使用一個overlay網路(7層，但也可以低於OSI網路棧)來實現ZTA。這些方式有時候稱為軟體定義周邊(SDP)，且經常會涉及軟體定義網路(SDN)[SDNBOOK]和基於意圖的網路(IBN) [IBNVN]的概念。在這種方式中，PA作為網路控制器，負責根據PE的決策來配置和重配置網路。客戶端通過受PA元件管理的PEP(繼續)進行請求訪問。
當在應用網路層(即7層)實現這種方式時，最常見的部署模型是代理/閘道器(見3.2.1章節)。在這種實現中，代理和資源網路(作為由PA配置的單個PEP)之間會建立一條安全通道，用於客戶端和資源的通訊。此外還有其他變種模型，如雲虛擬網路，基於非IP的網路等等。
3.2 部署變種的抽象架構
上述所有元件都是邏輯元件，它們不需要部署到獨立的系統上。單個資產可以擔任多個邏輯元件的職責，類似地，一個邏輯元件也由多個硬體或軟體元素來執行此類任務。例如，一個企業管理的PKI可能由一個負責簽發裝置證書的元件和一個用於簽發終端使用者證書的元件構成，但這兩個元件都使用了相同的企業根證書機頒發的中間證書。目前市場上可用的ZT產品中的PE和PA元件被包裝在一個單獨的服務中。
後續章節給出了選中的架構元件的一些部署方式。取決於企業網路的配置方式，在一個企業中，可能在不同的業務流程中使用不同的ZTA部署模型。
3.2.1 裝置代理/基於閘道器的部署
在這種部署模型中，PEP被劃分為兩個元件，位於資源上或作為一個資源前面的元件。例如，每個企業頒發的資產都有一個用於協調連線的裝置代理，且每個資源前面都有一個元件(即閘道器)，這樣資源僅需要與閘道器進行互動即可，本質上它是資源的代理。代理是一個軟體元件，為了對請求進行評估，需要將一些(或全部)流量定向到合適的PEP。閘道器負責與策略管理器進行通訊，確保僅批准由策略管理者配置的通訊路徑(見圖3)。
典型場景中，當一個使用企業頒發的行動式電腦的物件需要連線到企業資源(如人力資源應用/資料庫)時，首先由本地代理處理請求，並將其轉發給策略管理器。策略管理器和策略引擎可能是一個本地資產或雲服務。策略管理器將請求轉發給策略引擎進行評估。如果該請求被授權，則策略管理器會通過控制面，在裝置代理和相關的資源閘道器之間建立一條通道。整個過程可能需要一些資訊，如IP地址、埠資訊、會話金鑰或類似的安全部件等。然後，裝置代理和閘道器會對應用/服務的資料進行加密。當流程結束或策略管理器觸發了安全事件(如會話超時、重認證失敗等)時，會斷開裝置代理和資源閘道器之間的連線。
該模型適用於具有健壯的裝置管理程式以及可以通過閘道器來連線離散資源的企業。對於大量使用雲服務的企業，它是Cloud Security Alliance (CSA) Software Defined Perimeter (SDP) [CSA-SDP]的客戶端實現。這種模型也同樣適用於哪些不想使用BYOD策略的企業。只能通過裝置代理進行訪問，裝置代理可以置於企業所有的資產中。
3.2.2 基於飛地的部署(Enclave-Based Deployment)
該部署模型是上述代理/閘道器模型的變種。在這種模型中，閘道器元件可能不位於資產之上或單獨的資源前面，而位於資源飛地(資料中心所屬範圍)的邊緣(見圖4)。通常這些資源會服務單個業務功能，有可能不會直接與閘道器進行通訊(如，歷史遺留的資料系統可能不存在與閘道器通訊的介面)。這種部署模型比較適合在單個業務流程(如使用者通知、資料庫查詢、薪資支付等)中使用雲服務的企業。在這種模型中，整個私有云都放到了閘道器之後。
這種模型也可以與代理/閘道器模型混用，此時，企業資產中包含用於連線飛地閘道器的裝置代理，但使用了相同的基本代理/閘道器模型來建立連線、
該模型適用於具有歷史遺留應用或無法在本地資料中心中使用獨立的閘道器的企業。這些企業需要健壯的資產和配置管理程式來安裝/配置裝置代理。缺點是閘道器可以防護一組資源，但無法防護每個資源，這可能會讓物件看到他們無許可權訪問的資源。
3.2.3 基於門戶的資源部署
在這種部署模型中，PEP是一個獨立的元件，作為閘道器處理物件請求。閘道器門戶可以用於一個單獨的資源，也可以作為(用於一個業務功能的)資源集的安全飛地。例如，可以在私有云或包含歷史遺留應用的資料中心中使用閘道器門戶，見圖5。
相比其他模型，這種模型的好處是，不需要在所有客戶端裝置上安裝軟體元件。同時在BYOD策略和內部組織協作專案中採用這種模型也更加靈活。企業管理員不需要事先保證每個裝置都安裝了合適的裝置代理，但可以通過裝置請求訪問推斷出有限的資訊。這種模型僅可以在連線到PEP門戶時對資產和裝置進行掃描和分析，但無法對惡意軟體、未打補丁的漏洞以及配置持續進行監控。
這種模型的最大不同點在於它沒有本地代理來處理請求，因此企業可能無法具有全面的可見性以及對資產的整體把控(因為其只能在連線到門戶時才能看到並對資產進行掃描)。由此，企業可能會採取一些措施來緩解或補償該問題，如隔離瀏覽者。企業可能無法觀察到會話涉及到的資產。該模型也允許攻擊者發現並嘗試訪問門戶，或對門戶發起DoS攻擊，因此門戶系統應該具備一定的防DoS攻擊或網路中斷的功能。
3.2.4 裝置應用沙盒
代理/閘道器部署模型的另一種變體是在資產之上分塊執行經過稽核的應用或流程。這些元件可能是虛擬機器、容器或其他實現，但目的是相同的：防止應用或應用例項受到資產上易感染的主機或其他應用的威脅。
在圖6中，物件裝置在沙盒中執行著經過審批和稽核的應用。應用可以通過PEP來請求訪問資源，但PEP可能會拒絕來自該資產之上的其他應用的請求。在該模型中，PEP可能是一個企業本地服務或雲服務。
該變種模型的主要好處是，其將單獨應用與資產上的其他應用進行了分割。如果無法對資產漏洞進行掃描，那麼沙盒應用也可能會抵禦主機資產上潛在的惡意軟體的影響。該模型的一個缺點是，企業必須維護所有資產上的沙盒應用，且可能無法對客戶資產完全可見。此外，企業還需要保證每個沙盒應用是安全的，這可能要付出比簡單監控裝置更多的努力。
3.3 信任演算法
對於一個部署了Z他的企業，認為將策略引擎認為是其大腦，PE的信任演算法是其主要的思維過程。策略引擎會使用信任演算法(TA)來最終授予或拒絕對資源的訪問。策略引擎會從多個源獲取輸入(見第3章節)：包含物件資訊、物件屬性和角色、歷史物件行為模型、威脅情報來源以及其他後設資料源的策略資料庫。該過程可以分為圖7展示的幾類。
在上圖中，可以根據提供給信任演算法的內容，將輸入分為如下幾類：
- 訪問請求：物件的實際請求。請求的資源是所使用的主要資訊，但同時也使用了請求者的資訊。包括OS版本、使用的軟體(如發出請求的應用是否在批准的應用列表中?)以及補丁級別。通過這些因素以及資產的安全態勢來允許或拒絕到對資產的請求。
- 物件資料庫：請求訪問資源的"誰"。它是企業或協作者的一組物件(人或流程)，以及分配的物件屬性/特權集合。這些物件和屬性構成了資源訪問的策略的基礎[SP800-162] [NISTIR 7987]。使用者身份可以包括邏輯身份(如賬戶ID)和PEPs認證檢查的結果。可以考慮衍生為置信級別的身份屬性，包括時間和地理位置。可以將分配給多個物件的特權集看作角色，但給物件分配的特權應該基於特定的因素，不能僅僅因為它符合組織中特定的角色就授予該角色對應的特權。(物件屬性/特權)集合應該編碼並儲存在一個ID管理系統和策略資料庫中。在一些(TA)變體中(見3.3.1章節)也可能包括觀察到的物件行為資訊。
- 資產資料庫(和可觀察的狀態)：該資料庫包含每個企業所有(以及已知的非企業/BYOD)的資產(物理和虛擬)。資料庫會與資產的可觀察狀態進行比較，包括OS版本、存在的軟體以及完整性、位置(網路位置和物理位置)和補丁級別等。根據資產狀態和資料庫的比較結果，可能會限制或拒絕對資產的訪問。
- 資源要求：該策略補充了使用者ID和屬性資料庫，並定義了資源訪問的最小要求。這些要求可能包括身份識別器的擔保級別，如MFA網路位置(如拒絕來自海外IP地址的訪問)，資料敏感性和請求的資產配置等。可以由資料託管人(即負責資料的人)和負責在業務流程使用這些資料(即負責任務執行)的人來對這些需求進行開發。
- 威脅情報：這是一個或多個有關網際網路上的一般威脅和活動惡意軟體的資訊源。也可能包括裝置觀察到的可疑的通訊資訊(如查詢可能的惡意軟體命令和控制節點)。這些資訊可以是外部服務的，也可以是內部掃描和發現的(可以包括攻擊特徵和緩解措施)。這是唯一最有可能由服務而不是企業控制的元件。
每個資料來源的重要性可能通過專有演算法或企業進行配置。這些加權值可以用來反應資料來源的對企業的重要性。
然後將最終決定提交給PA執行。PA的任務是配置必要的PEPs來保證授權通訊。取決於Z他的部署方式，該過程可能會涉及將認證結果和連線配置資訊傳送給閘道器和代理或資源門戶。根據策略要求，PAs可能會通過保持或暫停一個連線會話來對連線進行重認證或重授權。PA也會根據策略(如超時、工作流結束以及安全告警等)來(發出命令)終止連線。
3.3.1 信任演算法變種
有多種方式來實現一個TA。不同的實現可能根據因素的重要性進行權衡。有兩種主要的特性來區分TA。第一種是如何對因素進行評估，是作為二元決策還是作為整體"得分"或置信級別的加權部分。第二種是如何根據同一物件、應用/服務或裝置的其他請求來評估請求。
- 標準 Vs 基於得分：標準的TA在授權到資源的請求或允許某個動作(如讀/寫)前必須滿足一系列屬性。由企業來配置這些標準，且應該針對每個資源進行單獨配置。只有在滿足標準時才能授權訪問或動作。基於分數的TA會基於每個資料來源和企業配置的比重來計算置信級別。如果得分大於配置資源的閾值，則可以授權訪問或允許執行某個動作。反之，則會拒絕請求或降低訪問特權(如只允許讀檔案，不允許寫檔案)。
- 單一 Vs 上下文：單一的TA會單獨看待每個請求，在做決策時不會考慮物件的歷史行為。這種方式可以快速做出決策，但如果攻擊停留在物件允許的角色範圍內，則存在未被發現的風險。上下文TA在評估訪問請求時會考量物件或網路的最近歷史。這意味著PE必須維護所有物件和應用的狀態資訊，但可能更容易檢測到攻擊者使用被破壞的憑據進行訪問的資訊，其訪問模式與PE在給定物件中看到的模式不同。這也意味著，在與物件互動時，PA（和PEP）必須將使用者行為告知PE。分析物件行為可以通過一個可接受的使用模型，行為的偏差可能會觸發額外的認證檢查或拒絕對資源的請求。
上述兩種因素並不總是相互依賴的。有可能一個TA給每個物件和/或裝置分配一個置信等級，但仍然會獨立評估每個訪問請求(即 單一的)。但上下文和基於得分的TA會提供更動態和顆粒度的訪問控制(由於基於得分的TA為請求賬戶提供了當前的置信級別，相比人工配置的靜態策略，可以會更快地適應不斷變化的因素)。
理想情況下，一個ZTA信任演算法應該是上下文的，但基礎設施元件總是對企業可見。一個上下文TA可以緩解在攻擊者對受損物件帳戶或內部攻擊保持接近“正常”訪問請求集的狀態下造成的威脅。在定義和實現一個信任演算法時，需要在安全、可用性和成本效益之間作權衡。當物件的行為與歷史趨勢不一致時，持續提示物件進行重認證，並在組織中規範其任務功能和角色，但同時也可能會導致可用性問題。例如，如果一個HR部門的員工通常一天會訪問20到30個員工的記錄，但如果一天內的訪問超過100條記錄，一個上下文TA可能會傳送告警。如果某個人在工作時間之外執行了訪問請求，則上下文TA可能會認為攻擊者在使用一個受損的HR賬戶偵察記錄，併發出告警。這是上下文TA可以探測出攻擊，但單一TA無法探測的例子。在其他例子中，一個會計師通常會在正常上班時間內訪問金融系統，但現在半夜且在一個未知的位置嘗試訪問系統，上下文TA可能會觸發告警並要求物件滿足更嚴格的置信級別或其他NIST Special Publication 800-63A [SP800-63A]描述的準則。
需要對給每個資源設定的準則或權重/閾值進行規劃和測試。企業管理員可能在一開始實現ZTA時遇到問題，如可能會因為錯誤配置導致拒絕本該被批准的訪問請求。因此需要在部署時加入"優化"階段，對準則或得分權重進行調整，來保證策略的執行不會影響企業的業務流程正常運作。此優化階段的持續時長取決於企業定義的進度指標和對工作流中使用的資源的不正確訪問的拒絕/批准的容忍度。
3.4 網路/環境元件
在一個ZT環境中，應該區分用來控制和配置網路和應用/訪問的通訊流和用來執行組織實際工作的通訊流。通常會將其分為用於控制通訊的控制面和用於應用/服務通訊流的資料面。
各種基礎設施元件(包括企業所有的和服務商提供的)會使用控制面來對資產進行維護和配置。通過判定、授權或拒絕資源訪問，以及執行必要的操作來設定資源之間的通訊路徑。而資料面則用於實際軟體的通訊。在控制面建立通訊路徑之前，有可能無法使用資料面通訊通道。例如，PA和PEP有可能使用控制面來配置物件和企業資源的通訊路徑，然後應用/訪問負載就可以使用建立好的資料面路徑。
3.4.1 Z他的網路要求
- 企業資產使用基本的網路互聯：區域網(LAN)提供了基本的路由和基礎設施功能(如DNS)。遠端企業資產可能不會使用所有的基礎設施服務。
- 企業必須能夠識別企業所有或由企業管理的資產，以及裝置的當前安全態勢：使用企業簽發的憑據來識別資產，且不能使用無法認證的資訊(如網路MAC地址)。
- 企業能夠觀察到所有的網路流量：企業應該記錄看到的資料面的報文(即時無法在應用層上對所有資料包執行檢查)。企業需要過濾關於連線(即目的、時間、裝置身份等)的資訊來動態更新策略並在PE評估訪問請求時通知PE。
- 不能在未訪問PEP的前提下允許訪問企業資源：企業資源不能接收來自網際網路的任意入站連線。只有在客戶端經過認證和授權之後才能接收自定義配置的連線。由PEP來設定這些連線路徑。如果沒有訪問PEP，則有可能無法發現資源。這樣做可以防止攻擊者通過掃描和/或對位於PEPs後面的資源發起DoS攻擊。注意，並不是所有的資源都需要使用這種方式進行隱藏，有些網路基礎設施元件(如DNS服務)必須是可訪問的。
- 資料面和控制面是邏輯隔離：一個網路上的策略引擎、策略管理器和PEPs元件之間是邏輯隔離的，且不能被企業資產和資源直接訪問。資料面用於應用/服務的資料流量。策略引擎、策略管理器和PEPs使用控制面來進行通訊並管理資產之間的通訊路徑。PEPs必須能夠同時傳送到和接收來自資料面和控制面的訊息。
- 企業資產需要能夠訪問PEP元件：企業物件必須要能夠訪問PEP元件來獲取到資源的訪問許可權。可以通過企業資產上的前端門戶、網路裝置或軟體代理來啟用連線。
- PEP是作為業務流的一部分，可以訪問策略管理器的唯一元件：企業網路上運作的每個PEP都有一條到策略管理器的連線，用於給客戶端和資源建立連線。所有的企業業務流程必須通過一個或多個PEP來處理流量。
- 遠端企業資產應該可以在不通過企業網路基礎設施的前提下訪問企業資源：例如，一個遠端物件不應該使用一條到企業網路的連線來訪問被企業使用、但由公有云供應商託管的服務(如email)。
- 用於支援ZTA訪問決策流程的基礎設施應具有可擴充套件性，並考慮到流程負載的變化：ZTA中使用的PE(s)、PA(s)和PEPs是所有業務流程的核心元件。無法連線到PEP(或PEP無法連線PA/PE)或到PEP的連線出現了延遲都會對業務流程的執行造成負面影響。實現Z他的企業需要考慮到元件的過載以及在需要時對基礎設定進行擴容來滿足不斷增長的使用場景。
- 由於策略或觀察到的因素，企業資產可能無法連線到特定的PEPs：例如，可能有一條策略，其表明，如果當請求的裝置來自非企業所在的國家時，拒絕來自移動裝置的資源訪問。這些因素可能基於位置(物理或網路位置)、裝置型別或其他準則。
4 部署場景/使用場景
記住，在任何企業環境下都可以設計零信任準則。大多陣列織已經在其企業基礎設施或在實現資訊保安和恢復策略以及最佳實踐的過程中實現了零信任的一部分元素。一些部署場景和使用場景下更傾向於使用零信任架構。例如，ZTA源於地理上分佈和/或勞動力流動性高的組織中。也就是說，任何組織都可以從零信任架構中獲得好處。
在下面使用場景中，並沒有明確指明ZTA，這是因為企業傾向於同時使用基於周邊和Z他的基礎設施。正如在7.2章節中討論的，企業很可能會在一段時間內同時存在ZTA元件和基於周邊的網路基礎設施。
4.1 使用"衛星設施"的企業
企業最常見的場景是其有一個總部，以及一個或多個地理上分散的分部，且無法通過企業所有的物理網路進行連線(見圖8)。遠端位置的員工可能無法使用完全由企業所有的本地網路，但仍然需要訪問企業資源來完成任務。企業可能會使用到企業總部網路的多協議標籤交換(MPLS)連線，但不保證為所有的流量分配足夠的頻寬，或可能不希望將傳送給基於雲的應用/服務的流量經過企業總部網路。
類似地，員工可能使用企業所有的或個人所有的裝置在進行遠端辦公。這種場景下，企業可能會授予部分資源(如員工日程、email等)，並拒絕到或限制到更多敏感資源(如HR資料庫)的訪問。
在這種使用場景下，PE/PA(s)通常會作為雲服務(通常會提供更高的可用性，且不會要求遠端員工依賴企業基礎設施來訪問雲資源)託管，終端資產具有已安裝的代理(見3.2.1章節)或訪問資源門戶(見3.2.3章節)。將用於遠端辦公的PE/PA(s)部署在企業本地網路可能並不是響應最迅速的，且員工必須將流量傳送回企業網路才能訪問雲服務託管的應用/服務。
4.2 多雲和雲到雲的企業
越來越常見的場景是，企業使用多雲供應商來部署ZTA。這種使用場景中，企業會使用一個本地網路，並使用一個或多個雲服務供應商來託管應用/服務和資料。有時候，應用/服務被託管在域資料來源分開的雲服務上。為了效能和方便管理，在雲供應商A上託管的應用應該能夠直接連線到雲供應商B上託管的資料來源，而無需強制應用通過隧道進入企業網路。
這種使用場景是CSA的軟體定義周邊(SDP)規範[CSA-SDP]的服務到服務的實現。當企業轉而使用更多的雲託管應用和服務時，依賴企業周邊來實現安全的方式將變成一種負擔。正如在2.2章節中討論的，ZT原則採用的觀點是，企業所有或維護的網路基礎設施和由其他服務供應商所有和維護的基礎設施並沒有什麼不同。多雲的零信任方法會將PEP放到每個應用/服務和資料來源的入口位置。PE和PA可能位於雲內或第三方雲供應商之上。客戶通過門戶或本地安裝的代理就可以直接訪問PEPs。使用這種方式，在使用企業外部託管的情況下，企業仍然可以管理到資源的訪問。同時存在的挑戰是，不同的雲供應商有其特定的方式來實現類似的功能，企業架構師需要了解如何在使用的雲供應商之上來實現企業ZTA。
4.3 具有合同服務和/或非員工訪問許可權的企業
另一種常見的場景是，現場來訪者和/或合同服務供應商需要有限地訪問企業資源來完成其工作(見圖10)。例如，企業有其內部的應用/服務、資料庫和資產，它們與供應商之間有服務合同，供應商偶爾會在現場提供維護支援(如，由外部供應商所有和管理的智慧加熱和照明系統)。這些來訪者和服務供應商需要連通網路來執行其任務。一個零信任企業可能會在因此企業資源的前提下，允許這些裝置和上門服務技術人員訪問網際網路。
在上例中，企業有一個支援來訪者與員工互動的會議中心，同樣，使用SDP的ZTA方法，員工裝置和物件是不同的，可以適當訪問企業資源。來訪者可以訪問企業園區網路，但不能訪問企業資源，甚至無法通過網路掃描發現企業服務(即防止網路探測/網路漫遊)。
在這種使用場景中，可能將PE(s) 和PA(s) 託管到雲服務或放到LAN上(假設很少或基本不會用到雲託管服務)。企業資產可能安裝代理(見3.2.1章節)或通過門戶來訪問資源(見3.2.3章節)。PA(s)保證所有的非企業資產(沒有安裝代理或沒有連線到門戶的資產)無法訪問本地資源，但可能可以訪問網際網路。
4.4 跨企業邊界的協作
第四種使用場景是跨企業進行協作。例如，有一個涉及企業A員工和企業B員工的專案(見圖11)。這兩個企業可能是不同的聯邦機構(G2G)，甚至一個是聯邦機構，另一個是私企(G2B)。企業A會操作專案的資料庫，但必須允許其訪問企業B的特定資料。企業A可能會設定特定的賬戶來讓企業B的員工訪問所需要的資料，並拒絕對其他資源的訪問，但這種方式很快就會變得難以管理。將兩個組織都註冊到聯邦ID管理系統可以更快地建立這些關係，前提是兩個組織的PEP都可以在聯合ID社群中對主題進行身份驗證。
這種場景類似場景1(4.1章節)，兩個企業的員工可能不位於其組織的網路基礎設施之上，且他們需要訪問的資源可能位於其中一個企業環境或託管的雲上。這意味著，基於企業A 的訪問策略，就不需要配置複雜的防火牆或企業範圍內的訪問控制列表(ACL)來允許企業B的特定IP地址訪問企業A的資源。如何實現這種訪問取決於使用的技術。類似場景1，作為雲服務託管的PE和PA可能在不建立VPN或類似通道的前提下向各方提供可用性。企業B的員工可能被要求在其資產上安裝軟體代理，或通過網路閘道器(3.2.3章節)來訪問需要的資料資源。
4.5 使用公共或面向客戶服務的企業
很多企業的一個常用特性是具有面向公共的服務，這種服務可能會也可能不會要求使用者進行註冊(即，使用者必須建立或獲得一組登入憑據)。這類服務面向一般的公眾、與現有業務關係有關的一組客戶或特定的非企業使用者組，如員工家屬。在所有場景中，請求的資產可能不是企業所有的，且企業在內部網路安全政策的實施方面也會受到限制。
對於一個不需要憑據訪問的面向公共的資源來說，不需要直接使用ZTA原則。企業不能嚴格控制請求資產的狀態，且不需要憑據來訪問匿名的公共資源(如公共網頁)。
企業可能會為註冊的公共使用者(如具有業務關係的客戶)和特定的使用者(如員工家屬)建立策略。如果使用者需要生成或頒發憑據，企業可能會制定有關密碼長度、生命週期和其他細節的策略，並提供可選或必要的MFA。但也限制了企業可以為這類使用者實現的策略。入站請求的資訊可能被用來確定公共服務的狀態以及探測可能的來自偽裝成合法使用者的攻擊。例如，當一個使用者註冊到一個使用者門戶後，就可以使用某個通用網路瀏覽器進行訪問。當來自未知的瀏覽器型別或已知過時版本的訪問請求突然增加時，就表示有可能出現了某種自動攻擊，企業可以採取相應的動作來限制這些來自特定使用者的請求。企業還應該瞭解關於可以收集和記錄哪些請求使用者和資產的資訊的法規或條例。
5 與零信任有關的威脅
沒有企業可以消除安全風險。在現有網路安全策略和指導、身份和訪問管理、持續監控以及一般網路清潔（指通過使用特殊軟體、選擇難以破譯的密碼等保護網上電腦資訊的做法）的補充下，合理實現和維護ZTA可以降低整體風險並抵禦常見的攻擊。然而，在實現ZTA時，一些威脅具有獨特的能力。
5.1 對ZTA決策流程的破壞
在ZTA中，策略引擎和策略管理器是整個企業的核心元件。除非經過PE和PA的批准和配置，否則企業資源之間不應該建立通訊。這意味著，這些元件必須進行合理的配置和維護。配置了可以訪問PE規則的企業管理員有可能會執行不批准變更，或有可能因為失誤而破壞企業的運營。同樣，一個洩露的PA可能會允許訪問某些未經批准的資源(如遭到破壞的個人所有裝置)。對這類威脅的緩解意味著必須要合理配置和監控PE和PA元件，且所有配置變更都必須記錄日誌和接受審計。
5.2 DoS或閘道器中斷
在ZTA中，PA是資源訪問的核心元件。企業資源不能在沒有PA允許和(可能的)配置的前提下進行互聯。如果一個攻擊者對PEP(s)或PE/PA進行了中斷或拒絕訪問(如DoS攻擊或路由劫持)攻擊，則有可能對企業的運營產生負面影響。企業可以通過在安全可靠的雲環境中實施策略或按照網路彈性指南 [SP 800-160v2]將策略複製到多個位置來緩解這種威脅。
上述方式可以緩解風險，但無法消除風險。像Mirai這樣的殭屍網路會針對主要的網際網路服務供應商執行大量DoS攻擊，中斷給上百萬網際網路使用者提供的服務。攻擊者還有可能會攔截和阻塞企業中到PEP或PA的部分或所有使用者賬戶(如分部或某個遠端員工)的流量。這些場景下，只有一部分企業物件會受到影響(可能包括歷史的遠端訪問VPN，不僅限於ZTA)。
一個託管的供應商偶然情況下可能會導致基於雲的PE或PA下線。在過去，雲服務的IaaS和SaaS都經歷過中斷事件。如果無法通過網路訪問策略引擎或策略管理器元件，則一個操作錯誤就有可能導致企業無法正常運作。
還有一個風險，即PA可能無法訪問企業資源，因此即使授予了物件訪問許可權，PA也無法通過網路來配置通訊路徑。這可能是由於DoS攻擊或使用量過大導致的。這與其他網路中斷類似，此時部分或所有企業物件由於某種原因而無法訪問特定的資源。
5.3 憑據竊取/內部威脅
合理實現ZT、資訊保安和恢復策略以及最佳實踐可以降低攻擊者通過竊取憑據或內部攻擊造成的威脅。ZT中，不根據網路位置給予隱式信任的準則意味著攻擊者需要通過洩露的賬戶或裝置來在企業中找到立足點。合理部署和實現ZTA可以防止洩露的賬戶或資產訪問超出其許可權範圍內或訪問模式下的資源。這意味著攻擊者的首要目標是與資源有關的，且具有相關訪問策略的賬戶。
攻擊者可能會通過釣魚攻擊、社交工程或組合攻擊來獲取有價值的賬戶的憑據。"有價值"的含義與攻擊者的意圖有關。例如，企業管理員賬戶可能是有價值的，但攻擊者更關心財務收益，因此那些可以訪問金融或支付資源的賬戶更具有價值。為訪問請求實現MFA可能可以降低賬戶洩露造成的資訊丟失的風險。然而，使用有效憑據的攻擊者(或惡意的內部人員)可能可以使用授予該賬戶的許可權進行訪問。例如，一個具有有效人力資源員工的憑據或(企業所有)資產的攻擊者或惡意員工可能仍然能夠訪問員工資料庫。
ZTA降低了風險，並防止洩露的賬戶或資產在整個網路中漫遊。如果沒有授予某個洩露的賬戶訪問特定資源的許可權，則可以繼續拒絕對該資源的訪問。此外，相比發生在遺留的、基於周邊的網路中的賬戶洩露，ZTA可以使用一種上下文信任演算法(第3.3.1章節)來探測並快速響應該賬戶的請求。上下文TA可以檢測到訪問模式超出一般的行為，並拒絕該洩露的賬戶或來自內部的威脅對該資源的訪問。
5.4 網路可見性
正如在3.4.1章節中提到的，需要檢查並記錄網路上的所有流量，然後通過分析來確定並對可能的企業攻擊做出反應。然而，一些(有可能是大部分)企業網路上的流量對L3層網路分析工具是不透明的。流量可能來自於非企業所有的資產(如使用企業基礎設施訪問網際網路的合同服務)或拒絕被動監控的應用/服務。無法執行深度報文分析或檢查加密流量的企業必須使用其他方式評估網路上可能存在的攻擊者。
這並不意味著企業無法分析其看到的加密流量。企業可以採集加密流量的後設資料(如源和目的地址等)，並使用這些資訊來探測網路上活動的攻擊者或可能的惡意軟體通訊。可以使用機器學習技術來分析那些無法解密和檢查的流量。企業可以引用機器學習來將流量分為有效的或惡意的流量，並對後者採取相應的補救措施。
5.5 系統儲存和網路資訊
與企業監控和網路流量分析有關的威脅就是分析元件本身。如果使用儲存的監控器掃描的網路流量和後設資料來構建上下文策略，進行預測或用於其他分析，這些資料就可能會變為攻擊者的目標，因此需要保護網路圖、配置檔案和其他型別的網路架構文件等資源。如果一個攻擊者可以成功訪問到這些資訊，他們可能會進一步洞察到企業架構，並識別出後續偵察和攻擊的資產。
ZT企業中的攻擊者可能會偵察的另一個資訊是用於編碼訪問策略的管理工具。就像儲存的流量一樣，該元件包含了到資源的訪問策略，攻擊者藉此可以瞭解到哪些賬戶最有價值(如，可以訪問目標資料來源的賬戶)。
對於所有有價值的企業資料，應該將防護重點放到阻止未授權的訪問(和未授權的訪問嘗試)。由於這些資源的安全性很高，因此它們應該具有最嚴格的訪問策略，且只能被指定的或專有的管理員賬戶訪問。
5.6 依賴專有資料格式或解決方案
ZTA依賴多種不同的資料來源來作決策，涉及到的資訊包括請求物件、使用的資產、企業和外部情報以及威脅分析等。通常會使用資產來儲存這些資訊，且對資訊的互動並沒有一個通用的、開發的標準。這可能導致企業由於互操作性問題而被供應商鎖定。如果一個供應商有一個安全問題或出現業務中斷，則該企業有可能無法在不付出極端支出(例如，替換部分裝置)或不經歷漫長過渡過程(例如從一種特定格式的策略規則轉換為另一種格式的策略格式)的前提下遷移到一個新的供應商。像DoS攻擊，這類風險並不僅限於ZTA，只是因為ZTA嚴重依賴動態訪問資訊(企業和服務供應商)，中斷的發生可能會影響到一個企業的核心業務功能。為了緩解相關的風險，企業應該對服務供應商進行全面評估，可考慮的因素除效能和可靠性外，還應該考慮供應商安全控制、企業轉換成本和供應鏈風險管理等。
5.7 在ZTA管理中使用非個體實體(NPE)
可以在企業網路中部署人工智慧和其他基於軟體的代理來管理安全問題。這些元件需要與ZTA管理元件(如策略引擎、策略管理器)進行互動(有時候會代理人類管理員)。如何在一個實現Z他的企業中對這些元件本身進行認證是一個開放性的問題。大多數自動化技術系統在使用API為元件提供資源時，會使用某種方式進行身份驗證。
使用自動化技術進行配置和策略執行中存在的最大風險是，有可能將企業的安全態勢誤報為假陽性(將無害行為誤認為是攻擊的)和假陰性(將攻擊誤認為是正常活動的)，可以通過定期重新分析來糾正決策偏差並提升策略流程。
攻擊者有可能會誘導或強迫一個NPE來執行一些攻擊者無特權的任務。相比人類使用者來說，在管理或與安全有關的任務層面，軟體代理的認證標準(例如，API金鑰與MFA)可能會比較低。攻擊者可以與代理進行互動，理論上可以通過欺騙代理來獲得更大的訪問許可權，或代表攻擊者執行某些任務。攻擊者還有可能獲取到可以訪問軟體代理的憑據，並在執行任務時冒充代理。
6 零信任架構和與現有聯邦指導的互動
略
7 遷移到零信任架構
相比於基礎設施或流程的批量替換，實現ZTA更像一個旅程。一個組織應該尋求使用增量的方式來實現用於保護高價值資料資產的零信任原則、流程變更和技術解決方案。大多數企業會在一段不確定的時間內繼續使用零信任/基於周邊的混合模型，同時繼續投資正在進行的IT現代化轉型。如果IT現代化計劃中囊括了轉向基於ZT原則的架構，則可能幫助企業形成小規模工作流遷移的路線圖。
企業如何遷移到一個戰略取決於當前的安全態勢和運作方式。在部署以ZT為中心的環境之前，企業應該達到ZT的能力基線[ACT-IAC]。該基線包括企業能夠對資產、物件、企業流程、流量流以及相關依賴進行識別和分類。企業會在開發一系列候選的業務流程以及該流程中涉及的物件/資產前用到這些資訊。
7.1 純零信任架構
在綠地方式(指全新的環境)中時，可以從頭開始構建零信任架構。假設企業知道其需要在流程中運作的應用/訪問，就可以基於零信任原則來為這些流程生成架構。一旦確定了流程，企業就可以縮小所需要的元件，並確定各個元件如何進行互動。到此為止，後續就需要靠工程和組織經驗來構建基礎設施以及配置元件。取決於企業的當前配置和運作方式，可能會包含額外的組織變更。
實踐中，對於聯邦機構或其他組織來說，很難在現有的網路上行得通。但有時候會要求組織履行新的職責，這需要構建自己的基礎設施。這些場景中，可以引入一定程度的ZT概念。例如，一個代理可能履行構建一個新的應用、服務或資料庫的新職責。此時，可以圍繞ZT原則和安全系統工程[SP8900-160v1]來為代理設計新的基礎設施，如在授權訪問和圍繞新資源建立微邊界前，需要評估物件的信任度。新基礎設施的成功度取決於該設施對現有資源(如ID管理系統)的依賴程度。
7.2 混合ZT和基於邊界的架構
並不是所有企業都可以在一輪技術重新整理週期中遷移到零信任。當企業中的ZTA需要與非ZTA流程協作時，將無法確定其遷移週期。在遷移到ZTA方法的過程中，企業可能一次只遷移一個業務流程。企業需要確保通用的元素(如ID管理、裝置管理、事件日誌等)足夠靈活，能夠在ZTA和基於周邊的混合安全架構中正常運作。企業架構師還有可能將ZTA候選方案限制為可使用現有元件介面的方案。
將現有流程遷移到ZTA很有可能需要對部分現狀進行重新設計。企業可能會藉此採用安全系統工程 [SP800-160v1] 實踐(如果流程中還沒有采用的話)。
7.3 將ZTA引入基於周邊的架構網路的步驟
遷移到ZTA需要一個組織詳細瞭解對其資產(物理和虛擬)、物件(包括使用者特權)以及企業流程。PE會使用這部分資訊來對資源訪問進行評估。不完整的資訊通常會因PE(缺少資訊而)拒絕請求而導致業務處理失敗。特別是在企業中部署了"影子IT"的情況下。
在將ZTA引入企業前，應該對現有的資產、物件、資料流和工作流進行調查。這種認知形成了ZTA部署之前必須達到的基本狀態。如果無法瞭解當前的運作狀態，則企業無法確定需要引入的新流程或系統。這些調查可以並行執行，但兩者都與組織業務流程的檢查有關。這些步驟可以對應RMF[SP800-37]中的步驟，任何採納Z他的目的都是一個降低機構業務職能風險的過程。圖12展示了實現Z他的路線。
在建立初始清單之後，需要定期進行維護和更新。更新可能會也可能不會影響也會流程，但需要對業務流程進行評估。例如，在對數字證書供應商進行並更後，可能不會造成重大影響，但會涉及證書根儲存管理、證書透明性日誌監控以及其他一開始並不明顯的因素。
7.3.1 確定企業中的參與者
為了讓零信任企業運作，PE必須要了解企業的物件。物件應該圍繞人和可能的NPEs，如與資源互動的服務賬戶。
使用特殊特權的使用者，如開發者或系統管理員，當給這些物件分配屬性或物件時，需要進行額外的審查。在很多歷史安全架構中，這些賬戶可能具有訪問所有企業資源的完整許可權。在使用日誌和審計動作來確定訪問行為模式的同時，ZTA應該允許開發者和管理員具有足夠的靈活性來滿足其業務需求。ZTA可能會要求管理員滿足更嚴格的置信等級或NIST SP 800-63A(第5章節 [SP800-63A] )中描述的準則。
7.3.2 確定企業所有的資產
正如2.1章節提到的，實現Z他的關鍵是能夠確定和管理裝置。ZTA可能還需要確定並監控非企業所有的裝置(這些裝置可能位於企業所有的網路技術設施上，或需要訪問企業資源)。能夠管理企業資產是部署Z他的關鍵。這包括硬體元件(如膝上型電腦、手機、IoT裝置等)和數字部件(如使用者賬戶、應用、數字證書等)。有時可能無法對企業所有的資產進行全面普查，因此可以考慮在企業所有的基礎設施上構建快速確認、分類和訪問新發現的資產的能力。
這不僅僅是對企業資產資料庫的分類和維護，還包括配置管理和監控。對一個資產當前狀態的觀察能力是評估訪問請求流程的一部分(2.1章節)。這意味著企業必須能夠配置、調查和更新企業資產，如虛擬資產和容器，也包括其物理和網路位置。在執行資源訪問決策時應該將這些資訊通知給PE。
應該儘可能地對非企業所有的資產和企業所有的"影子IT"進行分類。這可能包括所有企業可見的資訊(如MAC地址。網路位置)以及管理員補充的資料表項。這些資訊不僅僅用於訪問決策(如協作者和BYOD資產可能需要聯絡PEPs)，也用於企業監控和取證記錄等。影子IT帶來了一個特殊的問題，因為這些資源是企業所有的，但不像其他資源那樣進行管理。特定的ZTA方式(大部分是基於網路的)可能會導致影子IT元件無法使用(由於無法瞭解到影子IT，並將其加入到網路訪問策略中)。
很多聯邦架構已經開始確定企業資產。那些已經建立了CDM專案能力的機構，如HWAM[HWAM] 和軟體資產管理(SWAM )[SWAM]，在制定ZTA時有豐富的資料進行參考。機構也可能包含一組涉及高價值資產(HVA)[M-19-03] 的候選流程，這些HVA對機構任務至關重要。在使用ZTA設計業務流程之前需要在現有的企業或機構範圍內進行此項工作。這些專案應該是可擴充套件的且能夠適應企業的變更(不僅僅體現在遷移到ZTA時，也包括考慮成為企業一部分的新資產、服務和業務流程時)
7.3.3 確定主要流程並評估與流程執行有關的風險
機構應清查的第三項是確定並對機構任務中的業務流程、資料流和關係進行排序。業務流程應該通知在哪些環境下資源訪問請求是允許或拒絕的。一個企業可能希望在首次轉向ZTA時使用低風業務流程，這樣業務中斷不會對整個組織造成負面影響。一旦獲得足夠的經驗，就可以將更重要的流程作為候選。
使用基於雲資源或被遠端員工使用的業務流程通常是比較好的ZTA候選者，更可能獲得可用性和安全方面的提升。相比於從企業周邊進入雲或通過VPN將客戶帶入企業網路，企業客戶可以直接請求雲服務。企業的PEPs保證在資源請求授予一個客戶前能夠遵循企業策略。規劃者還應該在效能、使用者體驗和為特定企業流程實現ZTA而帶來的工作流上的脆弱性等方面進行權衡。
7.3.4 制定ZTA候選人的政策
確定一個候選者服務或業務流程的過程取決於多種因素：流程對組織的重要性、影響的物件組和工作流使用的資源的當前狀態。資產或工作流的風險數值可以通過NIST 風險管理框架[SP800-37]進行評估。
在確定資產或工作流之後，需要確定工作流使用或影響的所有上游資源(如ID管理系統、資料庫、微服務等)、下游資源(如日誌、安全監控)和檢視(如物件、服務賬戶)。這可能會影響到對首次遷移到Z他的候選者的選擇。與對整個企業物件至關重要的應用程式/服務(如電子郵件)相比，確定的企業物件(如採購系統)子集使用的應用程式/服務可能更受歡迎。
企業管理員需要決定候選業務流程中使用的準則集(如果使用了基於準則的TA)或資源的置信比重(如果使用了基於得分的TA)。管理員可能需要在調優階段對這些準則和數值進行調節。這些引數需要保證策略的有效性，但不能妨礙對資源的訪問。
7.3.5 確定候選方案
一但完成了候選的業務流程列表，就可以有一系列的候選方案。一些開發模型(3.1章節)非常適合特定的工作流和當前企業生態系統。類似地，一些供應商方案(相比其他場景而言)更適用於某些場景。下面是需要考慮的因素：
- 方案是否要求在客戶裝置上安全元件？這可能會限制使用或期望使用非企業所有的資產的業務流程，如BYOD或跨機構協作。
- 方案是否要求業務流程資源完全存在於企業場所中?一些方案會假設請求的資源位於雲端(稱為南北流量)且不位於企業場所(東西流量)。候選業務流程資源的位置會影響候選方案以及流程的ZTA。
- 方法是否提供了用於分析的日誌互動的途徑？ZT的一個主要元件是採集和使用流程涉及到的資料，並在做訪問決策是將其反饋給PE。
- 方案是否為不同的應用、服務和協議提供了廣泛的支援？一些方案可能會廣泛支援協議(web、SSH等)和傳輸(IPv4和IPv6)，而其他則可能僅更專於特定的場景，如web或Email。
- 方案是否需要變更物件行為？一些方案可能會要求額外的步驟來執行特定的工作流。這可能會更改企業物件執行工作流的方式。
一種解決方案是將現有業務流程建模作為試點專案，而不僅僅是替代專案。該試點專案可以用於多個業務流程或特定的某種場景。在將物件轉換為ZTA部署並拋棄歷史流程技術設施前，可以將試點當作"試驗場"。
7.3.6 初始部署和監控
一旦選擇了候選的工作流和ZTA元件，就可以開始初始化部署了。企業管理員必須使用選擇的元件來實現開發好的策略，但一開始有可能會使用觀察和監控模式。很少企業會在第一次迭代就完成所有的策略集：有可能會拒絕一些重要的使用者賬戶(如管理員賬戶)來訪問資源，而這些賬戶可能已經被授予了訪問特權。
有時為了確保策略的有效性和可操作性，新的ZT業務流程可能執行在只-報告模式。企業可以同時瞭解到基線資產和資源訪問請求、行為和通訊模式等。只-報告意味著應該為大多數請求授予訪問許可權，並使用連線的日誌和追蹤與一開始開發的策略進行比較。應該執行基本的策略，如拒絕那些由於MFA失敗或已知的、攻擊者控制或破壞的IP地址，並記錄此次訪問請求。但在一開始部署時，訪問策略應該更加寬鬆，以便從實際的ZT工作流互動中收集資料。一旦建立了工作流的基線活動模式，就可以更容易地識別異常行為。如果無法以更寬容的方式運作，企業維護者應該仔細地對日誌進行監控，隨時準備基於維護經驗來修改訪問策略。
7.3.7 擴充套件ZTA
當獲得足夠的信心，並正確設定了工作流策略之後，企業就進入了穩定維護階段。此時仍然需要對網路和資產進行監控，對流量進行記錄(2.1章節)，但應該以較低的節奏對策略進行修改(因為它們不應該很嚴重)。所涉及的資源和流程的物件和相關方也應該提供反饋，以便改進運作方式。至此，企業管理員可以開始計劃ZT部署的下一個階段。與之前的推出方式一樣，需要確定候選工作流和解決方案集，並制定初始策略。
然而，如果工作流發生了變更，則需要重新評估正在運作的ZT架構。系統重大變更，如新裝置，軟體的重大更新(特別是ZT邏輯元件)，以及組織架構的變動等，可能會導致工作流或策略的變更。實際上，應該重新考慮整個過程，並假定已經完成了部分工作。例如，採購新裝置之後，此時沒有建立任何使用者賬戶，只需要更新裝置清單即可。