云原生應用供應鏈安全風險防護方案探討

郭新海 張小梅 劉 安 丁 攀

中國聯通研究院 北京 100048

1 背景

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

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

2 風險分析

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

2.1 開發測試階段的風險

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

2.2 運營階段的風險

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

3 安全防護方案

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

圖1 應用供應鏈安全防護單一過程流程圖

同時云原生應用的安全防護從研發階段、集成測試階段到上線運行階段，需要反復迭代對應用進行監控防護及整改修復，以更全面地保證應用的安全[4]，整個應用供應鏈的循環監控檢測整改修復流程如圖2所示。

圖2 應用供應鏈循環過程流程圖

3.1 標準指引

鑒于如今國內外都開始重視軟件供應鏈安全，特別是美國為改善軟件供應鏈安全已經發布行政命令，要求為出售給政府的軟件開發建立基線安全標準，從而提高軟件的安全性。參考軟件供應鏈安全現狀和國內外形勢，對于云原生應用供應鏈也應該建立相應的安全標準，并充分發揮標準在技術、管理等方面的指引作用，通過標準來限定安全編碼規范、第三方組件引用等，為云原生應用的供應鏈中的應用構建、安全風險評估、檢測、管理等工作提供技術保障和實施指南。

3.2 技術方法

3.2.1 軟件組成成分分析

云原生應用開發強調持續交付，在產品功能不斷更新，開發周期不斷縮短的前提下，應用的開發大量使用第三方開源組件和第三方框架已經成為開發過程中的必然選擇，對開源組件和第三方框架進行有效檢測和管理已經成為開發階段保證應用安全的必選方法。

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

3.2.2 交互式安全測試

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

IAST比較常用的模式是插樁模式，插樁模式可以分為主動插樁模式和被動插樁模式，被動插樁模式不會改造原始流量包，不會利用攻擊payload進行流量包重放，通過在應用中插入agent，對底層函數進行hook，利用污點跟蹤技術來確定應用程序是否存在安全漏洞，該方法在測試的過程中不會產生臟數據。然而主動插樁模式結合了DAST的功能，需要篡改原始的請求包，改成攻擊payload后進行數據報文重放，同時在底層函數hook點進行跟蹤，能夠判定漏洞的存在，但是因對原始數據包加入了攻擊注入語句，會產生臟數據。

利用插樁模式的IAST技術，能夠有效檢測目錄遍歷、DOM型XSS、反射型XSS、CSRF、命令注入、SQL注入、表達式注入、任意文件上傳、XXE外部實體引用、HTTP only等應用漏洞，覆蓋了OWASP TOP 10和CWE漏洞類型標準，同時該技術對傳統安全檢測方法無法處理的加密場景、防篡改場景、一次性資源場景、多污染源場景、編碼場景等場景下的漏洞都能夠有效檢測出，提升了安全漏洞的檢出效率和正確率。

通過在應用的功能測試階段利用該技術，能夠更準確地檢測出漏洞，并確定漏洞代碼的具體位置，從而更有利于開發人員在應用上線前消除漏洞。

3.2.3 容器安全基線配置檢測

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

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

3.2.4 應用自免疫

在應用的運行階段通過RASP技術來賦予應用自免疫的能力[8]。RASP技術和傳統的WAF及防火墻在應用的外圍構筑安全防線不同，該技術通過在應用的內部植入agent的方式來對應用進行防護，其采用類似于IAST技術的hook函數方法，通過hook底層函數監測用戶的輸入，能夠實時檢測和阻斷惡意訪問或者黑客攻擊，同時由于其采用了hook函數的技術，當攻擊發生時能直接將相應的代碼行信息反饋給安全人員，并確定系統是否存在相應的漏洞。

RASP技術在賦予應用自免疫能力的同時，有效彌補了WAF的不足，在應用運行階段構建更深的縱深防御體系，對于WAF無法處理的加密流量也能有效檢測，其能夠發現并抵御的攻擊有SQL注入、XSS、文件系統操作、表達式執行、文件上傳、反序列化攻擊、惡意JNI調用、XXE、SSRF、WEBSHELL后門攻擊、掃描器攻擊等。通過使用該技術，在應用的運行階段，能夠針對應用的各類攻擊進行檢測和防護，在云原生應用供應鏈的最終階段，有效保護應用安全。

3.3 應用風險管理

沒有百分之百安全的應用，在云原生環境下更是如此，通過各種安全技術手段完全消除云原生應用供應鏈中的安全風險是不可能的，在采用技術手段的同時還需要加強應用的風險管理。在利用好各種技術對應用進行安全風險檢測、防護的同時，建立一套成熟、全面的風險管理體系和云原生應用供應鏈風險管理閉環的運作模式，包括風險的識別、漏洞修補、持續檢驗、彈性運作等，各個方面循環運作，才能有效提升云原生應用供應鏈的整體安全性。

4 總結

云原生技術的使用已經成為當前云計算方面的必然發展趨勢，各類應用向云端遷移的迫切更需要保證應用供應鏈的安全。本方案借鑒現有的技術，構造了云原生應用供應鏈安全防護方法，從標準、技術和管理方面說明了如何保證云原生應用供應鏈的安全。供應鏈安全不再是單一的產品安全，其更需要開發、測試、運營、安全各方面人員的共同努力，只有秉承協同合作的理念，才能使應用供應鏈安全更加完善，這方面的工作仍然需要大家進一步去推進，從而在保證云原生應用的安全性的基礎上，享受云原生技術帶來的便利。