关于开发运维 安全团队需要知道什么?
作者: 日期:2017年01月04日 阅:5,389

开发运维(DevOps)在19%的IT公司中已经在用,另外19%处于试验阶段,还有35%打算在2017年实现开发运维。以上数据源于上周刚举行了数据中心、基础设施和运维大会的某大型分析公司的调查结果。明年,将是开发运维跨越鸿沟的一年。

devops-security

随着开发运维逐渐成为主流,将安全融入其守则是不可避免的。无论“开发安全运维”这词儿是否流行,安全必须提升位序以更早进入软件供应链的时代已经到来。

什么是开发运维?

在将安全囊括进开发运维之前,先定义好开发运维或许会有所帮助。难点之一,是每个开发运维项目都是独特的。畅销开发运维书《凤凰计划》作者之一乔治·斯巴福德曾说过:“让5个人来定义开发运维,你会得到7种不同答案。”

Gartner对开发运维有个定义,使用了内部术语,对不熟悉敏捷开发方法的人而言不太能理解。定义开发运维存在阻力,因为固定的行业标准可能会有违以最符合公司业务需求的方式实现的目标。

因此,没有标准定义,反而有助于理解这段公案。敏捷开发是在需要更快创新的压力下出现的。然而,开发发布速度,受限于基础设施和运维。因而,开发与运维合作更紧密的压力就是开发运维的推动力。

作为草根运动,尽管在定义上一直存在争议,开发运维支持以下几大原则倒是越来越获得共识了:

  • 开发运维的存在有助于帮助公司取得成功
  • 涵盖很广,但焦点在IT
  • 基础是敏捷和精益
  • (协作)文化很重要
  • 反馈是创新之源
  • 自动化能帮忙

最后,开发运维是关于使用协作、敏捷方法解决业务问题或运用信息技术抓住商机的。

开发运维与安全如何交织?

如果公司正运用开发运维,下列6条原则可供用以使安全支持开发运维工作:

1. 开发运维的存在有助于帮助公司取得成功

安全一直享有“说否部门”的美誉,尽管靠策略缓解风险依然是信息安全的一个重要组成部分,业务需求也必须在这些策略中占据同等重要地位,而不是仅仅从安全实践方面考虑。二者不应是相互敌对的,业务部门必须了解风险,承认风险,同时,在共同协作中,安全部门必须着重考虑如何帮助公司取得竞争优势。

2. 涵盖很广,但焦点落在IT

公司想要在被数字化改变了的世界取胜(想想Uber对出租车行业做了什么),IT就处在这一转变的中心位置。但它并不是一个人孤零零坐在圆心。与公司其他部门,比如人力资源、财务、运营甚至外部供应商的配合是必需的。信息安全应在风险耐受和公司监管要求之内,持续寻求尽可能无摩擦的相互交流。

3. 基础是敏捷和精益

理解从丰田制造运营中借用来的敏捷宣言和精益原则,将大大有益于安全人士融进开发运维。安全必须配合各项工作达成持续集成/交付/部署,并提供积极清除软件供应链中各种限制(比如许可等待时间)的方法。

4. 文化很重要

开发运维与之前做法的最大不同,就是对协作的强调。这是一种分享共同目标以有所成的文化思维,也是代表业务而非技术产出的标尺。安全应该融入减少风险的协同努力,而不是表现得像是疏离在外的批评者。

5. 反馈是创新之源

实验和学习对开发运维很重要,而这些需要足够的反馈,尤其是来自业务部门的。该反馈需要暴露给每个人,以便能够做出改善和更大的创新,但这也要求类似“无可非议的解剖”之类的东西来改进系统。安全文化在开发运维中必须避免沦为指责文化。

6. 自动化能帮忙

自动化带来了更快更便利更高质量的交付。工具是开发运维的力量倍增器,但不是其基础。自动化不能强化协作,但确实能让协作更方便。用作测试、认证或监视的安全工具应包含在开发运维工具链中,它们的输出应被广泛共享以形成提升。

2017是信息安全团队与开发运维携手共建,成为业务和其他IT部门更好的合作伙伴的一年。公司企业依赖这种能力来进行更快的创新和保持更低的风险,借此抓住机会,扛住数字化压力。

 

申明:本文系厂商投稿收录,所涉观点不代表安全牛立场!


相关文章