新報告探索云原生應用轉型及其安全復雜性。
隨著公司企業逐漸轉向技術即服務,生產工作負載將持續轉移至公共云平臺,服務器類型也將從虛擬機 (VM) 和實體計算機轉變至容器及無服務器平臺。不斷增加的復雜性無意會增加安全防護的難度。
企業戰略集團 (ESG) 針對 371 位美國及加拿大的 IT 和安全專業人士做了問卷調查,于 9 月底發布了《DevOps 安全——企業調查報告》。調查對象均來自公共云服務和容器使用相當成熟的公司企業,且為公司中負責評估、采購和管理云安全產品及服務的人員。
報告指出,現在及將來一段時間內,云原生應用均由部署在混合云上的異構微服務組成。盡管大多數公司企業的服務器類型傾向于虛擬機和實體機,但未來兩年內他們的選擇將轉向容器和無服務器平臺。
ESG 高級分析師兼網絡安全集團業務主管 Doug Cahill 表示,ESG 在 2017 年時也做過類似的調查研究,但因為為時過早,并沒有問無服務器函數相關問題。
今年,研究人員發現,34% 的受訪者 “廣泛” 使用無服務器函數,18% 有限度使用,16% 計劃在未來 1~2 年內開始使用,28% 正在評估是否采用。僅 3% 沒有使用無服務器函數的打算。
Cahill 解釋道,已經部署云原生應用的公司企業開始大量采用無服務器函數調用。他們也調查了應用容器的使用情況,該項指標在過去幾年里也呈持續增長狀態。驅動無服務器函數采用增長的因素包括:安全改善 (73%)、可抵御攻擊的網絡技術 (66%)、包含無服務器函數調用的源代碼中植入安全功能 (64%),以及新開發應用上市時間縮短 (57%) 等。
任何事物都有正反兩面,無服務器函數也不例外。API 漏洞 (32%) 是考慮無服務器函數時的主要顧慮,其次是“秘密泄露” (26%) 的問題,造成未加密數據傳輸的 API 調用 (22%) 排第三,提權 (11%) 和未批準 API 的使用 (9%) 緊隨其后。
Cahill 雖震驚于使用無服務器架構的企業數量,卻對生產環境中服務器類型的多樣化毫不意外。他指出,現實環境的異構情況非常突出,35% 的受訪者都計劃同時采用虛擬機、容器和/或無服務器架構。
問題在于,技術的混雜增大了云安全面臨的挑戰。研究人員稱,云原生應用令混合環境和多云環境更難以防護。
一致性是最大的問題。43% 的受訪者擔心他們數據中心和部署云原生應用的公共云環境之間該如何保持一致。很多人認為現有安全工具不支持云原生應用,所以公司企業常使用由獨立團隊管理的多種單點工具。
近 3/4 (73%) 的受訪者稱其公司使用太多專門工具保護云原生應用。由于公司通常指派不同團隊負責各個環境的控制工作,成本和復雜性節節攀升。
我覺得我們會看到云安全單點工具的融合和 API 安全工具的融合。
他預測有可能出現某個 API 安全產品能覆蓋多種編程語言和 API。
DevOps安全:思維轉變
DevSecOps 作為保護云原生應用安全的主要方式漸漸興起。超過半數 (55%) 的受訪者向 DevOps 中融入了安全,22% 正計劃這么做。20% 正在評估可納入 DevOps 過程的安全用例。
然而,僅 8% 的公司企業當前以 DevSecOps 操作保護的云原生應用占比在 75% 或以上。研究人員預測,隨著 DevOps 團隊創建可重復、可擴展的 DevOps 集成,以 DevSecOps 保護 3/4 以上云原生應用的公司企業將會在兩年內達到 68%。越多應用受到該方法的保護,對自動化的需求會越大。
需重新審視開發背后的人員、過程和技術,方可有效實踐該方法。關于人員和過程,產品鏈涉及的所有成員均需承擔安全責任。盡管安全傳統上是在開發過程末端上的一道鎖,但持續集成/持續交付 (CI/CD) 模式下是很難真正 “鎖上” 的。
一直以來,DevOps 和安全的著眼點大不相同。DevOps 在乎速度;安全小心謹慎。DevOps 覺得安全會拖慢進度;安全認為 DevOps 根本就是在上演夾縫求生。
如果能將安全融入 CI/CD 工具,就能夠以 DevOps 的速度安全前行。但將安全融入開發的腳步很慢:盡管 52% 的公司企業將安全團隊引入云原生應用上線前的保護工作,但很多公司都是被動地在做這件事:或是遭遇過安全事件,或是出于融資需求,或是擔心存儲在云中的數據。1/3 的公司企業是從開發過程初始階段就納入安全。
除了捏合安全團隊與產品團隊,還有另外一個與人員相關的問題:確保雙方,尤其是安全團隊,理解對手在用的攻擊類型和方法。“易受攻擊的應用到底有什么不同?” 一旦安全人員理解了 API 和無服務器函數中的漏洞點,他們就可以更好地配合開發團隊做好防護。
《DevOps 安全——企業調查報告》地址:
https://www.datatheorem.com/resources/reports/esg-security-for-devops/