BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

安全性——“DevOpS”中的S

| 作者 Manuel Pais 关注 9 他的粉丝 ,译者 李彬 关注 1 他的粉丝 发布于 2013年6月28日. 估计阅读时间: 3 分钟 | CNUTCon 了解国内外一线大厂50+智能运维最新实践案例。

阿姆斯特丹DevOps Days的第一天,Schuberg Philis安全官Frank Breedijk在演讲中介绍了安全性和DevOps之间的摩擦,以及如何协作以避免这些问题。演讲中,他举出的例子包括自动化安全测试及其环境、缩小安全审计范围使其仅针对相关系统组件,或是让安全性补丁在产品变更队列中能够享有更高顺位。

Frank强调了安全性与以下两项因素之间的矛盾:开发方面在安全性上缺乏投入(他们更注重功能的交付),而且还缺乏来自运营方面的支持——运营方面认为安全性是其常规工作之上的不必要负担。最后,由于DevOps看起来缺乏职责分离,而且令产品变更频率上升,安全方面的人员往往将其视作一种风险。Frank认为真正的DevOps文化应该倡导协作——不仅仅是开发和运营之间的协作,还要提倡他们与安全方面的协作(因此,他开玩笑道,DevOpS中的S应该与其他首字母缩写中的S具有相同涵义,例如Http/HttpS, Imap/ImapS)。

要增加各方之间的协作,可以阐明安全性要求,并增加系统变更的透明度,从而减少对安全威胁的恐惧。例如,针对PCI、DSSSOX审计的一种常见误解,是认为需要审计整个系统,而实际上只有部分组件需要经过审批。另一方面,产品变更的交付频率一般会因为采用DevOps而显著增加。回滚将不再是可行的选择,而随着发布高优先级安全性修订能力的增加(在产品变更队列中插队),前向修正(fixing forward)将得以实现。

Frank认为,对安全性来说,高交付频率并非注定成为问题。当对所有人可见的时候,较小的变更会更容易进行安全性分析和测试;再加上交付窗口数量的增加,将允许更快地修复产品中的安全性问题。最后,专注于基础架构配置管理,以管理诸如动态产品环境等内容,也将有助于基础架构安全性测试。例如,自动检查用于配置新机器的OS镜像,以及所有需要的安全性补丁。综上,安全环境和测试的自动化将变得更容易,而后便能够轻松地整合到交付流程中。

对于功能导向敏捷开发团队和产品拥有者的心态,Frank也指出了将安全性要求纳入其中所面临的困难。为了满足这些要求所需的工作,需要在开发迭代中进行规划,而诸如通过修复安全性缺陷以减少技术债务的工作,应该与功能交付得到同等奖励。

最后,Frank表示真正的DevOps文化应该拥抱安全团队,并调整激励措施,从而让为了交付功能性变更而工作的人们也能够看到安全性和运营方面的要求。安全团队不应该被看做交付变更的瓶颈,而是一种“免疫系统”——侦测威胁并提供解决它们所需要的洞见和工具。

与大会其他内容一样,这一演讲通过流媒体进行了直播,其讲稿也已经发布在网上。

查看英文原文:S is for Security

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我
社区评论

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT