【譯】Gartner CWPP市場指南

原文：https://www.gartner.com/doc/reprints?id=1-1YSHGBQ8&ct=200416&st=sb?utm_source=marketo&utm_medium=email&utm_campaign=2020-05-22 03:03:51-Global-DA-EN-20-05-04-7010g000001JNCsAAO-P1-Prisma-2020-gartner-market-guide-for-cwpp-[FY20]
本人是一枚初學者新手，若有不對指出，請不吝賜教。

雲原生安全保護的需求不斷髮展，包括公有云和私有云中的虛擬機、容器、無服務器工做負載，安全管理人員必須解決混合雲工做負載環境中獨特的安全動態問題。

概述

問題現狀

• 企業使用終端保護平臺（EPP）做爲服務器工做負載保護，可是EPP 的功能僅僅是用來保護終端用戶設施的（如：桌面、筆記本電腦等），這種防禦措施無疑將企業的應用程序與數據至於風險之中。
• 大多數企業都使用了不止一個公有云基礎設施服務。
• 如今大多數企業都在使用基於容器的服務，而且在嘗試PaaS平臺服務。
• 對於雲遠程安全應用，工做負載的安全性須要前置於編碼開發過程。
• 如今愈來愈多的容器和無服務負載被掃描出漏洞，可是對工做負載卻不多作保護或者運行時保護措施，而是依靠外部網絡檢測和事件監視來檢測威脅。
• 雲工做負載配置不當致使的風險高於工做負載折衷致使的風險。

Recommendations 建議

爲基礎設施安全管理人員提供以下幾項建議：

• 架構師負責對全部工做負載(不管位置、大小或架構)進行一致的可見性和控制。
• 要求雲工做負載保護平臺（CWPP）供應商經過計劃用於無服務器的解決方案來支持容器。若是您的舊供應商不符合您的容器要求，請公開提出解決方案。
• 將工做負載掃描和合規性工做擴展到開發（DevSecOps），尤爲是基於容器和無服務器功能，基於PaaS的開發和部署。
• 要求CWPP產品開放API。
• 在運行時，採用零信任模式來替代以反病毒爲中心的策略，At runtime, replace antivirus-centric strategies with a 「zero-trust execution」/default deny approach to workload protection where possible, even if used only in detection mode.
• Architect for CWPP scenarios where runtime agents cannot be used or no longer make sense.
• 要求CWPP供應商提供集成雲安全態勢管理(CSPM)功能，以識別風險配置。

市場定義

CWPP的市場由以工做負載爲中心的安全產品定義，這些產品針對現代混合，多雲數據中心架構中工做負載的獨特保護要求（請參閱注2）。 CWPP應爲物理計算機，虛擬機（VM），容器和無服務器工做負載提供統一的可見性和控制力，而不管其位置在哪裏。
CWPP的產品應該從掃描開發中已知的漏洞開始。在運行時，CWPP產品應該保護工做負載免受攻擊，一般包括系統完整性保護、應用程序控制防禦、內存保護、行爲監視、基於主機的入侵預防和可選的反惡意軟件保護功能等。

市場描述

終端保護市場已經分化爲以終端用戶爲中心的設備保護產品EPP和CWPP，也就是本文的研究對象。不管工做負載的位置或粒度如何，cwpp均可以保護服務器工做負載免受攻擊。cwpp爲安全管理人員提供對服務器工做負載的可見性和可控性。然而，現代數據中心的組成、工做負載的粒度和開發速度都在迅速變化。CWPP產品和安全管理人員都必須不斷髮展，以適應環境的變化。
現代數字業務應用程序和服務由本地和IaaS中運行的多個工做負載組成。在大多數狀況下，企業會以定製的方式使用多個供應商的lass服務。儘管使用運行在本地工做負載的狀況在減小，但大多數企業認爲，至少將來幾年內仍是會使用本地工做負載的方式。現實狀況是，大多數企業將把工做負載分佈在本地、託管在多個IaaS服務平臺，咱們將其稱爲混合多雲架構。 CWPP必須支持這一點。
同時，工做負載的粒度、生命週期以及建立方式也在改變。如今，大多數企業在開發、試驗或生產過程當中至少使用一個基於Linux容器的應用程序，PaaS服務的採用也愈來愈多，無論工做負載的粒度如何，都應採用CWPP策略以提供一致的可見性和對工做負載的控制。

圖1:工做負載的抽象演化
隨着敏捷開發模式盛行，一般每週都會有幾回迭代，有時甚至一天好幾回迭代，此時工做負載的粒度也變得愈來愈細化、生命週期也愈來愈短，保護這些快速變化和短時間工做負載的最佳方法是在開發階段滲入保護機制，以便在生產環節中實例化時，這些工做負載從「誕生」就是受到保護的。此外，雲原生應用程序一般虛擬機、容器、以及PaaS服務組成，全部這些設備都須要收到保護。所以，隨着工做負載粒度和動態變化，CWPP產品也須要不斷適應這一變化。
有時，咱們也會發現企業在服務器工做負載上使用了面向終端用戶的EPP產品，這些產品是專爲臺式機、筆記本電腦和平板電腦設計的，它們不適合於動態混合、多雲工做負載保護的需求。服務器工做負載面臨的風險和威脅明顯不一樣於面向終端用戶的系統，使用爲終端用戶設備設計的EPP產品的企業正在將企業數據和應用程序置於風險之中。相比之下，CWPP專一於現代混合(基於本地和雲)、多雲(使用多個公共雲IaaS供應商)數據中心中服務器工做負載的保護需求。事實上，一些較大的CWPP供應商，如趨勢科技(Trend Micro)、賽門鐵克(Symantec)和邁克菲(McAfee)，爲EPP和CWPP提供不一樣的、獨立的產品，以知足這些市場的獨特需求。一些規模較小的廠商只面向CWPP市場。差別包括CWPP的要求，如平臺的徹底可編程性以及應用程序控制和雲平臺集成的重要性。CWPP的另外一個關鍵區別是，須要支持在DevSecOps環境中使用持續集成/持續部署(CI/CD)掃描的Linux和Linux容器。

市場導向

CWPP爲企業提供了一種保護混合、多雲工做負載的方法，無論工做負載的位置或粒度，並提供了對全部服務器工做負載的一致可見性和控制。2019年，咱們已經正式估計這個市場將達到12.44億美圓，增加率爲20.5%，三個最大的供應商——趨勢科技、賽門鐵克和邁克菲佔了CWPP市場年收入的大約一半。
企業愈來愈多地使用CWPP產品，背後也存在着諸多優點：

• 工做負載正在從本地遷移到公共雲IaaS平臺, IaaS工做負載的整體數量(包括容器和無服務器功能)正在快速增加。
• 在公共雲IaaS平臺中，以工做負載爲中心、基於主機的CWPP解決方案，提供了比傳統基於串聯網絡的安全策略更易實現的安全架構，拿設備來講，基於工做負載的產品會隨着工做負載數量的增長、減小而自動擴展、縮減。
• 在必須終止會話的主機工做負載下，更容易實現對安全套接字層/傳輸層安全性（SSL / TLS）解密和檢查，而沒必要使用「中間人」方法來解密流量。對於檢查基於微服務的體系結構中從一個服務到另外一個服務的橫向東西向流量，尤爲如此。
• 在使用基於容器的應用程序體系結構、基於微服務的應用程序以及採用無服務器PaaS向雲原生應用程序開發的轉變過程當中，CWPP也須要在開發和運行時都具備新的功能。雲原生應用程序須要特定的解決方案，這些解決方案旨在知足基於雲的系統的保護要求。
  CWPP其餘關鍵市場趨勢包括：
• 使用雲原生加密對公共雲中的全部靜態數據進行加密。此功能之前是CWPP產品的常見功能，可是大多數企業使用操做系統或底層雲結構的內置加密功能（請參閱註釋5）。所以，在 2020年市場指南中，加密不是CWPP的必要要求。
• 默認狀況下使用基礎雲平臺進行細分。許多企業更喜歡使用基礎雲結構（例如，Azure網絡安全組）的內置分段功能。這減小了CWPP供應商提供基於主機的防火牆的需求。可是，對於那些專一於微細分的CWPP供應商來講，與底層雲平臺的細分功能的本機功能集成是常見的要求。
• 企業對工做負載威脅檢測和響應能力的需求。Gartner在CARTA戰略框架和適應性安全架構中指出，CWPP戰略不能僅僅依賴於預防性控制。所以，服務器工做負載行爲監視(服務器終端檢測與響應 EDR)正成爲CWPPs的關鍵需求。像CrowdStrike（以EDR產品聞名）這樣的廠商如今正積極地實踐工做負載威脅檢測和響應。事實上，一些CWPP廠商只關注工做負載的威脅檢測/響應(有時也稱爲雲威脅檢測和響應 CDR)。
• 工做負載的生命週期愈來愈短。在使用容器和無服務器計算的雲本地開發環境中，影響應用程序的進程和線程不少、變化很快，傳統基於加載簽名文件和反惡意軟件掃描的方式在執行時間上是不容許的。監控運行中的工做負載可能須要數十個實例才能建立可靠的模型。從實例化工做之時起，工做負載就必須「誕生即安全」。這對CI / CD管道中的開發掃描、建模以及仿真都提出了重要要求。
• 向基礎架構不變的思惟轉變。這是一種操做模型，其中不容許在生產系統上進行任何配置更改、補丁程序或軟件更新。修補程序和更新將應用在基礎（「黃金」）映像和圖層，而後從這些映像從新構建生產工做負載並進行替換，而不是提供服務。有了不變的基礎架構，CWPP保護策略將在運行時轉移到對應用程序控制和容器鎖定（默認拒絕/零信任）的關注上，更加着重於在部署以前掃描漏洞。在將工做負載部署到生產中以前，這些策略還將轉移到在開發中構建應用程序控制/白名單模型。此概念的一個有趣擴展是內存不變性，它旨在確保在工做負載的生存期內，只有已知的合格代碼才能在內存中駐留。
• 在容器環境中，無代理思想的轉變。沒法保證企業可以在基於容器的部署中將代理放置在Linux主機操做系統中。鎖定最小的內核和某些託管容器服務的狀況愈來愈多。答案是提供一種體系結構選項，以將CWPP產品做爲特權容器運行，一些CWPP初創公司僅關注容器的保護要求。
• 對Kubernetes的快速適應。在過去的三年中，Kubernetes已經成爲Linux容器編排的標準。一些新興的CWPP廠商只專一於保護Kubernetes環境，支持Amazon Web Services（AWS），Microsoft Azure和Google Cloud Platform（GCP）託管的Kubernetes服務是常見的要求，同時還支持Red Hat OpenShift。
• The shift to CWPP code layering, wrappering or insertion for protection serverless functions. In serverless PaaS environments, agents and privileged containers/sidecars will not work. New approaches are needed, such as layering in security controls,4 injection of security protection and creating a parent/child relationship from a security wrapper to the serverless function. Some CWPP startups focus only on this use case.
• 無運行時保護。對於容器和無服務器架構，若是在開發中掃描工做負載並知足基本需求(如網絡分段)，爲何要在運行時保護中增長對容器/無服務器的負擔?假設進行預掃描，則核心運行時保護需求（例如分段，網絡監控和行爲監控）可能會在工做負載以外交付。隨着採用不變的基礎架構以及無容器/服務器的PaaS生命週期（以分鐘而不是數小時爲單位），這種狀況愈來愈多。
• CWPP / CSPM的融合以及雲原生應用程序保護平臺（CNAPP）的出現。隨着對CWPP的安全掃描轉換到了開發階段，掃描雲配置是否存在過多風險也是有利的。咱們將此風險配置掃描稱爲雲安全狀態管理。CSPM是CWPP提供者的天然銜接。

CWPP和CSPM的銜接

CWPP和CSPM能力的結合具備協同效應，許多廠商都在追求這一戰略。這一合併將建立一個新的類別CWPP和CSPM能力的結合具備協同效應，許多廠商都在追求這一戰略。這一合併將建立一個新的CNAPPs類別(參見「頂級安全和風險管理趨勢」)，用於掃描開發中的工做負載和配置，並在運行時保護工做負載和配置。，用於掃描開發中的工做負載和配置，並在運行時保護工做負載和配置。

市場分析

圖3顯示了現代混合多雲數據中心架構中工做負載保護策略的主要元素。

如上圖多層次三角形所示，服務器工做負載的安全性源於陰影部分中的基礎配置與最佳實踐，任何工做負載保護策略都必須今後處開始，並確保知足如下條件：

• 任何人（攻擊者或管理員）都沒法從物理上或邏輯上訪問工做負載。
• 工做負載映像應只具有功能所需代碼，服務器鏡像應瀏覽器和電子郵件的使用。
• 對服務器工做負載的更改必須通過嚴格的管理流程和審覈機制，而且經過強制身份認證和訪問權限管理（一般使用PAM特權訪問管理產品）。
• 操做系統和應用程序日誌做爲整個企業安全信息和事件管理(SIEM)工做的一部分進行收集和監視。
• 工做負載須要最小化、補丁化和加固，減小攻擊面暴露。
• 根據基於身份的策略對工做負載進行細分-在大多數狀況下，使用內置的細分功能，例如對部署了雲工做負載的基礎可編程雲基礎架構進行標記。
  在以上幾點的基礎上，建議採用服務器工做負載保護金字塔的預防、檢測和響應三個組合，它們提供了一個全面的工做負載保護策略。可是，根據工做負載的使用狀況、工做負載的暴露程度以及企業的風險承受能力，並非每一個服務器工做負載都嚴格須要每一層的功能。

CWPP金字塔的八大組件

CWPP金字塔共有八大組件，最底下的兩層涵蓋了加固、安全配置、漏洞管理和網絡劃分，囊括了操做安全和CWPP，是相當重要的兩層。

CWPP第一層組件：Hardening, Configuration and Vulnerability Management

刪除沒必要要的組件，如Telnet、FTP等其餘服務，(若是沒法刪除，則在管理策略上禁用)。鏡像應該使用行業標準指南(如Internet Security Center CIS指南)做爲進行加固，這些特定的步驟能夠由IT操做來維護和執行(所以在基礎中包含這個層)。確保系統根據組織的指導方針進行加固和配置，並根據組織的政策和行業最佳實踐及時更新系統。
在許多狀況下，可使用外部掃描工具或服務（例如Cavirin，Qualys，Rapid7或Tenable）來實現此功能。可是，在本市場指南中的某些CWPP解決方案還可使用其代理從「由內而外」評估工做負載系統的配置、合規性和漏洞狀態，在這種狀況下，CWPP應根據工做負載的內容爲增強工做負載提供具體的策略建議。

CWPP第二層組件：Network Firewalling, Visibility and Microsegmentation

工做負載安全性的一項關鍵要求是對工做負載與其餘資源進行通訊的能力進行防火牆/分段。可是，某些企業不須要CWPP產品便可執行此功能。相反，他們使用雲基礎結構的內置分段。所以，咱們將該層放置在圖3中金字塔的陰影矩形部分中。有的CWPP產品提供了本身的防火牆功能，而其餘產品則管理Windows和Linux的內置防火牆。一些CWPP還管理Amazon EC2安全組和Microsoft Azure網絡安全組的內置分段。一些供應商只專一於微細分。在全部狀況下，該解決方案都應知足對基於身份的「微細分」（更細化，軟件定義的細分，也稱爲零信任網絡細分的日益增加的需求）數據中心的東西向流量。
此外，一些解決方案還提供了對通訊流的可見性和監視，就像某些雲服務提供商（例如Azure網絡安全組流日誌，AWS VPC流日誌和GCP防火牆規則日誌）同樣。爲了從原始流日誌數據中弄清楚，可視化工具使操做和安全管理員能夠了解流模式，設置分段策略並監視誤差。最後，幾家供應商提供了工做負載之間網絡流量的可選加密（一般是點對點IPsec傳輸模式安全關聯），以保護移動中的數據，並在工做負載之間提供加密網絡隔離。
CWPP第三層組件：System Integrity Assurance 系統一致性保證
這裏的功能在運行時跨越兩個領域：

• Preboot
  首先，在工做負載實例化期間，在加載其餘固件和微代碼、hypervisor、vm和容器系統映像以前，測量基本輸入/輸出系統(BIOS)、統一可擴展固件接口(UEFI)、其餘固件和微代碼的能力，這一般是經過基於物理系統硬件的信任度量來實現的。在公共雲中，這將僅限於在安裝和驗證地理位置以前測量系統映像和容器的完整性。

• Postboot
  實時監視工做負載的完整性，包括工做負載啓動後的關鍵系統文件和配置。與獨立防病毒軟件同樣，單獨使用文件完整性監視(FIM)的價值很是小。然而，某些狀況下可能須要它，由於FIM是多個法規的要求，好比支付卡行業數據安全標準(PCI DSS)。更高級的解決方案還會監視Windows註冊表、啓動文件夾、驅動程序、引導加載程序和其餘關鍵系統區域的完整性(請參閱「文件完整性監視的最佳實踐」)。比FIM更有用且愈來愈重要的是監視工做負載配置偏離所需的操做狀態。對於不可變的基礎設施尤爲如此。CWPP提供的一些產品能夠監視工做負載，以發現意外的狀態變化，並將這些變化重置爲所需的設置。
  CWPP第四層組件：Application Control/Whitelisting 應用控制與白名單
  本地VM和公共雲IaaS中的大多數工做負載都運行單個應用程序。對於託管基於微服務的應用程序和無服務器功能的容器，幾乎老是如此。使用應用程序控制來控制服務器上運行的可執行文件提供了很是強大的安全保護策略。這使企業能夠對可執行文件採用默認的拒絕或者零信任安全的狀態。默認狀況下，全部表現爲要執行文件的惡意軟件都會被阻止。許多CWPP解決方案提供內置的應用程序控制功能，或者提供專門針對此場景的解決方案。
  或者，也可使用的操做系統內置的應用程序控制功能，好比軟件限制策略，包括AppLocker和Windows Defender Device Guard、加強性的Linux (SELinux)或使用Linux的AppArmor，或使用VMware的AppDefense。一些廠商可使用更細粒度的策略對運行時行爲作進一步制約。

CWPP第五層組件：Exploit Prevention/Memory Protection 利用阻止與內存保護

應用程序控制解決方案是不可靠的，必須結合漏洞利用預防和內存保護功能（例如，地址空間佈局隨機化（ASLR）和seccomp）結合使用，或與CWPP廠商提供的補充功能結合使用。
咱們認爲這是一項必不可少的功能，能夠防止出現白名單應用程序中的漏洞受到攻擊且操做系統受企業控制的狀況（對於無服務器，須要保護雲服務提供商的底層操做系統）。注入的代碼徹底從內存運行，而且不會表現爲單獨執行和可控制的過程（稱爲「無文件惡意軟件」）。此外，漏洞利用防護和內存保護解決方案能夠提供普遍的防護攻擊的保護，而無需傳統的基於簽名的防病毒解決方案的開銷。當補丁不可用時，它們也能夠用做緩解控件。一些CWPP廠商使用了另外一種更強大的內存保護方法，稱爲「移動目標防護」-隨機分配OS內核，庫和應用程序，以便每一個系統在其內存佈局上有所不一樣，以防止基於內存的攻擊。

CWPP第六層組件：Server Workload EDR, Behavioral Monitoring and Threat Detection/Response

這一層功能也是強制性的。可是，能夠經過從工做負載外部進行監視來實現此功能。服務器EDR超越了先前討論的系統完整性監視（EDR的基本形式），也超越了基於主機的傳統入侵檢測系統（HIDS）。服務器EDR監視檢查行爲，例如網絡通訊，啓動的進程，打開的文件以及用於指示惡意活動（包括容器內）的行爲模式的日誌條目。另外一種技術是創建白名單應用程序的預期行爲模式，並尋找行爲誤差。
一些最終用戶EDR點解決方案供應商專門針對服務器工做負載保護用例進行行爲監視(請參閱「端點檢測和響應解決方案的市場指南」)。這些功能側重於檢測和響應，而不是預防攻擊。一些組織將經過基於網絡和基於雲的監視來實現這一點，而不是使用基於主機的代理(例如，使用主要雲提供商的內置網絡流日誌數據，避免了基於工做負載的持續監視的資源開銷)。所以，咱們並無把這做爲CWPP的核心要求。服務器EDR的另外一個常見用例是，在發生突發事件時，經過名稱或散列快速掃描全部系統，尋找特定文件的存在。這相似於基於簽名的防病毒掃描，可是若是未使用防病毒引擎，則可用於檢測/響應方案。

CWPP第七層組件：Host-Based IPS With Vulnerability Shielding

在此，CWPP產品會深度檢查傳入的網絡流量以發現針對已知漏洞的攻擊並加以阻止。若是基於網絡的入侵防護系統（IPS）保護工做負載，則該層多是冗餘的。可是，基於網絡的IPS可能沒法抵禦VM間或容器間的攻擊。另外，因爲流量是在主機工做負載處終止的，所以基於主機的入侵防護系統（HIPS）檢查多是更好的體系結構選擇，由於它是在主機而不是網絡中執行的。 HIPS成爲深度控制方面的寶貴防護手段，可防止對零日漏洞的攻擊，直到能夠應用補丁或從補丁映像重建工做負載的代碼爲止。一些組織使用HIPS來減小服務器修補的頻率。對於保護難以修補的服務器工做負載或供應商再也不受修補程序支持的服務器工做負載（例如Windows Server 2008，該服務器工做負載在2019年末再也不受支持），它們可能也很關鍵。

CWPP第八層組件：Anti-malware Scanning

基於簽名的防病毒和防惡意軟件掃描對管理良好的服務器工做負載幾乎沒有價值。即便服務器工做負載採用了具有內存保護和漏洞利用防護功能的應用程序控制白名單模型，在某些狀況下，基於簽名的文件掃描頗有用。例如，若是服務器工做負載充當通用文件存儲庫，例如文件共享，網絡文件系統（NFS）服務器，FTP服務器或Microsoft SharePoint 服務器等，在這種狀況下，應掃描文件存儲庫。但這能夠在CWPP產品以外執行（例如，一些雲訪問安全代理 CASB 廠商提供此功能）。
存儲服務(如公共雲IaaS中的對象存儲)也應該進行掃描。理想狀況下，這些存儲服務將取代傳統的網絡文件共享並移出工做負載。另外一個須要防病毒的例外狀況是，法規規定強制防病毒軟件的使用。可使用最小的開源軟件(OSS)引擎(如ClamAV)進行基本文件系統掃描來知足合規性一種可能的策略；或者，使用您現有的端點防病毒解決方案並對其進行配置，以最小化對服務器性能的影響，例如，能夠經過禁用實時掃描、下降計劃掃描的頻率和將掃描範圍縮小到容許更改的文件系統區域來實現這一點。

表明廠商

市場介紹

本《市場指南》中列出的表明性供應商（請參閱註釋1）在本出版物發行時提供了專門針對在內部和公共雲IaaS中服務器工做負載的工做負載保護而設計的運輸產品。爲了得到對OS自己（若是適用）的詳細可見性，使用了代理。對於容器環境，可使用主機OS代理或特權容器。對於無服務器的工做負載，可使用分層，包裝或注入。
CWPP產品不能只是將在服務器上運行的面向桌面的產品。必須對產品進行設計和優化，以支持企業混合多雲架構中本研究中描述的服務器工做負載保護用例。做爲託管服務提供的CWPP不在本研究範圍以內。必須將基於API的集成到他們正在保護的雲架構中。客戶端要求的最多見的API集成是VMware，AWS，Azure，OpenStack，Red Hat OpenShift和Kubernetes。
提供以工做負載爲中心的防禦產品的廠商不少。一些廠商專一於在多個操做系統之間提供儘量多的防禦功能。其餘的則專一於微分段、內存保護、行爲監視等特定功能，或者僅關注容器或無服務器保護。
爲了幫助潛在客戶肯定哪一種CWPP產品最能解決其面臨的問題，咱們將供應商分爲以下八類。

Table 1: Broad, Multi-OS Capabilities

Source: Gartner (April 2020)

Table 2: Vulnerability Scanning, Configuration and Compliance Capabilities

Table 3: Identity-Based Segmentation, Visibility and Control Capabilities

Table 4: Application Control/Desired State Enforcement Capabilities

Memory and Process Integrity/Protection Capabilities

Table 5: Server EDR, Workload Behavioral Monitoring and Threat Detection/Response Capabilities

Table 6: Container and Kubernetes Protection Capabilities

Table 7: Serverless Protection Capabilities

市場建議

隨着企業需求的不斷髮展，對CWPP產品的需求也在不斷增加。在評估CWPP產品時，咱們推薦如下評估標準:

• 按照對企業重要性程度覆蓋金字塔圖表中的功能。
• 支持Windows，Linux，Linux容器以及對Kubernetes的顯式支持。若是使用AWS，則應提供對Amazon Linux的明確支持。
• License 能夠跨本地與雲端；
• 對於license的選擇，能夠繼續採用傳統的基於主機、按年的方式，也能夠增長一個可選項：按照鏡像使用大小；
• 爲了雲端部署更便捷，能夠選擇控制檯服務方式；
• 雲服務提供商的商店中能夠集成該軟件，以便於客戶購買和使用；
• 可選的CSPM能力；
• 可選的反病毒掃描功能，包括可選的雲對象存儲掃描功能；

建議按照以下最佳實踐來評估CWPP產品：

• 定製雲工做負載保護策略，以知足特定的需求；
• 不要指望終端防禦EDR產品能實現保護工做負載的功能；
• CWPP廠商應該繼續支持對windows server 2008的防禦，以及在未打補丁的狀況下提供相應的緩解措施；
• 同一化管理：大多數企業數據中心的將來都是混合多雲架構，CWPP產品不只須要來保護物理機、VMs、容器以及無服務器工做負載，這些管理功能應所有集中在一個管理平臺，並經過單個API集進行統一管理；
• 開放API：要求CWPP廠商開放API，便於雲環境中功能的自動化；
• 在評估CWPP產品時，將容器保護功能做爲一項強制功能，若是您正在使用Kubernetes並考慮使用一個受管理的Kubernetes服務，那麼也必須明確指出支持這個環境；
• 要求CWPP廠商提供關於無服務器功能保護全景圖和架構，預計這將在一年內成爲一項強制性要求；
• 支持專門從事容器編排監控和無服務器功能的CWPP廠商；
• 若是您的舊CWPP供應商尚不支持容器或無服務器功能，或者這些功能尚不成熟，則能夠購買CWPP端點解決方案（可能須要簽約一到兩年的合合同）。或者，從新選擇一個支持這些功能的CWPP供應商；
• 將工做負載測試(特別是容器和無服務器的測試)擴展到CI/CD流程中。專一於運行時保護的CWPP產品不知足應用程序開發方式和承載應用程序工做負載的變化；
• 不管您的CWPP供應商是否提供CSPM功能，將CSPM做爲優先項目；
• 爲將來可能不須要CWPP運行時Agent作好準備，直接容器和無服務器功能的漏洞掃描和配置預部署。然而，當部署在不可變的基礎設施中，並從外部監視異常行爲時，它們可能不須要任何來自工做負載自己的補充運行時保護。