■ 山東 姜建華 趙長林

隨著開發(fā)及運維（DevOps）及微服務架構變得越來越普遍，APP的開發(fā)團隊正尋求使用更為輕量級的云服務來部署應用的工作負載。

一種常被采用的技術就是無服務器計算，它將整個的工作負載（容器和操作系統(tǒng)實例）都交給供應商的背板架構，從而使開發(fā)人員可以創(chuàng)建微服務的APP，僅要求在云供應商的環(huán)境中上傳和操作APP代碼。

然而，無服務器云架構使用的日漸增加暴露了一些安全團隊需要評估和解決的新的潛在風險。本文將討論關于無服務器架構的安全問題，以及解決或緩解這些問題的最佳方法。

無服務器的編碼風險

無服務器計算尤其易于遭受編碼安全風險。例如，惡意代碼的執(zhí)行可以經由無服務器架構產生，并且可以長時間存在于內存中。無服務器環(huán)境中的固有缺陷本身也是一個問題，因為這些缺陷會導致遠程代碼的執(zhí)行。

無服務器環(huán)境也容易產生代碼安全問題。由于容器的宿主平臺可能大規(guī)模地超出范圍，因此，團隊必須專注于保護輸入、代碼和執(zhí)行。在制定減輕無服務器安全風險的策略時，企業(yè)應當首先專注于靜態(tài)代碼的審查。為了掃描代碼，有些第三方的供應商可以整合到無服務器的環(huán)境中。

很多無服務器的編碼風險都會存在而不管代碼在何處和如何運行，由此導致如下的核心問題：

一是事件劫持。劫持缺陷仍可以影響代碼及其處理輸入的方式。改進的輸入驗證和預定義的數據庫層邏輯（例如存儲過程）有助于修復這個問題。

二是失敗的認證。企業(yè)必須重視無服務器APP用戶的角色定義和強認證的執(zhí)行。

三是不安全的APP秘密存儲。API密鑰、加密密鑰和其它秘密往往涉及到無服務器的功能執(zhí)行。安全團隊應當確保開發(fā)人員使用成熟的秘密管理工具和某種特定云的密鑰存儲。

四是異常處理不當。開發(fā)人員應確保錯誤和異常得到適當處理，以防止堆棧的痕跡被暴露或顯示。

無服務器環(huán)境中的身份和訪問問題

無服務器的另一個主要安全問題是特權和許可的控制。這種控制應當針對所有的無服務器應用程序，并由強健的“云身份和訪問管理（IAM）”實施。除了訪問無服務器功能的服務許可外，企業(yè)必須對無服務器功能得以運行的許可實現最少化。

初涉此領域的企業(yè)需要在本地云環(huán)境中記錄每一個無服務器的API事件（包括訪問、修改及執(zhí)行等）。這可以由與亞馬遜的AWS CloudTrail云資源調用記錄服務等類似的服務實現。

無服務器的安全問題并不是只有編碼和云身份及訪問管理這兩方面。其它的需要關注的方面都與配置有關：企業(yè)應當通過限制內存利用和可能的無服務器輸入手段而減輕不安全的部署設置所帶來的問題。調整應用程序的執(zhí)行超時有助于減輕拒絕服務攻擊和經濟損失。

當前，保障無服務器架構的云的和本地的安全選項還是有限的。為真正保障無服務器的安全，企業(yè)可能需要全面的靜態(tài)代碼分析，對內存進行分析用以應對緩沖區(qū)劫持，還要對輸入和行為進行動態(tài)掃描，并且記錄所有活動，以及其它的安全控制。目前，多數供應商僅僅提供了定義運營要素的能力，如內存的大小和使用、日志，以及對功能和無服務器相關服務自身的一些許可。

企業(yè)還可以整合一些工具用以提供對無服務器架構實施的透明度。這些工具有很多，如Check Point Protego以及Dashbird等。企業(yè)還可以考慮可以將安全性增加到持續(xù)集成或持續(xù)交付階段的工具以及在云中實施的工具。許多容器安全工具，如Palo Alto Prisma和Aqua都可以實現此功能。但是安全從業(yè)者必須明確：所有這些產品都要求大量的資源，因此無法應對所有可能發(fā)生的情況。