云原生背景下的应用安全建设

文章首发于：

火线 Zone 社区（https://zone.huoxian.cn/）

大家好，我是徐越，今天分享云原生安全这个话题，云原生安全这个话题其实太大了，我之前所做的一些研究成果，主要是在应用层，所以我们今天讨论的重点就围绕着云原生的应用安全。

第一块：云原生的应用安全目前发展到一个什么进度，以及未来它会向哪些方向去延伸。

第二块：我们做技术的是怎么样去入门？

我是从 17 年开始进入到一线的云厂商，做云安全产品以及安全研究相关的工作。之前关于云原生领域的研究成果，从主机安全到 Web 安全，到容器安全，这些可以在我的博客上找到。https://cdxy.me/about

议题主要分为四个大部分：

第一部分：云安全现在发展到一个什么样的阶段，我们作为一个安全从业者怎么看待这件事情，我们要不要投入云安全研究？

第二、三部分：从红队和蓝队两个视角去介绍云安全的技术发展，目前都涉及到的技术栈是什么？做这些研究所需要的能力是什么？

第四部分：云安全的入坑建议。

第一部分，首先就是云安全是什么？云安全对于整个安全行业，或者对于我们每一个技术人来讲，我们到底怎么看待这个事情？我们要不要把它当做我们工作的主要方向去做，这个背后的根本逻辑是什么？

首先整个网络安全行业，它是有很多驱动力在的，其中我认为最强也是周期最长的一个驱动力，就是 IT 基础设施的发展。也就是说安全一定是跟随着基础设施架构发展去不断演进的。

那么现在基础设施发展的趋势是什么？就是万物互联，我们之前讲的，比如早期的边界防御到后面的纵深防御，再到现在我们发现所有的大型企业级应用，基本上都能看到非常多的云边端的互联，云又分为私有云、公有云，包括云上的 SaaS 服务等几个方面。

我们现在看到一个企业级的应用。他其实把非常多的基础设施和能力连接了起来，比如公有云的 IaaS 层，以及私有云的 IaaS 层，VM 或者容器等等这些基础设施，包括云上的所有 SaaS 化的服务，包括企业的应用有可能会跟终端，比如手机端的这些 APP，智能汽车里面内置的 APP，边缘计算以及传统的企业的 IDS，企业内部的办公，以及很多这种 PaaS 平台对第三方合作伙伴或者开发者开放的一些能力。

在万物互联的背景下，边界这个概念在逐渐地弱化，资产的攻击面是越来越多的，那么想做好安全这件事情，其实就是要求每一块安全能力要不断的去细化，下沉到基础设施层。

那么我们看到在这里面，云安全只是万物互联的 IT 基础设施发展下的，只是大趋势里面的一部分，那我们仅讨论云安全这个话题，目前云安全有什么问题，这里面我主要总结出来三点，也是目前业内无论是创业市场，还是安全研究领域比较关注的几个方向。

第一块就是 laaS 层，也就是基础设施层的挑战，那这一块，就一定是说传统的 VM 向容器化，以及微服务化去发展。

其实业内的话，容器目前已经非常大规模的在各行各业去落地，那么在基础上我们发现其实安全是滞后的，那这里面就为攻击者创造了一段时间的研究空间，以及为防守者提出了一个新的挑战。

第二块就是 SaaS 层，SaaS 层把能力作为软件形式交付，SaaS 的应用分为两种，一种是对人的，就是后端用 API 来做，前端再套一个 UI 界面，这样子去做它最终的一个交付。还有一种就是对机器的，比如说今天我开发一个 APP，可能我需要集成很多的地图功能或者其他功能，那么传统可能需要去买，需要去集成，今天的话，其实只要调一下云上的这些 API，做一个付费就可以集成这块能力。

那 SaaS 挑战主要就是越来越多的企业能力以 API 的形式进行开放和交付，这里面就会涉及 API 的安全保护问题。

第三块，就是分布式的安全协同问题，也就是企业的基础设施进行了一个大规模的分布式之后，我们怎么保证网络侧的统一性、接入的有效性、效率、所有的安全策略、以及安全运维在不同的基础架构之下的一个协同。主要目前来讲看到的这几个趋势，以及目前研究比较火的几个领域，基本就是在这里。

从红队的角度来讲，红队现在是一个什么样的研究状态？

我们发现红队对容器化的讨论会稍微多一点，从 2020 年微软先发表了一个 kubernetes 的 ATT&CK，其实阐述了新的 IT 基础设施架构下，尤其是 kubernetes 和容器的架构下，和传统的 VM 的攻击思路有哪些不一样。从那个时候开始，我们看到大量的云厂商、安全厂商，企业的甲方，都开始投入云原生的安全研究，包括很多的大厂建立了专门的云原生的红队。

上图是在 2020 年，我在云厂商的时候，做了一版更细致的所有攻击的一些描述，又添加了一些针对云平台的攻击手段。

接着在 2021 年的云鼎这边提出的云安全攻防矩阵，是在此之上进行了又一次的丰富，这里面我们其实可以看到它已经区分出来了整个云的基础设施，包括云服务器的攻击方式，也就是传统 Linux 或者 Windows 的 server；然后是容器这一块，比如说这个 docker 和 kubernetes，以及容器的一些镜像仓库，还有其他的一些中间件和基础设施的攻击方式；然后是云服务这一块，比如我们现在看到被攻击比较多的云存储，可能经常会出现这种权限问题，泄露数据的一些问题，包括一些云平台本身的账户泄露，或者云平台的 API 入侵等等。

那么我觉得入门云安全的话，从攻击者的视角来讲，看到所有的这些工具技术，去理解掌握这里面所有的攻击模式，就能够对云安全里面应用层、基础设施层的安全攻击手段有一个宏观的了解，大概就能够知道云安全我们到底在讨论哪些技术，这个是从红队视角去讲。

那么我们细节一点，云安全具体带来哪些新的攻击面？主要是右边我们所讲的这三块，第一块就是新的基础设施，像 k8s 或者 serverless function，以及现在我们讲的这个 mesh 架构，它的一些基础设施的漏洞，以及在他上面所生长的一些应用中存在的应用漏洞。

然后第二块，就是云平台本身，那云平台的话，其实历史上我们也看到出现过很多问题，其实大部分都是由于这个凭证泄露，然后去通过一些比如说云助手，一些 API 的通道，去操纵这个云账号或者云资产导致的一些安全问题。然后第三块就是云服务的一些 API，比如说云的存储，云的计算，然后云的认证，以及其它的很多第三方的能力输出，这里面还是之前说的，一方面是 API 加 UI，另外一方面就是直接的 API 攻击，这一块造成的危害也是很大的，之前我们看到出了很多，这种云存储导致企业数据泄露的情况。针对这几种攻击面变化的这些工具，我在上面列出来，就是这个小字里面，这里面都是 github 上的一些开源项目，入门的话可以去参考一下他们覆盖了哪些攻击点，以及实现攻击的逻辑。

讲到云安全最主要的一个场景，就不得不说容器这一块。我左边那个图画了一部分攻击场景。主要包括攻击者对于容器的基础设施，以及对于这种 SaaS 化的云上的应用，以及云上服务基础设施的这些攻击路径。这里我们可以去稍微的理解一下，这个入口点，以及这个提权逻辑，以及这个持久化逻辑，以及窃取数据逻辑，可能会跟传统的 Linux 或者 Windows 的攻击的路径会有一些差异，也是说这两年来我们看到越来越多的红队开始这方面的武器化研究。

接下来如果说我们想做这个云原生的，再往深入一点，就是想做到 IaaS 层的安全的话，其实它是一个比较困难的话题。这个其实我们包括之前我在做这一块安全的时候，也和其他的一些容器安全相关的一些厂商去交流过，就是这块的研究为什么会有一定的门槛，就在于它其实是多种技术能力的融合。比如说你首先要懂 Linux，然后还要懂这个虚拟化，比如说 docker 或者 k8s 的一个架构和原理，然后当然你还要有一个攻防的思维。这个是三种能力的结合，导致你可以在这一块做漏洞挖掘，或者做一些安全方案性的建设。

我们举一个例子是一个老漏洞，这个漏洞，其实是一个公开的东西，包括 Exp 也是公开的。为什么要提这个事情？

其实是给大家体会一下做这个漏洞的攻击和复现的时候，我们会涉及到多少个知识面。首先左边这一块是官方的一个漏洞描述，我们看到这些名词，首先就是这些名词是否理解，这个 containerd，然后这个 shim，runc，unix socket，包括这个后面的一些通讯协议这一块，我们有没有这个基础知识，能不能做这件事情，包括后面的 Exp 怎么写。

这里面所有的这些概念其实都是要去研究，都是要去积累的，然后在此基础上，我们才能去做这个 IaaS 层的漏洞的一些分析工作。

从原理上来讲，首先就是说这里面会分为几层，就比如首先从这个 k8s 层，通过 containerd 去做这个容器的管理，后面又抽象了一层，能力的接口用作这个 shim，然后后面整个虚线框起来的这个东西，其实就是每一个容器，它所处理的，在 Linux 体系里面所存在的一个进程的关系。其实容器逃逸它本质上就是一个 Linux 隔离的问题，就是一个低权限的进程，我怎么能做到变成一个高权限的进程。

那这里首先你得在这个 Linux 这个维度能够非常清楚地了解，就 Linux 的一些权限隔离机制，比如说 Linux Namespaces 和 Capabilities 这几个东西是怎么实现的，然后才能去理解这个漏洞的一个利用原理。在编写 Exp 的过程中，你还要对 containerd，或者说这个整个 k8s、docker 的这个细节到源码级的功能要有一个了解，比如说这个漏洞挖掘者，他所提出来的一个 Exp 的思路，就是通过 shim 这个高权限进程共享网络空间的时候，可以直接通过一个低权限操纵这个高权限进程，然后控制它再起个容器，再起一个容器的过程中，我们给它更高的一个权限，然后再通过这个容器内部去操纵宿主机资源，最后拿到宿主机 shell。

这个流程其实是一个非常通用的容器逃逸流程。但是如果你做过 OCI 研发，或者看过这一块文档的时候，其实你可以提出一个更方便的方法，就比如说左下角这个图，其实 OCI 它提供了非常多的 hook，就在容器的启动过程中，这个 hook 里面有一个 prestart，这里面直接可以反弹 shell，在起容器的过程中，甚至这个容器都不用真正的跑起来，它就可以直接 bash 命令直接执行。

这个 Exp 我们也是收录在那个 CDK 的右边那个链接里面，觉得有兴趣的同学或者有一定积累的同学可以研究一下，大概也就能理解做 IaaS 层的漏洞研究和挖掘需要哪些积累，这是一个例子。

然后针对入门路径，挖洞的话我们大家可以从这一块入手，挖洞这个东西我不太建议大家上来一下子就要挑战特别难的一个目标，比如说我要搞一个 k8s RCE 出来，我们再 CNCF 的 landscape 图里面可以看到现在整个云原生的生态体系，已经衍生出了非常多的应用和中间件。那这里面其实我还是建议如果入门的话，我们先挑一些自己跳一下能够得到的目标，一步一步地循序渐进的，从简单到难去实现这一块的研究。

挖洞这里面其实有一个我觉得比较好出洞的一个思路，就是说多组件安全的设计不一致。这个思路其实在 orange 之前的几次 blackhat 演讲里面体现的很明显，就是说我单个组件拎出来是没有问题的，但是多个组件针对一种协议，一种规范，它的实现里面是有不一致的点，那么我考虑整个应用流程过程中，其实多个组件它拼凑在一起的时候，这些不一致的点，有可能就会成为漏洞的起因。

这里有一个有意思的案例，我在下面也放了链接。我们做红队或者漏洞这块的研究，它本质上还是一个积累的过程，如果我们对整个云原生的生态体系，包括组件，研究的特别细致的话，其实这里面的漏洞还是很多的，相比你直接去挖这个 Linux 和 Windows 漏洞来讲的话，这一块仍然是一个蓝海。

上面是红队这一块，然后蓝队这一块，也就是说企业从防守方的角度去考虑，怎么去建设云原生这一块的安全体系。

首先第一块蓝队应该注意的，安全责任区这里是有个变化的，那我们看到现在的基础设施，从左边的传统的虚拟机上面直接跑 APP，然后到现在的虚拟机容器 APP，再往后容器都已经 on demand，包括到后面的 serverless，底层的这些东西已经被云厂商或者云服务提供商默认的做安全掉了，就是图里面这个灰色的部分。

图里面这个浅蓝色的部分，其实是一个云厂商和用云计算的企业共担的一个责任区，那么深蓝色的部分，就是企业主要去负责去建设的一块安全的责任区，其实我们看到不断的往后去发展，IaaS 基础设施的服务化程度越严重，其实企业在里面需要解决的安全问题是越来越少的，所以我们为什么说云其实是在某种程度上来讲是更安全的，就是这个道理。

然后就目前来讲，针对大量应用上云的企业，我们看到了一些明显攻击的趋势，就目前来讲，对云平台以及容器基础设施的攻击已经非常广泛了。这不是一个新的话题，而是说现在所有的这些公网上的这些蠕虫也好，僵尸网络也好，都默认集成了这些关于容器，关于 K8S 的一些攻击手段，如果说一些比较 low 的漏洞，可能你开到网上瞬间就被入侵。

第二块就是刚才我所讲的这个趋势，基础设施层会由云厂商去默认地做到安全。在此基础上业务层的东西更是企业需要解决的一个问题，比如说靠近人的东西，其实它是永远不会消亡的一个安全话题，包括人员的行为管控、鉴权以及凭证泄露导致的一些安全问题。

另一方面应用安全也不会消失，就是包括所有的云的基础设施上面跑的企业应用代码，所有应用层和业务层的安全，它跟以前是一样的，它会一直存在，比如说 web 领域，包括这个应用中间件，应用组件漏洞，以及一些供应链的风险，这个是一向存在的。那么在这一块云平台厂商默认做安全的策略之下，其实还是刚才讲的这三个方向是企业需要关注的一个重点。比如现在我们看到这个容器安全，k8s 安全，API 安全，以及分布式的安全协同，分布式安全协同这个词是我造的，包括现在我们看到的 XDR、CSPM、SASE，或者零信任等等，其实它本质上解决的就是一个大规模分布式架构下的安全协同问题。

另一方面，咱们这边有在甲方或者在企业侧做蓝队的同学可能除了技术之外，还会遇到一些其他方面的挑战，比如说安全部门在做一些基建，在做一些安全策略的时候，可能会跟业务方出现冲突，或者说我们没有拿到足够多的预算，足够多的资源去实现一个整体的安全水位的提升。

那这里面我们考虑更深一层的问题，在甲方去做这个安全建设，一定会遇到一个资源问题。资源问题背后的其实是安全团队的一个定位问题，也就是说我们做安全建设总提到一句老话叫“出了事儿要你何用，没出事儿要你何用”。其实这个本质背后是一个定位的问题，如果说我们能够把这个安全与业务的对立的关系转化成合作的关系，也就是说把安全部门的一个定位，从保障业务到赋能业务做一个转化的话。

其实就可以去为安全部门，或者说为安全研究带来更多的资源，就能够保障更多的技术同学，他有一个很好的环境去研究云安全领域或者新兴的一些安全的技术。这里其实对于一线的甲方从业者，我是建议大家要跳出安全攻防思维的模式，多去接触业务，就可以实现从保障到赋能业务的安全部门定位的转化。

然后从防御角度来讲，现在的基础设施布防其实业内也有非常多的成熟的产品能够去做，比如说传统的南北向的防火墙，包括镜像查杀，各种 Node 级别的，也就是 VM 级别的 EDR，也可以适配容器环境的一些入侵场景，比如说进程、网络、文件运行时的一些监控，包括整个 k8s 这一块的应用日志的审计，以及云的 SaaS 服务的一些配置检查，多云的安全协同管控，以及一些 API 的审计。

这些方面目前从蓝队角度来讲，其实在头部的一些厂商已经开始有动作，开始着手针对新的基础设施架构做完整的安全建设。

此外再提一点，就是蓝队这块除了攻防思维之外，我比较建议大家学一下数据分析。因为现在企业防御的一些困境，也就是大家都知道的一个现状，就是资产永远是摸不清的，漏洞永远是修不完的，安全设备布得越来越多，可能一个服务器里面，现在已经布了四五个 agent，可能一个交换机里面已经接了十个八个的网络流量分析设备，那运营成本也是越来越高的。

从企业的投入产出比的角度来考虑，其实现在这个甲方的安全从业者或者蓝军，更需要思考的是如何把安全这件事情流程化、数据化和智能化地建设起来，从而系统地去降低运营成本。那这个数据驱动安全这个逻辑其实很早在我之前那些分享里面也是提到过无数遍，包括现在一些网络上比较火的安全的新概念，新的产品方向，其实从数据角度来讲，把不同的日志怎么去采，怎么去关联分析，最终产出什么样的一个价值。照着这个逻辑也可以理出来所有安全产品和方案的一个发展路线。

第四块就是一个云安全的入门建议，作为技术人员大家应该更多的是关注技术这一块的成长。我大体将技术人员的成长分为两种路线。一种是纯研究型的路线，另一种是跟业务相关的，跟企业安全建设相关的业务路线。我个人走的其实是业务型的路线，今天也着重说一下这条路线。

这个图是之前从一位投资人那边看到的，我又改了一下，基本上我看到身边很多的安全技术出身的人，他的发展路线是这个样子。首先我们可能在学校的时候，或者在学习安全这件事情的时候，攻击是一个很 fancy 的事情，刚开始的时候我们拿到一个别人写好的 Exp 打下来了某些站，到后来我们能够自己去写 Exp，一直到我们能够自己去挖漏洞。

做攻击，不断的去突破限制，其实是一个非常爽的事情，也是很多人喜欢上做安全技术的一个理由。那么如果再往上走一层的话，如果我们要去做整体的安全解决方案，或者说在甲方去做安全的一个建设的话，其实不仅要有攻击思维，他还要全面的去了解公司的 IT 架构以及业务。

因为不同的场景，用的基础设施不一样，包括几朵云里面，它对容器化、虚拟化这一件事情各家厂商的架构都是有差别的。那我们怎么能够结合我们自己的业务需求，以及怎么结合公司现有 IT 架构去做一个投入比较低，但是效果比较好的这样一个整体的方案，然后不断的去推进安全水位的提升，这是防御角度需要具备的能力。

再往后，就是如何把我们的技术能力通过复用来转化更多价值，让我们付出一份时间，让这份时间能够复制。这一块就涉及到产品化，如果我们要在安全角度做创业，或者我们要把在企业内部建设出来的能力去完成商化的话，其实还需要有市场化和企业化这两块的思维。

今天主要针对攻击和防御这两个点我列了几个入门建议，也是我一路学下来遵守的几个原则，第一块就是多看官方文档，少看中文材料，少看 CSDN。这个是一定的，因为我发现看二手的信息确实能够把这个东西跑起来，但是你根本接触不到它背后所包含的优雅的设计逻辑。哪怕是文档上面，就是跟代码无关的文档表达，其实国内外的差别还是很大的，所以建议有能力的同学尽可能的去阅读一下原始的官方文档。

第二点，很多同学可能在入门的时候都会先拿别人的 Exp 过来跑一跑，或者别人的扫描器挖一挖漏洞，刷一刷 SRC。但是如果后面想要长期发展的话，还是要有研究的深度，这一块的建议就是多看项目源码，像之前在容器研究中大概我也把这些像 containerd、k8s，包括 docker 的一些 OCI 的其他一些东西的源码都是看了一遍，然后才去做这方面的研究和漏洞复现，还有一些 Exp 的工作。

如果说我们源码阅读积累到了一定量的话，其实你对一些它本身的设计模式就会有个了解，那么有一天，你突然来了一个 idea，然后你大脑中其实是有一个数据库，或者有一个决策树的，你就会知道这一个攻击场景在哪些安全的设计理念或者设计模式里，它一定会有冲突，这样就是一个漏洞产生的原因。

第三点就是看别人挖漏洞，复现漏洞的同时，要再往深想一层。单纯把这个漏洞看懂，然后感叹一句，哇他的脑洞真大，其实这个是没有用的。漏洞看多了之后，你能够发现每一个优秀的漏洞研究员挖洞是有一些固定模式的，你看到漏洞原理之后，再往深问一层，他为什么能发现这个漏洞。这个问题问多了之后，可能我们就可以抽象出一些非常基础的挖洞模式出来，然后再把这个模式批量的去复用到你脑海里积累的场景，你就可以批量去产出同类漏洞。

最后一点，就是业余时间研究它永远不如直接从事这块的工作接触的信息量以及视野更大。所以说对于入门来讲，最好还是能够找到一个工作中的实际战场，就是把兴趣和工作结合在一个高强度高效率的环境去不断的磨练自己。

这四点就是针对云安全领域技术入门，或者说漏洞挖掘领域技术入门的一个建议，然后因为时间有限，所以我大体上今天只是做一个综述性质的表达，后面的话，关于整个云安全这一块，包括应用安全，或者职业发展这一块，也欢迎去做一个深入的交流。