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

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

流動(dòng)的攻擊面

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

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

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

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

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

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

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

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

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

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

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

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

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

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

許多云供應(yīng)商提供了基本形式的日志記錄功能或函數(shù)，常見示例包括AWS CloudWatch或Azure函數(shù)。盡管這些函數(shù)為無服務(wù)器環(huán)境啟用了非常基本的日志記錄，但是代價(jià)可能很高，并且一旦無服務(wù)器架構(gòu)擴(kuò)展到一定規(guī)?；蛞欢ǔ潭鹊膹?fù)雜性時(shí)，它們就可能無法滿足你的要求。

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

如何實(shí)施日志記錄

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

編輯：jq