零信任的IT環境架構

Zero Trust Architecture — NIST 800–27 標準介紹。

32 min readOct 27, 2020

"只有通過將系統定義為代碼，才能為重要的系統實現零信任模型。否則，管理系統中每個流程的控制的手動工作將會非常繁重。"

現今的大型企業環境越來越複雜，可能會有總部/分公司的內部網路，行動裝置，雲端服務等等。傳統的防火牆的Zone/segmentation概念(internal/external/DMZ三隻腳)的分類方式已經越來越無法有效的對應這一些新型態的網路服務，故”Zero-trust”概念被提出來應對現今日益複雜的環境。而NIST(國家標準暨技術研究院-美國的不是台灣的)，定義了800–27的標準與架構建議與實作方式。

Zero-Trust 概念,以下會簡稱會ZT，而Zero-Trust Architecture則簡稱ZTA:

ZT的概念主要是在保護"資料"，但它也延伸到該資料所乘載的服務/設備/人員，ZT的假設是:駭客/病毒/惡意程式等等已經存在企業的整體網路之中，這個網路基本上是"不可信的"。哪麼企業就必需不斷對這個不信任的網路持續分析與評估風險於存在於這個不可信的網路之中的所有公司的數位資產，並找出對應的方式將風險將低。在ZT中保護的方式通常是"最小化"access這些數位資產的權限，重點是"持續的"authenticating and authorizing。傳統的驗證與授權就是驗證一次之後就完成了，這麼做有其缺點存在。因為驗證過後，驗證系統後面的使用者行為就都不管了。而ZTA的設計架構包含了網路/系統及日常的維運。換句話說ZTA實行不只是技術層面。還包含了流程變更，核心原則等。

ZT的由來

這一個名詞是由美國國防部底下的國防資訊系統署(Defense Information Systems Agency, DISA)所提出的，理念是由傳統的perimeter-base的傳統防禦模式進化到每一個transactions(或access request)都要檢查的模式。

ZT的基本概念

主旨就是保護企業的數位資產，權限的給予應該要是明確的。意思是甚麼樣的系統/服務/人員該有甚麼權限動作(例如讀或寫)應該要非常明確並且能夠持續監控這些動作。ZT是一個end-to-end模式，意思是從服務的發起端到最終端會經過很多的裝置/系統/服務/認證等等節點，這些在服務要求發起時所經過的這些節點都必須要是最小的授權。

ZT/ZTA在NIST 800–27 的運作定義如下:
Zero trust (ZT) provides a collection of concepts and ideas designed to reduce the uncertainty in enforcing accurate, per-request access decisions in information systems and services in the face of a network viewed as compromised.
Zero trust architecture (ZTA) is an enterprise’s cybersecurity plan that utilizes zero trust concepts and encompasses component relationships, workflow planning, and access policies.
所以由上面定義可以知道，要實現ZTA不只是技術層面還需要政策面來配合。在此一模式下我們就可以將整個企業的資訊系統/環境的不確定性/風險將到最小。

最終目的跟所有的資訊安全目的是一樣的:防止未授權的人或物進到不該進入的服務或資料中，並且能實現小最權限(last privilege)的動作的控制程度。

下圖為簡單的一個ZT access簡圖

在這上圖中，有兩個部分作為Access control system， PDP(policy decision point)and PEP(policy enforcement point)。這一套系統還是要實現兩個最基本的access control: authentication and authorization。但我們還有更進階的問題要問(在實行這一套系統時)。
1. 這一個人員/系統在要求獨立單一的要求(access request)時，我們有多少"信心程度"真的是這一個人/系統所要求的嗎?
2. 這一個人員/系統要求存取資源時，我們有多少”信心程度”這一個人/系統真的是可以存取的嗎?
3. 這一套系統或裝置在存取服務時，它的健康狀態如何呢?
4. 還有其他的因素是要被我們被列入"信心程度"的因素中嗎?例如:所在地點或Appliction/OS版本等等。

Untrusted Zone就字面上一樣，所有未經過PDP/PED的traffic都會停留在這裡。哪甚麼又是Implicit trust zone呢?
打一個比方，機場安檢 — -
在我們要搭機時，我們需要經過一連串的安檢之後會在登機區等待上機。在安檢後要到登機門的中間區域，我們都做過基本的海關(PDP/PEP)檢查。這一段區域所有的旅客(network traffic)都是經過基本可信的。所以implicit trust zone就是這一段旅客登機區。
但由於PDP/PEP實行一連串的詳細安檢完之後就無法在控制通過的traffic，故這一段的Implicit trust zone要越小越好。

根據上述這些因素，企業需要建立的是一個動態的risk-based policies for resource access而且需要設定企業內所有的系統或設備都能夠符合這些做法。意味著企業不應該只實行類似帳號密碼的基本認證，而應該去驗證這些系統或人員在企業的數位資產中，是不是每個”執行動作”都符合公司的資安政策或要求呢?

ZT的精神(或者說是信念)

雖然之前提及ZT倡議不要用傳統的firewall zone/segmentation/perimeters base的哪中大區域範圍概念來實行，但其實我們只是把zone /segmentation/perimeters更細緻化的區分，從大的zone/segmentation /perimeters導向 micro-segmentation/zone/perimeters的概念。

ZT的基本精神如下(注意:每個企業的狀況有所不同，故不是一定要全部實行的)

所有的資料/運算服務都被視為資源(resource)的一部分:
從企業的業務流程(整個end-to-end的資料流)來看，會經過企業非常不同多的設備(wireless/firewall/router/server/storage等)或應用程式或服務(例如Cloud Services)，第一步就是要能跟對這些設備或服務做"分類"，才能決定哪些人或服務甚麼樣的權限進入哪種資源。
所有的通訊(traffic)都必須要是安全的:
我們必需假設企業不論內部的網路(LAN)或外部的網路(WAN)都是不可信的，所有的traffic走這些WAN/LAN都是不安全的，我們信任的區域應該只縮小到這些traffic會經過的設備甚至是這些設備中的Services。所以需要實行一些安全的方式來保護這些traffic.故在這裡的保護必需要達到authentication/confidentiality/integrity。
進入到企業的每個單一resource(如第一點提到的)它的access要求必須細緻化到per-session basis:
例如我這一個transaction(access request)是要對某一個share folder修改某一個檔案。哪麼我就要針對這一個放檔案的動作，從endf-to-end(你的電腦到最後該folder的storage)會經過的每一個裝置或服務有相對應的檢查。
進入到這些resource是由動態的policy來決定的 — -包含"觀察"終端設備ˊ現行與歷史狀態包含(使用者電腦)驗證，該設備的應用程式，對發起要求的服務/設備。甚至包含整個使用者發起服務要求的行為模式。
我們必需"時時刻刻"確認企業IT環境內的所有設備/服務都是最安全的狀態並且能夠持續監控它。這邊可能是OS/Application/Anti-virus是不是在最新的版本，patch有沒有上，hardware的firmware是不是新版本，甚至設定(configuration)是不是如企業的policy所要求的?有沒有並異動?
最重要的是 — -針對這些事企業有沒有一套系統能"持續"監控。
所有的資源的驗證(authentication)與授權(authorization)都要是動態的:
這是一個持續不斷的觀察end-toend的過程，掃描/評估/適應網路威脅與持續評估不斷變動的traffic.在實現ZTA時也會需要有ICAM(Identity, Credential, and Access Management)於資產管理系統來輔助。
企業必需盡可能的收集整個IT環境的資訊:
這邊說的不只是一般傳統的監控系統，而是更細微的資訊。例如每個人/事/物的發生，誰或甚麼對誰或甚麼做了甚麼樣的事.進而能夠分析最後能夠加入動態的Policy之中。

ZT的網路概觀

針對一些企業的內部(例如:LAN)或外部網路(例如:WAN)，分別在與這些網路是不是可以由企業自行控制的。實行ZTA必定要有上面所提的ZT精神伴隨著以下的一些假設:

對企業可以控制的網路:
1. 這個網路是不可信的
2. 這個網路內仍然有我們不可控的裝置，例如BYOD(bring-your-own-device).
3. 每個resource 的信任都是獨立給予的，例如我們信任這一台Server，卻不應該只要在這台server上面跑的service都應該信任，必需分開來看。

對企業是不可控的網路:
1. 不是所有的企業資源都會在可控的網路內，我們有時會有一些外部服務存在於外部網路中(例如雲端服務)
2. 員工於外部環境工作時它們的網路環境是不可信的。也就是所這些access reuest有可能是假的或是部分被修改的。所以針對這些使用者如何實行依些安全的方式(authentication/confidentiality/integrity)是重要的。

ZTA的架構中的各部分元件

上圖為第一張ZT簡圖(Zero Trust Access)的詳細版本，上圖將PDP再分為兩個部分，Policy Engine and Policy Administrator。在Control Plane and Data Plane範圍以外的是輔助的資料來源或功能。
以下為每個元件的功能

Policy engine (PE):這是決定有"access request" 時要不要放行，PE會使用企業已經訂定好的資安的policy/rules來決定，從外部資料來源來擷取(例如 CDM系統)。PE會決定可以access與紀錄所有的access request，決定後由PA(Policy administrator)來執行。

Policy administrator (PA):這個元件主要是建立或關閉subject與resource地的通訊。它會產生一個token/credential在client端，Client帶著這個token就可以access resource,PA會與PEP溝通告知要開啟通訊管道。有些產品會把PE還有PA視為一體。

Policy enforcement point (PEP):這個元件負責實際開啟/關閉/監控subject到resource的通訊。

在這兩個之外的元件，我們有一些其他元件來輔助ZTA來做決定是否放行這些access request。

Continuous diagnostics and mitigation (CDM) system:這是有關於收集企業數位資產的狀況，簡單來說這是提供資產狀況給PE評估放行的可能性。

Industry compliance system:這是企業的稽核系統，可能包含的內外稽核規則，已確定ZTA的架構還是處於這些要求之下。

Threat intelligence feed(s):這是情資威脅平台系統，可以提供最新的資安威脅給PE。例如今天有一個最新的系統漏洞，然後透過CDM系統知道有一個系統有這種漏洞，哪PE就可以決定立刻關閉這些有漏洞的連線要求。

Data access policies:這是access rule，它可以是靜態(由企業事先定義好)或動態(由PE產生)，這一個功能是資源授權的給與。也就是這些access reuest可以進到resource做甚麼樣的事。

Enterprise public key infrastructure (PKI):PKI系統，相信有資安概念的都知道不用特別多做解釋。

ID management system:這一個也不用多做解釋,帳號系統-像Windows AD or LDAP。

另外"Network and system activity logs" and “Security information and event management (SIEM) system”都是屬於log系統。可以提供給PE決定是否放行的依據。

實行ZTA的三種架構

實行ZTA時沒有絕對同一套方式，視您企業現行的狀況來決定的。

1.Enhanced Identity Governance:
主要使用身分驗證的方式來產生access policy/rules，根據身分驗證來產生這個驗證可以對那些資源做甚麼事。一旦這個驗證被註銷了，相對應的access policy/rules也會被消除。但PE也會參考其他的資料來源決定放行的層級，例如參考CDM系統加以評估。針對這些外部參考資料access policy/rules也會不太一樣。例如如果這個access reuest是在分工公司網路，不在總部網路，哪就不給這一個身分有核心系統刪除的權限。
這種方式適合企業是網路是不可控的，也就是可能有外部(非企業)的設備會連線進到企業網路。有人會說，設類似DMZ或VLAN等等網路的方式就可以了，但你敢100%保證部會出問題嗎?

2. Micro-Segmentation:
此種方式跟傳統的firewall 運作方式一樣，只是將範圍(zone/segmentation)縮小到單一的設備或服務。我們會在每一個設備或服務前端擺設類似gateway or NGFWs的設備，而這個設備的功能就等同於PEP。而這麼多的PEP agent會受到PDP的控制。如果是設置NGFWs的設備/或服務，還可以加上這些設備原有的功能。
但是不是每一個devices or services都需要在前端擺上這樣一個裝置，則要看企業所處在的風險。全部都設置的話，整個IT環境的複雜度與管理成本都會升高整個ZTA系統的反應速度也可能變慢。

3. Network Infrastructure and SDP(Software Defined Perimeters):
這種方式是在網路層面做管控(可以從Layer 7 往下- overlay network)，這種方式也稱作SDP。SDP通常包含了SDN(software defined network)與IBN(intend-based networking)的概念。PA就會像網路設備的controller or control plane(負責設備的configuration/rules)，ㄧ樣受到PE的管控。當我們的網路層檢查是設定在Layer 7時，通常是agent/gateway模式(後面會提到這個模式)。

以上三種方式所提及的元件/服務都是邏輯性的，意思是在做ZTA佈署時一個單一"實體"的設備可以是包含上面所提到的元件功能。也有可能是一個邏輯元件包含了好幾個實體設備或軟體。所以在要實行ZTA前可以盤點一下公司內部的那些設備資產本身已經符合ZTA的要求了。上面提及的架構是一般常用的，企業也會根據自己的狀況與這些架構稍有不同。只要能符合ZT的精神就可以。

Agent/Gateway-Based的佈署模式:

這個模式下，PEP被拆分為兩個元件(agent/gateway)。由上圖舉例說明，Enterprise system中擺放agent(可能是安裝在使用者電腦或伺服器上)，每一個resource 前端有一個gateway(類似proxy的功能, Istio也是這樣做法)這個Gateway會跟PA溝通並接受PA的指令來決定是否放行。
當公司的裝有這一個agent的設備要求進入某一個resource時會跟control plane(PA/PE)溝通，這個agent會帶一些這項設備的資訊(OS/IP/port/session key等等)。驗證成功後agent與gateway會建立一個加密的通道開始資料傳輸，完成後這個連線會被終止。終止的原因也有可能是一些不正常的因素發生，例如session-timeout或於連線過程再次驗證失敗。
此種模式下你要對你的每一項數位資產有很好的管控能力，如果你都不知道這項設備在做些甚麼，這種方式也不適合貴單位來佈署另外這也不適合有BYOD的企業，除非這些設備也在企業的管控下。

Enclave-Based的佈署模式:

這種模式就很像一般傳統Firewall的作法，gateway後面會有好幾個reources。通常會是一個business function組合起來。例如workflow系統可能是一個Ap server 加一個DB server，又或是有某些原因企業的resource前面不能有gateway(可能是舊系統沒有API跟gateway溝通之類)。這種方式的缺點就是每一個資產無法各別保護，在這gateway的policy/rule是對這一群resource做保護。

Resource Portal-Based的佈署模式:

此種佈署方式PEP會是一個單一的元件(gateway)，在這gateway後面可以是單一的或一群的resource。這種方式的好處是你不用每個公司資產都裝agent(適合有BYOD的公司)，只要能確認能夠通過gateway的驗證就好。雖然在驗證時可以掃描來源端的狀況但只有一次性，之後就可能無法持續監控來源端的狀況。由於有這種缺點存在，企業必須要有其他的補救措施。而且這個gateway變成使整個PE/PA/PEP變成單一元件，容易成為攻擊目標:例如DoS。

Application Sandboxing佈署模式:

基本上就是把OS and Apllication分開來，意思是我只相信跑在sandbox裡的Application，這類的Sandbox可能是VM,Contianer 或CHEF habitat。PEP直接與Application溝通，也就是說在同一台的其他服務如要有著同樣的access rquest是會被拒絕的。
這個模式的好處是，我們已經把信任的範圍縮小的Application了。也就是所在OS layer若發生一些資安issues只要sandbox可以運作正常就不太會受這些issues的影響。但缺點是由於這些Application跑在sandbox環境中，我們可能無法監控這些sandbox環境確認它是安全的，數位資產管理也有可能做不到。所以在sandbox整體監控也必須有想對應的做法。

ZT的信任演算法

在實行ZTA時我們可以從之前的架構圖看到，PE(policy Engine)是最終決定要不要放行的元件，就像人的大腦一樣。但這個大腦必須要有很多資料來源來綜合判斷之後來下決定(如下圖)

如上圖，我們看到了一些資料來源

Access request:
這是來源端所帶的要求資訊，這些要求資訊是主要使用的資料。但來源端的本身資訊也會被使用，例如來源端的 OS版本，使用甚麼樣的應用程式要求，這個應用程式的版本夠不夠安全乃至於其他關於這些來源端的安全狀態相關資訊都有可能被用到。

User identification, attributes, and privileges:
這個資安人員來說就很容易理解，基本上就是甚麼樣的人或應用程式有甚麼樣的權限做甚麼樣的事，而且還會根據不一樣的人事時地物來的條件給出不一樣的權限動作。

Asset database and observable status:
這項資料來源是企業所擁有的數位資產資料與現行該資產的狀態，數位資產資料庫會跟現行的資料狀態做比對。可能是網路IP，OS版本，使用甚麼樣的應用程式等等資料，若比對不符就會拒絕該項要求。

Resource access requirements:
這是一個預先定義好的Policy set，主要是每一個User ID與其相對應的最小權限動作。而access requirements的要求可能要有MFA，網路IP位置，要傳送資料的敏感度(有時也稱作data toxicity)等資料。而這些access requirements的產生會同時存在於Data custodian與相關業務會運用到這些資料的業務流程中。

Threat intelligence:
這個就是現在很多業者在做的情資威脅平台，也是ZTA的資料來源之一。

但這些資料來源的分數權重要如何給呢?可能是企業已經有相對應的方法可以給予這些項目分數權重，也可能是用專有的演算法。最後就是一路往下送執行了，在PE新的決定往下執行時有可能會因為現行的session不合決策，會被斷線或暫停。

不同信任演算法規則

我們有兩種不同的演算規則，第一種是 factor(各項因素)的評估可以使用
"binary decisions" 或"整體分數的各項因素的權重"或是"信心程度"。第二種w同一個來源要求的單一與其他的access request評估。

Criteria- versus score-based:
Criteria-based就是企業定義好每個來源(帳號/設備/服務等)的要求被事先定義好它能執行的動作(例如讀取或寫入)。
Score-based根據要求來源的各項資訊打分數外加企業可能已經定義好對這一項來源的分數，只要分數高於設定好的值哪來源要求就會被通過。但如果分數沒有達到的話，哪原來定義好的允許動作還會被降低。例如原來能夠對某一個檔案讀與寫，分數沒有達標會被降為只能讀取。

Singular versus contextual:
Singluar指每次的access request都會被獨立評估，也就是PE系統不在乎這個來源上一次是不是有惡意的要求或是下一次也有可能有惡意要求。好處是這方式系統評估很快要不要給過，但缺點是它無法加入之前的歷史紀錄一起評估。
contextual 就與Singluar相反了，評估歷史紀錄。但若PE評估的歷史紀錄越多，哪這個access request反應就會很慢。

上述所提及到的這些演算法方式是可以搭配使用的，但contextual+score-based的方式運作得比較好的。因為我們可以對來源要求有一定的信心程度認為現在這個access request是可以信任的。

理想中我們應該使用contextual方式的ZTA演算法，但現實中對有些企業還說有可能沒辦法一下子實行這種做法(受限於公司內的現行的IT基礎建設)。但我們應該朝著這個目標前進，因為此種方式能夠將潛伏在公司內部的攻擊者的風險減到最低(PS這讓我想到cyber kill chain的阻斷理論)。在實行ZTA時我們需要從多方面考量，例如安全性/易用性(usability)還有具成本效益的方式。哪甚麼是安全性或者具成本效益相信大家都很明瞭，哪甚麼是具易用性(usability)呢?
就是過去的歷史紀錄可以被我們很容易拿來作為參考資料之用。舉例來說在ZTA架構中持續驗證使用者與分析/辨別使用者的行為就會有易用性的情況發生。例如在過去的歷史紀錄中HR部門有10位同仁在周一到週五的上班時間平均有50筆accress record，可能有時有加班情況record大概只有10筆左右。但有一天假日accress request超過15筆以上，這時系統就可能要發出相關的告警給HR部門主管或是系統自動採取下一個動作。所以這是過去的資訊提供了易用性的資料給我們，但之前提過了Singular就沒有使用過去資料的做法。

ZT中的網路環境與元件

相信對網路熟悉的人都了解網路設備中被分成兩個部分control plane and data plane，在這裡就不多加解釋了有興趣的人可以去查閱相關資訊。在ZTA中PA 及PEP就是control plane負責下決定，data plane就是真實的資料通過的地方。

需要那些網路元件來建構ZTA呢?有以下部分
1. 網路的基礎建設，提供網路連結(network routing)與基本服務(像DNS服務)。
2. 有相關的產品或解決方案能夠讓企業辨別與控制相關的數位資產以及能夠辨識該資產目前的健康程度。
3. 有相關的產品或解決方案能夠監控所有企業內的網路流量(從ISO L1 to L7)以便能夠分析並提供給PE作為下決策的資料來源之一
4. 所有的要進到企業的resource都要經過PEP。所有的access reuquest都必續經過驗證授權等程序。這個好處在於PEP在resource之前，相關的網路掃描或攻擊都不直接接觸該resource。不過有些網路基礎服務是不必經過PEP而是公開，例如DNS服務。而有關這一類基礎服務的防禦就必須用另外的方式。
5. ZTA中的PE/PA/PEP在邏輯上是切開來的而且不會”直接”access企業的resource或數位資產，這些服務只是像gateway決定要不樣放行而已。
6. ZTA架構需要用的相關資源能夠應付企業現在與未來的需求。如同前面看到的架構圖，因為所有的access request都需要經過ZTA相關的元件。所以先關的元件服務如果有問題(例如運行的資源不足或是服務或底層的機器掛掉)哪麼就會立刻影響企業的運行。所以ZTA的HA/scability都需要備考量。
6. 企業的來源端可能無法連到PEP，企業內的LAN環境大概不會有甚麼問題。但是外部辦公室或行動員工(在外面跑來跑去)連線也需要納入考量。

部署的情境/Use case

有些公司其實可能已經有ZTA的雛型(例如perimeter-base的架構)，以下我們介紹幾個部署的情境。再次說明以下的部署情境，每個企業的狀況有所不同。底下的都是讓您參考的資料，最重要的是能夠達到ZT的精神即可。

企業總部與分公司的架構

上圖應該是大部分比較大的企業會使用的架構，絕大部分的IT服務都位於總部只留下很少的IT資產在分公司。ZTA的服務都會放在總部，分公司的使用者可能是安裝ZTA的agent在電腦上面或是用portal的方式來驗證，要注意的是因為遠端使用者現在要經過PEP再到要去的地方。所以網路的回應速度需要被考量進去。上圖是透過Internet的方式，你可能也會使用site-to-site VPN或是專線的方式。

多雲架構

現在越來越多的企業開始選擇雲端平台作為企業的IT服務之一，為了不讓同一個雲端業者綁住同時也怕該雲端業者服務有問題時造成企業無法營運，多雲策略也開始應運而生。如上圖，我們將服務分在不同的雲端平台上中間建立連線，兩個Server之間使用SDP(software defined perimeter)來作為安全的連線。我們可以看到若企業還是使用傳統防火牆來管理企業與雲端的連結會有很多不足的地方。如之前提及的ZT精神:不信任公司內外部的網路環境。哪PE及PA元件你可能會擺在任何地方(可能是公司內部也可能是雲端業者A或B，更有可能是另一個雲端業者C)端看你的信心程度，但無論如何透過ZTA企業內外部的access request to resource都會在掌控之下。

企業內的非公司職員(可能是訪客外包商或是駐點人員)

這些人只完成被賦予應該要完成的工作而去到應該去的resource。

這種狀況應該是很多企業有的情境，傳統做法就會是切一大堆的VLAN外加一堆防火牆的隔離。狠一點的可能再把全公司電腦的MAC address加到資料庫裡。但老實說現今的網路是動態的你可能遇到惡意的外來者拿著電腦亂接網路雖然有MAC address作為來源。但也有可能惡意使用者會使用到員工的電腦等等不確定的事。所以ZT的精神再次被使用，使用SDP(software defined perimeter)的方式來應用這個狀況。

使用ZTA的風險議題

沒有一家企業或單位能夠完全對資安風險免疫不論使用哪種方式，我們能做的只是盡量地降低風險。所以ZTA也不是百分百的零風險，它也有以下的威脅存在

亂搞ZTA的設定與參數

如前面介紹PE及PA是ZTA中做出決策的部分，如果這部分的設定及其相關的參數沒有做好，哪麼馬上影響的是公司的服務。但若設定的很隨便哪PE跟PA被攻擊的可能性就會變大，ㄧ但被攻陷哪企業所有的資源都有如無人之境可以被存取。這項議題你面對的是設定的不好有被"攻擊的風險"，設定的太過嚴苛你可能遭遇"營運的風險"

Dos攻擊或網路掛掉

網路掛掉不用說大家都不用玩，因為全部的服務都運作不了。所以網路的高可用性需要被考量。另外DoS攻擊是指針對PE and PA的部分，網路設計上該怎樣避免或降低PE and PA被攻擊的可能性。一旦這兩個元件被攻擊你將又會遭遇公司業務維運上的風險。

看不見的網路內容

之前提到的，我們應該要能對企業中網路的資料能夠擷取與分析。但很不幸的，現今有越來越多的網路服務有著加密的功能(例如https)。有些企業根據公司的政策可能會在 network gateway or proxy server強制解密，若沒有的話我們應該怎麼做呢?我們還是能夠收集這些加密流量的metadata來作為分析資料(大都使用Machine Learning方式)的來源，但在ZTA中這一部分只需要用在無法受企業管控的資產上。因為受管控的資產是我們所信任的(當然信任程度不一樣可以做的事也就不同)

儲存網路內容的地方

剛剛提到我們需要收集網路流量來分析，但收集過來的資料所存放的地點應該需要被嚴格保護及管控。否則這些歷史資料ㄧ但被修改哪整個ZTA也就沒有意義了，因為所做出的決策是錯誤的。

依賴專有的資料格式

由於ZTA需要很多數據來源做為參考，在統整或交換這些資料時我們所用的資料格式必須要是通用的，不然我們很容易被某個廠商或解決方案綁死。也難很利用到現有的設備或服務在做資產更換時也會有很多限制。

用非人類來當ZTA的管理者

簡單來說就是用AI或其他軟體解決方案來代替人類當ZTA的管理者(操作與調整PE或PA)。但這些非人的管理者怎麼樣在ZTA中驗證自己呢?這個是需要被討論的。但最大的風險是這些自動化的管理方案會帶來兩個問題
1. false positives(假警報) — 明明是正常的access request卻被判斷有問題
2. false negatives — 真的有問題的access request卻被放放行了
這些大都可以使用 "regular returning analysis"來降低這種狀況發生。
但另一方面這一類的解決方案就會變成是攻擊者的首要目標了，一旦這類的AI被攻陷接下來攻擊者就可以暢行無阻。

遷移到ZTA

遷移到ZTA架構跟絕大多數的解決方案一樣是需要逐步實現的。例如相關人員要先有ZT的精神，符合ZT概念的流程變更到技術評估。但最重要的一點就是先盤點你的數位資產並進行分類。
從企業自身目前的資安狀態開始評估起從而建立baseline，從盤點分類企業本身的資產/使用者/業務流程等開始，哪些需要有ZT的需求那些不需要有，有了這些資訊才可以開始往ZTA的架構前進。以下我們介紹幾種遷移的進程。

ㄧ次到位

這大概很少有企業能做到，尤其公司越大人員其服務越多越困難。因為你必須知道企業IT環境的所有細節與跟該IT環境所有相關的業務流程，這個衝擊可能會很大。比較適合一開始公司要開始建立IT服務，相關人員要開始接受ZT的相關概念。但好處是一次到位我們受限制的因素就會很少，但可能舊有的設備或服務就無法使用。

過渡型架構(ZTA與傳統防禦DMZ並存)

這應該是已經有IT服務的企業會使用的方式。實作這種方式不應從技術角度來看，而應該是從每種企業的業務流程來觀察。這個業務流程關連到那些IT設備/應用程式/服務等，一次一個流程。但由於很多設備/應用程式/服務不只對應一種業務流程而可能是好幾個，所以評估相關的設備/應用程式/服務能夠同時在ZTA與一般傳統的DMZ防禦模式下共存。但這樣也同時限制了我們可以選擇的ZTA解決方案。一次到位就不會有這樣的問題，不過原有的設備可能可以繼續使用。

逐步過度的步驟

之前我們說到我們必須收集從"業務流程"搭配道IT環境各項設備與服務才能做資訊分類，因為這些資訊都將成為PE做決策的依據。只要資訊不夠完成PE就可能下出錯誤的判斷而導致業務中斷，其中我們最怕的應該是
shadow IT — 有著資訊單位不知道的IT服務存在於企業中。
這些資料要怎麼收集呢?(注意:再強一次我們必須企業的業務流程來收集這些資料)我們可以參照NIST另一個標準 NIST 800–37 RMF(Risk Management Framework)，請參照下圖

辨認要求來源

在來源要求中會帶著User ID而來，有的可能是人用的有些是非人用(程式/服務)我們必須辨識這些ID來給予正確的權限才能有足夠的信心程度運作。關於此類的準則或基本要求可以參照NIST 800–63A(Digital Identity Guidelines)。

辨認企業控管的資產與非控管的資產於企業的網路中

這是最基本的要求，非企業控管的部分我們最起碼要能辨識與監控。由於今日的數位資產(不管是軟硬體)都會於企業的資產管理中進進出出。我們必須盡量能夠辨識新的資產與移除舊的資產資料。在此類的資產管理中能夠知道此類資產(從容器到實體機，從軟體到硬體)的各種狀態包含了這個資產的設定檔管理(Ansible/CHEF/Puppet)。這一些資訊也是PE的評估'資料之一。在此類的辨識與管控下，Shadow IT將會不復存在。

辨認主要業務流程與評估執行ZTA架構所帶來的風險

我們可以先從衝擊沒有哪麼大的業務流程開始試行，有了更多的施行經驗逐步地推行到核心業務流程。
若是剛開始使用雲端服務或是從work from home的員工是一個不錯的開始測試。
哪麼如何選擇我們的第一個ZTA的一個完整業務流程的服務呢?有幾個因素我們可以列入考量點: 該業務對公司的重要性，影響的組織人數，以及這個業務流程現行相關的資源狀態。這時我們需要進行風險評估分析，可以參考NIST 的 Risk Management Framework(SP-80037).
在某個業務流程被確認之後我們需要開始對這個業務流程相關的上游的IT服務(例如: ID management system, database, application)及下游IT輔助服務(例如:logging, Security monitor)及entities(例如:使用者，service account)以上這些會關係到這一個業務流程的所有相關都會影響我們第一個選擇ZTA的實行。接下來我們就要決定要選擇使用 criteria-based TA or score-based TA(信心程度)來實行在這一個業務流程中。過程中管理者需要不斷調整參數來確認是有效且不會影響使用者的日常業務活動。
選擇完用哪種TA之後我們就要看這一個被選擇的業務流程適合哪種部署模式或廠商的解決方案。不論是哪種有幾個因素也需要被納入我們的考量之中。

1.這個方案是不是要安裝agent在所有相關的公司的相關數位資產中?因為有可能公司現行有BYOD政策允許員工有私人的設備在收發公司的email(這涉及法律問題)。
2.這個業務流程是只有在公司內部跑(該業務起始與完成都只跟公司員工有關不涉及公司以外的人)或是該業務也會影響公司以外的人。這兩種狀況需要連結的resource有可能不同所以有不同的稱謂，只在公司內的稱 east-west traffic, 牽扯公司外的稱north-south traffic。
3. 這個方案可以產生足夠精細的log讓我們去分析嗎?尤其是所有相關服務節點與人員互動的log.
較建議的方式應該是有架構跟log分析後進行觀察但還不把access policy實行下去，確認有足夠資料分析後逐步地將每個resource 納入access policy.