技术分享 | 悬镜周幸讲解《云原生下的IAST落地实践》
作者: 日期:2021年09月16日 阅:6,388

云原生技术成为近年来炙手可热的话题,是业务创新发展的重要驱动力。随着云原生产业规模不断扩大,云端应用在整个生命周期中的每一个阶段都面临着不同的安全挑战,企业需要在安全的架构下设计DevOps流程与工具。

内容摘要

  1. 云原生概述
  2. 云原生下的应用安全
  3. IAST简介
  4. IAST结合容器化和微服务
  5. IAST结合DevOps流水线
  6. 思考与展望

图:悬镜安全合伙人、华东区技术运营负责人周幸

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探针、流量代理/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 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功能,在上线后的环节做安全防护,实现运行时自我保护机制。


相关文章