前言
网络安全 发展的方向有两种趋势，一是与新场景、新应用结合，典型的如云计算、人工智能、物联 网等；二是安全技术自身的演化，例如欺骗技术、威胁狩猎、智能决策等，而这两类趋势往往可能会融 合，如人工智能与安全技术之间，既利用 AI技术赋能安全运营形成 AISecOps，又加速了智能化安全运 营和智能化攻击技术的对抗。当云计算 发展将近二十年后，已然进入了新的阶段：云原生时代。以容器、编排和微服务为代表的 云原生技术，正在影响各行各业的 IT基础设施、平台和应用系统，也在渗透到如 IT/OT融合的工业互联网、 IT/CT 融合的 5G、边缘计算等新型基础设施中。理解云原生体系存在的新架构、新风险和新威胁，有 助于我们构建面向新型 IT基础设施的安全防护机制；利用云原生的先进技术，融合到当前的攻防体系中， 也有助于我们提升整体安全防护的弹性、适应性、敏捷性。我们在 2018 年发布了《容器安全技术报告》，详细分析了容器技术所面临的风险和安全挑战，介 绍了安全左移思路下的安全基线、镜像安全等内容，给初建容器安全的机构一些有益的建议。近年随着 编排技术、无服务和服务网格等技术的快速发展，我们将重点放在了整个云原生 生态体系的安全研究上。鉴于此，我们发布了《云原生安全技术报告》，本报告较为全面地分析了云原生落地所面临的安全 风险和威胁，进而提出了云原生的防护思路和安全体系。首先，详细介绍了多种实现云原生环境的可观察、 可追踪的技术手段；然后介绍了在事前应实现零信任网络访问控制的微隔离技术，以及在事中面向容器 环境的异常检测技术和面向云原生应用和服务的应用业务安全技术。此外，报告也介绍了云原生新形态 的服务网格和无服务安全防护技术。最后，报告就 5G核心网和边缘计算等场景探讨了云原生安全的应用。 本报告在编写过程中参考了大量资料，吸取了多方的宝贵意见和建议，在此深表感谢。报告的编写 和发布得到了相关单位的大力支持，我们在此表示衷心的感谢！欢迎广大读者批评、指正。
云原生安全概述
云原生安全概述 随着云计算技术的成熟和云计算系统的广泛部署，上云成为了企业部署新业务的首选。同时， 各大云计算服务商的厮杀日益激烈，新的概念也层出不穷。近年来，云原生计算（Cloud Native Computing）越来越多地出现在人们的视野中，那么云原生计算与传统云计算相比有什么不同，能利用 云原生计算解决什么问题，本章我们将介绍云原生计算的概念和应用场景。
云原生简介
近年来，云计算的模式逐渐被业界认可和接受。在国内，大多数利用开源或商业的 IaaS 系统构建 云计算平台，这种方式所带来的好处是整体资源利用更加合理，集约式的运营降低成本，提升整体水平。 但总体而言，这样的上云实践只是“形”上的改变，还远没有到“神”上的变化。 在上云实践中，传统应用有升级缓慢、架构臃肿、无法快速迭代等问题，于是云原生的概念应运而生。 云原生充分利用云计算弹性、敏捷、资源池和服务化等特性，解决业务在开发、集成、分发和运行等整 个生命周期中遇到的问题。真实业务中出现的问题，才是真正的“问题”。所以，我们认为云计算下半 场的开场哨已经吹响，谁赢得云原生的赛道，谁才真正赢得了云计算。 更为正式地，云原生计算基金会（Cloud Native Computing Foundation，CNCF）对云原生的见解 [1] 是“云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的 应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式 API。这些技术能够 构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段，云原生技术使工程师能够 轻松地对系统作出频繁和可预测的重大变更。” 在云原生应用和服务平台构建过程中，容器技术凭借其轻隔离、易分发等特性和活强大的社区支 持，成为了云原生等应用场景下的重要支撑技术。无服务、服务网格等服务新型部署形态也在改变云端 应用的设计、开发、部署和运行，从而重构云上业务模式。
云原生安全简介
与云计算安全相似，云原生安全也包含两层含义：“面向云原生环境的安全”和“具有云原生特征 的安全”。
面向云原生环境的安全
面向云原生环境的安全，其目标是防护云原生环境中的基础设施、编排系统和微服务的安全。 这类安全机制，不一定具备云原生的特性（比如容器化、可编排），它们可以是传统模式部署的， 甚至是硬件设备，但其作用是保护日益普及的云原生环境。 一个例子是容器云（CaaS）的抗拒绝服务，可用分布式拒绝服务缓解机制（DDoS Mitigation）， 而考虑到性能限制，一般此类缓解机制都是硬件形态，但这种传统安全机制正是保障了是面向云原生系 统的可用性。 此外，主机安全配置、仓库和镜像安全、行为检测和边界安全等都是面向云原生环境的安全机制。
具有云原生特性的安全
具有云原生特征的安全，是指具有云原生的弹性敏捷、轻量级、可编排等特性的各类安全机制。 云原生是一种理念上的创新，通过容器化、资源编排和微服务重构了传统的开发运营体系，加速业 务上线和变更的速度，因而，云原生系统的种种优良特性同样会给安全厂商带来很大的启发，重构他们 的安全产品、平台，改变其交付、更新模式。 仍以 DDoS 为例，在数据中心的安全体系中，抗拒绝服务是一个典型的安全应用，以硬件清洗设备 为主。但其缺点是当 DDoS 的攻击流量超过了清洗设备的清洗能力时，无法快速部署额外的硬件清洗设 备（传统硬件安全设备的下单、生产、运输、交付和上线往往以周计），因而这种安全机制无法应对突 发的大规模拒绝服务攻击。而如果采用云原生的机制，安全厂商就可以通过容器镜像的方式交付容器化 的虚拟清洗设备，而当出现突发恶意流量时，可通过编排系统在空闲的服务器中动态横向扩展启动足够 多的清洗设备，从而可应对处理能力不够的场景。这时，DDoS 清洗机制是云原生的，但其防护的业务 系统有可能是传统的。
云原生安全融合的安全
虽然我们形式上将云原生安全分为了两类安全技术路线，但事实上，如果要做好云原生安全，则必 然需要使用“具有云原生特性的安全”技术去实现“面向云原生环境的安全”，因而两者是互相融合的。 让我们继续以 DDoS威胁为例，一方面可用性是整个云原生系统中重要的安全属性，无论是宿主机、 容器，还是微服务、无服务业务系统，都需要保证其可用性；另一方面，在云原生系统中要实现可用性， 在物理边界侧要构建按需、弹性的 DDoS 缓解能力，在容器、微服务边界侧部署虚拟、弹性的 DDoS 机 制，这就需要云原生的安全能力。两者相辅相成，缺一不可。
小结
要实现云原生安全，就需要首先评估云原生系统中的安全风险和相关威胁，设计具有针对性的安全 机制；在此过程中，云原生系统的固有业务特点，就要求安全厂商现有的安全能力云原生化。目前可预 见的是，安全能力的云原生化，绝不是简单的将原有安全设备虚拟化或容器化，而是要按照部署要求进 行容器化，按照性能要求进行轻量化，按照功能进行拆分、微服务化，最后实现弹性、敏捷、轻量级等 特性。
安全问题成为影响云原生落地的重要因素
安全问题成为影响云原生落地的重要因素 从各种各样的安全风险中可以一窥云原生技术的安全态势，云原生环境仍然存在许多安全问题亟待 解决。在云原生技术的落地过程中，安全是必须要考虑的重要因素。
服务暴露
服务暴露的问题，我们在 2018 年的报告 [2]中就已经详细进行了分析，这里再简单做一下回顾。我 们利用网络空间搜索引擎 Shodan 对 2020 年 10 月份某天暴露 2375 端口的 Docker Daemon 服务进行 了分析，发现仍然有约 4800 个 Docker Daemon 对外暴露 2375 端口，其中部分是没有设置访问认证的， 可以直接与之交互。 图 2.1 部分暴露 2375 端口且无访问认证的主机 另外，我们也对同时期 Kubernetes Dashboard 在互联网上的暴露情况进行了统计，发现仍有约 1200 个 Kubernetes Dashboard 服务暴露在互联网上。其中也仍存在不需要认证即可登录的情况。这种 端口暴露是非常危险的。 图 2.2 一个对外暴露端口且无访问认证的 Kubernetes Dashboard 服务
数据泄露
数据泄露在云原生中仍然是重要的安全威胁。以亚马逊的对象存储服务 Amazon S3 为例，其在云 原生中也得到了应用 [3]，然而，S3 数据泄露事件被屡屡曝光，不胜枚举 [4][5]。 在上述众多数据泄露事件中，绝大多数是 S3 存储桶的公开访问，有的事件涉及 S3 被设置为允许任 何 AWS登录用户访问，甚至一个医疗数据泄露事件的相关存储桶竟然被设置为了任何人均可读写，这 是不可想象的。
恶意挖矿攻击
特斯拉 Kubernetes 挖矿事件
2018 年 2 月 20 日，云安全公司 RedLock 发文披露 [6]，特斯拉的 Kubernetes 集群曾在数月前被入侵， 黑客在其中部署了挖矿程序。据报道，入侵的直接原因是，其 Kubernetes 集群的 Dashboard 处于未授!
权即可访问状态，且暴露在互联网上。
对于一个 Kubernetes 集群来说，控制 Kubernetes Dashboard 意味着能够直接向集群下达指令，严 重情况下攻击者甚至能够逃逸出容器，进而轻易控制集群所有宿主机节点，其风险等同于甚至超过域沦 陷，却往往得不到相应的重视。
微软监测到大规模 Kubernetes 挖矿事件
2020 年 4 月 8 日，微软 Azure 安全中心发布博文称，检测到大规模 Kubernetes 挖矿事件 [7]。2020 年 6 月 10 日，微软 Azure 安全中心再次发布文章，警告滥用 Kubeflow 的大规模挖矿事件 [8]。两起事 件的曝光日期如此接近，说明以 Kubernetes 为代表的云原生系统很可能正在成为不法分子赖以牟利的
新渠道。
针对 Kubeflow 的攻击事件，影响了数十个 Kubernetes 集群，通常用于机器学习的 Kubernetes 集 群各节点的算力会比普通服务器要强大许多，这些算力同样能够被攻击者所用，为挖矿带来显著增益。
事实上，容器环境下的恶意挖矿并不新鲜，挖矿活动一般发生在脆弱容器中。例如，黑客利用容器 内部运行有漏洞 Web 的应用程序，获得容器控制权，进而部署挖矿程序。
Graboid蠕虫挖矿传播事件
2019 年 10 月 15 日，Unit 42 安全团队发现了一款新型挖矿蠕虫 [9]，命名为 Graboid（大地虫）， 该蠕虫的挖矿产出是门罗币（Monero），被发现时，它已经传播到了超过 2000 台不安全的 Docker 宿 主机上。这是安全研究者第一次发现借助 Docker 容器进行挖矿和传播的蠕虫。
本次事件中，攻击者首先通过不安全的 Docker 守护进程暴露出来的远程端口获得对目标主机的控 制权，然后下达指令从 Docker Hub 上拉取（pull）并运行实现上传的恶意镜像。由于传统终端防护机制（AV、 EDR）并不能很好地审计容器内部的行为和数据，故很难检测出这类恶意行为。
我们必须认真对待云原生环境下的蠕虫传播事件。相比传统内网环境，云原生集群环境下各节点之 间具有更强的关联性。例如，在 Kubernetes 集群内，一旦蠕虫获得了 API Server 的控制权限，就能够
在非常短的时间内感染整个集群，并能利用编排技术持久化恶意代码，后果不堪设想。
