取消
显示结果 
搜索替代 
您的意思是: 
cancel
3276
查看次数
0
有帮助
2
评论
julianchen
Spotlight
Spotlight
引言:本文向您介绍将安全整合到DevOps中(DevSecOps),以保证您能更快、更低风险地交付出软件产品的三项原则。
现如今,尽管各种骇人听闻的网络攻击事件已是各类新闻头条的“常客”了,但是大多数企业仍会在其IT环境的搭建之初就忽略了、或错误地实施了安全管控。
而对于一些初创型企业及其新建的IT系统而言,它们时常会将有限的资金花费在对于无关的资产、或流程的保护之上。根据Verizon 2018年度数据泄露调查报告(https://www.verizonenterprise.com/verizon-insights-lab/dbir/)显示,在一般企业的系统中,有40%的漏洞会出现在应用层。而他们花费在保护应用程序上的年度安全预算,却只有3%~4%。
与此同时,一般企业的IT部门在人员岗位分配上也存在着不均衡的现象,时常会出现100名开发人员仅配备了一位安全技术专家的状况。而这些孤独的安全人员,往往不得不疲于提供瀑布式的安全策略与实践,以赶上整个研发团队的敏捷开发节奏。因此,当他们根据安全检查表中的不达标项,叫停某些应用编码工作、进而导致延迟产生的时候,都将被视为是对公司当前项目推进的阻碍、内部生产效率的破坏、甚至是对整体文化的“毒害”。
在现实情况中,如果您没有在整个软件交付的管道中实施安全流程管控的话,要么您必将面临着各种组件的延迟交付或风险发布,而且这些组件往往会带有潜在的漏洞。不过,这恰好是DevSecOps能够发挥作用的地方。它通过各种安全实践,来最小化软件交付管道中的各种脆弱性,为组织的IT和业务的目标保驾护航。
XebiaLabs公司(译者注:一家独立的软件公司,专注于为大型组织开发企业级的持续交付与DevOps软件)最近组织的一次网络研讨会上,来自Signal Sciences的研究主管--James Wicketthttps://www.linkedin.com/in/wickett/),与DevOps思想领袖--Gene Kimhttps://blog.xebialabs.com/2017/04/20/10-tips-integrating-security-devops/),以及XebiaLabs的首席产品官(CPO--Rob Stroudhttps://blog.xebialabs.com/2018/07/24/separation-of-duties-how-to-conform-in-a-devops-world/),讨论了如何将安全性接入到整个DevOps生命周期中的三项原则。
您除了可以通过链接:https://xebialabs.com/community/webinars/devsecops-missing-link-of-business-velocity/,来收听该网络研讨会的现场录音之外,还可以通过如下文字阅读有关DevSecOps的三项核心原则。
原则1:为最坏的场景做好设计
为了将安全性尽量“左移”(指各项流程管道的初始阶段),获取开发部门的理解与支持是非常重要的。为了实现该目标,各个企业需要帮助研发人员了解到,在他们的应用程序中可能存在的威胁与漏洞,并需要有针对性的进行各种计划与设计。Wickett建议采用如下四种方式:
l 舱壁模式(BulkheadPatterns-- 以一种分割应用程序之间依赖性的方式,来设计您的程序代码。这是一种“未雨绸缪”的设计理念。如果您能够隔离应用程序中的各个组件,那么纵然某一个组件出现了故障,而其他组件仍然可以运行并提供服务。Wickett说,该模式的典型应用案例就是针对微服务的引入。您会很自然地借用舱壁的理念,将大的整块服务分割成多个小的单功能服务。虽然这是一种绝佳的安全实践,不过我们也需要在企业环境中事先考虑到微服务的扩展限制问题。
l 恶意用户场景(EvilUser Stories -- 您可以通过描述用户如何破坏系统的安全性,来提醒敏捷开发团队,在他们编写最终产品代码时限制恶意用户的各种可能行为。例如他们可以这样制定代码的逻辑:如果有用户在访问某个网站时,试图进行跨站点脚本注入攻击,那么就直接拒绝其任何操作行为。Wickett说,那些具有高安全性的组织,通常会使用各种既定的语言、模式和测试框架,来描述不同的用户场景,并以此融入现有的敏捷开发企业文化之中,使之成为可接受的系统的一部分。
l 威胁建模(Threatmodeling-- 在软件开发的过程中,您可以使用威胁模型来说明应用程序在运行时所涉及到的组件,并识别出这些组件可能面临的潜在风险,进而选取最好的防护措施。威胁建模对于那些缺乏安全专家人手的环境是至关重要的。同时,通过提供一些具有针对性的风险管控模型,安全人员会更容易实现与研发部门的沟通,并达成共识。
l 风险评估(RiskAssessments -- 您可以将基于风险的评估方法运用到自己的环境中,以确定哪些给定的措施更适合于自己的用例环境。这将有助于开发人员通过提供参数输入的方式,将评估集成到应用的设计与实施阶段,并贯穿整个项目的生命周期。
原则2:安全测试贯穿整个管道
一般而言,针对软件交付管道的全面安全加固,就意味着:在应用程序的整个生命周期,对每一个组件和阶段,都采取漏洞测试。您可以采用如下的方法测试软件交付管道的安全性。
l 逆境测试(AdversityTesting -- 您可以通过各种“实战性”的攻击工具,对自己的管道进行注入攻击,以找出不同的安全漏洞。Wickett推荐下载的工具包括:Metasploithttps://www.metasploit.com/)、Niktohttps://cirt.net/Nikto2)和Arachnihttp://www.arachni-scanner.com/)。安全人员通过利用它们来对某个网站进行测试,以找出那些薄弱的环节。这些测试的目的都是为了获悉您系统环境中的漏洞,以及整体抗攻击的能力。
l 安全即代码(Security-as-Code -- 类似于基础设施即代码(infrastructure-as-code,https://xebialabs.com/glossary/infrastructure-as-code/),安全即代码是将各种安全模式集成到代码系统之中,成为一个自动化的流程部分。由于它能够更多地将开发人员带入安全相关的流程中,因此安全即代码是企业塑造DevSecOps文化的重要组成部分。
l 漏洞测试(VulnerabilityTesting -- 通常情况下,我们会用不同的方法对应用程序进行漏洞测试。其中包括:
§ 静态应用程序安全测试(SAST),提供了一套检测应用程序代码漏洞的工具集。
§ 动态应用程序安全测试(DAST),是采用外部攻击,来测试应用程序的运行状态的一种方法。
§ 交互式应用程序安全测试(IAST),是在测试阶段的分析应用程序的行为,以帮助开发者对所发现的漏洞进行优先级排序的一种方法。
原则3:摒弃只重视AppSec培训的谬误
在过去十年间,整个行业都过于重视培训开发人员编出具有安全性的代码。虽然AppSec培训非常重要,而且其各种最佳实践能够提高企业的整体安全意识,但是它也会带给一些其它问题。对于一些新手程序员而言,只要是用人工编写代码的方式,就可能会带有漏洞。因此我们不应盲目地认为他们所开发的代码,足以让其应用程序固若金汤。同时,接受过AppSec培训的研发人员,会更具备“全栈”的开发能力,当然更容易被其他公司所“挖”走。
因此,我们不能只专注于开发人员是否能编写出更为安全的代码,而应该尽可能地将各种流程自动化,并放置到软件交付管道的左侧(初始阶段),同时在右侧(管道的末端)增设各种与安全相关的监测工具。另外,我们应当尽量通过一套部署管理系统,来强制实施各项自动化的进程,以保证代码在最终发布阶段的安全性。
安全性和敏捷性并重
对于一般企业而言,将不同职能部门的团队组织起来,通过DevOps的协作方式,在规定时间内交付出软件产品是极具挑战性的。我们时常会看到一些实施了DevOps的企业,他们的团队虽然实现了在软件产品交付上的“提速”,却无法让产品达到相应的安全水准。因此,如果您在软件持续交付的过程忽略了安全性的保障的话,那么您最后将会失去客户的信任,也没有人愿意、或敢去使用您的软件产品。

【原标题】Delivering Securityand Speed: The 3 Core Principles of DevSecOps (作者: Tim Buntel)
原文链接: https://dzone.com/articles/deliv ... he-3-core-principle

评论
one-time
Level 13
Level 13
感谢版主分享,谢谢~
Ning Zhang
Cisco Employee
Cisco Employee
感谢分享,谢谢!!!!!!
入门指南

使用上面的搜索栏输入关键字、短语或问题,搜索问题的答案。

我们希望您在这里的旅程尽可能顺利,因此这里有一些链接可以帮助您快速熟悉思科社区:









快捷链接