2022年云计算行业研究报告 云原生安全威胁分析与检测技术

一、前言

随着云计算技术的蓬勃发展，传统上云实践中的应用升级缓慢、架构臃肿、无法快速迭代等“痛点”日益明显。能够 有效解决这些“痛点”的云原生技术正蓬勃发展，成为赋能业务创新的重要推动力，并已经应用到企业核心业务。然 而，云原生技术在创造效益的同时，却也面临着严峻的安全问题。 本报告基于安全狗“云原生安全团队”近几年的研究成果，以及近年来对云原生安全领域的观察编制而成。我们期望 通过我们对以“云原生威胁检测”为主要视角的总结分析，能够为各个行业 / 企业 / 单位对云原生安全技术开展后续 的云原生安全建设提供进一步的参考建议。 本报告的主要内容如下：

第一部分，从容器化基础设施、容器编排平台、云原生应用以及无服务等方面分析云原生安全威胁； 第二部分，从云原生安全事件风险、云原生安全漏洞风险等方面介绍近年来一些重要的云原生安全威胁； 第三部分，从容器镜像、容器运行时、容器网络、云原生可观测性、宿主机威胁检测以及容器 ATT&CK 矩阵等角度 介绍云原生威胁检测技术； 第四部分，介绍基于我司实践经验提出的五层云原生漏洞风险检测模型“CCICA”； 第五部分，介绍基于我司实践经验提出的一种基于 ATT&CK 容器矩阵的可应用于提取检测规则，提升产品检测能力 的模型方法论“AKDA”； 第六部分，介绍我司基于 CCICA、AKDA 的理论基础的云原生威胁检测实战场景、案例； 第七部分，从云原生未来发展趋势、云原生安全未来发展趋势以及云原生攻防对抗未来发展趋势三个角度进行云原生 安全实践与技术展望。

二、云原生安全威胁分析

云原生技术逐渐成为云计算市场发展的新趋势之一。随着越来越多的云原生应用落地和使用，其相关的安全风险与威 胁也不断涌现。云原生安全事件频频发生也直接影响了整个云原生系统的安全性。以下章节将围绕云原生环境中存在 的威胁展开分析。

（一）容器化基础设施的威胁风险

在实现云原生的主要技术中，容器作为支撑应用运行的重要载体为应用的运行提供了隔离和封装，因此成为云原生应 用的基础设施底座。云原生架构的安全风险包含容器化基础设施自身的安全风险，容器化部署则成为云原生计算环境 风险的输入源。

1．容器全生命周期的威胁风

容器的秒级启动或消失的特性以及持续频繁的动态变化，极大程度地缩短了生命周期，但也增加了安全保护的难度和 挑战。容器的安全问题，在容器全生命周期（创建、分发、运行、停止）的各个阶段都存在相应的风险和威胁隐患。

（1）容器镜像构建阶段存在的风险

随着容器技术的普及，容器镜像也成为了软件供应链中重要的一环。因此，当业务依赖的基础镜像存在安全漏洞或者 包含恶意代码时，其潜在危害比黑客从外部发起攻击要严重得多。

①镜像CVE漏洞利用

“镜像漏洞利用”指的是镜像本身存在漏洞时，依据镜像创建并运行的容器通常也会存在相同漏洞，镜像中存在的漏 洞会被攻击者用以攻击容器的情况。这种行为往往会对容器造成严重影响。备受开发者青睐的 Alpine 镜像曾曝出过 一个漏洞，编号为 CVE-2019-5021。在 3.3 到 3.9 版本的 Alpine 镜像中，root 用户密码被设置为空，攻击者在攻入容 器后获得容器内部 root 权限的机会增大。

②镜像投毒

镜像投毒是一个宽泛的话题。指的是攻击者通过某些方式，如上传镜像到公开仓库、入侵系统后上传镜像到受害者本 地仓库以及修改镜像名称假冒正常镜像等，欺骗、诱导受害者使用攻击者指定的恶意镜像创建并运行容器，从而实现 入侵或利用受害者的主机进行恶意活动的行为。 根据目的不同，常见的镜像投毒有三种类型：投放恶意挖矿镜像、投放恶意后门镜像和投放恶意 exploit 镜像。 图 2-1 容器全生命周期的威胁风险 投递恶意挖矿镜像。这种投毒行为主要是通过欺骗受害者在机器上部署容器的方式获得经济收益。2018 年 6 月，一 份研究报告指出，一个名为 docker123321 的账号向 Docker Hub 上陆续上传了 17 个包含挖矿代码的恶意镜像。截 至 Docker Hub 官方移除这些镜像时，它们已经累计被下载超过 500 万次。据统计，黑客借助这一行为获得了市值约 9 万美元的门罗币。

投放恶意后门镜像。这种投毒行为的主要目的是控制容器。通常，受害者在机器上部署容器后，攻击者会收到容器反 弹过来的 Shell。在 2017 年 9 月，有用户在 Docker Hub 的反馈页面中反馈前述 docker123321 账号上传的 Tomcat 镜像包含了后门程序。结合该账号上传的其他恶意镜像的挖矿行为可推测出攻击者在连接上述后门后会部署挖矿程序 以此获得经济收益的可能性。 投放恶意 exploit 镜像。这种投毒行为是为了在受害者部署容器后尝试寻找宿主机上的各种漏洞来实现容器逃逸，以 实现对受害者机器更强控制。从攻防对抗的角度来看，恶意 exploit 镜像只不过是一种攻击载荷投递方式，其特点在 于具有隐蔽性和可能产生巨大的影响范围。试想，如果 Docker Hub 上某一热门镜像包含了某个 1day 甚至 0day 漏 洞的利用程序，理论上，攻击者将一下子获取上百万台计算机的控制权限。

投放恶意后门镜像。这种投毒行为的主要目的是控制容器。通常，受害者在机器上部署容器后，攻击者会收到容器反 弹过来的 Shell。在 2017 年 9 月，有用户在 Docker Hub 的反馈页面中反馈前述 docker123321 账号上传的 Tomcat 镜像包含了后门程序。结合该账号上传的其他恶意镜像的挖矿行为可推测出攻击者在连接上述后门后会部署挖矿程序 以此获得经济收益的可能性。 投放恶意 exploit 镜像。这种投毒行为是为了在受害者部署容器后尝试寻找宿主机上的各种漏洞来实现容器逃逸，以 实现对受害者机器更强控制。从攻防对抗的角度来看，恶意 exploit 镜像只不过是一种攻击载荷投递方式，其特点在 于具有隐蔽性和可能产生巨大的影响范围。试想，如果 Docker Hub 上某一热门镜像包含了某个 1day 甚至 0day 漏 洞的利用程序，理论上，攻击者将一下子获取上百万台计算机的控制权限。

（2）容器镜像分发阶段存在的风险

镜像的安全需要重点建设。镜像的安全性会直接影响容器安全，因为容器镜像在存储和使用的过程中，可能会被植入 恶意程序或修改内容以此篡改。一旦使用被恶意篡改的镜像创建容器后，将会影响容器和应用程序的安全。

（3）容器运行时存在的风险

在容器运行时存在的安全问题中，“容器逃逸”是最具代表性的高风险安全问题。攻击者可通过利用漏洞“逃逸”出 自身拥有的权限，实现对宿主机或者宿主机上其他容器的访问，同时带来进行时资源耗尽的风险。

①容器逃逸

与其他虚拟化技术类似，逃逸是最为严重的安全风险。无论是 Docker 容器、还是 Kata 类安全容器，都暴露过各类 逃逸漏洞。逃逸风险对于容器化的云原生场景是一个不可避免的风险面，因为其直接危害了底层宿主机和整个云计算 系统的安全。根据层次的不同，可以进一步展开为：危险配置导致的容器逃逸、危险挂载导致的容器逃逸、相关程序 漏洞导致的容器逃逸、内核漏洞导致的容器逃逸、安全容器逃逸风险。

危险配置导致的容器逃逸。用户可以通过修改容器环境配置或在运行容器时指定参数来缩小或扩大约束。如果用户为 不完全受控的容器提供了某些危险的配置参数，就为攻击者提供了一定程度的逃逸可能性，主要包括未授权访问带来 的容器逃逸风险，特权模式运行带来的容器逃逸风险。 危险挂载导致的容器逃逸。将宿主机上的敏感文件或目录挂载到容器内部，尤其是那些不完全受控的容器内部，往往 会带来安全问题。在某些特定场景下，为了实现特定功能或方便操作，人们会选择将外部敏感卷挂载入容器。随着应 用的逐渐深化，挂载操作变得愈加广泛，由此而来的安全问题也呈现上升趋势。例如：挂载 Docker Socket 引入的容 器逃逸风险、挂载宿主机 procfs 引入的容器逃逸风险等。

相关程序漏洞导致的容器逃逸。所谓相关程序漏洞，指的是那些参与到容器生态中的服务端、客户端程序自身存在的 漏洞。CVE-2019-5736 正是这样一个存在于 runC 的容器逃逸漏洞，它由波兰 CTF 战队 Dragon Sector 在 35C3 CTF 赛后基于赛中一道沙盒逃逸题目获得的启发，对 runC 进行漏洞挖掘，成功发现能够覆盖宿主机 runC 程序的容器逃 逸漏洞。 内核漏洞导致的容器逃逸。Linux 内核漏洞的危害之大、影响范围之广，使得它在各种攻防话题下都占有一席之地。 近年来，Linux 系统曝出过无数内核漏洞，其中能够用来提权的也不少，脏牛（CVE-2016-5195）大概是其中最有名 气的漏洞之一。事实上，脏牛漏洞也能用来进行容器逃逸，一种利用方法的核心思路是向 vDSO 内写入 shellcode 并 劫持正常函数的调用过程。在成功触发漏洞后，攻击者可以获得宿主机上反弹过来的 Shell，实现容器逃逸。

安全容器逃逸风险。无论是理论上，还是实践中，安全容器都具有非常高的安全性。然而，在 2020 年 Black Hat 北 美会议上，Yuval Avrahami 分享了利用多个漏洞成功从 Kata containers 逃逸的议题，安全容器首次被发现存在逃逸 可能性，他使用发现的三个漏洞（CVE-2020-2023、CVE-2020-2025 和 CVE-2020-2026）组成漏洞利用链先后进行容 器逃逸和虚拟机逃逸，成功从容器内部逃逸到宿主机上。

②资源耗尽

容器在运行时默认情况下并未对容器内进程在资源使用上做任何限制，以 Pod 为基本单位的容器编排管理系统也是 类似的。Kubernetes 在默认情况下同样未对用户创建的 Pod 做任何 CPU、内存用限制。限制的缺失使得云原生环境 面临资源耗尽型攻击风险。

（4）容器网络存在的风险

在网络安全方面，由于 K8S 默认不做网络隔离，传统物理网络的攻击手段依然有效（如 ARP 欺骗、DNS 劫持、广播 风暴等）。同时，攻击者可利用失陷的容器进行针对 K8s 集群内部、内网主机的横向渗透； 容器网络环境也面临着“访问关系梳理难，控制难”的痛点。比如：东西向访问流量庞大，无法感知业务间访问关系； 业务访问关系错综复杂，无法制定精细化的访问控制策略；静态策略无法跟随虚拟机自动迁移；容器平台体量巨大， 上下线周期短，容器 IP 地址变化频繁，难以适配容器环境等等。

2．宿主机的威胁风险

容器与宿主机共享操作系统内核，因此宿主机的配置对容器运行的安全有着重要的影响，比如宿主机中安装有漏洞的 软件可能会导致任意代码执行风险，端口无限制开放可能会导致任意用户访问风险，防火墙未正确配置会降低主机的 安全性，没有按照密钥的认证方式登录可能会导致暴力破解并登录宿主机等。安全是一个整体，任何一个环节出问题， 都会影响到其他环节。应用安全可影响到容器安全，容器逃逸可影响到虚拟主机及容器集群的安全，虚拟主机逃逸会 影响到虚拟化基础设施的安全。

3．容器化开发测试过程的威胁风险

DevOps 所倡导的理念是追求敏捷、协作与快速迭代。开发人员往往为了追求便捷的开发环境与快速的迭代节奏选择 将安全系统配置（如权限管理、访问控制等）的优先级降低，为效率与敏捷让步，最终可能使敏感数据权限管理不当 而在容易发生泄露、系统资源无防护的内部开放。若研发环境采用传统安全防护措施，一旦边界防御措施被突破，内 部数据与资源将会对外部攻击者完全开放，产生不可估量的损失与影响。

（二）容器编排平台的风险分析

在云原生环境中，编排系统无疑处于重中之重的地位。任何编排系统都会受到一些攻击，这些攻击会影响部署的整体 安全性和运行时的持续安全性。而 Kubernetes 早已成为容器编排系统的“事实标准”，下面对容器编排平台的风险 进行分析。

1．Kubernetes组件不安全配置

Kubernetes 编排工具组件众多、各组件配置复杂，配置复杂度的提升增加了不安全配置的概率。不安全配置引起的 风险不容小觑，比如 Kubernetes API Server 的未授权访问，Kubernetes Dashboard 的未授权访问，Kubelet 的未授 权访问等，都可能会导致编排工具中帐户管理薄弱，或部分帐户在编排工具中享有很高特权，入侵这些账户可能会导 致整个系统遭到入侵。

2．Kubernetes提权

Kubernetes 非法提权，是指普通用户获得管理员权限或 Web 用户直接提权成管理员用户。编排工具可能存在多种 漏洞导致此类攻击，Kubernetes 权限提升。以 CVE-2018-1002105 漏洞为例，这是一个 Kubernetes 的权限提升漏 洞，允许攻击者在拥有集群内低权限的情况下提升至 Kubernetes API Server 权限；通过构造一个对 Kubernetes API Server 的特殊请求，攻击者能够借助其作为代理，建立一个到后端服务器的连接，攻击者就能以 Kubernetes API Server 的身份向后端服务器发送任意请求，实现权限提升。

3．Kubernetes拒绝服务

传统虚拟化技术设定明确的 CPU、内存和磁盘资源使用阈值，而容器在默认状态下并未对容器内进程的资源使用阈 值做限制，以 Pod 为单位的容器编排管理工具也是如此。资源使用限制的缺失使得云原生环境面临资源耗尽的攻击 风险，攻击者可以通过在容器内运行恶意程序，或对容器服务发起拒绝服务攻击占用大量宿主机资源，从而影响宿主 机和宿主机上其他容器的正常运行。

4．Kubernetes中间人攻击

默认情况下，Kubernetes 集群中所有 pod 组成了一个小型的局域网络，那么就可能发生像中间人攻击这样针对局域 网的攻击行为。假如攻击者借助 Web 渗透等方式攻破了某个 Pod，就有可能针对集群内的其他 Pod 发起中间人攻击， 进而进行 DNS 劫持等。攻击者能够潜伏在集群中，不断对其他 Pod 的网络流量进行窃听，甚至可以悄无声息地劫持、 篡改集群其他 Pod 的网络通信，危害极大。

（三）云原生应用的威胁风险

云原生化应用主要包括微服务、Serverless；同时云原生基础设施和云原生应用也会在原有云计算场景下显著扩大 API 的应用规模，新的安全风险也不容忽视。

1．微服务的威胁风险

首先，随着微服务的增多，暴露的端口数量也急剧增加，进而扩大了攻击面，且微服务间的网络流量多为东西向流量， 网络安全防护维度发生了改变；其次，不同于单体应用只需解决用户或外部服务与应用的认证授权，微服务间的相互 认证授权机制更为复杂，人为因素导致认证授权配置错误成为了一大未知风险。并且微服务通信依赖于 API，随着业务规模的增大，微服务 API 数量激增，恶意的 API 操作可能会引发数据泄漏、越权访问、中间人攻击、注入攻击、拒 绝服务等风险；最后，微服务治理框架采用了大量开源组件，会引入框架自身的漏洞以及开源治理的风险。

微服务入口点增加导致攻击面增大。单体应用的场景下，入口点只有一个，所有的请求都会从这个入口点进来。在这 个入口点建立一组 Filter 或者 Interceptor，就可以控制所有的风险。微服务场景下，业务逻辑并不在一个单一的进程 里，而是分散在很多进程里。每一个进程都有自己的入口点，导致需要防范的攻击面比原来更大，风险也会更高。

微服务调度复杂增加访问控制难度带来越权风险。在单体应用架构下，应用作为一个整体对用户进行授权；而在微服 务场景下，所有服务均需对各自的访问进行授权，明确当前用户的访问控制权限。传统的单体应用访问来源相对单 一，基本为浏览器，而微服务的访问来源还包括内部的其它微服务。因此，微服务授权除了服务对用户的授权，还增 加了服务对服务的授权。默认情况下，容器网络间以白名单模式出现，如果不对 Pod 间访问进行显式授权，一旦某 一 Pod 失陷，将极速扩展至整个集群的 Pod。

微服务治理框架漏洞引入应用风险。常用的微服务治理框架，例如 Spring Cloud、Dubbo 等都是基于社区的模式运 作，虽然内置了许多安全机制，但默认值通常并不安全，常常引入不可预料的漏洞，例如用户鉴权混乱、请求来源校 验不到位等。这些漏洞将会导致微服务业务层面的攻击变得更加容易，为微服务的开发和使用者带来安全隐患。比如 Spring Cloud config 存在 CVE-2019-3799、CVE-2020-5405 漏洞，有的社区对这些漏洞进行了及时修复，需要软件及 时更新到新版本；但也有的漏洞长期缺乏修复，需要微服务开发厂商自行修复，这类漏洞通常修复比较复杂、修复成 本较高。

2．API的威胁风险

云原生带来 API 爆发式增长增加滥用风险。云原生化之后，从基础架构层、到上面的微服务业务层都会有很多标准或 非标准的 API。因为 API 既充当外部与应用的访问入口，也充当应用内部服务间的访问入口，所以数量急剧增加、调 用异常频繁。爆发式的增长导致 API 在身份认证、访问控制、通信加密、以及攻击防御等方面的问题更加明显，面临 更多潜在的风险。

（四）无服务的威胁风险

Serverless（无服务器运算）又被称为函数即服务（Function-as-a-Service，缩写为 FaaS），是云计算的一种模型。 以平台即服务（PaaS）为基础，无服务器运算提供一个微型的架构，终端客户不需要部署、配置或管理服务器服务，代码运行所需要的服务器服务皆由云端平台来提供 ,Serverless 使得底层运维工作量进一步降低，业务上线后，也无 需担忧服务器运维，而是全部交给了云平台或云厂商。。对应 Serverless 的安全风险，一方面包含应用本身固有的 安全风险，另一方面包含 Serverless 模型以及平台的安全风险。 应用程序固有的安全风险，总体上类似传统应用程序的安全风险内容，包括：应用程序漏洞带来的安全风险、第三方 依赖库漏洞引入的安全风险、权限控制缺陷带来的安全风险等。

erverless 模型以及平台的安全风险，主要包括以下几类： （1）函数多源输入导致供应链安全风险资源权限管控不当带来函数使用风险 （2）设计使用不规范引入数据泄露风险 （3）FaaS 平台自身漏洞带来入侵风险 （4）平台设计机制缺陷引入账户拒绝服务风险 （5）缺乏 Serverless 专有安全解决方案导致风险应对能力不足

（五）服务网格的威胁风险

服务网格作为一种云原生应用的体系结构模式，应对了微服务架构在网络和管理上的挑战，也推动了技术堆栈分层架 构的发展。从分布式负载均衡、防火墙的服务的可见性，服务网格通过在各个架构层提供通信层来避免服务碎片化， 以安全隔离的方式解决了跨集群的工作负载问题，并超越了 Kubernetes 容器集群，拓展到运行在裸机上的服务。服 务网格与微服务在云原生技术栈中是相辅相成的两部分，前者更关注应用的交付和运行时，后者更关注应用的设计与 开发。若未在服务网格中采用双向 TLS 认证，服务间容易受到中间人攻击。若未做东西向、南北向的认证鉴权，服 务间容易受到越权攻击。

三、云原生安全近年威胁

（一）近年云原生安全事件风险

1．近年来云原生安全问题分布

根据 StackRox 在 2021 年发布的《容器和 Kubernetes 安全态势报告》显示，针对云原生应用的威胁数量呈现上升趋 势。在过去的 12 个月里，有 94％的组织在其容器环境中遇到过安全问题，其中 69％的组织检测到错误配置，27％ 的组织在运行时遇到安全事件，还有 24％的组织发现了严重的安全漏洞。

在看到惊人的数字之余，进一步考虑到安全事件带来的影响，以及可能会给组织带来灾难性的后果。在云原生环境， 一旦没有实施全面有效的安全防护，黑客可利用漏洞攻击容器上的服务，或可进一步利用容器漏洞，直接访问容器云 上的敏感信息，获取服务器特权，对容器云进行修改并最终完全控制服务器，造成恶劣影响和重大损失。所以必须综 合考虑云原生环境下的 Docker、Kubernetes 等组件的整体安全性，分析研究它们的漏洞特征，进而才能构建一条完 整防线。

2．典型的云原生安全事件

（1）攻击团伙TeamTNT入侵KUBERNETES集群植入挖矿木马

TeamTNT 是一个主要入侵在线容器并通过挖矿和 DDoS 进行牟利的攻击团伙。2021 年年初，该团伙被发现入侵了某 Kubernetes 集群，通过结合脚本和现有工具，最终在容器内植入挖矿木马。研究人员已经发现并确认将近 50000 个 IP 在 TeamTNT 对多个集群实施攻击中被攻击到。在 3 月至 5 月发生的事件期间，TeamTNT 反复使用了多个 IP。大 多数被攻击的节点来自中国和美国。

（2）第一个已知的针对Windows容器的恶意软件

2021 年 3 月，研究人员发现了第一个已知的针对 Windows 容器的恶意软件，恶意软件命名为 Siloscape。其主 要目标是逃离容器。通过 Windows 容器针对 Kubernetes 集群的严重混淆恶意软件。其主要目的是为配置不当的 Kubernetes 集群打开一个后门，以运行恶意容器。该恶意软件可以利用 Kubernetes 集群中的计算资源进行加密劫持， 并可能从受感染集群中运行的数百个应用程序中窃取敏感数据。

（3）下载2000万次的Docker Hub镜像来自加密矿工

研究人员发现有基于云的加密货币挖矿攻击活动，其中矿工通过 Docker Hub 中的镜像进行部署。研究人员分析发现 Docker Hub 中存在用于加密货币挖矿攻击活动的恶意镜像文件，并发现了来自 10 个不同 Docker Hub 账户的 30 个 镜像文件。多个容器映像文件被挖矿软件劫持了至少两年之久，且已被下载了超过 2000 万次。其中主要进行门罗币 挖矿，保守估计加密货币挖矿活动获利 20 万美元。

（4）安全公司Rapid7遭到Codecov供应链攻击，源码泄露

网络安全公司 Rapid7 透露，2021 年 4 月 1 日，程序审计平台 Codecov 遭黑客攻击，该事件可能影响其 2.9 万名客户， 并且引发大量公司连锁数据泄露，造成又一起“供应链”重大安全危机。Codecov 表示从 1 月 31 日开始，黑客就已 经对 Codecov 发起了攻击，利用 Codecov 的 Docker 镜像创建过程中出现的错误，非法获得了其 Bash Uploader 脚 本的访问权限并且进行了修改。这意味着攻击者很有可能导出存储在 Codecov 用户的持续集成（CI）环境中的信息， 最后将信息发送到 Codecov 基础架构之外的第三方服务器。

（二）近年云原生安全漏洞风险

1．近年云原生安全漏洞统计

截至 2021 年 12 月末，我们通过对 CVND 漏洞数据统计分析了云原生基础设施的漏洞分布情况。首先，其中 Docker 相关的漏洞共 174 个，2021 年 38 个。与过去几年相比，在漏洞数量上并没有明显减少的趋势，一旦黑客突破 Docher，如容器逃逸，将会对主机造成巨大威胁；其次，Kubernetes 的安全是整个项目安全生产运行的重要保障。 但是与 Kubernetes 相关的漏洞数量达到 106 个。近年来，随着容器云广泛应用，容器云安全漏洞频繁被发现，漏洞影响越来越严重。如果没有采取及时、有效的防范 措施，一旦攻击者利用这些漏洞，可轻易对云原生基础设施造成致命攻击。

2．典型的云原生安全漏洞

针对近年来出现的众多云原生安全漏洞，一些值得关注的漏洞如下。

（1）CVE-2021-30465：Open Containers 社区披露了 runC 相关的漏洞，攻击者通过创建恶意 Pod，利用符号链接以及条件竞争漏洞将宿主 机目录挂载至容器中，最终可能导致容器逃逸问题。当 Pod 中启动多个容器时，攻击者可以利用条件竞争，构造一个恶意 Pod 并挂载包含了软链接的目标路径，在特定 条件下可以逃逸并获取容器 rootfs 之外的主机文件系统访问权限。

（2）CVE-2021-41103：Containerd 社区公布了安全漏洞 CVE-2021-41103，该漏洞源于 Containerd 中的缺陷。当容器根目录和一些系统插 件中缺少必要的权限约束时，可使一个非特权的主机 Linux 用户拥有遍历容器文件系统并执行目标程序的权限。 在多租户场景下，如果集群节点中的容器包含扩展权限（例如 setuid），非特权的 Linux 用户可能发现并执行该程序。 如果非特权的主机 Linux 用户 UID 碰撞到了容器中执行程序的所属用户或组，这个非特权的 Linux 用户可以读写该文 件从而导致越权访问。

（3）CVE-2021-25735：Kubernetes 官方披露了 kube-apiserver 组件的安全漏洞，攻击者可以在某些场景下绕过 Validating Admission Webhook 的准入机制更新节点。 如果集群中存在使用 Validating Admission 机制进行节点更新准入校验的 Webhook，并且该 Webook 的准入依赖节 点原状态的某些字段，则攻击者可以通过某些手段绕过准入校验完成对节点实例模型的修改。

（4）CVE-2021-25741：Kubernetes 社区公布了安全漏洞 CVE-2021-25741，该漏洞可使攻击者使用软链接的方式在容器中挂载指定 subPath 配置的目录逃逸到主机敏感目录。 在多租户场景下，拥有以 Root 用户启动容器权限的恶意攻击者可以利用该漏洞逃逸至主机文件系统，获取主机敏感 目录的读写权限。

四、云原生威胁检测技术

（一）容器镜像安全检测技术

1．容器镜像安全现状

据 Sysdig 的《2022 云原生安全和使用报告》的数据显示：在运行于生产环境的镜像中，至少包含一个可修复漏洞的 镜像占比高达 85%。此外，包含严重程度为“高”或“严重”的可修复漏洞占比高达 75%。除此之外，攻击者还可以投放恶意镜像到 Docker Hub 中，如果这些恶意镜像被下载以后，就等同于引狼入室。总体 而言，容器镜像安全现状不容乐观。

2．容器镜像安全检测

容器是从本地的镜像仓库中拉取来的，因此镜像的安全性直接关系到容器安全。并且，在实际环境中，本地构建的镜 像还会引入第三方库，所以对引入的第三方库和本地构建的镜像进行安全检测就尤为重要。这里的镜像安全检测主要 分为三个层级，第一级是静态检测，基于已知 CVE 漏洞进行安全扫描和检测；第二级是供应链检测，通过供应链的 威胁情报作为数据支持，并通过自动化测试技术方法来检测镜像中的漏洞；第三级是动态检测，结合已知 CVE 和威 胁情报，并在此基础之上，构建容器沙箱，进行实时动态检测。三个层级层层递进，目前最为基础的是“静态检测”。 正在不断提升和优化的是“供应链检测”。未来，“动态检测”技术将可能得到广泛的应用。

（二）容器运行时安全检测技术

1．基于规则的已知威胁检测

基于规则的异常检测方法一直是最为经典的方案，容器环境下也依然适用。与传统威胁检测不同的是，容器环境下出 现了许多新的威胁场景，如容器逃逸、容器应用漏洞利用，相关的规则和检测引擎也发生了新的变化。

2．基于行为的未知威胁检测

大多数未知行为是无法通过规则匹配检测出来的，因而可通过行为分析来发现未知威胁。一般来说，不同应用的业务 场景是不同的，但在生产运营时间内，业务依赖的程序和模块的行为是能确定、可预测的。 基于上述分析，收集内部业务正常运行期间的进程集合及进程行为、属性集合，采用自学习、无监督的方式，可自动 构建出合理的镜像、容器进程行为基线。在自学习结束后，可以利用这些行为基线对容器内的未知威胁进行检测。

（三）容器网络安全检测技术

1．微隔离

微隔离是一种细粒度的网络隔离技术，其核心能力聚焦于东西向流量，对容器、主机的东西向流量进行隔离和控制， 阻止当攻击者进入云原生网络后进行横向移动。

（1）基于Network Policy实现微隔离

Network Policy 是 Kubernetes 的一种资源，可用来说明一组 Pod 之间是如何被允许互相通信，以及如何与其他网络 端点进行通信。Network Policy 使用标签选择 Pod，并定义选定 Pod 所允许的通信规则。每个 Pod 的网络流量包含 流入（Ingress）和流出（Egress）两个方向。 在默认的情况下，所有的 Pod 之间都是非隔离的、完全可以互相通信，也就是采用了一种黑名单的通信模式。当为 Pod 定义了 Network Policy 之后，只有允许的流量才能与对应的 Pod 进行通信。在通常情况下，为了实现更有效、 更精准的隔离效果，会将这种默认的黑名单机制更改为白名单机制，也就是在 Pod 初始化的时候，就将其 Network Policy 设置为 deny all，然后根据服务间通信的需求，制定细粒度的策略，精确地选择可以通信的网络流量。

（2）基于Sidecar实现微隔离

另外一种微隔离的实现方式就是采用 Service Mesh 架构中的 Sidecar 方式。Service Mesh（比如 Istio）的流量管理 模型通常与 Sidecar 代理（比如 Envoy）一同部署，网格内服务发送和接收的所有流量都经由 Sidecar 代理，这让控 制网格内的流量变得异常简单，而且不需要对服务做任何的更改，再配合网格外部的控制平面，可以很容易地实现微 隔离。

（3）云原生网络入侵检测

由于云原生环境下，传统的 IDS 无法监控和检测到云原生环境的的入侵行为，所以云原生网络入侵检测机制需要实现 对 Kubernetes 集群中每个节点上 Pod 相关的东西及南北向流量进行实时监控，并对命中规则的流量进行告警。告警 能够定位到哪一个节点、哪一个命名空间内的哪一个 Pod。 针对云原生环境下的微隔离需求，一些厂商参考了 NetworkPolicy 以及 SideCar 方案等微隔离实施标准，结合其在主 机微隔离上的技术积累。提出了同时支持主机工作负载与容器工作负载的微隔离解决方案。安全狗“云隙”微隔离产 品就是这种技术路线的代表。具体来说，就是使用 Kubernetes 集群中已经提供的 Network Policy 基础设施进行白名 单的网络管控，并使用产品 In Container Firewall 的功能对集群中 Pod 实施黑名单的网络管控。这样不仅有效利用了 Kubernetes 已有的成熟基础设施，同时也利用了产品在主机微隔离体系的成熟积累。

（四）云原生可观测性

在云原生时代，容器化的基础设施使得应用自身变得更快、更轻。一台主机上可以同时承载上百个容器的部署运行， 主机上应用的部署密度以及变化频率，较传统环境，有着巨大的变化。因此，需要可观测性来清晰地发现和记录主机 快速变化的应用行为。 正所谓“未知攻，焉知防”，面对云原生架构下的大规模集群以及海量灵活的微服务应用，只有知道集群中应用的具 体操作、行为，才能够进行高效的安全防护。 全面的云原生可观测性，包括了系统日志、应用日志等一整套完善的日志审计，还包括了各类运行指标的高性能监控， 以及进程行为追踪、服务调用链追踪等，使我们能够清晰地了解系统详细的运行状况，进而快速高效地进行威胁的检 测、追踪与溯源。

（五）宿主机威胁检测技术

1．总体技术架构

宿主机入侵监测及安全管理平台通常由端 + 云 + 控制台三部分构成，提供了包含安全体检、资产管理、漏洞风险管理、 入侵威胁管理、安全监控、安全防护、合规基线、安全报表、安全告警等功能。

2．关键技术介绍

现有安全检测体系主要采用基于已知威胁特征的传统检测技术，包括防火墙、IPS、杀毒、沙箱等被动技术。这类技 术在以云主机、容器、微服务等为代表的云 / 云原生技术架构场景下，存在一系列难以克服的局限，比如：不能有效 检测和防护新型云攻击威胁、云内部访问控制无法精细化隔离、安全代理软件自身运行占资源影响业务应用的正常运 行等等。 针对云工作负载新型恶意攻击现有检测能力不足的问题，须结合基于机器学习和多维度运行时监控算法，研发多引擎 查杀技术，以有效提升云工作负载新型恶意攻击检测能力。

（六）容器ATT&CK矩阵

MITRE ATT&CK（Adversarial Tactics,Techniques,and Common Knowledge）是基于实战的、全球可访问的网络安全 对抗战术、技术和常识知识库，也是近几年网络安全领域最热门的工具。在 ATT&CK 框架的帮助下，安全团队对攻 击者的行为有了更广泛的了解，成为网络安全学科有用的工具，具有可用于红蓝对抗以及改进网络和系统威胁监测的 能力。2021 年 4 月，MITRE 发布了 ATT&CK 第九版，其中 ATT&CK 容器技术矩阵的出现使得针对 K8s 容器环境的攻 防对抗研究有了可遵循的基本框架。该框架创建了一个明确的、可衡量可量化的行业标准和通用语言， 以评估其容器的安全风险和安全能力。

ATT&CK 容器技术矩阵涵盖了编排层（例如 Kubernetes）和容器层（例如 Docker）的攻击行为，还包括了一系列与 容器相关的恶意软件。ATT ＆ CK 容器矩阵有助于我们了解与容器相关的安全问题，包括镜像安全、镜像仓库完整性 问题、容器运行时安全问题、容器网络层安全以及配置安全问题。于是将 ATT&CK 容器技术矩阵的威胁监测能力与 云原生安全技术相结合，以此提升云原生安全下的威胁监测水平，形成“两翼一统”的格局。这对将高度复杂的云原 生安全攻防对抗和入侵检测从“玄学”变成“科学”，具有深远的意义。

五、云原生漏洞风险检测模型

云原生漏洞风险的隐患当前主要涉及两方面，其一是用户业务运行所依赖的系统组件中存在漏洞；其二是用户业务组 件中存在漏洞。这两方面的漏洞，都会一定程度威胁到云原生整个系统的安全性，所以两方面都应该进行相应的漏洞 检测，确保安全无死角。 而从云原生环境的架构角度来对这两个方面进行进一步的细化，又可以得到一个 5 层安全模型，简称“CCICA 安全模 型”。

（一）CCICA云原生安全模型介绍

为了进行云原生环境下的安全治理，须关注“Cloud”（云）、“Cluster”（集群）、“Image”( 镜像）、“Container” （容器）以及“Application”( 应用）等组成部分，安全狗将这 5 个云原生环境的关键组成部分概括成“CCICA 安全 模型”，下面依次展开介绍。

（二）CCICA云原生安全模型漏洞检测方法概述

基于云原生安全的五大关键组成部分，总结出“CCICA”云原生漏洞风险检测模型。该模型以云原生架构为基础，由 外到内将云原生环境分为 5 个层次。

在云原生环境下，漏洞风险检测应具备以下两个特点： （1）采用内嵌方式，而无需外挂部署； （2）要充分利用云平台原生的资源和数据优势，解决云计算面临特有的安全问题。 安全狗的基于 Agent 的“轻量化、插件化”架构具备上述两个特点，可针对“CCICA”这一云原生安全五层模型进行 漏洞扫描，下面依次展开介绍。

1．Cloud：这一层级主要对应于数据中心的基础设施，属于主机安全范畴。目的是帮助客户检测基础设施的安全风险，作为实施 主机安全加固的依据。主要应用方案为云安全领域的主机漏洞扫描方案。（案例：云眼的应急漏洞、系统漏洞、网站 漏洞、弱口令、风险账号、配置缺陷扫描）。

2．Cluster：这一层级主要对应云原生编排平台，主要组成部分是云原生环境的基础平台组件（例子：Kubernetes 的控制层平面）。 目的为帮助客户获知集群自身的安全风险基本信息，为后续加固方案制定提供依据。主要应用方案为编排平台漏洞扫 描以及 CIS 安全合规基线检查。（案例：云甲的 Kubernetes 集群漏洞扫描，基于端口扫描、PoC 测试，检查集群环 境可能存在的漏洞；云甲基于 CIS 的 Docker、Kubernetes、OpenShift 安全基线，可进行⼀键自动化检测并提供可 视化基线检查结果和代码级的修复建议帮助用户及时发现并修复脆弱点。

3．Image：这一层级主要对应云原生环境中的各种镜像，包括来自镜像仓库以及宿主机的各种容器镜像。目的是解决云原生环境 中镜像安全问题。主要应用方案为容器镜像漏洞扫描、敏感信息扫描、病毒木马扫描、网页后门扫描。

4．Container：这一层级主要对应云原生环境中运行的各种容器，目的是解决云原生环境中容器运行时安全问题。主要应用方案为“运 行时威胁检测”；该应用方案可以分为“恶意文件查杀”“基于规则的已知威胁检测”以及“基于行为模型的未知威 胁检测”三方面来看。在“恶意文件查杀”方面，基于“静态扫描”和“动态实时防护”进行恶意代码查杀，并对它 们进行信任、隔离、下载、删除等；在“基于规则的已知威胁检测”方面，深入研究漏洞底层原理，进行威胁分析、 特征提取（如进程的异常文件行为、高危系统调用、等方面的特征）和规则构建，并利用构建好的规则进行检测实战。 同时，深入研究攻击者的渗透手法，进行容器内的异常命令和文件异常操作威胁检测；在“基于行为模型的未知威胁 检测”方面，通过对容器的进程事件、文件事件、网络事件、进行一定周期的学习，构建容器行为基线，以期对基线 外的行为产生告警，检测 0day 漏洞攻击。

5．Application：这一层级主要对应容器镜像中用户业务相关的运行实体，主要是安装于镜像之中的各种业务模块，比如 WEB 应用。 目的是防止客户业务自身引入不安全的配置、组件和代码到系统之中，从而影响整体的系统安全。主要应用方案为软 件成分分析以及 WEB 漏洞扫描。

六、云原生入侵风险检测模型

当前，虽然业界对基于 ATT&CK 评估、强化产品安全能力有着广泛的研究，但是却没有针对 K8s 容器环境的，以提高“安 全产品检测能力”为目标的框架模型，这无疑会阻滞容器安全产品检测能力的持续提升。在这一问题背景下，安全狗 提出了一种基于 ATT&CK 容器矩阵的可应用于提取检测规则，提升产品检测能力的 AKDA 模型。

（一）AKDA模型

1．模型架构

ATT&CK 的出现为终端安全产品的检测能力提供了一个明确的，可衡量，可落地的标准。为了能够更好地基于 ATT&CK 评估、强化安全产品的能力上，我们提出基于 ATT&CK 的 AKDA 模型。AKDA 是 Attack、Knowledge、Data Sources 以及 Algorithm 这 4 个单词的首字母，即为此模型的关键四步，故名为 “AKDA 四步法模型”。其中“A”代表“Attack”，其含义是：模拟红队攻击；“K”代表“Knowledge”，其含义 是：构建攻防知识图谱；“D”代表“Datasource”，其含义是：确定数据源；“A”代表“Algorithm”，其含义是： 总结威胁检测算法。

（二）模拟红队攻击

“模拟红队攻击”是利用 AKDA 模型的第一步。为了进行模拟红队攻击，首先应根据需求构设实验环境，传统的渗透 测试侧重于突出攻击者可能在某个时间段会利用不同类型系统上的哪些漏洞。而模拟实验则不同，为了能有效提升产 品的检测能力，需要不断调整红蓝对抗场景，研究不同场景下的攻击技术。由于在真实的场景下，大多数真正的攻击 者都有特定的目标（例如，获取对敏感信息的访问权限）；所以，在模拟对抗时，往往会为红队指定特殊的目标，让 蓝队能够针对特定的攻击技战术进行研究和测试。

（三）攻防知识图谱

基于“模拟红队攻击”，可以进行 ATT&CK 的攻防知识图谱的构建。“攻防知识图谱”的依据主要 在于“红队在实施攻击的时候，将不可避免地产生失陷信标 IoC 以及攻击信标 IoA，因而蓝队在识别攻击的时候是有 迹可循的”。由攻防对抗图谱可以洞悉红蓝双方的博弈。在该图中，蓝队的目标是“监控”，需要从左往右看，而红 队的目标是“攻击”，需要从从右往左看。蓝队可通过此图思考防御规则的设置，而红队可通过此图思考防御规则的 绕过。

基于 ATT&CK 框架进行检测分析，这种方式与传统的检测方式有所不同。基于 ATT&CK 检测分析并不是识别已知的 恶意行为然后进行阻断，而是收集在系统上发生的事件数据，并基于这些数据来识别是否为 ATT&CK 知识库中描述 的可疑行为。

（四）数据源

在 AKDA 模型中，确定数据源是重要的一环。数据源的确定是总结该安全场景下的威胁检测算法的前提。在 ATT&CK 框架下的每项技术描述中都有对应于该技术的数据源信息。它告诉我们可以从哪些类型的数据中找到攻击技术实施后 所留下的痕迹。例如对于“命令及脚本执行”的攻击战术，数据源可以是命令执行、模块加载、进程创建以及脚本执 行。数据源往往是模拟攻击结束后蓝方“打扫战场”发现的特征或行为。并且在实际的实战过程中，针对某个技战术 往往要联合多个数据源进行报警，使报警的准确率更高。笔者经过对多个容器安全产品进行研究中发现，备受关注的 前三分别是进程监控、进程命令行参数以及文件监控。通过异常进程、异常文件操作及异常命令等角度，可覆盖 K8s 运行时安全的高频攻击场景。这和 ATT&CK 官方统计的数据是相吻合的。

（五）威胁检测算法

威胁检测算法是“AKDA 模型”的最后一环，也是提升产品检测能力的关键。“红队模拟攻击”是以红队的视角思考 攻击策略，模拟黑客攻击组织机构，而“威胁检测算法”则是思考针对此类攻击的“防御”。

威胁检测算法的构建往往需要不同专业背景的人员进行协作。例如，由安全研究人员梳理具有专业背景的知识库、标 签，并与编程人员、算法研究人员一道设计并优化基于规则的静态匹配算法、基于 AI 的智能算法，或者基于关联分 析的算法。

（六）AKDA模型与ATT&CK之间的关系

在云原生环境中，容器编排系统处于重中之重的地位。据 Sysdig 的《2021 容器安全及使用现状报告》统计，K8s （Kubernetes）在容器编排市场中的占比高达 90%，已经成为容器编排的“事实标准”。然而，传统的安全防护方 式对解决 K8s 容器安全问题有着“威胁监测能力不足”的局限性。因此针对 K8s 容器环境的威胁检测技术亟待发展， 该项研究意义重大。

ATT&CK 容器矩阵的出现使得针对 K8s 容器环境的攻防对抗研究有了可遵循的基本框架。该知识库不仅为针对 K8s 集 群的渗透测试和红蓝对抗提供了理论基础，还成为了一种攻防双方都认可的一种通用语言，并已被广泛应用于渗透测 试活动、防御检测评估、安全运营中心成熟度评估以及网络威胁情报收集等方面。 通过模拟红队攻击、构建攻防知识图谱、确定数据源以及威胁检测算法四个阶段阐述云原生下攻防实践以提升产品能 力的方法。让相对抽象的容器攻击技战术变得有迹可循，以更高效、更准群的方式评估、提升安全产品的检测能力。 未来的安全产品的检测能力将随着攻击技术的发展变得更全面，“AKDA 四步法模型”也应该变得更完善，弥补基于 容器 ATT&CK 在安全检测能力方面的短板。

七、云原生安全实践与技术展望

（一）云原生安全实践

作为致力于提供云安全领域相关产品、服务及解决方案的云安全厂商，这里以我们为例，介绍其在产品和解决方案方 面的一些实践，抛砖引玉。 安全狗容器安全产品云甲采用主机安全 Agent 和安全容器相结合的技术，既能做到对容器的全面保护又能灵活地跟 容器编排体系相结合。在整个容器的安全生命周期中，采用自动检测、自动分析、自动处理的方式来保障容器在构建、 部署和运行整个生命周期的安全。在容器镜像、容器编排、容器运行时几个方面，通过扫描、检测、防篡改等手段进 行风险和发现；在容器内应用安全方面，使用智能检测、机器学习与威胁预测等先进的方法来确保容器及容器内应用 安全。

1．构建阶段

在构建阶段，云甲提供镜像、设施基础检查。针对镜像检测提供镜像在构建中构建后镜像检查服务，针对在 Jenkins 等工具构建生成的镜像进行镜像风险检测，通过镜像准入控制，把控镜像来源，确保安全；提供在仓库镜像的镜像风 险检查，主机中的镜像风险检查。包括但不限于漏洞风险、软件包、证书信息合规、敏感密钥信息、可疑历史操作、 病毒木马文件等。

2．部署阶段

在部署阶段，云甲提供镜像阻断控制、仓库访问控制、添加基础可信镜像等安全能力。 安全狗云原生安全威胁分析报告已到尾声，但云原生产业在中，云原生安全刚刚拉开序幕，云原生安全将开启多元主 导、深度融合、轻量设计的趋势。 镜像阻断控制：采用自定义镜像阻断规则，对存在 root 用户启动、病毒木马、网页后门、特定漏洞或非信任镜像等 规则下的镜像阻断其运行。 仓库访问控制：支持通过身份认证、访问权限控制，避免用户提权访问其他用户的镜像资源。 添加基础可信镜像：通过支持添加基础镜像、可信镜像，在运行、管理镜像中提升运行镜像安全，减少维护时间。

3．运行阶段

在运行阶段，云甲提供运行时安全、容器网络安全、云原生应用安全、基础设施检查。运行时安全：提供行为基准检测，通过建立容器正常运行时的行为基准模型，圈定正常行为范围，将运行时行为与基 准模型进行实时监控比对，从而发现模型外的异常行为，进一步发现未知漏洞攻击等行为。 提供异常风险监控，包括但不限于逃逸风险、反弹连接、进程行为监控、病毒木马、网页后门、执行 ssh 命令、非法 挂载设备等；提供风险事件阻止隔离，包括隔离 POD、停止容器、阻止程序、隔离文件等，并根据严重性发出不同 等级的告警通知。

容器网络安全：支持集群内 POD、容器、服务等资源访问关系、流量关系拓扑。帮助用户在容器运行阶段业务流量 可视化，制定策略；支持容器微隔离，基于自然语言模型进行策略管理，根据端口协议添加策略，添加多种级别的策 略规则，并且支持策略验证与策略回滚。云原生应用安全：支持自动检测发现 K8s 集群中的微服务并做可视化；支持对发现的微服务进行漏洞风险扫描。 基础设施检查：提供主机环境及编排平台环境的漏洞检测，检测运行组件风险；提供针对主机容器 Docker、K8S 的 基线合规检查，减少由于配置不当、挂载不当等带来的风险。

（二）云原生未来展望

安全狗云原生安全威胁分析报告已到尾声，但云原生产业在中，云原生安全刚刚拉开序幕，云原生安全将开启多元主 导、深度融合、轻量设计的趋势。

1．云原生未来发展趋势

（1）云原生应用将成为新基建的重要抓手

2020 年 3 月 4 日，中共中央政治局常务委员会会议强调，要加快推进国家规划已明确的重大工程和基础设施建设， 其中要加快 5G 网络、数据中心等新型基础设施建设进度；随后，国家发改委也进一步明确了“新基建”的范围，包 括以云计算等为代表的新技术基础设施和以数据中心为代表的算力基础设施。 落实国家战略部署，落实新基建是当务之急，从目前的发展现状来看，传统行业企业基本实现了业务的云迁移，其应 用系统的弹性、自动化数据管理能力得到一定的改善，但与类似“双 11”、“618“等互联网支撑系统相比，仍然存 在明显差距，其原因在于业务应用软件云原生化改造和创新尚未跟上。可以说，云原生应用已经成为新基建的重要技 术抓手。

（2）运维下沉，服务网格将成为主流，Serverless逐步推广

云计算的一个发展方向就是运维下沉，将和业务无关的管理功能和运维工作尽量下沉到基础设施中，应用可以聚焦在 业务能力的开发和运营。这个趋势演化的过程，影响了云计算的发展方向。从一开始的虚拟化，到 IaaS，到 PaaS 都 是将应用系统的部分运维职责交给平台运维的过程。

PaaS 为云应用提供了运行容器，解决了应用部署的问题和运行时管理的问题，但是应用仍然有大量的运维工作，特 别是对于微服务应用，需要解决诸多的问题，如服务的发布和感知，多实例应用的负载均衡，服务故障检测和隔离， 已经应用灰度发布的策略等。这些在 PaaS 层面是无法解决的，通常是由开发框架解决，就是我们前面提到的微服务 治理框架。 因为业务功能的提供才是业务开发团队的价值体现，业务开发团队应该聚焦于业务功能的实现，非功能的需求应该交 给平台处理。基于这个诉求服务网格出现了，微服务治理的问题可以有服务网格统一运维管理，业务应用只需关注业 务能力的实现。

服务网格出现后，业务应用本身的生命周期还是需要应用来运维保障。这就逐步演化出了 Serverless 的概念， Serverless 并非没有 Server，而是对于开发团队来说根本不在意 Server 是什么样的。开发团队只需要提交业务代码， 就可以得到需要的运行实例，对应用开发团队来说，Server 是不存在的。 从目前业界的技术趋势来看，ServiceMesh 的概念已经被大部分的大型云上企业接受，ServiceMesh 被诟病的性能问 题也在被逐步解决中，可以预测今年将有更多的微服务应用采用这一基础能力。Serverless 目前发展还比较初期，包 括了全托管的服务和 FaaS（函数即服务），全托管服务在公有云已经逐步成熟，随着混合云的普及，全托管服务会 逐步发展。FaaS 由于涉及开发模式的转变，目前要取代现有的开发模式还需要时日，不过有些合适的应用场景应该 会有越来越多的应用。

（3）软硬结合，解决虚拟化性能问题的利器

随着云计算的发展，虚拟化技术越来越多的被使用，从计算虚拟化到存储虚拟化到网络虚拟化。虚拟化技术带来了很 多的好处，虚拟化是基础设施服务化的基础，通过虚拟化，可以实现基础设施即代码，大大提升了资源的可管理性和 自动化程度。但是虚拟化带来了另外一个问题，就是性能的损耗和软件进程之间的相互影响问题。

对于性能损耗，会导致需要的资源比实际业务耗费的资源更多，提升了服务器资源的成本；进程之间的相互影响则会导致云平台的整体性能问题，网络虚拟化和存储虚拟化都需要通过软件进程的方式，来处理网络流量和 IO。为了 实现分布式高可用和减少数据包转发，基础的 SDN，SDS 的进程通常是和应用进程部署在同一套集群上。这就导致 了有可能部分的 SDN 和 SDS 的管理进程所在服务由于各种原因，CPU 或是内存占用过大，导致无法及时处理网络和 IO 请求，导致云平台整体性能下降。

为了解决这两个问题，目前一个解决思路就是软硬结合，讲云平台的管理进程，如调度管理，网络的虚拟交换机，存 储的虚拟存储网关从操作系统进程中剥离出来，让这些进程跑在专门设计的服务器板卡上，这些板卡专门设计的，通 常含有定制化的芯片（FPGA），可以进行编程，从而可以保持虚拟化话的优势的同时，使的管理进程和业务进程隔离， 避免相互影响；同时由于通过定制芯片（如 FPGA）来处理，性能会有很大提升，大大降低了虚拟化的损耗。

2．云原生安全未来发展趋势

（1）云工作负载安全成为“新基建”安全的基础

没有云工作负载安全就没有云安全，保护云工作负载安全将成为今后云安全防护的关键。随着新基建的快速推进，云 计算和云原生技术正在影响各行各业的 IT 基础设施、平台和应用系统，并随着渗透到工业互联网、5G、车联网、边 缘计算等新型基础设施中，云工作负载安全防护将进一步扩展应用到工业网、车联网、IT 和 OT 融合的 5G 网络、边 缘计算等新型场景中，为设计、部署和运营这些云工作负载基础设施和应用系统企事业单位提供云原生技术相关的风 险、威胁和安全防护手段进行融合的最佳实践。

（2）安全产品将具有云原生的特性

云原生架构将赋予传统安全弹性、可编排、微隔离的云原生能力，传统安全将与云原生深度融合，构建云原生安全架 构，形成对云原生基础设施的防护、检测和响应的能力。

（3）云原生安全落地方案走向敏捷化、精细化

采用容器部署的运行实例具有生命周期短的特点，云原生安全必然要求能够迅速敏捷、及时发现容器的异常行为，并 快速响应。随着微服务、无服务的应用，服务粒度越来越细，相应的云原生安全粒度也越来越细，从过去的容器粒度， 到目前的函数粒度，未来可能是更精细化的粒度。

（4）托管式安全运营服务将成为主流

云原生安全服务商在云端建立统一的安全运营中心，并将分散到各个用户业务场景数据接入进来，进行统一的安全防 护，安全专家基于这些数据进行安全监测和快速处置，大大降低了应对云原生攻击的难度。

（5）云安全建设责任划分更加清晰

目前，在云安全建设当中，对安全责任划分依然比较模糊，租户认为业务系统迁移到云平台之后，所有的安全都由云 平台负责。其实不然，网信办早在 2014 年就已经发文（中网办发文 [2014]14 号），明确指出“四不”原则，“安全 管理责任不变、安全管理标准不变、数据归属关系不变、敏感信息不出镜”，即云安全建设有明显的责任划分，云平 台服务商负责基础设施的安全建设，云租户负责其自己的软件平台、应用平台的安全建设，由双方共同承担虚拟化资 源层的安全建设。未来，随着云原生技术的广泛应用，相关标准不断完善，云安全建设的责任划分将更加清晰。

3．云原生攻防对抗未来发展趋势

（1）云原生技术会融合攻防技术

云原生技术既然能够构建敏捷、弹性扩展的应用，那么攻击者也会使用云原生技术来构建自己的武器库，使用云原生 技术进行的攻防对抗将成为常态。

（2）黑产集团已经具备自动化攻击手段

2019 年，UNIT42 安全团队发现第一款新型挖矿蠕虫，命名为 Graboid 大地虫，被发现时该新型挖矿蠕虫已传播到 2000 多个不安全的 Docker 主机。该病毒可以定期从 C&C 中提取新脚本，因此不仅仅是传播挖矿病毒，而且可以用 于勒索软件或任何恶意软件，可见在云原生技术更新迭代的同时黑产的攻击技术也紧跟其后。

（3）红蓝对抗基于云原生技术增多

红蓝对抗中，利用 ATT&CK 容器矩阵，来覆盖了更多维度的攻防流程和对象，通过初始访问、执行攻击、实现持久 防御作战，再到防御绕过、横向移动，最终窃取数据造，来推动整个云生态的安全稳定。

（本文仅供参考，不代表我们的任何投资建议。如需使用相关信息，请参阅报告原文。）