從安全角度來看，遷移到無服務器環(huán)境有利也有弊。一方面，因性質使然，無服務器可以改善安全性。首先，您不必再為服務器打補丁。其次，無服務器計算的短暫性和無狀態(tài)性讓攻擊者很難下手。最后，由于現(xiàn)在您的應用在云中采用大量的小功能塊構造，您可以將每個計算單元視為一個單獨的實體。

　　總之，無服務器架構讓安全性在許多方面都變得更加簡單，并且需要一種獨特的、細化的方法。但是另一方面，無服務器也引發(fā)了其他變化，無服務器應用面臨著獨特的安全挑戰(zhàn)，包括：

　　難以找到不同數(shù)據之間的關聯(lián)

　　每一個功能、API 和協(xié)議都是潛在的攻擊點

　　無服務器應用導致邊界變得更易滲透和分散化

　　具有挑戰(zhàn)性且耗時

　　WAF、防火墻和 IDS 等傳統(tǒng)網絡或邊界防護系統(tǒng)無處安放

　　無服務器具有短暫性和分散性，這意味著更頻繁的狀態(tài)變更和更多的風險管理及安全審核要求

　　應用安全威脅始終存在，只是形式和行為有所不同。實現(xiàn)控制和安全性需要思維方式的徹底轉變。人們應該少將防御重點放在特定事件上，多加關注這些重復性無狀態(tài)攻擊的整體模式。

　　那么，保護無服務器應用是誰人之責？

　　新技術的誕生總是會讓人們忘記前車之鑒，導致安全告急。不管應用團隊的做法是對是錯，還是無關緊要，開發(fā)人員都將他們視為絆腳石，認為他們是導致延遲的禍首之一。無服務器也不例外。但不同的是，無服務器應用保護的責任歸屬還不明確。

　　傳統(tǒng) AppSec 方法耗時長、拖進程，抵消了無服務器的快速部署優(yōu)勢。如果開發(fā)人員等待安全人員為其打開端口、分配 IAM 角色或建立專屬安全組，那么他們原本開發(fā)出的超高速方法就白費了。雖然安全專家也不想妨礙開發(fā)人員，但他們仍然需要控制策略和可視性，如何在不延緩進程的情況下聯(lián)合 DevOps 實施安全控制成為他們的一大難題。這讓所有人都陷入了困境。

　　保護無服務器應用離不開大家的共同努力，需要開發(fā)人員、DevOps 和 AppSec 的緊密合作。安全團隊需要找到一個平衡點，既允許開發(fā)人員在能力范圍之內實施最佳安全編碼實踐（自動化程度越高越好），又認真落實好自己的職責，在生命周期的早期階段修復漏洞和解決問題，同時幫助開發(fā)人員確定問題的風險，即部署這一應用是否會危及業(yè)務安全。最后，創(chuàng)建跨職能團隊，整合安全專家與開發(fā)團隊的力量，實現(xiàn)與 DevOps 的緊密協(xié)作，確保安全問題不會抵消無服務器的速度優(yōu)勢。

　　對于相關最佳實踐，以下是我的一點拙見，僅供參考：