零信任架構(ZTA)簡介

46 min readJan 23, 2024

當今的網路安全的保護方式可以用建築物的牆壁和門進行類比，從而允許犯罪分子嘗試撬開門鎖。如今，組織依賴其安全“門鎖”，然後對門鎖進行嚴格監控，以確保犯罪分子不會闖入。最好是隔離資產，然後依靠檢視威脅來阻止未經授權的使用者進入。我們可能想看看是誰在敲門，但絕對必須透過拒絕開鎖的機會來防止惡意行為。這就是為什麼迫切需要有效的零信任部署的本質。此外，眾所周知，駭客的主要目標是滲透網絡，然後能橫向移動，以便以更高的特權憑證存取系統。 零信任可以防止未經授權的使用者隱藏其活動，從而限制對授權使用者的存取。

而本文將分為六個部分來介紹ZTA，別分是:

ZTA的背景脈絡
零信任的定義、概念與組件
零信任的目標
零信任的效益
ZTA的規劃考量
ZTA的實作範例
零信任使用案例

ZTA的背景脈絡

ZT的產生源因於IT新技術的產生，特別是雲端運算的崛起。也是因為雲端，ZT的概念也從這裡產生 — Micor-segmentation。而也因為使用雲端，進而產生更多的資安曝險。雲端的崛起加速了組織的數位轉型，但同樣的任何東西有好的一面(數位轉型)就一定有不好的一面(資安曝險)，雲端也帶來了新的挑戰(技術、財務、安全等方面):

雲端服務用得越多、越深，複雜性變得更高
雲端與地端機房的整合也可能變得困難
雲端所造成的大量遠端連結產生了風險

Notes:關於組織如何使用雲端來達成組織的數位轉型，可參閱麥肯錫的這一篇文章 — CIO/CTO如何利用雲端加速數位轉型。

再來是組織的資料不再存在於企業的內部，而是雲端業者的機房中。但是組織還是負有資料保管人的責任。這意味著傳統地端機房保護資料(城牆與護城和)的方式不再有效。

與此同時零信任與其ZTA就產生來對應此一挑戰。ZTA 根據「Never trust, always verift」的概念建立雲端(機房不是我們控管的)並授予對雲端資源的存取權。而其架構設計是 inside out而不是傳統的outside in方法。基於ZT的概念進而產生了不同的零信任面向 — 零信任模型、零信任安全模式、零信任方法、零信任架構等。

零信任的定義、概念與組件

ZT概念的原則於實踐是用來減少在現今動態的IT環境中的資安風險。由於我們前面說的傳統的資安方式(城牆與護城河)，對動態的IT環境不再有效。所以ZT的本質是將所有的資安技術方法細緻化，也就是我們將針對每個帳號/設備/服務等實行嚴格的Authentication/verification，不管是內到外或是外到內。

所以ZT要保護的是組織的數位資產，而非建立一道護城河(區別組織內與外)，而其資產的風險態勢也不是基於它的位置，而是是否有強大的驗證/授權控制措施位於其中。根據ZT的概念，組織的安全態勢(Security posture)是基於Authentication/authorization與基於風險分析。所以要存取系統/資源之前必需要先進行authentication/explicit authorization。這些概念就會產生以下的規則：

當實體(人員/設備)請求存取資源時，不對實體的可信度做出假設
從零權限開始，然後應需求加上所要求的權限
假設資安事件已經發生並驗證所有人員、設備、系統、網路和資料存取，無論這些發生在何處、發生在誰身上或發生了什麼

五個原則

美國國防部對ZT定義出了五個原則:

原則一: 假設整個環境是惡意的

攻擊者已存在於網路的內部與外部
預設所有的使用者/設備/網路/環境都是不可信的

原則二: 假設攻擊已經發生了

大多數組織/企業都已經歷過大量的網路攻擊並且已經受到損害
在各項資源的建立/管理/防禦，心態是: 就好像駭客已經在網路內部一樣
應更仔細地檢視存取/授權決定

原則三: 永不信任，並不斷驗證(Never trust, always verify)

預設拒絕所有的存取(這也是一般我們在使用防火牆的預設設定)
針對每個使用者/設備/應用程式/工作流程/資料流進行最小特權設定(Last privilege)。傳統上，我們通常只有對使用者進行最小權限設定

原則四: 清楚地檢視

基於整個背景脈絡進行資源的安全性存取(此動作是持續不斷的)
有條件式的存取且條件可能會發生變化(因為環境是動態的)

原則五: 運用統一的方式來分析

根據資料進行數據分析與行為分析
紀錄每一筆的交易(transaction)

根據以上的描述我們可以得出以下幾個設計原則

我們應該在資料存取者(人或機器)的驗證還沒完全完成之前，拒絕所有的存取。對資源的存取是臨時的，需要重新驗證。存取的時間跨度由政策定義
存取資源的方式會有所不同，因為未經身份驗證不允許資料存取者進行存取
只有該實體(人或機器)被授權後才能進行資源存取
強制執行最小特權，特別是授予的最少必要存取權限
持續監控控制措施的實施和有效性

支柱

ZTA有著以下七個支柱:

支柱一: 使用者/身分辨識

保護/限制/強制 DAAS(Data/assets/applications/services) 存取，包括"身分、憑證和存取"等管理
MFA與持續性的進行MFA
持續性的驗證與授權並監控其活動模式
使用RBAC 和 ABAC 等方式授權使用者存取應用程式/資料

支柱二: 設備端點

對設備進行辨識、驗證、授權、盤點、隔離、保護、修復與控制，這些都是必要的
設備的即時診斷與修補，針對設備實施MDM(Mobile device Manager) 或C2C(comply-to-connect)計畫

支柱三: 網路/環境

對其網路/環境進行細緻化的存取/政策限制的實體與邏輯性的區隔(segment)
Micro-segmentation可更好地保護/控制 DAAS
微分段(Micro-segment)可以控制特權存取、管理內部/外部資料流與防止橫向移動(lateral movement)。

支柱四: 應用程與工作負載

應包含地端與雲端的系統/服務/應用程式
零信任的工作負載應該包含到所有的Stack層面，從應用程式層到虛擬層
從應用程式層到虛擬層(VM/Container)都要適應於ZT的架構
資料交付方式(例如Proxy的技術)都會是ZT decision/enforcement point的一部分
自行開發的代碼/Library都需要經過DevSecOps的審查

支柱五: 資料

ZT可以保護重要的DAAS

所以我們(資安從業人員)要對組織的DAAS有非常清楚的認知與理解。另外要根據系統的重要性對組織的DAAS進行分類，並發展其資料管理政策。這一類的資料管理政策會產生出:

資料類型
發展模式
傳送/儲存資料的加密方法

而DRM、DLP、軟體定義的storage與細部化的資料標籤都是非常重要的。

支柱六: 可見度&分析

可見度與分析可以讓我們理解與意識到重要的整理脈絡細節，這有助於更好地理解效能、行為和活動基線

而這也會強化我們異常偵測的能力，根據即時的背景脈絡存取決策進行動態的資安政策變更。另外我們也可以佈署一些感測機制來監控資料。解析網路封包也能讓我們得知一些狀況。

支柱七: 自動化與編排(orchestration)

自動化一些人工資安流程以採取基於政策的行動

SOAR就是一個很好的例子，可以自動回應依些早期有規劃到的一些資安威脅。

組件與元素

ZT在整個資源存取流程中有三個核心組件:

Communication — 實體、資源之間的通訊
Identity — 要求存取的實體
Resource — 被存取的資源

在以上的核心組件中，有兩種元素發揮作用:

Policy — 強制所有的連線應該怎麼進行，甚麼人/實體、時間、如何連到甚麼樣的資源
Data resource — Policy的資料來源，根據這些資料動態的調整其Policy。

這些元素的適用性取決於我們的使用方式和部署。以下是NIST SP 800–207中關於ZTA的架構其及流程，流程的說明可參閱本部落格＂零信任的IT環境架構＂一文。

零信任的目標

零信任的目標分為以下三大類：

一般性目標

解決信任假設和缺乏適當存取控制的安全風險。通常降低此類的風險就是＂降低攻擊面積與加強控制＂。
提供全面且一致的安全性，以防範內部和外部的惡意攻擊者
ZT主要可以解決運算/資料資源與請求存取的原則之間信任的短暫性
強化安全性以及動態政策的執行與決策(從雲端到地端)
用於旨在損害暴露的存取機制的內部/外部攻擊

技術性目標

制定一個框架來保護資源 —
如同前面我們提到了，組織在ZT的概念中不應該存在＂預先信任任何事物＂，不管這個事物是在網路的內部或外部。組織應該基於資料的價值與需要保護的重要性來設計一個具業務導向目標來設計其系統安全。而現有的網路安全技術和陳舊，效果有限，保護不足，基於實體網路、系統和基於簽章的威脅偵測的方法/框架也不再有效。
資安人員與相關人員的資安體驗不會變得複雜 —
ZTA會將環境中所有的數位資產(從網路設備到應用程式系統)變成一個具有一致性的存取模型。例如ZTA會審視你是誰？你現在要存取資源嗎？你用甚麼設備存取？之後才會開綠燈放行，而這些都是基於某個時間區段的風險評估。ZTA沒有那些複雜的一層層的 ACL 圖表清單，也沒有由潛在相關決策者管理的分層群組。也不再有沒有舊的或孤立的團體，負責人早已離開。不會再根據過時的型號/標籤進行授權。與組織調整或外包人員相關的設定、取消配置或存取權限撤銷不會出現延遲。因為這些作業全部都由PDP(Policy Decision Point)來自動執行了。
縮小攻擊面積與複雜度 —
我們之前有提到，傳統的資安防禦是＂城牆與護城河＂的概念。也就是說惡意的網路流量通常會被我們阻絕在＂城牆＂之外。但是一旦可以進到內部網路之後就是一馬平穿了，因為我們會覺得城牆內是安全的，故而不做任何設防（例如內網的流量不做加密）。也因為這種思維，讓駭客只要聚焦於攻破城牆就好。
而ZT的never trust, always verify的概念讓我們把內網當作外網看待，讓每一個資源都有自己的護城河。而這樣的做法也讓駭客無法進行或嘗試類似0 day的攻擊。PEP/PDP無時無刻會進行存取資源的決定是否該接受或拒絕。為此，ＺＴ將攻擊面積將由聚焦在每一個資源轉移到保護不良的資源上。
由於現代IT環境的日益複雜性: 不斷增加的IT專案與各類系統的改版/功能增加，這些在實際的存取動作發生前都需要有相關的存取決策。而因為舊有的存取政策在每一種資源/系統上都是孤立的，就會造成管理上有漏網之魚。而日益增加的複雜性，讓我們有了盲點（缺乏整體可見性），配置複雜化進而產生了漏洞與弱點（永遠有補不完的洞）。
雲端/混和雲/多雲/邊緣運算等環境存取控制政策管理（Access control policy management）更加複雜。ZT減少了此類的複雜性: 因為它假設每個存取要求都是惡意且不受信任的。所以ZT將保護的邊界縮小到每個應用程式與資料，來保護應該要保護的事物。這是因為ZT會提供比標準安全機制更有細緻度與針對性的存取配置的屬性。ZT將Access point數量的減少會導致對存取/權限的更嚴格控制，包括對廠商/供應商等第三方的存取/權限的控制。
強制最小特權 —
所謂的最小特權就是entity(人或機器)只能擁有他們完成他們應該完成作業所需的最小權限，而且當有需要時權限才會被給予並且是持續評估此類動作是否正常。ZT使用的是Micro-segment來將IT環境細分成不同的微小物件來進行保護。這樣的作法讓我們在不斷變動的IT環境中讓資安治理與維運團隊持續不斷適應其動態變化。
ZT包括基於目的的專用身份(dedicated identities)，也稱為身份角色(identity personas)所謂的身分角色有助於限制因身分外洩而造成的攻擊面。
強化控制與韌性 —
ZT的目標是強化IT Infra的韌性與安全態勢。在此目標下的ZTA會是減少IT infra/數位資產的攻擊可見度與可能的攻擊向量。也由於ZT的Micro-segment的概念，任何的資安事件的可能性與發生範圍我們都可以進行早期預防與最小範圍的圍堵。縮小攻擊面也意味著我們可以防止對內外部惡意者對IT環境的scanning與mapping。ZTA有兩個層次的架構: 在給予最小特權之前強制進行authentication與authorization。
將資安事件影響的範圍侷最小化 —
ZTA 的主要目標是使事故管理流程更加有效能和效率；為此，ZTA 的幾項核心設計原則（例如「never trust, always verify」）和持續違規的假設要求對所有系統實體進行持續的行為監控。
Micro-segmenation和持續網路存取授權的要求減少了潛在漏洞的影響半徑，因為它限制了駭客橫向移動的能力。當違規確實發生時，損害僅限於有限區域，並且可以針對事故範圍進行遏制/根除和補救工作。
ZTA 中包含的持續監控能力可以更有效地識別異常和事件。事故相關資料也用於更新 PDP，從而允許動態策略定義/執行，這對於限制整個組織網路的影響至關重要。

業務目標

降低風險 —
因為採用雲端與相關新興技術所帶來的風險，尤其是上述所提到的技術性目標。這進而可以減少業務的攻擊面，並且與組織的業務連續性跟韌性態勢保持一致也可維護。ZT減少的風險有：

橫向移動所產生的不正確權限
超越了need to know需求的存取權限
超越了特定存取週期（例如非上班時間）
存取是使用不受信任的設備
存取是使用不安全的方法（例如沒加密或無效的憑證）
阻止暴力破解、分散式阻斷服務 (DDoS) 或中間人 (MITM) 攻擊等方法

強化治理與合規 —

ZT有兩個主要的功能可以讓組織進行合規管理

Discovery
mapping out

所有的網路資產與相關的存取控制。以上的功能都是自動化的，以此讓所有的資產都與最新的合規要求一致。ZT還可以協助我們根據不同的資源的不同合規需求進行分離管理以符合合規需求，並且這些動作都有事後的稽核紀錄可供查詢。

讓組織文化與C-Level們的風險偏好保持一致 —

零信任的效益

ZT的效益可以讓我們從技術面（如減少被攻擊成功的可能性、強化可見性）到業務面（強化合規要求）。一些效益如下：

減少被攻擊成功的可能性
強化存取的可信度
強化可見度與分析能力
合規的強化
還有其他未列出的ZT綜合效益

減少被攻擊成功的可能性

減少被攻擊面與限縮影響範圍：

基於Entity的屬性、使用者行為、裝置的安全程度、要求的內容與環境相關的風險來進行資源存取
ZTA只對經過驗證與授權的使用者呈現資源的可見度

根據上圖一的ZTA架構，當使用者（筆電）送出資源存取要求到PEP，PEP轉發該要求到PDP，PDP會檢查該使用者是否根據Policy被驗證與授權完成。如果完成，PDP會告訴PEP說可以放行該要求。這種Agent或Gateway deployment model（如下圖）意味著存取要求是經過審查的、劃分的應用程式或流程。

不論這種劃分的環境是VM、容器，它們的目標都是一樣的 : 保護在一組可能被入侵的共享資源中運作的應用程式/instance。實體伺服器只會運行一個被認可、被驗證並處於sabdbox中的應用程式。這些被驗證過的應用程式之間或存取其他資源的通訊被PEP所控制。

減少攻擊者橫向移動的能力

ZT使用所謂的implementation of segmentation，來限制攻擊者在內部環境進行橫向移動的能力，這同時也減少了攻擊面與可能的影響範圍。

所短偵測到資安事件的時間與圍堵

ZT 以身分(Identity)為核心，提高”存取嘗試和使用者/裝置身分”的可見度，這可以即時偵測到惡意的存取嘗試與其身分進而降低在損害發生前的攻發生。為威脅偵測上ZT也提高了持續驗證的能力程度，早期的威脅偵測可以防止攻擊者成功的發起攻擊嘗試。

增加資源存取的可信度

ZTA 整合了 IAM(Identity access management) 和策略解決方案為 SSO(Single sign on) 的Identity/Support提供單一事實來源(single source of truth)。使用者身份驗證集中化，身份驗證是強大的、動態的，並且在允許存取之前嚴格執行，這些驗證可以依靠MFA、session timeout、再驗證要求與validation來支援。

同樣適用於堆疊(Stack)中的任何層，並具有基於角色/背景脈絡/屬性的細緻度存取/權限。ZT的資源存取也是回歸最基本的資安原則：leasr privilege與need to know。資料的存取也是在加密(基於資料敏感度)的保護之下，不論該資料處於何種狀態(at rest/in motion/ processed)。

依據上述的這些，我們可以歸因能增加存取信任度的原因有：

細緻化的存取與權限，而且給予存取是基於背景脈絡
在進入網路/資源之前對使用者/裝置進行驗證
強制最小特權的規則
統合一些強大的驗證方式，例如MFA
中心化的存取控制
針對各項資源做持續性的身分驗證與授權
強化資料保護

有些ZTA會採用SPA(Single Packet Authorization)來強化其存取可信度。SPA使用次世代Passive authentication技術，這是用特殊的加密封包來取代傳統的 service listeners與open ports的方式。流程如下：

第一個由client送出的SPA封包會被reject
SPA服務會辨識在SPA封包中的＂IP stack與attempts＂來進行驗證
如果驗證成功，伺服器建立明確政策以向請求端點(也就是client)露出服務。例如會開啟防火牆的某個port並開始建立安全且加密的連線。
PEP 透過與 PDP 通信，支援對請求存取的使用者身分強制執行 IAM 最小權限政策
建立mTLS session進行資料傳輸
在整個流程與其背景脈絡中，裝置被驗證認可開始進行業務作業
定期/不定期的驗證（手動或自動）可以是IAM policy中的一部分

強化可見度與分析能力

ZTA是靠著能分析＂日誌/監控/告警＂能力來強化使用者的活動：他做了甚麼，甚麼時候做的。任何嘗試存取特殊的資源與使用管理者帳號的活動都應該被記錄、監控與回報，不論該存取是成功或失敗的。

而可見度與分析能力也能強化異常偵測：用於偵測入站和出站流量中的可疑模式。有了異常事件後，不同程度的自動化及其流程都可以為我們提供更快速與順暢的回應/修復流程。

總結ZTA的可見性與分析能力，能為我們帶來的效益有：

細緻化的日誌與監控讓我們最大化可見度
對使用者實體行為進行監控分析，進而進行使用者實體行為分析
網路隔離與Micro-segmentation讓我們能快速偵測與修正錯誤
持續監控所有攻擊面
資料外洩的最小化
持續評估裝置的安全態勢

根據CSA(雲端安全聯盟)的SDP(軟體定義邊界)，不論是麼東西發出存取要求，IAM policy都會被強制執行。不論成功或失敗所有在存取路徑上的組件其存取都會被記錄，這進而增加了可見性與分析能力。

裝置的安全態勢評估會在mTLS sessions的發生期間進行。隨時時間的推移，我們可以在這些行為中偵測到資安事件是否發生或有異常的行為。而這麼多的事件就需要有一些正確的自動化流程來協助我們。

ZTA的第三項要求是使組職能夠觀察到所有網路流量：

紀錄網路封包（例如OSI L3）檢查裡面的Data Plane
過濾connection metadata(如destination/time/device identity)來動態的調整policy並通知PE，好進行存取要求的評估

由於歷史的使用者行為與現行的使用者行為會持續不斷的被進行比較，可能是外部的基準分析或違反內部活動的歷史基準。分析結果會被打上一個分數，如果分數低於我們設定的閥值，該存取就會被拒絕。

如果不是惡意攻擊者，他們就需要被通知分數低於規定值所以拒絕存取。然而如果是惡意攻擊者，我們需要視他們想要做甚麼樣的行動/行為與存取甚麼資源來決定怎麼給予不同的處理程序。

強化合規

ZTA使用以下幾種方式來強化組織的合規性。例如要求組織來經常檢視其存取政策，進而確保與IT環境的演變保持一致。而政策對資安治理是其基本要求(將目的/目標轉化為資安規則)，政策也支持組織繼續對股東/利害關係人負責。ZT也要求組織＂嚴格執行/持續監控/經常更新＂控制資源存取的政策。

其他效益

ZT可以幫助組織識別業務流程、資料流、使用者、資料和相關風險。這些見解可以更好地幫助組織降低雲端和容器部署的風險，同時改善治理和合規性。組織還可以更深入地了解使用者和設備，更快地識別威脅，並保持對網路的更全面的控制。架構良好的 ZTA 還可以降低 IT 複雜性，同時支援彈性和縱深防禦。

除了安全優勢之外，ZT 安全框架的優勢還有很多，並且根據企業的組織架構、架構和營運模式而有所不同。利用雲端技術實現 ZT 功能自動化有助於最大限度地降低持續營運成本並減輕人力資源和人員配置的負擔。

ZT模型提供資料、服務、應用程式和基礎架構的統一存取控制。這使得企業能夠使用一種解決方案來應對主要威脅，而不是使用多種工具（例如防火牆、VPN、CASB）。透過統一組織的存取控制，ZT 降低了安全成本，同時提高了效率、可見度、可管理性和使用者體驗。

以下是 ZT 的額外效益：

潛在的成本降低
IT管理設計的簡化
改進的資料保護（主要業務資料和客戶資料）
安全的遠端存取
改進的使用者體驗

ZTA的規劃考量

本節將討論一個成功的ZTA實行有哪些預備作業，在做規畫時的一些通用工具與框架。ZTA是一個基於以下因素的規劃流程：

組織的安全方法的成熟度等級（關於成熟度相關概念，可參閱本部落格關於COBIT的文章）
組織現行的文化/技能/專業程度（這個樣一樣可以參閱COBIT）
現有的舊有技術的數量及其重要性
現行的投資與可用預算
服務架構與資料流複雜度
組織的終極目的與目標

組織的風險管理會構成任何有效網路安全方法的核心，包括：

ZT 的轉換戰術高度依賴相關組織的風險概況(Risk profile)和風險偏好(risk appetite)
ZT的實施範圍可能是組織的全部或部分的數位資產
ZT的轉換將是依循基於風險的分階段方法，多次迭代最終會形成由 ZT 驅動的組織

以下是一個範例圖表，來評估組織目前在ZTA的哪一個程度：

組織性與技術性的規劃

以下為規劃的步驟：

理解需求 — 第一步是從理解組織的高階需求，我們將會需要從一些C-Level們中確認這些問題的答案：

為何採用ZT?
有哪些重要的資產需要被保護？
對組織來說，ZT與組織的任務相關性與重要性那些？
採用與不採用ZTA的機會成本是甚麼？
組織的文化適合 ZT 嗎? 現有差距是多少（如果有）?
ZT的採用與轉換很急嗎？
成功的指標是甚麼？

確認利害關係人 —這在所有的組織的行事或專案中是基本中的基本，ZT也不例外。

所有相關的利害關係人都需要參與到並聽取其意見回饋
要得到C-Level們的支持
跨團隊的溝通與協作
針對未來的規劃有一個找錢的流程

定義現狀 — 內部的一些現有方法與流程的成熟度評估，如：

治理
風險管理
合規
資產管理
IAM
Cybersecurity

我們還需要根據ZTA的七個支柱來與我們現有的流程、程序與解決方案個別的進行分析。這包含了：

資產/資料的分類與庫存清單
驗證與授權（如MFA等）
網路分段
加密與金鑰的管理
SSDLC的管理
CI/CI
監控與分析
transaction flows

設定目標 — 也就是設定未來的狀態，例如：

完整的轉換到ZTA，或是部分環境使用（也就是整個環境中混合使用）
有多少（百分比）資源會被影響到？

當我們設定好了目標，我們需要回答以下問題：

優先順序甚麼？
有甚麼是可以快速得到績效的？
有沒有預先要準備的或是有上游作業的相依性？
有現有的基礎可以開始延續嗎？
C-Level的授權的等級是什麼？
策略是甚麼？
有多少預算？
路線圖是甚麼？

定義使用案例 —
針對一個部門進行案例分析，如財務部或開發部門。

發展協作計畫 — 此類的協作計畫可以仿效軟體開發的敏捷專案計畫方法，該計畫包含的要件有：

有哪些資產會在此計畫中
確定範圍內的原則
定義IAM的方法
確定範圍內的流程
選擇一個服務架構
設計資料流與處理流程
選擇ZT的實行模型
定義政策
技術或解決方案的測試、評估與選擇
實行、佈署、發展、交付
監控ZT的實行
採ˋ用、檢視與優化
擴大範圍並重申範圍

專案實行的風險

組織的任何專案都會有其風險，ZT的專案風險有：

ZTA組件的故障 — 例如PDP或PEP掛掉

實行風險：可能會防礙使用者和受影響的應用程式正確進行身份驗證/操作
衝擊：存取受保護的資產可能會被攻擊成功
減緩方式：需要對系統設計HA或有failover機制

新的評估與檢視規則 —

實行風險：不正確的實行方式，以及可能造成被攻擊成的的錯誤操作
衝擊：由於新的基礎設施只取決於架構，因此對解決方案的錯誤評估可能不符合新基礎設施
減緩方式：一組預先計畫的程序與評估步驟可以建立起一個受過驗證的ZT實行

安全維運 —

實行風險：不正確的實行與過時的流程或文件
衝擊：安全等級會下降，會留下潛在的防禦缺口;回應資安事故將使用到錯誤的程序
減緩方式：應在 ZTA 設計階段的早期對敏感資料和可接受的路線進行全面分析

遠端的API calls —

實行風險：缺乏"API協定的支援，API request的檢查，資料洩漏的監控與API discovery"，例如殭屍或影子 APIs
衝擊：解析 API request的複雜性以及已過期版本的存在
減緩方式：實現對所有相關解析器(Parsers)的支援；提供正確的控制措施來保護 PII 等敏感數據

混和式實施的複雜度 —這會讓環境的複雜度變高，進而需要額外的精力與時間來維護/運作/支援

實行風險：無法預見的資源分配不當可能會顯著增加實施成本和期限
衝擊：ZTA 採用/實施可能會與舊有/非 ZTA 環境共存，因此營運/技術/基礎設施必須支援混合架構
減緩方式：每個環境的SIEM 可能會以不同的方式處理相同網路事件的警報

ZTA與現有網路的整合 — 整合是一項極具挑戰的作業

實行風險：在實行ZTA之前，與舊有系統不相容的問題需要被解決
衝擊：在實行ZTA時，與舊有系統的互操作性(interoperability)極其重要
減緩方式：透過驗證流程使用增量階段進行，如果出包了就快速倒回

部分的ZTA解決方案部署 —

實行風險：只做一部份的ZTA等於沒有做。因為ZTA要求的能力成熟度沒有達到，這會造成ZTA要解決的問題還是存在
衝擊：在ZTA中的弱點對攻擊者來說還是存在，一樣會造成資安問題
減緩方式：驗證ZTA採用策略;讓C-Level們了解，問題依然沒有解決需要持續地進行ZTA

在沒有正確操作的情況下部署部分的 ZTA 解決方案 —

實行風險：已部署的技術、解決方案/資源的企業基準不一致，這些技術、解決方案/資源的惡化或消耗沒有達到我們想要的結果
衝擊：這些風險使組織面臨惡意威脅，導致組織面臨更高的技術和聲譽風險
減緩方式：確保ZTA採用策略是涵蓋必要的短、中長期的成本與組織重組進而支援與維護ZTA

ZTA的實作範例

所有的ZTA實行方法都是定義於NIST SP 800–207，本節將講述在真實世界中的實行方法與其主要特徵。這些提到的選項聚焦於網路架構領域，我們將介紹以下三種實行方法:

CSA的SDP
ZTNA
Goolge的beyond Corp

NIST的零信任方法中ZTA會使用到建構區塊有:

Enhanced Identity Governance
Micro-Segmentation
Network Infra &SDP(Software Defined Perimeters)

但如同本文之前所述，這一些實行的建構區塊與組件都會受到將要實行ZTA組織的業務流程、需求、文化等影響我們架構長成甚麼樣子。

CSA SDP(軟體定義邊界)

CSA SDP是完全符合ZT原則的，並且提供一種On-demand，動態地啟用air-gapped networks。信任的網路會與不被信任的網路隔絕以減緩網路攻擊。

SDP實現了以下所有ZT概念的要求:

在授權存取資源之前，不管甚麼東西要存取都要先經過驗證(verification)
在整個連線期間，會持續評估該session與其風險程度
定義在護城河網路模式下的舊的網路攻擊方法的變異體
因為不斷擴大、日益複雜的攻擊面來改善業務安全態勢
監控資產的"完整性與安全性"態勢
運用預設是drop-all gateway，直到使用者/裝置是經過驗證與授權才能存取gateway背後的資產
連線(Connection)的預先檢視可以完全控制連線的條件/參數

CSA的SDP建立連線的過程如下:

SDP client(安裝agent軟體的)在Initiating SDP Host(後面簡稱IH)開啟連線到SDP
IH裝置(有裝SDP client software agent的)是面對使用者的(可能是筆電或其他伺服器)，整個SDP的運作可以不用全部都在組織的內部網路
Accepting Gateway會接收來自IH的連線並且提供是受SDP保護的服務(前提是使用者/裝置都已經過驗證)，並且該裝置通常會是在組織的網路之下
Gateway會開始監控/紀錄/回報這整個session的狀況

在此同時IH跟Accepting Gateway都會跟SDP controller進行溝通，Controller與這兩個裝置溝通的內容是

使用者是經過驗證與授權的
裝置是經過驗證的
受保護的通訊通道
資料/管理這兩種流量通道是分離的

SDP提供了6種佈署模式:

Client to Gateway
Client to Server
Server to Server
Client to Server to Client
Client to Gateway to Client
Gateway to Gateway

整個SDP的運作都服膺於ZT的原則之下:

IH與使用者都要先經過Controller(也就是PDP)的驗證成功後才可以連接到Gateway
SDP gateway會對IH套用 drop-all policy直到IH驗證成功，所以在SDP gateway背後的所有服務都在這一個policy的保護下
SDP controller/gateway是一個存取/通訊的檢查點 — 並提供一個持續監控/紀錄/回報的能力

而這些SDP的組件佈署選項可以是:

Controller可以在地端或雲端
Gateway可以佈署在Server上，或是一台獨立的設備
SDP背後的服務可以是很多個

最佳實踐

由於它們會有單點故障問題Controller應該HA的設計，以抵禦 DoS/DDoS 攻擊和其他類似的惡意活動。使用具有負載平衡功能的多個實體伺服器實例（例如網域名稱系統負載平衡）等 HA 策略。
如果發生故障或過載，Gateway可以block服務。可以使用不同的負載平衡模式（例如，Controller可以充當Gateway的負載平衡器）。Gateway是有狀態的 SDP 實體，可以維護 mTLS session，因此切換到不同的Gateway可能會中斷tunnel上的session。
SDP Controller可以使用internal user-to-service mapping或與第三方服務的連線（例如 LDAP、目錄服務）。授權通常基於使用者角色和更細緻度的資訊、使用者或裝置屬性、甚至使用者被授權存取的特定資料元素/資料流。實際上，SDP Controller維護的存取政策可以由其他組織結構（例如企業服務目錄和身分識別儲存）來維護。根據 NIST，Controller執行的動態 ZT 政策被歸類為 ZT 原則。

ZTNA

SDP 的特徵是使用 SPA(Single Packet Authorization)，但 ZTNA 的前提與 SDP 非常相似。在一些文獻中，ZTNA 起源於 SDP。不管是使用者或應用程式都在城牆後面被保護，所以這讓使用者不論何時/何地/任何裝置都可以去存取服務。ZTNA有兩個不同的架構所組成: endpoint-initiated ZTNA與service-initiated ZTNA。

Endpoint-initiated ZTNA
此一架構與原始版本的SDP規範非常類似，會有一個lightweight agent安裝在終端裝置上，並且能與controller溝通。Controller會去驗證使用者，驗證成功後會開啟一個連線通道到這個使用者經過授權的應用程式中。不過這一個架構的困難在於，終端裝置一定要安裝agent，不然就沒辦法受到管理進而可以使用服務。下圖為整個連線順序。

Service-initiated ZTNA
此一架構用的是Broker機制，作為使用者與應用程式之間的橋樑。Lightweight ZTNA connector(可以在地端或雲端)會位於服務的前端，Connector會從服務要往外的網路流量建立連線到Broker。基於驗證機制，網路流量將會經過Broker。這一種架構適用BYOD的使用者或是給廠商與供應商的系統存取。連線流程如下圖所示。

ZTNA服膺於ZT的原則有:

假設一個有惡意使用者的存取環境
假設資安事故已經發生
每個存取到服務的動作都需要驗證(never trust, always verify)
因為Broker機制讓服務藏起來，進而減少攻擊面
只有經過驗證的使用者可以存取

綜合以上的ZTNA說明，我們可以得出以下ZTNA的一些特徵:

在使用者體驗、敏捷性、適應性和簡化的策略管理都有其效益
如果是雲端的ZTNA，它還可以有可擴充性跟易於採用
ZNTA可以取代傳統的VPN
Endpoint-initiated ZTNA的架構對於沒裝agent的無法管理
無法阻絕攻擊者已經存在於服務中
ZTNA的安全強化可以使用SASE搭配(關於SASE的介紹請參閱本部落格的文章介紹)
ZTNA 中沒有規定根據建立的持續檢查來撤銷session
對於程式存取來說，政策管理度要複雜幾個量級
ZTNA大多適用於使用者存取與取代VPN

Google BeyodCorp

這主要是設計給大型企業的員工來存取內部系統用的。所以大部分組件都是 we proxy/checkpoint來控制所有的內部資源存取，意思就是: 如果是走client-to-server(如ERP)協定，BeyondCorp就沒搞頭了。

任何存取受保護的資源都要透過Proxy，而裝置/使用者的檢查資料來源是基於device inventory與user databases。802.1用於在經驗證過的受控裝置與micro-segmenation。

另外對於內部系統存取，Access control engine提供了授權。也會在整個運作的pipeline加上一些額外資訊來判斷(如地點、裝置信任度)。

BeyondCorp服膺於ZT的原則如下:

裝置/使用者必須被Access Proxy來驗證與授權
對於未經驗證與授權的實體Access proxy拒絕任何存取請求
每個存取請求由Access Proxy使用最小權限原則個別處理
所有的存取嘗試與通訊當會使用Access Proxy當作檢查點; 因此，它會對其進行持續監控，記錄和報告所有網路通訊，包括合法和非法的存取嘗試。

但由於這是Google專有的ZTA架構，所以有一些特徵如下:

不需要裝agent在裝置上(但需要在瀏覽器安裝plugin)
憑證應該儲存在TPM中
彈性較小
很難與現有的IAM跟其他系統整合
缺乏強大的加密控制
對於未經驗證/授權的實體很難隱藏其基礎架構
Access proxy需要同時處理 control/data plane的流量

ZT的使用案例

在本節中，我們將討論各種 ZT 使用案例以及它們的變化 — 無論是在架構上還是在風險緩解功效和限制/依賴性方面。在許多產業中都可以找到無數的 ZT使用案例。以下我們將介紹一些常見案例，並按以下要點細分：

案例描述
安全風險
風險緩解
限制和依賴性

遠端存取與VPN的代替

企業過去一直透過 VPN（即加密通道）為員工提供對公司網路的安全遠端存取。隨著雲端服務的廣泛使用，員工現在需要對駐留在一個或多個雲端和相關環境（例如，VPC 或VNet）中的服務進行額外的遠端存取。過去，安全遠端存取僅限於組織的地端機房。如今，組織還必須為員工提供不再託管於組織的地端機房內的應用程式和服務的存取權限。

傳統 VPN 保護終止於組織的網路邊界，使遠端使用者無論身在何處都可以存取組織的資源。 IT資源上雲導致VPN效能大幅下降。為了解決這個問題並實現對遠端服務的最佳存取，組織正在使用雲端代理和 SASE 等新技術創建到外部飛地(也就是不在組織的網路邊界內)的加密通道。這使得員工、廠商和合作夥伴能夠安全地存取內部服務/應用程式以及其他公有雲的 IaaS/PaaS/SaaS 產品。 ZTA 透過在遠端設備/使用者與飛地之間的通訊中包含 SDP 功能（即 SPA）來增強遠端存取程序的安全態勢。

安全風險
在大多數 VPN 解決方案中，使用者可以透過 VPN 閘道進入組織網路；一旦經過身份驗證並被授予存取權限，使用者就可以存取組織資產。此外，應在存取之前進行裝置身份驗證，以驗證裝置沒有惡意軟體。例如，如果遠端員工的裝置感染了惡意軟體，則該惡意軟體可能會影響該使用者進入網路後可存取的所有組織資產。

風險緩解
ZTA 透過更精細的且基於背景脈絡的安全控制有效地避免 VPN 的許多固有安全漏洞。例如，傳統 VPN 實現的所有用戶流量在到達雲端應用程式之前都會經過 VPN gateway，造成高延遲以及單點故障/或被攻擊。此外，相同的政策和安全控制適用於所有使用者，無論應用程式和用戶位置如何。

相較之下，ZTA的每項服務都由ZT gateway單獨保護；每個用戶端首先連接到Controller，只有在身份驗證和授權之後，它們才能透過Gateway與mTLS 連接到應用程式。每個應用程式還可以應用不同的政策和安全控制。

使用 VPN，使用者（尤其是行動用戶）經常會遇到網路延遲、常斷線和連線問題。即使使用split tunneling，使用者與網路的連線也會受到影響。 split tunneling是一種 VPN 功能，可分割網路流量並透過加密的 VPN 通道發送其中一些網路流量。

限制和依賴性
ZT 環境靈活且能夠適應變化，因為 ZT 模型是基於經過驗證的標準，包括 mTLS、SAML 和 X.509 憑證等。由於其可擴展性，它可以與資料加密和遠端認證系統等安全系統相結合。將演進的加密隧道與ZTA耦合提供了演進的路徑。

Micro-segmentation(微分段)

ZT 強制隔離網路上裝置之間的連線。透過要求對設備到設備的連接進行更細緻、基於政策的存取，組織可以防止網路流量的可見性 — — 甚至對內部使用者也是如此。這是透過在應用程式周圍創建動態、可信任的網路區域來實現的，從而有效地將它們隱藏起來，防止未經授權的使用者和裝置發現。在典型的微分段網路上，網路上伺服器或裝置之間的每個連線都將透過單獨的身份驗證和資料流量層進行引導。每個設備都必須啟動自己的加密通道才能與伺服器通訊。因此，每個連線都是其他主機無法穿透的獨立網路。微分段有助於確保設備存取僅限於經過驗證的授權實體，並且可以非常有效地防止網路攻擊(橫向移動)在整個環境中傳播，從而限制對相關受感染設備的影響。微分段架構可以部署在雲端環境和地端機房。

隨著時間的推移，基於時間的分段政策和控制通常會變得更加精細。事實上，控制的細緻度和系統技術堆疊的壽命之間存在直接關聯。出現的一些較常見的微分段架構模式包括：

傳統網路分段
資料中心（即東西向）分段
應用程式微分段
工作負載微分段

安全風險
一旦駭客在網路中站穩腳跟，他們通常會橫向移動，試圖攻擊網路上的其他機器。網路可見性通常不限於 VPN 和企業 IT 環境中的特權使用者/裝置。設備本身也容易受到攻擊，因為其中一些 IT 資產可能可以從網路上觀察到。

風險緩解
ZT 實作不會預設地信任網路上的任何裝置或應用程式。只有受信任的設備才能在基於 SPA 的請求之後發起連接，然後透過加密通道發起連接。 IT 環境的安全狀況得到了增強，因為設備/服務對未知使用者完全隱藏，使用者是受控且封裝在裝置之間的通道內。

限制與依賴性
由於對使用者和裝置及其各自對每個應用程式或資源的存取保持嚴格的控制，因此設備之間的架構和互動需要仔細整合，以減少與使用者/裝置驗證相關的延遲。此外，儘管在授予連接之前連接裝置的安全狀況和身份已得到驗證，但設備之間流動的資料並未經過驗證。

SaaS

雲端的SaaS 部署模型的興起使組織能夠存取前所未有的一系列可擴展 IT 資源。這可以推動創新並提高生產力，但也帶來了傳統企業防火牆以外的新 IT 安全挑戰。每個正在使用的 SaaS 解決方案都帶來了與廠商風險管理、資料保護、存取控制、使用者體驗、稽核、監控、特權存取管理等相關的眾多挑戰。

安全風險
在SaaS共享責任模型中，存在"可見性、治理和控制"都降低的面向，導致各種安全風險；因此需要"理解、監控和報告" SaaS 解決方案以接受風險。例如，資料保護合規措施適用於 SaaS 供應商，這使得風險接受度對於實施過程至關重要，除非添加額外的控制措施來緩解風險。業務部門在 IT 不知情或未經 IT 許可的情況下選擇採購和使用 SaaS 應用程式。這種現像也稱為影子IT，顯著增加了資料外洩和安全事件的風險。因此， IT 應在其服務等級協議/合約中指定對符合性報告標準的控制要求。

由於行動員工的興起和雲端應用程式的激增，以網路為中心的安全架構不再被認為是足夠的保護。一旦使用各種漏洞和攻擊方法（例如網路釣魚、惡意軟體或洩漏的密碼）突破安全邊界，駭客就可以在其他安全層和系統之間自由移動以搜尋易受攻擊的資料。

微服務和第三方 API 在過去幾年間得到了大量應用，使 SaaS 產品能夠透過公開支援的 API 與現有系統整合。組織可以簡單地訂閱這些服務，而不是從頭開始建立它們；然而，這給生態系統帶來了供應鏈風險。

風險緩解
採用ZT SaaS管理模式是緩解SaaS服務固有的網路風險的有效方法。這包括在 SaaS 應用程式中實施基於政策的存取控制（無論使用者/裝置位置如何），以及監控所有 SaaS 使用模式。

在許多情況下，組織透過單一登入安全性（例如SAML）和CASB 的基於IP 的存取控制來增強SaaS 應用程式的安全性，但這可能會對使用者體驗產生負面影響，導致延遲增加和效能下降。 ZT模型為SaaS應用程式增加了更強的安全性，而不影響使用者的體驗。

限制與依賴性
ZT SaaS控制措施依賴SaaS機制來控制組織帳號存取。這包括對 SaaS 服務的client SSO 存取清單的支援 — 有效地停用對 SaaS 服務的直接存取（即繞過 SSO 存取機制）。 ZT 和 SDP 控制 SaaS instance內部或不同 SaaS 應用程式之間的資料流的能力有限。

混合雲與多雲

混合雲將地端解決方案(或私有雲)與一個或多個公有雲服務結合，並透過site-to-site VPN 和專線等技術實現每個不同服務之間的連接。許多組織也採用多雲策略；為此，組織可以使用公有雲、混合雲或私有雲作為其整體雲端採用策略的一部分。

安全風險
使用多雲、混合雲或其組合會擴大組織的被攻擊面。不同的公有雲在VPC 之間或 VPC 與私有雲之間使用不同的 IAM 模型、安全控制和連線方法。

混合和多雲部署固有的廣泛網路存取等級與 ZT 的最小權限存取模型相衝突。例如，CSP可能會預設採用最開放的存取等級以保持互通性- 在site-to-site VPN 的情況下，必須為任何網路存取配置私有雲和公有雲之間的連接，以便任一網路上的裝置都可以使用私有雲和公有雲之間的連線。

風險緩解
如果將ZT套用於組織的所有雲端部署，ZT 可以減緩公有雲服務固有的安全風險。以下是跨不同CSP和私有雲存取組織資源的指導原則：

特定網路上的裝置/使用者連線點不該決定哪些雲端服務可存取。
在最初連接之前以及任何後續連接到雲端資源之前，應對使用者進行身份識別、驗證和授權。
對服務和資源的存取權限是根據組織對使用者/裝置的理解而授予的，無論他們連接到哪個雲端服務。
私有雲和公有雲應用相同的安全控制（例如通道和加密）。

ZTA 透過隱藏所有服務和資源（無論其位置如何）來滿足這些要求。在完成身份驗證和授權之前，使用者無法存取這些資源。

ZTA 針對每項服務強制在使用者裝置和 PEP 之間使用相互加密的通道。實施最小權限存取模型是因為存取政策是有細緻度的並且基於資源/服務，而不是基於網路、雲端或 VPC。

限制與依賴性
ZT 透過其分散式架構改善了使用者體驗，消除了可能造成延遲並導致單點故障。然而，由於各家CSP的設計模式各不相同，真正與雲端和供應商無關的 ZT 實施可能很難實施。例如，Azure AD 的 SSO 實作與 Azure 雲端不同；同樣，GCP 也不同於基於 OpenStack 的私有雲。

最後，多雲部署和混合到公有雲之間的互連取決於供應商。可以遵循最佳實踐，但沒有一種標準協議或實現，因此不容易設計和實現。

OT(Operational Technology)

OT 主要存在於工業環境中，其中的流程經過仔細監管和管理以實現預期結果。與 OT 環境相關的系統是工業控制系統 (ICS) 和 IIoT 設備。

傳統上，OT 環境由封閉的、物理隔離的網路和系統組成。然而，較新的 OT 解決方案為越來越多的產業別提供了與連接和自動化相關的高階功能（例如智慧型 OT 設備）。對 OT 產生的資料和功能的依賴正在迅速增加，要求採用這些新技術的組織規劃可存取、安全且有彈性的部署。

將智慧型 OT 裝置暴露於網際網路或外部網路可能會將網路威脅引入組織網路和環境。因此，ZT 安全最佳實踐要求每個連接的實體都有一個身份，並且必須被視為 ZT 框架（使用者、裝置、虛擬基礎架構和雲端資產）不可分割的一部分。以下部分介紹了與 ICS 和 IIoT 相關的幾個案例。

CPS, IoT, IIoT, ICS

根據 NIST SP 1500–201，CPS(cyber-physical systems) 是實體元件、網路系統、嵌入式電腦和軟體的整合，這些元件連結在一起以進行資訊共享，形成一個完整的系統。 CPS 是未來智慧服務、智慧城市、智慧醫療保健管理等的基礎。顧名思義，CPS 本質上是跨學科的，並提供網路和物理系統的無縫整合。

物聯網由配備軟體和(或)感測器的設備（即物件）網路組成，透過 WiFi 或其他無線/有線技術連接到互聯網。物聯網設備的範圍包括家庭設備
（例如，家庭自動化解決方案、智慧門鈴）到工業設備（例如，智慧農業設備、組裝線機器人）。 IIoT 是 IoT 的子集，專門指工業應用。 IIoT 系統使工業企業能夠透過自動化、持續監控和分析來提高效率和生產力。

工控系統 (ICS) 涵蓋工業生產中使用的多種類型的控制系統，包括：

SCADA(Supervisory control and data acquisition)系統
DCS(Distributed control systems)
PLC(Programmable logic controllers)，常見於工業部門和關鍵基礎設施中

此外，COTS(commercial-off-the-shelf)網路設備越來越多地用於IACS( industrial automation and control systems)。這些 COTS 設備通常價格低廉、高效且高度自動化。

ICS 系統通常由封閉系統組成，其組件以匯流排拓撲連接到系統控制器。然而，組織越來越需要內部 IT 網路和 ICS 系統之間的連接，這項要求將網路物理風險導入環境中，因為 ICS 系統可能支援電力、照明、空調和水管理的關鍵設施流程。因此，組織應利用 ZT、SDP 和 SPA 來減輕因將 ICS 與組織的 TCP/IP 網路整合而產生的網路風險。

安全風險
由於 IIoT 和 ICS 屬於工業或網路物理系統領域，因此機密性、完整性和可用性（即 CIA Triad）原則的優先順序與傳統 IT 系統不同。相反地，可用性和完整性優先於機密性，以便首先保護人類生命和有形資產（例如電網）。不幸的是，這種保密性的缺乏導致了各種引人注目的事件，其中國家等級支持的駭客成功地破壞了工業和網路物理系統，造成了重大的物理損害。

由於 ICS 廣泛部署在水、電、石油/天然氣和能源等關鍵基礎設施環境中，對這些系統的威脅可能會造成重大傷害和傷亡。隨後，恐怖分子、國家等級支持的駭客、一般駭客和犯罪分子等惡意行為者對 ICS 相關的漏洞和利用產生了濃厚的興趣。更複雜的是，由於這些即時系統的重要性和高可用性的要求，很難在這些即時系統上進行安全加固和修補。

ICS 網路攻擊通常屬於以下類別之一：

將惡意軟體植入到裝置中以攻擊網路上相鄰的資源
控制 OT 設備以竊取資料或執行未經授權的操作

2019 年揭露了 400 多個 ICS 漏洞，其中超過四分之一是由於未修補的系統造成的。根據美國電腦緊急準備小組 (US-Cert) 和國家安全局 (NSA) 的說法，最常見的 OT 威脅向量和漏洞包括以下內容：

在轉向 OT 網路之前，利用魚叉式網路釣魚在組織的 IT 網路中獲得立足點
部署商品勒索軟體來加密資料並對 IT 和 OT 網路產生不良影響
連接到可公開存取的 PLC，初始化來存取無需身份驗證
利用常用連接埠和標準應用層協定的弱點與控制器通訊並下載修改後的控制邏輯
使用供應商提供的工程軟體和程式下載來損害系統
修改PLC 上的控制邏輯和參數

風險緩解
ZT 允許組織在Control plane和Data plane上實施更強的 IIoT 設備完整性和資料機密性，同時確保 IIoT 設備對整個系統操作的可用性。此外，由於 IIoT 設備被視為 ICS 生態系統的一部分，因此可以利用 ZT 模型透過微分段安全地隔離 IT 和 OT，從而有效地將Data plane上的業務應用程式與Control plane上的業務應用程式隔離。

如果按照 ZTA 規範進行部署和管理，以下 OT 設備類型將受益於顯著降低的網路風險：

IIoT：
使用SPA 的SDP 透過強制執行IIoT 裝置驗證和基於風險的使用者身分驗證（例如，針對特權操作的MFA），降低了未經授權的使用者存取和惡意IIoT 裝置（例如，具有hard code憑證的風險裝置）。由於 IIoT 端點主要基於 IP，具有一個或多個網路接口，因此與 SIEM/SOAR 結合使用的標準監控解決方案可用於觸發警報和防禦措施。
ICS：
透過將 ICS 組件（例如 SCADA、人機介面 [HMI]、DCS）納入具有 SPA 的 SDP，組織可以限制高度脆弱的使用者對這些系統的存取。更具體地說，消除hard code憑證的不良做法，以強制執行基於風險的使用者身份驗證。此外，具有 SDP 和 SPA 的 ZTA 提供了一種機制來實現 ICS 元件的control plane與Data plane的微分段，以減輕由於業務應用程式互連而帶來的風險。

限制與依賴性
在 OT 背景脈絡下，ZT 的限制主要源自於設備資源限制以及 ICS 系統在網路實體介面層級使用傳統和(或)非 IP 通訊協定。例如，用於公用事業應用的 IIoT 設備可以在一個介面上使用 ZigBee/IEEE 802.15.4 協定與智慧電錶進行通訊，而智慧電錶則可以使用 IP 協定與公用事業管理系統進行通訊。此外，ICS 系統（例如 SCADA、PLC）依賴 ModBus 或 Profinet 等 OT 協定來實現Control plane功能。在這些場景中，在Control plane的邊緣套用到 ZT 德下游可能具有挑戰性。

由於感測器和 IIoT 控制器與 SDP 通訊/驗證的能力通常受到限制，因此架構師需要在 ZTA 設計階段考慮這些限制。最終，可能需要採用Agentless微分段或基於外部proxy的方法，因為基於Agent的 ZTA 可能無法與 OT 和 IIoT 設備配合使用。

此外，由於 OT 和 IIoT 設備更難修補和(或)升級，因此基於網路的微分段對於保護相鄰系統免受潛在易受攻擊的設備的影響至關重要。此外，可以實施持續的流量掃描和深度封包檢查來偵測和阻止已知的攻擊類型，即使它們來自受信任的實體。

5G

5G無線技術代表了通訊網路的重大轉變，為智慧城市、自動駕駛汽車、遠距醫療等應用提供了新的功能和連接。借助 5G，數十億設備、感測器和系統將能夠根據時間敏感性、延遲和處理要求自動連接到網路。除了更快的速度、更大的容量和更少的延遲之外，5G 還將提供eMBB(improved mobile broadband)、mMTC(massive machine-type communications)和uRLLC(ultra-reliable low-latency communications)。

除了大型基地台之外，5G 還使用小型蜂巢式基地台在低、中、高頻段運作。在人口稠密的地區，小型蜂巢式基地台充當訊號中繼器，從而提高速度、網路容量和可靠性。核心網路（全球通訊基礎設施的骨幹）路由資料並連接存取網路的不同部分。更多的5G介紹請參閱本部落格"5G網路的技術架構與協定 — Part1"一文。

安全風險
5G 支援多項突破性技術，尤其是行動邊緣運算 (MEC)，這些技術可顯著提高應用程式效能並實現前所未有的即時資料處理量。邊緣運算將運算和儲存資源放置在更靠近客戶和(或)電信網路基礎設施內的位置。這消除了與網路回程延遲相關的效能問題（即必須不斷地來回傳輸到資料中心）。

不幸的是，這些支援 5G 的新配置也為環境帶來了新的安全風險；從使用者裝置到無線存取網路，從行動邊緣運算到核心節點，5G的開放架構帶來了廣闊的攻擊面。此外，5G 網路利用軟體定義網路 (SDN) 技術；如果沒有適當的保護，SDN 資產可能會受到駭客的攻擊，而駭客可以重新配置網路設備、監控所有通訊並更改應用程式資料。

此外，由於 5G 使網路設備、儲存、運算硬體和其他 IT 基礎設施更接近終端使用者，因此實體安全對於增強邏輯層上的 ZTA 安全性更加重要。值得注意的是，這個風險因素以及許多其他風險因素在 4G 基礎設施中也很常見，因為在遠端位置運行的現有電信設備通常缺乏強大的實體安全措施來阻止攻擊。

風險減緩
如前所述，5G 網路從無線存取網路到核心節點和行動邊緣運算節點都是軟體定義的，因此特別容易受到橫向移動惡意軟體的攻擊。 ZT設備保護可用於驗證系統中軟體下載和更新的真實性，以及對日誌檔案的存取。

由於 5G 網路支援內部運算和外部雲端資源，因此它們也容易受到 MITM 攻擊。 ZT 的安全模型可確保從 5G 使用者裝置到行動邊緣運算或雲端的安全連線。最後，ZT資料保護可以部署在物聯網到5G Gateway上，以確保只有經過身份驗證和授權的系統才能存取受保護的資料。

限制與依賴性
整合 ZT 需要存取 5G 基礎設施設備中的網路驅動程序，這在某些廠商的方案中可能很難取得。此外，ZT 的身份和授權概念可能很難在具有Generic software process names（例如儲存或保存）的裝置中實現。未來的 ZTA 版本將需要支援Agentless方法，以促進 5G 實現的無數邊緣配置，因為並非所有邊緣設備都可以支援Agent軟體安裝。