xp 自动化安全配置_自动化管道作为安全推动者

xp 自动化安全配置

让我们从安全角度考虑自动化管道。 管道可以成为安全推动因素。 开发人员机器中的安全代码可能会导致生产中运行的代码不安全。 特别是在此过程中需要人工干预时。 自动化管道可以减轻这种风险。 我们必须确保只能通过管道将代码提升到生产环境中，这样才能最大程度地减少攻击面 。

但是， 可以被破坏的管道不能提供太多的安全保证 。 同事和自动化专家Marc van Lint 宣告我们的管道与我们的应用程序代码同样重要 。 在安全性方面尤其如此。 DevOps的许多概念已经到位，可以帮助我们实现这一目标。 管道应定义为代码，并保存在安全的存储库中并进行版本控制。 这样，我们可以很好地看到代码投入生产的所有步骤，只有授权用户才能对其进行更改（最低特权原则），任何更改都可以追溯到特定个人。

在确保管道安全之后，我们必须使其有用。 在非常高的水平上，管道主要是关于测试和升级到不同的环境。 管道的一个好方法是先廉价又快速。 我们提供了许多可用的工具，我们可以直接使用它们。 静态应用程序安全测试（SAST）和动态应用程序安全测试（DAST）在我们的管道中必不可少。 然后是一致性测试，例如PCI DSS。 OWASP维护了一系列安全测试工具[1]，评估并选择您需要的工具。 然后，当然，我们定义了测试。 单元测试，集成测试，回归测试，性能测试，故障测试。 清单很长。 测试是建立信心的基础。 通过每次测试，我们可以更加确定我们的代码是安全的。 同样重要的是，我们会生成支持证据（稍后会对此进行更多介绍）。

以上工具可用于我们存储库中已存在的代码或在我们的环境之一中运行的应用程序。 但是我们可以更早开始。 Talisman [2]之类的工具是Git的一个预推钩子，可以在我们提交之前捕获提交的可疑文件，例如授权令牌和私钥。 现在，我们处于“保守秘密”这一主题上，这是一个具有挑战性的主题，通常到位的流程都是不安全的。 这是我们的管道提供帮助的好地方。 生成证书，遵循密码策略并保守机密性，机密性应自动化。 默认情况下，这可以确保安全性 。 管道再次救援！

现在关于通过环境进行推广。 二进制文件仅生成一次，并且可用于所有阶段（测试，验收，生产）。 完全相同的机制用于释放到每个环境。 每个提交都会被构建，测试并发布到生产环境中吗？ 没那么快。 我们希望快速发布，确实如此，但是我们不能以牺牲安全性为代价。 为了促进发展，有一些安全原则要到位。 包括职责分离和资产分类 。 我将从后者开始，因为它可能并不那么明显。 在我看来，与生产环境相比，我们的测试环境（及其中的代码）可以归为较低价值的资产。 测试环境中的漏洞没有生产中的漏洞那样严重。 我会解释的，不要生我的气。 如前所述，我们希望我们的自动化流水线能够在保持安全的前提下尽快进行，并尽可能减少干预。 提交仅通过了所有测试就无法达到生产。 后门或漏洞可能会泄漏出去。 在发布到生产之前，公司中可能需要一些流程。 因此，将变更移至测试环境而无需审查变更可能很好，但需要接受代码审查和书面批准才能接受。 然后从接受到生产的提升，不能仅仅通过开发人员的批准而完成，而产品所有者，经理和变更请求的批准必须是其中的一部分，并且必须自动化。 从而分离关注点。 所有这些当然都可以在我们的管道中观察到，并在整个过程中记录下来。

因此，在将所有这些精力都放在保护我们的管道并在其中嵌入安全测试并将其用于保护我们的发布过程之后，下一步是什么？ 我们要证明！ 生产中出现的任何人工制品均应附带采取安全措施的支持证据 。 这对于审核非常有帮助。 幸运的是，只要我们在管道中的任务具有相关的综合日志记录，那么按照我们的描述进行管道操作就很容易了。

我们确保管道是将代码投入生产的唯一途径。 管道是可观察的并已版本化。 对代码进行功能，漏洞，合规性，性能，故障的测试，并生成这些测试的报告。 在推广到不同环境之前，必须先获得四眼原则的认可。 所有这些均已记录，分组，保留并准备好用于当前或过去生产中的每个工件。 管道既不是我们安全之旅的起点也不是终点。 但是它们可以而且应该是非常重要的资产。

[1] https://www.owasp.org/index.php/Appendix_A:_Testing_Tools[2] https://github.com/thoughtworks/talisman

翻译自: https://www.javacodegeeks.com/2019/08/automation-pipelines-security-enabler.html

xp 自动化安全配置