無伺服器體系架構：應用安全範式轉換

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

如果你問軟體開發人員何謂軟體架構，可能會得到五花八門的答案：軟體架構「是藍圖或計劃」、「概念模型」或「大局」，不一而足。毫無疑問，架構或缺少架構關係到軟體的成敗。良好的架構有助於擴展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（實時應用程序自我保護）解決方案——它是一種新型應用安全保護技術，它將保護程序像疫苗一樣注入到應用程序，並和應用程序融為一體，能實時檢測和阻斷安全攻擊，使應用程序具備自我保護能力，當應用程序遇到特定漏洞和攻擊時不需要人工干預就可以進行自動重新配置應對新的攻擊。

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

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

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！