[[389866]]

無服務器架構使組織無需運行內部服務器即可大規模構建和部署軟件。微服務等功能即服務(FaaS)模型的廣泛應用也證明了無服務器架構的普及。無服務器架構不僅節省了大量成本，并且其可擴展性為組織的業務增長提供了更大的靈活性。

以下將概述組織確保無服務器架構的安全性應該考慮的關鍵領域。雖然適合組織生態系統的解決方案對其來說是獨一無二的，但以下內容將為組織采用無服務器架構提供堅實的基礎。

不斷變化的攻擊面

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

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

而且，由于無服務器架構的入口點繁多且拓撲復雜，無服務器攻擊面是多層和多維的。因此其攻擊面具有高度的復雜性和波動性，因此幾乎不可能進行人工映射和監視。

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

自動化監視和發現系統可以使組織更好地防范威脅。但組織的安全人員只能保護自己看到的內容，除非其監視工具可以隨著系統的擴展增加其可見性范圍，否則無服務器架構的大部分將會受到威脅。

在組織的無服務器架構中，很有可能會采用自動連續部署。這意味著組織攻擊面上的薄弱點也在不斷地自動生成。如果組織的監控和發現功能無法跟上威脅的發展，那么在新的細分市場中很容易受到攻擊。

幸運的是，有一些平臺可以實時映射和監視無服務器架構。其中許多功能還具有可以擴展的安全性，并確定未經授權的用戶可以惡意操縱數據的位置。其中一些平臺是專門為無服務器安全而設計的。

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

無服務器架構的最常見風險來自數據注入。自從第一個無服務器系統上線運營以來，注入漏洞已成為無服務器安全討論的主要話題。

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

可以說，規模越大，從中提取數據的資源就越豐富。這些不同的源類型均帶有唯一的消息格式和編碼方案。其中任何一個都可能包含不受信任或攻擊者控制的輸入數據。預測和消除這些惡意注入對于組織來說可能是一個艱巨的挑戰。

投資于功能監視和日志記錄以實現強大的無服務器安全性

在這種情況下的“投資”不一定指的是金融投資，投入的時間和精力更為重要，盡管如果發現堆棧不足，則可能會帶來額外的成本。重大安全漏洞造成的成本影響遠遠超過組織在安全方面的成本支出。

許多云計算供應商提供了日志記錄功能的基本形式。常見示例包括AWS CloudWatch或Azure Functions。盡管這些功能為組織的環境啟用了基本的日志記錄，但是它們的成本可能很高，并且一旦組織的無服務器架構擴展到一定規?；蜻_到一定程度的復雜性時，它們可能無法滿足組織的需求。

開箱即用的解決方案并不總是適合組織的需求。盡管它們具有基本功能，但可能缺乏在應用程序層進行全面安全事件審核的功能。組織的無服務器架構的規模和形態將根據組織的獨特設計而定，有許多專家構建的平臺和工具可用來彌補這些監視和日志記錄的不足。

創建獨特的邏輯并利用中間云存儲服務

如上所述，在功能監視和日志記錄投入一些時間和精力是值得的。在無服務器環境中使用功能日志記錄要克服的主要障礙是，監視和日志記錄存在于組織的數據中心范圍之外。

通過讓組織的工程師、無服務器開發人員和DevOps團隊創建其架構所獨有的日志記錄邏輯，可以對此進行協調。組織將需要一種邏輯從各種云功能和服務中收集日志，并將其推送到遠程安全信息和事件管理(SIEM)系統中。

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

無論組織使用哪種架構模型，這些報告都是至關重要的報告。但是，在復雜且不斷變化的無服務器環境中，其監視和可見性可能很棘手。因此，需要創建可在單個存儲庫中隔離、提取和整理這些報告的邏輯，以便可以實時監視整個架構至關重要。

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

功能特權過多和身份驗證失敗

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

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

隨著無服務器生態系統的發展，采用的身份驗證方案失敗或效率低下，可能會為未經授權的用戶創建無限數量的訪問點。這本身是危險的，如果組織的功能特權過多，那將是災難性的事件。

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

如果這兩個缺陷都是由于未遵循盡職調查而存在的，那么惡意攻擊者或外部用戶很容易訪問到組織的系統。身份驗證失敗之后，就會出現漏洞，特權功能權限一旦進入就可能竅取重要數據。組織在設計、構建和部署過程中，如果深思熟慮，可以避免這兩種情況。

無服務器安全性更多的注意事項

當然，還有其他考慮。例如，需要記住要停用過時的功能和云計算資源。這不僅有助于簡化成本，而且原有和未使用的組件會在無服務器架構的攻擊面增加不必要的維度。自動定期清理環境并刪除未使用的角色、標識和依賴項。

避免重用執行環境也很重要。對于云計算提供商來說，在調用之間執行環境是很有誘惑力的。這使得他們的云平臺在處理新的調用時更加高效。然而，當執行環境繼續運行時，可能會留下有價值的敏感數據，因此組織需要確保提高效率不會以犧牲安全性為代價。

組織的無服務器環境是唯一的，因此實現無服務器安全性的方法也應該如此

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