应用安全体系建设之路

Posted 2023-05-04

参考技术A

只要提到应用安全，总是离不开一个概念——sdl建设，但是在大部分互联网公司并没有看到过哪家SDL做的好的，SDL强调安全流程，从业务需求的提出就介入进去，在整个业务的研发周期中，每一块都有相应的安全方法、安全制度来指导，安全作为业务的一个属性加入进去，SDL在过程中实施的是对业务的卡点、考核。

这块主要是对流程进行梳理，把安全与项目研发流程相结合形成项目的安全开发管控流程，安全贯穿到整个项目研发流程中，包括前期的需求分析，安全设计、代码编写、代码上线部署、测试环境测试、正式环境上线运行等，可以认为此时走传统的SDL流程。

这里有个问题，若是业务量增长的话对于人力成本是巨大的，这里很多公司就结合DevSecOps理念来解决一部分人手不足的问题，这个框架讲研发、运维、安全作为一个团队来对业务的安全负责，安全不单是安全团队的怎样，成了业务中每个人的责任。下面简要说下DevSecOps理念及落地实施。

对于DevSecOps的落地来说，这个只是个框架，是个方法论，具体的技术实施呢，都知道是将Sec融入到Dev和Ops的里面，对于怎么融入、怎样结合到起来，就需要根据不同公司的不同特点来定了。

对于安全来说，主要的任务就是保护公司的业务不会被外界入侵，不会被外界攻击，攻击能及时发现切断。

DevSecOps框架需要建设不同的安全体系，需要不断优化和完善对于的体系来覆盖框架的不同阶段。对于在真正的实施过程中，大部分公司都可能涉及到以下不同的能力建设，在具体落地过程中，笔者认为可以简单总结为几个能力建设：主动发现的能力、被动发现的能力、业务管控的能力、安全运营的能力。

主动发现的能力简单来说是能主动发现业务中的安全问题、安全漏洞、安全风险，业界中比较常用的技术有黑盒扫描、白盒扫描、安全评估与测试以及红蓝对抗。

这个是每个公司都会有的，也是初期重点建设的一块，有采用商业扫描工具：awvs、appscan等，也有采用自研方式进行。

这里不说商业的扫描工具，对于互联网公司，大部分都会采用自研扫描工具的方式进行，简单说下自研扫描器里面涉及到的一些需要重点考虑的地方：

白盒的话在互联网公司除了几个大厂有自研的引擎外，据了解都是采用了商业的工具，在具体的落地过程中也调研了不少白盒扫描工具：checkmarx、coverity、codeql、sonarqube。

checkmarx和coverity都有sonarqube的插件在，都可以作为sonar的一个引擎来工作，对于sonar来说，很多互联网公司都基于这个做代码质量的扫描，这个其实给做白盒能力有了很大的便利性。

checkmarx对于web来说效果比coverity要好些，并且对于用户的使用体验和操作都是比较不错，将checkmarx插件集成到sonar里面，这样业务不需要单独集成checkmarx，而是只需要按照以前的流程集成sonar就可加入安全扫描的能力。

但是有一点需要考虑，对于安全结果来说业务很多时候不知道是不是误报还是真实的安全风险，这就需要安全人员介入到流程里面，对代码扫描的结果进行审核，确定是漏洞的提交给业务，不是漏洞的直接忽略处理，这样前期需要大量的人工参与，需要不断优化规则，不断调整策略减少误报。前期可以通过对结果的分析可以将一些误报率较高的规则下掉，只留高威胁级别的规则在，保证人工在每天是可以覆盖的住流程的

后期的话由于sonar是带有api接口的，可以基于sonar包装一层，构建安全自己的代码扫描平台，可以提供api接入到CI中，可以将漏洞审核与漏洞管理平台打通，可以通过平台调整规则、新加规则等。这样在整个CI中，sonar+代码扫描平台两个，业务只要关心sonar上面的代码质量问题，安全只要登入代码扫描平台审核白盒扫描出来的漏洞即可。

这里涉及到一个白盒里面的子项目：白盒扫描插件，这个作为白盒检测，更加进行了左移，在业务编写代码的时候就直接进行扫描。可以基于：https://github.com/alibaba/p3c 来包装一层来做

还有一个白盒的子项目：第三方组件的漏洞发现，这个做起来可以通过采购商业软件来实现，比如Blackduck或者xray，对业务是透明的，只要安全人员控制好流程和策略。

红蓝对抗是一种能更深层次发现安全问题和安全风险的方式。每过一段时间组织一次蓝队行动，对着一个核心目标不限手段、不限方式地进行攻击，以获取核心目标为目的。可以更好地发现整个业务体系中存在的安全问题和安全风险点，帮助红队进行安全优化及建设，红蓝对抗在安全进行中一定程度后可以考虑重点进行建设，对于整个风险的发现和推动是巨大的。

被动发现安全风险的能力，可以采用的技术有：安全监控、蜜罐

监控可以分为两类：未发现风险的监控、风险之中的监控，风险之后的溯源

为了发现风险的监控，可以提前杜绝掉风险的发生，比如前面说的，若是资产梳理是没有问题的，可以每天将业务新增的资产进行扫描查看，比如：新上的域名是一个管理系统，他没有走内部的安全流程，就存在问题，直接要求整改。新上的域名、服务器直接进行扫描器的扫描，可以第一时间发现是否存在漏洞。

发生风险的时候的监控：

- 攻击流量监控 ：这个就是有很多扫描器、很多测试的数据的特征进行流量监控，监控到了直接报警，也可结合SOC进行数据分析处理，利用WAF进行自动化封IP等防御措施，这样将内部各个防御能力打通，实现自动化编排，后期流量日志采用大数据建模方式来发现未特征化的攻击。

- DNS监控： 对于很多命令执行、SQL注入、SSRF等漏洞的探测大部分是通过DNS来的，内部系统发起DNS请求是可以在内部DNS服务器上捕捉到的，这样将DNS日志监控起来，初始先制定一些黑名单，观察是否有机器对外发现这些恶意DNS请求了，对这些机器进行分析，就有可能发现未知的存在的安全风险。

- SQL执行日志监控： 对于sql注入的发现还是比较有用的，SQL注入通常会有一些注入特征在，只要匹配到这些特征，就可以发现某个业务在遭受sql注入的攻击

除此之外，对外界代码仓库、文档仓库的监控也是属于监控体系的，包括GitHub监控、百度网盘监控等等，这个github好说，很多开源的工具系统存在，将业务的关键信息加入到监控中即可，对于百度网盘之类的监控就不太好做了。

这个也是发现攻击的一种很好的方式，不单可以发现外部使用到的poc、密码字典等等信息，也能发现一些未知的攻击方式和APT行为存在

业务管控能力，比较通用的是WAF，为啥把WAF能力放在安全管控上面，WAF是可以做到哪些ip能访问，哪些ip不能访问，哪些路径能访问，哪些路径不能访问到的，说起来也是对业务的访问做的管理。WAF有很多成熟的商业产品在用，也可以自研，自研的话前期是基于正则匹配来做的，通过匹配对应的参数位置上的参数值是否包含有关键字来做。后期的话要想准确性高、误报率小的话还是需要机器学习和语义分析来做。

现在对于业务管控比较热门的零信任体系的建设，比较常见的是安全网关的模式，有空说下零信任的一些内容，现阶段知识还不深，就不说了，再深入研究研究看。

提到安全运营，很多人的脑袋想到的都是举办些安全活动，打打杂之类的工作，在笔者看来，一个企业的安全运营能力才真正能体现出该企业的安全能力，安全运营是推动SDL流程不断优化、不断完善的动力，是为DevSecOps规划建设指明道路和方向的。

技术要是没有了运营，是无法进行后续的优化和改进的，运营没有了技术，是虚的空的，无法落地的，安全运营包括了外部运营、内部运营，不同的运营又可划分为非技术运营、技术运营两种

外部运营里面的非技术运营，主要包括了安全品牌的建设、宣传等，主要是提供公司在业界的影响力，这样可以更好的吸引外部的安全研究者为我们服务，更好的吸引外界安全人员以外部视角参与到公司的安全建设中来

外部的技术运营：组织技术人员参加外部的比赛、大会等，发表技术文章等，以技术能力展现出来，这样在行业中展示出公司的技术实力。

内部非技术运营：汇总每个能力方面的数据做分析，将各个能力的结果通过数据化的方式展示出来，一方面可以给老板看到能力的建设进展情况，也能使大家了解到自己做的工作的成果

具体的落地可采用：数据大屏的方式来展示出来，通过soc平台完成。

内部技术运营：通过非技术运营出来的结果反哺各个能力建设，通过内部、外部发现的安全问题，优化各个能力的建设，补充不足之处，推动流程优化和DevSecOps建设方向。

具体落地：主要是需要运营人员对每一部分的能力建设比较了解，通过看问题能发现更深层面的东西，然后对每个结果进行安全能力上面的推动。

全链路压测性能保障体系建设之路

日前杭州数列科技资深技术专家高金受邀软件质量效能社区（Q&E Meetup online）分享关于全链路压测性能保障体系建设，以下文字是对本场直播内容的记录。

Play

2020年互联网面临新的机遇，但也出现了新的挑战。线上业务量增大，业务的复杂性也随之增加，传统压测工具无法满足日益增长的业务量，越来越多企业趋向于构建分布式架构。但由于分布式架构体系上的应用服务具有数量多、规模大、环境复杂等特点，这就导致其线上稳定性问题更难被快速发现及定位，即使好不容易将问题找到，单一的工具或系统也难以快速解决。

1. 全链路压测的应用场景

以下列举了一些适用于全链路压测的一些典型场景：

1.1 新系统上线场景：

准确探知系统承载能力，防止刚上线被用户流量冲垮。新系统上线一般会遇到以下两个问题：

1.  新系统能够支持多大的并发流量访问，是否需要增加机器来满足用户流量

2.  新系统性能是否满足预期，是否影响用户体验。

如果这两个问题没有很好的解决会造成严重的影响 ，举个例子：某知名电商双十一推出一款网红产品的秒杀业务，想通过秒杀来吸引一波流量，结果双十一当天功能刚上线就系统宕机，消费者各种投诉、网上各种舆论，至此这家电商到现在再没搞过此类秒杀业务。

1.2 峰值业务稳定场景：

流量激增情况下，比如像双十一这样的大促，系统如果没有做好相关的准备，很容易被用户流量冲垮，导致公司业务受损，目前业内普遍通过全链路压测提前模拟流量激增场景，来增强系统的承载能力。

1.3 系统容量规划场景：

成本优化，对系统进行精细化的容量规划。无论是新系统上线还是大促场景，都会遇到容量规划的问题，目前容量规划更多是结合平常系统性能表现以及预计用户流量按照经验去规划，但这种规划一般无法做到精准容量评估，一种是评估多了，造成机器浪费，一种是评估少了造成线上故障，对业务造成影响。

1.4 系统可用性探测场景：

探测系统的可用性，提升系统的整体服务能力和吞吐量。全链路压测另外一个典型用场景就是通过模拟真实的用户流量压力，去探知系统的性能瓶颈，从而提升系统的整体服务能力和吞吐量，提升用户体验。

2. 全链路压测有什么好处

2.1 保障重大活动的系统稳定性

避免公司业务和声誉因为技术故障受到损失，为技术团队赢得业务团队的尊重。

2.2 精准的容量评估

帮助公司用最低的成本满足业务的性能要求

2.3 重大项目重构切换前的性能验证

系统重构是IT部门场景的技术更新的方法，每次上线都需要经历一段阵痛期，期间性能问题、业务故障频发，用户投诉频繁。通过全链路压测可以在正式切换前完全解决性能问题；配合自动化的用例梳理和人工验证，可以极大程度降低业务故障。两者配合使用，可以快速的渡过不稳定期，提升用户体验。

2.4 端到端的全链路巡检，第一时间发现故障并快递定位问题

常见的监控体系通过一些间接的指标来判断是否有故障发生（比如通过CPU利用率、内存使用率、应用的错误日志数量、业务单量和基线的对比等等方式），间接的方式会产生大量的误报，造成告警麻痹症，真的故障发生后不一定能第一时间引起重视。

通过全链路压测提供的数据隔离功能，可以在线上通过压测流量验证真实的业务接口是否能正常工作。这种方式可以直接在用户发现业务故障前，让相关人员第一时间知晓。配合链路的监测分析功能，快速定位问题应用所在。经过验证该方法在客户真实环境中比传统监控方法平均提前7分钟发现故障，告警正确率是传统告警方式的几十倍。

2.5 建立公司的性能运营体系，将运动式的性能优化演化为自发的日常性能优化

很多公司都有运动式或者故障驱动的性能优化经历，比如马上要双十一，总监牵头开始性能优化；有人管的时候性能表现很好，一旦没人牵头做性能优化的事情，又会有很多性能问题被暴露出来。这样的方式通过优化效率很低，投入还大。

2.6 通过全链路压测的方式，配合目标制定、绩效和工单系统。

自动化的全链路压测可以日常化的排查性能瓶颈，通过工单将问题直达负责人，极大的提升性能优化的效率，将性能问题控制在萌芽状态。

3. 为什么选择线上环境而不是测试环境

2013年阿里云提出了通过影子表、影子库等技术来实现全链路压测的概念，对集团的所有的中间件、核心应用针对性的做了改造，使其具备支撑全链路压测的能力。影子表能力可以让压测产生的写入数据全部都隔离到其他区域，不影响生产数据，应用升级中间件后就自动具备了这个能力。为了解决商业压测工具不能提供超大瞬间流量的问题，阿里自研了压测流量产品，通过分布在全国各地的CDN机器，同时发起超大并发流量，对集团内部应用进行全链路压测。通过模拟双十一相同的生产集群、流量模型、流量规模的方案，来提前验证系统是否具备支撑双十一的高压能力，从而保障了阿里双十一的稳定运行。

理想情况下，如果测试环境想跟线上环境完全一致，软硬件都一致，是可以做到的。但是为了保持完全一致，机器成本、维护成本、数据同步都需要大量的支出，所以这也要根据公司情况来衡量。如果用线上环境直接做压测的话就不需要机器与维护成本了，但是难点在于对技术的要求比较高。

4. 线上环境压测要注意哪些问题？

一般在线上直接做压测会遇到以下几个问题：

1. 环境问题：生产环境与性能测试环境，单机配置与节点配置差异较大，导致最终结果会产生偏移；适合性能环境的中间件、JVM、web容器配置不一定适合生产环境。

2. 数据流向问题：单个场景与混合场景测试，数据流会形成断层，不具备流转性，压测数据模型不够完善。

3. 真实性问题：性能测试环境压测，硬件配置差异、数据差异、中间件配置差异，最终导致流量预估与压测结果的偏移，不够贴近真实。

4. 成本问题：多个系统性能测试环境占用的硬件资源较大，若实现生产压测，可有效释放对应硬件资源。

5. 如何开展全链路压测呢？

先说一下大概的一个流程，从准备阶段到开展部署实施到最后的上线。然后，拿其中的两个难点作为案例给大家重点介绍一下。

5.1 压测前：

• 压测范围：明确压测目标、梳理压测链路

• 业务系统改造：业务系统接入压测探针进行压测改造

• 压测方案：制定整个压测计划、压测数据构造、压测流程、紧急预案、监控指标等

• 压测管理：压测相关配置，如：压测任务、施压配置、SLA配置、压测指标配置等

• 压测验证：验证压测是否按照预期正常运行

5.2 压测中：

• 压测实施：执行压测任务、观察压测中运行状态等

• 压测监控：关注基础监控、业务监控等

• 紧急处理 ：压测中遇到的紧急问题处理如：数据污染、压测标识丢失、集群告警等

5.3 压测后：

• 压测报告：压测后产生的压测性能分析报告

• 压测数据清理：将压测数据还原到压测之前，为下次压测作准备

• 压测复盘：复盘整个压测过程中的问题，提升压测效率

5.4 难点之一：线上环境如何构造压测流量？

全链路压测需要最大程度的模拟正式业务环境下的流量，我们需要考虑到几个问题，比如请求数据如何构造，以及请求数据的多样化等。

举个例子，我们压测【下单】链路，需要尽可能模拟真实用户的下单情况，比如流量要与真实用户分布类似来自全国各地，以及购买各式各样的商品，还有访问下单的不同渠道，有时候甚至需要考虑用户的终端设备等。目前数列科技ForceCop在构造压测流量主要有两种方式：

2. 录制回放：收集某个时间段的正常业务数据，然后通过清洗敏感信息，最后加上压测标记去运行，达到最高程度的模拟正式业务场景，确保数据的真实性、多元化，以及场景覆盖的完整性。

5.5 难点之二：如何进行数据隔离？

1. 流量染色：构造压测流量时，将压测标记加入到压测流量中进行流量染色，比如页面发起的http请求，我们会在http请求的消息头里面加入压测标记。

2. 压测标记传递：当压测流量流经业务链路时，会经过很多事先被植入过压测探针的应用。当压测流量经过这些应用时，会被应用里的探针识别出来，并且会携带这些压测标记继续传递下去。比如压测流量经过Dubbo服务时，探针会把压测标记放到Dubbo的上下文中。

3. 压测数据存储：压测流量最终会持久化到数据库、缓存、消息中间件等，当压测探针识别到压测流量要持久化，就会将压测流量持久化到对应的影子区域。比如数据库会持久化到影子库或者影子表中、消息会写到影子topic中。

6. 数列全链路压测Forcecop产品优势

1）不需要对系统代码进行改造

因为对市面上主流的中间件都做了兼容支持，业务团队只需要将Agent协助部署到应用系统中，就可以完成全链路的梳理和接入了。

2）压测数据与正式数据的安全隔离

通过给压测流量染色、白名单核验机制、压测试跑，Agent会识别压测流量并对压测流量进行特定逻辑处理，将产生的压测数据存储到影子库表里，从而实现了与正常的业务数据的物理隔离。

3）低性能损耗

据我们以往经验，整套Agent植入后只会占用机器3%~5%的性能资源，而且产品特地设计了开关控制，可以全局控制压测是否需要启动。 在不需要压测时候关闭压测，这样就可以实现几乎0性能损耗。

4）自动梳理链路

应用链路往往复杂而多变，人工梳理费时费力准确度还不高。但准确的链路关系却是全链路压测实施的前提。因此数列全链路压测产品提供自动化的链路梳理功能，自动识别应用入口下的所有链路信息，告别人工梳理链路时代。

5）智能SLA警示/终止

即使做好万全准备，压测仍不能避免万无一失，数列全链路压测产品提供智能SLA规则，提前设置好预警与终止规则，当压测过程中触发SLA规则时，系统会自动进行警示或立即终止压测，防止造成额外损失。

6）压测报告

压测报告有针对性的对业务活动指标进行描述，如性能警告、请求总数、最大并发数、TPS、平均RT、SA等，对不同的业务活动进行实际与目标值对比，对峰值情况进行说明。绘制压测业务场景的TPS、平均RT、请求成功率实时趋势走向图。

7）可视化控制台

目前控制台的功能（压测自动化）包含压测配置、压测控制、压测实况、压测报告、链路梳理、压测管理、性能监控、性能分析等模块，用户仅通过页面点击即可完成一系列的压测配置，一站式全自助进行性能环境或者生产环境下的全链路压测。

7. 数列已落地的全链路压测方案

目前数列的全链路压测产品Forcecop被运用在申通快递、德邦物流、某985高校、爱库存、广州考试院、coty CRM等多个企业，下面举两个例子、来简要说明实施后的效果。

案例一：某头部物流

双十一前夕对申通的「核心订单平台」和「巴枪系统」系统进行多轮全链路压测，包括链路探活、链路监控和架构治理等自动梳理监控加快了排查的效率，降低业务峰值延迟，发现并解决了系统中的30多个性能问题，如：订单生成错误率过高、订单解析文件堆积和自动分拣系统吞吐量不足等，从而保障了双十一的稳定运行。

案例二：某985高校

疫情期间，据统计该校共开设了700+在线课程，涉及近千个教学班。该校教育平台系统峰值最高qps高达1w+，是平时峰值的100倍左右。分别在三个不同的场景共发现高风险性能问题49个，压测前后成功率从74%提高到100%。这些问题的解决有效的保障了疫情期间单日数百万访问量的系统稳定。

案例三：某头部电商

某电商平台实施全链路压测方案之前，每次日常活动和店庆大促都会遇到系统性能故障，仅2019年11月就出现2次缓存引起的故障，每次数小时。秒杀系统更是研发团队烫手山芋，秒杀上线系统崩溃，推广效果大打折扣。实施生产全链路压测后，研发团队借助这款压测“核武器”有效的对整体系统性能进行压测优化，今年的店庆大促成功抗住活动时的高并发流量，是日常峰值4倍以上。研发负责人反馈“这下心里有底了，喝着茶就能轻松应付店庆大促”

案例四：国内知名某金融科技

据统计，该金融科技公司2019年交易订单金额2.1万亿，面对如此庞大的交易量，整体技术架构面临前所未有的调整。通过在核心系统多条链路接入全链路压测，依靠自动化输出可视化报告分析性能瓶颈进行针对性优化，平台系统峰值TPS提升20%，并能做到持续的系统性能整体管控，目前该公司的业务交易系统能够轻松应对交易洪峰，让客户的支付更加高效、安全

案例五：某省考试院

某省考试院，2019年学生报考系统在报考高峰期间崩溃，影响了教育考试报名工作的进行。后面引入数列生产环境全链路压测解决方案，前后进行4次压力测试，发现了考生报名系统中登录、考生报考、报考确认链路中20多个性能问题，并在链路优化后进行反复压测验证。最终被压测的链路性能表现明显提升，能在高峰时期同时满足10万考生报考的系统性能需求，并且响应时间控制在100ms以内。

关于数列科技

数列科技（http://www.shulie.io/），一家专业的数字化公司，致力于帮助客户实现数字化转型。公司推出全链路压测产品、智能回测测试产品、IT数字化运营管理等数字化运营的专业咨询服务和行业解决方案，共同打造一体化的高可用IT质量保障平台。无需业务系统改造即可在生产环境进行安全压测，帮助客户解决生产环境的性能优化、容量评估、自动性能回归测试与IT团队质量管理协同等难题。目前，已经赢得顺丰快递、浙江大学、爱库存、中移金科、永辉超市、广东考试院等众多领先企业或高校的认可。