最近幾年，無服務器計算技術實現了顯著的增長，同時也伴隨著新解決方案生態系統的蓬勃發展。這些新的解決方案提供了可觀察性、實時追蹤、部署框架、以及應用安全性。

[[259558]]

隨著無服務器安全風險逐漸引發人們的關注，那些嘲笑者和憤世嫉俗者們所謂“FUD”——恐懼、不確定、懷疑——的習慣又一次發作，他們指出，盡管無服務器技術在軟件快速部署和大幅降低TCO方面有著巨大的價值，但同時也帶來了新的安全挑戰。

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

衡量一項成熟技術的關鍵指標之一，是該技術的生態系統。是否擁有蓬勃發展的社區、廣泛的文檔、實踐指南和工具，決定了企業組織是否會信任并采用新的技術。

最近，云安全聯盟(Cloud Security Alliance，CSA)聯合PureSec公司合作撰寫了一份無服務器安全指南，這份指南從去年的版本中汲取了大部分的內容，同時增加了兩個重要的風險等級。

這份題為《無服務器應用12個最嚴重的風險》的指南，是針對那些處理無服務器應用的安全和開發受眾編寫的，但內容并不僅限于指出這些風險的存在，還為所有主流平臺提供了落地實踐。我們對風險類別的定義如下：

風險1：功能事件-數據注入

無服務器技術可以采用不同事件源輸入的數據，而且每個事件源都有自己特有的消息格式和編碼機制。這些事件消息中，可能包含了受黑客控制的、或者不受信任的數據輸入，這些是需要經過嚴格審查的。

風險2：認證失敗

由于無服務器改善了面向微服務的系統設計，因此應用可能包含數十個甚至數百個功能。如果不謹慎執行的話，身份驗證過程中就很容易出現錯誤。

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

云提供商提供了很多設置選項，可以根據特定需求調整服務。開箱即用的設置不一定是最安全的選擇。隨著越來越多的企業組織遷移到云端，云配置出現漏洞也越來越普遍。

風險4：過度特權功能權限和角色

管理功能權限和角色，是企業組織在把應用部署到云端時，面臨的最艱巨的安全挑戰之一。有時候開發人員想走捷徑，采用“通吃”的權限模型，這是很常見的。

風險5：功能監控和記錄功能不足

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

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

雖然第三方庫的不安全性，并不是只有無服務器技術才有的缺點，但由于缺乏應用網絡和行為安全控制能力，無服務器環境中檢測出的惡意軟件包要更加復雜一些。

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

應用秘密存儲最常出現的問題之一，就是把這些秘密信息簡單地保存成某個軟件項目中的一個純文本文件，或者是把這些秘密信息保存成一個作為環境變量的純文本文件。

風險8：拒絕服務和財務資源枯竭

無服務器架構具有自動可擴展和高可用性等特點，但是，與任何其他類型的應用一樣，無服務器需要采用良好的設計以避免出現瓶頸，是至關重要的。

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

業務邏輯操作是很多軟件中常常出現的問題。但是，無服務器應用有些特殊，它們通常遵循微服務設計的，其中包含的各種功能是鏈接在一起形成了一個邏輯整體的。如果執行不當的話，可能就會被攻擊者篡改預期的邏輯。

風險10：不恰當的異常處理和詳細錯誤消息

與標準應用的調試功能相比，無服務器應用的逐行調試功能是受到限制的，而且更復雜一些。因此，經常會出現很冗長的錯誤消息，這可能會導致敏感數據的泄漏。

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

隨著時間的推移，無服務器功能和相關的云資源可能會過時，應該被淘汰掉。處理過時的組件，是為了減少不必要的成本，并消除可以避免的受攻擊面。過時的無服務器應用組件，可能是那些不好的無服務器功能版本、未使用的云資源、不必要的事件源、未使用的角色或者身份、未使用的依存關系。

風險12：交叉執行數據持久性

無服務器平臺為應用開發人員提供本地磁盤存儲、環境變量和內存，用于執行任務。為了讓無服務器平臺能夠高效處理新的調用，云提供商們可能會在后續的調用中重復利用這個執行環境。如果無服務器執行環境被反復用于后續的調用，屬于不同的用戶或不同的會話，那么就有可能遺留下來敏感的數據，并出現敏感數據泄露。

該指南的目的是提高人們的認識，幫助企業組織安全地進行無服務器方面的創新，而不是傳播恐慌。任何平臺都存在安全風險，無服務器也不例外。CSA提出這些問題的目的，是為了鼓勵企業組織采用新的技術，同時避免風險和常見錯誤。