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

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

不斷變化的攻擊面

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

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

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

無服務器架構(gòu)的自動映射和監(jiān)視

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

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

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

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

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

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

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

投資于功能監(jiān)視和日志記錄以實現(xiàn)強大的無服務器安全性

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

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

開箱即用的解決方案并不總是適合組織的需求。盡管它們具有基本功能，但可能缺乏在應用程序?qū)舆M行全面安全事件審核的功能。組織的無服務器架構(gòu)的規(guī)模和形態(tài)將根據(jù)組織的獨特設計而定，有許多專家構(gòu)建的平臺和工具可用來彌補這些監(jiān)視和日志記錄的不足。

創(chuàng)建獨特的邏輯并利用中間云存儲服務

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

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

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

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

通過日志邏輯收集的日志需要存儲在某個地方。這是中間云存儲服務發(fā)揮重要作用的地方。通過使用一個外部系統(tǒng)來整理整個無服務器生態(tài)系統(tǒng)中的日志記錄信息，組織將能夠?qū)崟r監(jiān)視安全事件。

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

如果組織沒有對功能和用戶進行盡職調(diào)查和適當?shù)膶彶椋瑒t無服務器架構(gòu)中可能存在一些致命的弱點。

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

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

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

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

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

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

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

組織的無服務器環(huán)境是唯一的，因此實現(xiàn)無服務器安全性的方法也應該如此

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