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

GitOps對安全事件調查與取證的影響

GitOps是一種新的開發模式，最早是由 Kubernetes 管理公司 Weaveworks在 2017 年提出，其目的主要在于為云原生應用程序實現簡單持續的部署。

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

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

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

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

1、安全能力左移

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

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

2、加快安全事件響應

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

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

GitOps環境下開展數字取證的最佳實踐

數字取證和事件響應（DFIR）主要包括恢復和調查數字化IT系統上發現的違法線索和證據。隨著社會越來越依賴計算機系統和云計算，DFIR已成為網絡安全防護和執法管理工作的重要方面，也是確保網絡安全的關鍵操作程序。

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

為了讓DFIR和GitOps緊密配合，安全人員可以通過以下方式進行優化和調整：

1、集成警報和DFIR工具

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

2、提供可操作的反饋

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

3、防止云漂移

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

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

4、持續跟蹤進度

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

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