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正好可以将这种合作提升到新的水平，创建“融入到”开发流程中的集成式安全能力。

GitOps可以实现代码级的安全能力，所有配置和安全策略都是声明式的，并统一保存在版本控制系统中。这让所有更改都可以输入到自动化管道中，以验证、部署和监控它们。

GitOps不仅仅是一种管理基础架构的有效方式，它还提供了一种将安全转移的策略，在开发周期的早期阶段记录预期状态的所需更改，比如安全问题、错误和漏洞。GitOps可以更加轻松地修复与安全相关的错误，并立即重新部署受影响的环境或应用程序。

如果组织的业务系统因为存在漏洞而受到威胁，GitOps可以快速响应以修复安全问题。组织可以回滚到以前的安全配置，或者添加补丁或修复程序以立即部署新版本，从而快速响应事件或漏洞。

将基础架构作为代码来存储有助于快速识别存储库中与漏洞相关的特定代码行。它可以帮助调查人员快速评估事件的规模、更迅速地恢复，并减小网络攻击造成的破坏。

数字取证和事件响应（DFIR）主要包括恢复和调查数字化IT系统上发现的违法线索和证据。随着社会越来越依赖计算机系统和云计算，DFIR已成为网络安全防护和执法管理工作的重要方面，也是确保网络安全的关键操作程序。

GitOps是一种全新的应用系统开发模式，因此安全人员也需要从新的视角看待GitOps环境下的数字业务取证、事件响应及其他安全建设工作。过去，安全事件响应人员在开展安全事件调查和溯源时首先需要花费大量时间去查清环境中究竟发生了什么。通过正确实施的GitOps模型，可以清晰记录整个环境中的所有行为来源，只要识别中央Git存储库中的更改或检测环境中的“漂移”行为，就可以立即检测到漏洞、不安全的配置或对资源进行的恶意更改。

为了让DFIR和GitOps紧密配合，安全人员可以通过以下方式进行优化和调整：

安全团队需要直接访问取证数据，以便用来确定警报的优先级和对事件进行分类。因此，DFIR平台、安全监控和警报工具应与事件管理工具集成起来，以便安全警报可以直接发送到工作团队使用的现有工具和工作流程。同时，需要创建审计跟踪记录，记下响应每个警报的情况，这提供了可见性和问责制，并有助于改进响应流程。

在发现安全问题后， DevOps团队需要尽快推送更新。因此在添加和实施防护措施时，要确保开发人员了解相关安全构建或部署的标准。确保系统不仅能够阻断危险，还为开发人员提供有意义的上下文，比如说存在什么安全问题、它如何影响代码以及需要怎样来修复。

在纯粹的GitOps模式中，控制器组件不断对照生产资源的实际状态检查IaC模板中的预期状态；一旦检测到任何偏差，就重新部署资源。然而实际情况往往并非如此，在许多情况下，维护工作将因手动配置更改和调整资源而发生漂移。

因此要留意云漂移，务必要有完整的可见性和监控机制，以确保问责制。一旦明确发现了漂移，应尽快撤消这些更改，或者将更改添加到IaC模板，并通过管道推送更改。记住，IaC模板对DevOps环境构成了最大的安全风险之一，任何更改都可能是恶意的。

要跟踪基于GitOps的安全实施的进度，应列出已识别和修补的现有错误配置的数量，以及新引入的错误配置的数量。这两个数字都应该逐渐减少。另一个有价值的指标是修补已识别的错误配置所需的时间。最初这可能是几小时或几天，随着GitOps环境趋于成熟，可会缩短到几分钟或几秒钟。

为安全指标设立基准也很重要，因为这可以帮助团队发现异常情况。比如说，如果错误配置数量突然增加，团队应立马清楚发生了异常情况。开发人员可以全面调查环境，查看新部署或现有部署是否违反策略，并解决问题的根本原因。

https://www.tripwire.com/state-of-security/controls/what-is-gitops-how-will-it-impact-digital-forensics/

合作电话：18311333376

合作微信：aqniu001

投稿邮箱：[email protected]