【譯】Gartner CWPP市場指南

本人是一枚初學者新手，如有不對請留言指出，感謝不吝賜教，

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

概述

問題現狀

• 企業使用終端保護平臺（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做好準備，直接容器和無服務器功能的漏洞掃描和配置預部署，然而，當部署在不可變的基礎設施中，并從外部監視例外行為時，它們可能不需要任何來自作業負載本身的補充運行時保護，

標籤：其他

上一篇：buuctf-SimpleRev

下一篇：gps網路時間服務器的詳細解釋