由於邁向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內容
熱門新聞
2024-12-03
2024-11-20
2024-11-29
2024-11-15