一、前言

　　云计算、大数据和人工智能的来临，上云已经成为组织数字化转型的必由之路。云原生作为云计算的下一个阶段，相关的开发和部署模式已经成为业界趋势，技术、产品、标准和解决方案的生态系统也在同步扩张之中，决策者面临着跟进这些复杂设计的挑战。

　　云原生技术应用产生了新的云安全需求，CISO 要在竞争激烈的云原生市场中确保业务安全。传统的防火墙、反病毒、服务器监控、终端检测响应和SIEM等安全产品，与云原生的适配性较好，容易部署上云。但工作负载安全、威胁检测、用户行为监控、合规与风险管理等安全产品，无法适应云原生技术的新安全需求，需要进行专门的重新设计。

　　过去的几年，诞生了云工作负载保护平台CWPP（Cloud Workload Protection Platform）、云安全态势管理CSPM（Cloud Security Posture Management）等云安全产品，对云原生安全的保护发挥了重要作用。但是，随着新应用场景的出现、技术的演化和市场的变化趋势，云原生应用保护平台（Cloud-Native Application Protection Platform, CNAPP）的概念诞生，渐有统一CWPP和CSPM之势。本文将对CNAPP的发展演进脉络进行分析。

　　二、传统主机保护平台

　　01 终端保护平台

　　云原生应用程序保护平台最初起源于终端保护平台（Endpoint Protection Platform，EPP）。虽然一些企业现在仍在使用EPP产品作为保护服务器工作负载的安全产品，但是EPP是面向物理终端设备（台式机、笔记本电脑和平板电脑等）的解决方案，不适合企业混合云场景下的工作负载保护的要求。

　　在这种场景下，基础架构是由本地服务器、虚拟服务器以及公有云环境共同组成，主要的保护目标是服务器的工作负载。EPP产品的继续使用会使企业的数据和应用程序处在巨大的安全风险之中。传统的以数据中心、网络和终端为主要保护对象的安全理念和产品，需要向混合云场景进行演进。

　　02 混合云场景下的云工作负载保护平台

　　混合云的部署架构逐渐被市场接受。为了满足混合云场景下的工作负载保护，云工作负载保护平台（Cloud Workload Protection Platform, CWPP）随之产生。CWPP最初（2016年）基于主机安全的解决方案进行定义，区别于EPP的PC维度，CWPP主要解决的问题在于数据中心维度。CWPP强调了混合数据中心架构需要统一的管理、Linux系统的重点支持、杀毒软件的无效、定价灵活性以及跟云平台的对接和API与DevSecOps的结合等等。

　　从技术角度来看，最核心的是跟云平台原生的对接，利用AWS或者Azure提供的接口来进行相关安全措施的处理。比如说通过VPC接口可以做到相关业务的微隔离，也可以通过网络流量日志来进行流量的安全分析。

　　2017年，CWPP增加了外部场景的云工作负载安全服务（WAF、Firewall和IPS等），进一步增强云工作负载的保护。并且，开始采用控制面的安全措施（IAM配置、网络配置以及管理员访问等）。

　　此外，容器的出现，使得用户无法对线上系统进行处理，安全措施需要前移到开发环节，并且运行时的应用控制和容器的锁定需要作为新的防御手段，云工作负载保护架构随之发生了变化。新架构要求对SDL流程的支持，与自动化CI/CD工具的结合，要求API可以灵活调用，将安全检查前移。

　　03 混合多云场景下的云工作负载保护平台

　　2018年，大部分组织开始在使用至少两个厂商的云计算服务。混合多云的部署架构成为市场的主流。为了满足混合多云场景下云工作负载保护，CWPP需要提供统一的安全策略管理，以减少企业的知识鸿沟。

　　同时，CWPP的管理需要自动化，从而更好地与DevSecOps相结合。例如，在自动化生成工作负载时，自动化安装和配置相关的软件或安全策略。

　　此外，CWPP开始注重机器学习技术对产品能力金字塔各个层面的加强作用。例如，对于微隔离层面，机器学习可以先学习和观察正常的情况，然后建立白名单，随着时间的推移不断更新和修正策略以达到不用人工介入就可设置安全策略的状态。

　　然而，CWPP并不能解决Serverless计算方式所带来的安全问题，势必需要对工作负载的定义进行重新和全面审视。因而，Gartner在2019年对工作负载的外延和内涵进行细粒度解释，根据抽象度的不同分为物理机、虚拟机、容器和Serverless。

　　这几种工作负载从虚拟化水平到单位的计量再到生命周期都有很大的区别。能力金字塔因而发生了重大变化。从原来的11个能力删减到8个能力，并且将最底层的“运维习惯”与“加固、配置与漏洞管理”进行了整合。删掉了“欺骗防御”能力，因为欺骗/蜜罐系统是单独产品提供。同时数据的静态加密大部分情况下都有云厂商提供，比如AWS的EBS加密和Azure的磁盘加密，因此“静态加密IaaS数据”这个能力也从能力金字塔中删掉了。但是加强了对威胁检测和响应的要求，相当于要学习EDR的能力。

　　图1：工作负载抽象

　　2020年，CWPP能力金字塔进一步精简，文件加密和防病毒从其中移除。目前的能力，从最核心的开始，按照重要性逐渐递减的排序，包括八层：加固、配置和漏洞管理，基于身份的隔离和网络可视化，系统完整性保证，应用控制/白名单，预防漏洞利用和内存管理，服务器工作负载行为监测、威胁检测和响应，主机防入侵和漏洞屏蔽，扫描恶意软件。

　　图2：基于风险的工作负载保护控制层次结构

　　三、云原生应用保护平台

　　01 云原生应用保护平台的产生背景

　　首先，从安全市场角度来看，云原生技术持续深入发展和广泛普及势必带来新的网络安全发展机遇，产生庞大的网络安全需求，并推动云安全业务向纵深发展。

　　其次，从安全生态角度来看，安全产品的融合发展成为必然选择。CWPP在数据面对云工作负载进行保护，CSPM在控制面对云工作负载进行保护。

　　值得注意的是，当前大多数的云安全事件都是配置错误和管控失当引起的，凸显正确配置和合规的重要性，控制面的安全变得越加重要。数据面和控制面的云安全产品通过相互融合组成统一的解决方案，能够更好地保护多云和多租户，云原生应用保护平台（CNAPP）由此产生。

　　最后，从云安全实际需求角度来看，混合多云仍将是组织和机构未来一段时期的基础架构。

　　但是，工作负载的粒度、生命周期以及创建方式发生了显著变化，云安全保护需求势必也会发生变化。

　　首先，组织正在越来越多地采用容器和Serverless等技术进行云原生应用开发，工作负载的粒度越来越来越细，云原生安全保护需要适应工作负载粒度的变化。

　　其次，容器和Serverless等形式的云原生开发的流行，工作负载的生命周期越来越短，部署在这些工作负载上的恶意软件也呈现出快速变化的特点。传统的基于签名文件加载或反恶意软件扫描的方式无法及时响应，基于行为建模的方案也因无法收集足够案例变得失效。云原生安全保护需要适应工作负载的生命周期越来越短的变化。

　　最后，工作负载越来越通过镜像构建和替换，正在向不变的基础设施转变。云原生安全保护同样需要适应这种变化。

　　02 云原生应用程序保护平台的主要特点

　　总的来说，CNAPP将会吸收CWPP和CSPM的能力，不仅需要把不同的安全解决方案集成在一起，跨越不同技术边界实施一致的安全策略，提供统一的云原生保护，还需要采用面向安全的架构设计（例如，零信任），识别动态工作负载中的属性和元数据，自动化地保护开发、发布、部署和运营等整个生命周期。

　　首先，CNAPP无疑仍将聚焦动态混合、异构多云架构场景下的工作负载保护，重点是跨不同技术边界实施一致的安全策略。

　　其次，CNAPP需要具备对所有粒度的工作负载进行保护的能力。云原生应用需要虚拟机、容器和无服务器PaaS组合起来提供服务，单一的工作负载保护无法保证应用的整体安全。并且，随着工作负载的粒度和动态变化，CNAPP策略和产品也许必须动态适应、弹性伸缩。

　　第三，CNAPP需要对开发、发布、部署和运营等整个生命周期进行保护。现在的CWPP主要关注工作负载运营阶段的保护，缺乏对其他阶段的保护。CNAPP需要注重基于基础设施的不变性进行保护。在开发阶段，使用安全测试来识别合规和配置的相关问题，为持续改进提供快速、可操作的反馈流程。在发布阶段，持续地对工作负载镜像（例如容器镜像）进行自动扫描和更新，避免遭受漏洞、恶意软件、危险代码以及其它不当行为的侵害，确保所依赖的开源软件和第三方应用等软件供应链的安全。在部署时，对工作负载镜像的属性进行的验证（例如，签名、安全策略等）。

　　第四，CNAPP需要适应云原生开发的快速迭代，基于CI/CD 实现自动化。云原生追求的本质目标是效率，CI/CD作为效率提升的重要手段，是云原生的关键特性。云原生时代，不满足CI/CD自动化的安全产品，将摧毁云原生的价值，也就不能算作云原生安全保护。

　　第五，CNAPP需要重点加强配置保护和合规性检查能力。云计算基础设施错误配置带来的安全风险要比攻破工作负载带来的安全风险更大。CSPM能够对云计算技术设施的配置和合规性进行持续评估和改进，CNAPP需要充分吸收CSPM的这种能力。

　　第六，CNAPP需具备对云原生应用程序进行威胁检测和响应的能力。CWPP主要依赖于预防性控制，而CNAPP需要采用CARTA战略框架和自适应安全架构，对云原生应用程序以及相关工作负载的行为进行监控。