【ZTA 101】NIST SP 800-207第七章：邁向零信任架構

由於邁向ZTA並非一蹴可幾，因此NIST在這份標準文件的最後一章（第七章），提供了導入零信任架構（ZTA）的建議步驟，讓企業不只對於ZTA有所認識，在實際行動的大方向上，也有可循序漸進的步驟能依循。

第七章 邁向零信任架構

在第一章時，NIST已經指出，朝向ZTA過渡會是一段漫長過程，並不是全面的技術更換，在既有的企業IT基礎架構中，其實已有ZTA的元素存在，而在第七章的開頭，NIST再次強調這件事，指出導入ZTA是一段旅程，而不是大規模更換基礎設備或流程。

對於零信任原則的實施、流程的變化，以及保護高價值資料資產技術解決方案的採用，企業組織需要尋求一個漸進的方式。

基本上，多數企業的網路安全策略，會以零信任與傳統邊界防護混合的模式進行，並持續很長一段間，這期間內將會持續投資於IT基礎架構現代化。換言之，制定IT現代化的計畫，將包含基於零信任原則的架構，這將有務於企業為小規模的工程流程擬定日後發展藍圖。

當然，每家企業導入零信任的策略，均要取決於當前的網路安全運作與現況。

NIST指出，企業應該要在布署零信任環境之前，就能達到一個基本的安全水準。而這個基本安全水準的面向，將包含資產、主體、業務流程與流量，以及對應的識別與分類，也就是對於這些資訊要有詳細的了解。這是因為，企業需要這些資訊，才能有助於後面工作的進行。

第七章第一節 純粹的零信任架構

若以一個全新的環境而言，企業可以從頭開始構建零信任架構。

因此，這裡需要假設企業知道，運作中會有哪些應用程式、服務與工作流程，因此可以為這些工程流程，建立一個基於零信任原則的架構。

一旦確定了工作流程，企業就可以縮小所需元件的範圍，並開始描繪每個元件的互動關係。

從這一刻開始，建立架構與設定配置元件將是企業一大工程，同時可能也要關注額外的組織性變動，具體還是取決於企業運作與配置的現況。

當然，對於普遍企業組織來說，這很少是可行的選項，畢竟已經擁有既有網路環境。不過，一旦要建立新的應用程式、服務或資料庫時，是可以在某種程度上，引入零信任的概念。

第七章第二節　混合零信任架構與傳統邊界防護的架構

基本上，對於普遍企業而言，零信任與傳統企業邊界防護架構共存的情形，可能會需要一段時間，在NIST的建議中，導入零信任的方法上，企業可以每次只針對一個業務流程的方式去進行。

但同時，企業需要確認是否有足夠且靈活的共同元素，例如身分識別管理、裝置管理與事件日誌記錄等，以支撐混合式安全架構的運行。對於徵選的ZTA解決方案，企業架構師也可能希望是，限制為可以與現有元件介面連接的解決方案。

要讓既有業務流程邁向到ZTA，可能有些部分需要重新設計，相對地，企業也可趁著這樣的機會，遵循SP800-160v1的系統安全工程的內容去實踐。

第七章第三節　介紹從邊界網路架構邁向零信任架構的步驟

基本上，本章節是最關鍵的部分，這裡提供了導入ZTA的步驟建議，讓企業對於ZTA的導入更有方法。

前面多少都有提到，邁向ZTA的過程中，企業組織需要詳細瞭解自身在實體與虛擬的資產，以及包含用戶權限的主體，還有業務流程。

因為這些知識內容，將是策略引擎（PE）在評估資源請求存取時所需，一旦這些知識內容不完整，將會導致業務流程失敗，也就是PE因為資訊不足的原因，而拒絕存取請求。

換言之，企業組織如果不了解當前的業務運作狀況，當然也就無法確定需要採用哪些新流程或系統。因此，企業應在努力將ZTA引入企業之前，對於資產、主體、資料流與工作流程進行調查。

NIST表示，這些相關的調查，都與組織業務流程的檢查有關，其實是可以同時進行的。同時這裡還特別強調一點，這些步驟是可與NIST風險管理框架（RMF）的SP 800-37相對應的，這是因為，採用ZTA的任何過程，就是要降低組織業務功能風險的過程。

還要注意的是，在初始的盤點清單建立後，需要定期維護與更新，並要注意更新之際，可能更改業務流程也可能不產生影響，但都應該要對業務流程進行評估。

在此，NIST提供了一個視覺化的圖表，讓外界可以瞭解導入ZTA的步驟與路線。

資料來源：NIST，iThome整理，2022年3月

具體而言，NIST提供了7大建議步驟，分別是：（一）識別企業中的角色，（二）識別企業中的資產，（三）識別關鍵流程，並要評估與流程執行相關的風險，（四）針對ZTA候選者制定政策，（五）識別候選的解決方案，（六）初期部署與監控，（七）擴展零信任架構。

　一、識別企業中的角色

為了使零信任企業得以運行，以策略引擎（PE）的角度來看，必須對於企業主體先有所認識。

這裡指的主體，包含了人類，也有可能是非人類實體（Non-person Entities，NPE），好比是與可資源互動的服務帳號。

至於特權帳號使用者，如開發人員或系統管理者，在分配屬性與角色時，需要具有額外的審查。在許多傳統安全架構中，這些帳號可能有用存取所有企業資源的能力，

而在ZTA架構之下，應該允許開發人員與管理者有足夠的靈活性，以滿足他們的業務需求，同時使用日誌和審核機制來標識存取行為模式

此外，關於ZTA的布署上，可要求管理者在NIST SP 800-63A中滿足更高分數或符合更嚴格的標準。

　二、識別企業中的資產

前面章節提到ZTA的關鍵要求之一，是要有能力識別與管理設備，同時ZTA還要求針對非企業擁有的設備，同樣要有能力去識別與監控，因為這些設備可能存在於企業擁有的網路基礎設施上，或是存取企業的資源。簡而言之，布署ZTA的成功關鍵，就是要有能力管理企業資產。

具體而言，這些企業資產包括硬體元件，例如筆記型電腦、手機與IoT裝置，還有數位artifacts，例如使用者帳號、應用程式與數位憑證等。或許我們不可能對所有企業擁有的資產，進行完整的普查與盤點，因此，所以企業或許應考慮建立一套機制，可在企業基礎設施上，將新發現的設備資產，做到快速識別、分類與評估。

需要注意的是，這不僅僅是對企業資產進行簡單的歸類與維護資料庫，還須包括配置管理與監控。

畢竟，觀察資產當前狀態的能力，是評估存取請求過程的一部分。這意味著企業需要企業必須能夠配置、調查與更新企業資產，譬如虛擬資產與容器，以及實體與網路位置，當進行資源存取決策時，這些資訊需要通知到PE。

此外，非企業擁有的資產，以及企業擁有的影子IT，也應該盡可能的納入分類。這方面可能包括企業內可見的任何東西，例如MAC地址、網路位置，並透過管理者的資料輸入加以補充。這些資訊不僅可用於存取決策，也將用於企業的監控與日誌鑑識。

還要注意的是，影子IT會帶來一個特殊的問題，因為這些資源是企業所擁有，但卻不像其他資源那樣被管理。因此也要注意，有些ZTA方法可能會導致影子IT變得不可用。

　三、識別關鍵流程，並要評估與流程執行相關的風險

第三個清查項目，機構應對業務流程、資訊流，以及對於機構任務中的關係，做到識別排序。

基本上，業務流程應通知資源存取請求被批准或拒絕的情況。對於企業而言，建議可從低風險的業務流程開始朝向ZTA邁進，因為一旦業務中斷，還不致於讓對整個組織帶來負面的影響，一旦獲取了足夠的經驗，就可以選擇其他重要的業務流程繼續進行。

同時，利用基於雲端的資源，或是由遠端工作人員使用的業務流程，對於ZTA也是相當不錯的方式，並可能會看到可用性與安全性上的改善。

此外，企業用戶可以直接請求雲端服務，而不是投射企業邊界到雲端，或是將用戶透過VPN帶入企業網路。因為，透過企業的政策落實點（PEP），可確保向用戶授予資源存取權之前已遵循企業政策。

但這裡還強調一點，規畫ZTA的人，還要考慮一些潛在的因素，當實施ZTA時可能會出現的問題，包括效能、使用者體驗，以及可能增加工作流程脆弱性等，需要做出權衡取捨。

　四、識別導入 ZTA 候選程序的政策

在選擇服務或業務工作流程以實施ZTA的過程中，有幾個重要因素必須注意：包括流程對組織的重要性，受影響的群體對象，以及在工作流程中資源使用的當下狀態。

而要評估資產的價值，或是資產與工作流程的相關風險，在NIST的建議中，NIST風險管理框架可為企業帶來幫助，也就是NIST SP 800-37。

在識別了資產與工作流程之後，也就是識別工作流程中所使用或影響的所有上游資源、下游資源與實體。

上游資源：如ID管理系蓊、資料庫、為服務

下游資源：如日誌、資安監控

實體：如主體、服務帳號

這些都會使企業第一次遷徙ZTA時，在選擇上帶來影響。NIST並舉例說明，一部分企業主體使用的應用程式或服務（如採購系統），可能比整個企業群體至關重要的應用程式或服務（如電子郵件）更適合。

接下來，企業管者者需確認要使用的信任演算法（Trust Algorithm），並且調整權重標準，以確保不阻礙資源的存取，並且存取管控政策是有效的。

　五、識別可行的解決方案

當確定了業務流程的清單後，企業架構師將可制定解決方案選擇的清單，這部分NIST指出可從五個關鍵因素去考量

●解決方案是否要求在客戶資產上安全元件？

　在非企業資產使用或需求上，這可能會限制業務流程，像是BYOD或跨機構合作的情境。

●解決方案在業務流程完全存在於企業場所的情況下是否有效？

　因為有一些解決方案預設請求的資源是存放雲端（所謂的南北向資料流），而不是在企業的周邊（東西向資料流），因此業務流程資源的位置，將影響解決方案與ZTA流程的選擇。

●解決方案是否提供了可互動的Log記錄供分析？

　畢竟零信任的關鍵元件，就是要蒐集與使用流程相關的資料，提供給政策引擎以做出存取決策。

●解決方案是否針對不同應用程式、服務與協議提供廣泛支援？

　有些解決方案可能支援廣泛的協議（如網路、SSH等）、協議（IPv4、IPv6），但一些解決方案可能只適用於特定範圍，像是網路或電子郵件。

●解決方案是否需要改變主體的行為？

　有些解決方案可能在執行特定工作流程時需要額外的步驟，這可能會改變企業主體執行工作流程的方式。

總體而言，這一解決方案是先將現有業務流程建立模型，作為試點計畫，而不僅僅是一個替代方案。而這樣的試點方案可以具通用性，也就是能適用與多個業務流程，或是當成特定的使用案例。基本上，在過渡到ZTA部署之前，試點計畫可視為ZTA的驗證場域，之後再脫離傳統的流程基礎架構。

　六、初期部署與監控

在選擇了工作流程與ZTA元件後，就可以開始進入初期部署階段。

一開始企業可能遇到的問題是，希望先以觀察或監控模式來進行。只是很少有企業可以在第一次就能完善，像是重要的帳戶可能在存取資源時被拒絕，或是可能不需要具備某些存取權限。

因此，在新的ZT業務流程之下，可在「僅報告」（Reporting-only）模式下先執行一段時間，以確保政策是有效且可行，並讓企業可以理解其運行。在Reporting-only模式之下，這意謂著對於大多數存取請求給予存取許可，應將日誌與連結的蹤跡，進而比對最初制定的管理政策。

不過，這裡也指出初始部署時，存取政策可以更寬鬆一點，以便收集ZT工作流在實際交互過程下的相關資料，一旦建立工作流程下活動範例的基準，就可以更容易識別異常行為。若無法以更寬鬆的方式運作，企業網路維運人員需要密切監控日誌，並隨時準備依據運作經驗修改存取政策。

　七、擴展零信任架構

在初期實際部署運作之後，完善了工作流的所有政策，企業就進入穩定運行階段。

此時，網路與資產仍然被監控，流量也都被記錄，但回應與政策調整的節奏放慢，持續從各式問題反餽做到改進。接下來，企業管理者可以規畫ZT部署的下一循環，也就是回到上述第四步驟，選定下一個工作流程與解決方案，並進行部署。

同時，也要注意如果工作流程發生變化，需要重新評估運行中的零信任架構。這包括新設備、軟體（特別是零信任邏輯元件）的重大更新，以及組織架構的轉變，都可能導致工作流程與政策產生變化。實際上，應假設有些工作已經完成的情況，重新審視整個流程。

更多ZTA 101內容

１　２　３　４　５　６　７