關於雲原生應用，這些安全風險瞭解一下

摘要：雲原生應用究竟和傳統應用有何不同，安全風險上有何變化？本文將從傳統應用風險、應用架構變革帶來的風險、雲端計算模式帶來的風險三個維度進行介紹。

一.  概述

隨著雲端計算技術的不斷髮展，上雲已經不再是一種選擇，而是一種共識，是企業數字化轉型的必要條件。在相應實踐過程中，傳統應用存在升級緩慢、架構臃腫、無法彈性擴充套件及快速迭代等問題，於是近年來雲原生的概念應運而生，憑藉著雲原生彈性、敏捷、資源池和服務化等特性，解決了業務在開發、整合、分發和執行等整個生命週期中遇到的問題。

雲原生環境中，應用由傳統的單體架構轉向微服務架構，雲端計算模式也相應的從基礎設施即服務（Infrastructure as a Service，IaaS）轉向為容器即服務（Container as a Service，CaaS）和函式即服務（Function as a Service，FaaS）。應用架構和雲端計算模式的變革是否會導致進一步的風險，這些風險較之傳統應用風險又有哪些區別？在講述雲原生應用具體風險前，首先列舉以下三個觀點，這些觀點有助於大家更好地理解本文所講述的內容。

觀點一 雲原生應用繼承了傳統應用的風險和API的風險

雲原生應用源於傳統應用，因而云原生應用風險也就繼承了傳統應用的風險。此外，由於雲原生應用架構的變化進而導致應用API互動的增多，可以說雲原生應用中大部分互動模式已從Web請求/響應轉向各類API請求/響應 ，例如RESTful/HTTP、gRPC等，因而API風險也進一步提升。

觀點二 應用架構變革將會帶來新的風險

由於應用架構變革，雲原生應用遵循面向微服務化的設計方式，從而導致功能元件化、服務數量激增、配置複雜等問題，進而為雲原生應用和業務帶來了新的風險。

觀點三 計算模式變革將會帶來新的風險

隨著雲端計算的不斷髮展，企業在應用的微服務化後，會進一步聚焦於業務自身，並將功能函式化，因而出現了無伺服器計算（Serverless Computing）這類新的雲端計算模式，進而引入了Serverless應用和Serverless平臺的新風險。

綜上所述，可以看出雲原生應用帶來的風險是不容小覷的。本文將從傳統應用風險、應用架構變革帶來的新風險、雲端計算模式變革帶來的新風險三個維度分別進行介紹，希望可以引發大家更多的思考。

二. 傳統應用面臨的風險

雲原生應用風險可以參考傳統應用風險。傳統應用風險以Web應用風險為主，主要包括注入、敏感資料洩露、跨站指令碼、使用含有已知漏洞的元件、不足的日誌記錄和監控等風險。

此外，雲原生環境中，應用的API互動模式逐漸由“人機互動”轉變為“機機互動”，雖然API大量出現是雲原生環境的一大特點，但本質上來說，API風險並無新的變化，因而其風險可以參考現有的API風險，主要包括安全性錯誤配置、注入、資產管理不當、資源缺失和速率限制等風險。

有關傳統應用風險和API風險的更多細節可以分別參考OWASP組織在2017和2019年釋出的應用十大風險報告[1]和API十大風險報告[2]。

三.  應用架構變革帶來的新風險

3.1 雲原生應用帶來的新風險

雲原生應用面臨的新風險主要體現在：新應用架構的出現。新應用架構遵循微服務化的設計模式，透過應用的微服務化，我們能夠構建容錯性好、易於管理的松耦合系統，與此同時，新應用架構的出現也會引入新的風險，為了較為完整地對風險進行分析，本文將以資訊系統安全等級三要素，即機密性（Confidentiality）、完整性（Integrity）、可用性（Availability）作為導向介紹應用架構變化帶來的新風險。

機密性受損的風險

典型的如資訊洩露風險，攻擊者可透過利用資產脆弱性和嗅探、暴力破解等攻擊方式竊取使用者隱私資料，從而造成資訊洩露風險。

完整性受損的風險

典型的如未授權訪問風險，攻擊者可透過利用資產脆弱性和中間人攻擊等行為繞過系統的認證授權機制，執行越權操作，從而造成未授權訪問的風險。

可用性受損的風險

典型的如系統被拒絕服務的風險，一方面，攻擊者可透過畸形報文、SYN泛洪等攻擊方式為目標系統提供非正常服務，另一方面，系統供不應求的場景也會導致系統遭受拒絕服務風險。

本小節接下來的內容，將以資訊洩露、未授權訪問、拒絕服務為例，分別介紹上述三類風險。

3.1.1   資料洩露的風險 

雲原生環境中，雖然造成應用資料洩露風險的原因有很多，但都離不開以下幾個因素：

應用漏洞：透過資產漏洞對應用資料進行竊取。

金鑰不規範管理：透過不規範的金鑰管理對應用資料進行竊取。

應用間通訊未經加密：透過應用間通訊未經加密的缺陷對傳輸中資料進行竊取，進而升級到對應用資料的竊取。

3.1.1.1 應用漏洞帶來的風險

應用中儲存的資料多是基於API進行訪問，若應用中某API含有未授權訪問漏洞，例如Redis未授權訪問漏洞，攻擊者便可利用此漏洞繞過Redis認證機制，訪問到內部資料，進而導致了敏感資訊洩露的風險。

傳統單體應用架構下，由於API訪問範圍為使用者到應用，攻擊者只能看到外部進入至應用的流量，無法看到應用內部的流量，所以針對惡意使用API漏洞進行資料竊取造成的損失範圍通常是有限的。

反觀微服務化應用架構，當單體應用被拆分為若干個服務後，這些服務會根據業務情況進行相互訪問，API訪問範圍變為服務到服務（Service to Service），若某服務因API漏洞導致攻擊者有利可圖，那麼攻擊者將會看到應用內部的流量，這無疑為攻擊者提供了更多的攻擊渠道，因而針對資料洩露的風險程度而言，微服務架構相比傳統單體應用架構帶來的風險更大。此外，隨著服務數量達到一定規模，API數量將不斷遞增，進而擴大了攻擊面，增大了資料洩露的風險。

3.1.1.2 金鑰不規範管理帶來的風險

在應用的開發過程中，開發者常疏於對金鑰的管理從而導致資料洩露的風險，例如開發者將金鑰資訊、資料庫連線密碼等敏感資訊硬編碼在應用程式中，從而增大了諸如應用程式日誌洩露、應用程式訪問金鑰洩露的風險。

傳統單體應用架構中，開發者常將配置連同應用一起打包，當需要修改配置時，只需登入至服務端進行相應修改，再對應用進行重啟便可實現，這種單個集中式配置檔案的儲存方式從金鑰管理風險的角度上講是相對可控的。

微服務應用架構中，應用的配置數量與服務數量的逐漸增多是成正比的，例如微服務應用中會存在各種服務、各種資料庫訪問、各種環境變數的配置，且各配置支援動態調整。同時，微服務應用架構對服務的配置管理也提出了更高的要求，例如程式碼與配置可分離、配置支援分散式、配置更新的實時性、配置可統一進行治理等，因而微服務下的配置管理更加複雜，對運維人員的要求更高，金鑰管理的難度也在不斷提升，最終會造成更大的資料洩露風險。

3.1.1.3 應用通訊未經加密帶來的風險

如果應用採用HTTP協議進行資料傳輸，那麼HTTP頁面的所有資訊將都以純文字形式進行傳輸，並且預設不提供任何加密措施。因而在資料傳輸過程中易被攻擊者監聽、截獲和篡改，典型的攻擊流程為攻擊者透過Fiddler、Wireshark等抓包工具進行流量監聽，截獲傳輸的敏感資訊（例如資料庫密碼、登入密碼等），最後攻擊者根據自身意圖對敏感資料進行篡改併傳送至服務端，進而導致資料洩露的風險。

傳統單體應用架構中，由於網路拓撲相對簡單，且應用通訊多基於HTTP/HTTPS，因而造成的資料洩露風險多是因為採用了HTTP協議。微服務應用架構中，網路拓撲相對複雜，因遵循分散式的特點，應用間的通訊不僅採用HTTP/HTTPS協議，還採用gRPC等協議，由於gRPC協議預設不加密，因而將會導致攻擊面的增多，為資料洩露帶來了更多的風險。

3.1.2  未授權訪問的風險

雲原生環境中，應用未授權訪問的風險多是由於應用自身漏洞或訪問許可權錯誤地配置導致。

3.1.2.1 應用漏洞帶來的風險

應用漏洞是造成未授權訪問的一大因素。未授權訪問漏洞非常之多，較為常用的如Redis、MongoDB、Jenkins、Docker、Zookeeper、Hadoop等應用都曾曝光過相關漏洞，例如Docker曝出的Docker Remote API未授權訪問漏洞，攻擊者可透過Docker Client或HTTP請求直接訪問Docker Remote API，進而對容器進行新建、刪除、暫停等危險操作，甚至是獲取宿主機shell許可權。再如MongoDB未授權訪問漏洞，該漏洞造成的根本原因在於MongoDB在啟動時將認證資訊預設設定為空口令，從而導致登入使用者可透過預設埠無需密碼對資料庫進行任意操作並且可以遠端訪問資料庫。

從漏洞成因的出發點來看，認證及授權機制的薄弱是其主要原因，在單體應用架構下，應用作為一個整體對使用者進行認證授權，且應用的訪問來源相對單一，基本為瀏覽器，因而風險是相對可控的，微服務應用架構下，其包含的所有服務均需對各自的訪問進行授權，從而明確當前使用者的訪問控制許可權，此外，服務的訪問來源除了使用者外還包含內部的其他服務，因而在微服務架構下，應用的認證授權機制更為複雜，為雲原生應用帶來了更多的攻擊面。

3.1.2.2 訪問許可權錯誤配置帶來的風險

由於運維人員對使用者的訪問許可權進行了錯誤配置，進而會增大被攻擊者利用的風險。例如，運維人員對Web應用訪問許可權進行相應配置，針對普通使用者，運維人員應只賦予其只讀操作，若運維人員進行了錯誤的配置，例如為普通使用者配置了寫操作，那麼攻擊者便會利用此缺陷繞過認證訪問機制對應用發起未授權訪問攻擊。

傳統應用架構中，應用由於設計相對單一，其訪問許可權也相對單一，幾乎只涉及使用者對應用的訪問許可權這一層面，因此對應的訪問許可權配置也相對簡單。因為訪問許可權配置簡單的特點，使用者身份憑據等敏感資訊常儲存在應用的服務端，一旦攻擊者利用配置的缺陷對應用發起未授權訪問入侵，就有可能拿到所有儲存在後端的資料，從而造成巨大風險。

微服務應用架構下，由於訪問許可權還需涉及服務對服務這一層面，因此將會導致許可權對映關係變得更加複雜，相應的許可權配置難度也在同步增加，例如一個複雜應用被拆分為100個服務，運維人員需要嚴密地對每個服務賦予其應有的許可權，如果因疏忽導致為某個服務配置了錯誤的許可權，攻擊者就有可能利用此缺陷對服務展開攻擊，若該服務中包含漏洞，進而可能會導致單一漏洞擴充套件至整個應用的風險。所以如何對雲原生應用的訪問許可權進行高效率管理成為了一個較難的問題，這也是導致其風險的關鍵因素。

3.1.3 被拒絕服務的風險

被拒絕服務是應用程式的面臨的常見風險。造成拒絕服務的主要原因包括兩方面，一方面是由於應用自身漏洞所致，例如ReDoS漏洞、Nginx拒絕服務漏洞等，另一方面是由於訪問需求與資源能力不匹配所致，例如某電商平臺的購買API由於處理請求能力有限，因而無法面對突如其來的大量購買請求，導致了平臺資源（CPU、記憶體、網路）的耗盡甚至崩潰。這種場景往往不帶有惡意企圖，而帶有惡意企圖的則主要以ACK、SYNC泛洪攻擊及CC（Challenge Collapsar）等攻擊為主，其最終目的也是應用資源的耗盡。

3.1.3.1應用漏洞帶來的風險

應用漏洞可以導致應用被拒絕服務，那麼具體是如何導致的呢？以ReDoS（Regular expression Denial of Service）漏洞為例，ReDoS為正規表示式拒絕服務，攻擊者對該漏洞的利用通常是這樣的一個場景，應用程式為使用者提供了正規表示式的輸入型別又沒有對具體的輸入進行有效驗證，那麼攻擊者便可透過構造解析效率極低的正規表示式作為輸入進而在短時間內引發100%的CPU佔用率，最終導致資源耗盡，甚至應用程式崩潰的風險。

3.1.3.2訪問需求與資源能力不匹配帶來的風險

此處以CC攻擊舉例，其攻擊原理通常是攻擊者透過控制殭屍網路、肉雞或代理伺服器不斷地向目標主機傳送大量合法請求，從而使正常使用者的請求處理變得異常緩慢。

傳統Web場景中，攻擊者利用代理伺服器向受害者發起大量HTTP GET請求，該請求主要透過動態頁面向資料庫傳送訪問操作，透過大量的連線，資料庫負載極高，超過其正常處理能力，從而無法響應正常請求，並最終導致伺服器當機。

在微服務應用架構下，由於API數量會隨著服務數量的遞增而遞增，因而可能將會導致單一請求生成數以萬計的複雜中間層和後端服務呼叫，進而更容易引起被拒絕服務的風險，例如若微服務應用的API設計未考慮太多因單個API呼叫引起的耗時問題，那麼當外部訪問量突增時，將會導致訪問需求與資源能力不匹配的問題，使服務端無法對請求作出及時的響應，造成頁面卡死的現象，進而會引起系統崩潰的風險。

3.2 雲原生業務帶來的新風險

雲原生應用業務風險和雲原生應用風險有何區別？雲原生應用風險主要是Web應用風險，即網路層面的風險，而云原生應用業務風險無明顯的網路攻擊特徵，多是利用業務系統的漏洞或規則對業務系統進行攻擊來牟利，從而造成一定的損失。

此外，與傳統應用架構中的業務風險不同，微服務應用架構中，若服務間的安全措施不完善，例如使用者授權不恰當、請求來源校驗不嚴格等，將會導致針對微服務業務層面的攻擊變得更加容易，例如針對一個電商應用，攻擊者可以對特定的服務進行攻擊，例如透過API傳入非法資料，或者直接修改服務的資料庫系統等。攻擊者可以繞過驗證碼服務，直接呼叫訂單管理服務來進行薅羊毛等惡意操作。攻擊者甚至可以透過直接修改訂單管理和支付所對應的服務系統，繞過支付的步驟，直接成功購買商品等。

綜上，應用微服務化的設計模式帶來的業務風險可包含兩方面，一方面是未授權訪問風險，典型場景為攻擊者透過許可權繞過對業務系統的關鍵引數進行修改從而造成業務損失，另一方面則是API濫用的風險，典型的是對業務系統的薅羊毛操作。

3.2.1 未授權訪問的風險

在雲原生業務環境中，造成未授權訪問風險的原因，可以大致分為業務引數異常和業務邏輯異常兩方面，為了更為清晰的說明上述異常如何導致未授權訪問的風險，這裡以一個微服務架構的電商系統舉例說明。如圖1所示：

圖 1某電商系統流程圖

3.2.1.1業務引數異常帶來的風險

API呼叫過程中往往會傳遞相關的引數。引數的取值根據業務場景的不同會有不同的取值範圍。例如商品數量必須為非負整數，價格必須大於0等。若API對相應引數的監測機制不完善，那麼攻擊者便可透過輸入異常引數導致業務系統受到損失。例如在圖1所示的電商系統中，若商品價格只在商品介紹服務中進行校驗，而未在訂單管理和支付服務中進行校驗，那麼攻擊者則可以透過直接呼叫訂單管理和支付服務的API將訂單價格修改為0元或者負值，從而給業務系統造成損失。

3.2.1.2業務邏輯異常帶來的風險

相比於前一類異常，此類異常一般較為隱蔽。攻擊者採用某些方法使API呼叫的邏輯順序出現異常，包括關鍵呼叫步驟缺失、顛倒等。例如在圖1所示的電商系統中，攻擊者可以利用漏洞繞過支付的步驟直接提交訂單。這樣就會出現業務邏輯關鍵步驟缺失的情況，進而會為業務系統帶來損失，例如驗證碼繞過異常就屬於業務邏輯異常的一種。

3.2.2 API濫用的風險

針對此類風險，通常指的是攻擊者對業務系統的薅羊毛操作，風險成因則是由於業務頻率異常所致，這裡以電商系統舉例說明。

業務頻率異常主要指標對一個或一組API的頻繁呼叫。業務系統往往透過圖形驗證碼的方式來避免機器人刷單的操作。例如在圖1所示的電商系統中，攻擊者可以繞過驗證碼所對應的服務，直接對訂單進行操作，進而實現機器刷單，對電商進行薅羊毛。

四. 雲端計算模式變革帶來的新風險

作為一種新的雲端計算模式，Serverless具備許多特性，典型的主要有輸入源的不確定性、伺服器託管雲服務商、供應商鎖定等，這些特性可能會給Serverless帶來新的風險。

此外，由於Serverless最終呈現的還是多個函式組成的應用，且被Serverless提供的服務端執行，因此Serverless風險還應包括Serverless應用的風險及Serverless平臺的風險。

最後Serverless因購買、部署成本低、函式訪問域名相對可信等將會使Serverless面臨被濫用的風險。

4.1 Serverless特徵帶來的風險

4.1.1  輸入源不確定帶來的風險

Serverless函式是由一系列事件觸發的，如雲端儲存事件（S3、Blobs和其他雲端儲存）、流資料處理（如：AWS Kinesis）、通知（如：SMS、電子郵件、IoT）等，鑑於此特性，我們不應該把來自API呼叫的輸入作為唯一攻擊面。此外，我們不再控制源到資源間的這條線，如果函式被郵件或資料庫觸發，將無處可設定防火牆或任何其他控制措施來驗證事件源[4]。可見輸入源的不確定性將可能導致一定的風險。

在傳統應用程式開發中，開發者根據自身實踐經驗，在數量有限的可能性中可判定出惡意輸入來源，但Serverless模式下函式呼叫是由事件源觸發，輸入來源的不確定性限制了開發者的判定。例如當函式訂閱一個事件源後，該函式在該型別的事件發生時被觸發，這些事件可能來源於FaaS平臺，也可能來源於未知的事件源，對於來源未知的事件源可以被標註為不受信任。在實際應用場景中，如果開發者沒有良好的習慣對事件源進行分類，則會經常導致將不受信任的事件錯認為是FaaS平臺事件，進而將其視為受信任的輸入來處理，最終帶來了風險。 

具體地，輸入來源的不確定性會為Serverless應用帶來注入的風險，與傳統應用相同的是，注入攻擊過程與並無太大區別，不同的是攻擊向量的變化，傳統應用中用於注入攻擊的向量通常指攻擊者可以控制或操縱應用輸入的任何位置，但Serverless應用由於輸入的不確定性因而帶來了更大的攻擊面。

4.1.2 服務託管雲服務廠商帶來的風險

傳統應用中，例如Web應用常部署在本地/遠端伺服器上，關於服務端的作業系統漏洞修補、網路拓撲的安全、應用在服務端的訪問日誌及監控等均需要特定的運維人員去處理，而Serverless的伺服器託管雲服務商的特點將導致開發者無法感知到伺服器的存在，實際上開發者也無須對伺服器進行操作，只需關注應用本身的安全即可，伺服器的安全則交由雲廠商管理Serverless的這一特徵實際上降低了安全風險。

4.1.3  供應商鎖定帶來的風險

“供應商鎖定”是指使用者依賴特定供應商提供的產品及服務，並且在不產生實質性轉換成本或運營影響的情況下無法使用其他供應商的雲服務，在Serverless中，“供應商鎖定”是目前存在的一大問題，例如使用者選擇AWS作為應用的執行環境，由於一些原因，該應用需遷移至Microsoft Azure平臺，但“供應商鎖定”的問題導致無法輕易的將之前執行的應用及使用的相應資源如S3儲存桶等平滑遷移至Microsoft Azure平臺中，進而導致企業面臨應用轉換成本的風險。

4.2 Serverless應用風險

Serverless應用屬於雲原生應用，其應用本身與傳統應用基本是相同的，唯一區別是應用程式碼編寫需要參照雲廠商提供的特有程式碼模版，而傳統應用通常沒有這個限制。

Serverless應用屬於雲原生應用，雲原生應用又源於傳統應用，因而傳統應用面臨的風險幾乎可以全面覆蓋Serverless應用風險，關於風險分析部分可以參考之前傳統應用風險的內容，更詳細的內容可以參考OWASP組織在2017年釋出的Serverless應用十大風險報告[4]。

4.3 Serverless平臺風險

Serverless平臺主要指FaaS平臺，目前主流的FaaS平臺分為兩種型別，一種是面向公有云提供商的FaaS平臺，常見的有AWS Lambda、Microsoft Azure Functions、Google Cloud Functions等，另一方面則是面向私有云的FaaS平臺，此類以開源專案居多，且均支援在Kubernetes上進行部署，常見的有Apache OpenWhisk[7]、Kubeless[8]、OpenFaaS[9]、Fission[10]等。類似在IaaS平臺上執行虛機、PaaS平臺上執行作業系統和應用，FaaS平臺較之上述平臺的主要區別為其執行的是一個個Serverless函式。FaaS平臺自身負責雲環境地安全管理，主要包括資料、儲存、網路、計算、作業系統等。

4.4 Serverless被濫用的風險

Serverless被濫用具體是指攻擊者透過惡意構建Serverless函式並利用其充當整個攻擊中的一環，這種方式可在一定程度上規避安全裝置的檢測。導致Serverless被濫用的原因主要包括以下幾點：

1. 雲廠商提供Serverless函式的免費試用

近些年，各大雲廠商為了使用者體驗，均對使用者提供免費的Serverless套餐，包括每月免費的函式呼叫額度，這種方式雖然吸引了更多的使用者去使用Serverless函式, 但也使得攻擊者的攻擊成本大幅降低。

2. 使用者部署Serverless函式的成本低

由於Serverless服務端託管雲廠商的機制，故使用者只需實現函式的核心邏輯，而無須關心函式是如何被部署及執行的，利用這些特點，攻擊者可以編寫對其有利的Serverless函式並能省去部署的成本。

3. Serverless函式訪問域名可信

當使用者部署完Serverless函式後，需要透過觸發器去觸發函式的執行，通常使用者使用雲廠商提供的API閘道器作為觸發器，建立API閘道器觸發器之後，雲廠商會為使用者提供一個公網的域名，用於訪問使用者編寫的Serverless函式。需要注意的是，該公網域名通常是雲廠商域名相關的子域名，因而是相對可信的，鑑於此，攻擊者可以利用函式訪問域名的可信去隱藏其攻擊資產，躲避安全裝置的檢測。

五. 總結

本文詳細分析了雲原生應用面臨的風險，可以看出，雲原生應用相比傳統應用面臨的風險主要為應用架構變革及新的雲端計算模式帶來的風險，而針對應用本身的風險並無較大變化，因而對雲原生應用架構和無伺服器計算模式的深度理解將會有助於瞭解整個雲原生應用安全。

參考文獻

[1] https://owasp.org/www-project-top-ten/

[2] https://owasp.org/www-project-api-security/ 

[3] https://netflixtechblog.com/starting-the-avalanche-640e69b14a06 

[4] https://www.owasp.org/index.php/OWASP_Serverless_Top_10_Project 

[5] https://github.com/apache/openwhisk 

[6] https://github.com/kubeless/kubeless 

[7 https://github.com/openfaas/faas 

[8] https://github.com/fission/fission