| 编辑推荐: |
本文主要讲解了云原生概述、云原生下的应用安全、IAST简介、IAST结合容器化和微服务及IAST结合DevOps流水线等。
本文来自于微信公众号安世加，由Linda编辑、推荐。 |
|
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 Part 3：IAST简介
IAST（交互式应用程序安全测试工具）帮助企业解决走向云原生过程中的安全工具选择难题。传统的AST工具有SAST（白盒）和DAST（黑盒），IAST又叫做灰盒，是由Gartner提出的新一代交互式应用程序安全测试方案。
IAST工具通过服务端部署Agent探针、流量代理/VPN或主机系统软件等检测模式，收集、监控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 Part 4：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 Part 5：IAST结合DevOps流水线
DevOps是从左向右流水线式的进行，IAST工具主要应用在测试阶段。当把插桩的agent结合环境部署到测试环境，完成API
Test或者手动测试后，IAST即以插桩或者API对接的方式对接到DevOps流水线上。这样在完成功能测试时，IAST检测的结果也可以同步展示在流水线当中。
此外，因为DevOps流水线在很大程度上采用自动化的运转方式，对此IAST工具可以设置安全阈值或质量阈值，安全团队可以在完成流水线测试环节之后，根据IAST返回的漏洞数量、漏洞类型，以及中高危漏洞的整体占比，来判断DevOps流水线能否发布到预生产环境。
通过IAST工具进行漏洞检测的好处在于，相较于传统安全工具的检测时间长、误报率高等问题，IAST的检测模式结合DevOps流水线，能快速地在应用上线前对漏洞进行定位以及修复。
IAST嵌入DevOps流程有四大优点：
第一，全流程自动化，安全插件无缝嵌入到DevOps流程。
第二，同步收集流量并精准定位到代码行，指导研发修复。
第三，安全性的质量卡点，设置极限安全的质量阈值，直接阻断流水线，减少安全漏洞流转到上线后。当流水线在测试阶段被检测出不符合预先设置的质量卡点，检测报告将返回到开发人员，开发人员依据报告进行快速的定位和修复。
第四，完善安全开发工具链，IAST是DevOps流水线中的一个环节，它能与流水线上的其他类型工具结合，比如第三方组件检测、容器安全检测等工具，共同构建完整的安全开发流程体系。
06 Part 6：思考与展望
随着云原生的推进，以及应用逐步实现微服务的改造之后，对于IAST交互式应用安全测试工具也提出了更高的要求。
首先，多语言多场景的覆盖。当前企业以Java作为开发语言偏多，但不排除后端还有保存着如Python、PHP、.net等。因此除了Java之外，IAST工具需要提升对主流语言的覆盖能力。同时还应实现全场景支持，除了基于语言的插桩检测模式，还应支持流量或其他检测方式，以覆盖更多的业务场景。
其次，随着容器化、微服务化、分布式等技术的推进，基于IAST的插桩原理，除了测试安全漏洞，还应该具备深度挖掘微服务框架下API接口的能力。例如当应用采用微服务架构，测试人员对API接口发现不全，此时基于插桩的原理，可以对API接口进行挖掘分析，测试出安全或功能的API覆盖率等，提供给测试人员、开发人员和安全人员。
最后，云原生下的一体化探针。云原生下传统安全工具WAF（Web应用防火墙）的规则设定已不能适应当前环境多变、漏洞多变的情况，由此可以引入RASP安全解决方案。当频繁发版时，测试阶段以IAST插桩探针检测安全漏洞，并在保证应用安全的前提下，将短时间内无法修复的安全漏洞流转到上线后，测试阶段的插桩探针能够携带到上线后开启RASP功能，在上线后的环节做安全防护，实现运行时自我保护机制。 |
