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

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

流動的攻擊面

簡而言之，軟件環(huán)境的攻擊面包括未經(jīng)授權用戶可以輸入或提取數(shù)據(jù)的所有點。了解和監(jiān)控這些點是有效實現(xiàn)無服務器安全的關鍵。

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

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

自動映射和監(jiān)控無服務器架構

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

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

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

數(shù)據(jù)注入：最常見的無服務器安全風險

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

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

可以說，規(guī)模越大，函數(shù)輸入數(shù)據(jù)的來源就越豐富。

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

投資函數(shù)監(jiān)控和日志記錄，實現(xiàn)強大的無服務器安全性

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

許多云供應商提供了基本形式的日志記錄功能或函數(shù)，常見示例包括AWS CloudWatch或Azure函數(shù)。盡管這些函數(shù)為無服務器環(huán)境啟用了非?；镜娜罩居涗洠谴鷥r可能很高，并且一旦無服務器架構擴展到一定規(guī)模或一定程度的復雜性時，它們就可能無法滿足你的要求。

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

如何實施日志記錄

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

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

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

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

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

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

函數(shù)權限過高和身份驗證失敗

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

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

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

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

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

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

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

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

無服務器環(huán)境是獨特的，因此實現(xiàn)無服務器安全性的方法也應是獨特的。

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

編輯：jq