Dan Swinhoe 陳琳華

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

無(wú)服務(wù)器應(yīng)用亦稱(chēng)為云函數(shù)，可執(zhí)行非常具體的任務(wù)且存在時(shí)間僅為數(shù)秒鐘。這使得它們?cè)诔浞掷迷骗h(huán)境和降低成本方面更加高效。

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

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

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

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

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

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

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

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

“最常見(jiàn)的攻擊方法是事件數(shù)據(jù)注入。在這過(guò)程中，攻擊者會(huì)注入惡意數(shù)據(jù)，然后在事件觸發(fā)期間被函數(shù)使用，”P(pán)ureSec的Segal說(shuō)。“此類(lèi)惡意數(shù)據(jù)可能會(huì)濫用應(yīng)用程序?qū)勇┒?，例如SQL注入、命令注入、本地文件包含、數(shù)據(jù)泄漏等。此類(lèi)攻擊將操縱函數(shù)的業(yè)務(wù)邏輯?！?/p>

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

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

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

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

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

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

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

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

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

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

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

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

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

3、盡可能不將敏感數(shù)據(jù)放入函數(shù)的源代碼中。確保所有數(shù)據(jù)都已加密。同時(shí)，要確保身份驗(yàn)證方法是有效的，并盡可能使用FaaS提供商的東西。此外，還要進(jìn)行定期評(píng)估。Checkmarx的Eshkenazi說(shuō)：“如果你不在服務(wù)器上的代碼中編寫(xiě)敏感數(shù)據(jù)，那就同樣不應(yīng)該在無(wú)服務(wù)器代碼中編寫(xiě)敏感數(shù)據(jù)，因?yàn)樗鼈兛赡鼙恍孤逗褪艿焦??！?/p>

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

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