郭新海 張小梅 劉 安 丁 攀

中國(guó)聯(lián)通研究院 北京 100048

1 背景

云原生作為一套技術(shù)和方法論，在當(dāng)前云網(wǎng)融合和數(shù)字化轉(zhuǎn)型的背景下已經(jīng)被廣泛應(yīng)用，并且已經(jīng)成為云計(jì)算領(lǐng)域的必然導(dǎo)向。該技術(shù)自從2013年誕生，經(jīng)過不斷的發(fā)展與豐富，已經(jīng)包括持續(xù)交付、DevOps、微服務(wù)、容器技術(shù)、敏捷基礎(chǔ)設(shè)施等多個(gè)主題。CNCF(云原生計(jì)算基金會(huì))通過調(diào)查顯示應(yīng)用的快速化部署、良好的擴(kuò)展性和便利的可移植性已經(jīng)使眾多企業(yè)受益，因此目前各個(gè)企業(yè)都在全力推進(jìn)應(yīng)用上云，指出除了不能也不必要上云的遺留應(yīng)用外，企業(yè)中的其他應(yīng)用應(yīng)該盡早盡快地轉(zhuǎn)移到云端，以享受云計(jì)算帶來(lái)的優(yōu)勢(shì)和便利。云原生的四要素——持續(xù)交付、DevOps、微服務(wù)和容器化[1]已經(jīng)被越來(lái)越多的人們所接受和使用。目前，國(guó)內(nèi)的有關(guān)部門也正在努力推動(dòng)云原生標(biāo)準(zhǔn)體系的建設(shè)，且已經(jīng)形成對(duì)容器、微服務(wù)和DevOps的要求標(biāo)準(zhǔn)和技術(shù)參考模型。在外因和內(nèi)力的共同作用下，云原生技術(shù)在金融、電信、互聯(lián)網(wǎng)等應(yīng)用領(lǐng)域已經(jīng)成為主流的技術(shù)[2]。

當(dāng)前隨著云原生技術(shù)的廣泛使用，云原生應(yīng)用安全已經(jīng)成為信息安全領(lǐng)域的重要方面，根據(jù)Gartner的調(diào)查統(tǒng)計(jì)，信息安全攻擊有75%都發(fā)生在應(yīng)用層面而非網(wǎng)絡(luò)層面上，而這方面的防護(hù)卻相當(dāng)薄弱。特別是當(dāng)前云原生技術(shù)快速發(fā)展、各類應(yīng)用容器化部署、應(yīng)用敏捷開發(fā)和快速上線的特點(diǎn)，導(dǎo)致了應(yīng)用可能會(huì)出現(xiàn)更多的漏洞與安全問題，進(jìn)而被攻擊者利用后而發(fā)起攻擊行為。同時(shí)，傳統(tǒng)的云原生應(yīng)用安全防護(hù)與傳統(tǒng)web應(yīng)用的防護(hù)方法類似，主要集中在應(yīng)用運(yùn)行時(shí)防護(hù)，例如web應(yīng)用安全網(wǎng)關(guān)(WAF)、web漏洞掃描器等，未形成整個(gè)應(yīng)用的供應(yīng)鏈安全防護(hù)，因而也造成了應(yīng)用上線運(yùn)行后的安全防護(hù)壓力倍增。通過制定云原生應(yīng)用的供應(yīng)鏈安全防護(hù)方案，將安全賦能至應(yīng)用開發(fā)、測(cè)試到上線運(yùn)行的各個(gè)環(huán)節(jié)，同時(shí)將安全融入DevOps實(shí)現(xiàn)DevSecOps，避免單純的依靠應(yīng)用上線運(yùn)行后的安全防護(hù)手段來(lái)保護(hù)應(yīng)用免受攻擊，構(gòu)建完備的云原生應(yīng)用供應(yīng)鏈安全防護(hù)方案保證云原生應(yīng)用的安全，從而提高整個(gè)云的安全防護(hù)水平，才能有效助力云網(wǎng)融合的發(fā)展和數(shù)字化轉(zhuǎn)型。

2 風(fēng)險(xiǎn)分析

由于云原生技術(shù)中廣泛的采用持續(xù)交付、DevOps、微服務(wù)和容器化的方案，使得云原生應(yīng)用的供應(yīng)鏈安全風(fēng)險(xiǎn)數(shù)量隨之增多。其中應(yīng)用的持續(xù)交付和DevOps使得開發(fā)人員更加注重應(yīng)用的開發(fā)速度和交付效率，由于對(duì)速度和效率的追求，開發(fā)人員經(jīng)常會(huì)利用開源項(xiàng)目的框架進(jìn)行二次開發(fā)或者引用許多開源組件，引用開源組件和框架之時(shí)，如果不對(duì)開源組件和框架進(jìn)行安全檢查勢(shì)必會(huì)導(dǎo)致開源組件和框架中存在的漏洞、惡意代碼等引入所開發(fā)的應(yīng)用，同時(shí)由于開發(fā)人員對(duì)于安全問題的不重視和開發(fā)水平的參差不齊，也特別容易使開發(fā)的應(yīng)用產(chǎn)生安全漏洞和業(yè)務(wù)邏輯漏洞；容器化的使用，使得應(yīng)用的部署和運(yùn)行非常便利，但是容器的使用極易將容器中存在的漏洞大面積引入云環(huán)境中，從而威脅整個(gè)云環(huán)境。綜上，開發(fā)階段的漏洞風(fēng)險(xiǎn)引入、測(cè)試階段未進(jìn)行安全測(cè)試、應(yīng)用上線后缺少必要的安全防護(hù)與隔離手段、容器漏洞的引入都是云原生應(yīng)用供應(yīng)鏈中面臨的風(fēng)險(xiǎn)。

2.1 開發(fā)測(cè)試階段的風(fēng)險(xiǎn)

云原生應(yīng)用的開發(fā)測(cè)試階段是風(fēng)險(xiǎn)漏洞引入的主要階段，當(dāng)然此階段也是消除風(fēng)險(xiǎn)漏洞最容易和成本最低的階段。該階段風(fēng)險(xiǎn)漏洞引入的主要原因有：開發(fā)人員編寫代碼中存在的業(yè)務(wù)邏輯缺陷，開發(fā)人員編寫代碼存在的典型安全漏洞，開發(fā)人員任意使用第三方組件和第三方框架引入的組件和框架漏洞，測(cè)試人員只注重功能測(cè)試未進(jìn)行應(yīng)用安全測(cè)試等。由于這些原因，云原生應(yīng)用從開發(fā)完成階段，自身就已經(jīng)存在了很多風(fēng)險(xiǎn)漏洞，屬于帶病的應(yīng)用，其可能存在各種各樣的安全風(fēng)險(xiǎn)，如業(yè)務(wù)邏輯漏洞、典型安全漏洞(如注入漏洞、身份認(rèn)證漏洞、敏感信息泄露漏洞、XML External Entity漏洞、失效的訪問控制、安全配置錯(cuò)誤、跨站腳本、反序列化漏洞、Cross-site request forgery、Server-Side Request Forgery、文件上傳、文件包含等)、第三方組件和框架類漏洞等[3]。上述漏洞都會(huì)成為云原生應(yīng)用的致命弱點(diǎn)，使應(yīng)用本身極容易受到攻擊，進(jìn)而威脅到整個(gè)云生態(tài)環(huán)境的安全。

2.2 運(yùn)營(yíng)階段的風(fēng)險(xiǎn)

由于云原生應(yīng)用從開發(fā)階段未能消除風(fēng)險(xiǎn)漏洞，當(dāng)應(yīng)用處于運(yùn)營(yíng)階段后也會(huì)產(chǎn)生相應(yīng)的安全問題。在云環(huán)境中部署時(shí)，云原生應(yīng)用經(jīng)常會(huì)被構(gòu)造為鏡像，并上傳至鏡像倉(cāng)庫(kù)，從而被容器所使用，因此可能會(huì)導(dǎo)致大面積的風(fēng)險(xiǎn)漏洞存在。據(jù)Gartner預(yù)測(cè)，到2022年將有75%的全球化企業(yè)將在生產(chǎn)中使用云原生的容器化應(yīng)用，因此云原生應(yīng)用本身的風(fēng)險(xiǎn)將會(huì)成為風(fēng)險(xiǎn)的重要來(lái)源面。另外，在該階段容器化的引用也會(huì)導(dǎo)致很多風(fēng)險(xiǎn)的存在，如漏洞利用類：由于Docker與主機(jī)共用一個(gè)操作系統(tǒng)內(nèi)核，如果主機(jī)內(nèi)核存在橫向越權(quán)或者提權(quán)漏洞，即使Docker使用普通用戶執(zhí)行，容器被入侵后，攻擊者還是可以利用內(nèi)核漏洞逃逸到主機(jī)，進(jìn)行惡意行為操作；如服務(wù)暴露類：因Docker默認(rèn)服務(wù)端口為2375，開啟沒有任何加密和訪問控制的Docker Remote API服務(wù)且暴露在互聯(lián)網(wǎng)上是非常危險(xiǎn)的；如拒絕服務(wù)類：如果不對(duì)每個(gè)容器的可用CPU、內(nèi)存等資源進(jìn)行有效的限制和管理，容器之間就會(huì)造成資源使用不均衡等影響，嚴(yán)重時(shí)可能導(dǎo)致主機(jī)和集群資源耗盡，造成拒絕服務(wù)攻擊；如逃逸類：通過容器逃逸，可以獲取更大的權(quán)限，威脅其他容器，甚至是宿主機(jī)；如環(huán)境配置類：由于容器基線配置的不合理導(dǎo)致容器信息暴露，從而被攻擊者利用發(fā)起下一步的攻擊等。上述風(fēng)險(xiǎn)都在云原生應(yīng)用的運(yùn)營(yíng)階段嚴(yán)重威脅著應(yīng)用本身和整個(gè)云環(huán)境的安全。

3 安全防護(hù)方案

面對(duì)云原生應(yīng)用供應(yīng)鏈中的各類安全問題，需要的不再是單一的技術(shù)手段和安全管理的加強(qiáng)，而是需要有整個(gè)云原生應(yīng)用供應(yīng)鏈的安全防護(hù)方案和國(guó)家的戰(zhàn)略指引。在國(guó)家戰(zhàn)略指引的方向下構(gòu)建DevSecOps，保證云原生應(yīng)用的安全。本文所提的安全防護(hù)方案主要是在開發(fā)測(cè)試的過程中加入了安全的方案，使安全左移，同時(shí)在應(yīng)用上線運(yùn)行后賦予應(yīng)用自免疫能力并提高應(yīng)用運(yùn)行環(huán)境的安全。研發(fā)測(cè)試階段通過軟件組成成分分析對(duì)應(yīng)用的第三方組件和框架進(jìn)行安全檢測(cè)和評(píng)估，集成測(cè)試階段通過交互式安全測(cè)試檢測(cè)應(yīng)用的漏洞，上線運(yùn)行階段通過安全基線配置檢測(cè)保證容器自身安全并利用RASP(Runtime Application Self-protection)賦予應(yīng)用自免疫能力，簡(jiǎn)要的方案流程圖如圖1所示。

圖1 應(yīng)用供應(yīng)鏈安全防護(hù)單一過程流程圖

同時(shí)云原生應(yīng)用的安全防護(hù)從研發(fā)階段、集成測(cè)試階段到上線運(yùn)行階段，需要反復(fù)迭代對(duì)應(yīng)用進(jìn)行監(jiān)控防護(hù)及整改修復(fù)，以更全面地保證應(yīng)用的安全[4]，整個(gè)應(yīng)用供應(yīng)鏈的循環(huán)監(jiān)控檢測(cè)整改修復(fù)流程如圖2所示。

圖2 應(yīng)用供應(yīng)鏈循環(huán)過程流程圖

3.1 標(biāo)準(zhǔn)指引

鑒于如今國(guó)內(nèi)外都開始重視軟件供應(yīng)鏈安全，特別是美國(guó)為改善軟件供應(yīng)鏈安全已經(jīng)發(fā)布行政命令，要求為出售給政府的軟件開發(fā)建立基線安全標(biāo)準(zhǔn)，從而提高軟件的安全性。參考軟件供應(yīng)鏈安全現(xiàn)狀和國(guó)內(nèi)外形勢(shì)，對(duì)于云原生應(yīng)用供應(yīng)鏈也應(yīng)該建立相應(yīng)的安全標(biāo)準(zhǔn)，并充分發(fā)揮標(biāo)準(zhǔn)在技術(shù)、管理等方面的指引作用，通過標(biāo)準(zhǔn)來(lái)限定安全編碼規(guī)范、第三方組件引用等，為云原生應(yīng)用的供應(yīng)鏈中的應(yīng)用構(gòu)建、安全風(fēng)險(xiǎn)評(píng)估、檢測(cè)、管理等工作提供技術(shù)保障和實(shí)施指南。

3.2 技術(shù)方法

3.2.1 軟件組成成分分析

云原生應(yīng)用開發(fā)強(qiáng)調(diào)持續(xù)交付，在產(chǎn)品功能不斷更新，開發(fā)周期不斷縮短的前提下，應(yīng)用的開發(fā)大量使用第三方開源組件和第三方框架已經(jīng)成為開發(fā)過程中的必然選擇，對(duì)開源組件和第三方框架進(jìn)行有效檢測(cè)和管理已經(jīng)成為開發(fā)階段保證應(yīng)用安全的必選方法。

在該階段利用自動(dòng)化的第三方開源組件檢測(cè)技術(shù)，該技術(shù)秉承安全左移的理念，在軟件開發(fā)的過程中進(jìn)行評(píng)估和自動(dòng)化測(cè)試，完成對(duì)應(yīng)用的組成成分分析。該方法在應(yīng)用功能測(cè)試的過程中通過在應(yīng)用中插入agent，利用agent跟蹤代碼的流向，確定應(yīng)用所使用的組件，然后通過匹配CNNVD和CVE漏洞庫(kù)，來(lái)確定第三方開源組件是否存在已知漏洞，對(duì)存在已知漏洞的安全組件提供相應(yīng)的漏洞細(xì)節(jié)描述和修復(fù)建議，以供開發(fā)人員修復(fù)或替換相應(yīng)的組件，從而避免和消除第三方開源組件的使用所引入的漏洞。

3.2.2 交互式安全測(cè)試

交互式應(yīng)用安全測(cè)試(IAST)技術(shù)也推動(dòng)了整個(gè)安全測(cè)試的左移[5]，在應(yīng)用的功能測(cè)試階段同時(shí)進(jìn)行了安全漏洞檢測(cè)，其已經(jīng)成為了DevSecOps安全工具鏈中的必備手段。該技術(shù)區(qū)別于傳統(tǒng)的動(dòng)態(tài)應(yīng)用安全測(cè)試(DAST)技術(shù)[6]和靜態(tài)應(yīng)用安全測(cè)試(SAST)技術(shù)，目前比較典型DAST技術(shù)和SAST技術(shù)分別是web漏掃和靜態(tài)代碼審計(jì)，且已經(jīng)被廣泛應(yīng)用。

IAST比較常用的模式是插樁模式，插樁模式可以分為主動(dòng)插樁模式和被動(dòng)插樁模式，被動(dòng)插樁模式不會(huì)改造原始流量包，不會(huì)利用攻擊payload進(jìn)行流量包重放，通過在應(yīng)用中插入agent，對(duì)底層函數(shù)進(jìn)行hook，利用污點(diǎn)跟蹤技術(shù)來(lái)確定應(yīng)用程序是否存在安全漏洞，該方法在測(cè)試的過程中不會(huì)產(chǎn)生臟數(shù)據(jù)。然而主動(dòng)插樁模式結(jié)合了DAST的功能，需要篡改原始的請(qǐng)求包，改成攻擊payload后進(jìn)行數(shù)據(jù)報(bào)文重放，同時(shí)在底層函數(shù)hook點(diǎn)進(jìn)行跟蹤，能夠判定漏洞的存在，但是因?qū)υ紨?shù)據(jù)包加入了攻擊注入語(yǔ)句，會(huì)產(chǎn)生臟數(shù)據(jù)。

利用插樁模式的IAST技術(shù)，能夠有效檢測(cè)目錄遍歷、DOM型XSS、反射型XSS、CSRF、命令注入、SQL注入、表達(dá)式注入、任意文件上傳、XXE外部實(shí)體引用、HTTP only等應(yīng)用漏洞，覆蓋了OWASP TOP 10和CWE漏洞類型標(biāo)準(zhǔn)，同時(shí)該技術(shù)對(duì)傳統(tǒng)安全檢測(cè)方法無(wú)法處理的加密場(chǎng)景、防篡改場(chǎng)景、一次性資源場(chǎng)景、多污染源場(chǎng)景、編碼場(chǎng)景等場(chǎng)景下的漏洞都能夠有效檢測(cè)出，提升了安全漏洞的檢出效率和正確率。

通過在應(yīng)用的功能測(cè)試階段利用該技術(shù)，能夠更準(zhǔn)確地檢測(cè)出漏洞，并確定漏洞代碼的具體位置，從而更有利于開發(fā)人員在應(yīng)用上線前消除漏洞。

3.2.3 容器安全基線配置檢測(cè)

在云原生技術(shù)中，應(yīng)用已經(jīng)開始普遍的使用容器部署，因此在保證應(yīng)用自身安全的前提下也需要其寄宿的容器安全水平相應(yīng)提高，才能使應(yīng)用所在的容器環(huán)境更加安全。通過容器的自動(dòng)化安全基線配置檢測(cè)，能有效地發(fā)現(xiàn)容器配置的不合規(guī)項(xiàng)。該方法通過利用自動(dòng)化檢查腳本對(duì)容器的配置情況進(jìn)行自動(dòng)化檢查，從而發(fā)現(xiàn)容器配置的不合規(guī)項(xiàng)，并提出相應(yīng)的整改建議和整改方法，使應(yīng)用部署人員根據(jù)相應(yīng)的建議對(duì)容器的配置進(jìn)行整改，從而提高容器環(huán)境的安全水平，以進(jìn)一步保證應(yīng)用的安全。

通過容器基線配置檢測(cè)，能夠有效提高容器配置的安全水平[7]，其作為應(yīng)用部署階段的安全檢測(cè)方法是應(yīng)用供應(yīng)鏈安全中必備的手段。

3.2.4 應(yīng)用自免疫

在應(yīng)用的運(yùn)行階段通過RASP技術(shù)來(lái)賦予應(yīng)用自免疫的能力[8]。RASP技術(shù)和傳統(tǒng)的WAF及防火墻在應(yīng)用的外圍構(gòu)筑安全防線不同，該技術(shù)通過在應(yīng)用的內(nèi)部植入agent的方式來(lái)對(duì)應(yīng)用進(jìn)行防護(hù)，其采用類似于IAST技術(shù)的hook函數(shù)方法，通過hook底層函數(shù)監(jiān)測(cè)用戶的輸入，能夠?qū)崟r(shí)檢測(cè)和阻斷惡意訪問或者黑客攻擊，同時(shí)由于其采用了hook函數(shù)的技術(shù)，當(dāng)攻擊發(fā)生時(shí)能直接將相應(yīng)的代碼行信息反饋給安全人員，并確定系統(tǒng)是否存在相應(yīng)的漏洞。

RASP技術(shù)在賦予應(yīng)用自免疫能力的同時(shí)，有效彌補(bǔ)了WAF的不足，在應(yīng)用運(yùn)行階段構(gòu)建更深的縱深防御體系，對(duì)于WAF無(wú)法處理的加密流量也能有效檢測(cè)，其能夠發(fā)現(xiàn)并抵御的攻擊有SQL注入、XSS、文件系統(tǒng)操作、表達(dá)式執(zhí)行、文件上傳、反序列化攻擊、惡意JNI調(diào)用、XXE、SSRF、WEBSHELL后門攻擊、掃描器攻擊等。通過使用該技術(shù)，在應(yīng)用的運(yùn)行階段，能夠針對(duì)應(yīng)用的各類攻擊進(jìn)行檢測(cè)和防護(hù)，在云原生應(yīng)用供應(yīng)鏈的最終階段，有效保護(hù)應(yīng)用安全。

3.3 應(yīng)用風(fēng)險(xiǎn)管理

沒有百分之百安全的應(yīng)用，在云原生環(huán)境下更是如此，通過各種安全技術(shù)手段完全消除云原生應(yīng)用供應(yīng)鏈中的安全風(fēng)險(xiǎn)是不可能的，在采用技術(shù)手段的同時(shí)還需要加強(qiáng)應(yīng)用的風(fēng)險(xiǎn)管理。在利用好各種技術(shù)對(duì)應(yīng)用進(jìn)行安全風(fēng)險(xiǎn)檢測(cè)、防護(hù)的同時(shí)，建立一套成熟、全面的風(fēng)險(xiǎn)管理體系和云原生應(yīng)用供應(yīng)鏈風(fēng)險(xiǎn)管理閉環(huán)的運(yùn)作模式，包括風(fēng)險(xiǎn)的識(shí)別、漏洞修補(bǔ)、持續(xù)檢驗(yàn)、彈性運(yùn)作等，各個(gè)方面循環(huán)運(yùn)作，才能有效提升云原生應(yīng)用供應(yīng)鏈的整體安全性。

4 總結(jié)

云原生技術(shù)的使用已經(jīng)成為當(dāng)前云計(jì)算方面的必然發(fā)展趨勢(shì)，各類應(yīng)用向云端遷移的迫切更需要保證應(yīng)用供應(yīng)鏈的安全。本方案借鑒現(xiàn)有的技術(shù)，構(gòu)造了云原生應(yīng)用供應(yīng)鏈安全防護(hù)方法，從標(biāo)準(zhǔn)、技術(shù)和管理方面說(shuō)明了如何保證云原生應(yīng)用供應(yīng)鏈的安全。供應(yīng)鏈安全不再是單一的產(chǎn)品安全，其更需要開發(fā)、測(cè)試、運(yùn)營(yíng)、安全各方面人員的共同努力，只有秉承協(xié)同合作的理念，才能使應(yīng)用供應(yīng)鏈安全更加完善，這方面的工作仍然需要大家進(jìn)一步去推進(jìn)，從而在保證云原生應(yīng)用的安全性的基礎(chǔ)上，享受云原生技術(shù)帶來(lái)的便利。