【51CTO.com快译】开发运维正在彻底改变开发人员和运营团队的协同工作方式，以便更快速地交付更优秀的软件。究其核心，开发运维的本质是自动化。开发、测试和部署方面的几项任务自动化后，开发人员就可以经常修改代码，并部署到生产环境。亚马逊这家领先的开发运维倡导者曾经一度声称每天要部署1000多次。
但是这种加快的工作流程有可能绕过安全编程实践，开发人员常常发现很难在第一时间融入这种实践。如果开发运维要继续保持发展势头，开发人员就需要在软件交付生命周期的早期阶段整合安全测试。
这就是“加固型开发运维”背后的想法，这场运动让开发人员负责安全测试。加固型开发运维插入了多个点，以便安全测试能够及早发现潜在的软件问题，以免这类问题进入生产环境，但同时又不影响持续集成和应用程序交付。
分析公司Securosis的首席技术官阿德里安·莱恩(Adrian Lane)说：“加固型开发运维就是在进入到生产环境之前整顿代码，确保一旦代码部署到生产环境，能够抵御外部威胁。要像攻击者那样对待你的代码。”
以开发运维之道确保代码安全
开发运维的核心目标是，提供实现敏捷开发必不可少的自动化和实践，并且让软件开发由庞大的瀑布项目转为持续交付管道。
加固型开发运维需要一种类似的转变：丢弃非常复杂的、为期多年的安全路线图，改为逐步改进。太多企业组织往全面的计划投入了大量的资金和时间，结果发现投入打了水漂。
总体愿景比路线图更灵活，让每个人都可以专注于逐步改进。比如说，致力于确保头一个季度部署的所有新代码没有SQL注入问题，然后在下一个季度清理旧应用程序中的SQL注入问题，而不是说到年底所有应用程序都得到修复，清除开放式Web应用程序安全项目(OWASP)列出的十大安全漏洞排行榜上的所有软件漏洞。
这种逐步改进方法的一个影响是，缩短了发现安全漏洞后修补漏洞所花的时间。通过把项目分成多个小部分，更容易优先确定代码更改，并在更短的部署窗口内准备好发布。安全问题被有序地分成较小的具体任务后，开发人员就可以优先考虑并处理安全漏洞及其他代码更改。
测试软件有助于确保安全成为迭代方法的一部分。比如说，Gauntlt这种安全测试框架为众多安全工具提供了钩子(hook)，它让开发人员、运维团队和安全团队在质量保证过程中相互合作，从而将测试融入到持续集成中。测试工作及早提供了应用程序安全方面的反馈。
让开发人员负责安全测试并不是那么牵强附会――毕竟，开发人员一般相当了解在哪里找到应用程序的危险地带(hot spots)。他们知道哪里的信息是硬编码，哪些组件应该有更多的错误处理，哪些部分会得益于更好的数据管理。
Splunk的安全市场副总裁宋海岩在最近的一次视频采访中说：“更快地工作意味着更有效地处理安全漏洞。不要仅仅专注于在开发和测试过程中发现代码错误――要考虑生产环境中的代码有问题后，改进响应和修复流程。让安全成为整个系统的一部分，那样人们没必要考虑安全。”
将安全纳入工作流程
开发运维让开发人员更快地移动，但更快地工作并不意味着糟糕代码或更多的安全漏洞。完全存在这种风险：有更多的机会犯错误，或者忽视常见的配置设置。
硬编码密码就是一个明显的例子。将密码嵌入到源代码中、“之后”修复，而不是合理创建含有登录信息的一个配置文件来得更快速。要是不落实提醒开发人员回过头去删除密码的控制机制，或者不落实发现遗留代码的代码审查流程，你就有可能敞开大门。
软件提供商Micro Focus的副总裁乔治·韦伯(George Webb)说：“开发运维不是让我们开发更多的不安全代码，而是我们确实需要考虑落实治理和管理的种种方式。”
在大多数开发周期中，“安全测试”专注于外部威胁，比如用户错误或恶意黑客攻击，却忽视了开发人员或管理员可能构成的内部威胁。加固型开发运维扭转了这种情况，测试查找开发人员错误和管理员配置错误，并确保权限和角色正确分配，那样在必要的情况下限制了数据访问。安全测试应包括清理代码、重置调试器以及审核配置文件的步骤。所有这些任务应在工作流程的早期阶段完成，以免阻碍软件交付。
韦伯表示，“我们并不改变你构建代码、编写代码或者测试代码的方式”，而是扩大了测试范围，兼顾更多的使用场合。
持续交付管道的另一部分是实现工具链自动化，那样用于开发、集成、测试、部署和代码监控的工具可以连接起来。消除使用手册和易出错的流程，并实现工具标准化，确保每个人都遵循同样的程序、使用同样的工具集来工作。通过尝试，搞清楚在哪里把安全融入到工具链中。比如说，只要新代码签入(checked in)、应用程序完成，代码分析常常最有意义。
理想方法因组织和团队而异。比如说，许多开发运维团队发现很难加入静态代码分析，因为静态扫描往往需要很长的时间。莱恩表示，如果代码每天要提交多次，就没有足够时间加入安全测试。
模糊的界线，但治理存在
开发运维消除了开发、质量保证、运维和安全方面的孤岛，那样每个人都能作为同一个团队的成员协同工作。虽然开发人员承担了更多的安全责任，但他们并没有让安全团队失业。
安全管理员应继续为内外系统管理开发人员的身份、角色和访问权限。开发人员应该被视为特权用户，而不是管理员，只可以访问他们需要处理的那些类型的数据或源代码部分。
为了避免阻碍开发人员，一个方法就是使针对受限制的资源请求临时提升权限的过程实现自动化。另一个方法是建立一个组件库或资源库，拥有认为可以安全使用的最新版本的组件库和模块。只要开发人员访问组件库，应用程序不太可能受到旧代码错误的危害，而版本标准化简化了维护和部署。
安全团队仍然有其工作，但角色发生了变化。现在它建议并帮助工具选择，给出部署方面的建议，甚至帮助编写代码或测试，以验证代码。
Micro Focus的解决方案及支持副总裁雷纳托·奎达斯(Renato Quedas)说：“我们一起测试，一起开发，一起部署。就因为界线模糊并不意味着你没有任何控制可言。”
自动化控制为安全铺平道路
自动化是将安全控制融入到开发运维的关键。工具链中的每个工具可以生成审计跟踪记录，比如谁签入代码，出现了什么变更。扫描工具可以定期检查企业的每个GitHub代码库，密切关注被发送到企业外面的敏感数据，比如硬编码的登录信息、加密密钥以及其他类型的访问令牌。
开发人员可能将新版本的组件和库上传到共享组件库或资源库，但这么做应该启动一个验证过程，确保新组件是合法的，并生成审计跟踪记录，表明谁进行了变更。
在部署到生产环境前后使用Chaos Monkey是另一个很好的例子，表明了安全测试如何成为整个生命周期的一部分。Chaos Monkey是来自网飞公司(Netflix)的一个开源项目，这种服务在亚马逊网络服务上运行，网飞驻留在该平台上。Chaos Monkey力求自动扩展群组，并终止群组里面的虚拟机。这样一来，各团队就可以隔离并解决应用程序或总体架构在处理故障时面临的任何问题，以免在没人照看的凌晨时分演变成重大问题。
由于把重点都放在了自动化和工具链上，很容易忘了这点：开发运维并不是单单着眼于技术或流程。采用某一种工具或方法并不意味着“搞开发运维”。开发运维是一种理念。它可能始于开发流程的重要人员，但是要真正发挥影响，开发运维就需要渗入到企业文化中。
首先要尊重
加固型开发运维要奏效，工作团队、开发人员和运维团队就需要信任对方。若没有这个必不可少的部分，每一个请求和任务就会变得很艰难。
开发人员、运维团队和安全人员对于彼此都抱有先入为主的观念，因而很难让各团队合为一体。开发人员不是可以为所欲为的牛仔，运维团队并不干脆拒绝偏离既定流程的任何事情，安全人员并不只是一味唠叨安全漏洞和规则。要有大家都在同一个团队的想法，这点很重要。
为了博得每个团队的关注，要解决它们最关注的问题。与运维团队谈论避免停运和性能故障，与安全和风险专业人员着重谈论数据泄密和安全漏洞，与开发人员谈变如何减少计划外的工作。
进行常规的红队/蓝队演练，那样所有团队成员都能看到问题在哪里，并如何改变日常做法。检测到网络中断有多快?要花多长时间才能查明问题，并拿出解决方法?目前是否进行测试以用于软件测试或网络监控?是时候设计新的测试来检测未来的类似事件吗?
一开始，你就需要让每个人意见一致，让团队看到别人要处理的种种挑战。开发运维原本就需要大家的共同参与。否则，自动化工具、逐步改进或安全控制机制都毫无作用。
【51CTO译稿，合作站点转载请注明原文译者和出处为51CTO.com】
