從安全角度來看,遷移到無服務(wù)器環(huán)境有利也有弊。一方面,因性質(zhì)使然,無服務(wù)器可以改善安全性。首先,您不必再為服務(wù)器打補丁。其次,無服務(wù)器計算的短暫性和無狀態(tài)性讓攻擊者很難下手。最后,由于現(xiàn)在您的應(yīng)用在云中采用大量的小功能塊構(gòu)造,您可以將每個計算單元視為一個單獨的實體。
總之,無服務(wù)器架構(gòu)讓安全性在許多方面都變得更加簡單,并且需要一種獨特的、細化的方法。但是另一方面,無服務(wù)器也引發(fā)了其他變化,無服務(wù)器應(yīng)用面臨著獨特的安全挑戰(zhàn),包括:
安全可視性
難以找到不同數(shù)據(jù)之間的關(guān)聯(lián)
更多攻擊點和攻擊向量
每一個功能、API 和協(xié)議都是潛在的攻擊點
邊界侵蝕
無服務(wù)器應(yīng)用導(dǎo)致邊界變得更易滲透和分散化
更多管理權(quán)限
具有挑戰(zhàn)性且耗時
無處部署安全控件
WAF、防火墻和 IDS 等傳統(tǒng)網(wǎng)絡(luò)或邊界防護系統(tǒng)無處安放
更多功能和更多變化意味著更多風(fēng)險
無服務(wù)器具有短暫性和分散性,這意味著更頻繁的狀態(tài)變更和更多的風(fēng)險管理及安全審核要求
應(yīng)用安全威脅始終存在,只是形式和行為有所不同。實現(xiàn)控制和安全性需要思維方式的徹底轉(zhuǎn)變。人們應(yīng)該少將防御重點放在特定事件上,多加關(guān)注這些重復(fù)性無狀態(tài)攻擊的整體模式。
那么,保護無服務(wù)器應(yīng)用是誰人之責(zé)?
新技術(shù)的誕生總是會讓人們忘記前車之鑒,導(dǎo)致安全告急。不管應(yīng)用團隊的做法是對是錯,還是無關(guān)緊要,開發(fā)人員都將他們視為絆腳石,認(rèn)為他們是導(dǎo)致延遲的禍?zhǔn)字。無服務(wù)器也不例外。但不同的是,無服務(wù)器應(yīng)用保護的責(zé)任歸屬還不明確。
傳統(tǒng) AppSec 方法耗時長、拖進程,抵消了無服務(wù)器的快速部署優(yōu)勢。如果開發(fā)人員等待安全人員為其打開端口、分配 IAM 角色或建立專屬安全組,那么他們原本開發(fā)出的超高速方法就白費了。雖然安全專家也不想妨礙開發(fā)人員,但他們?nèi)匀恍枰刂撇呗院涂梢曅裕绾卧诓谎泳忂M程的情況下聯(lián)合 DevOps 實施安全控制成為他們的一大難題。這讓所有人都陷入了困境。
保護無服務(wù)器應(yīng)用,人人有責(zé)
保護無服務(wù)器應(yīng)用離不開大家的共同努力,需要開發(fā)人員、DevOps 和 AppSec 的緊密合作。安全團隊需要找到一個平衡點,既允許開發(fā)人員在能力范圍之內(nèi)實施最佳安全編碼實踐(自動化程度越高越好),又認(rèn)真落實好自己的職責(zé),在生命周期的早期階段修復(fù)漏洞和解決問題,同時幫助開發(fā)人員確定問題的風(fēng)險,即部署這一應(yīng)用是否會危及業(yè)務(wù)安全。最后,創(chuàng)建跨職能團隊,整合安全專家與開發(fā)團隊的力量,實現(xiàn)與 DevOps 的緊密協(xié)作,確保安全問題不會抵消無服務(wù)器的速度優(yōu)勢。
對于相關(guān)最佳實踐,以下是我的一點拙見,僅供參考:
- 繪制應(yīng)用映射圖,觀察持續(xù)的信息流
- 在功能級別實施邊界防護
- 針對每個功能創(chuàng)建合適的最小化角色