前言:
本文主要记录了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监控用例图
//监控上报
NOCITCE
- 本地JVM性能监控
未触发熔断,随PerformanceMonitor执行周期(默认60s)进行上报;触发熔断,放入。
REPORT_THREAD线程池排队上报。
- 访问请求监控
触发被判断为高频请求限流时,放入
REPORT_THREAD线程池排队上报。
- agent数据收集监控
hook点命中被判断为高频hook限流/超时hook错误率达到阈值时,放入
REPORT_THREAD线程池排队上报。
- agent异常监控
异常触发时,放入
REPORT_THREAD线程池排队上报。
2、业务流程
活动之间不仅有严格的先后顺序限定,而且活动的内容、方式、责任等也都必须有明确的安排和界定,以使不同活动在不同岗位角色之间进行转手交接成为可能。活动与活动之间在时间和空间上的转移可以有较大的跨度。
双方根据58业务实际需求,针对下方6种执行流程进行了重新设计。
- 洞态守护线程监控器执行流程部署配置
- 高频hook限流执行流程
- 高频请求限流执行流程
- 性能监控熔断执行流程
- 异常监控降级执行流程
- 服务端下发指令降级执行流程
3、业务实体状态图
状态机用于对模型元素的动态行为进行建模,更具体地说,就是对系统行为中受事件驱动的方面进行建模。状态机专门用于定义依赖于状态的行为(即根据模型元素所处的状态而有所变化的行为)。
△性能熔断开关状态机
其行为不会随着元素状态发生变化,模型元素不需要用状态机来描述其行为(这些元素通常是主要负责管理数据的被动类)。
4、58场景系统设计
1)应用容器架构
应用容器架构定义了单个应用由哪些组件或服务构成,是关于应用容器内组件的逻辑分组。目的是将职责进行分解,分配给不同的组件,保证每个组件职责单一,进而控制和管理整体的复杂度。
2)应用交互时序图
应用间交互时序图是一种流程建模,描述了应用之间交互的顺序,将交互行为建模为消息传递,通过描述消息是如何在应用间发送和接收,来动态展示应用之间的交互。相对于其他UML图,时序图更强调交互的时间顺序,可以直观的描述交互的过程。
除了针对58应用场景的容器架构和交互顺序流程建模设计,此外还对数据库、ES等存储方式进行了设计。
58和洞态经历了4个月研发,核对了agent端5千行代码,调整服务端3千多行代码,双方经过50次讨论,形成了20篇技术文档,最后完成符合58应用场景的设计。
当然,过程中也遇到了困难。测试的过程中,各种agent降级失败,服务端无法收到对应数据,经过双方联调测试后,最后成功部署,进而又做了大规模部署的高性能方案。
No 4部署后测试效果
基于以上所考虑的问题点,在经过部署后,进行深入调研测试。
1)测试环境
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 5
洞态|58生产环境效
在实际生产环境部署上,经过测试总结出洞态在58应用场景下的优势主要有3点,很好的帮助58解决业务的安全问题。
1.洞态轻代理、重服务器的架构
代理只负责采集和发送数据,服务器则负责分析与识别漏洞, 每当并发量增高时,由于洞态优秀的架构设计和可预先添加熔断策略与阈值,即保证了Agent的稳定运行又不会影响到测试服务的正常运行。
2.洞态熔断降级功能避免对业务产生影响
在测试环境中,依然会存在对应用进行压力测试的情景,如果在压测时应用依然安装了洞态 的 agent,会导致压测结果严重失真。使用“熔断降级” 功能,设置“高频流量限流”可以避免压力测试时 agent 对业务产生影响。
3.洞态熔断降级功能可针对接口进行限流控制
高频访问数据库的接口在安装了agent后导致响应时间过长,是因为对hook点高频访问造成的。使用“熔断降级” 功能,设置“单请求hook限流”可以针对接口进行限流控制。
洞态已经成为58集团众多的业务场景下研发和测试阶段不可缺少的检测工具,未来洞态将提供开发标准化,灵活的服务端数据接口和跨应用问题的解决方案。
申请产品试用
领取白皮书资料
关于火线
火线安全是基于社区的云安全公司,主要运营洞态、火线安全平台、火线安全云和火线Zone云安全社区。
火线安全通过自主研发的自动化测试工具和海量的白帽安全专家,为企业提供可信的安全服务,助力企业解决应用生命全周期的安全风险。
热门跟贴