安全赋能业务，让安全与业务共生 – 作者:黑客小平哥-安全小百科

前言

随着企业业务的高速发展，云计算与微服务等基础架构的逐步成熟，传统的安全模式已经很难满足如今的安全需求。特别是《网络安全法》实施以来，企业越发重视自身的安全发展，也在不断尝试改变自身的安全体系架构，但是安全与业务的传统矛盾依旧无法真正解决，如何让安全与业务共生成了迫切需要解决的难题，本文重点带来业务安全体系建设的思考。

安全的演变之路

传统的安全模式

在网络安全泛滥的年代，黑客肆无忌惮的横行，QQ被盗、网站被黑、上网被钓鱼等等问题屡见不鲜。随后，部分前瞻性企业开始进行自身的网络安全治理，增设网络安全工程师相关职位，对自身安全问题进行安全测试并提交开发进行修复，“安全补漏”阶段也随之而来并逐步被其它企业效仿。

SDL诞生

随着“互联网+”的兴起，企业业务高速发展，传统的“安全补漏”模式的弊端也随之出现。当业务系统被黑客攻击之后，往往很难第一时间去发现并解决，一般都会造成一定程度的损失，特别是近几年兴起的勒索病毒（如Wannacry）、挖矿病毒的出现导致企业顿时陷入瘫痪，因此安全问题又重新被重视起来，“安全前置或安全左移”思想也逐步产生，SDL（软件安全开发生命周期）安全体系建设也在这时候被提上日程，并被广泛接纳。

SDL到DevSecOps的演变

SDL安全体系建设在一定程度上有效的缓解安全问题的产生，但是好景不长。云计算与微服务等基础架构的逐步成熟，给企业带来新的难题，也对开发、测试、运维等安全人员有了更高的要求。DevOps带来的各种优势和趋势成为安全实施的难点，快速交付、新技术风险、安全职责划分、安全文化的缺失等等都是急需解决的安全痛点。由于SDL缺乏对运维过程安全的关注，在此环境下DevSecOps逐步被引用到企业中，相比较传统SDL而言，DevSecOps不仅仅只注重代码安全，而是将安全手段穿插到研发与运维的每个阶段，真正做到人人关注安全、人人参与安全、人人为安全负责，目前像阿里、滴滴等科技公司都已经将DevSecOps流程化，从而大大提升系统安全性，其中的一些经验和思考值得我们参考和学习。

安全与业务的思考

企业安全与业务联动

既然有了安全体系建设的目标，那么将其落地就是个艰苦而漫长的过程。安全与业务最大的矛盾是安全可能会阻碍业务的发展，由于安全问题导致业务上线推迟或者下线。由于安全体系建设是“由安全部主导，多部门联合”的特殊性，导致安全落地最大的阻力不是代码，不是测试而是部门联动性和人员配合性，因此为解决这一矛盾有以下建议：

1、建立安全体系建设规程文件

正所谓无规矩不成方圆，安全体系建设的前提必须要有相应的规程文件，明确安全的角色、职责、动作等基本流程框架，当然，这少不了高层领导及相关架构师的支持。

2、增设初步的安全团队及安全业务接口人

安全团队是安全体系的基础，安全团队的任务是带领业务走向正确的安全轨道，因此一个好的安全团队往往能够轻松的带动多条业务安全线，控制业务安全走向。

但是由于安全人员和业务人员分工不同，甚至在不同部门，因此对业务内部工作缺乏认知，缺少沟通，所以由业务团队增设安全业务接口人是打通安全与业务的关键。安全业务接口人职责是充当安全与业务的桥梁，传递安全讯息与调配安全资源。

3、以“纵深防御，适度安全”为核心思想

“纵深防御”思想一直以来都是企业安全从业者秉承的宗旨，纵深防御是指不能只依赖单一安全机制，应该建立多种机制，互相支撑以达到比较满意的目的。“纵深防御”体系能够有效的保障企业的内部安全，能够及时阻止外部的横向入侵，但是没有绝对的安全，任何企业也无法做到绝对安全。当然，“绝对安全”的理想是美好的，但是代价是巨大的，企业要想发展，业务必须排在第一位，“绝对安全”会严重影响业务的走向，得不偿失。因此，必须以“纵深防御，适度安全”为核心思想，让业务安全、稳定的运行，那何为适度？值得我们思考。

DevSecOps落地思考

DevSecOps具体落地方案会单独介绍，本次不再赘述，本次重点介绍DevSecOps在企业中的重要地位、重难点防治以及落地关键点。

1、DevSecOps落地简述

DevSecOps是一种全新的安全建设模型，是对敏捷开发以及持续集成/持续交付（CI/CD）有力的安全扩展，得益于DevOps的快速发展。随着安全被越发重视，安全思考也越来越深入，其宗旨就是将开发、测试、运维等过程全部纳入安全手段当中，人人为安全贡献，人人为安全负责，借助一张图可以清楚明白这种模型整体架构：

上图（引用OPPO）可以清晰的看出安全手段完整的嵌入在软件生命的每个阶段，实时的保障软件的安全走向，因此，团队协作才是DevSecOps能够高效稳定的运行的核心。

下图是DevSecOps落地基本动作一览图，基本涵盖了一系列落地的基本要求和需要建立的模板、动作、平台和规范等等，落地详情此次不做赘述。

2、重难点防治

开源组件治理

针对DevSecOps治理中后期会发现，传统的安全问题在DevSecOps逐步完善的时候就已经被消灭的殆尽，开源组件问题就会被凸显出来，比较熟知的像Apache Struts和fastjson等等安全问题层出不穷，给企业带来极大的隐患。

安全版本不可控：开源组件由于无法由企业内部控制，导致研发在引用的时候经常忽略其版本的安全性先以业务为主，且企业创建安全组件库过于复杂且影响大导致无法实施，最终上线版本可能存在安全隐患。

安全扫描误报大、筛选困难：在DevSecOps流程中，针对开源组件扫描的时候，常常由于其误报大，筛选困难，以及对业务的影响，导致该过程单纯的只是形式化，无法真正保障安全。

线上项目组件问题监控难：往往线上项目突然发现开源组件漏洞后，无法实时定位具体应用路径，导致应急时间长，增大风险暴露时间。

内部组件失控：对于公司内部研发的组件较开源组件治理相对容易，但是往往被企业忽略，内部研发的通用组件往往缺少源码安全审计以及没有第一时间管控，导致后期业务重复漏洞频发，增加重复工作量。

API安全治理

企业另一大安全隐患就是API接口安全，由于其往往被企业研发人员忽略，导致风险得不到重视。

缺乏访问授权：“权限最小化原则”应该是企业的基本共识，但是可能在API接口中却得不到体现，API未授权问题导致企业大量敏感信息暴露在公网。

缺乏私有请求认证：企业研发人员往往因为调用方便，或者缺乏安全意识，没有防篡改、防重放攻击等安全手段，导致调用API的时候只进行简单的认证，如使用简单的id对应身份，导致越权等问题出现。

缺乏传输加密：用户敏感信息明文传递是极容易被忽略的地方，往往由于服务端加解密不易同步实现，导致被搁置。

3、适度安全的核心

前文提到“纵深防御，适度安全”的问题，那么何为“适度安全”？在企业安全建设中，业务人员往往感觉安全手段是给自己的一个牢笼，上线迫在眉睫，还有腾出手来整理安全漏洞，加班加点，这样长此以往，配合度明显降低。

“适度安全”的宗旨就是坚守底线，抓大放小。我们的底线是不能存在高危漏洞，在次基础上，对其它安全问题根据业务需要，抓大放小，保障业务如期交付的前提下，对业务适当放行，等业务稳定运行之后，在对“小问题”进行逐步排期解决，这样才能保障安全与业务同步进行。

4、安全自动化平台建设

DevSecOps这么庞大的安全体系，参与人员、参与部门那么多，工作那么繁杂，单纯靠人来完成几乎不可能，业务人员也没有那么多时间来做具体的事情，所以，自动化平台建设就需要同步进行。

可视化操作平台建设：由于非安全人员甚至连安全人员自己都不能清楚的知道DevSecOps安全建设的具体实施方案，导致大家都像无头苍蝇，不知道下一步干什么，建设DevSecOps线上操作平台以及可视化平台，可以使各方面的参与人员有一个标准的操作流程和跟踪流程，明确大家整体的安全走向。

CI/CD自动化安全扫描工具链建设：由于CI/CD的自动化操作，导致人为参与的安全手段无法紧跟脚步，最终被抛弃。但是随着IAST/RASP技术的广泛使用，安全自动化扫描已经完全可以完美集成到业务当中，完成业务测试部署的同时，自动化且无感知的完成安全扫描，大大节省安全的人力，也为业务人员节省了安全测试时间。