無服務(wù)器體系架構(gòu)：應(yīng)用安全范式轉(zhuǎn)換。所謂“范式轉(zhuǎn)換”(Paradigm Shift)指的就是長期形成的思維習(xí)慣、價(jià)值觀的改變和轉(zhuǎn)移。而“無服務(wù)器”(Serviceless)體系架構(gòu)正是打破了人們的習(xí)慣思維，讓服務(wù)器不可見，從而讓整個(gè)開發(fā)部署過程更為安全高效，給所有開發(fā)部署運(yùn)維人員帶來的是軟件架構(gòu)和應(yīng)用程序部署的新大陸。不過，“無服務(wù)器”架構(gòu)方法并非能夠解決所有問題，相反地，它也會導(dǎo)致一系列新的安全問題和挑戰(zhàn)。

無服務(wù)器體系架構(gòu)：應(yīng)用安全范式轉(zhuǎn)換

如果你問軟件開發(fā)人員何謂軟件架構(gòu)，可能會得到五花八門的答案：軟件架構(gòu)“是藍(lán)圖或計(jì)劃”、“概念模型”或“大局”，不一而足。毫無疑問，架構(gòu)或缺少架構(gòu)關(guān)系到軟件的成敗。良好的架構(gòu)有助于擴(kuò)展Web或移動應(yīng)用程序，而糟糕的架構(gòu)可能導(dǎo)致嚴(yán)重問題，勢必需要重寫、花費(fèi)高昂成本。

而“無服務(wù)器”體系架構(gòu)最大的一個(gè)安全優(yōu)勢就是，可以幫助開發(fā)者擺脫運(yùn)行后端應(yīng)用程序所需的服務(wù)器設(shè)備的設(shè)置和管理更新工作。這些任務(wù)都由無服務(wù)器體系架構(gòu)提供商負(fù)責(zé)，然后再以服務(wù)的方式為開發(fā)者提供所需功能，例如數(shù)據(jù)庫、身份驗(yàn)證等。

熱點(diǎn)推薦：無服務(wù)器的云成本有多高

然而，盡管現(xiàn)在開發(fā)者不用再對許多由無服務(wù)器云提供商處理的安全任務(wù)負(fù)責(zé)，但他們?nèi)匀恍枰?fù)責(zé)為那些有服務(wù)器端邏輯的應(yīng)用程序編寫強(qiáng)大的代碼，并確保這些應(yīng)用程序代碼不會存在應(yīng)用程序?qū)勇┒?。而且現(xiàn)在看來，這種任務(wù)并不會很快消失。

至于云供應(yīng)商方面，將負(fù)責(zé)提供用于運(yùn)行這些代碼的服務(wù)器，并在必要時(shí)對服務(wù)器進(jìn)行縮放。執(zhí)行完畢后，承擔(dān)這些功能的容器會立刻停用，并且執(zhí)行過程以100毫秒為單位進(jìn)行度量，用戶只需為運(yùn)行代碼過程中所消耗的資源付費(fèi)，一些人將這種模式叫做功能即服務(wù)(FaaS)。

此外，任何與應(yīng)用程序本身或與之交互的云服務(wù)相關(guān)的配置同樣需要安全防護(hù)。因?yàn)槿魏五e(cuò)誤的設(shè)置和云服務(wù)的誤配置都有可能成為無服務(wù)器體系架構(gòu)的攻擊入口，導(dǎo)致敏感機(jī)密信息的泄漏，以及為潛在的中間人攻擊(MiTM)提供入口點(diǎn)。同樣地，這項(xiàng)任務(wù)也屬于應(yīng)用程序所有者的責(zé)任。

在“無服務(wù)器”的世界中，云供應(yīng)商會和你一起分擔(dān)安全責(zé)任。下圖就展示了共享無服務(wù)器安全責(zé)任模型：

應(yīng)用程序所有者：

無服務(wù)器體系架構(gòu)：應(yīng)用安全范式轉(zhuǎn)換

為“云內(nèi)部”的所有者(Owner “in” the Cloud)負(fù)責(zé)。包括客戶端、云端數(shù)據(jù)、傳輸數(shù)據(jù)(包含在公共或不可信網(wǎng)絡(luò)-如互聯(lián)網(wǎng)-上流動的信息，以及在私有網(wǎng)絡(luò)-如企業(yè)或企業(yè)局域網(wǎng)-范圍內(nèi)流動的數(shù)據(jù))、應(yīng)用程序、身份和訪問管理、云服務(wù)配置等。

FaaS(功能即服務(wù))提供商：

無服務(wù)器體系架構(gòu)：應(yīng)用安全范式轉(zhuǎn)換

為“構(gòu)成云”的所有者(Owner “of” the Cloud)負(fù)責(zé);包括操作系統(tǒng)+虛擬設(shè)備+容器、計(jì)算、存儲、數(shù)據(jù)庫、網(wǎng)絡(luò)、地域、可用性區(qū)域(AZ)、邊緣位置(edge location)等。

雖然無服務(wù)器體系結(jié)構(gòu)引入了簡捷和高效，但同時(shí)也引入了一系列新的問題和應(yīng)用程序挑戰(zhàn)：

1. 不斷增加的攻擊面

無服務(wù)器功能消耗來自各種事件源的數(shù)據(jù)，例如HTTP APIs、消息隊(duì)列(message queues)、云存儲以及物聯(lián)網(wǎng)(IoT)設(shè)備通信等。而且無服務(wù)器體系架構(gòu)幾乎不像Web環(huán)境那樣，開發(fā)人員知道哪部分消息不應(yīng)該被理解被信任的(GET / POST參數(shù)、HTTP標(biāo)頭等)。這大大增加了無服務(wù)器體系結(jié)構(gòu)的潛在攻擊面，特別是當(dāng)消息使用協(xié)議和復(fù)雜的消息架構(gòu)時(shí)，其中許多不能通過標(biāo)準(zhǔn)的應(yīng)用程序?qū)臃雷o(hù)(如Web應(yīng)用程序防火墻)進(jìn)行檢查。

2. 整體系統(tǒng)復(fù)雜性

針對無服務(wù)器體系架構(gòu)的可視化和監(jiān)控工作仍然要比監(jiān)控標(biāo)準(zhǔn)軟件環(huán)境更復(fù)雜。在偵察攻擊的階段，威脅實(shí)施者會試圖擊破網(wǎng)絡(luò)防御和弱點(diǎn)，這對網(wǎng)絡(luò)安全解決方案檢測可疑行為并關(guān)閉該行為也是一個(gè)關(guān)鍵點(diǎn)。由于無服務(wù)器架構(gòu)是駐留在云環(huán)境中的，所以“本地”實(shí)時(shí)網(wǎng)絡(luò)安全解決方案是多余的，這意味著可能會錯(cuò)過發(fā)現(xiàn)早期的攻擊跡象。而且盡管無服務(wù)器系統(tǒng)通常提供了日志記錄功能，但可能不適合安全監(jiān)視或?qū)徲?jì)的目的。

3. 攻擊面的復(fù)雜性

無服務(wù)器體系架構(gòu)中的攻擊面對于某些人來說可能很難理解，因?yàn)檫@樣的體系架構(gòu)還是比較新的。許多軟件開發(fā)人員和架構(gòu)師尚未獲得足夠的安全風(fēng)險(xiǎn)經(jīng)驗(yàn)，以及保護(hù)此類應(yīng)用程序所需的適當(dāng)防護(hù)措施。

4. 安全測試不足

對無服務(wù)器體系架構(gòu)執(zhí)行安全測試要比測試標(biāo)準(zhǔn)應(yīng)用程序更為復(fù)雜，尤其是當(dāng)這些應(yīng)用程序與遠(yuǎn)程第三方服務(wù)或后端云服務(wù)(如NoSQL數(shù)據(jù)庫、云存儲或流處理服務(wù))交互時(shí)。另外，自動掃描工具目前也不適用于掃描無服務(wù)器應(yīng)用程序。

傳統(tǒng)的安全防護(hù)措施并不適用：由于使用無服務(wù)器體系架構(gòu)的組織無法訪問物理(或虛擬)服務(wù)器或其操作系統(tǒng)，因此他們無法部署傳統(tǒng)防護(hù)層，如端點(diǎn)保護(hù)、基于主機(jī)的入侵防御、Web應(yīng)用程序防火墻或是RASP(實(shí)時(shí)應(yīng)用程序自我保護(hù))解決方案——它是一種新型應(yīng)用安全保護(hù)技術(shù)，它將保護(hù)程序像疫苗一樣注入到應(yīng)用程序，并和應(yīng)用程序融為一體，能實(shí)時(shí)檢測和阻斷安全攻擊，使應(yīng)用程序具備自我保護(hù)能力，當(dāng)應(yīng)用程序遇到特定漏洞和攻擊時(shí)不需要人工干預(yù)就可以進(jìn)行自動重新配置應(yīng)對新的攻擊。

正是這最后一條(即傳統(tǒng)的安全防護(hù)措施并不適用)要求在無服務(wù)器體系架構(gòu)的應(yīng)用程序安全性方面進(jìn)行大幅度的范式轉(zhuǎn)換。根據(jù)定義，在無服務(wù)器體系架構(gòu)中，您只能控制應(yīng)用程序的代碼，而且它幾乎是您所擁有的唯一東西。這也就意味著，如果您需要保護(hù)自己的無服務(wù)器代碼，唯一的選擇就是確保自己編寫了安全的代碼，并將這這種安全性融入到應(yīng)用程序中。

這實(shí)際上并不是一件壞事——無服務(wù)器計(jì)算迫使軟件架構(gòu)師和開發(fā)人員以將安全性構(gòu)建其中的方式來解決安全問題，而不是在發(fā)生問題時(shí)再去進(jìn)行安全防護(hù)。很顯然，這是一種更為積極主動的方式。