前言：
本文主要记录了58集团和火线洞态联合共建58云原生应用场景下安全产品部署前设计监控降级方案全过程，帮助58保证安全检测的可用性及稳定性。
No 1
58集团简介
58集团是国民服务大平台，是国内专业的“本地、免费、真实、高效”生活服务平台，为了保障企业产品和用户安全，58集团信息安全部从公司安全架构层面开始逐步实践SDL落地“安全左移”，努力在应用发布到线上之前就将安全漏洞发现并修复，用最低的成本解决安全漏洞的问题。
No 2
58为什么选择洞态
目前，58集团先后完成了DAST、SAST的建设，为了实现更细粒度的漏洞检测和纵深检测，21年Q4开始着手发起IAST项目。
DAST是效果比较直观成本相对较低的检测手段，但缺点很明显：覆盖率不足且会产生脏数据引起业务问题。
SAST相对来说成本高一些：因为国内没有运营成本比较低的白盒产品；从事静态分析的人员也比较少，很难培养合适的安全人员；最重要的是白盒会产生很多误报，这类误报的过滤也会带来一些额外的人力、信任成本。
58安全部门希望拥有一个准确度高覆盖面广，方便测试融入安全的安全测试工具，在项目上线前对应用进行安全检测，而IAST正好可以满足。
IAST是介于黑白盒之间的产品，依赖测试请求，同时又使用污点分析进行漏洞建模。优点是误报率相对较低，不会产生脏数据。
伴随上述问题，58开始对IAST类产品进行了相关的调研。通过调研发现洞态比较符合58集团业务的需求。
1.洞态被动插桩式检测。不需要额外的fuzz流量，获取应用中的数据流和控制流进行污点分析。
2.开源。可自主使用，社区可反馈安全策略，保证漏洞覆盖的广度和深度。
3.轻Agent重服务端。Agent端只负责数据采集，对业务影响相对较小。
4.联合开发定制化功能。58内网测试服务对稳定性要求极高，安全产品的部署需优先保证业务方服务的可用性及稳定性，因而需要设计监控降级方案。
经过双方多次沟通，最终决定联合开发解决在58场景里最关心的稳定性相关问题。
No 3
联合共建全过程
上面提到了58最核心的需求，所以双方联合开发的内容主要是对洞态开源内容的稳定性、降级方案进行了设计和改造。
1、业务分析
双方根据58的应用场景，确定需求范围(同样用例分析也是)，58希望系统提供什么样的服务，以及58需要为系统提供的服务，以便容易理解这些元素的用途，也便于58软件开发人员最终实现这些元素。
58经过和洞态团队的深入沟通，花了3个月制作了容灾降级方案，这里只做简单的描述，下图是结合58业务场景设计图。
△agent监控用例图
//监控上报
1.本地JVM性能监控
未触发熔断，随PerformanceMonitor执行周期(默认60s)进行上报；触发熔断，放入。
REPORT_THREAD线程池排队上报。
2.访问请求监控
触发被判断为高频请求限流时，放入
REPORT_THREAD线程池排队上报。
3.agent数据收集监控
hook点命中被判断为高频hook限流/超时hook错误率达到阈值时，放入
REPORT_THREAD线程池排队上报。
4.agent异常监控
异常触发时，放入
REPORT_THREAD线程池排队上报。
2、业务流程
活动之间不仅有严格的先后顺序限定，而且活动的内容、方式、责任等也都必须有明确的安排和界定，以使不同活动在不同岗位角色之间进行转手交接成为可能。活动与活动之间在时间和空间上的转移可以有较大的跨度。
双方根据58业务实际需求，针对下方6种执行流程进行了重新设计。
- 洞态守护线程监控器执行流程部署配置
- 高频hook限流执行流程
- 高频请求限流执行流程
- 性能监控熔断执行流程
- 异常监控降级执行流程
- 服务端下发指令降级执行流程
3、业务实体状态图
状态机用于对模型元素的动态行为进行建模，更具体地说，就是对系统行为中受事件驱动的方面进行建模。状态机专门用于定义依赖于状态的行为（即根据模型元素所处的状态而有所变化的行为）。
△性能熔断开关状态机
其行为不会随着元素状态发生变化，模型元素不需要用状态机来描述其行为（这些元素通常是主要负责管理数据的被动类）。
4、58场景系统设计
1）应用容器架构
应用容器架构定义了单个应用由哪些组件或服务构成，是关于应用容器内组件的逻辑分组。目的是将职责进行分解，分配给不同的组件，保证每个组件职责单一，进而控制和管理整体的复杂度。
△洞态系统架构
2）应用交互时序图
应用间交互时序图是一种流程建模，描述了应用之间交互的顺序，将交互行为建模为消息传递，通过描述消息是如何在应用间发送和接收，来动态展示应用之间的交互。相对于其他UML图，时序图更强调交互的时间顺序，可以直观的描述交互的过程。
△洞态JavaAgent(v1.3.0)启动流程图
除了针对58应用场景的容器架构和交互顺序流程建模设计，此外还对数据库、ES等存储方式进行了设计。
58和洞态经历了4个月研发，核对了agent端5千行代码，调整服务端3千多行代码，双方经过50次讨论，形成了20篇技术文档，最后完成符合58应用场景的设计。
当然，过程中也遇到了困难。测试的过程中，各种agent降级失败，服务端无法收到对应数据，经过双方联调测试后，最后成功部署，进而又做了大规模部署的高性能方案。
No 4部署后测试效果
基于以上所考虑的问题点，在经过部署后，进行深入调研测试。
1）测试环境
| Agent版本 | 1.7.0 |
| 靶场 | DongTai-JavaAgent-Benchmark |
| 软件配置 | MySQL v5.7, Redis v6.2.5, Jmeter v5.4.1 |
| 操作系统 | Ubuntu |
| CPU | 16 核 |
| 内存 | 32 G |
2）测试场景
测试用例：DongTai-JavaAgent-Benchmark
此用列包含 Spring Boot, Spring MVC, JDBC Template 和 Redis Template。
测试接口会单次查询 MySQL 和多次查询并插入 Redis 数据。
并发量: 1，25，50，100，500，1000，5000
测试场景: 未插桩/插桩代理的应用运行
测试标准: 平均响应时间、响应中位数、吞吐量、CPU占用、内存使用
3）熔断降级配置
单请求 hook 限流：1000 次
每秒处理请求数（QPS）：3000 次
系统 CPU 阈值：90 %
JVM 内存阈值：90 %
单请求 hook 限流：限制单个请求内每秒hook数量
高频流量限流：每秒限制处理请求数量（并发量）
4）测试结果
- 平均响应时间（ms)
- 响应中位数（ms）
- 每秒事务数(TPS)
- CPU使用率（%）
- 内存使用率（%）
No 558生产环境效果
在实际生产环境部署上，经过测试总结出洞态在58应用场景下的优势主要有3点，很好的帮助58解决业务的安全问题。
1.洞态轻代理、重服务器的架构
代理只负责采集和发送数据，服务器则负责分析与识别漏洞, 每当并发量增高时，由于洞态优秀的架构设计和可预先添加熔断策略与阈值，即保证了Agent的稳定运行又不会影响到测试服务的正常运行。
2.洞态熔断降级功能避免对业务产生影响
在测试环境中，依然会存在对应用进行压力测试的情景，如果在压测时应用依然安装了洞态 的 agent，会导致压测结果严重失真。使用“熔断降级” 功能，设置“高频流量限流”可以避免压力测试时 agent 对业务产生影响。
3.洞态熔断降级功能可针对接口进行限流控制
高频访问数据库的接口在安装了agent后导致响应时间过长，是因为对hook点高频访问造成的。使用“熔断降级” 功能，设置“单请求hook限流”可以针对接口进行限流控制。
洞态已经成为58集团众多的业务场景下研发和测试阶段不可缺少的检测工具，未来洞态将提供开发标准化，灵活的服务端数据接口和跨应用问题的解决方案。
近期评论