2022年云原生安全現(xiàn)狀報告：探尋云擴張的成功之路

22022年云原生安全現(xiàn)狀報告探尋云擴張的成功之路簡介 3執(zhí)行摘要 4云擴張與策略 4安全態(tài)勢及摩擦 4安全驅動程序 4云和云原生安全的全球現(xiàn)狀 5疫情期間的云發(fā)展情況 5云遷移安全挑戰(zhàn) 8高性能的企業(yè)屬性 9安全態(tài)勢和支出 9企業(yè)如何實現(xiàn)更強大的安全態(tài)勢 11開源安全工具的影響 12確定云群體并從中汲取經驗 13哪個群體最能描述您的企業(yè)？ 14云采用群體的現(xiàn)狀 14云擴張迅速具有兩極分化的結果 16安全供應商、工具和團隊的作用 18最佳安全性的群體采用情況 20結語 23方法和統(tǒng)計 23關于 24PaloAltoNetworks 24PrismaCloud 242022年云原生安全現(xiàn)狀報告2在這些年度云原生安全現(xiàn)狀報告中，全球3,000多名受訪者接受了有關其云采用策略、預算、經驗和計劃的調查。他們的回答揭示了用于實施云工作負載和管理云原生架構安全性的實踐、工具和技術。與2020年的報告一樣，我們的目標是突出在云計劃中取得成功的企業(yè)以及未能實現(xiàn)目標的企業(yè)的行為和關聯(lián)成果。各企業(yè)的云安全解決方案呈現(xiàn)出明顯差異。其中包括他們實施技術和流程以支持高安全態(tài)勢(定義為云安全工作的有效性)和低安全摩擦(定義為云安全限制其運營的程度)的差異。毋庸置疑，新冠疫情影響了云擴張和成果(請參閱“新冠疫情的持續(xù)影響”)。盡管各企業(yè)在疫情期間迅速采取行動應對不斷增長的云需求，但許多企業(yè)仍在實現(xiàn)云安全自動化并降低云風險方面面臨困境。然而，從那些剛開始利公司都在持續(xù)向云遷移。該報告確定了方法和成果的模式，生成了三個具有代表性的群體，即采用有限企業(yè)、擴張迅速企業(yè)和成熟用戶。這些群體是根據(jù)云足跡、轉型目標和運營策略等特征生成的。我們將這些群體與嚴謹?shù)臄?shù)據(jù)和群體行為分析一同呈現(xiàn)，以幫助讀者找到自己的同行群體，并確定影響成果的共同挑戰(zhàn)和策略。無論您企業(yè)的云成熟度級別、行業(yè)、地2022年云原生安全現(xiàn)狀報告3隨著云的獨特功能不斷發(fā)展，我們利用云推動業(yè)務發(fā)展的方式也在不斷變化。因此，本報告中的研究特別關注云原生安全社區(qū)中最新的首要問題和內容，包括自動化、DevSecOps、安全態(tài)勢、開源的使用等。我們每年制作本報告的宗旨始終如一：為您提供寶貴的見解，并在2022年及以后的云采用和安全之旅中為您提供指導。?疫情期間，企業(yè)的云使用量在整體上迅速提高了25%以上，但在綜合安全性、合規(guī)性和技術復雜性方面陷入?各企業(yè)以更少的預算增加了對云的使用，39%的企業(yè)在云方面的支出低于1000萬美元(與2020年相比增長16%)，只有26%的企業(yè)的云支出超過5000萬美元(與2020年相比下降17%)。?雖然各企業(yè)仍在繼續(xù)使用各種計算選項，但平臺即服務(PaaS)和無服務器方法的使用率增長了20%，這些方法可以支持快速過渡到云，而容器和容器即服務(CaaS)的使用率增長情況則較為平緩。?具有強大安全態(tài)勢的企業(yè)出現(xiàn)較少安全摩擦(企業(yè)認為云安全支持或限制其運營的程度)的可能性要高出2倍以了對云安全采用雙管齊下的方法的必要性，既可利用卓有成效的安全功能，又不會干擾安全運營之外?如果企業(yè)擁有一流的安全運營，員工可在工作效率和滿意度方面享受最大紅利。80%安全態(tài)勢強大的企業(yè)和85%安全摩擦較少的企業(yè)均表示，員工工作效率有所提高。?大多數(shù)企業(yè)(55%)反映自身安全態(tài)勢薄弱，并認為他們需要改進其基礎活動(例如獲得多云可視性、跨賬戶應用更一致的監(jiān)管或簡化事件響應和調查)以實現(xiàn)更強大的態(tài)勢。?主要使用開源安全工具的企業(yè)中，有80%的企業(yè)安全態(tài)勢薄弱或非常薄弱，而主要利用其云服務提供商的企業(yè)中，這一比例為26%，依賴第三方的企業(yè)中，這一比例為52%，這表明使用不同的工具拼湊平臺會降低企業(yè)的企業(yè)數(shù)量比2020年增加了27%，這表明他們正在減少安全供應商并獲得更多功能。?企業(yè)采用和實施DevSecOps方法的程度是衡量一流安全性的主要指標。緊密集成DevSecOps原則的企業(yè)擁有強大或非常強大的安全態(tài)勢的可能性要高達7倍以上，而安全摩擦較少的可能性要高達9倍以上。2022年云原生安全現(xiàn)狀報告431%631%69%影響今年的調查于2021年5月開展，即新冠疫情迫使人們居家隔離后一年多。我們的受訪者提供了他們在過去12個月(從2020年6月到2021年6月)中做出的業(yè)務決策，這段時期代表了二戰(zhàn)以來最嚴重的全球社會經濟動蕩時期。這些企業(yè)所做的決策是為了應對云交付服務需求方面意想不到的巨變，這種變化幾乎同時在全球范圍內上演，并對每個行業(yè)產生以下“如果沒有在整個開發(fā)管道中嵌入自動化的安全控制，快速的云擴張和復雜性這二者結合會造成危害。”和線上醫(yī)療的快速過渡大幅增加了在線協(xié)作和會議工具的使用。型應用的迫切需求激增。轉向接觸較少的網(wǎng)購和外賣用餐。鏈管理，各方各面對云基礎設施支持的需求越來越大。隨著各公司競相滿足意想不到的新需求，他們發(fā)現(xiàn)自己正面臨另一種全球威脅：網(wǎng)絡攻擊。PaloAltoNetworks的一份關于新冠疫情的Unit42云威脅報告指出，“安全事件的爆炸式增長”與疫情最初六個遷移到云在本報告的第一部分，我們回顧了全球企業(yè)報告的云采用和云安全活動的廣泛趨勢。(有關報告中調查對象的詳細部分。)發(fā)展情況疫情期間，云工作負載總體顯著增加，云托管工作負載比例從2o2o年的平均46%躍升至平均59%。此外，69%的企業(yè)將一半以上的工作負載托管在云中，而2020年這一比例僅為31%。446%59%圖1：2020年以來的云工作負載量變化情況(百分比)2022年云原生安全現(xiàn)狀報告5各企業(yè)秉承前瞻性理念，自去年以來沒有顯著改變他們對云使用方式的期望。平均而言，各企業(yè)預計在兩年內將68%的工作負載托管在云中，這與去年65%的預期基本一致。盡管疫情期間的轉變速度比許多企業(yè)預期的要隨著企業(yè)轉向私有云工作負載托管，今年云的構成也發(fā)生了變化，平均55%的云工作負載托管在私有云上，比2020年增加了7個百分點。雖然各企業(yè)仍在繼續(xù)使用各種計算選項，但PaaS和無服務器方法的使用率增長了2o%，而容器和CaaS的使用率增長情況則較為平緩。PaaS和無服務器策略允許開發(fā)團隊將應用放在云中，而無需同時構建和擴展基礎架構，這可能有助于支持過去一年中向云的快速過渡。這是我們預計將繼續(xù)進行并將密切關公有48%52%2020私有55%4545%20%2021虛擬機容器CaaSPaaS和無服務器其他202120202021202020212020202120202021202024%30%17%24%13%121%122%4%3%42%圖2：公有云與私有云中托管的工作負載份額(左)；按計算類型劃分的工作負載份額(右)在研究企業(yè)擴展其云功能的原因時，我們發(fā)現(xiàn)戰(zhàn)略業(yè)務驅動因素推動了這一增長，這些因素包括應用現(xiàn)代化、保持競爭力和控制基礎設施開銷。雖然疫情無疑是今年報告中的一個影響因素，但總體而言，這些原因仍然是企業(yè)選擇企業(yè)的業(yè)務發(fā)展速度越來越快。應用現(xiàn)代化保持市場競爭力降低基礎架構開銷合規(guī)性參與更廣泛的數(shù)字化轉型工作提高開發(fā)人員的敏捷性誕生于云/始終在云端61%53%51%142%140%39%16%圖3：擴展云功能的原因2022年云原生安全現(xiàn)狀報告621%<$10M39%日本報告稱未來24個月21%<$10M39%日本報告稱未來24個月內，無服務器架構的使用量增幅最大(57%)，這一比例高于其他所有架構。近半數(shù)(47%)的美國受訪者表示安全態(tài)勢強大或非常強大，這一比例與其他國家/地區(qū)相比更高。在巴西，近一半(48%)的受訪者預計其公司在未來兩年內將有76-100%的工作負載在云中，這表明了各企業(yè)向云敞開懷抱的趨勢。支出在1ooo萬美元以內，與2020年相比增加16%，只有26%的企業(yè)的云支出超過5ooo萬美元，與2020年相比下降17%。云支出的下降可能是由于疫情導致全面預算削減或資金重新分配的結果，也可能只是反映了云活降。 $￥ €26%$50M46%2020年，21%的企業(yè)對云的投2021年，這一比例增至39%。云預算超過5000萬美元的企業(yè)從資不到1000萬美元。46%下降到26%。圖4：云預算的變化雖然不同行業(yè)、地域和收入的云采用方式略有不同，但數(shù)據(jù)表明這些差異在整體結果中并沒有發(fā)揮重要作用。也就德國報告的自動化安全流程比例最高(40%)。與任何其他接受調查的國家/地區(qū)相比，英國使用更多開源工具作為其主要云安全提供商。圖5：云趨勢(按全球地區(qū)劃分)2022年云原生安全現(xiàn)狀報告7過去一年，各企業(yè)迅速擴大了對云的使用，他們報告的最大挑戰(zhàn)與去年的受訪者相同，即綜合安全性和合規(guī)性以及維護全面安全性滿足合規(guī)性要求技術復雜性20212020202120202021202050%39%42%32%145%42%圖6：云遷移挑戰(zhàn)雖然最高云預算有所下降，但云安全預算仍保持穩(wěn)定。這意味著，雖然各企業(yè)的總體云支出較少，但是他們的安全預算沒有打折扣。這突出表明各公司了解保護云以便充超過3o人，這一比例高于去年的41%。此外，各公司在擴展云環(huán)境時還整合了他們的云安全供應商。數(shù)據(jù)顯示，自去年以來，僅使用一到五個安全供應商的企業(yè)數(shù)量增加了27%，而使用六到十個供應商的企業(yè)數(shù)量下降了19%。44%20201515%2021圖7：受訪者將超過20%的云預算用于安全方面80%60%40%20%0%1-5個安全供應商6-10個安全供應商68%41%41%39%120%20%202022020圖8：安全供應商數(shù)量的變化2022年云原生安全現(xiàn)狀報告8雖然各公司減少了他們合作的安全供應商的數(shù)量，但他們所利用的安全工具的數(shù)量同比變化很小。我們將云安全供應商定義為企業(yè)雇用來保護其云和安全工具的所有公司，依據(jù)是這些網(wǎng)絡安全公司提供的能力和/或功能的數(shù)量。近四分之三的企業(yè)使用1o種或更少的安全工具，這表明他們正致力于通過更少的安全供應商來滿足大量功能需求。這種整合可得出以下觀察結果，即依賴多個供應商的不同工具的企業(yè)可能會遇到盲點，因此增加風險并需要額外工作來縮小這些差距。28%的企業(yè)仍在使用大量工具(其中8%的企業(yè)使用21到50多種工具)，我們會為他在使用21種或更多安全工具的企業(yè)中，幾乎所有(91%)企業(yè)都要通過六個或更多供應商來提供這些工具。為了同時管理諸多工具，這些企業(yè)需具備更大的團隊來管理和支持云工作負載安全；其中近一半(49%)的企業(yè)雇用了50多名員工來管理云安全。因此，收入更高的公司更有可能使用更多工具，這一點也許不足為奇。在收入達10億美者中，這一比例只有3%。除了安全供應商和工具的使用差異之外，我們還調查了成功實現(xiàn)云擴張的企業(yè)的安全屬性。該研究強調了云原生安的影響。業(yè)評估其云安全工作有效性的方式。業(yè)認為云安全支持或限制其運營的程度。為衡量云安全態(tài)勢，我們詢問了受訪者對于六項陳述的認同度。受訪者對這些陳述的認同度越高，說明他們對企業(yè)云安全態(tài)勢的整體認知就越強。我們發(fā)現(xiàn)，安全態(tài)勢薄弱的企業(yè)略多一些(55%)。更具體地說，這些企業(yè)認為需要加強他們基礎活動(例如獲得多云可視性、跨帳戶應用更一致的監(jiān)管或簡化事件響應和調查)的效果。具有強大安全態(tài)勢的企業(yè)往往安全支出更多。三分之二以上擁有強大或非常強大的安全態(tài)勢的企業(yè)將16%或更多云預算用于安全方面。在安全態(tài)勢薄弱或非常薄弱的企業(yè)中，只有不到五分之一的企業(yè)將相同比例的云預算用于安全方面?！鞍踩珣B(tài)勢強大”的企業(yè)似乎也計劃增加其安全支出。近四分之三(71%)安全態(tài)勢強大或非常強大的企業(yè)計劃在未來12個月內將16%或更多云預算用于安全方面，而在安全態(tài)勢薄弱或非常薄弱的企業(yè)中，這一比例只有46%。我們的安全工具提供對所有云帳戶和資源的可視性我們的風險和漏洞優(yōu)先級極為有用我們的自動化運行時保護為工作負載提供了強大的安全基線我們的安全工具為所有云原生應用和資源提供強大的監(jiān)管策略云安全態(tài)勢我們的安全工具有助于輕松維護合規(guī)環(huán)境并輕松生成審計就緒報云安全態(tài)勢我們的安全工具有助于更輕松地開展調查和響應事件非常強大6%強大39%45%強大云安全態(tài)勢薄弱33%非常薄弱22%55%薄弱云安全態(tài)勢圖9：影響安全態(tài)勢的因素(左)；安全態(tài)勢強大或薄弱的企業(yè)比例(右)2022年云原生安全現(xiàn)狀報告929%90%80%70%60%50%為了分析云安全摩擦，我們詢問受訪者對于兩項陳述(關于云采用和云安全帶來的業(yè)務成果)的認同度。受訪者對29%90%80%70%60%50%這些陳述的認同度越高，說明他們對企業(yè)云安全摩擦的整體認知就越強。關于這個問題，我們發(fā)現(xiàn)只有不到一半(48%)的企業(yè)認為他們的安全摩擦較少。云安全摩擦云安全摩擦由于云安全方面的問題，我們的云擴張未達到預期投資回報率安全流程導致我們的項目時間安排有所延遲高摩擦中摩擦低摩擦24%28%48%圖10：引起企業(yè)摩擦的因素(左)；具有高、中或低摩擦的企業(yè)比例(右)通過結合這兩個指標，我們發(fā)現(xiàn)實現(xiàn)低安全摩擦對于加強安全態(tài)勢而倍多。這凸顯了對云安全采取雙管齊下的方法的必要性：各企業(yè)應努力獲得最有效的安全功能，但他們需要確保這些工具和流程不會干擾除了出色的運營之外，我們還發(fā)現(xiàn)了實現(xiàn)這些一流安全成果的其他優(yōu)勢。在實現(xiàn)了高安全態(tài)勢和低摩擦的企業(yè)中，員工在工作效率和滿意度方面享受了最大紅利，超過8o%的安全摩擦較少的企業(yè)提高或顯員工滿意度。771%例提升工作效率提升滿意度非常薄弱薄弱強大安全態(tài)勢等級安全態(tài)勢進行對比2022年云原生安全現(xiàn)狀報告1022%16%現(xiàn)更強大的安全態(tài)勢22%16%接下來，我們研究了表現(xiàn)最好的企業(yè)為減少企業(yè)摩擦及改善整體安全態(tài)勢而采取的方法。實現(xiàn)這種一流的均衡安全：?DevSecOps集成-云安全接觸點集成到整個開發(fā)生命周期(從構建到運行時)的程度。?云安全自動化-云安全自動化的程度。我們要求受訪者在回答四個問題時以“從不”到“總是”的等級為他們企業(yè)的DevSecOps集成程度打分。DevSecOps集成交付周期的要求和設計階段交付周期的構建階段交付周期的測試階段交付周期的部署階段具有高度DevSecOps集成的團隊比例661%化團隊高自動化團隊低自動化團化團隊高自動化團隊圖13：影響DevSecOps集成衡量的因素(左)；將DevSecOps集成與自動化級別進行對比(右)企業(yè)采用和實施DevSecOps方法的程度是衡量一流安全性的主要指標。將DevSecOps原則緊密集成到開發(fā)生命周期中的企業(yè)擁有強大或非常強大的安全態(tài)勢的可能性要高達7倍以較少的可能性要高達9倍以上。為了衡量自動化程度，我們要求受訪者評估他們的企業(yè)對五種安全實踐的自動化程度，等級從“完全手動”到“完全自超過7倍擁有強大或非常強大的安全態(tài)勢的可能性要高達7倍以上并且9倍安全摩擦較少的可能性要高達9倍以上圖14：緊密集成DevSecOps原則的企業(yè)成果全自動化登錄云帳戶以實現(xiàn)可視性錯誤配置補救措施掃描基礎架構即代碼(IaC)模板在CI/CD期間掃描容器映像安全警報的票證創(chuàng)建772%自動化團隊低安全摩擦的團隊比例3838%團隊441%低自動化團隊圖15：影響自動化衡量的因素(左)；將安全摩擦與自動化水平進行對比(右)2022年云原生安全現(xiàn)狀報告3%2%80%72%60%41%38%40%25%20% 0%CSPCSP3%2%80%72%60%41%38%40%25%20% 0%CSPCSP低安全摩擦百分比強大/非常強大的安全態(tài)勢百分比100%83%331%自動化中級別自動化自動化各企業(yè)針對其安全工具提供商采取了多種方法，將云服務提供商(CSP)、第三方和開源安全工具加以利用。然而，與使用第三方或CSP方法的同行相比，主要依賴開源工具的企業(yè)的預算通常較少，但萬萬沒想到，這些團隊比使用第三方或CSP提供商工具的團隊規(guī)模更大，7o%主要依賴開源工具的企業(yè)報告稱其安全團隊有3o名或更。16%29%29%21%5%主要安全提供商25%18%36%18%第三方主要安全提供商14%47%32%5%開源主要安全提供商7%26%39%21%7%均衡安全提供商安全支出占云預算百分比1–5%6–10%11–15%21–30團隊規(guī)模少于20人16–20%51+3151+21%10%36%28%26%主要安全提供商13%34%27%26%第三方主要安全提供商17%53%20%10%開源主要安全提供商19%36%33%12%均衡安全提供商圖17：安全提供商和團隊預算(上)以及規(guī)模(下)2022年云原生安全現(xiàn)狀報告212%64%15%9%CSP6%6%442%32%20%第三方非常薄弱薄弱1%19%51%29%強大非常強大2%15%43%40%衡圖18：安全提供商和安全態(tài)勢總的來說，數(shù)據(jù)表明開源安全工具無法提供全面集成方法來滿足企業(yè)正在尋找的所有能力和功能。成功利用開源安全工具的企業(yè)似乎只是將預算成本轉移到勞動力上，以此為他們的工作提供支持。希望采用開源工具的企業(yè)應準備方案提供商提供此類支持。并從中汲取經驗如上所述，為了確定某些框架是否可以在DevSecOps方法和自動化安全之外推動一流的安全性，我們發(fā)掘出各企業(yè)在疫情期間推動云環(huán)境和云安全時采用的模式。疫情期間提供了自然實驗，我們能夠對比不同的方法并了解這些方法對大幅精簡時間線的影響。這種集中遷移到云端的操作無需等待數(shù)年，而是在短短幾個月內就迅速產生了我們利用數(shù)據(jù)根據(jù)企業(yè)行為和云安全方法發(fā)現(xiàn)了三個具有代表性的群體。請注意，無論地理獨特見解。第一個群體是采用有限企業(yè)，包括在疫情前和疫情期間不太關注云采用的企業(yè)。第二個群體是擴張迅速企業(yè)，包括在疫情前云足跡較少但在疫情期間快速、廣泛采用云的企業(yè)。最后，擴張的企業(yè)。使用這些數(shù)據(jù)與同行進行基準測試、驗證經驗并了解差異。借助此分析，您還可以確定最符“這使我們能夠跳出企業(yè)身份，根據(jù)企業(yè)應對云和云安全計劃的方法對云成功因素和失敗路徑獲取獨特見解?！?022年云原生安全現(xiàn)狀報告133939%62%采用有限的企業(yè)：占總數(shù)的39%更可能擁有低收入疫情爆發(fā)之前：云足跡較小疫情爆發(fā)期間：云擴張穩(wěn)定戰(zhàn)術價值驅動發(fā)展云投資和優(yōu)先級較低利用無服務器架構規(guī)劃：云使用總量的目標較平均(62%)333%62%擴張迅速的企業(yè)：占總數(shù)的33%更可能擁有高收入疫情爆發(fā)之前：云足跡較小疫情爆發(fā)期間：云擴張迅速戰(zhàn)略和戰(zhàn)術價值驅動發(fā)展平均云投資和優(yōu)先級當前：利用PaaS架構規(guī)劃：云使用總量的目標校平均(62%)884%28%成熟用戶：占總數(shù)的28%大多為大型企業(yè)(按收入)疫情爆發(fā)之前：云足跡較大疫情爆發(fā)期間：云擴張穩(wěn)定戰(zhàn)術價值驅動發(fā)展云投資和優(yōu)先級較高均衡使用計算環(huán)境規(guī)劃：云使用總量的目標較高(84%)云采用群體的特征常是一致的。采用有限的企業(yè)擴張迅速的企業(yè)成熟用戶采用有限的企業(yè)擴張迅速的企業(yè)成熟用戶消費者生命科學和醫(yī)療保健金融服務1,000萬美元以下能源、資源和行業(yè)1,000萬金融服務1,000萬美元以下能源、資源和行業(yè)5億-10億美元科技、媒體和電信105億-10億美元科技、媒體和電信圖20：按行業(yè)劃分的云采用群體(左)；按收入劃分的云采用群體(右)1億-5億美元超過50億美元采用有限企業(yè)在疫情之初云足跡較少，并且在接下來的12個月內增長幅度最小。擴張迅速企業(yè)在疫情之初的云足相比之下，成熟用戶擁有大量現(xiàn)有云足跡，但與采用有限企業(yè)類似，計劃當被問及未來計劃時，疫情前足跡較小的兩個群體(采用有限企業(yè)和擴張迅速企業(yè))預計在未來兩年內將有62%的工作負載遷移到云端。相比之下，成熟用戶預計將繼續(xù)大量使用云，在未來兩年內將有平均84%的工作負載遷2022年云原生安全現(xiàn)狀報告144%4%2%49%35%14%26%59%33%84%4%4%2%49%35%14%26%59%33%84%61%13%74%20202021當前總額2022年的目標采采用有限的企業(yè)62%擴擴張迅速的企業(yè)62%成熟用戶成熟用戶云工作負載比例在所有群體中，云支出差異很大。只有42%的采用有限企業(yè)在云方面的支出超過1000萬美元，相比之下，擴張迅速企業(yè)的這一比例為69%，成熟用戶為70%。成熟用戶的云預算也最高，有10%的成熟用戶的云支出超過1億美元，而采用有限企業(yè)和擴張迅速企業(yè)的這一比例分別只有2%和1%。2%13%27%39%15%15%1%24%44%25%10%33%27%26%4%采用有限的企業(yè)擴張迅速的企業(yè)成熟用戶不知道/無支出1,000萬-5,000萬美元100萬美元以下5,000萬-1億美元100萬-1,000萬美元1億美元以上圖22：采用群體的云總體支出2022年云原生安全現(xiàn)狀報告15境我們還發(fā)現(xiàn)了云架構方法的差異。成熟用戶更有可能使用混合計算環(huán)境，包括虛擬機(VM)、容器/CaaS、PaaS和無服務器，其中65%的企業(yè)均衡使用這四種環(huán)境。擴張迅速企業(yè)也采用一種基本平衡的方法(48%)，但該群體對于PaaS的使用是成熟用戶的兩倍(分別為28%和14%)。此決策可跳過基礎架構管理，可能為擴張迅速企業(yè)根據(jù)我們的分析，云足跡較少且增長計劃較慢的采用有限企業(yè)可能不是“云優(yōu)先”企業(yè)；相反，他們的云計算工作旨在支持其他企業(yè)策略。該群體的計算決策(其中47%主要使用無服務器，32%使用平衡堆棧)可能反映了這一礎架構。10%32%11%47%的企業(yè)28%48%10%14%企業(yè)14%65%9%12%無服務器側重于VM平衡側重于PaaS圖23：按采用群體計算架構組合果調查這些群體的云目標后，我們發(fā)現(xiàn)了一個讓人意想不到的模式。擴張迅速企業(yè)群體分為兩個不同的子群體。大多數(shù)擴張迅速企業(yè)(74%)紛紛成功擴大其云足跡，在過去一年將35%的工作負載轉移到云端，并計劃在未來兩年內再轉移12%的工作負載。相比之下，另外26%的擴張迅速企業(yè)在疫情期間將28%的工作負載轉移到了云端，但令人驚訝的是，他們計劃在未來兩年內將云工作負載減少26%，這表明他們計劃將工作負載移出云端，或不擴張迅速企業(yè)群體的這種分歧引發(fā)了新的問題：是什么導致了如此巨大的分歧？我們可以從這些企業(yè)的經驗中汲取什么經驗？我們如2020202120202021采用有限的企業(yè)35%14%+13%擴張迅速的企業(yè)采用遇阻34%28%-26%擴張迅速的企業(yè)采用成功24%35%+12%擴張迅速的企業(yè)61%13%+10%圖24：2020–2021年云工作負載增長情況和2022–2023年預期情況2022年云原生安全現(xiàn)狀報告164%44%34%17%1%隨著我們深入調查，發(fā)現(xiàn)在云采用工作中取得成功以及經歷了重要挑戰(zhàn)的擴張迅速企業(yè)可以解釋這種分歧。與更成4%44%34%17%1%功的同行相比，在云采用過程中遭遇挑戰(zhàn)的擴張迅速企業(yè)在云方面的投資要高得多，2o21年，有45%的公司在云方面的支出超過5ooo萬美元，相比之下，如今只有13%的擴張迅速企業(yè)繼續(xù)保持其發(fā)展軌跡。這表明一些擴2%13%27%39%15%15%采用有限的企業(yè)1%2%2%2%擴張迅速的企業(yè)采用遇阻1%11%51%30%6%擴張迅速的企業(yè)采用成功10%33%27%26% 4%成熟用戶不知道/無支出100萬美元以下100萬-1,000萬美元1,000萬-5,000萬美元5,000萬-1億美元1億美元以上圖25：采用群體的支出水平我們還發(fā)現(xiàn)這些群體的云目標存在顯著差異。對于所有群體而言，應用現(xiàn)代化和保持競爭力等短期目標是云擴張的主要驅動因素，而更具戰(zhàn)略性的思維則處于次要地位。但是，他們在企業(yè)一致性方面存在很大差異，成功的擴張迅倍多。采用有限的企業(yè)擴張迅速的企業(yè)采用遇阻擴張迅速的企業(yè)采用成功成熟用戶應用現(xiàn)代化保持市場競爭力降低基礎架構開銷參與更廣泛的數(shù)字化轉型工作合規(guī)性提高開發(fā)人員的敏捷性誕生于云/始終在云端158%49%39%29%40%37%11%64%57%52%40%35%46%23%77%75%75%73%58%51%16%52%38%46%25%32%29%20%圖26：將工作負載遷移到云端的原因2022年云原生安全現(xiàn)狀報告1716%60%23%7%16%40%37%35%20%27%18%16%60%23%7%16%40%37%35%20%27%18%觀點，即成功的云采用必須成為更廣泛的戰(zhàn)略企業(yè)轉型的一部分，因為云將影響業(yè)務的許多領域，并且擴展業(yè)務規(guī)模必須準備好支持這些變化。雖然調查中途退出的擴張迅速企業(yè)僅占所有參與調查的企業(yè)的8%，但他們也強調了采用有限的企業(yè)擴張迅速的企業(yè)采用遇阻擴張迅速的企業(yè)采用成功維護全面安全性技術復雜性滿足合規(guī)性要求重構傳統(tǒng)應用缺乏對服務和提供商的了解缺乏人才和/或咨詢服務缺少預算沒有明確的云遷移策略54%43% 46% 36%1 25%24%12% 12%54%34%35%34%33%33%38%21%51%60%51%39%49%43%35%30%圖27：云采用計劃的主要挑戰(zhàn)同的方法與安全供應商合作，在取得成功的企業(yè)中，有83%的企業(yè)使用了五個1%成熟用戶43%39%33%31%30%27%19%15%19%30%40%11%采用有限的企業(yè)擴張迅速的企業(yè)采用遇阻擴張迅速的企業(yè)采用成功成熟用戶1-2個供應商3-5個供應商6-10個供應商圖28：使用的獨立安全供應商數(shù)量2022年云原生安全現(xiàn)狀報告18接下來，我們調查安全團隊時發(fā)現(xiàn)，成功的擴張迅速企業(yè)往往擁有相對較小的團隊以及較小的供應商網(wǎng)絡，但安全工具更多(再次強調，安全工具被定義為網(wǎng)絡安全公司提供的能力和/或功能的數(shù)量)。另一方面，經歷過挑戰(zhàn)的。16%41%24%19%采用有限的企業(yè)20%27%28%25%擴張迅速的企業(yè)采用遇阻6%6%2323%36%35%擴張迅速的企業(yè)采用成功16%56%22%6%成熟用戶少于20人21–3031–5051+圖29：云安全團隊的規(guī)模研究表明，所有群體都在使用大量安全工具，其中超過一半的群體使用超過五種工具。這表明，既定環(huán)境所需的最佳安全工具數(shù)量可能存在一個變量方程，其中較大的云環(huán)境必然需要更多工具，或者不同的團隊傾向于使用不同的而導致缺少安全信息和控制所致。28%25%38%9%采用有限的企業(yè)26%37%29%8%擴張迅速的企業(yè)采用遇阻13%62%20%20%5%5%擴張迅速的企業(yè)采用成功40%26%24%10%成熟用戶1-2個工具3-5個工具6-10個工具圖30：使用的工具數(shù)量(不考慮供應商)如果存在這樣的變量方程，數(shù)據(jù)表明安全工具的集成也是一個關鍵因素。利用少于五種安全態(tài)勢，但團隊之間的摩擦不受工具數(shù)量的影響。相反，您可以通過DevSecOps方法集成您的安全工具，獲得更廣泛的可視性和全面控制，。“您可以通過DevSecOps方法集成您的安全工具，獲得更廣泛的可視性和全面控制，從而收獲更好的成果。”2022年云原生安全現(xiàn)狀報告1937%44%30%52%37%44%30%52%低安全摩擦百分比強大/非常強大的安全態(tài)勢百分比60%60%55%57%55%49%4049%20%18%0%1-2個工具3-5個工具6-10個工具11-20個工具21個以上工具數(shù)量和安全成果情況在上文中，我們討論了DevSecOps集成和安全自動化作為實現(xiàn)最佳云安全的關鍵要素的重要性。我們的群體表明，63%成功擴張其云采用的擴張迅速企業(yè)還集成了DevSecOps原則。即使與成熟用戶相比，這一數(shù)字也要高明成功的擴張迅速企業(yè)在擴展云功能時特別注意在整個開發(fā)生命周期中集成安全性。14%44%42%采用有限的企業(yè)15%36%49%擴張迅速的企業(yè)采用遇阻63%24%13%擴張迅速的企業(yè)采用成功35%32%33%成熟用戶低DevSecOps中DevSecOps高DevSecOps圖32：在應用生命周期中集成DevSecOps的程度2022年云原生安全現(xiàn)狀報告20同樣，大量使用云的群體(成熟用戶和成功的擴張迅速企業(yè))也傾向于自動化，這兩類群體中分別有44%和40%的企業(yè)呈現(xiàn)高度自動化。另一方面，在云擴張方面遭遇困境的擴張迅速企業(yè)則處于落后狀態(tài)，其中4o%的化程度較低。14%66%20%采用有限的企業(yè)12%48%40%擴張迅速的企業(yè)采用遇阻44%39%17%擴張迅速的企業(yè)采用成功40%3636%24%成熟用戶低自動化動化圖33：整個開發(fā)生命周期的安全自動化水平最終，我們發(fā)現(xiàn)取得成功的擴張迅速企業(yè)擁有最強大的安全態(tài)勢，其中81%的企業(yè)的安全態(tài)勢為強大或非常強大。成熟用戶以50%的比例排在第二位，而69%處于困境中的擴張迅速企業(yè)表現(xiàn)的安全態(tài)勢薄弱或非常薄弱。采用有限企業(yè)的安全態(tài)勢也較薄弱，但如前所述，該群體仍然致力于少量使用云，他們可能會以不同的方式衡量云2%19%54%25%采用有限的企業(yè) 5%26%35%34%擴張迅速的企業(yè)采用遇阻9%72%10%9%擴張迅速的企業(yè)采用成功8%42%25%25%成熟用戶非常薄弱弱大非常強大圖34：所有云采用群體的安全態(tài)勢水平2022年云原生安全現(xiàn)狀報告5%8%42%45%此處有更多跡象表明，企業(yè)一致性對于成功的云轉型至關重要，在安全態(tài)勢中遇到困難的群體也會在安全摩擦方面5%8%42%45%陷入困境。半數(shù)苦苦掙扎的擴張迅速企業(yè)存在高安全摩擦，而成功的擴張迅速企業(yè)和成熟用戶中該比例只有13%和14%。33%33%34%采用有限的企業(yè)50%37%37%49%13%擴張迅速的企業(yè)采用遇阻13%20%67%擴張迅速的企業(yè)采用成功14%24%62%成熟用戶低摩擦圖35：所有云采用群體的企業(yè)摩擦數(shù)量雖然這些企業(yè)使用了一系列安全提供商，但經歷過挑戰(zhàn)的擴張迅速企業(yè)傾向于利用更多開源安全提供商。相比之的企業(yè)專注于CSP或第三方驅動的安C