【译】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作好准备，直接容器和无服务器功能的漏洞扫描和配置预部署。然而，当部署在不可变的基础设施中，并从外部监视异常行为时，它们可能不须要任何来自工做负载自己的补充运行时保护。