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

[[226952]]

如果你問軟件開發人員何謂軟件架構，可能會得到五花八門的答案：軟件架構“是藍圖或計劃”、“概念模型”或“大局”，不一而足。毫無疑問，架構或缺少架構關系到軟件的成敗。良好的架構有助于擴展Web或移動應用程序，而糟糕的架構可能導致嚴重問題，勢必需要重寫、花費高昂成本。

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

然而，盡管現在開發者不用再對許多由無服務器云提供商處理的安全任務負責，但他們仍然需要負責為那些有服務器端邏輯的應用程序編寫強大的代碼，并確保這些應用程序代碼不會存在應用程序層漏洞。而且現在看來，這種任務并不會很快消失。

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

此外，任何與應用程序本身或與之交互的云服務相關的配置同樣需要安全防護。因為任何錯誤的設置和云服務的誤配置都有可能成為無服務器體系架構的攻擊入口，導致敏感機密信息的泄漏，以及為潛在的中間人攻擊(MiTM)提供入口點。同樣地，這項任務也屬于應用程序所有者的責任。

在“無服務器”的世界中，云供應商會和你一起分擔安全責任。下圖就展示了共享無服務器安全責任模型：

應用程序所有者：

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

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

為“構成云”的所有者(Owner “of” the Cloud)負責;包括操作系統+虛擬設備+容器、計算、存儲、數據庫、網絡、地域、可用性區域(AZ)、邊緣位置(edge location)等。

雖然無服務器體系結構引入了簡捷和高效，但同時也引入了一系列新的問題和應用程序挑戰：

1. 不斷增加的攻擊面

無服務器功能消耗來自各種事件源的數據，例如HTTP APIs、消息隊列(message queues)、云存儲以及物聯網(IoT)設備通信等。而且無服務器體系架構幾乎不像Web環境那樣，開發人員知道哪部分消息不應該被理解被信任的(GET / POST參數、HTTP標頭等)。這大大增加了無服務器體系結構的潛在攻擊面，特別是當消息使用協議和復雜的消息架構時，其中許多不能通過標準的應用程序層防護(如Web應用程序防火墻)進行檢查。

2. 攻擊面的復雜性

無服務器體系架構中的攻擊面對于某些人來說可能很難理解，因為這樣的體系架構還是比較新的。許多軟件開發人員和架構師尚未獲得足夠的安全風險經驗，以及保護此類應用程序所需的適當防護措施。

3. 整體系統復雜性

針對無服務器體系架構的可視化和監控工作仍然要比監控標準軟件環境更復雜。在偵察攻擊的階段，威脅實施者會試圖擊破網絡防御和弱點，這對網絡安全解決方案檢測可疑行為并關閉該行為也是一個關鍵點。由于無服務器架構是駐留在云環境中的，所以“本地”實時網絡安全解決方案是多余的，這意味著可能會錯過發現早期的攻擊跡象。而且盡管無服務器系統通常提供了日志記錄功能，但可能不適合安全監視或審計的目的。

4. 安全測試不足

對無服務器體系架構執行安全測試要比測試標準應用程序更為復雜，尤其是當這些應用程序與遠程第三方服務或后端云服務(如NoSQL數據庫、云存儲或流處理服務)交互時。另外，自動掃描工具目前也不適用于掃描無服務器應用程序。

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

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

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