近年來，無服務器計算技術有了顯著增長，新解決方案的生態系統也蓬勃發展。這些新解決方案提供可觀察性、實時跟蹤、部署框架和應用程序安全性。

無服務器安全

隨著無服務器安全的風險越來越受到關注，荒謬和憤世嫉俗的人稱其為“FUD”的習慣——恐懼、不確定性和懷疑。他們指出，雖然在軟件和軟件中快速部署無服務器技術對于降低 TCO 具有巨大價值，但同時也帶來了新的安全挑戰。

不斷發展的無服務器生態系統

成熟技術的關鍵指標之一是技術的生態系統。您是否擁有繁榮的社區、廣泛的文檔、最佳實踐指南和工具將決定您的組織是否信任并采用新技術。

最近，云安全聯盟 (CSA) 與人合著了一份無服務器安全指南，該指南借鑒了去年發布的大部分內容，并增加了兩個重要的風險級別。

該指南“無服務器應用程序的 12 大最大風險”是為處理無服務器應用程序的安全和開發人員編寫的，但不僅指出了這些風險的存在，還為所有主要平臺提供了最佳實踐。我們定義風險類別如下：

風險一：功能性事件——數據注入

技術可以消費來自不同事件源的數據輸入，每個事件源都有自己獨特的消息格式和編碼機制。這些事件消息可能包含攻擊者控制的或不受信任的數據，需要仔細檢查。

風險二：認證失敗

由于沒有服務器改進面向微服務的系統的設計，因此應用程序可以包含數十個甚至數百個功能。如果做得不仔細，在認證過程中很容易出錯。

風險 3：不安全的無服務器部署配置

云提供商提供了許多可根據特定需求定制的設置選項。開箱即用的設置不一定是最安全的選擇。隨著越來越多的企業組織遷移到云端，云配置中的漏洞變得越來越普遍。

風險四：權限函數權限和角色過多

管理功能權限和角色是組織在將應用程序部署到云時面臨的最嚴峻的安全挑戰之一。有時開發人員想走捷徑，采用“pass-all”權限模型，這很常見。風險 5：功能監控和文檔不足

雖然大多數云提供商提供非常強大的日志記錄功能it技術，但這些日志不一定適合在應用程序層提供安全事件的完整審計跟蹤。

風險六：依賴不安全的第三方

雖然第三方庫的不安全不僅是技術的短板，應用網絡和行為安全控制的缺失it技術，環境下惡意軟件包的檢測也更加復雜。

風險七：不安全的應用秘密存儲

應用程序秘密存儲最常見的問題之一是在軟件項目中將秘密保存為純文本文件，或者將秘密保存為純文本文件作為環境變量。

風險 8：拒絕服務和耗盡財務資源

無服務器架構的特點是自動可擴展性和高可用性，但與任何其他類型的應用程序一樣，無服務器需要最佳實踐和良好的設計來避免瓶頸。

風險 9：無服務器業務邏輯操作

業務邏輯操作是很多軟件的通病。但是，無服務器應用程序有些特殊。它們通常在設計時考慮到微服務，所涉及的各種功能鏈接在一起形成一個邏輯整體。如果實施不當，攻擊者可能會篡改預期的邏輯。

風險 10：異常處理不當和錯誤消息冗長

無服務器應用程序的逐行調試是有限的，并且比標準應用程序調試功能更復雜。因此，經常會出現非常冗長的錯誤消息，這可能會導致敏感數據泄露。

風險 11：遺留/未使用的功能和云資源

隨著時間的推移，無服務器功能和相關的云資源可能會過時，應該被淘汰。處理過時的組件以減少不必要的成本并消除可避免的攻擊面。過時的無服務器應用程序組件，可能是無服務器功能的錯誤版本，未使用的云資源，不必要的事件源，未使用的角色或身份，未使用的依賴項。

風險十二：數據持久化的交叉執行

無服務器平臺為應用程序開發人員提供本地磁盤存儲、環境變量和用于執行任務的內存。為了讓無服務器平臺有效地處理新的調用，云提供商可以為后續調用重用該執行環境。如果執行環境被重復用于后續調用，屬于不同用戶或不同，可能會遺留敏感數據，導致敏感數據泄露。

本指南的目的是提高認識并幫助組織組織安全的無服務器創新，而不是引起恐慌。任何平臺都有安全隱患，任何服務器也不例外。CSA 提出這些問題的目的是鼓勵組織采用新技術，同時避免風險和常見錯誤。