基于DevOps的安全保障研究

李 深余 建

（1.中国电信股份有限公司福建分公司，福建 福州 350000；2.三明学院网络中心，福建 三明 365004）

0 引言

21世纪的技术革命就是互通互连的应用，它们让人们的点滴生活变得更加便利。云计算让工作生活效率倍增，帮助人们网上购物、网上订餐、车票预订等，分享照片给朋友和家人，寻找新家附近的美食，跟踪健身计划的进展，大众越来越受益于这些应用。腾讯、淘宝、京东、Facebook和Google等服务的增长速度表明，无论是在手机屏幕上还是在浏览器中，每个应用都为用户带来了巨大的价值。

这场革命的成功一部分要归功于创建和运营这些应用的工具的进步。互联网上的竞争日益激烈，用户对创意的新鲜感很快就会消退，组织必须快速行动来占领市场份额，并锁定其产品的用户。在初创企业的世界里，取得成功的关键因素是创意融入产品的速度和成本。DevOps带来了一场革命，通过互联网世界里工具和技术的工业化，它让低成本运营在线服务成为可能，这场革命让小型初创企业也能够和科技巨头相互竞争，一争高下。

在这场创业热潮之中，数据安全有时候会受到损害。客户已经展示出了对应用的信任，并且愿意用他们的数据来换取功能，这导致大量的组织存储了海量的用户个人信息，而当这种局面形成之时，组织往往还没有准备好能处理这些数据的安全策略。一个让组织心存侥幸的激烈竞争格局再加上海量的敏感信息，这简直就是孕育灾难的完美“温床”。因此，随着在线服务数量的不断增加，数据泄露也随之出现得越来越频繁。

1 De v Op s安全现状

随着云服务和云生态环境的兴起，传统的网络运营已经从提供和运行云基础设施，转移到了提供服务支持型的应用程序。现在，随着容器化环境技术的发展，安全团队也在进行着类似的转变，这是因为应用程序的安全已经逐步进入了DevOps的领域。考虑到DevOps在构建、测试和部署应用程序方面的专业知识和核心作用，大量的运营成员必须负责去保护这些应用程序以及基础设施。虽然安全团队仍然需要去制定一些安全策略并设置防护边界，但DevOps将越来越多地去操作更适用于容器化应用程序的安全工具。

2 De v Op s中的安全

DevOps（Development和Operations的组合词）是一种重视“软件开发人员（Dev）”和“IT运维技术人员（Ops）”之间沟通合作的文化、运动或惯例。透过自动化“软件交付”和“架构变更”的流程，来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。

DevOps可以代表许多不同的含义，这取决于它应用于信息技术（IT，Information Technology）领域的那个部分。运营核电站的基础设施和在网站上处理信用卡的支付有很大的不同，但同样都可以从DevOps中获益，对运营进行优化和加强。本文不可能涵盖DevOps和IT的全部领域，因此重点着眼于云服务，这是一个专注于Web应用开发和运维的领域。对于运维保护和维护一个托管在云中的Web应用，可以轻易地将它们转换到任何DevOps环境之中。DevOps教会使用者，行之有效的策略要求运维方和开发方结合得更为紧密，要开发人员和运维人员之间的各种沟通壁垒。同样地，保障DevOps必须从安全团队和他们的工程师伙伴之间的紧密协作开始。安全需要作为服务的一项功能提供给客户，同时安全团队和DevOps团队的内部目标必须保持一致。

当安全变成DevOps不可分割的一部分之后，安全工程师可以将安全控制直接内建到产品之中，而不是在事后强加于产品之上。每个人都有着让组织获得成功的共同目标。只有目标达成一致，沟通才得到改善，数据安全得到提升。将安全引入Devops的核心思想中，让安全团队采用DevOps技术，将他们的注意力从仅仅保护基础设施转移到通过持续改进来保护整个组织的目标上来。在本研究中，笔者将这种方法称为持续安全。

3 De v Op s的持续安全模型

持续安全由三个领域组成，图1中已由三个带编号的方框标出。每一个领域都聚焦于DevOps流水线的一个特定方面。客户的反馈刺激了组织的扩张，从而驱动出新的特性，这一过程也适用于持续安全。本文分为三个部分，每一部分分别覆盖了持续安全的一个领域：

图1 “持续安全”模型

（1）驱动安全（TDS，Test-Driven Security）。程序安全的第一步就是定义、实现并测试安全控制。TDS覆盖了简单的安全控制，比如Linux服务器的标准配置，还有Web应用必须实现的安全标头。通过持续地实现基本的安全控制，并不断地测试这些安全控制的准确性，可以获得极大的安全感。在实施得不错的DevOps中，人工测试应该是例外而不是规则。安全测试的处理方式和所有应用测试的处理方式一模一样，自始至终都要自动化。

（2）监控与应对。在线服务命中注定会受到威胁。当事件发生时，组织会向安全团队求助，团队必须准备好应对之策。持续安全的第2个阶段就是监控和应对风险，保护组织赖以生存的服务和数据。

（3）消除风险并完善安全性。网络安全不只是技术，安全策略如果只是关注技术问题，则不能称之为成功。持续安全的第3个阶段将跳出技术范畴，在更高的层面观察组织的安全形势。

成熟的组织信任它们的安全程序，而且会和它们的安全团队紧密协作。要做到这一点，组织需要专注、经验及良好的意识，即知道什么时候承担风险及什么时候规避风险。全面的安全策略要结合技术和人员，识别出可以改进的方方面面，并且合理地分配资源，所有这些都发生在快速完成的改进周期中。

3.1 测试驱动安全

只用手机就能突破层层防火墙或是破解密码，这样的黑客神话只是电影大片里的噱头，真实世界里鲜有这样的事情发生。在大多数情况下，攻击者会找安全防御较弱：有安全漏洞的Web框架、过时的系统、密码容易被猜到且可以公开访问的管理页面，以及不小心泄露在开源代码里的安全凭证，这些都是攻击者喜欢的目标。实现持续安全策略的第一个目标就是守住底线：在组织的应用和基础设施上使用基本的安全控制集并持续地进行测试。

安全团队、开发人员及运维人员之间应该建立安全最佳实践清单，以确保每个人都认同其价值。通过收集这些最佳实践并加入一些常识，基线需求的列表很快就可以建立起来。

3.1.1 应用安全性

现代Web应用暴露在大量的攻击之下。开放Web应用安全项目（OWASP，Open Web Application Security Project）发布了排名在前十名的最常见的攻击手段：跨站脚本攻击、SQL注入攻击、跨站请求伪造、暴力攻击，等等，数不胜数。幸运的是，每一种攻击向量都可以通过在正确的地方使用正确的安全控制来化解。

3.1.2 基础设施安全性

依靠laaS（Infrastructure as a Service）运行软件并不能让DevOps团队高枕无忧，从而不用去关心基础设施的安全性。所有系统都有对外授予更高权限的入口，比如VPN、SSH网关，或者管理面板。随着一个企业的不断扩张，在开放新的入口和集成更多模块时，必须一直小心翼翼地保护好系统和网络。

3.1.3 流水线安全性

DevOps交付产品的自动化方式和大多数安全团队熟悉的传统运维方式完全不同。破坏CI/CD流水线只会把运行在生产环境中的软件的控制权拱手让给攻击者。在从代码提交到生产环境部署的这个过程中，采用的自动化步骤可以使用提交签名和容器签名这样的完整性控制来保护。

3.1.4 持续测试

在刚刚定义的三个领域中，对于任意一个领域中的应用来说，安全控制单独实现起来都相当简单。困难来自随时随地测试和实现它们。这就是TDS该发挥作用的时候了。TDS是一种类似测试驱动开发（TDD，Test-Driven Development）的方法。TDD建议开发人员先编写表达期望行为的测试，然后再来编写满足测试的代码；TDS建议先编写表达期望状态的安全测试，然后再实现让测试通过的安全控制。

3.2 攻击监控安全与应对

现代组织十分复杂，要想用合理的成本覆盖每一个角落基本上是不可能实现的。安全团队必须权衡优先级。日常的攻击监控与应对方法集中在日志和欺诈检测、入侵检测和事件响应三个方面。如果组织能做好这三项，那么就是做好了应对安全事件的准备。

3.2.1 日志和欺诈检测

日志的生成、保存和分析在组织的每一个部分都发挥着作用。开发人员和运维人员需要日志来跟踪服务的健康度。产品经理使用它们来度量特性受欢迎的程度或是用户留存率。对安全性来说，要关注检测安全异常和在调查事件时提供取证能力两个特定的日志需求。日志收集和分析达到理想化的要求几乎是不可能的。海量的数据使存储变得不切实际。

日志流水线是处理并集中来自各种日志源的日志事件。日志流水线十分强大，因为它提供了一条可以执行异常检测的单一管道。与每个组件自己执行检测相比，它的模型更简单，但是它在大型环境中的实现可能比较困难。图2概括了日志流水线的核心组件。

图2 日志流水线分析

日志和流水线包含了：用于记录来自基础设施各个组件的日志事件的收集层；用于捕捉和路由日志事件的流式处理层；用于检查日志内容、检测欺诈并告警的分析层；用于归档日志的存储层。允许运维人员和开发人员访问日志的访问层。强大的日志流水线为安全团队提供了监控基础设施所需的核心功能。

3.2.2 入侵检测

入侵检测在入侵基础设施时，攻击者通常会按照以下四个步骤执行：

（1）在目标服务器上留下恶意载荷。恶意载荷是一种非常小的后门脚本或恶意软件，小到可以被下载和执行而不会引起注意。

（2）一旦部署，后门便会与母船建立联系，通过命令与控制(CC，Commandand-Control)信道接收进一步指令。CC信道可以采用很多种形式，包括：出站IC连接，在正文中隐藏特殊关键字的HTML页面，或者在TXT记录中嵌入命令的DNS请求。

（3）后门执行指令并在网络中扩散，扫描并入侵其他主机直到发现有价值的目标。

（4）找到目标后，攻击者势必要盗取其中的数据，很可能是通过另一条和CC信道平行的信道来盗取这些数据。

对于网络流量和系统事件，可以采用以下工具进行观察和分析：

（1）入侵检测系统（IDS，Intrusion Detection System）：图3展示了IDS如何通过持续不断地分析网络流量副本，以及如何通过持续不断地在网络连接上应用可检测欺诈活动的复杂逻辑，来检测CC信道。IDS擅长对千兆字节的网络流量中的欺诈活动模式进行实时检查。

图3 IDS流量检测拓扑图

（2）连接审计：分析经过基础设施的全部网络流量有时是不现实的。NetFlow提供了另一种审计网络连接的方式，它通过将连接信息记录在流水线中的方式来进行审计。当无法访问底层时，NetFlow是审计IaaS基础设施中的网络层活动的好方法。

（3）系统审计：对线上系统的完整性进行审计是跟踪整个基础设施中发生一切事情的绝佳方法。在Linux中，内核的审计子系统可以记录在系统中执行的所有系统调用。攻击者在入侵系统时常常会在这种类型的日志中留下蛛丝马迹，将这些审计事件发给日志流水线可以帮助检测到入侵。

入侵检测难度很大，常常需要安全团队和运维团队的密切合作。如果操作不当，这些系统就会占用本该用于运营生产服务的资源。3.2.3 事件响应

在任何组织中，遇到的最紧张的情况或许就是处理安全事故了。即使是最强大的公司，安全事件给公司带来的混乱和不确定性也可能严重破坏其健康运转。在安全团队手忙脚乱地恢复系统和应用的完整性时，领导层也必须做好止损，并确保业务能尽快恢复正常运营。

在应对安全事件时应该遵循的一套六阶操作手册。它们是：

（1）准备：确保有一套处理安全事件的最精简流程；

（2）识别：迅速判断异常是否是安全事件；

（3）隔离：阻止破坏进一步扩散；

（4）杀灭：消除对组织的威胁；

（5）恢复：恢复组织正常运营；

（6）总结：事后进行回顾并总结经验教训。

4 De v Op s安全保障

完整的安全策略远远不是只涵盖实现安全控制和事件响应等技术方面的因素，持续安全中的“人”的因素才是实施风险管理的关键。

4.1 评估风险

对许多工程师和管理人员来说，风险管理就是制作花花绿绿的超大电子表格，任由它们在收件箱里堆积如山。不幸的是，这种现象屡见不鲜，这导致许多组织放弃了风险管理。管理风险就是识别出威胁到生存和增长的问题，以及排列出它们的优先级。电子表格中的花哨的单元格的确有用，但那并不是重点。好的风险管理必须达到以下三个目标：

（1）频繁快速地以小迭代的方式运作。软件和基础设施会持续不断的变化，一个组织必须能够频繁地讨论风险，而不是陷进数周漫长的流程中；

（2）DevOps自动化，手动操作只是例外，而不是规则；

（3）组织里的每个人都要求参加风险讨论，构建安全的产品和维护安全是整个团队的工作。

4.2 安全测试

成熟的安全程序的另一个核心强项是能够通过安全测试定期评估自身的表现。通过测试策略如何在以下三个重要方面来帮助完善组织的安全性：

（1）使用漏洞扫描、模糊测试、静态代码分析或者配置审计等安全技术手段对应用和基础设施的安全性进行内部评估。笔者将讨论多种可以集成到CI/CD流水线中的技术，它们将变成DevOps策略中软件开发生命周期（SDLC，Software Development Lifecycle）的一部分；

（2）利用外部公司来审计核心服务的安全性。如果目标正确，安全审计会给组织带来很多价值，并且利于用新的思路和视角审视安全程序。通过有效地使用外部审计和“红军”，让它们充分发挥作用；

（3）建立漏洞报告奖励程序。DevOps组织通常会积极拥抱开源并公开发布大量源代码。对于独立安全研究人员来说，这是巨大的资源，他们会测试应用，并报告他们在安全性上的发现以换取几千美元的报酬。

完善一个持续安全程序需要好几年的时间，但这些时间投入会让安全团队变成一个组织产品策略中不可或缺的一部分。通过跨团队的紧密合作及对安全事件的妥善处理和技术指导，安全团队将从他们的伙伴那里收获保障客户安全的信任。成功的持续安全策略的核心就是：将安全人员及其工具和知识尽可能地与DevOps中其他人拉近距离。

5 结语

要想真正保护客户，安全性必须内建到产品之中，必须和开发人员还有运维人员紧密合作。测试驱动安全，监控与应对攻击，以及完善安全性是推动组织实现持续安全策略的三个阶段。传统的安全技术，例如漏洞扫描、入侵检测及日志监控，都应该被重复利用并进行调整，以适应DevOps流水线。