云原生技术带来巨大价值的同时，也带来了诸多基于云原生视角的新型安全挑战。为了让广大用户更加详细地了解云原生安全，默安科技推出“云原生安全之变”系列文章，为各位逐一介绍云原生技术各阶段所面临的风险挑战与解决方案。本篇文章主要对云原生工作负载安全进行阐述。

一、CNAPP与CWPP

自从Gartner在2021年8月发布《Innovation Insight for Cloud-Native Application Protection Platforms》报告以来，CNAPP以不可阻挡之势，在国外安全市场中占据重要位置。

该报告明确了CNAPP的定义，以及所解决问题，此后Paloalto、Aquasec等安全厂家迅速跟进迭代相关产品，相继推出自家的CNAPP产品，PA为了形成完善的CNAPP体系，甚至连续出手收购创业公司，合入Prisma产品体系，组成Prisma Cloud 云原生安全产品线，可见CNAPP在目前全球安全市场中的火热程度。

报告中强调：“云原生应用程序的最佳安全体系、需要一种集成性的平台，这种平台从开发阶段开始，延伸到运行时保护。企业管理者应该评估新兴的云原生应用保护平台，这些平台为云原生应用的安全提供了一个全生命周期的防护。”

图源自：Gartner

基于此，CNAPP的基础能力应该包括：IAC扫描、容器扫描、CWPP、CIEM、CSPM。CNAPP平台的重点在于对云原生应用，跨越开发环境到运行时环境，提供全生命周期的安全防护，因此，CWPP（云工作负载安全）作为运行时环境中的主要安全能力，是CNAPP中非常重要的一环。

二、云原生工作负载安全的范围

参考Gartner CWPP市场指南中对CWPP的定义，以及Paloalto、Aquasec等国外云原生安全头部厂商的产品能力，云原生工作负载安全的范围相对明确：工作负载安全必须提供跨越公有云与私有云中的VM、容器、ServerLess全栈的安全保护。

有两个容易忽视的点需要注意：

第一，尽管物理服务器的安全并不在云原生工作负载安全的范围内，但在少数情况下，K8S和Docker也会被装在物理服务器上提供服务，如此一来，物理服务器的安全是否没有保障？其实未必。现在CWPP类产品，实际情况中不只安装在VM上，也装在了大量的物理服务器上，因此如果物理服务器被作为基础计算资源，也可以当做VM处理，或纳入到云原生基础设施安全的范畴。

第二，CWPP正在加速与CSPM融合，包括现在所流行的无代理扫描，也是这种碰撞的结果之一，因此工作负载安全的定义，未来很可能同时包含IAAS与PAAS层，并不是持续不变的。

图源自：Gartner

除了以上提到的工作负载安全定义外，IAC（基础设施即代码）扫描，也有一部分属于工作负载的范畴。因为IAC是通过类似编码的形式来自动化、批量生成云上的计算、存储、网络等资源，同时为这些资源赋予相应的属性，一个错误的IAC可能会生成数千个存在安全风险的云主机，即数千个有安全风险的基础设施和工作负载。

因此，默安科技云原生安全团队认为，IAC安全与工作负载安全有一定的相关性，应在工作负载生成之前，编码阶段就进行安全检查。所以在默安科技尚付CNAPP云原生保护平台（以下简称“尚付CNAPP”）中，IAC扫描功能被视为重点。

三、IAC安全介绍

上期“云原生基础设施安全”一文对基础设施即代码(IaC) 进行了详细分析，IaC更多是在定义基础设施及其属性、基础设施之间的关系，有少量属性与工作负载安全相关，基础设施的部分在此不再阐述。IaC生命周期管理从声明性开始，在云提供商时代，IaC 工具还有助于抽象云应用，可以自动创建定义的资源（网络、存储、计算等）并进行应用配置（DNS 配置、防火墙规则等）。

将IaC的工作流程左移到开发阶段是一种更加高效的做法。DevOps 工程师在编写应用代码的同时，将资源的分配代码同时编写，实现更紧密的开发测试运维一体化。但是，错误的IAC代码可能导致凭据泄露、未授权访问等安全问题。

例如，编写AWS Terraform文件的时候，存储桶默认可访问，若block_public_acls和block_public_policy设置为false，则允许任何公共访问，会造成严重的数据泄露事件，这就是IAC安全扫描存在的意义。

在云原生的IT架构下，IAC扫描往往会包含各个公有云的IAC代码扫描、K8S Mainfest、Dockerfile等文件的代码扫描，从文件中发现不安全的配置项，进而提醒用户进行修复，由于IAC文件往往采用声明式方法，编码方式相对固定，比传统的代码扫描更进一步，因此Paloalto等大厂均提供IAC代码一键修复的功能。

四、工作负载安全-云主机安全

对于云主机的工作负载安全，国内外安全厂商均提供了优秀的产品解决方案，下面这张图基本可以囊括其相关功能：

图源自：Gartner

本图中越往下方的能力，越基础和有效，用户越需要优先考虑。

CWPP的能力以运维与安全检查为基础，资产清点、权限管理、日志管理等偏运维侧的能力被认为是最基础的CWPP能力；再往上，CWPP需要具备配置安全的最佳实践以及资产漏洞的发现与管理能力；网络方面推荐采用基于身份认证的隔离策略，以及应提供整个网络关系的可视化；在此基础之上，系统完整性验证、白名单机制、应用控制能力，应是CWPP产品需要提供的；针对工作负载的攻击，CWPP应具备EXP拦截、内存保护的能力，在之前这部分能力被叫做“虚拟补丁”，在用户对某些漏洞修复存在困难时，开启虚拟补丁功能可以有效帮助用户获得时间窗口，推进漏洞彻底修复；针对主机的攻击，CWPP需要与EDR类似的威胁发现、行为监控与相应的能力，更进一步，是网络层面的威胁发现与相应能力，其实HIPS的能力同样可被视为虚拟补丁的一部分，更多的是对漏洞进行自动防护；最后，恶意软件的查杀与处置能力，被认为是CWPP能力中的可选项。

在CWPP的能力象限中，默安科技云原生安全团队发现：国内普遍重视的防病毒能力，反而被认为了可选项。其中原因有以下几点：

1 通常来说云主机的内存和CPU资源都比较少，防病毒的引擎会占用大量资源。

2 云工作负载的生存周期比较短，这个特性对恶意软件的扩散与传播相对不友好。

3 最重要的是，云工作负载环境是相对比较简单的，已经逐渐偏向不可变基础设施了，很少有人工额外进行操作，因此国外针对恶意软件的主流应对策略，逐渐转向白名单策略，确定业务进程、网络、文件相关的资源，其他额外派生的一律认为是异常，这是一种开销更小，控制更严谨的防病毒方案。

4 对已经存在恶意软件的工作负载，更倾向于从行为侧进行检查，归类主机的入侵检测与响应阶段去解决。

最后需要强调：由于云原生的容器方案大家多用Docker，与操作系统共享内核，因此内核漏洞很有可能会造成Docker逃逸，在针对云主机安全上，内核漏洞的检查、修复、虚拟补丁能力，可以放到更高的优先级考虑。

五、工作负载安全-容器安全

容器安全可以说是CNAPP中最重要的部分，可以按以下阶段划分安全活动：

1 开发过程相关活动：镜像扫描、Dockerfile扫描、CI/CD集成。

2 部署相关活动：容器基线扫描、容器准入、镜像签名。

3 运行时相关活动：容器内威胁检测与响应（包含容器逃逸）、容器白名单（进程、网络、文件等）、容器网络威胁检测与响应。

实际上，还有一些与容器安全强相关的部分，比如K8S安全、宿主机内核安全，已在“云原生基础设施安全”一文中讨论过；对于运行时的容器网络安全，默安科技将在本系列继续推出一篇“微服务网络安全”的文章进行讨论，在此不过多介绍。

在此，主要讨论三个能力：

第一是容器的镜像安全部分，整个容器镜像的生态被认为是不够友好的，这把压力转到了使用者侧。比如，在以前不使用容器的时候，软件或操作系统的最新版基本没有漏洞，用户可以相信最新版的安全性，但是容器镜像并非如此，官方镜像仓库中的镜像，依然存在安全漏洞，导致官方镜像被供应链攻击、植入恶意病毒的情况时有发生。

因此容器镜像安全的管控方式，更像开源组件的管控方式，首先是镜像的入口，企业应通过管理和技术手段阻止个人私自在公网上拉取镜像用于开发环境，开发生产环境的镜像统一从企业内部的镜像仓库拉取。其次，针对镜像仓库，应持续的进行镜像扫描，包含软件/操作系统漏洞、恶意文件、敏感信息、配置安全等扫描能力，在开发过程中可以对拉取到的镜像在CI/CD中再进行一次扫描；最后，在部署阶段，要针对镜像进行签名校验，与开发阶段经过安全检查的镜像进行对比，部署完成后根据漏洞情报进行及时的镜像更新。

第二是白名单思想，默安科技云原生安全团队通过对国外容器安全产品能力的分析，发现很多厂商已经取消了传统的一些入侵检测项，比如反弹shell、提权、后门等，转而用容器内进程、文件、网络白名单来取而代之，究其原因，归根于容器的运行、更新形式，都是以不可变基础设施思想为基础的。按照标准的K8S+Docker的环境来作为业务运行环境的时候，如果要进行业务更新或者修改，开发人员不会手动登录到容器内部进行修改，而是重走一遍CI/CD流程，打包出一个新的镜像，进而更新当前生产环境中的镜像。

至于业务连续性问题，K8S有自己的更新机制，这意味着：在没有镜像更新的时候，容器内部的活动因为没有人工主动干预，所以一切都应在预期之内，如果有出现预期之外的活动，就可以直接被认为是异常，这就是白名单思想。虽然国内依然有很多企业使用胖容器的方法进行过渡，但仅仅是过渡而已。在标准的容器环境中再去检测反弹shell、提权、后门等行为意义不大，由于容器存留的时间非常短暂，有经验的攻击者拿到容器权限第一时间定是想逃逸，或接管K8S，而不会费尽心机去进行传统的红队动作。

第三是容器资产的准入控制，多数厂商对容器准入部分的控制项包含三个维度：容器基线、镜像安全、签名校验，参照CIS或某些云厂商给出的容器最佳实践，对容器的基线进行检查，或进行容器的签名校验，或基于镜像的安全扫描结果，设置准入的控制项，进而执行对应的动作，这是工作负载安全准入的通用做法。但在CNAPP的体系中，强调开发与运行时的一体化，开发阶段的安全风险，也应成为准入的控制因素之一，目前还没有在任何其他厂商的产品上看到此类能力。

默安科技尚付CNAPP平台，除了容器基线、镜像安全、签名校验之外，还将开发过程中未修复的安全风险，作为准入的控制项之一，不过这部分更偏向于微服务或应用安全，在此只做简单介绍。微服务在开发测试期间是否存在高危风险漏洞、是否使用了带有漏洞的第三方组件库或是使用了带有错误配置的IaC等等，这些在开发测试期间发现的安全风险都有可能致使微服务上线后产生安全风险，因此在此准入阶段需要再次做好安全卡点，防止微服务带病上线。

六、工作负载安全-ServerLess安全

无服务作为新兴的工作负载，已经成为一种趋势，其使用率逐年增加，不过即使是在国外，ServerLess的使用率目前也远不如容器广泛，在国内更是处于刚刚起步的阶段，在此讨论ServerLess安全显然有一些为时过早，不过，默安科技云原生安全团队仍对此进行了讨论，希望能对之后的ServerLess安全研究有所帮助。

ServerLess安全总体可以总结为下图：

由于篇幅限制，此处仅讨论3个最重要的问题：风险在哪里、ServerLess安全方案如何部署、能够解决哪些问题。

对于ServerLess的安全风险，用户需要着重关注是配置与代码。

早在2017年BlackHat上国外安全研究员就发表了ServerLess安全的议题《Hacking-Severless-Runtimes》，其中提到：无服务现在所利用最多的风险类型是配置泄露和权限控制，导致大量的数据泄露，甚至是攻击者接管函数，与传统的数据泄露有以下三方面的不同：

1 传统应用只是从单一服务器上获取敏感数据，但是在Serverless架构中攻击者可针对各种数据源进行攻击，例如各种云存储或DynamoDB等，因此攻击面更广。

2 Serverless应用由多个函数组成，不能像传统应用程序使用单个配置文件，因此开发人员多使用环境变量替代，虽然使用起来更为简单，但使用环境变量本是一个不安全的行为。

3 开发人员并不具备良好的Serverless的密钥管理经验，易造成敏感数据泄露的风险。

在serverless.yml中就存在环境变量的KMS密钥，可以用于解密上文所提到的环境变量，进而获取更多的敏感数据，直到现在还能搜到很多泄露的serverless.yml。

权限控制问题同理，开发人员应按照代码所调用的无服务API给予最小权限，很多时候为了省事，开发人员直接开放了大量不必要的权限，因而增加了安全风险。例如，函数执行业务逻辑时不可避免会对数据库进行CRUD操作，在此期间，开发人员需要给予函数对数据库的读写权限。在不对数据库进行其它操作时，开发人员应当给予只读权限或关闭其权限，如果此时开发者将权限错误的更改为读写操作，攻击者会利用此漏洞对数据库展开攻击，从而增加了攻击面。

无服务的代码层面的问题，比较类似于传统的代码问题，一样会遭受例如SQL注入、XSS、代码注入、命令执行等攻击，OWAPS曾经也出过无服务安全TOP10漏洞：http://www.owasp.org.cn/OWASP-CHINA/owasp-project/OWASPTop10-release-v1.2.pdf（复制链接到浏览器打开）

代码层面的问题更多需要在开发阶段去解决，形成完整的DevSecOps体系，利用IAST、SAST、SCA、DAST等工具在开发阶段尽量解决高危风险，避免带病上线，此处不过多讨论。

最后，关于ServerLess防护的安全方案，当前大致有两种方向。一种是采用组件，利用代码嵌入的方式，接管请求与响应，进行过滤以及权限限制，例如puresec项目中，其无服务保护功能的调用方式如下，能够对无服务提供：目录读写权限控制、子进程控制、对外连接控制、代码读写权限控制等，达到保护无服务函数的目的。组件嵌入的方式对代码有一定的入侵性，需要研发人员进行代码修改。

另一种方式是通过增加layer的方式，增加一个额外保护层，实现类似WAF的效果，layer层的控制函数有企业自行提供，例如improve就采用了这种方式将自家的waf能力应用到无服务保护上。

七、结语

随着云原生的持续火热，云原生安全也逐步在国内流行起来，现今很多企业都着手开始建设容器安全，业界已经对云原生安全有了基本的共识，但是各位也应认识到：容器安全是CNAPP体系中的重要一环但不是全部，工作负载安全的范围不只是容器，云原生体系依然面临着众多风险。

默安科技尚付 CNAPP，从诞生之初，所努力的方向就是CNAPP平台。早在公司成立之初，默安科技就开始了DevSecOps、CWPP等能力的布局，经过多年沉淀，默安科技成为DevSecOps领域的国内优秀产品和方案提供商，加上公司对容器安全、CSPM等方面的产品创新，在2022年正式推出了“尚付 CNAPP云原生应用保护平台”，帮助用户打造完整、体系化的云原生安全解决方案。作为该领域国内领先的第三方供应商，默安科技希望对未来的一些预见，能够帮助广大政企用户建设更安全、更稳定的云原生体系。

参考资料
• https://marketplace.visualstudio.com/items?itemName=aquasec.aquasecserverles
• https://www.paloaltonetworks.com/prisma/cloud/cloud-workload-protection-platform
• https://www.paloaltonetworks.com/prisma/cloud/serverless-security
• https://blog.aquasec.com/what-is-cnapp
• https://blog.aquasec.com/gartner-cloud-workload-protection-platforms
• https://www.aquasec.com/products/container-security/
• https://info.aquasec.com/secure-aws-lambda-workloads
• https://www.aquasec.com/products/serverless-container-functions/
• https://www.secrss.com/articles/26798