GitOps已經(jīng)成為軟件開發(fā)領(lǐng)域最受關(guān)注的熱門趨勢之一。由于簡單易用，同時又具備彈性、可預測性和可審計性等方面的優(yōu)勢，這種新的軟件開發(fā)模式正在被廣泛采用。對于安全人員來說，需要關(guān)注的是，GitOps有一個重要特性是它可以簡化安全團隊運維操作，尤其是在復雜的云和容器化環(huán)境下。

　　GitOps對安全事件調(diào)查與取證的影響

　　GitOps是一種新的開發(fā)模式，最早是由 Kubernetes 管理公司 Weaveworks在 2017 年提出，其目的主要在于為云原生應用程序?qū)崿F(xiàn)簡單持續(xù)的部署。

　　我們可以將GitOps理解為“ IaC + Git + CI/CD”，即基于 IaC 的版本化 CI/CD，它的核心是使用 Git 倉庫來管理基礎設施和應用的配置，并且以 Git 倉庫作為基礎設施和應用的單一事實來源，對開發(fā)人員從其他地方修改配置（比如手動修改線上配置等）一概不予通過。

　　GitOps的核心想法是依托一個Git存儲庫，該存儲庫始終含有代表生產(chǎn)環(huán)境預期狀態(tài)的聲明式配置，并通過自動化流程監(jiān)管Git存儲庫，將生產(chǎn)環(huán)境與這個預期狀態(tài)相匹配。當開發(fā)人員要部署新的應用程序或更新現(xiàn)有應用程序，只需更新存儲庫，自動化流程就會處理所有事情。如果集群的實際狀態(tài)與 Git 倉庫中定義的期望狀態(tài)不匹配，Kubernetes reconcilers 會根據(jù)期望狀態(tài)來調(diào)整當前的狀態(tài)，最終使實際狀態(tài)符合期望狀態(tài)。

　　基于GitOps的以上特性，我們可以認為，GitOps能夠提高軟件開發(fā)可靠性，有效防止“配置漂移”等危險情況的發(fā)生，同時簡化復雜容器化環(huán)境的管理難度，提高軟件開發(fā)過程的安全性和可審計性。

　　DevOps團隊早就意識到安全防護在系統(tǒng)開發(fā)流程中的重要性，需要進一步加強與安全團隊的合作，而GitOps正好可以將這種合作提升到新的水平，創(chuàng)建“融入到”開發(fā)流程中的集成式安全能力。

　　01 安全能力左移

　　GitOps可以實現(xiàn)代碼級的安全能力，所有配置和安全策略都是聲明式的，并統(tǒng)一保存在版本控制系統(tǒng)中。這讓所有更改都可以輸入到自動化管道中，以驗證、部署和監(jiān)控它們。

　　GitOps不僅僅是一種管理基礎架構(gòu)的有效方式，它還提供了一種將安全轉(zhuǎn)移的策略，在開發(fā)周期的早期階段記錄預期狀態(tài)的所需更改，比如安全問題、錯誤和漏洞。GitOps可以更加輕松地修復與安全相關(guān)的錯誤，并立即重新部署受影響的環(huán)境或應用程序。

　　02 加快安全事件響應

　　如果組織的業(yè)務系統(tǒng)因為存在漏洞而受到威脅，GitOps可以快速響應以修復安全問題。組織可以回滾到以前的安全配置，或者添加補丁或修復程序以立即部署新版本，從而快速響應事件或漏洞。

　　將基礎架構(gòu)作為代碼來存儲有助于快速識別存儲庫中與漏洞相關(guān)的特定代碼行。它可以幫助調(diào)查人員快速評估事件的規(guī)模、更迅速地恢復，并減小網(wǎng)絡攻擊造成的破壞。

　　GitOps環(huán)境下開展數(shù)字取證的最佳實踐

　　數(shù)字取證和事件響應（DFIR）主要包括恢復和調(diào)查數(shù)字化IT系統(tǒng)上發(fā)現(xiàn)的違法線索和證據(jù)。隨著社會越來越依賴計算機系統(tǒng)和云計算，DFIR已成為網(wǎng)絡安全防護和執(zhí)法管理工作的重要方面，也是確保網(wǎng)絡安全的關(guān)鍵操作程序。

　　GitOps是一種全新的應用系統(tǒng)開發(fā)模式，因此安全人員也需要從新的視角看待GitOps環(huán)境下的數(shù)字業(yè)務取證、事件響應及其他安全建設工作。過去，安全事件響應人員在開展安全事件調(diào)查和溯源時首先需要花費大量時間去查清環(huán)境中究竟發(fā)生了什么。通過正確實施的GitOps模型，可以清晰記錄整個環(huán)境中的所有行為來源，只要識別中央Git存儲庫中的更改或檢測環(huán)境中的“漂移”行為，就可以立即檢測到漏洞、不安全的配置或?qū)Y源進行的惡意更改。

　　為了讓DFIR和GitOps緊密配合，安全人員可以通過以下方式進行優(yōu)化和調(diào)整：

　　01 集成警報和DFIR工具

　　安全團隊需要直接訪問取證數(shù)據(jù)，以便用來確定警報的優(yōu)先級和對事件進行分類。因此，DFIR平臺、安全監(jiān)控和警報工具應與事件管理工具集成起來，以便安全警報可以直接發(fā)送到工作團隊使用的現(xiàn)有工具和工作流程。同時，需要創(chuàng)建審計跟蹤記錄，記下響應每個警報的情況，這提供了可見性和問責制，并有助于改進響應流程。

　　02 提供可操作的反饋

　　在發(fā)現(xiàn)安全問題后， DevOps團隊需要盡快推送更新。因此在添加和實施防護措施時，要確保開發(fā)人員了解相關(guān)安全構(gòu)建或部署的標準。確保系統(tǒng)不僅能夠阻斷危險，還為開發(fā)人員提供有意義的上下文，比如說存在什么安全問題、它如何影響代碼以及需要怎樣來修復。

　　03 防止云漂移

　　在純粹的GitOps模式中，控制器組件不斷對照生產(chǎn)資源的實際狀態(tài)檢查IaC模板中的預期狀態(tài)；一旦檢測到任何偏差，就重新部署資源。然而實際情況往往并非如此，在許多情況下，維護工作將因手動配置更改和調(diào)整資源而發(fā)生漂移。

　　因此要留意云漂移，務必要有完整的可見性和監(jiān)控機制，以確保問責制。一旦明確發(fā)現(xiàn)了漂移，應盡快撤消這些更改，或者將更改添加到IaC模板，并通過管道推送更改。記住，IaC模板對DevOps環(huán)境構(gòu)成了最大的安全風險之一，任何更改都可能是惡意的。

　　04 持續(xù)跟蹤進度

　　要跟蹤基于GitOps的安全實施的進度，應列出已識別和修補的現(xiàn)有錯誤配置的數(shù)量，以及新引入的錯誤配置的數(shù)量。這兩個數(shù)字都應該逐漸減少。另一個有價值的指標是修補已識別的錯誤配置所需的時間。最初這可能是幾小時或幾天，隨著GitOps環(huán)境趨于成熟，可會縮短到幾分鐘或幾秒鐘。

　　為安全指標設立基準也很重要，因為這可以幫助團隊發(fā)現(xiàn)異常情況。比如說，如果錯誤配置數(shù)量突然增加，團隊應立馬清楚發(fā)生了異常情況。開發(fā)人員可以全面調(diào)查環(huán)境，查看新部署或現(xiàn)有部署是否違反策略，并解決問題的根本原因。

更多信息可以來這里獲取==>>電子技術(shù)應用-AET<<