解決無服務器架構的安全問題

■ 山東 姜建華 趙長林

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

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

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

無服務器的編碼風險

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

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

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

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

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

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

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

無服務器環境中的身份和訪問問題

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

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

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

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

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