您还未登录! 登录 | 注册 | 帮助  

您的位置: 首页 > 软件开发专栏 > 开发技术 > 正文

三项DevSecOps核心原则,保证交付的安全与速度

发表于:2018-10-12 作者:陈峻编译 来源:51cto

三项DevSecOps核心原则,保证交付的安全与速度

现如今,尽管各种骇人听闻的网络攻击事件已是各类新闻头条的“常客”了,但是大多数企业仍会在其IT环境的搭建之初就忽略了、或错误地实施了安全管控。

而对于一些初创型企业及其新建的IT系统而言,它们时常会将有限的资金花费在无关的资产、或流程的保护之上。根据Verizon 2018年度数据泄露调查报告显示,在一般企业的系统中,有40%的漏洞会出现在应用层。而他们花费在保护应用程序上的年度安全预算,却只有3%~4%。

与此同时,一般企业的IT部门在人员岗位分配上也存在着不均衡的现象,时常会出现100名开发人员仅配备了一位安全技术专家的状况。而这些孤独的安全人员,往往不得不疲于提供瀑布式的安全策略与实践,以赶上整个研发团队的敏捷开发节奏。因此,当他们根据安全检查表中的不达标项,叫停某些应用编码工作、进而导致延迟产生的时候,都将被视为是对公司当前项目推进的阻碍、内部生产效率的破坏、甚至是对整体文化的“毒害”。

在现实情况中,如果您没有在整个软件交付的管道中实施安全流程管控的话,那么您必将面临着各种组件的延迟交付或风险发布,而且这些组件往往会带有潜在的漏洞。不过,这恰好是DevSecOps能够发挥作用的地方。它通过各种安全实践,来最小化软件交付管道中的各种脆弱性,为组织的IT和业务的目标保驾护航。

在XebiaLabs公司(译者注:一家独立的软件公司,专注于为大型组织开发企业级的持续交付与DevOps软件)最近组织的一次网络研讨会上,来自Signal Sciences的研究主管--James Wickett,与DevOps思想领袖--Gene Kim,以及XebiaLabs的首席产品官(CPO)--Rob Stroud,讨论了如何将安全性接入到整个DevOps生命周期中的三项原则。

您除了可以通过链接:https://xebialabs.com/community/webinars/devsecops-missing-link-of-business-velocity/,来收听该网络研讨会的现场录音之外,还可以通过如下文字阅读有关DevSecOps的三项核心原则。

原则1:为最坏的场景做好设计

为了将安全性尽量“左移”(指各项流程管道的初始阶段),获取开发部门的理解与支持是非常重要的。为了实现该目标,各个企业需要帮助研发人员了解到,在他们的应用程序中可能存在的威胁与漏洞,并需要有针对性的进行各种计划与设计。Wickett建议采用如下四种方式:

  • 舱壁模式(Bulkhead Patterns)-- 以一种分割应用程序之间依赖性的方式,来设计您的程序代码。这是一种“未雨绸缪”的设计理念。如果您能够隔离应用程序中的各个组件,那么纵然某一个组件出现了故障,而其他组件仍然可以运行并提供服务。Wickett说,该模式的典型应用案例就是针对微服务的引入。您会很自然地借用舱壁的理念,将大的整块服务分割成多个小的单功能服务。虽然这是一种绝佳的安全实践,不过我们也需要在企业环境中事先考虑到微服务的扩展限制问题。
  • 恶意用户场景(Evil User Stories) -- 您可以通过描述用户如何破坏系统的安全性,来提醒敏捷开发团队,在他们编写最终产品代码时限制恶意用户的各种可能行为。例如他们可以这样制定代码的逻辑:如果有用户在访问某个网站时,试图进行跨站点脚本注入攻击,那么就直接拒绝其任何操作行为。Wickett说,那些具有高安全性的组织,通常会使用各种既定的语言、模式和测试框架,来描述不同的用户场景,并以此融入现有的敏捷开发企业文化之中,使之成为可接受的系统的一部分。
  • 威胁建模(Threat modeling) -- 在软件开发的过程中,您可以使用威胁模型来说明应用程序在运行时所涉及到的组件,并识别出这些组件可能面临的潜在风险,进而选取最好的防护措施。威胁建模对于那些缺乏安全专家人手的环境是至关重要的。同时,通过提供一些具有针对性的风险管控模型,安全人员会更容易实现与研发部门的沟通,并达成共识。
  • 风险评估(Risk Assessments) -- 您可以将基于风险的评估方法运用到自己的环境中,以确定哪些给定的措施更适合于自己的用例环境。这将有助于开发人员通过提供参数输入的方式,将评估集成到应用的设计与实施阶段,并贯穿整个项目的生命周期。

原则2:安全测试贯穿整个管道

一般而言,针对软件交付管道的全面安全加固,就意味着:在应用程序的整个生命周期,对每一个组件和阶段,都采取漏洞测试。您可以采用如下的方法测试软件交付管道的安全性。

  • 逆境测试(Adversity Testing) -- 您可以通过各种“实战性”的攻击工具,对自己的管道进行注入攻击,以找出不同的安全漏洞。Wickett推荐下载的工具包括:Metasploit(https://www.metasploit.com/)、Nikto(https://cirt.net/Nikto2)和Arachni(http://www.arachni-scanner.com/)。安全人员通过利用它们来对某个网站进行测试,以找出那些薄弱的环节。这些测试的目的都是为了获悉您系统环境中的漏洞,以及整体抗攻击的能力。
  • 安全即代码(Security-as-Code) -- 类似于基础设施即代码(infrastructure-as-code, https://xebialabs.com/glossary/infrastructure-as-code/),安全即代码是将各种安全模式集成到代码系统之中,成为一个自动化的流程部分。由于它能够更多地将开发人员带入安全相关的流程中,因此安全即代码是企业塑造DevSecOps文化的重要组成部分。
  • 漏洞测试(Vulnerability Testing) -- 通常情况下,我们会用不同的方法对应用程序进行漏洞测试。其中包括:
    • 静态应用程序安全测试(SAST),提供了一套检测应用程序代码漏洞的工具集。
    • 动态应用程序安全测试(DAST),是采用外部攻击,来测试应用程序的运行状态的一种方法。
    • 交互式应用程序安全测试(IAST),是在测试阶段分析应用程序的行为,以帮助开发者对所发现的漏洞进行优先级排序的一种方法。

原则3:摒弃只重视AppSec培训的谬误

在过去十年间,整个行业都过于重视培训开发人员编出具有安全性的代码。虽然AppSec培训非常重要,而且其各种最佳实践能够提高企业的整体安全意识,但是它也会带来一些其他问题。对于一些新手程序员而言,只要是用人工编写代码的方式,就可能会带有漏洞。因此我们不应盲目地认为他们所开发的代码,足以让其应用程序固若金汤。同时,接受过AppSec培训的研发人员,会更具备“全栈”的开发能力,当然更容易被其他公司所“挖”走。

因此,我们不能只专注于开发人员是否能编写出更为安全的代码,而应该尽可能地将各种流程自动化,并放置到软件交付管道的左侧(初始阶段),同时在右侧(管道的末端)增设各种与安全相关的监测工具。另外,我们应当尽量通过一套部署管理系统,来强制实施各项自动化的进程,以保证代码在最终发布阶段的安全性。

安全性和敏捷性并重

对于一般企业而言,将不同职能部门的团队组织起来,通过DevOps的协作方式,在规定时间内交付出软件产品是极具挑战性的。我们时常会看到一些实施了DevOps的企业,他们的团队虽然实现了在软件产品交付上的“提速”,却无法让产品达到相应的安全水准。因此,如果您在软件持续交付的过程中忽略了安全性的保障的话,那么您最后将会失去客户的信任,也没有人愿意、或敢去使用您的软件产品。

原文标题:Delivering Security and Speed: The 3 Core Principles of DevSecOps ,作者:Tim Buntel

 相关文章