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