Dan Swinhoe 陳琳華

攻擊者有多種方法來攻擊無服務(wù)器應(yīng)用，但是本文中的這些最佳實踐將有助于阻止這些攻擊。

無服務(wù)器應(yīng)用亦稱為云函數(shù)，可執(zhí)行非常具體的任務(wù)且存在時間僅為數(shù)秒鐘。這使得它們在充分利用云環(huán)境和降低成本方面更加高效。

與任何新技術(shù)一樣，這種新范式的安全隱患尚未得到充分探索或理解。PureSec的首席技術(shù)官兼聯(lián)合創(chuàng)始人Ory Segal稱：“許多人仍然認(rèn)為無服務(wù)器是神奇的，保護(hù)代碼的安全可交由他人負(fù)責(zé)，但事實遠(yuǎn)非如此?！辈贿^，我們也許可以通過強化無服務(wù)器應(yīng)用和使用安全最佳實踐來降低數(shù)據(jù)泄露的概率。

如何攻擊無服務(wù)器函數(shù)

當(dāng)然，服務(wù)器仍然存在，但函數(shù)是抽象的且不依賴于任何一個基礎(chǔ)設(shè)施。事實上，服務(wù)器上有函數(shù)的源代碼，并且至少有一個托管的臨時容器正在執(zhí)行函數(shù)。這意味著應(yīng)該認(rèn)真考慮它們的安全性。

Segal指出，“無服務(wù)器函數(shù)只是幾個簡單的代碼片段，當(dāng)某個事件觸發(fā)時云提供商將執(zhí)行這些代碼片段。因此與任何其他軟件一樣，它們也會遇到應(yīng)用程序?qū)勇┒??！?/p>

關(guān)于無服務(wù)器架構(gòu)中最常見的安全風(fēng)險的研究發(fā)現(xiàn)，GitHub上五分之一的無服務(wù)器應(yīng)用存在嚴(yán)重的安全漏洞。不過到目前為止，還沒有關(guān)于無服務(wù)器函數(shù)遭到破壞的重大攻擊報告。盡管如此，安全研究社區(qū)卻對此非常感興趣，其中一些人認(rèn)為有針對性的攻擊正在發(fā)生，只是沒有被發(fā)現(xiàn)而已。

Mozilla的安全工程師Andrew Krug在去年早些時候的黑帽大會上表示：“人們正在尋找無服務(wù)器函數(shù)的漏洞，特別是在開源領(lǐng)域，很容易就找到代碼中漏洞在哪里?！?/p>

2018年7月，PureSec在其所支持的IBM Cloud Functions產(chǎn)品的開源無服務(wù)器計算平臺Apache Openwhisk中發(fā)現(xiàn)了一個漏洞。該漏洞允許攻擊者覆蓋源代碼并更改函數(shù)邏輯。為此Apache基金會還專門發(fā)布了一個補丁。

PureSec最近還演示了一種攻擊。該攻擊利用無服務(wù)器中的自動擴(kuò)展函數(shù)將單個易受攻擊的函數(shù)轉(zhuǎn)變?yōu)榇笠?guī)模的加密貨幣挖掘礦場。在測試中，該攻擊可使挖礦函數(shù)擴(kuò)展至平臺的最大并發(fā)限制。這種攻擊可能會導(dǎo)致在賬期結(jié)束時出現(xiàn)大量費用。由于加密貨幣挖礦會導(dǎo)致受害者消耗額外的計算資源，該報告估算這筆費用每月多達(dá)12萬美元。

“最常見的攻擊方法是事件數(shù)據(jù)注入。在這過程中，攻擊者會注入惡意數(shù)據(jù)，然后在事件觸發(fā)期間被函數(shù)使用，”PureSec的Segal說?！按祟悙阂鈹?shù)據(jù)可能會濫用應(yīng)用程序?qū)勇┒?，例如SQL注入、命令注入、本地文件包含、數(shù)據(jù)泄漏等。此類攻擊將操縱函數(shù)的業(yè)務(wù)邏輯。”

在2018年7月的倫敦OWASP AppSec大會上，Checkmarx的Shimi Eshkenazi和Amit Ashbel則演示了一種代碼注入攻擊，它可在同一應(yīng)用程序中“交叉污染”函數(shù)，克服了持久性問題。在演示過程中，該團(tuán)隊展示了他們能夠通過代碼注入訪問函數(shù)代碼，并下載該函數(shù)代碼，在對其進(jìn)行修改后再通過原始病毒函數(shù)感染其他的函數(shù)。

Eshkenazi說：“你將會陷入無限循環(huán)的交叉感染中，而這將導(dǎo)致所有其他函數(shù)失控。擺脫這種情況的唯一方法是將所有函數(shù)恢復(fù)到原始來源。記住是所有函數(shù)，不能遺漏其中的任何一個?！?/p>

無服務(wù)器計算有哪些安全優(yōu)勢？

盡管可能存在風(fēng)險，但無服務(wù)器函數(shù)仍擁有一些安全優(yōu)勢，主要在于它們是孤立的、短時的和只讀的，并且通常只有很少或是沒有特權(quán)升級。與其他類型的代碼相比，將它們做為攻擊目標(biāo)具有更大的難度。與單體應(yīng)用程序相比，函數(shù)通常沒有什么職責(zé)和訪問數(shù)據(jù)，因此直接破壞范圍更小。

Checkmarx的網(wǎng)絡(luò)安全推廣官Amit Ashbel在OWASP AppSec大會上表示：“函數(shù)在它們自己的環(huán)境中運行這一事實減少了潛在的破壞，并且由于沒有任何東西存儲在上面，所以函數(shù)在運行后會被移動、刪除和丟棄。這兩個特點也都阻止了注入的東西被存儲起來。如果你注入的東西（在函數(shù)結(jié)束后）被刪除，那么這一函數(shù)仍然是新的和干凈的。（它們）應(yīng)該更加安全?！?/p>

函數(shù)由主要云提供商作為服務(wù)提供這一事實也提供了額外的安全性。雖然實際函數(shù)的編碼和配置是由用戶決定的，但是AWS和Azure之類的產(chǎn)品將負(fù)責(zé)確保底層硬件的安全性和補丁，同時函數(shù)本身也將定期更新，這些提供商的規(guī)模意味著拒絕服務(wù)攻擊將更加容易被應(yīng)對。

與錯誤配置的S3存儲桶會導(dǎo)致許多重大數(shù)據(jù)泄漏事件一樣，錯誤配置的無服務(wù)器應(yīng)用也可能會導(dǎo)致出現(xiàn)數(shù)據(jù)泄漏等問題?！癓ambda的默認(rèn)值很好。這里面的問題在于流行的無服務(wù)器框架引入的默認(rèn)值，它們往往會導(dǎo)致IAM（身份和訪問管理）權(quán)限完全敞開，”Mozilla的Krug說。

如何保護(hù)無服務(wù)器函數(shù)

無服務(wù)器技術(shù)目前仍處于初期階段，這一特點也反映在圍繞著該技術(shù)的安全實踐當(dāng)中。Serverless.com的調(diào)查發(fā)現(xiàn)，調(diào)試、監(jiān)控和測試是無服務(wù)器應(yīng)用的最大挑戰(zhàn);而PureSec的調(diào)查發(fā)現(xiàn)，35%的企業(yè)并沒有安全指南或工具以保護(hù)無服務(wù)器代碼。在該研究中，有48%的企業(yè)對其無服務(wù)器應(yīng)用的安全可見性的水平并不滿意。當(dāng)一家企業(yè)擁有50多個職能部門時，這一數(shù)字會急劇上升，這表明存在大規(guī)模安全問題。

Segal指出，“傳統(tǒng)的應(yīng)用層保護(hù)，例如Web應(yīng)用防火墻和端點保護(hù)解決方案，不適用于無服務(wù)器架構(gòu)，并且由于缺乏底層基礎(chǔ)設(shè)施或網(wǎng)絡(luò)/操作系統(tǒng)無法訪問而無法部署。目前無服務(wù)器的安全測試方法和工具仍幾乎沒有。”

盡管如此，企業(yè)還是可以遵循一些最佳實踐來改善其無服務(wù)器應(yīng)用和函數(shù)的安全狀態(tài)。以下是可以遵循的五大應(yīng)用安全最佳實踐：

1、在設(shè)計和開發(fā)時就考慮到安全性，并使用威脅建模來了解自己面臨的風(fēng)險。執(zhí)行靜態(tài)代碼分析和滲透測試以檢測漏洞。使用安全API驗證事件數(shù)據(jù)輸入。該安全API可以清理或驗證用戶輸入，并將流入的HTTP / HTTPS流量掃描至無服務(wù)器應(yīng)用。

2、確保身份與訪問管理（IAM）的角色和權(quán)限被正確配置，以便函數(shù)只能被需要訪問它們的東西訪問。只授予函數(shù)提供執(zhí)行任務(wù)所需的權(quán)限。如果只需要讀取函數(shù)，請確保其權(quán)限是只讀的。

3、盡可能不將敏感數(shù)據(jù)放入函數(shù)的源代碼中。確保所有數(shù)據(jù)都已加密。同時，要確保身份驗證方法是有效的，并盡可能使用FaaS提供商的東西。此外，還要進(jìn)行定期評估。Checkmarx的Eshkenazi說：“如果你不在服務(wù)器上的代碼中編寫敏感數(shù)據(jù)，那就同樣不應(yīng)該在無服務(wù)器代碼中編寫敏感數(shù)據(jù)，因為它們可能被泄露和受到攻擊。”

4、清楚如何正確開發(fā)無服務(wù)器應(yīng)用。糟糕的自動擴(kuò)展函數(shù)可能會拖累資源。Auth0的Webtask.io函數(shù)即服務(wù)平臺（FaaS）的首席架構(gòu)師Tomasz Janczuk表示，平臺遭受拒絕服務(wù)攻擊的情況很常見，這些攻擊實際上通常是由用戶錯誤而導(dǎo)致。這些例子中包括設(shè)計效率低下的函數(shù)，這些函數(shù)會試圖分配大量內(nèi)存，嘗試將大量文件寫入文件系統(tǒng)，或者通過無休止的循環(huán)來阻塞CPU。

5、確保對無服務(wù)器應(yīng)用擁有細(xì)致入微的安全可見性和深刻的洞察力。監(jiān)控非常重要，尤其是在增加函數(shù)的數(shù)量時。監(jiān)視API身份驗證嘗試，對函數(shù)配置、權(quán)限或觸發(fā)器的修改行為，以及執(zhí)行超時等。“無論應(yīng)用程序是傳統(tǒng)的、容器化的，還是無服務(wù)器的，都必須不斷監(jiān)控整個交付堆棧的安全性，”Synopsys的Black Duck高級技術(shù)推廣人員Tim Mackey說。“隨著應(yīng)用程序被分解至以無服務(wù)器模式部署的函數(shù)中，這些應(yīng)用程序的潛在攻擊面將會增加，每個函數(shù)都應(yīng)被視為一個不同的可交付成果，并進(jìn)行全面的安全審查?！?/p>