洞察云原生安全趨勢，詳解DevSecOps建設

通過調研100+云原生應用組織的安全建設情況，我們總結了這些組織安全建設的主要趨勢。

洞察1：云原生安全管理方式

• 集中的、自上而下的安全采購和管理模式
• 利用管理平臺整合安全工具統一管理策略
• 安全管理與DevOps流程集成

圖1 不同云原生安全管理方式的比例

洞察2：不同安全成熟度組織的特點

• 更高安全成熟的組織能夠更有效地修補漏洞：超過75%的組織會在全生命周期過程中掃描代碼，對漏洞的響應速度提高了28%。
• 隨著組織安全成熟度越高，開發人員越認可安全的價值：安全成熟度高的組織的開發團隊認為安全團隊是業務推動者的概率比其他的組織要高出4.2倍。
• 安全成熟度與高效運營正相關：安全成熟度較高的組織認為他們的安全能力對應用程序的可靠性、可見性和安全性有顯著的積極影響。
• 安全成熟度越高的組織遭受的安全事件更少：通過調研發現，2021年安全成熟度較高的組織遭受的安全事件減少了31%。
• 安全成熟度會影響產品的功能和準時交付：安全成熟度較高的組織對按時交付安全代碼的信心增加了4.3倍。
• 安全成熟度高的組織業務收入明顯超過預期目標：高成熟度階段的組織相比于低成熟度階段的組織增加業務收入的可能性高出55%。

洞察3：組織應用云原生技術所面臨的主要安全風險

• 利用已知軟件漏洞進行攻擊
• 利用0Day漏洞進行攻擊
• 利用配置錯誤的云服務、工作負載或特權賬戶進行攻擊
• 由第三方進行的未經授權的訪問
• 惡意軟件包括勒索軟件和加密軟件，它們可以橫向移動到云工作負載中
• 有針對性地滲透攻擊
• 由于API的不安全使用而導致數據丟失的攻擊
• 濫用特權賬戶或通過被盜的憑證進行訪問
• 對象存儲中顯示的公開數據

洞察4：組織使用安全供應商和安全工具的數量

?在調研中發現各組織在將應用擴展到云環境時，還整合了他們的云原生安全供應商。如圖2所示，2021年使用1到5個安全供應商的組織數量增加了27%，使用6到10個安全供應商的組織數量與2020年相比下降了19%。

圖2 組織合作安全供應商數量的變化

組織減少了安全供應商的數量，同時也對利用的安全工具做了簡化。近四分之三的組織使用10個或更少的安全工具，這表明組織希望通過更少的安全供應商，獲得更廣泛的安全功能。因為依賴多個供應商的不同工具可能會出現安全盲點增加風險。

兩大屬性實現成功的云原生安全建設

為了得出成功應用云原生技術組織的安全建設特點，我們通過兩個安全屬性來比較不同組織的安全特點：

• 安全態勢：指組織如何評價其云原生安全工作的有效性。
• 安全摩擦：指組織認為云原生安全支持或限制其業務的程度。

如圖3所示，為了衡量云原生安全態勢，我們通過6個調查問題，調研了各組織的安全人員，受訪者對這些問題的認可度越高，表明該組織的安全工作越有效。如圖4所示，調查發現55%的組織安全能力較弱，比如在獲得多云可見性、跨應用的統一安全管理或者簡化事件響應流程等方面需要優化。

圖3 影響安全態勢的因素

圖4 不同安全態勢組織的百分比

如圖5所示，為了分析云原生安全方面的摩擦，我們通過對2個問題進行調研，受訪者越強烈地同意這些觀點，表明該組織的安全摩擦越高。如圖6所示，通過調研發現只有48%的組織認為他們的安全摩擦很低。

圖5 導致組織安全摩擦的因素

圖6 具有高、中、低摩擦的組織的百分比

結合這兩個指標，可以發現實現低安全摩擦對于提高組織安全態勢至關重要。組織通過優化安全工具和流程進行安全建設的同時，要盡可能減少對業務的影響。

強大的安全能力，不但可以提高運營效率，而且具有高安全態勢和低摩擦的組織可以提高生產力和員工滿意度。如圖7所示，調研發現超過80%的安全摩擦水平較低的組織報告員工滿意度顯著提高。

圖7 整體安全態勢對組織的積極影響

兩大要素助力組織實現強大安全態勢

通過調研發現，提高組織安全態勢減少安全摩擦主要有兩個核心因素：

• DevSecOps集成——將云原生安全能力集成到從構建到運行時的整個開發生命周期中。
• 安全自動化——云原生安全自動化的程度可以有效提高組織的安全能力降低安全摩擦。

組織實施DevSecOps方法并實現安全自動化是提高安全態勢的主要因素。將DevSecOps原則緊密集成到開發生命周期中的組織，擁有更強大的安全態勢和更低的安全摩擦。如圖8、9所示，我們總結了有助于提高DevSecOps集成度和自動化程度的一些因素。

圖8 影響DevSecOps集成度量的因素

圖9 提高云原生安全自動化的因素

七大原則實現DevSecOps自動化安全建設

DevSecOps是組織云原生安全建設的重要部分，它是由開發、運營和安全人員組成的聯合團隊，使組織在一個確定的范圍內快速地向市場交付安全的應用。復雜的、動態的云原生項目需要這種方式的協作，但大多數組織仍然很難有效地實施DevSecOps模式。問題是，DevSecOps不僅僅是一種技術轉變，也是一種文化變革。組織實施DevSecOps主要存在以下安全挑戰：

難以評估安全風險：在復雜的云原生環境中每天會發生大量的安全告警，如果不能很好地評估風險進行優先級排序，并實現風險閉環管理，大多數安全風險告警就會被簡單地忽略了。

缺乏開發過程的風險解決能力：大多數安全工具主要針對運行時，這時風險已經暴露出來。如果能在開發過程中解決發現的安全風險，會更容易而且影響更小。

自動化程度低減緩開發速度：假設DevOps團隊在檢測到問題時有修復問題的能力，但如果依賴人工檢查和手動修復問題，這不僅效率極低，而且減緩了開發速度。

高效、成功的DevSecOps模式中開發人員能夠在開發過程中獨立通過可靠、簡單的方式修復漏洞解決安全風險，通過改進團隊內部的協作，從而使整個組織實現技術和文化的全面變革，帶來業務和安全的雙重提升。想要成功地實施DevSecOps，組織需要在文化上和技術上重新思考如何安全地構建、部署和運行應用程序，主要遵循以下七個原則。

原則一：利用IaC實現可重復性和文檔化

?隨著云原生環境的規模和復雜性的增長，組織非常需要一些工具來實現快速、統一的部署。同時，需要從開發到運行整個生命周期中保護基礎設施安全。一方面，基礎設施即代碼(IaC)允許在被測試、應用和審計的基礎上對環境進行更改，從而提高敏捷性和安全性。另一方面，它還提供了可重復性和文檔化的重要好處。隨著部署環境的增多，每個環境都有自己獨特的特性和標準。IaC通過對基礎設施進行持續地版本控制和審查，從而更容易理解基礎設施如何以及為什么會發生變化。

通過IaC不僅可以幫助DevOps團隊快速、大規模地實現業務目標，還可以將安全更早地集成到整個生命周期中。通過這兩個因素使組織更容易實現不可變的基礎設施，在這種狀態下，基礎設施在部署后永遠不會被修改。不可變的基礎設施實踐進一步提高了云原生環境的安全性和合規性。

原則二：通過IaC盡早開始安全管理

?調查顯示，67%的數據泄露問題是由于云配置錯誤導致的。這可能是因為沒有及早地修復問題或因為安全團隊和開發團隊溝通不及時。解決這兩個問題就需要將安全盡早地集成到DevOps流程中。

通過威脅建模可以主動識別威脅，并建立針對這些威脅的安全控制。威脅模型可以通過分析IaC來構建，以確定需要定義哪些資源、如何配置它們以及它們之間的關系。通過IaC提供的上下文，可以更好地了解生產環境中的漏洞路徑，以及它的風險等級。通過使用IaC，在部署流程之前就開始風險檢測，盡早開始風險管理。

威脅建模有助于盡早識別風險，而策略即代碼(PaC)提供了一種為這些威脅建立安全控制的方法。PaC可以集成到基礎架構開發過程中，從而在整個生命周期中檢測和減輕安全和操作問題。將PaC集成到構建管道中可以檢測違規操作和風險，從而防止將問題引入運行時環境中。在運行時，PaC可以檢測違規操作并強制執行策略，從而實現安全。將PaC工具集成到開發過程中，實現自動執行管道中的安全策略，幫助團隊在部署之前發現并修復違規行為。

原則三：部署前掃描IaC發現策略違規行為

?除了IaC的操作優勢之外，它還能夠在開發的早期發現錯誤配置和策略違規，并向開發人員提供實時反饋。在開發人員向存儲庫中提交代碼時不斷掃描IaC，可以及早發現并修復違規行為，而且不會阻礙開發過程。在開發過程中嵌入安全性，并在基礎設施的整個生命周期中強制執行安全性。這種模式被稱為不可變安全，它可以通過以下三個方式來實現：

• 在提供云基礎設施之前降低風險來保護IaC。
• 檢測可能引入風險的新資源和配置更改，確保運行時的云基礎設施安全。
• 將IaC建立的基線同步應用于運行時，從而消除風險漂移。

原則四：部署前掃描應用程序/容器代碼以發現漏洞

?容器應用增加了鏡像、應用程序和基礎設施的攻擊面，為安全漏洞提供了更多可利用的機會。掃描將在基礎設施內部運行的代碼非常重要。SAST、DAST和IAST都用于應用程序安全測試，并且它們各有優缺點。SAST（靜態應用程序安全測試）可以在應用程序開發時發現漏洞，但可能有很高的假陽性。DAST（動態應用程序安全測試）可以檢測正在運行的應用程序中的漏洞，但不能識別它們在代碼中的確切位置。IAST（交互式應用程序安全測試）提供了DAST和SAST都提供的許多好處，但缺點是它需要特定的語言支持。

原則五：為違規行為創建自動拉取請求

?開發人員并不是安全專家，需要提供工具幫助他們在不阻礙業務流程的情況下解決風險。當發現錯誤配置時，應該通知開發人員這個問題，并提供通過拉取請求或合并請求來修復這個問題的代碼。例如代碼修復(RaC)等技術可以自動完成修復，并將它們直接提交給違規代碼所在的存儲庫。開發人員審查建議，并將更改合并到正常工作流的代碼中。這樣做，問題就得到解決，使得建立IaC作為安全基線，并部署基礎設施，這些流程都不會出現問題。

通過代碼修復（RaC）不僅可以解決問題，它也能極大地改善安全狀況。在發現錯誤配置的時候，可以自動修復云基礎設施，在不影響開發速度的情況下快速有效地解決問題。

原則六：在部署期間執行安全策略

?在處理復雜的動態系統時，關鍵問題是很難在開發的早期預測在部署過程中可能會遇到的風險。許多組織在開發后期進行安全審查，但如果出現問題，通常手動流程很難修復這些問題。使得部署過程產生安全摩擦。

因此，組織需要在部署前識別漏洞和違規操作，通過自動修復技術（RaC）簡單快速修復問題，確保部署階段的安全性。部署過程通常使用artifacts和IaC部署到運行時環境中，可以建立PaC控件來驗證artifacts和IaC在部署過程本身是否兼容。

原則七：在運行時執行安全策略

?云基礎設施的配置更改會在運行時發生，原因有很多，而且頻率非常高。事實上，超過90%的組織都會有這種情況發生。為了提高安全性，需要在運行時階段執行與開發和部署階段相同的安全策略。理想情況下，這種強制執行將防止不符合策略的配置更改。

持續監控運行時環境中的配置漂移，并自動將運行時更改重新回傳給IaC，使團隊能夠保持統一性，這有助于避免部署過程中的摩擦，因為開發人員不需要擔心覆蓋重要的運行時配置。同時在運行時檢測到不符合要求的更改，也可以立即從IaC重新部署，以消除有風險的更改。

來源：青藤云安全

原文鏈接：https://weibo.com/ttarticle/p/show?id=2309404791526881624232#_0