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

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

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

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

　　無(wú)服務(wù)器應(yīng)用導(dǎo)致邊界變得更易滲透和分散化

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

　　WAF、防火墻和 IDS 等傳統(tǒng)網(wǎng)絡(luò)或邊界防護(hù)系統(tǒng)無(wú)處安放

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

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

　　那么，保護(hù)無(wú)服務(wù)器應(yīng)用是誰(shuí)人之責(zé)？

　　新技術(shù)的誕生總是會(huì)讓人們忘記前車之鑒，導(dǎo)致安全告急。不管應(yīng)用團(tuán)隊(duì)的做法是對(duì)是錯(cuò)，還是無(wú)關(guān)緊要，開(kāi)發(fā)人員都將他們視為絆腳石，認(rèn)為他們是導(dǎo)致延遲的禍?zhǔn)字�一。無(wú)服務(wù)器也不例外。但不同的是，無(wú)服務(wù)器應(yīng)用保護(hù)的責(zé)任歸屬還不明確。

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

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

　　對(duì)于相關(guān)最佳實(shí)踐，以下是我的一點(diǎn)拙見(jiàn)，僅供參考：