DevOps敏捷开发模式已被业界普遍认可并被广泛应用，同时伴随云原生技术的兴起，青睐采用容器编排解决方案来构建和管理应用的企业不胜枚举。但是，应用程序安全测试依赖运行时探针，采用容器编排方案同时也意味着可能存在百万甚至千万个节点，而这个量级的节点无疑为IAST后台探针承载量带来了巨大挑战。因此，IAST检测平台是否支持多种架构部署模式，能否确保每个应用程序能在上线前发现并解决漏洞问题，将成为决定 IAST 检测平台在 DevSecOps 下顺利落地的关键。
1、背景介绍
1.1 何为高可用、高并发
高可用HA（High Availability）是在分布式系统架构设计中，通过设计减少系统不能提供服务的时间，保障业务连续性。举例来说，以时间单位进行统计，系统每运行100个时间单位，如有1个时间单位无法提供服务，那么系统的可用性就是99%。
高并发HC（High Concurrency）是在分布式系统架构设计中，通过设计保证系统能够同时并行处理大量请求。它所涉及的指标有：响应时间（Response Time）、吞吐量（Throughput）、每秒查询率QPS（Query Per Second）、并发用户数等。
1.2?IAST为企业带来的价值
实践发现，单机部署IAST满足小规模应用日常测试没有问题，但是对于大部分IT建设程度完善、应用规模庞大的企业，则需要支持企业级分布式高可用架构，才能确保满足客户的正常测试需求。原因如下：
1）IAST探针技术是伴随应用进程启动的，为保证测试覆盖率，需要尽可能实现每个应用进程都加载探针。
2）CI/CD流水线借助容器发布，在敏捷开发模式下，如果每个子应用每天会发布10-20个迭代版本，那么对于1000个子应用规模的企业，探针至少需要同时支持3000-5000个子应用迭代版本的检测。如果再考虑子应用实际运行的进程实例，还需要支持更多探针同时在线。
3）IAST本身价值在于将安全测试前置到开发测试阶段，并且有个重要前提是，绝不能干扰开发测试过程。当开发测试过程出现意外情况时，难以要求开发测试重复流程，因此需要至少能保证每一个迭代版本的安全测试结果无丢失。
DevSecOps强调在自动化流程中的各个环节嵌入安全措施，IAST作为覆盖开发测试中应用迭代版本安全测试的关键技术，当企业业务应用系统的开发迭代量日趋庞大时，必然会给平台提出新的要求，那就是需要具备高可用、高并发能力。
作为国内IAST头部厂商，悬镜积累了丰富的IAST实践经验，服务行业广泛覆盖金融、能源、电信、互联网、车联网等领域，辐射多种业务场景及不同规模的客户群体。
2、方案实践
2.1 单机部署（小规模）
单机部署模式，适合企业小规模应用测试、低成本接入测试环节的需求。该模式部署不仅成本低，还支持迁移和扩展，可以作为IAST初步推广试点，用以评估效果和完善推广方案。
?
2.2?多引擎部署（中等规模）
多引擎部署模式，适合企业的中等规模应用测试需求。对于初具规模的CI/CD流水线发布流程，通过对接测试发布环境，方可应对部门或组织内部日常迭代版本的全部安全测试需求，赋能应用安全测试。
?
2.3?高可用部署（大型企业）
在成熟的DevOps体系下，大型企业应用发布的频率每月可达百万次。因此，在应对真实大规模应用迭代测试时，则必须使用高可用模式来满足测试需求。通过将各个关键平台组件分离分节点部署，保障在单一组件出现异常时，其他组件仍然可以正常使用。同时，高可用部署模式，也可适配异地多中心的场景。
?
3、用户场景案例
3.1 某大型物流公司
对于物流公司来说，跨地区业务是典型的特征。在某物流公司分拣平台系统的发布测试案例中，由总部的IT中心构建发布版本，向各区域下发应用包，区域承担部署验证测试任务，部分架构示意图如下：
?
在引入IAST时，不仅要考虑区域网段隔离，还应考虑不同地区之间收集数据难以汇总的问题。悬镜灵脉IAST采用地区分布式引擎中心+总控中心的模式，做到各区域数据不影响，数据统一集中管控，对安全问题进行汇总分析,部分架构示意图如下：
?
3.2?某大型电商网站
购物促销的热卖季对于电商网站来说是个大考验，由于电商类平台涉及到系统较多且复杂，如库存、订单、支付等，同时也对应用的并发处理能力要求极高。在某电商的架构中，采用微服务的架构，每一个微服务专注提供单一功能，部分架构示意图如下：
?
该模式下，每个单独模块发版频繁，多个应用多个模块同时上线测试，这对于IAST的并发处理能力要求极高。悬镜灵脉IAST构建数据中转集群，采用集群的方式收集、处理以及备份数据，实现高可用、高并发，部分架构示意图如下：
?
4、架构解析
4.1?Tendis（风险数据存储）
Tendis完全兼容Redis协议，支持Redis主要数据结构和接口，兼容大部分原生Redis命令。集群支持增删节点，并且数据可以按照 Slot 在任意两节点之间迁移，自动检测故障节点。当故障发生后，slave 会自动提升为 master 继续对外提供服务。
在实际部署中，最小高可用架构，建议使用3主3备的方式，并且注意数据读写方式，以及内存的占用控制。
4.2?Center（自研中心引擎）
Center模块是悬镜自研的中心引擎服务，支持分布式扩展，用于同时对接Scanner、Proxy、Collector等主要服务，通过协调各组件服务，实现资源动态分配、任务划分，支持提供检测能力弹性扩展。
4.3?Analyzer（自研数据分析引擎）
一般来说，对于漏洞检测类产品，从底层Agent发现应用漏洞时，再到上报平台处理，界面展示漏洞，整个过程需要尽可能达到实时。当应用规模较小时，比较容易实现，但是当应用达到一定规模，对数据进行在线处理时，漏洞信息从收集到展示的时间延迟则会放大数倍，从而导致信息获取严重滞后，可以想见负面后果的严重性。
悬镜通过自研Analyzer数据分析引擎，利用分布式处理机制的优势，对大并发上传的漏洞数据进行分析，且可进一步去重、关联分析、统计应用安全指标，保障数据展示实时性，确保能够将第一手风险告警及时投送给用户。
4.4?Scanner（自研风险检测引擎）
Scanner模块是悬镜自研的主动风险检测引擎，结合悬镜代理/VPN、流量镜像、主机流量系统、启发式爬虫等检测模式，主动发起POC探测，发现风险。Scanner模块在早期研发设计中，要求本身具备分布式扩展部署能力，因此天然适配高可用模式，可实现无缝衔接。
4.5?Kafka（风险数据收集）
Kafka常作为高吞吐低延迟的高并发、高性能的消息中间件，在大数据领域有广泛运用。配置良好的Kafka集群甚至可以做到每秒上百万的高并发写入。
IAST Agent探针基于应用运行时进行污点分析检测，将检测漏洞数据上报Center服务平台。建立Kafka集群服务，可以支持流水线中大量应用高速发布时，接收每个Agent上报的检测数据，确保不遗漏。
需要注意的是，某些客户环境下，Kafka部署环境和Agent部署环境隔离，会使用Nginx作为代理进行IP映射，因此需要特殊处理保证Agent连接正确Kafka。
?
结语
随着企业用户业务量的持续加码，高可用已成为迫切的、广泛存在的市场需求。因此，不仅仅是在物流、电商、线上支付等行业，越来越多的大型企业也更倾向于打通系统，采用分布式系统架构，把所有的风险项目展示出来，做统一的风险把控，实现系统的持续安全。
悬镜灵脉IAST平台在低误报、精准检测、高覆盖等方面已取得了具有行业领先性的技术突破。在对实际应用场景和业务开发语言的兼容性方面，灵脉IAST能够给与企业更加全面的支持。目前，在金融、能源、电信、互联网、车联网等行业的高并发场景中已广泛落地实施，具备典型的参考价值。悬镜灵脉IAST在业务开发语言兼容范围领跑行业的同时，已率先实现了千万级高并发业务场景、异地多中心等复杂业务场景的支持，可以有效地把应用威胁发现能力前置到开发测试环节，使安全工作能够柔和嵌入企业的软件开发体系，从源头上实现对上线应用项目的透明安全测试。
