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

內容摘要

• 云原生概述
• 云原生下的應用安全
• IAST簡介
• IAST結合容器化和微服務
• IAST結合DevOps流水線
• 思考與展望

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

01 云原生概述

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

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

云原生應用的三大特征：

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

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

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

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

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

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

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

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

02  云原生下的應用安全

云原生下的四大應用安全風險：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

03  IAST簡介

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

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

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

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

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

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

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

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

當在執(zhí)行寫庫或寫文件操作時，通過觀察污點匯聚點攜帶的污點標記，代碼執(zhí)行流結合流量的請求和響應做最后的聚合分析，發(fā)現(xiàn)整個流程中是否存在安全漏洞。

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

04  IAST結合容器化和微服務

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

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

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

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

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

05  IAST結合DevOps流水線

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

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

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

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

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

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

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

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

06  思考與展望

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

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

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

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

關于懸鏡安全

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