剖析無服務(wù)器 (Serverless) 架構(gòu)基礎(chǔ)安全指南

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

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

流動的攻擊面

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

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

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

自動映射和監(jiān)控?zé)o服務(wù)器架構(gòu)

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

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

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

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

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

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

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

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

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

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

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

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

如何實施日志記錄

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

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

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

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

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

在無服務(wù)器架構(gòu)的拓?fù)渲锌缢袩o服務(wù)器函數(shù)跟蹤和遏制攻擊者和惡意/未經(jīng)授權(quán)的輸入，而無需考慮層。

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

如果沒有對函數(shù)和用戶進(jìn)行盡職調(diào)查和適當(dāng)?shù)膶彶?，則無服務(wù)器架構(gòu)中可能存在致命的弱點組合。

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

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

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

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

進(jìn)一步的無服務(wù)器安全注意事項

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

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

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

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

編輯：jq