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

內(nèi)容摘要

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

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

01 云原生概述

云原生計算基金會（CNCF）的定義：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

03  IAST簡介

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

第一，全流程自動化，安全插件無縫嵌入到DevOps流程。

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

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

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

06  思考與展望

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

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

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

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

關(guān)于懸鏡安全

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