無服務器（Serverless）架構使組織無需內部服務器即可大規模構建和部署軟件。像函數即服務（FaaS）模型這樣的微服務盛行，推動了無服務器架構的普及。無服務器架構能夠節省巨大的成本，并為大規模可伸縮性提供靈活性。

　　本文將概述確保無服務器架構的安全性應考慮的關鍵領域。雖然最適合的無服務器生態系統的解決方案是獨一無二的，但以下內容將為建立無服務器架構安全方法提供堅實的基礎。

　　流動的攻擊面

　　簡而言之，軟件環境的攻擊面包括未經授權用戶可以輸入或提取數據的所有點。了解和監控這些點是有效實現無服務器安全的關鍵。

　　無服務器系統由數十個、數百個甚至數千個組件組成。每一個新的工具、服務或平臺集成到無服務器系統中，都為惡意和未經授權的用戶提供了新的切入點。每次擴展和修整無服務器架構時，攻擊面都會發生變化。

　　此外，由于無服務器架構的入口點眾多且拓撲復雜，無服務器攻擊面是多層次、多維度的。無服務器架構的攻擊面具有很高的復雜性和波動性，因此人工映射和監控這些攻擊面幾乎不可能。

　　自動映射和監控無服務器架構

　　對于無服務器系統的自動化監控和發現，使你可以領先威脅一步，找到系統的安全薄弱點。你只能保護你能看到的東西。除非監控工具可以隨著系統的擴展而增加其可見性范圍，否則系統的大部分可見性將很快消失。

　　在無服務器架構中，很有可能會采用自動連續部署。這意味著攻擊面上的新弱點也在不斷地自動生成。如果監控和發現能力無法跟上，無服務器架構中新的部分將很容易受到攻擊。

　　幸運的是，有可用的平臺可以實時映射和監控無服務器架構。許多平臺功能擴展了安全性，能指出未經授權的用戶可以惡意操縱數據的位置。其中的某些平臺在設計時特別考慮了無服務器安全性。

　　數據注入：最常見的無服務器安全風險

　　對于無服務器架構，數據注入是最常見安全風險。自第一個無服務器系統上線以來，注入漏洞已成為無服務器安全討論的普遍特征。

　　無服務器架構的每個組件和函數都需要來自大量來源的輸入。這些輸入可能是云存儲事件、來自API網關的命令、消息隊列事件、數據庫更改、來自IoT遙測的信號、甚至是電子郵件。這個輸入列表實際上是無限的，僅受限于架構的規模和內容。

　　可以說，規模越大，函數輸入數據的來源就越豐富。

　　這些確實是已看到的問題。每一種不同類型的來源均帶有獨特的消息格式和編碼方案。其中的任何一種都可能包含不受信任或受攻擊者控制的輸入。預測和消除這些惡意注入是一個艱巨的挑戰。

　　投資函數監控和日志記錄，實現強大的無服務器安全性

　　在這種情況下，“投資”不一定指金融投資。時間和精力更為重要，盡管已發現投入時間和精力不足，會帶來額外的代價。不要拖延時間和精力的投入。重大安全漏洞造成的代價影響，遠遠超過保護自己免受此類侵害的相對較低的投入。

　　許多云供應商提供了基本形式的日志記錄功能或函數，常見示例包括AWS CloudWatch或Azure函數。盡管這些函數為無服務器環境啟用了非常基本的日志記錄，但是代價可能很高，并且一旦無服務器架構擴展到一定規模或一定程度的復雜性時，它們就可能無法滿足你的要求。

　　開箱即用的解決方案并不總是適合需求。盡管它們具有基本函數，但它們可能缺乏在應用程序層進行全面安全事件審計的能力。無服務器架構的規模和形態的設計越獨特，這種解決方案的不適合性便越正確。有許多專家構建的平臺和工具可用來彌補這些監控和日志記錄的不足。

　　如何實施日志記錄

　　正如本文所說，函數監控和日志記錄需要（但值得）投入一些時間和精力。在無服務器環境中使用函數日志記錄要克服的主要障礙是，監控和日志記錄存在于組織數據中心范圍之外。

　　通過協調工程師，無服務器開發人員和DevOps團隊來創建無服務器架構獨有的日志記錄邏輯，該邏輯可以從各種云函數和服務中收集日志，并將其推送到遠程SIEM（安全信息和事件管理）系統上。

　　在無服務器環境中一些已知的特別重要的日志報告類型包括身份驗證和授權、嚴重錯誤和故障、更改、惡意軟件活動、網絡活動和資源訪問。

　　無論使用哪種無服務器架構模型，其中的許多日志報告都是關鍵報告。但是，在復雜且不斷變化的無服務器環境中，監控和可見性可能很棘手。創建可在單個存儲庫中隔離，提取和整理這些日志報告的邏輯，對于實時監控整個架構至關重要。

　　通過日志邏輯收集的日志需要存儲在某個地方。這是中間云存儲服務發揮作用的地方。通過使用單個外部系統來整理整個無服務器生態系統中的日志記錄信息，對安全事件進行實時監控。

　　在無服務器架構的拓撲中跨所有無服務器函數跟蹤和遏制攻擊者和惡意/未經授權的輸入，而無需考慮層。

　　函數權限過高和身份驗證失敗

　　如果沒有對函數和用戶進行盡職調查和適當的審查，則無服務器架構中可能存在致命的弱點組合。

　　首先是健壯的身份驗證。無服務器通常意味著面向微服務的架構設計。微服務架構可以包含數百個單獨的函數。除了充當其他進程的代理外，許多無服務器函數還會使用公共Web API暴露在外。這就是為什么應用健壯的身份驗證方案至關重要的原因。

　　隨著無服務器系統的發展，身份驗證方案失敗或效率低下，可能會為未經授權的用戶創建無限數量的訪問點。這本身是危險的，但是如果函數權限過高，則可能會造成災難性的后果。

　　在具有數十甚至數百個組件的無服務器環境中，管理函數權限和角色感覺就像一場艱苦的戰斗。工程師犯下的最常見的安全錯誤之一是試圖偷工減料并應用“包羅萬象”的權限模型。盡管這樣可以節省時間，但它使無服務器環境中的所有內容都極易受到攻擊。

　　如果由于未遵守盡職調查而同時存在以上兩個缺陷，則無服務器系統很容易被惡意外部用戶訪問。身份驗證失敗會打開大門，函數權限過高會將無服務器系統交給進入到系統的惡意外部用戶。在設計，構建和部署過程中通過透徹周到的考慮，可以避免這兩種情況。

　　進一步的無服務器安全注意事項

　　當然，還有其他考慮。例如，切記要停用過時的函數和云資源。這不僅有助于節約成本，而且舊的和未使用的組件會增加不必要的架構攻擊面的維度。定期自動整理無服務器環境，并刪除未使用的角色，身份和依賴項。

　　避免重用執行環境也很重要。對于云供應商而言，在兩次調用之間保留執行環境可能很誘人。它使平臺在處理新的調用時效率更高。但是，當執行環境被保留下來時，有價值的敏感數據可能會被保留下來。確保別以犧牲安全性為代價來實現效率。

　　無服務器環境是獨特的，因此實現無服務器安全性的方法也應是獨特的。

　　這始終是最重要的考慮因素。無論是部署配置，權限模型還是日志記錄工具，開箱即用的解決方案都只能提供通用的保護。獨特的無服務器環境需要一種獨特的無服務器安全方法。