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

內容摘要

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

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

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探針、流量代理/虛擬專用網絡或主機系統軟件等檢測模式，收集、監控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功能，在上線后的環節做安全防護，實現運行時自我保護機制。

關于懸鏡安全

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