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

本文涉及的产品
Web应用防火墙 3.0,每月20元额度 3个月
云安全中心漏洞修复资源包免费试用,100次1年
容器服务 Serverless 版 ACK Serverless,952元额度 多规格
简介: 云原生安全这个话题其实太大了,我之前所做的一些研究成果,主要是在应用层,所以我们今天讨论的重点就围绕着云原生的应用安全。

文章首发于:火线Zone社区

作者:徐越

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

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

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

image.png

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

image.png

议题主要分为四个大部分

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

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

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

image.png

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

image.png

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

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

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

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

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

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

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

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

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

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

image.png

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

image.png

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

image.png

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

image.png

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

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

image.png

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

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

image.png

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

image.png

我们举一个例子是一个老漏洞,这个漏洞,其实是一个公开的东西,包括Exp也是公开的。为什么要提这个事情?其实是给大家体会一下做这个漏洞的攻击和复现的时候,我们会涉及到多少个知识面。首先左边这一块是官方的一个漏洞描述,我们看到这些名词,首先就是这些名词是否理解,这个containerd,然后这个shim,runc,unix socket,包括这个后面的一些通讯协议这一块,我们有没有这个基础知识,能不能做这件事情,包括后面的Exp怎么写。这里面所有的这些概念其实都是要去研究,都是要去积累的,然后在此基础上,我们才能去做这个IaaS层的漏洞的一些分析工作。

image.png

从原理上来讲,首先就是说这里面会分为几层,就比如首先从这个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层的漏洞研究和挖掘需要哪些积累,这是一个例子。

image.png

然后针对入门路径,挖洞的话我们大家可以从这一块入手,挖洞这个东西我不太建议大家上来一下子就要挑战特别难的一个目标,比如说我要搞一个 k8s RCE出来,我们再CNCF的landscape图里面可以看到现在整个云原生的生态体系,已经衍生出了非常多的应用和中间件。那这里面其实我还是建议如果入门的话,我们先挑一些自己跳一下能够得到的目标,一步一步地循序渐进的,从简单到难去实现这一块的研究。挖洞这里面其实有一个我觉得比较好出洞的一个思路,就是说多组件安全的设计不一致。这个思路其实在orange之前的几次blackhat演讲里面体现的很明显,就是说我单个组件拎出来是没有问题的,但是多个组件针对一种协议,一种规范,它的实现里面是有不一致的点,那么我考虑整个应用流程过程中,其实多个组件它拼凑在一起的时候,这些不一致的点,有可能就会成为漏洞的起因。这里有一个有意思的案例,我在下面也放了链接。我们做红队或者漏洞这块的研究,它本质上还是一个积累的过程,如果我们对整个云原生的生态体系,包括组件,研究的特别细致的话,其实这里面的漏洞还是很多的,相比你直接去挖这个Linux和Windows漏洞来讲的话,这一块仍然是一个蓝海。

image.png

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

image.png

首先第一块蓝队应该注意的,安全责任区这里是有个变化的,那我们看到现在的基础设施,从左边的传统的虚拟机上面直接跑APP,然后到现在的虚拟机容器APP,再往后容器都已经on demand,包括到后面的serverless,底层的这些东西已经被云厂商或者云服务提供商默认的做安全掉了,就是图里面这个灰色的部分。图里面这个浅蓝色的部分,其实是一个云厂商和用云计算的企业共担的一个责任区,那么深蓝色的部分,就是企业主要去负责去建设的一块安全的责任区,其实我们看到不断的往后去发展,IaaS基础设施的服务化程度越严重,其实企业在里面需要解决的安全问题是越来越少的,所以我们为什么说云其实是在某种程度上来讲是更安全的,就是这个道理。

image.png

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

第二块就是刚才我所讲的这个趋势,基础设施层会由云厂商去默认地做到安全。在此基础上业务层的东西更是企业需要解决的一个问题,比如说靠近人的东西,其实它是永远不会消亡的一个安全话题,包括人员的行为管控、鉴权以及凭证泄露导致的一些安全问题。另一方面应用安全也不会消失,就是包括所有的云的基础设施上面跑的企业应用代码,所有应用层和业务层的安全,它跟以前是一样的,它会一直存在,比如说web领域,包括这个应用中间件,应用组件漏洞,以及一些供应链的风险,这个是一向存在的。那么在这一块云平台厂商默认做安全的策略之下,其实还是刚才讲的这三个方向是企业需要关注的一个重点。比如现在我们看到这个容器安全,k8s安全,API安全,以及分布式的安全协同,分布式安全协同这个词是我造的,包括现在我们看到的XDR、CSPM、SASE,或者零信任等等,其实它本质上解决的就是一个大规模分布式架构下的安全协同问题。另一方面,咱们这边有在甲方或者在企业侧做蓝队的同学可能除了技术之外,还会遇到一些其他方面的挑战,比如说安全部门在做一些基建,在做一些安全策略的时候,可能会跟业务方出现冲突,或者说我们没有拿到足够多的预算,足够多的资源去实现一个整体的安全水位的提升。那这里面我们考虑更深一层的问题,在甲方去做这个安全建设,一定会遇到一个资源问题。资源问题背后的其实是安全团队的一个定位问题,也就是说我们做安全建设总提到一句老话叫“出了事儿要你何用,没出事儿要你何用”。其实这个本质背后是一个定位的问题,如果说我们能够把这个安全与业务的对立的关系转化成合作的关系,也就是说把安全部门的一个定位,从保障业务到赋能业务做一个转化的话。其实就可以去为安全部门,或者说为安全研究带来更多的资源,就能够保障更多的技术同学,他有一个很好的环境去研究云安全领域或者新兴的一些安全的技术。这里其实对于一线的甲方从业者,我是建议大家要跳出安全攻防思维的模式,多去接触业务,就可以实现从保障到赋能业务的安全部门定位的转化。

image.png

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

image.png

此外再提一点,就是蓝队这块除了攻防思维之外,我比较建议大家学一下数据分析。因为现在企业防御的一些困境,也就是大家都知道的一个现状,就是资产永远是摸不清的,漏洞永远是修不完的,安全设备布得越来越多,可能一个服务器里面,现在已经布了四五个agent,可能一个交换机里面已经接了十个八个的网络流量分析设备,那运营成本也是越来越高的。从企业的投入产出比的角度来考虑,其实现在这个甲方的安全从业者或者蓝军,更需要思考的是如何把安全这件事情流程化、数据化和智能化地建设起来,从而系统地去降低运营成本。那这个数据驱动安全这个逻辑其实很早在我之前那些分享里面也是提到过无数遍,包括现在一些网络上比较火的安全的新概念,新的产品方向,其实从数据角度来讲,把不同的日志怎么去采,怎么去关联分析,最终产出什么样的一个价值。照着这个逻辑也可以理出来所有安全产品和方案的一个发展路线。

image.png

第四块就是一个云安全的入门建议,作为技术人员大家应该更多的是关注技术这一块的成长。我大体将技术人员的成长分为两种路线。一种是纯研究型的路线,另一种是跟业务相关的,跟企业安全建设相关的业务路线。我个人走的其实是业务型的路线,今天也着重说一下这条路线。这个图是之前从一位投资人那边看到的,我又改了一下,基本上我看到身边很多的安全技术出身的人,他的发展路线是这个样子。首先我们可能在学校的时候,或者在学习安全这件事情的时候,攻击是一个很fancy的事情,刚开始的时候我们拿到一个别人写好的Exp打下来了某些站,到后来我们能够自己去写Exp,一直到我们能够自己去挖漏洞。做攻击,不断的去突破限制,其实是一个非常爽的事情,也是很多人喜欢上做安全技术的一个理由。那么如果再往上走一层的话,如果我们要去做整体的安全解决方案,或者说在甲方去做安全的一个建设的话,其实不仅要有攻击思维,他还要全面的去了解公司的IT架构以及业务。因为不同的场景,用的基础设施不一样,包括几朵云里面,它对容器化、虚拟化这一件事情各家厂商的架构都是有差别的。那我们怎么能够结合我们自己的业务需求,以及怎么结合公司现有IT架构去做一个投入比较低,但是效果比较好的这样一个整体的方案,然后不断的去推进安全水位的提升,这是防御角度需要具备的能力。再往后,就是如何把我们的技术能力通过复用来转化更多价值,让我们付出一份时间,让这份时间能够复制。这一块就涉及到产品化,如果我们要在安全角度做创业,或者我们要把在企业内部建设出来的能力去完成商化的话,其实还需要有市场化和企业化这两块的思维。

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

第二点,很多同学可能在入门的时候都会先拿别人的Exp过来跑一跑,或者别人的扫描器挖一挖漏洞,刷一刷SRC。但是如果后面想要长期发展的话,还是要有研究的深度,这一块的建议就是多看项目源码,像之前在容器研究中大概我也把这些像containerd、k8s,包括docker的一些OCI的其他一些东西的源码都是看了一遍,然后才去做这方面的研究和漏洞复现,还有一些Exp的工作。如果说我们源码阅读积累到了一定量的话,其实你对一些它本身的设计模式就会有个了解,那么有一天,你突然来了一个idea,然后你大脑中其实是有一个数据库,或者有一个决策树的,你就会知道这一个攻击场景在哪些安全的设计理念或者设计模式里,它一定会有冲突,这样就是一个漏洞产生的原因。

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

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

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

相关实践学习
通过Ingress进行灰度发布
本场景您将运行一个简单的应用,部署一个新的应用用于新的发布,并通过Ingress能力实现灰度发布。
容器应用与集群管理
欢迎来到《容器应用与集群管理》课程,本课程是“云原生容器Clouder认证“系列中的第二阶段。课程将向您介绍与容器集群相关的概念和技术,这些概念和技术可以帮助您了解阿里云容器服务ACK/ACK Serverless的使用。同时,本课程也会向您介绍可以采取的工具、方法和可操作步骤,以帮助您了解如何基于容器服务ACK Serverless构建和管理企业级应用。 学习完本课程后,您将能够: 掌握容器集群、容器编排的基本概念 掌握Kubernetes的基础概念及核心思想 掌握阿里云容器服务ACK/ACK Serverless概念及使用方法 基于容器服务ACK Serverless搭建和管理企业级网站应用
相关文章
|
6月前
|
边缘计算 Cloud Native 数据管理
【阿里云云原生专栏】云原生背景下的AIoT布局:阿里云Link平台解析
【5月更文挑战第29天】阿里云Link平台,作为阿里云在AIoT领域的核心战略,借助云原生技术,为开发者打造一站式物联网服务平台。平台支持多协议设备接入与标准化管理,提供高效数据存储、分析及可视化,集成边缘计算实现低延时智能分析。通过实例代码展示,平台简化设备接入,助力智能家居等领域的创新应用,赋能开发者构建智能生态系统。
180 3
|
消息中间件 存储 运维
《云计算加速开源创新》——云原生背景下消息领域的一次重新定义(下)
《云计算加速开源创新》——云原生背景下消息领域的一次重新定义(下)
|
数据可视化 Cloud Native 大数据
带你读《企业级云原生白皮书项目实战》——5.4.1 背景
带你读《企业级云原生白皮书项目实战》——5.4.1 背景
165 0
|
机器学习/深度学习 存储 人工智能
带你读《企业级云原生白皮书项目实战》——6.1.1背景
带你读《企业级云原生白皮书项目实战》——6.1.1背景
138 0
|
消息中间件 Cloud Native RocketMQ
带你读《企业级云原生白皮书项目实战》——6.3.1 行业背景
带你读《企业级云原生白皮书项目实战》——6.3.1 行业背景
122 0
|
消息中间件 缓存 Cloud Native
《云计算加速开源创新》——云原生背景下消息领域的一次重新定义(上)
《云计算加速开源创新》——云原生背景下消息领域的一次重新定义(上)
|
Cloud Native Nacos 微服务
《Nacos 启航,发布第一个版本, 云原生时代助力用户微服务平台建设》电子版地址
Nacos 启航,发布第一个版本, 云原生时代助力用户微服务平台建设
127 0
《Nacos 启航,发布第一个版本, 云原生时代助力用户微服务平台建设》电子版地址
|
消息中间件 存储 缓存
2022云栖精选—云原生背景下消息领域的一次重新定义
林清山 阿里云消息负责人 & Apache RocketMQ联合创始人
208 0
2022云栖精选—云原生背景下消息领域的一次重新定义
|
运维 自然语言处理 安全
阿里云解决方案架构师张平:云原生数字化安全生产的体系建设
企业要做安全生产建设的话,核心分为两大部分:一部分是技术体系建设,一部分是服务体系建设。
阿里云解决方案架构师张平:云原生数字化安全生产的体系建设
|
监控 Cloud Native Java
[ 云原生之谜 ] 云原生背景 && 定义 && 相关技术详解?
随着云计算概念的普及,云原生一次也慢慢浮现在人们的眼前,不论是安全还是应用,只要和云计算相关,好像都会加上原生二字。那到底什么是云原生呢?
525 0
[ 云原生之谜 ] 云原生背景 && 定义 && 相关技术详解?