云原生技術(shù)成為近年來炙手可熱的話題，是業(yè)務(wù)創(chuàng)新發(fā)展的重要驅(qū)動(dòng)力。隨著云原生產(chǎn)業(yè)規(guī)模不斷擴(kuò)大，云端應(yīng)用在整個(gè)生命周期中的每一個(gè)階段都面臨著不同的安全挑戰(zhàn)，企業(yè)需要在安全的架構(gòu)下設(shè)計(jì)DevOps流程與工具。

內(nèi)容摘要

• 云原生概述
• 云原生下的應(yīng)用安全
• IAST簡介
• IAST結(jié)合容器化和微服務(wù)
• IAST結(jié)合DevOps流水線
• 思考與展望

圖：懸鏡安全合伙人、華東區(qū)技術(shù)運(yùn)營負(fù)責(zé)人周幸

01 云原生概述

云原生計(jì)算基金會(huì)（CNCF）的定義：

• “云原生技術(shù)有利于各組織在公有云、私有云和混合云等新型動(dòng)態(tài)環(huán)境中，構(gòu)建和運(yùn)行可彈性擴(kuò)展的應(yīng)用。
• 云原生的代表技術(shù)包括容器、服務(wù)網(wǎng)格、微服務(wù)、不可變基礎(chǔ)設(shè)施和聲明式API。目前大家比較常用的可能是容器、微服務(wù)。
• 云原生對(duì)技術(shù)也提出了一些要求。它要求這些技術(shù)能夠很好地構(gòu)建容錯(cuò)性好、易于管理和便于觀察的松耦合系統(tǒng)。
• 云原生下要結(jié)合現(xiàn)有可靠的自動(dòng)化手段，使工程師們能夠輕松地對(duì)系統(tǒng)作出頻繁和可預(yù)測的重大變更。

云原生應(yīng)用的三大特征：

第一，容器化封裝。不同于以往應(yīng)用運(yùn)行在云主機(jī)、虛擬主機(jī)上，隨著容器化的推廣，允許應(yīng)用以容器為基礎(chǔ)，在容器中運(yùn)行，同時(shí)可以結(jié)合微服務(wù)，作為應(yīng)用程序部署的獨(dú)立單元。

第二，動(dòng)態(tài)管理。通過集中式的編排調(diào)度系統(tǒng)來動(dòng)態(tài)的管理和調(diào)度，比如常見的K8s。

第三，面向微服務(wù)。明確服務(wù)間的依賴，相互解耦。以往通過前端應(yīng)用和后端服務(wù)結(jié)合提供相應(yīng)的功能，比如點(diǎn)擊一個(gè)頁面，從請(qǐng)求到響應(yīng)，所有功能集成在一個(gè)后端應(yīng)用完成，而現(xiàn)在通過微服務(wù)將原有的功能切割成模塊化，形成微服務(wù)模式。 

為了實(shí)現(xiàn)云原生應(yīng)用的三個(gè)特征，云原生需要四種能力：

首先，應(yīng)具備提供微服務(wù)的能力，應(yīng)用之間通過RESTful API的方式進(jìn)行通信，在按功能和模塊劃分之后，將原有的應(yīng)用進(jìn)行解耦合，使服務(wù)具有更強(qiáng)的去耦合凝聚力。

第二，相比以往只發(fā)布單個(gè)或少量應(yīng)用，現(xiàn)在會(huì)發(fā)布N個(gè)模塊化的微服務(wù)應(yīng)用，需要引入自動(dòng)化工具進(jìn)行集成。DevOps或CI/CD工具能快速部署到生產(chǎn)環(huán)境，讓開發(fā)和運(yùn)維協(xié)同工作。

第三，將應(yīng)用拆分之后，每個(gè)模塊的功能上線都會(huì)變得更加頻繁，因此需要具備持續(xù)交付的能力，以應(yīng)對(duì)頻繁發(fā)布、快速交付、快速反饋，并降低發(fā)布風(fēng)險(xiǎn)。

最后，微服務(wù)需要一個(gè)載體，而最佳的載體就是容器化。

02  云原生下的應(yīng)用安全

云原生下的四大應(yīng)用安全風(fēng)險(xiǎn)：

第一，API。傳統(tǒng)的應(yīng)用通過Web請(qǐng)求->響應(yīng)，在點(diǎn)擊頁面后，通過后端響應(yīng)直接返回相應(yīng)內(nèi)容?，F(xiàn)在轉(zhuǎn)向云原生微服務(wù)化后，更多的是API從請(qǐng)求->響應(yīng)。而無論是微服務(wù)架構(gòu)還是云原生下的應(yīng)用，均來源于傳統(tǒng)應(yīng)用，因此也帶有傳統(tǒng)應(yīng)用的安全風(fēng)險(xiǎn)。同時(shí)由于API性質(zhì)的轉(zhuǎn)變，也會(huì)帶來API相應(yīng)的風(fēng)險(xiǎn)。

第二，DevOps。隨著自動(dòng)化工具CI/CD或DevOps的引入，加速了應(yīng)用發(fā)布流程。因此，留給安全人員和開發(fā)人員用于發(fā)現(xiàn)和修復(fù)問題的周期也隨之變短。

第三，微服務(wù)。當(dāng)應(yīng)用改造成容器化微服務(wù)之后，服務(wù)數(shù)量激增。雖然對(duì)外提供的仍是同一個(gè)應(yīng)用，但由于改造之后應(yīng)用微服務(wù)的數(shù)量會(huì)出現(xiàn)“一對(duì)N”的情況，安全質(zhì)量控制從一個(gè)應(yīng)用的安全問題轉(zhuǎn)變成多個(gè)微服務(wù)問題。

第四，人為因素。無論是傳統(tǒng)應(yīng)用，還是拆分模塊化之后的應(yīng)用，人為因素都是影響應(yīng)用安全的重要一環(huán)。特別是當(dāng)傳統(tǒng)應(yīng)用拆分為微服務(wù)之后，可能導(dǎo)致各個(gè)模塊被交給不同開發(fā)組進(jìn)行開發(fā)的情況，最后再將不同模塊封裝成為一個(gè)應(yīng)用。而每個(gè)模塊功能開發(fā)者的安全編碼規(guī)范、安全意識(shí)并不統(tǒng)一，從安全團(tuán)隊(duì)的角度來講，需要統(tǒng)一規(guī)范各個(gè)模塊的安全編程質(zhì)量。

在企業(yè)讓應(yīng)用走向云原生的過程中，也面臨四點(diǎn)問題：

第一，安全人員配比問題。當(dāng)前在企業(yè)中，相對(duì)于開發(fā)人員，安全人員的配比相對(duì)較低。隨著云原生應(yīng)用的推進(jìn)，安全人員的壓力也越發(fā)明顯。相較于以往只需維護(hù)管理幾個(gè)應(yīng)用的安全問題，在應(yīng)用被拆分為不同模塊后，維護(hù)管理安全工作變得分散，同時(shí)因?yàn)檎w的交付加速，安全人員的壓力倍增。

第二，應(yīng)用開發(fā)質(zhì)量問題。當(dāng)前企業(yè)的開發(fā)團(tuán)隊(duì)一般由自有團(tuán)隊(duì)和外包團(tuán)隊(duì)構(gòu)成，企業(yè)希望通過安全培訓(xùn)來固化團(tuán)隊(duì)的安全能力，但由于外包人員流動(dòng)性較大，安全能力培養(yǎng)無法固定，安全開發(fā)水平參差不齊，導(dǎo)致每次交付的安全質(zhì)量不能得到保證。

第三，有效的安全工具問題。當(dāng)前多數(shù)企業(yè)缺少一整套有效的安全工具，以往基于傳統(tǒng)應(yīng)用使用的安全工具很難契合云原生下的DevOps流程，對(duì)云原生下的微服務(wù)、分布式等新型框架的檢測能力有限。

第四，安全合規(guī)化問題。上級(jí)監(jiān)管單位的審查，以及近期《網(wǎng)絡(luò)安全法》、《關(guān)鍵信息基礎(chǔ)設(shè)施安全保護(hù)條例》、《個(gè)人信息保護(hù)法》、《數(shù)據(jù)安全法》等一系列相關(guān)法律法規(guī)的陸續(xù)頒布、實(shí)施，對(duì)應(yīng)用安全提出了更高的要求。

基于當(dāng)前應(yīng)用現(xiàn)狀和面臨的安全風(fēng)險(xiǎn)情況，企業(yè)在選擇安全工具時(shí)，應(yīng)主要考慮解決四個(gè)問題:

第一，無縫嵌入開發(fā)流程。現(xiàn)有的安全是為了服務(wù)于開發(fā)，如果企業(yè)已具備DevOps流程或CI/CD工具，那么安全手段和安全工具應(yīng)當(dāng)能契合云原生應(yīng)用的DevOps開發(fā)模式。

第二，隨著容器化、微服務(wù)以及分布式的推進(jìn)，安全工具要能應(yīng)對(duì)和檢測云原生框架下的API、微服務(wù)以及分布式架構(gòu)。

第三，檢測更快、更加無感知。隨著DevOps以及微服務(wù)的推進(jìn)，都要求檢測工具能在更加快速的同時(shí)減少人員參與，以避免干擾現(xiàn)有的應(yīng)用發(fā)布流程。

最后，應(yīng)用迭代周期縮短，安全工具的檢測結(jié)果要更具有指導(dǎo)性。當(dāng)漏洞發(fā)生時(shí)，留給開發(fā)人員的修復(fù)時(shí)間非常有限，這就要求工具提供的安全檢測結(jié)果能對(duì)開發(fā)人員具有指導(dǎo)意義，幫助他們?cè)诟痰臅r(shí)間內(nèi)定位問題和修復(fù)問題。

03  IAST簡介

IAST（交互式應(yīng)用程序安全測試工具）幫助企業(yè)解決走向云原生過程中的安全工具選擇難題。傳統(tǒng)的AST工具有SAST（白盒）和DAST（黑盒），IAST又叫做灰盒，是由Gartner提出的新一代交互式應(yīng)用程序安全測試方案。

IAST工具通過服務(wù)端部署Agent探針、流量代理/虛擬專用網(wǎng)絡(luò)或主機(jī)系統(tǒng)軟件等檢測模式，收集、監(jiān)控Web應(yīng)用程序運(yùn)行時(shí)的函數(shù)執(zhí)行、數(shù)據(jù)傳輸，并與掃描器端進(jìn)行實(shí)時(shí)交互，能高效、準(zhǔn)確地識(shí)別安全缺陷。其檢測漏洞覆蓋主流OWASP Top 10以及 CWE Top 25等漏洞。同時(shí)，還能準(zhǔn)確定位到漏洞所在的代碼文件、行數(shù)、函數(shù)及參數(shù)。簡單來說，IAST兼具了白盒檢測定位代碼行、黑盒及時(shí)反饋流量的能力。

懸鏡安全認(rèn)為，在IAST的實(shí)踐中，為了全面覆蓋應(yīng)用場景，除了基于語言本身支持主動(dòng)、被動(dòng)插樁檢測模式外，還應(yīng)該支持流量檢測模式，包括實(shí)時(shí)Web日志分析。

IAST的使用主要集中在軟件開發(fā)的測試階段。圖中所示完整的軟件開發(fā)流程包括從需求建立、研發(fā)編碼、拉取代碼、結(jié)合Jenkins等自動(dòng)化集成工具，然后進(jìn)行自動(dòng)化測試，提交到預(yù)發(fā)布環(huán)境，再到發(fā)布上線，其中在測試階段引入IAST工具，可以在該階段完成功能測試，在完成這些功能測試的同時(shí)，也完成了安全測試，整個(gè)過程不需要增加額外的人員參與。

IAST工具之所以能夠在完成功能測試的同時(shí)完成安全測試，得益于兩個(gè)核心功能。

IAST的核心功能之一：主動(dòng)模式。主動(dòng)模式又稱為“交互式缺陷定位”，那么其中的“交互”對(duì)象是什么？以圖示（上圖左側(cè)）為例，可以看到“掃描控制端”，在這個(gè)流程當(dāng)中，當(dāng)有了點(diǎn)擊、訪問之后，Web端能接收到請(qǐng)求流量，此時(shí)IAST工具與中間件集成，接收到相應(yīng)流量，在對(duì)這些流量進(jìn)行初步篩查后，將篩選流量發(fā)送到掃描控制端，掃描控制端會(huì)結(jié)合Payload進(jìn)行數(shù)據(jù)流量重放。重放驗(yàn)證的過程中能根據(jù)請(qǐng)求和響應(yīng)，以及函數(shù)代碼執(zhí)行流，判斷其中是否存在安全漏洞。

IAST工具的主動(dòng)模式支持漏洞復(fù)現(xiàn)。但當(dāng)IAST的插樁Agent收集到流量之后，反饋到掃描控制端，在重放過程當(dāng)中，一些類似于簽名、加密接口，或時(shí)效性較短的接口，在重放過程當(dāng)中存在失效的可能，導(dǎo)致無法做對(duì)應(yīng)的驗(yàn)證。而其好處在于，如果能夠結(jié)合Payload進(jìn)行驗(yàn)證并驗(yàn)證成功，其中存在的安全漏洞幾乎可以100%被定位到。 

IAST的另一個(gè)核心功能：被動(dòng)模式，它主要引入了動(dòng)態(tài)污點(diǎn)分析技術(shù)。動(dòng)態(tài)污點(diǎn)分析分為三個(gè)階段：污點(diǎn)輸入、污點(diǎn)傳輸、污點(diǎn)匯聚。當(dāng)一個(gè)請(qǐng)求流量輸入后，會(huì)給變量打上污點(diǎn)標(biāo)記，當(dāng)變量攜帶著污點(diǎn)標(biāo)記在整個(gè)函數(shù)內(nèi)部流轉(zhuǎn)時(shí)，就可以觀察它經(jīng)歷了哪些函數(shù)，整個(gè)過程就是一個(gè)污點(diǎn)傳播過程。

當(dāng)在執(zhí)行寫庫或?qū)懳募僮鲿r(shí)，通過觀察污點(diǎn)匯聚點(diǎn)攜帶的污點(diǎn)標(biāo)記，代碼執(zhí)行流結(jié)合流量的請(qǐng)求和響應(yīng)做最后的聚合分析，發(fā)現(xiàn)整個(gè)流程中是否存在安全漏洞。

通過這種方式可以發(fā)現(xiàn)，整個(gè)流程當(dāng)中沒有掃描控制端，從點(diǎn)擊到響應(yīng)的過程非常短，同時(shí)在不知不覺中進(jìn)行了完整的安全檢測。動(dòng)態(tài)污點(diǎn)分析不需要數(shù)據(jù)重放，也就意味著其中不存在臟數(shù)據(jù)，并且對(duì)API接口、簽名和加密接口等有非常好的處理效率和處理機(jī)制。整個(gè)過程在不引入第三方的情況下，直接利用原始的請(qǐng)求源，就能觀察出從流量到整個(gè)函數(shù)的執(zhí)行過程當(dāng)中是否存在安全漏洞。

04  IAST結(jié)合容器化和微服務(wù)

如何實(shí)現(xiàn)IAST與容器化和微服務(wù)相結(jié)合？首先，從傳統(tǒng)應(yīng)用到當(dāng)前的微服務(wù)架構(gòu)發(fā)生了一些改變。以往可以通過前端與后端協(xié)作，后端一個(gè)集成應(yīng)用提供所有服務(wù)，在請(qǐng)求訪問時(shí)后端能夠響應(yīng)，之后再返回到頁面進(jìn)行展示，即完成了這一過程。而在微服務(wù)框架下，可以結(jié)合容器化對(duì)功能模塊進(jìn)行拆分，拆分之后，后端可以通過多個(gè)微服務(wù)程序去執(zhí)行功能模塊化。

傳統(tǒng)的應(yīng)用中，通過JVM無法直接執(zhí)行.java或.class文件，但class文件可以通過class加載器在裝載之后即可運(yùn)行。以圖示（上圖）為例，原本一個(gè)JAR包通過JAVA-jar app.jar的方式即可執(zhí)行。以此為基礎(chǔ)，在class加載器之前，通過攔截修改class當(dāng)中的內(nèi)容，讓程序去執(zhí)行埋點(diǎn)邏輯，這就構(gòu)成了插樁的基本原理。只需要在參數(shù)中加上javaagent agent.jar，即引入了插樁方式。

通過字節(jié)碼插樁技術(shù)，使IAST結(jié)合容器微服務(wù)場景。以SpringBoot使用場景為例（上圖），通過SpringBoot打包一個(gè)模塊化的應(yīng)用，之后結(jié)合容器即可部署上線。而當(dāng)有了插樁的agent之后，agent.jar依賴于中間件上，打包后形成了每個(gè)容器里都攜帶著原始模塊化的微服務(wù)小應(yīng)用，也攜帶了插樁的agent。

從外部看起來仍是一個(gè)應(yīng)用，只是在微服務(wù)框架下有不同的微服務(wù)程序。但從整體來看，agent收集到的不同流量都將反饋到同一應(yīng)用上。所以懸鏡靈脈IAST也是把微服務(wù)下收集到的不同安全漏洞歸屬到同一應(yīng)用上，以應(yīng)用的維度去看待整體的安全漏洞現(xiàn)狀。

當(dāng)插樁完成并進(jìn)行打包之后，插樁的agent會(huì)隨著應(yīng)用啟動(dòng)而啟動(dòng)，靜默等待流量輸入。當(dāng)功能測試開始時(shí)，插樁的agent就會(huì)在測試階段持續(xù)觀察和檢測安全漏洞。

05  IAST結(jié)合DevOps流水線

DevOps是從左向右流水線式的進(jìn)行，IAST工具主要應(yīng)用在測試階段。當(dāng)把插樁的agent結(jié)合環(huán)境部署到測試環(huán)境，完成API Test或者手動(dòng)測試后，IAST即以插樁或者API對(duì)接的方式對(duì)接到DevOps流水線上。這樣在完成功能測試時(shí)，IAST檢測的結(jié)果也可以同步展示在流水線當(dāng)中。

此外，因?yàn)镈evOps流水線在很大程度上采用自動(dòng)化的運(yùn)轉(zhuǎn)方式，對(duì)此IAST工具可以設(shè)置安全閾值或質(zhì)量閾值，安全團(tuán)隊(duì)可以在完成流水線測試環(huán)節(jié)之后，根據(jù)IAST返回的漏洞數(shù)量、漏洞類型，以及中高危漏洞的整體占比，來判斷DevOps流水線能否發(fā)布到預(yù)生產(chǎn)環(huán)境。

通過IAST工具進(jìn)行漏洞檢測的好處在于，相較于傳統(tǒng)安全工具的檢測時(shí)間長、誤報(bào)率高等問題，IAST的檢測模式結(jié)合DevOps流水線，能快速地在應(yīng)用上線前對(duì)漏洞進(jìn)行定位以及修復(fù)。

IAST嵌入DevOps流程有四大優(yōu)點(diǎn)：

第一，全流程自動(dòng)化，安全插件無縫嵌入到DevOps流程。

第二，同步收集流量并精準(zhǔn)定位到代碼行，指導(dǎo)研發(fā)修復(fù)。

第三，安全性的質(zhì)量卡點(diǎn)，設(shè)置極限安全的質(zhì)量閾值，直接阻斷流水線，減少安全漏洞流轉(zhuǎn)到上線后。當(dāng)流水線在測試階段被檢測出不符合預(yù)先設(shè)置的質(zhì)量卡點(diǎn)，檢測報(bào)告將返回到開發(fā)人員，開發(fā)人員依據(jù)報(bào)告進(jìn)行快速的定位和修復(fù)。

第四，完善安全開發(fā)工具鏈，IAST是DevOps流水線中的一個(gè)環(huán)節(jié)，它能與流水線上的其他類型工具結(jié)合，比如第三方組件檢測、容器安全檢測等工具，共同構(gòu)建完整的安全開發(fā)流程體系。

06  思考與展望

隨著云原生的推進(jìn)，以及應(yīng)用逐步實(shí)現(xiàn)微服務(wù)的改造之后，對(duì)于IAST交互式應(yīng)用安全測試工具也提出了更高的要求。

首先，多語言多場景的覆蓋。當(dāng)前企業(yè)以Java作為開發(fā)語言偏多，但不排除后端還有保存著如Python、PHP、.net等。因此除了Java之外，IAST工具需要提升對(duì)主流語言的覆蓋能力。同時(shí)還應(yīng)實(shí)現(xiàn)全場景支持，除了基于語言的插樁檢測模式，還應(yīng)支持流量或其他檢測方式，以覆蓋更多的業(yè)務(wù)場景。

其次，隨著容器化、微服務(wù)化、分布式等技術(shù)的推進(jìn)，基于IAST的插樁原理，除了測試安全漏洞，還應(yīng)該具備深度挖掘微服務(wù)框架下API接口的能力。例如當(dāng)應(yīng)用采用微服務(wù)架構(gòu)，測試人員對(duì)API接口發(fā)現(xiàn)不全，此時(shí)基于插樁的原理，可以對(duì)API接口進(jìn)行挖掘分析，測試出安全或功能的API覆蓋率等，提供給測試人員、開發(fā)人員和安全人員。

最后，云原生下的一體化探針。云原生下傳統(tǒng)安全工具WAF（Web應(yīng)用防火墻）的規(guī)則設(shè)定已不能適應(yīng)當(dāng)前環(huán)境多變、漏洞多變的情況，由此可以引入RASP安全解決方案。當(dāng)頻繁發(fā)版時(shí)，測試階段以IAST插樁探針檢測安全漏洞，并在保證應(yīng)用安全的前提下，將短時(shí)間內(nèi)無法修復(fù)的安全漏洞流轉(zhuǎn)到上線后，測試階段的插樁探針能夠攜帶到上線后開啟RASP功能，在上線后的環(huán)節(jié)做安全防護(hù)，實(shí)現(xiàn)運(yùn)行時(shí)自我保護(hù)機(jī)制。

關(guān)于懸鏡安全

懸鏡安全，DevSecOps敏捷安全領(lǐng)導(dǎo)者。由北京大學(xué)網(wǎng)絡(luò)安全技術(shù)研究團(tuán)隊(duì)“XMIRROR”發(fā)起創(chuàng)立，致力以AI技術(shù)賦能敏捷安全，專注于DevSecOps軟件供應(yīng)鏈持續(xù)威脅一體化檢測防御。核心的DevSecOps智適應(yīng)威脅管理解決方案包括以深度學(xué)習(xí)技術(shù)為核心的威脅建模、開源治理、風(fēng)險(xiǎn)發(fā)現(xiàn)、威脅模擬、檢測響應(yīng)等多個(gè)維度的自主創(chuàng)新產(chǎn)品及實(shí)戰(zhàn)攻防對(duì)抗為特色的政企安全服務(wù)，為金融、能源、泛互聯(lián)網(wǎng)、IoT、云服務(wù)及汽車制造等行業(yè)用戶提供創(chuàng)新靈活的智適應(yīng)安全管家解決方案。更多信息請(qǐng)?jiān)L問懸鏡安全官網(wǎng)：www.xmirror.cn。