Secure DevOps Environments

最近看了一本小书《Secure DevOps Environments》，觉得有些观点非常有趣，简单记录一下。

文章中提到了一个非常有意思的词和观点，即：shift-left hacker 。文章中指出，目前攻击者已经不仅仅把目标设定在应用程序上，已经开始左移了，逐步把精力放到研发人员的开发环境、构建环境等等，并给出了几个不同阶段的实际攻击案例。

针对这种情况，MS 和 Sogeti 提出了一种方案来保护 DevOps 环境，虽然文章的最终目的可能是为了给 Sogeti 引流，但是文章中提出的一些建设思路和观点还是值得借鉴的。

原文链接：https://azure.microsoft.com/zh-cn/resources/securing-enterprise-devops-environments/

全文一共分为四个部分，分别是：

• 保护开发人员环境 (Secure The Developer Environment)
• 保护企业 DevOps 平台环境 (Secure The Enterprise DevOps Platform Environment)
• 保护应用环境 (Secure The Application Environments)
• 保护企业 DevOps 最佳实践 (Secure Enterprise DevOps In Practice)

这里简单的把大标题总结成了一张脑图：

按照四大部分简单总结一下文章内容。

Part I: Secure The Developer Environment

作者抛出了一个观点，对于开发人员来说，通常更想要高权限的账户、强大的、可定制的开发环境，这通常对开发人员提升效率有很大的帮助。实际情况也确实如此，开发过程中需要频繁测试或者修改代码，如果每次部署或测试都需要申请一大堆复杂的权限，或者开发环境非常难用，确实会降低开发效率。

基于这些情况，开发环境往往具有更高的权限以及更高的攻击价值，开发环境也逐步被 Shift-Left Hacker 盯上，作者也给出了一个发生在 2021 年 XCodeSpy 的真实攻击案例：https://thehackernews.com/2021/03/hackers-infecting-apple-app-developers.html

作者提出了 5 个方案/观点尝试对开发环境进行一些保护，下面简单展开讲一下。

Control The Developer Environment With A Cloud Environment

这部分作者提出尽量使用虚拟方案来建设开发环境，充分利用云资源的弹性、灵活的机制，随用随销毁。这样即便攻击者通过某些方式获取到了开发环境的权限，也没有足够的时间开展更多的攻击活动。但是这种方案有两个挑战：1. 很多团队可能不具备使用云创建、销毁、管理云虚拟机的专业知识。2. 频繁的创建销毁云资源对于成本管理是一项较大的挑战。

实际情况里，应该很少有企业能做到这种方案，但是如果针对部分高敏感的团队或部门实施这个方案，也许可行。

Secure The Developer Environment With Containers

这个其实是上一个方案的强化，即使用容器代替虚拟机，需要注意的是，容器的镜像需要企业自行维护，而不是使用各种公开镜像，以防出现各种供应链风险。

这里作者给了一个例子，即使用 Github Codespace ，在这个环境下开发代码时，Github 会为每一个开发人员分配一个单独的容器，用完就会销毁。

Configure Least Privilege Access

Most developers want to have administrator privileges to the environments and tools they use, but with great administrative privilege comes a great security challenge.

最小权限原则，已经被说烂了，但是真正能做到的企业却是少之又少。原因已经在前面讨论过了，开发人员往往更多的为了方便与高效，会尽可能的要求高权限，这就与最小权限原则互斥了。

这里作者提到了两个点，分别是使用统一的 SSO 对从 Web 端代码库的行为进行管控，另外一点就是使用受控制的 SSH KEY 来访问用户被授予相关权限的代码仓库，甚至这个 SSH KEY 可以由企业统一生成管理，不接受用户自己生成的密钥对。

Limit Who Can Change And Approve Code With Branch Security

这里主要观点是引入“分支管理策略”来限制开发人员引入新代码到代码库中，例如仅允许指定的人员向某个分支推送、合并代码，每次合并代码之前需要由指定人进行 CR，只有经过审计的代码才能合并到代码库中，这样一来，除非少部分管理员或CR人员的账号被盗用的时候，才能将恶意代码引入到代码库中，大大增加了攻击者植入后门代码的难度。

Adopt Only Trusted Tools, Extensions, And Integrations

这一点感觉国内很多公司都忽视了，即保证开发人员使用的 IDE 工具、IDE 上的插件是可信的。目前大部分情况下，开发人员都是直接从插件市场安装各种插件来提高开发效率，但是这就像各个语言的包管理工具一样，如果混入了恶意的插件进去，攻击者可以完全控制开发人员的开发机器，目前针对这方面的检测似乎也比较少见。

Part II: Secure The Enterprise DevOps Platform Environment

现代企业一般都依赖于成熟的流水线完成代码构建和部署，很多情况下传统的应用安全可能会忽视这部分环境，而这部分环境对于攻击者来说，往往具有更大的诱惑。

一般来说，构建环境里可能会存在很多敏感信息，包括代码本身、构建代码时需要填充的配置、各种拉去代码的密钥等等。

But now, with hackers shifting left and targeting these upstream tools, a new approach is needed to secure DevOps platform environments.

这里作者列举了 Codecov 的真实被攻击案例：https://www.zdnet.com/article/codecov-breach-impacted-hundreds-of-customer-networks/

对于这部分作者给出的方案或观点，简单介绍一下。

Ensure No Team Member Has Access To Secrets And Certificates

这里主要还是聚焦在权限问题，需要确保无关人员（无人员）可以访问到代码在生产环境中真实用到的各种密钥和证书。

主要思路是使用类似“统一密钥管理中心”之类的产品，统一管理密钥，只有在生产环境的代码，可以通过特定的方式访问到其中存储的密钥，也只能访问到当前系统被授予对应权限的密钥。

Automate Scans For Infrastructure-as-Code (IaC) Templates

随着基础设施也逐渐变成了一种“代码”，对于这类 IaC 环境进行自动化扫描也逐渐变得非常必要了。需要关注其中的各种配置错误、访问控制策略等等问题。一旦这些环境被部署到生产环境上，如果没有正确的访问控制，攻击者可能会较为轻松的连接到这些环境中。

Equip Every DevOps Platform Environment WIth Audit Trails

大部分情况下，传统的应用安全会更多的关注已上线系统的各种日志，但是对于 DevOps 平台、环境中的日志可能会有所欠缺。

而 DevOps 平台、环境中的日志可能会提供更多额外的价值，尽早的发现是否有攻击者在尝试植入后门、滥用权限等等操作。

日志记录中尽可能包含以下数据：

• 这个操作发生在哪个团队/组织中
• 哪位用户/账号触发的这个操作
• 在哪个代码仓库中触发的这个操作
• 具体执行了什么操作
• 这个操作的影响范围有多大
• 操作发生的详细时间

除此之外，还可以记录一些与企业、平台、业务特有的事件。这些日志最终应当被完整的审计（自动化、人工等），尝试从中识别出可能存在的各种安全风险。

Automate Approval Workflows

这部分主要观点是对于推送代码到生产环境等事件，需要进行审批，不能由开发人员自行推送任意代码到生产环境。

对于这一点，有些公司可能存在发布流程，仅允许在指定时间段发布，并且发布前有固定人员进行 CR 检查（大概率不是安全人员）。

咨询了我的某位曾在某头部互联网公司任职过的朋友，他们公司严格执行了发布前由安全人员对发布内容进行 CR 的策略。效果显著但成本巨大，确实极大的减少了线上的漏洞，但是也加重了安全人员的工作量（每天至少花费5个小时在 CR 上，至少工作到半夜12点）。这个方案还是要看实际的 ROI 来决定了。

Secure The Software Supply Chain

这一点应该就比较熟悉了，这几年国内也炒的火热供应链安全。在这个方面也是有很多的挑战，以后有机会可以展开单独讲讲。

Allow Only Verified DevOps Tool Integrations

这一点可能很多企业都是用不上的，字面意思，仅允许在 DevOps 平台上集成可信的工具。

大部分情况下企业内自建的发布平台，都有固定的发布流程和构建工具，很少有给开发人员自定义构建工具的情况。

作者使用了 Github Actions 举例，在 Github 上面，可以控制允许执行哪些 Actions，例如仅允许指定范围的 Actions 运行，可以大大的降低攻击面。

Part III: Secure The Application Environments

这一部分主要讲的还是应用安全，然而这部分私以为按照 SDL 展开会更好。作者并没有从 SDL 的角度出发，而是继续按照 DevOps 的角度继续描述的。

这一部分作者的主要观点在于，很多情况下，即使是开发环境、测试环境，可能也会持有大量的线上真实数据，或者一些其他的敏感信息，在做应用安全的时候，并不能因为这是个生产环境就忽视这个环境内的安全风险。开发测试环境同样有机会被攻击者访问到，同样会造成严重的安全问题。

这里提出了一个名词 landing-zone ，其实不太理解是什么意思，个人简单的假设为就是线上环境，即应用代码真实的部署环境。

在这部分中，作者提到了 SolarWinds 的真实被攻击案例：https://www.npr.org/2021/04/16/985439655/a-worst-nightmare-cyberattack-the-untold-story-of-the-solarwinds-hack

Leverage Well Architected Framework (WAF) For Landing Zone Provisioning

这里作者用到了个缩写 WAF，此 WAF 并不是 Web Application Firewall 的意思，个人不太喜欢这个缩写，有点造名词硬蹭的感觉。

这部分其实总结下来，就是应用需要一个好架构。比如需要包括：身份识别与访问控制、威胁保护、云安全、信息保护、信息合规、内部风险管理、发现与响应等等，顺便推了一波自家的 InnerSource 产品，说白了还是应用安全那一套，这里就不再继续展开讲了。

Lock Down Environments With Segmentation

个人感觉这里讲的内容更像是安全域划分和网络隔离相关的。主要有三块：

• Setup Management Groups
• Isolate Environments
• Segment Application Workloads

从各种意义上看起来都很像网络隔离，主要目的还是为了防范攻击者进入到内部后可以大规模的横向渗透。

Provide Security Teams With Visibility Into Delivery Pipelines

这部分内容更多的时关注扫描结果的透明化，即与 DevOps 团队共享扫描结果，从而与 CTO 或研发团队一起对存在安全风险的设施进行改造与修复。另外安全团队也需要自己的仪表板来收集、展示相关的安全风险，让安全团队更好的评估或了解当前系统的安全水位。

Remediate Vulnerabilities Quickly With A Software Bill Of Materials (SBOM)

这部分内容个人认为其实和软件供应链的部分放到一起更为合适。简单来说，软件供应链检查部分，并不仅仅是简单的检查出哪些依赖是不安全的就结束了，软件供应链检查环节还应该完整的记录下每个发布版本的交付物、构建产物的依赖清单，即 SBOM。有了这个清单之后，当未来的某一天某个组件出现漏洞时，企业可以根据这份清单快速的筛选出受影响的代码列表，从而缩短修复周期。

其实除了供应链信息，还需要存储更多关于代码的信息，这部分内容可以以后有机会再展开讲讲。

Part IV: Secure Enterprise DevOps In Practice

这里讲了一些保护 DevOps 的最佳实践，主要由以下三个部分组成：

• Teach DevSecOps Best Practices With InnerSource And Security Champions
• Find Ways To Leverage Self-Service Support
• Switch To Product-Centric DevOps Teams

说白了，再提出上面那三部分中的许多观点之后，都只是纸上谈兵，至少要落地到企业中才算开始。然而每个企业或者团队，本身就有不同的合作模式与工作模式，所以安全人员需要选取合适的模式插入 DevSecOps，并非一成不变。

这里的每一小节就不展开讲了，内容也比较简单，可以翻阅原文查看。

Closing Thoughts

很明显，对于一家企业的安全人员来说，仅仅关注于构建安全的应用程序时完全不够的，虽然这是一项重要的任务。但是要知道，对于攻击者来说，特别是 Shift-Left Hacker 来说，应用程序并不是攻击者唯一关注的东西。越来越多的 Real World 案例在表明，攻击者开始把目标转向了开发人员及其开发环境。

虽然刚刚书中提到的这些观点，也并不是通用的银弹，但是其中的某些部分还是有些启发的。对于应用安全架构设计来说，在设计时也不能忽视 DevOps 自身环境的安全风险。