云原生技术成为近年来炙手可热的话题，是业务创新发展的重要驱动力。随着云原生产业规模不断扩大，云端应用在整个生命周期中的每一个阶段都面临着不同的安全挑战，企业需要在安全的架构下设计DevOps流程与工具。
内容摘要
- 云原生概述
- 云原生下的应用安全
- IAST简介
- IAST结合容器化和微服务
- IAST结合DevOps流水线
- 思考与展望
图：悬镜安全合伙人、华东区技术运营负责人周幸
01 云原生概述
云原生计算基金会（CNCF）的定义：
- “云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。
- 云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式API。目前大家比较常用的可能是容器、微服务。
- 云原生对技术也提出了一些要求。它要求这些技术能够很好地构建容错性好、易于管理和便于观察的松耦合系统。
- 云原生下要结合现有可靠的自动化手段，使工程师们能够轻松地对系统作出频繁和可预测的重大变更。
云原生应用的三大特征：
第一，容器化封装。不同于以往应用运行在云主机、虚拟主机上，随着容器化的推广，允许应用以容器为基础，在容器中运行，同时可以结合微服务，作为应用程序部署的独立单元。
第二，动态管理。通过集中式的编排调度系统来动态的管理和调度，比如常见的K8s。
第三，面向微服务。明确服务间的依赖，相互解耦。以往通过前端应用和后端服务结合提供相应的功能，比如点击一个页面，从请求到响应，所有功能集成在一个后端应用完成，而现在通过微服务将原有的功能切割成模块化，形成微服务模式。
为了实现云原生应用的三个特征，云原生需要四种能力：
首先，应具备提供微服务的能力，应用之间通过RESTful API的方式进行通信，在按功能和模块划分之后，将原有的应用进行解耦合，使服务具有更强的去耦合凝聚力。
第二，相比以往只发布单个或少量应用，现在会发布N个模块化的微服务应用，需要引入自动化工具进行集成。DevOps或CI/CD工具能快速部署到生产环境，让开发和运维协同工作。
第三，将应用拆分之后，每个模块的功能上线都会变得更加频繁，因此需要具备持续交付的能力，以应对频繁发布、快速交付、快速反馈，并降低发布风险。
最后，微服务需要一个载体，而最佳的载体就是容器化。
02 云原生下的应用安全
云原生下的四大应用安全风险：
第一，API。传统的应用通过Web请求->响应，在点击页面后，通过后端响应直接返回相应内容。现在转向云原生微服务化后，更多的是API从请求->响应。而无论是微服务架构还是云原生下的应用，均来源于传统应用，因此也带有传统应用的安全风险。同时由于API性质的转变，也会带来API相应的风险。
第二，DevOps。随着自动化工具CI/CD或DevOps的引入，加速了应用发布流程。因此，留给安全人员和开发人员用于发现和修复问题的周期也随之变短。
第三，微服务。当应用改造成容器化微服务之后，服务数量激增。虽然对外提供的仍是同一个应用，但由于改造之后应用微服务的数量会出现“一对N”的情况，安全质量控制从一个应用的安全问题转变成多个微服务问题。
第四，人为因素。无论是传统应用，还是拆分模块化之后的应用，人为因素都是影响应用安全的重要一环。特别是当传统应用拆分为微服务之后，可能导致各个模块被交给不同开发组进行开发的情况，最后再将不同模块封装成为一个应用。而每个模块功能开发者的安全编码规范、安全意识并不统一，从安全团队的角度来讲，需要统一规范各个模块的安全编程质量。
在企业让应用走向云原生的过程中，也面临四点问题：
第一，安全人员配比问题。当前在企业中，相对于开发人员，安全人员的配比相对较低。随着云原生应用的推进，安全人员的压力也越发明显。相较于以往只需维护管理几个应用的安全问题，在应用被拆分为不同模块后，维护管理安全工作变得分散，同时因为整体的交付加速，安全人员的压力倍增。
第二，应用开发质量问题。当前企业的开发团队一般由自有团队和外包团队构成，企业希望通过安全培训来固化团队的安全能力，但由于外包人员流动性较大，安全能力培养无法固定，安全开发水平参差不齐，导致每次交付的安全质量不能得到保证。
第三，有效的安全工具问题。当前多数企业缺少一整套有效的安全工具，以往基于传统应用使用的安全工具很难契合云原生下的DevOps流程，对云原生下的微服务、分布式等新型框架的检测能力有限。
第四，安全合规化问题。上级监管单位的审查，以及近期《网络安全法》、《关键信息基础设施安全保护条例》、《个人信息保护法》、《数据安全法》等一系列相关法律法规的陆续颁布、实施，对应用安全提出了更高的要求。
基于当前应用现状和面临的安全风险情况，企业在选择安全工具时，应主要考虑解决四个问题:
第一，无缝嵌入开发流程。现有的安全是为了服务于开发，如果企业已具备DevOps流程或CI/CD工具，那么安全手段和安全工具应当能契合云原生应用的DevOps开发模式。
第二，随着容器化、微服务以及分布式的推进，安全工具要能应对和检测云原生框架下的API、微服务以及分布式架构。
第三，检测更快、更加无感知。随着DevOps以及微服务的推进，都要求检测工具能在更加快速的同时减少人员参与，以避免干扰现有的应用发布流程。
最后，应用迭代周期缩短，安全工具的检测结果要更具有指导性。当漏洞发生时，留给开发人员的修复时间非常有限，这就要求工具提供的安全检测结果能对开发人员具有指导意义，帮助他们在更短的时间内定位问题和修复问题。
03 IAST简介
IAST（交互式应用程序安全测试工具）帮助企业解决走向云原生过程中的安全工具选择难题。传统的AST工具有SAST（白盒）和DAST（黑盒），IAST又叫做灰盒，是由Gartner提出的新一代交互式应用程序安全测试方案。
IAST工具通过服务端部署Agent探针、流量代理/虚拟专用网络或主机系统软件等检测模式，收集、监控Web应用程序运行时的函数执行、数据传输，并与扫描器端进行实时交互，能高效、准确地识别安全缺陷。其检测漏洞覆盖主流OWASP Top 10以及 CWE Top 25等漏洞。同时，还能准确定位到漏洞所在的代码文件、行数、函数及参数。简单来说，IAST兼具了白盒检测定位代码行、黑盒及时反馈流量的能力。
悬镜安全认为，在IAST的实践中，为了全面覆盖应用场景，除了基于语言本身支持主动、被动插桩检测模式外，还应该支持流量检测模式，包括实时Web日志分析。
IAST的使用主要集中在软件开发的测试阶段。图中所示完整的软件开发流程包括从需求建立、研发编码、拉取代码、结合Jenkins等自动化集成工具，然后进行自动化测试，提交到预发布环境，再到发布上线，其中在测试阶段引入IAST工具，可以在该阶段完成功能测试，在完成这些功能测试的同时，也完成了安全测试，整个过程不需要增加额外的人员参与。
IAST工具之所以能够在完成功能测试的同时完成安全测试，得益于两个核心功能。
IAST的核心功能之一：主动模式。主动模式又称为“交互式缺陷定位”，那么其中的“交互”对象是什么？以图示（上图左侧）为例，可以看到“扫描控制端”，在这个流程当中，当有了点击、访问之后，Web端能接收到请求流量，此时IAST工具与中间件集成，接收到相应流量，在对这些流量进行初步筛查后，将筛选流量发送到扫描控制端，扫描控制端会结合Payload进行数据流量重放。重放验证的过程中能根据请求和响应，以及函数代码执行流，判断其中是否存在安全漏洞。
IAST工具的主动模式支持漏洞复现。但当IAST的插桩Agent收集到流量之后，反馈到扫描控制端，在重放过程当中，一些类似于签名、加密接口，或时效性较短的接口，在重放过程当中存在失效的可能，导致无法做对应的验证。而其好处在于，如果能够结合Payload进行验证并验证成功，其中存在的安全漏洞几乎可以100%被定位到。
IAST的另一个核心功能：被动模式，它主要引入了动态污点分析技术。动态污点分析分为三个阶段：污点输入、污点传输、污点汇聚。当一个请求流量输入后，会给变量打上污点标记，当变量携带着污点标记在整个函数内部流转时，就可以观察它经历了哪些函数，整个过程就是一个污点传播过程。
当在执行写库或写文件操作时，通过观察污点汇聚点携带的污点标记，代码执行流结合流量的请求和响应做最后的聚合分析，发现整个流程中是否存在安全漏洞。
通过这种方式可以发现，整个流程当中没有扫描控制端，从点击到响应的过程非常短，同时在不知不觉中进行了完整的安全检测。动态污点分析不需要数据重放，也就意味着其中不存在脏数据，并且对API接口、签名和加密接口等有非常好的处理效率和处理机制。整个过程在不引入第三方的情况下，直接利用原始的请求源，就能观察出从流量到整个函数的执行过程当中是否存在安全漏洞。
04 IAST结合容器化和微服务
如何实现IAST与容器化和微服务相结合？首先，从传统应用到当前的微服务架构发生了一些改变。以往可以通过前端与后端协作，后端一个集成应用提供所有服务，在请求访问时后端能够响应，之后再返回到页面进行展示，即完成了这一过程。而在微服务框架下，可以结合容器化对功能模块进行拆分，拆分之后，后端可以通过多个微服务程序去执行功能模块化。
传统的应用中，通过JVM无法直接执行.java或.class文件，但class文件可以通过class加载器在装载之后即可运行。以图示（上图）为例，原本一个JAR包通过JAVA-jar app.jar的方式即可执行。以此为基础，在class加载器之前，通过拦截修改class当中的内容，让程序去执行埋点逻辑，这就构成了插桩的基本原理。只需要在参数中加上javaagent agent.jar，即引入了插桩方式。
通过字节码插桩技术，使IAST结合容器微服务场景。以SpringBoot使用场景为例（上图），通过SpringBoot打包一个模块化的应用，之后结合容器即可部署上线。而当有了插桩的agent之后，agent.jar依赖于中间件上，打包后形成了每个容器里都携带着原始模块化的微服务小应用，也携带了插桩的agent。
从外部看起来仍是一个应用，只是在微服务框架下有不同的微服务程序。但从整体来看，agent收集到的不同流量都将反馈到同一应用上。所以悬镜灵脉IAST也是把微服务下收集到的不同安全漏洞归属到同一应用上，以应用的维度去看待整体的安全漏洞现状。
当插桩完成并进行打包之后，插桩的agent会随着应用启动而启动，静默等待流量输入。当功能测试开始时，插桩的agent就会在测试阶段持续观察和检测安全漏洞。
05 IAST结合DevOps流水线
DevOps是从左向右流水线式的进行，IAST工具主要应用在测试阶段。当把插桩的agent结合环境部署到测试环境，完成API Test或者手动测试后，IAST即以插桩或者API对接的方式对接到DevOps流水线上。这样在完成功能测试时，IAST检测的结果也可以同步展示在流水线当中。
此外，因为DevOps流水线在很大程度上采用自动化的运转方式，对此IAST工具可以设置安全阈值或质量阈值，安全团队可以在完成流水线测试环节之后，根据IAST返回的漏洞数量、漏洞类型，以及中高危漏洞的整体占比，来判断DevOps流水线能否发布到预生产环境。
通过IAST工具进行漏洞检测的好处在于，相较于传统安全工具的检测时间长、误报率高等问题，IAST的检测模式结合DevOps流水线，能快速地在应用上线前对漏洞进行定位以及修复。
IAST嵌入DevOps流程有四大优点：
第一，全流程自动化，安全插件无缝嵌入到DevOps流程。
第二，同步收集流量并精准定位到代码行，指导研发修复。
第三，安全性的质量卡点，设置极限安全的质量阈值，直接阻断流水线，减少安全漏洞流转到上线后。当流水线在测试阶段被检测出不符合预先设置的质量卡点，检测报告将返回到开发人员，开发人员依据报告进行快速的定位和修复。
第四，完善安全开发工具链，IAST是DevOps流水线中的一个环节，它能与流水线上的其他类型工具结合，比如第三方组件检测、容器安全检测等工具，共同构建完整的安全开发流程体系。
06 思考与展望
随着云原生的推进，以及应用逐步实现微服务的改造之后，对于IAST交互式应用安全测试工具也提出了更高的要求。
首先，多语言多场景的覆盖。当前企业以Java作为开发语言偏多，但不排除后端还有保存着如Python、PHP、.net等。因此除了Java之外，IAST工具需要提升对主流语言的覆盖能力。同时还应实现全场景支持，除了基于语言的插桩检测模式，还应支持流量或其他检测方式，以覆盖更多的业务场景。
其次，随着容器化、微服务化、分布式等技术的推进，基于IAST的插桩原理，除了测试安全漏洞，还应该具备深度挖掘微服务框架下API接口的能力。例如当应用采用微服务架构，测试人员对API接口发现不全，此时基于插桩的原理，可以对API接口进行挖掘分析，测试出安全或功能的API覆盖率等，提供给测试人员、开发人员和安全人员。
最后，云原生下的一体化探针。云原生下传统安全工具WAF（Web应用防火墙）的规则设定已不能适应当前环境多变、漏洞多变的情况，由此可以引入RASP安全解决方案。当频繁发版时，测试阶段以IAST插桩探针检测安全漏洞，并在保证应用安全的前提下，将短时间内无法修复的安全漏洞流转到上线后，测试阶段的插桩探针能够携带到上线后开启RASP功能，在上线后的环节做安全防护，实现运行时自我保护机制。
关于悬镜安全
悬镜安全，DevSecOps敏捷安全领导者。由北京大学网络安全技术研究团队“XMIRROR”发起创立，致力以AI技术赋能敏捷安全，专注于DevSecOps软件供应链持续威胁一体化检测防御。核心的DevSecOps智适应威胁管理解决方案包括以深度学习技术为核心的威胁建模、开源治理、风险发现、威胁模拟、检测响应等多个维度的自主创新产品及实战攻防对抗为特色的政企安全服务，为金融、能源、泛互联网、IoT、云服务及汽车制造等行业用户提供创新灵活的智适应安全管家解决方案。更多信息请访问悬镜安全官网：www.xmirror.cn。
