1、云云原生原生架构安全白皮书架构安全白皮书 （2022021 1 年）年） 云云原生原生产业联盟产业联盟 Cloud Native Industry AllianceCloud Native Industry Alliance，CNIACNIA 2022021 1 年年 5 5 月月版权声明白皮书版权属于云原生产业联盟， 并受法律保护。 转载、白皮书版权属于云原生产业联盟， 并受法律保护。 转载、摘编或利用其它方式使用本白皮书文字或者观点的，应注明摘编或利用其它方式使用本白皮书文字或者观点的，应注明“来源： 云原生产业联盟” 。 违反上述声明者， 本院将追究其“来源： 云原生产业联盟” 。 违反

2、上述声明者， 本院将追究其相关法律责任。相关法律责任。 编写说明编写说明 牵头编写单位：牵头编写单位： 中国信息通信研究院 参与编写单位： 参与编写单位： 阿里云计算有限公司、华为技术有限公司、腾讯云计算（北京）有限公司、北京百度网讯科技有限公司、北京升鑫网络科技有限公司（青藤云安全）、北京小佑科技有限公司、北京神州绿盟信息安全科技股份有限公司、奇安信科技集团股份有限公司、中国移动信息技术中心、启明星辰信息技术集团股份有限公司、北京云思畅想科技有限公司、杭州安恒信息技术股份有限公司、北京奇虎科技有限公司、苏州博纳讯动软件有限公司、烽火通信科技股份有限公司、浪潮电子信息产业股份有限公司、深信服科

3、技股份有限公司 编写组成员： 编写组成员： 中国信息通信研究院：郑剑锋、刘如明、陈屹力、杜岚、周丹颖、闫丹、郑立 阿里云计算有限公司：张大江、汪圣平、匡大虎、朱松 华为技术有限公司：张宇、卢宏旺、刘亚东、莫若 腾讯云计算（北京）有限公司：乐元、李滨、张祖优、姬生利 北京百度网讯科技有限公司：罗启汉、房双德 北京升鑫网络科技有限公司（青藤云安全）：胡俊、李漫 北京小佑科技有限公司：袁曙光、刘斌 北京神州绿盟信息安全科技股份有限公司：江国龙 奇安信科技集团股份有限公司：王亮 中国移动信息技术中心：王庆栋 前前 言言 云计算是信息技术发展和服务模式创新的集中体现， 是信息化发展的重要变革和必然趋势。

4、随着“新基建”加速布局，以及企业数字化转型的逐步深入， 如何深化用云进一步提升云计算使用效能成为现阶段云计算发展的重点。云原生以其高效稳定、快速响应的特点极大地释放了云计算效能，成为企业数字业务应用创新的原动力，有效推动了国民经济的高质量发展。 云原生技术架构充分利用了云计算弹性、敏捷、资源池和服务化特性，在改变云端应用的设计、开发、部署和运行模式的同时，也带来了新的安全需求和挑战。 传统基于边界的防护模型已不能完全满足云原生的安全需求，需要设计全新的云原生安全防护模式，基于动态工作负载，实现云原生技术架构和规模应用的全面防护。 本白皮书将从容器化部署、微服务应用模式、研发运营一体化等云原生特

5、有的技术架构和应用模式出发， 全面剖析云原生系统面临的安全威胁，针对性提出云原生安全边界、原则和防护模型，系统阐述涵盖基础设施安全、云原生计算环境安全、云原生应用安全、云原生研发运营安全、云原生数据安全及安全管理的云原生安全防护体系，列举了国内外云原生安全典型产品与方案， 最后对云原生安全的发展趋势进行了展望。 目目 录录 一、 技术变革、市场推动，呈现云原生安全新需求 . 1 （一） 云原生技术在生产环境采纳率急速升高 . 1 （二） 颠覆性技术架构变革带来全新安全隐患 . 1 （三） 传统的边界防护模型难以应对云原生安全风险 . 3 二、 深入架构、应用驱动，剖析云原生安全新型风险 . 4

6、 （一） 容器化部署成为云原生计算环境风险输入源 . 4 （二） 微服务细粒度切分增加云原生规模化应用风险 . 12 （三） Serverless 灵活性带来模型和平台管控风险 . 14 （四） DevOps 提升研运流程和安全管理的防范难度 . 17 （五） API 爆发式增长催化分离管控和权限滥用风险 . 18 三、 原则引领、架构融合，构建云原生安全体系模型 . 19 （一） 云原生安全防护范围及责任划分 . 19 （二） 云原生安全遵循的设计原则 . 20 （三） 云原生安全防护模型 . 23 四、 分层构建、全景覆盖，打造云原生安全防护体系 . 24 （一） 融合应用云安全防护模型夯

7、实基础设施安全 . 24 （二） 关注容器全要素全生命周期防护打造云原生计算环境安全 . 26 （三） 跟进微服务、Serverless 应用新模式持续推出云原生应用安全 37 （四） 全流程安全左移打造云原生研发运营安全 . 40 （五） 优化实施成本提升运营效率实现云原生数据安全 . 46 （六） 全链融合一体纳管构建云原生安全管理策略 . 47 五、 关注中外、聚焦产品，描绘云原生安全生态图景 . 52 （一） 放眼世界，体系化了解云原生安全开源项目与组件 . 52 （二） 立足本土，系统化梳理云原生安全解决方案与服务 . 54 六、 多元主导、深度融合，洞悉云原生安全发展趋势 . 64

8、 （一） 安全技术的主导力量从单边走向多元 . 64 （二） 安全设计理念从以人为中心转向以服务为中心 . 65 （三） 安全产品形态从粗暴上云转向与平台/应用深度融合 . 65 （四） 安全落地方案从重型化走向轻量化、敏捷化、精细化 . 66 图图 目目 录录 图 1 不同层次的容器逃逸问题 . 10 图 2 云原生安全防护责任共担模型 . 19 图 3 云原生架构安全防护模型架构图 . 23 图 4 CNCF landscape 安全项目及工具示意图 . 52 图 5 华为云容器安全方案架构图 . 55 图 6 阿里云 ACK 容器服务安全体系架构图 . 57 图 7 阿里云 ACK 容器

9、服务应用全生命周期安全能力 . 58 图 8 腾讯云容器安全服务（TCSS）架构图 . 59 图 9 青藤蜂巢容器安全产品架构图 . .61 图 10 青藤蜂巢容器安全产品全流程监测响应示意图 . 62 图 11 小佑科技镜界容器安全防护平台架构图 . 63 表表 目目 录录 表 1 云原生计算环境主要安全风险 . 4 表 2 微服务主要安全风险 . 12 表 3 Serverless 主要安全风险 . 14 表 4 DevOps 主要安全风险 . 17 表 5 API 主要安全风险 . 18 表 6 镜界容器防护平台产品功能列表 . 63 云原生架构安全白皮书（2021 年） 1 一、技术变

10、革、市场推动，呈现云原生安全新需求 （一）（一）云原生技术在生产环境采纳率急速升高云原生技术在生产环境采纳率急速升高 云原生的理念经过几年发展，不断丰富、落地、实践，云原生已经渡过了概念普及阶段，进入了快速发展期。云原生技术以其高效稳定、快速响应的特点驱动引领企业的业务发展，成为企业数字业务应用创新的原动力。 过去几年中， 以容器、 微服务、 DevOps、 Serverless为代表的云原生技术正在被广泛采纳， 2020 年 43.9%的国内用户已在生产环境中采纳容器技术， 超过七成的国内用户已经或计划使用微服务架构进行业务开发部署等1，这使得用户对云原生技术的认知和使用进入新的阶段，技术生

11、态也在快速的更迭。 （二）（二）颠覆性技术架构变革带来全新安全隐患颠覆性技术架构变革带来全新安全隐患 云原生技术架构充分利用了云计算弹性、敏捷、资源池和服务化特性，在改变云端应用的设计、开发、部署和运行模式的同时，也带来了新的安全要求和挑战。 以容器、 Serverless 为载体的云原生应用实例极大地缩短了应用生命周期； 微服务化拆分带来应用间交互式端口的指数级增长以及组件间组合设计复杂度的陡升； 多服务实例共享操作系统带来了单个漏洞的集群化扩散； 独立的研发运营流程增加了软件全生命周期各个环节的潜在风险。 云原生的特有属性带来了架构 1 数据来源：中国信息通信研究院中国云原生用户调查报告

12、2020 云原生架构安全白皮书（2021 年） 2 防护、访问控制、供应链、研发运营等领域全新的安全隐患和安全防护需求。 服务实例应用周期变短增加监控和溯源难度。以容器、Serverless 为载体的云原生应用实例的生命周期极大缩短，容器秒级启动或消失的特性以及持续频繁的动态变化， 增加了安全监控和保护的难度，准确捕捉容器间的网络流量和异常行为成为新挑战。 组件爆发式增长为应用防护能力提出更高要求。 微服务将单体架构拆分成多个服务，应用间的交互端口呈指数级增长、攻击面大幅增加，相较于单体应用架构集中在单个端口防护的简单易行，微服务化应用在端口防护、访问权限、授权机制等方面难度陡增。 容器共享操

13、作系统的进程级隔离环境增加逃逸风险。 传统软件架构下，应用之间通过物理机或虚拟机进行隔离，可以将安全事件的影响限制在可控的范围内。在云原生环境下，多个服务实例共享操作系统， 一个存在漏洞服务被攻陷可能会导致运行在同主机上其他服务受到影响，逃逸风险大大提高。 独立研发运营对软件流转的全链条安全提出新要求。 每个微服务应用都涉及相对独立的开发和测试流程， 并通过 CI/CD （持续集成/持续交付）流水线将应用部署运行到开发测试和生产环境中。在业务应用全生命周期中， 为各个环节的自动化安全防护能力提出了全新要求，不仅要避免各个环节的潜在风险，而且要提高应用的安全交付效率。 云原生架构安全白皮书（20

14、21 年） 3 （三）（三）传统的边界防护模型传统的边界防护模型难以难以应对云原生安全风险应对云原生安全风险 谈及云原生安全， 不少人还停留在传统安全意识和观念， 关注Web攻防和系统攻防，关注密码暴力破解和反弹 Shell。然而，安全总是具有“短板效应”，有时，一个简单的端口暴露、未授权访问没及时处理就为攻击者提供了不费吹灰之力长驱直入的机会。此外，云原生技术架构带来的风险，在未来数年内，会成为攻击者关注和利用的重点，进而发动针对云原生系统的攻击。 传统基于边界的防护模型已不能完全满足云原生的安全需求， 云原生关注快速开发和部署，这种特性要求进行防护模式的转变，从基于边界的防护模式迁移到更接

15、近基于资源属性和元数据的动态工作负载的防护模式，从而有效识别并保护工作负载，以满足云原生技术架构的独特属性和应用程序的规模需求， 同时适应不断变化的新型安全风险。 安全防护模型的转变要求在应用程序生命周期中采用更高的自动化程度，并通过架构设计（例如零信任架构）来确保安全方案实施落地；在云原生系统建设初期，需要进行安全左移设计，将安全投资更多地放到开发安全， 包括安全编码、 供应链 （软件库、 开源软件等）安全、镜像及镜像仓库安全等。 回顾安全发展史， 安全始终是跟随 IT 基础设施和业务来发展的，即安全跟随其服务的对象而演进。进入云原生时代，物理安全边界逐云原生架构安全白皮书（2021 年）

16、4 渐模糊并变成了无处不在的云原生安全体系， 从外到内， 无论可视化、运维和安全管理，还是南北向和东西向网络、容器基础架构、微服务应用模式、身份安全、数据安全等，都给安全市场带来了更丰富的产品维度，衍生出更多元的发展机遇。 二、深入架构、应用驱动，剖析云原生安全新型风险 云原生架构的安全风险包含云原生基础设施自身的安全风险， 以及上层应用云原生化改造后新增和扩大的安全风险。 云原生基础设施主要包括云原生计算环境（容器、镜像及镜像仓库、网络、编排系统等）、DevOps 工具链；云原生化应用主要包括微服务、Serverless；同时云原生基础设施和云原生应用也会在原有云计算场景下显著扩大 API

17、的应用规模。 本章将重点从云原生计算环境、 DevOps、 微服务、Serverless、API 这几个具体的方面展开分析云原生架构新增和扩大的安全风险。 （一）（一）容器化部署容器化部署成为云原生成为云原生计算环境计算环境风险风险输入输入源源 表 1 云原生计算环境主要安全风险 风险类型风险类型 风险引入途径风险引入途径 云原生网络安全风险 访问控制粒度过粗 网络分离管控不合理 云原生编排及组件安全风险 编排工具自身漏洞 编排组件不安全配置 不同安全级容器混合部署 编排组件资源使用不设限 编排节点访问控制策略配置不当 镜像安全风险 镜像含软件漏洞 云原生架构安全白皮书（2021 年） 5 镜

18、像配置缺陷 镜像来源不可信 镜像仓库安全风险 镜像仓库自身漏洞及管理问题 镜像获取通道不安全 容器逃逸攻击 容器危险配置 容器危险挂载 相关程序漏洞 宿主机内核漏洞 安全容器逃逸风险 1.网络的细粒度划分增加了访问控制和分离管控难度 访问控制粒度过粗引入了权限放大的风险导致越权攻击。 云原生环境下，服务实现了细粒度拆分，业务依赖关系复杂。如果容器网络层不能依据业务关系实现细粒度的访问控制策略， 就会带来网络权限放大的风险，例如：无需被外网访问的业务被默认设置了外网访问权限，容器网络可无限制访问宿主节点的下层网络等。攻击者将利用这些漏洞，获取权限外甚至核心系统的访问控制权限，最终实现越权甚至提权

19、攻击。 网络分离管控不合理增加了横向攻击的风险导致威胁扩展。 云原生网络既有南北向流量，也有东西向流量，服务之间的数据流动极其频繁；并且在云原生环境下，多个服务实例共享操作系统，一个存在漏洞服务被攻陷将会导致运行在同一主机上的其他服务受到影响。 如果各服务单元对应的容器组之间、 容器网络与物理网络之间没有做好网络权限的分离管控，外网攻击者就能从高风险实例逃逸，伴随东西向流量在集群网络内部的实例之间进行横向攻击， 致使威胁在集群内云原生架构安全白皮书（2021 年） 6 大范围扩散。 另外， 有些云原生平台采用 underlay 模式的网络插件，使得容器 IP 与节点 IP 共享同一网络平面，在

20、业务 IP 暴露给最终用户的同时，管理控制台会面临被入侵的风险。 2.云原生编排组件存在漏洞及管控风险增加入侵概率 编排工具自身漏洞导致非法提权和逃逸攻击。非法提权，是指普通用户获得管理员权限或 Web 用户直接提权成管理员用户。 编排工具可能存在多种漏洞导致此类攻击，以 CVE- 漏洞为例，这是一个 Kubernetes 的权限提升漏洞，允许攻击者在拥有集群内低权限的情况下提升至 Kubernetes API Server 权限；通过构造一个对Kubernetes API Server 的特殊请求，攻击者能够借助其作为代理，建立一个到后端服务器的连接，攻击者就能以 K

21、ubernetes API Server 的身份向后端服务器发送任意请求，实现权限提升。逃逸攻击，是指攻击者通过劫持容器内某种权限下的命令执行能力，借助一些手段进一步获得该容器所在宿主机上某种权限下的命令执行能力。以 CVE- 漏洞为例， 这是一个 Kubernetes 的文件系统逃逸漏洞， 允许攻击者使用 subPath 卷挂载来访问卷空间外的文件或目录，这个漏洞本质上是 Linux 符号链接特性与 Kubernetes 自身代码逻辑两部分结合的产物。符号链接引起的问题并不新鲜，这里它与虚拟化隔离技术产生了逃逸问题， 以前还曾有过在传统主机安全领域与suID 概念碰撞

22、产生的权限提升等问题。 云原生架构安全白皮书（2021 年） 7 编排组件不安全配置引起账户管理问题导致系统入侵。 编排工具组件众多、各组件配置复杂，配置复杂度的提升增加了不安全配置的概率，而不安全配置引起的风险不容小觑，可能会导致编排工具中帐户管理薄弱，或部分帐户在编排工具中享有很高特权，入侵这些账户可能会导致整个系统遭到入侵。 不同安全级容器混合部署导致高安全级容器面临入侵风险。 编排工具侧重工作负载规模和密度的管理。默认情况下，编排工具可以将不同安全级别的工作负载部署在同一主机上， 导致高安全级工作负载面临入侵风险。例如，将运行面向公众 Web 服务器的容器与运行处理敏感财务数据的容器置

23、于同一主机上， 在 Web 服务器有严重漏洞的情况下，就会显著提高处理敏感财务数据的容器面临的入侵风险。 编排组件资源使用不设限加大资源耗尽风险导致拒绝服务攻击。传统虚拟化技术设定明确的 CPU、内存和磁盘资源使用阈值，而容器在默认状态下并未对容器内进程的资源使用阈值做限制， 以 Pod 为单位的容器编排管理工具也是如此。 资源使用限制的缺失使得云原生环境面临资源耗尽的攻击风险， 攻击者可以通过在容器内运行恶意程序，或对容器服务发起拒绝服务攻击占用大量宿主机资源， 从而影响宿主机和宿主机上其他容器的正常运行。 典型漏洞包括CVE-2019-11253、CVE-2019-9512、CVE-201

24、9-9514 等。 云原生架构安全白皮书（2021 年） 8 编排节点访问策略配置不当导致未授权主机非法访问。 维护编排环境中各节点之间的信任关系时需要充分考虑依赖和调用关系， 编排工具访问策略配置不当可能让编排工具和其上运行的容器技术组件面临极大风险，例如：主机之间通信未加密或未认证，导致未经授权的主机加入集群并运行容器； 用于认证的密钥在所有节点中共享编排工具，导致集群中单个主机被入侵后扩散至整个集群被入侵等。 3.镜像构建部署过程不规范引入自身风险 镜像更新不及时导致软件漏洞。在传统模式中，部署的软件在其运行的主机上“现场”更新；与此不同，容器则必须在上游的镜像中进行更新，然后重新部署。

25、因此，容器化环境的常见风险之一就是用于创建容器的镜像版本存在漏洞，从而导致所部署的容器存在漏洞。 镜像配置缺陷导致应用风险增加。 镜像配置不当可能会让系统面临攻击危险，例如，镜像未使用特定用户账号进行配置导致运行时拥有的权限过高； 镜像含 SSH 守护进程导致容器面临不必要的网络风险等。 镜像来源不可信注入恶意镜像。 镜像及容器技术一个主要的特点就是方便移植和部署， 云原生用户可以将符合 OCI 标准的第三方镜像轻松部署到自己的生产环境中。因此，攻击者可将含有恶意程序的镜像上传至公共镜像库，诱导用户下载并在生产环境中部署运行，从而实现其攻击目的。根据目的的不同，常见的恶意镜像有三种类型：一云原

26、生架构安全白皮书（2021 年） 9 是恶意挖矿镜像，欺骗受害者在机器上部署容器从而获得经济收益；二是恶意后门镜像，受害者在机器上部署容器后，攻击者收到容器反弹过来的 shell，实现对容器的控制；三是恶意 exploit 镜像，在受害者部署容器后尝试寻找宿主机上的各种漏洞实现容器逃逸， 实现对受害者机器的控制。 4.镜像仓库模式增加云原生软件供应链风险来源 镜像仓库漏洞和管理问题带来自身安全风险。 镜像仓库安全风险主要涉及仓库账号及其权限的安全管理、镜像存储备份、传输加密、仓库访问记录与审计等， 这些方面如果存在加固或配置策略不足的问题，都可能导致镜像仓库面临镜像泄露、篡改、破坏等风险。例如

27、，垂直越权漏洞，因注册模块对参数校验不严格，导致攻击者可以通过注册管理员账号来接管 Harbor 镜像仓库，从而写入恶意镜像。实际使用中， 用户往往会将镜像仓库作为有效且获得批准的软件源， 因此，镜像仓库遭到入侵将极大增加下游容器和主机的入侵风险。 镜像获取通道不安全引入中间人攻击。 保证容器镜像从镜像仓库到用户端的完整性是镜像仓库面临的一个重要安全问题。 如果用户以明文形式拉取镜像， 在与镜像仓库交互的过程中极易遭遇中间人攻击，导致拉取的镜像在传输过程中被篡改或被冒名发布恶意镜像， 从而造成镜像仓库和用户双方的安全风险。 云原生架构安全白皮书（2021 年） 10 5.容器特性增加云原生运行

28、时逃逸风险和威胁范围 无论是 Docker 容器、还是 Kata 类安全容器，都暴露过各类逃逸漏洞，逃逸风险对于容器化的云原生场景是一个不可避免的风险面，特别是在多业务系统、多租户环境下，风险更高，直接危害了底层宿主机和整个云计算系统的安全。 根据层次的不同，容器逃逸的类型可以分为以下三类： 运行时操作危险配置、危险挂载应用程序操作系统内核程序漏洞内核漏洞严重性利用可能性层次安全容器逃逸 图 1 不同层次的容器逃逸问题 上图可以进一步展开为： 1) 危险配置导致的容器逃逸； 2) 危险挂载导致的容器逃逸； 3) 相关程序漏洞导致的容器逃逸； 4) 内核漏洞导致的容器逃逸； 5) 安全容器逃逸风

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

30、 Docker Socket 引入的容器逃逸风险，挂载宿主机 procfs 引入的容器逃逸风险等。 相关程序漏洞导致的容器逃逸。相关程序漏洞，指的是那些参与到容器生态中的服务端、客户端程序自身存在的漏洞。本节涉及到的相关漏洞均分布在容器及容器集群环境的程序组件中。例如 CVE-2019-5736 正是这样一个存在于 runC 的容器逃逸漏洞。 宿主机内核漏洞导致的容器逃逸。 对内核漏洞的利用往往都是从用户空间非法进入内核空间开始， 到内核空间赋予当前或其他进程高权限后回到用户空间结束。 Linux内核漏洞危害极大、 影响范围极广，是各种攻防话题下不可忽视的一环。近年来，Linux 系统曝出过无

31、数内核漏洞， 其中能够用来提权的也不少， 典型的就是脏牛漏洞 （Dirty COW CVE-2016-5195）。 安全容器逃逸风险。无论是理论上，还是实践中，安全容器都具有非常高的安全性。然而，在 2020 年 Black Hat 北美会议上，Yuval 云原生架构安全白皮书（2021 年） 12 Avrahami 分享了利用多个漏洞成功从 Kata containers 逃逸的议题，安全容器首次被发现存在逃逸可能性，他使用发现的三个漏洞（CVE-2020-2023、CVE-2020-2025 和 CVE-2020-2026）组成漏洞利用链先后进行容器逃逸和虚拟机逃逸，成功从容器内部逃逸到宿

32、主机上。 （二）（二）微服务微服务细粒度切分增加云原生规模化细粒度切分增加云原生规模化应用应用风险风险 表 2 微服务主要安全风险 风险类型风险类型 风险引入途径风险引入途径 攻击端口和攻击面增加 微服务入口点增加 访问控制风险 访问控制策略复杂 治理框架风险 微服务治理框架漏洞 首先，随着微服务的增多，暴露的端口数量也急剧增加，进而扩大了攻击面，且微服务间的网络流量多为东西向流量，网络安全防护维度发生了改变；其次，不同于单体应用只需解决用户或外部服务与应用的认证授权，微服务间的相互认证授权机制更为复杂，人为因素导致认证授权配置错误成为了一大未知风险， 并且微服务通信依赖于API，随着业务规模

33、的增大，微服务 API 数量激增，恶意的 API 操作可能会引发数据泄漏、越权访问、中间人攻击、注入攻击、拒绝服务等风险；最后，微服务治理框架采用了大量开源组件，会引入框架自身的漏洞以及开源治理的风险。 微服务入口点增加导致攻击面增大。单体应用的场景下，入口点只有一个，所有的请求都会从这个入口点进来，在这个入口点去建立一组 Filter 或者 Interceptor， 就可以控制所有的风险。 微服务场景云原生架构安全白皮书（2021 年） 13 下，业务逻辑不是在一个单一的进程里，而是分散在很多进程里。每一个进程都有自己的入口点，导致防范的攻击面比原来大得多，风险也会高得多。 微服务调度复杂增

34、加访问控制难度带来越权风险。 在单体应用架构下，应用作为一个整体对用户进行授权；而在微服务场景下，所有服务均需对各自的访问进行授权，明确当前用户的访问控制权限。传统的单体应用访问来源相对单一，基本为浏览器，而微服务的访问来源还包括内部的其它微服务，因此，微服务授权除了服务对用户的授权，还增加了服务对服务的授权。默认情况下，容器网络间以白名单模式出现，如果不对 Pod 间访问进行显式授权，一旦某一 Pod 失陷，将极速扩展至整个集群的 Pod。 微服务治理框架漏洞引入应用风险。常用的微服务治理框架，例如 Spring Cloud、Dubbo 等都是基于社区的模式运作，虽然内置了许多安全机制，但默

35、认值通常并不安全，常常引入不可预料的漏洞，例如用户鉴权混乱、请求来源校验不到位等，将会导致微服务业务层面的攻击变得更加容易，为微服务的开发和使用者带来安全隐患。比如Spring Cloud config 存在 CVE-2019-3799、CVE-2020-5405 漏洞，这些漏洞有的社区进行了及时修复，需要软件及时更新到新版本；但也有的漏洞长期缺乏修复，需要微服务开发厂商自行修复，这类漏洞通常修复比较复杂、修复成本较高。 云原生架构安全白皮书（2021 年） 14 （三）（三）ServerlessServerless 灵活性带来模型和平台管控风险灵活性带来模型和平台管控风险 表 3 Serve

36、rless 主要安全风险 风险类型风险类型 风险引入途径风险引入途径 应用程序固有风险 应用程序漏洞、第三方依赖库漏洞、消息明文传递等传统应用程序风险 Serverless 计算模型风险 函数多源输入 资源权限管控不当 数据源增加 环境变量替代配置文件存储 跨函数调用数据清理不及时 Serverless 平台风险 平台自身漏洞 平台账户拒绝服务（DoW） 平台强依赖性 Serverless 是云原生架构下，针对应用程序构建和部署运行的模型，其目标是使开发人员专注于应用程序的构建和部署运行，而无需管理服务器等资源。Serverless 模型包含了开发者开发、部署、运行的应用程序，以及云计算供应商

37、提供的 Serverless 支撑平台。对应 Serverless 的安全风险，一方面包含应用本身固有的安全风险，另一方面包含 Serverless 模型以及平台的安全风险。 应用程序固有的安全风险， 总体上类似传统应用程序的安全风险内容，包括：应用程序漏洞带来的安全风险、第三方依赖库漏洞引入的安全风险、权限控制缺陷带来的安全风险等。 Serverless 模型以及平台的安全风险，主要包括以下几类： 函数多源输入导致供应链安全风险。Serverless 模式下函数调用由事件源触发，这种输入来源的不确定性增加了安全风险。如果函云原生架构安全白皮书（2021 年） 15 数未对外界输入数据进行有效

38、的过滤或安全校验， 就可能存在 SQL 注入、系统命令执行等类型的攻击风险。 资源权限管控不当带来函数使用风险。Serverless 应用通常会由诸多函数组成，函数间的访问权限、函数与资源的权限映射会非常多，如何高效地进行角色和权限的管控是一个复杂的问题。许多开发者可能暴力地为所有函数配置单一的角色和权限， 这一行为将极大地增加函数使用风险。 设计使用不规范引入数据泄露风险。 一是数据源增加导致数据攻击面增加。传统应用只是从单一服务器上获取敏感数据，而Serverless架构中攻击者可针对各种数据源进行攻击， 攻击面更广。二是环境变量替代配置文件引入泄露风险。Serverless 应用由众多函

39、数组成， 无法像传统应用程序使用单个集中式配置文件存储的方式，因此开发人员多使用环境变量替代，虽然存储更为简单，但使用环境变量本就是一个不安全的行为，一旦攻击者进入运行环境，可以轻易获取环境变量信息，引起信息泄露。三是跨函数调用数据清理不及时引入数据泄露风险。Serverless 函数基于触发机制实现函数调用与运行，在无状态函数的运行过程中，倘若函数调用结束后没有及时清除暂存的配置参数、账号信息或其他业务敏感信息，后续使用基础设施资源的函数可能会访问这些数据，存在机密数据泄露的风险。 云原生架构安全白皮书（2021 年） 16 FaaS 平台自身漏洞带来入侵风险。近年来，私有云 FaaS 平台

40、由于其自身代码含有漏洞进而导致函数遭受攻击的案例越来越多， 这些攻击行为主要以攻击者利用平台漏洞进行挖矿、 数据窃取为主。 例如，2018年6月Apache OpenWhisk平台被曝出的CVE-2018-11756漏洞。 平台设计机制缺陷引入账户拒绝服务风险。 针对平台账户的攻击主要为 DoW 攻击（拒绝钱包攻击），这是拒绝服务攻击的变种，其目的是耗尽账户的账单金额。Serverless 平台通常支持自动化的弹性扩展，开发人员按函数调用次数付费，这一特性产生的费用通常没有特定限制。如果攻击者掌握了事件触发器，在未受保护的情况下，函数调用可能会极速扩展，随之产生的费用也将爆发式增长，最终会导致

41、用户账户受到重大损失。 例如， 2018 年 2 月 NodeJS “aws-lambda-multipart-parser”库被曝出的 ReDoS 漏洞（CVE-2018-7560）。 缺乏 Serverless 专有安全解决方案导致风险应对能力不足。广泛使用的安全检测体系如 WAF、IPS/IDS、DAST、SAST、日志审计工具等，均是基于云场景中虚机或容器底座、基于 Web 应用或传统应用架构进行设计、开发和应用的；而 Serverless 无论机制、架构还是应用场景均存在一定的特殊性， 现阶段成熟有效的安全检测工具与机制无法直接匹配或移植，使得 serverless 服务的使用者和运

42、营者难以有效应对网络中层出不穷的新攻击方法与手段， 在方法机制与工具支撑方面存在较大的差距与风险。 云原生架构安全白皮书（2021 年） 17 （四）（四）DevDevO Opsps 提升提升研研运流程运流程和安全管理的防范难度和安全管理的防范难度 表 4 DevOps 主要安全风险 风险类型风险类型 风险引入途径风险引入途径 设计风险 安全理念不够重视程度不足 流程风险 安全团队与安全流程缺失 管理风险 人员权限扩大 工具风险 开源工具和开源组件大量使用 安全理念和重视程度不足带来一系列设计安全问题。DevOps 所倡导的理念是追求敏捷、协作与快速迭代，开发人员往往为了追求便捷的开发环境与快

43、速的迭代节奏选择将安全系统配置（如权限管理、访问控制等）的优先级降低，为效率与敏捷让步，最终可能使敏感数据权限管理不当而在内部泄露、系统资源无防护而在内部开放。若研发环境采用传统安全防护措施，一旦边界防御措施被突破，内部数据与资源将会对外部攻击者完全开放，产生不可估量的损失与影响。 安全团队与安全流程缺失增加流程中的风险引入。经典 DevOps理念中，没有强调安全团队的参与和安全流程的控制，开发测试环境与生产环境的隔离也有悖于 DevOps 宣传的代码提交后部署到生产环境的流程（例如，代码中可能存在明文密钥、使用弱密码算法或不安全的传输协议等），这些都将引入全新风险。 人员权限扩大化导致敏感数

44、据泄露带来管控风险。按照 DevOps的理念，开发与运维的权限划分会有一部分模糊或权限的扩大化，导致开发人员有可能访问到生产环境里的客户敏感数据， 或者运维能访问到研发内部的企业敏感数据，这将导致敏感数据的泄露风险。 云原生架构安全白皮书（2021 年） 18 开源组件和开源工具的大量使用导致权限混乱和漏洞注入。DevOps 的实践中，多数企业会基于类似 Jenkins 的开源工具来整合工具链，而每个不同工具或组件都可能有各自的账号体系，如果使用超级管理员账号进行对接则存在巨大的安全隐患； 丰富的工具或组件也引入了更多安全漏洞需要持续关注和运维。 （五）（五）A APIPI 爆发式增长爆发式增

45、长催化催化分离管控和权限分离管控和权限滥用风险滥用风险 表 5 API 主要安全风险 风险类型风险类型 风险引入途径风险引入途径 未授权访问 API 管理不当 API 设计存在缺陷 数据泄露 安全措施不足 DDoS 风险 资源和速率没有限制 云原生带来 API 爆发式增长增加滥用风险。云原生化之后，从基础架构层、到上面的微服务业务层都会有很多标准或非标准的 API，既充当外部与应用的访问入口，也充当应用内部服务间的访问入口，API 的数量急剧增加、调用异常频繁。爆发式的增长导致 API 在身份认证、访问控制、通信加密、以及攻击防御等方面的问题更加明显，面临更多潜在的风险。与此同时，企业面对大量

46、的 API 设计需求，其相应的 API 安全方案往往不够成熟，从而引起滥用的风险。Gartner预测，到 2022 年，API 滥用将成为导致企业 Web 应用数据泄露最频繁的攻击载体。 云原生架构安全白皮书（2021 年） 19 三、原则引领、架构融合，构建云原生安全体系模型 （一）（一）云原生安全云原生安全防护范围及责任防护范围及责任划分划分 云原生安全不同于传统安全及云安全， 它更关注容器和容器运行时，针对微服务和无服务的应用新形态，也需要重新考虑其安全隐患和防护措施。 云原生安全所保护的对象，是指以容器技术为基础底座，以DevOps、 面向服务等云原生理念进行开发并以微服务等云原生架构

47、构建的业务系统共同组成的信息系统。容器服务、Service Mesh 与Serverless 等均属于云原生范畴，是以容器技术为核心基础的不同交付/服务模式，不同的服务模式责任模型有所不同，如下图所示。 平台提供方应用拥有方用户管理安全策略数据管理应用研发应用构建和部署服务运行时资源调配服务日志管理 存储加密网络安全 虚拟化设施IaaSIaaS用户管理安全策略数据管理应用研发应用构建和部署服务运行时资源调配服务日志管理 存储加密网络安全 虚拟化设施K8sK8s- -aaSaaS用户管理安全策略数据管理应用研发应用构建和部署服务运行时资源调配服务日志管理 存储加密网络安全 虚拟化设施CaaSCa

48、aS用户管理安全策略数据管理应用研发应用构建和部署服务运行时资源调配服务日志管理 存储加密网络安全 虚拟化设施FaaSFaaS用户管理安全策略数据管理应用研发应用构建和部署服务运行时资源调配服务日志管理 存储加密网络安全 虚拟化设施SaaSSaaS 图 2 云原生安全防护责任共担模型 云原生架构安全白皮书（2021 年） 20 （二）（二）云原生安全遵循的云原生安全遵循的设计设计原则原则 1.零信任架构 NIST 在 2020 年 8 月发布了最新的零信任架构，在零信任安全模型中，会假设环境中随时存在攻击者，不能存在任何的隐形信任，必须不断的分析和评估其资产、网络环境、业务功能等的安全风险，然

49、后制定相应的防护措施来缓解这些风险。在零信任中，这些防护措施通常要保证尽可能减少对资源 （比如数据、 计算资源、 应用和服务等）的访问，只允许那些被确定为需要访问的用户和资产进行访问，并且对每个访问的身份和安全态势进行持续的认证和授权。 零信任架构通过细粒度拆分构建微边界的架构模型， 并通过执行策略限制消除数据、资产、应用程序和服务的隐式信任，从而减轻了网络威胁横向扩散的可能性。 零信任架构的最常见实现方法是依赖于加密概念的。首先要用硬件或者令牌来保护特定的密钥信息，并且能够用安全的方式和平台进行通信。 零信任架构通常由几个部分组成： 每个实体都能创建自己的标识，每个实体都能独立地认证其它实体

50、（例如用公钥体系），实体之间的通信是加密且不可篡改的。 最小权限原则也非常重要， 甚至被认为是云原生架构中最重要的内容之一， 云原生技术栈的所有层面在进行认证授权的设计实现过程中，都需要考虑这个原则。 云原生架构安全白皮书（2021 年） 21 2.安全左移 在云原生安全建设中，容器实例生命周期短、业务复杂，而且存在与操作系统虚拟化环境中现有的物理或虚拟化的安全设备无法有效工作的情况，此时，增加运行时的安全投入无助于提高整体的安全水平。 因而国内外在过去两年提出了安全左移 （Shift Left） 的思路，即在云原生安全建设初期将安全投资更多地放到开发安全， 包括安全编码、供应链（软件库、开源