Serverless安全揭秘:架構、風險與防護措施

Serverless簡介

Serverless(又稱為無伺服器)架構是一種全新的雲計算模式,它是在容器技術和當前服務模式基礎之上發展起來的,它更多的是強調後端服務與函式服務相結合,使開發者無需關注後端服務具體實現,而更側重關注自己業務邏輯程式碼的實現。隨著雲原生技術的不斷髮展,應用部署模式已逐漸趨向於“業務邏輯實現與基礎設施分離”的設計原則。Serverless架構完美詮釋了這種新型的應用部署模式和設計原則。從雲原生整體發展路線來看,Serverless模式更趨近於雲原生最終的發展方向。

Serverless實現方式:BaaS和FaaS

雲計算發展歷程從IaaS(Infrastructure as a Service,基礎設施即服務)到PaaS(Platform as a Service,平臺即服務),再到SaaS(Software-as-a-Service,軟體即服務),逐漸的將去伺服器化的趨勢表現的愈發明顯,而SaaS的下一個階段可能就是BaaS+FaaS+Others,即Serverless。提到Serverless,我們首先得解下什麼是BaaS和FaaS。BaaS(Backend as a Service,後端即服務)和FaaS(Functions as a Service,函式即服務)是Serverless兩種主要的實現方式。BaaS可以理解為是一個整合和開放各種在應用開發中需要的服務能力的平臺,它透過建立大量重複的程式碼功能,方便應用基於服務的快速開發和構建。FaaS是Serverless主要的實現方式,開發者透過編寫一段邏輯程式碼來定義函式呼叫方式,當事件觸發時函式被呼叫執行。

FaaS本質上是一種事件驅動並由訊息觸發的服務,事件型別可以是一個HTTP請求,也可以是一次使用者操作,函式可以看作是完成某個功能或任務的程式碼片段。相比傳統應用執行模式,Serverless業務程式碼被拆分成了函式粒度,不同函式表示不同的功能,函式之間呼叫關係也更加複雜。

Serverless安全揭秘:架構、風險與防護措施

雲計算發展歷程與FaaS所處的地位

Serverless應用架構

通常Serverless應用都是基於無伺服器應用框架Serverless Framework構建完成的。開發者無需關心底層資源,即可快速部署完整可用的Serverless應用架構,同時Serverless平臺具有資源編排、自動伸縮、事件驅動等能力,覆蓋編碼、除錯、測試、部署等全生命週期,幫助開發者聯動各類雲元件資源,迅速構建完整的 Serverless 應用。

目前常見的雲廠商Serverless應用服務支援各類 Web 框架快速建立、遷移上雲,可以實現Express、Next。js、Python Flask、PHP Laravel、Koa、Egg。js、Nuxt。js等框架應用的快速部署。開發者無需進行復雜的配置,透過Web Fuction即可快速搭建各類場景下的Serverless應用,輕鬆實現雲函式、API閘道器、COS、DB 等資源的建立、配置和部署。Serverless提供從初始化、編碼、除錯、資源配置和部署釋出,到業務監控告警、實時日誌、故障排查的一站式解決方案。

從架構層面來看,Serverless由BaaS和FaaS共同構成了完整的應用架構。Serverless計算平臺可以幫助開發者完成構建服務執行環境,開發者無需購買伺服器,雲廠商負責提供並維護基礎設施資源和後端服務元件。Serverless架構具有自動擴縮容的特性,當應用部署後雲計算平臺會為Serverless應用提供足夠的資源來支援應用穩定執行。

Serverless安全揭秘:架構、風險與防護措施

Serverless元件架構圖

無伺服器雲函式(Serverless Cloud Function,SCF)是一種為企業和開發者們提供的無伺服器執行環境。開發者透過Web IDE或者本地IDE編寫程式碼,然後將程式碼和所需依賴一起打包部署到雲函式平臺。開發者會在業務程式碼中會提前定義好函式具體呼叫方式,如訪問資料庫、物件儲存、第三方服務等介面,使用者透過提前定義好的請求方式去訪問對應的服務,平臺會根據使用者請求去拉起相應的計算資源執行業務程式碼。

Serverless安全揭秘:架構、風險與防護措施

Serverless執行原理圖

安全風險共擔模型

由於Serverless後端基礎設施和服務主要是由雲廠商負責的,但是Serverless應用本身是面向企業和開發者的,Serverless應用允許開發者上傳自己的程式碼到服務端,同時允許開發者對應用配置做修改,若開發者上傳的程式碼中包含漏洞或應用配置錯誤,將導致應用面臨風險,因此Serverless安全問題相對複雜。

Serverless的安全風險責任劃分可以參照Serverless安全風險共擔模型。對於雲廠商來說,首先需要保障雲基礎環境安全,包括所有的底層基礎設施和後端服務軟體的安全性。同時雲廠商也擔負著Serverless平臺應用整體安全防護責任,藉助API閘道器、雲防護等優勢來保障Serverless應用安全。對於使用者來說,需要保證上傳到服務端的程式碼是安全的、同時確保應用策略配置安全,避免程式碼中存在漏洞或策略配置不當導致安全風險。所以從本質上來說,Serverless的安全性是需要雲廠商和使用者雙方共同承擔的。

Serverless安全揭秘:架構、風險與防護措施

Serverless安全風險共擔模型

Serverless安全風險

Serverless一般的攻擊流程:攻擊者透過應用程式漏洞或者元件漏洞實現初始訪問許可權,當獲取到伺服器許可權後,攻擊者會嘗試查詢並竊取使用者憑據或服務憑據,然後利用可用憑證進一步橫向攻擊其他雲服務。整個攻擊過程包含但不限於以下攻擊方式:

Serverless安全揭秘:架構、風險與防護措施

騰訊安全雲鼎實驗室根據自身安全實踐,結合國內外眾多相關案例,總結出了Serverless常見風險項,用以幫助開發以及運維人員識別各類風險,從而有效的保障Serverless應用安全。主要安全風險可參照下圖:

Serverless安全揭秘:架構、風險與防護措施

Serverless安全風險

1.應用程式漏洞

對於Serverless應用而言,SQL注入、命令注入、XSS等傳統漏洞風險在Serverless應用中同樣存在。若Serverless應用在實現過程中沒有對外部輸入進行嚴格校驗(包括使用者輸入和各應用間互動)則可能導致注入風險的發生。傳統應用的注入防護一般是對使用者輸入進行過濾和限制,但是Serverless應用內部網路相比傳統網路更加複雜,事件輸入可能來自任何雲服務(如伺服器、雲端儲存、電子郵件、訊息服務等),因此僅僅依靠編寫安全的程式碼和依賴傳統WAF防護並不能完全杜絕注入風險的發生。

示例: 檔案上傳處未過濾使用者輸入導致命令執行漏洞。由於開發者在編寫程式碼時使用了命令拼接的方式來構造路徑,但是沒有對檔名進行嚴格過濾,導致攻擊者可以控制傳入的內容,導致命令執行漏洞的產生。

Serverless安全揭秘:架構、風險與防護措施

Serverless安全揭秘:架構、風險與防護措施

2.拒絕錢包攻擊

DoW(Denial of Wallet,拒絕錢包攻擊)是針對雲平臺賬戶的DoS方式,其目的是透過高併發來耗盡使用者賬戶可用餘額。DoW攻擊與傳統拒絕服務(DoS)攻擊方式類似,惡意攻擊者向透過構造大量併發請求來觸發函式呼叫,由於Serverless是按照資源使用量和函式呼叫次數來收費的,當有大量呼叫產生時,服務會自動擴充套件,這將導致使用者賬戶可用餘額快速被消耗。DoW攻擊的一個典型的場景是在使用者訂閱web程式上生成大量虛假使用者,透過大量使用者訪問API端點造成大量資源消耗導致賬戶金額耗盡。

3.資源濫用風險

近年來,隨著Severless的快速發展,各種服務濫用現象也相繼出現,主要體現在雲函式濫用和Serverless基礎設施濫用。雲函式常被惡意人員用作構建代理池、隱藏C2和構建webshell,惡意人員透過構建此類應用來達到隱藏其客戶端真實IP的目的。Serverless應用也常被用於構建掃描、釣魚等攻擊平臺,攻擊者透過構建此類應用來實現對外部系統的掃描探測、釣魚竊取使用者資料等目的。這些濫用行為導致雲基礎設施資源被惡意利用和消耗,給雲服務的正常使用和監測帶來了極大的困擾。

示例: 使用Serverless構建掃描應用導致服務濫用。惡意攻擊人員透過上傳程式碼構建掃描應用,透過本地呼叫雲函式資源來實現動態IP掃描的目的。

Serverless安全揭秘:架構、風險與防護措施

4.第三方API和元件不安全接入

由於Serverless服務一般會接入多個雲服務元件,包括雲API、API閘道器、事件觸發器等。若雲服務或元件在接入Serverless服務時未對元件身份或接收資料進行校驗,則可能導致安全風險的發生。接入資料來源的增加會導致攻擊面擴大,傳統應用只能從單一伺服器上獲取敏感資料,而Serverless應用通常會接入大量資料來源,若攻擊者針對各資料來源進行攻擊,則可能獲取到大量敏感資料。

5.供應鏈攻擊風險

近年來,供應鏈安全事件時有發生,一些嚴重的漏洞可能來自於開源庫和框架,nodejs生態系統的一項統計表明通常我們部署的97%的程式碼來自於開源庫和開源元件,所以供應鏈攻擊對Serverless來說是一項非常重要的安全風險。

6.執行時安全風險

若攻擊者已經透過某種方式獲得了Serverless伺服器許可權後,則可能透過替換載入程式的方式攻擊Serverless應用服務,從而導致Serverless應用例項被接管。如果攻擊者可以修改Serverless ACL策略,則可以透過修改函式超時時間,增加服務冷啟動時間,或者透過Serverless預熱外掛增加執行時時長等方式實現持久化控制。

7.配置不當導致許可權濫用

當Serverless存在不安全的IAM配置時,將導致可執行惡意操作以及進行雲平臺身份越權。Serverless構建的應用程式通常包含數十或數百個函式,每個函式都有自己特定的功能和用途,這些功能被編織在一起並被編排以形成整個系統邏輯。一些函式可能會公開公共的WEB API介面,因此需要強大的身份驗證方案為相關功能、事件觸發提供訪問控制保護。當建立IAM策略時,如果沒有遵循最小許可權原則,則可能導致分配給函式的IAM角色過於寬鬆,攻擊者可能會利用函式中的漏洞橫向移動到雲賬戶中的其它資源。

8.日誌和監控不足

傳統的應用已經有比較成熟的日誌管理和分析工具,而Serverless函式級別的日誌分析工具還未被廣泛採用。由於Serverless應用函式數量多、生命週期短,各函式間呼叫關係複雜,因此任何一個點都可能成為攻擊突破口。對於雲廠商來說,需要具備完備的安全防護和應用監測體系,才能更好的保障Serverless應用和服務的安全。

9.雲環境網路攻擊風險

攻擊者可利用漏洞或錯誤的雲平臺架構配置,從公有云環境橫向移動到雲管理內部網路(如公有云到IDC網路);或者從公有云網路橫向移動到客戶構建的網路環境中,導致嚴重的攻擊事件產生。

10.雲特性攻擊風險

利用雲上服務的特性,也可展開更多的攻擊,例如透過Serverless服務竊取到雲服務憑據或角色臨時訪問憑據等資訊後,可利用這些憑據獲取對應服務的相應控制權限;又或是利用容器逃逸漏洞進行更深入攻擊操作等。

11.雲資源消耗攻擊風險

挖礦攻擊作為一種較為常見的攻擊形式,其威脅在雲環境中也同樣存在,Serverless服務同樣存在雲資源消耗攻擊風險,攻擊者攻擊Serverless服務用以進行挖礦操作,消耗客戶的資源和資金,給客戶造成影響。攻擊者瞄準雲上脆弱資產,將挖礦木馬植入雲資源中進行挖礦,這將導致客戶資源受到較大威脅。

12.金鑰儲存風險

Serverless服務中同樣存在金鑰以及憑據的儲存安全風險,攻擊者可以利用漏洞,在Serverless服環境變數中獲取憑證、或是在程式碼中查詢明文編寫的金鑰。

13.後門持久化風險

利用Serverless服務的彈性原則,與傳統攻擊所部署的後門相比,攻擊者可以在Serverless服務中構建更加隱蔽的後門。透過利用這些後門,可以達到持久化攻擊的效果。

Serverless防護措施

我們根據大量資料和實際案例,結合Serverless各類風險總結出了Serverless風險防護措施。通過了解這些安全防護手段,可以幫助開發以及運維人員識別並消除各類風險,從而更好的保障雲上資產安全。主要的安全防護措施總結如下:

Serverless安全揭秘:架構、風險與防護措施

Serverless安全防護

1.使用安全漏洞緩解措施

Serverless的安全性依靠使用者和雲廠商共同來保障,對於開發人員來說,最基礎的要求開發人員編寫程式碼時遵循安全開發原則,保證業務程式碼本身不存在安全漏洞;其次需要保證Serverless應用配置安全,避免因為配置不當導致不安全風險的發生。對於雲廠商來說,需要保證Serverless應用與其他雲服務元件的介面呼叫安全,對於重要的功能需要在功能模組之間放置防火牆做好隔離,當基礎應用存在注入等問題時,防火牆會起到一定緩解作用。其次由於Serverless通常接入應用元件和資料較多,因此需要使用https/tls來保障資料在傳輸過程中的安全性,同時使用KMS(Key Management Service,金鑰管理系統)來保障服務執行時的金鑰使用安全,避免將金鑰等敏感資料硬編碼或寫入環境變數中。

2.Dos攻擊緩解與防護

開發者透過編寫高效的Serverless函式來執行離散的目標任務,為Serverless功能執行設定適當的超時時間和磁碟使用限制,透過對API呼叫設定請求限制,對Serverless功能實施適當的訪問控制等來緩解Dos攻擊風險。同時使用不易受到ReDos等應用層Dos攻擊的API、模組和庫來避免Dos問題的產生。

3.Serverless濫用防護

針對Serverless濫用問題,需要從Serverless應用本身做限制,如限制某些庫和方法的使用,透過有效監控和阻斷來提高Serverless服務濫用的門檻,完善異常事件發現和監測機制,當發現濫用行為時及時觸發告警和阻斷濫用行為。

4.第三方依賴庫防護

由於Serverless依賴於第三方元件和庫構建應用程式和執行環境,因此第三方依賴庫的安全性直接影響到Serverless應用和平臺的安全。構建完善的第三方依賴庫防護和監測機制對保障Serverless應用安全起到極大的意義。

5.IAM訪問控制防護

在Serverless中,執行的最小單元通常為一個個函式,Serverless中最小特權原則透過事先定義一組具有訪問許可權的角色,並賦予函式不同的角色,從而可以實現函式層面的訪問控制,避免統一的許可權分配導致的各類安全風險。

6.Serverless平臺防護

對於雲廠商而言,要避免使用過時的函式和雲資源,重複利用資源雖然有助於節約成本,但是會導致Serverless攻擊面增加,因此必須定期清理伺服器環境,刪除未使用的角色,身份和依賴項等。其次要避免重用執行環境,對於雲廠商而言,在兩次呼叫之間保留執行環境,可以提高呼叫效率,但是當執行環境被保留下來時,部分敏感資料可能會被保留下來,這將導致一定的安全風險。

7.完善安全監控和日誌記錄

由於函式的生命週期極短,並且隨著擴充套件部署越來越多的函式,函式呼叫數量不斷增加,各函式功能之間存在複雜的關聯性,攻擊可能從任何一個點發起。因此需要建立完善監控機制,例如使用函式級別的日誌分析工具來提高監控能力,及時發現攻擊行為。

騰訊雲Serverless應用服務目前已經具備完善的安全防護體系。以騰訊云云函式(SCF)為例,在金鑰安全管理上,騰訊雲使用了金鑰管理系統(Key Management Service,KMS)。KMS使用經過第三方認證的硬體安全模組 HSM(Hardware Security Module)來生成和保護金鑰,實現金鑰全生命週期管理和保障資料安全能力。同時雲函式也完善了配套的監控和告警機制,提供如呼叫次數、記憶體使用、併發使用、超時、程式碼錯誤等多維度的監控和告警能力,幫助運維人員輕鬆實現應用後期維護。對於基礎設施、資源管理、安全管控、容災等能力是雲函式平臺必備的基礎能力,也是雲平臺的核心能力。

Serverless安全揭秘:架構、風險與防護措施

金鑰管理系統(KMS)產品架構圖

雲安全攻防矩陣V3。0釋出

騰訊安全雲鼎實驗室根據自身安全實踐,結合國內外相關案例,對雲上主流應用安全風險進行抽象,繪製出了雲安全攻防矩陣。企業和開發者可參照該矩陣瞭解雲服務攻擊手法,幫助開發以及運維人員識別各類風險。我們的雲安全攻防矩陣V3。0已經發布了,此次新增了Serverless安全矩陣模組,目前3。0版本已經涵蓋雲伺服器、容器、cos儲存桶、Serverless等主流雲服務。也歡迎大家積極踴躍與我們溝通交流,一起為維護雲安全貢獻力量。矩陣詳情可檢視雲鼎實驗室官網:

https://cloudsec。tencent。com/home/

寫在後面

Serverless作為一種新的技術和架構模式,雖然起步較晚但發展迅猛,短短几年時間已經推出多款備受開發者追捧的應用,吸引了大批開發者的關注。作為一個相對比較新鮮的事物,Serverless還有很多領域和價值值得我們去探索。隨著容器技術、IoT、5G、區塊鏈等新興技術的發展,技術上也逐漸趨向於中心化、輕量虛擬化、細粒度計算等,而Serverless也將借勢發展,相信不久的將來Serverless必將在雲計算的舞臺上大放異彩。