「守护云原生安全构建企业安全“护城河”」《2022产业互联网安全十大趋势》 安全系列研讨会原创

My life I and doesnt know yes me so great another thing。

中国。

我们线上会议室的嘉宾把自己的摄像头和麦先暂时处于关闭状态，谢谢。那我们今天下午的活动就正式开始。各位线上的嘉宾朋友们，大家下午好，欢迎来到由Co时代新基建创新院和腾讯安全联合打造的2022产业互联网安全时大趋势安全系列研讨会的线上会议室，我是本场研讨会的主持人，来自Co时代的刘晶。在前三期的研讨会中啊，我们与行业专家共同探讨了数据安全、信任架构以及如何对抗勒索攻击的三大安全话题，那感兴趣的嘉宾朋友也可以关注Co时代的微信公众号C时代网查看前三期内容的精彩回放。当前啊，云原生已经成为企业关键业务场景中不可或缺的技术支撑，助力着企业加速业务的创新迭代，实现降本增效。但是呢，频繁出现的云原生安全问题啊，也带来了更为复杂的安全隐患，搭建有效的云原生安。

安全体系成为了众多企业的迫切需求，本期研讨会我们就将聚焦守护云原生安全，构建企业安全护城河这一主题，与业界的专家们共同探讨如何搭建有效的云原生安全体系。本期的研讨会呢，我们非常荣幸的邀请到了四位分嘉宾，他们分别是来自北京赛博英杰科技有限公司创始人、董事长谭小生，高途集团C董一西，中科院计算所高级工程师李明宇，腾讯安云顶实验室云原生安全产品总监陶芬，让我们热烈的欢迎四位嘉宾的到来，也期待四位嘉宾接下来带来的精彩分享，那我也提醒我们线上的嘉宾啊，为大家带来精彩分享的同时呢，我们也邀请大家可以参与填写我们的调研问卷，完整填写呢，就可以获得由主办方送出的联想南阳。

的无线运动耳机，欢迎大家积极参与。数字经济时代传统行业的数字化转型不断的驱动着云原生产业发展迈向新阶段，但云原生在给业务带来积极影响的同时呢，也带来了全新的安全挑战。接下来我们就首先有请北京赛博英杰科技有限公司创始人、董事长谭小生，谭校长呢为我们带来的主题分享是云原生应用趋势和安全策略，欢迎谭校长，好的，谭校长欢迎您，您把您的摄像头和麦打开，可以开始您的分享了，谢谢。

好，谢谢，非常荣幸能够有机会来这里和各位朋友们。稍等。OK，呃这样的，其实呢，我自己是一个老程序员啊，到现在今年正好工作了30年，在过去的十多年里面呢，也是正好因为在互联网公司属于是在云计算方面做时践比较早的一个企业，三零的系统部是我一手建的，在我手里呢，这个公司的运营的服务器呢，从呃1000台最后到10万台，呃到后面的几年的时候呢，其实我们的这个服务器是大量的虚拟化的，可以说是在呃做云计算的话呢，我们也是最早的一批实者，但是呢，最近是觉计算的这个前进的步骤，步伐非常之。

我们从最早的是做虚拟化，做虚拟机等等这一层，然后呢，到最近几年的这个docker，到现在match，可以说呢，这个呃之很，如果说十年我们说计算和今说的计算。这个有非常大的区别的，那么在这里呢，其实我们一方面要知道这个云计算前进的这个这个步骤，另外要知道它的这个中间的这个变化是是在什么地方。那么今天的云计算，因为它能够这个呃，让这个程序由耦合到松耦合，再到通过服务来做耦合，这种这个变化呢，其实是让开发变得更加敏捷的，一定程度上呢，它是因为云计算的这个发展，也改变了软件开发的模式。

由于软件开发的模式的变化，然后呢，也会给安全方面造成一系列的这种新的挑战，我们在下面呢，会有更多的这个。同时呢，云计算因为它能够这个快速的做，呃，就是伸缩能够给呃，另外它按需付费等等这些东西带来的好处呢，使企业难以拒绝，呃，云计算能带来的这些这些呃对企业的这种便利，那这样呢，云计算的非常快的这个就得得以推广和发展。那么我们在今天来说呢，就是说云原生这个词，云原生和云计算到底是都有什么样的这种这种变化。呃，我的理解呢，是云原生呢，是说我们的应用程序怎么样的开发，能够充分的利用云计算的一些特性。

这个在早期的云计算，其实这个不太明显，呃，早期的是做虚拟化，那我过去的程序是在一台机上，那么现在在一个虚拟机上，其实它的变化还不是很大。但是到现在呢，就是我们的有微服务这种架构，然后呢我有sourcesh，然后呢我交付的话是不可变的基础设施，那么我还可以实现容器的动态的编排。那么在这个过程之中呢，其实对于程序的开发，它就要一个持续的集成和持续的部署。然后有声明是API等这些东西，这是出来的原生的一些基础架构，那这时候其实影响的就是说我程序到底怎么出来。那么。这个中间呢，在涉及到云原生安全的时候，就是一般来说呢，他认为云原生要关注四个C，第一个是cloud云本身，第二个是C是集群。

第三个是container，第四个是代码。然后呢，具体他们分别是指什么呢。我们来看云原生对于软件开发的流程，对于应用的架构和它的运行的模式有什么样的影响。第一是云生这里面呢，它是会有这个offs和这种cicd的概念，这种呢是过去呢，20年前我们当开发软件的时候，大家呢，会讲这个软件的生命周期，更多的会讲我要做好需求，需求控制好了，然后呢我做设计，然后做代码实再做测试。等等，但是在过去的十多年里面，我们看到因为互联网的这个快速的发展取得了成功。使得我们。软件开发的速度要求是非常之快，那这时候呢，我们再用传统的不管用瀑布模型还是用迭代模型等等这些这些来开发呢，似乎都这个无法去满要，因为把软件发出推向用要，那这时候呢，有一个概念就出来了，VE ho。

S这个概念的，如果说在20多年前，我们在做软件功能的时候是尽可能避免的，也就所谓的什么呢？三边工程，你边设计边开发，一边这个用户一边用，一边还不断的出了各种各的问题。那么但现在呢？S已经成为这个现在这个时代几乎是必然的一种开发方式，那的遇到什么样的问题，我们的安全么？因为你过去没有说一个软件交付，然后再提供这个呃，功能测试，再提供安全测试的这样的一个瀑布模型的这样的一种迭代的方法，那你的软件再开发出来跑安全么时候概。S，那么它和软件的开发、测试、运营这个过程就已经在一起了。这个过程呢，就。

会会带来cid的这样的一系列的这种这种工作，好这是第一部分，这因为S这种软件开发的流程的变化，它带来了一个新的词，就是2017年提出来的S的这样一个概念，把软件把安全的这个。检查和安全的从设计等等，这些和软件开发的流程在一起，这是这是一个流，这个一个影响。第二个呢，是微服务的概念，服务它其实是呃，会使程序的或者一个系统的边界去产生了变化，过去这么多年，我们呃一个成功的安全的防御的思想呢，就是边界防御，不管从防火墙还是挖。等等这些东西它都是假设我是有一个边界，我在边界的地儿呢，我可以放上一组安全设备，然后呢，我可以去对流量进行过滤，对于攻击呢，进行检测，能够去做出响应，好那这个如果是你都变成了micro service这种这种情况的时候，那你的边界在哪里？

你边界的防御的思想是不是要改变，这是第二个造成的影响。那么对service，那好，那就是在这种情况呢，它又有了一个service，然后把它的数据平面和控制平面又分开了，这种这个呃，这个情况呢，它又提供了一一些这个应用管理，或者是安全管理测量的这些方法。那这种呢，是不是又给我们提供了一种新的一种做安全的机制，我们安全的做的方法是不是也会随之而产生改变？我们再来看所谓的workload工作负载，工作负载从十多年前的这个我们的是以物理机为这样的一个呃单位，那么到后来呢，就有了，有了虚拟机，一台物理机上可以跑多台虚拟机，那后来在容器化。容器化的这个时候呢，这个一个容器的生存周期呢，它就是变到短到了几分钟，长则数天，那这时候呢，容器呢，它可以跑在虚拟机里面，也可以直接是有提供服务的这样的这种厂商来提供。

那么再往后有了，就是我无服务，我甚至是这个我跑在容器里面呢，和这样的一个一个呃服务，我直接对外提供一个API，好那这种它一个方式呢，它的这种生存的周期呢，可能只有数秒或者到数小时，那这种情况你可以看到它的每个工作负载的生存周期有了非常大的变化，这种东西呢，就会造成什么呢？在服务器的这个时候，好，我这服务器上跑的us，我在OS这上面我可以装安全软件，我可以这个对于操作系统级别以对应用级别做各种各样的安全的扫描和防护等等这些东西都可以做。到虚机的时候呢，它因为一个虚机可以生存几个月到几年的时间，这时候安全的就做的，我可以做在宿主机的OS里面，我在weather这一层去做各种样的安全的这个防范，你比如像早期春趋势科技的一些，呃，这种虚拟化的安全的这样的这个系统啊，也可以跑在guest OS里面。

然后呢，我在盖S里面呢，去做各种各样的安全防御这种过件，但是到容器的时候呢，这时候就开始遇到挑战了。呃，我们呢，就是国内的，呃，安全企业有一部分是做容器安全的，一个呢，它是做容器的静态扫描啊，那么第二个呢，它可以让它的一些安全系统跑在容器里面，但这时候呢，这个对容器做安全扫描这种静态的方法还还好办一些，但如果是你跑在容器里面，这时候就会遇到一个挑战，这个容器起来它可能就几分钟时间，它就被销毁了。那这时候呢，你这里面的这个安全的防护的这个软件，到底有没有机会能够去得到充分的运行，就是一个挑战，那service OK，那你到底把你安全的东西放在哪里了，它不像容器，你还有机会能够放进去到so，你就根本没有机会能够这个把这个东西再再放在里面的好。

这是工作负载和变化所造成的这样的这种一系列的这种挑战。这个呢，就是对于这个一道容器化了之后呢，主机防御的思想在里面起不起作用，就是一个挑战，到这一的话，就是要我们是不是要做到API级的防护，还有呢，过去呢，就是你基于呃虚机的时候呢，它还可以有一个IP，我可以有基于IP的一组防护策略可以用，那么到容器到的时候。你一个IP背后其实对照的可能是多个容器。可能是多个这种的，一个一个这种这个服务，那么这种情况呢，对于IP的策略就显得它的管控力度已经不够了，那这时候就需要再有些新的防护的这种措施。还有呢，在云原生和传统应用的区别是什么呢？第一个是开发语言上的区别，传统的应用用CC Java等等这些语言为主来写的，那么在现在云延生应用的时候呢，其实越来越多的用用go，用note JS等等这种新的开发语言，那这时候呢，比如说各种S工具，这种对于源代码当些扫描的这些工具，它支不支持新的这些语言，这就是第一个挑战。

还有呢，部署方式，我们呢，就有容器化部署或者这种，那么对容器化部署呢，就说对容器里面的代码是不是安全，那这种呢，就是引来了对于容器的安全的这样的一种，呃，这种扫描的这种这种需求。还有呢，就是我们在软件的，呃，CCD做到了自动化，那么我们安全我是不是也要自动化，你要是用人工的运维再去对付自动化的，呃，集成和交付这种肯定是无法满足要求的。还有是。在现在的云原生的这种情况下呢，它是动态的扩容和缩容就变得非常之频繁，那这个时候你的防线怎么办？如果你的防线实像过去的边界防御的这种静态的这种这种这种防御的话呢，也就变得非常的困难，那这时候也是让你的防线要被迫要变成动态的。

以上这些呢，就是提到的就是在现在的云原生的这种呃情况之下，因为开发模式，部署方式，运营方式的这种变化，他对安全呢，提出来的一些这种挑战，我们再来看过去的应用程序，应用程序呢，从最早的是单体化的应用，我是呃在一台机器或者一组机器内部，我可以有呃我的业务的逻辑，然后呢，我再访问我的后台，然后在前端有这个UI，这这样的，那到这个面向于服务的啊，这时候呢，他的这业务的总线，业务服务总线要对面对多个service，然后最后再带对一个同样的后台，到后来的micro service。到今天的so，到今天的so是什么呢？它引入了方形service。Service这样的这种新的概念。在这个时候，其实我的整个的一个应用程序整个是被打碎了，它可以是由跑在多个云端的，在云端多台不同的这个呃，基础设施之上的，所谓workload之上呢，这样的function去组合在。

访问云端的后台服务，那在在前端的去进行组合，这时候其实我一个应用的边界已经变得非常之不清楚了，那这时候呢，传统的边界防御思想，其实在这种新的就这个云原生的这种架构之下，其实已经不适用了，我们必须要找出来，在新的这个原生的这个架构之下，能够。这个做应用安全的这样的这种方法。还有呢，像service新一个呃架构这里呢，供个机，所谓里面你我们可以看它里面有服务发现负载均，服务的降调用，故障注入，日志监控这个量，身份认证控制加密等等这样的一堆，它可以说就是提供了程序的这种测量和安全服务的这样的一种一种机制。

那这种情况之下呢，就是如何把好的起来，能够帮助我们去做好这种，呃，云生架构的安全就是非常有有意义的一件事情。我们再来看在service match中间的这种，比如流量处理，那么它有这个proxy，在这个情况之下呢，它就我们可以提供一些观察和追踪啊等等这样的这种这种服务，呃呃，不知道大家有没有关注到，像阿里的这个，呃，就是蚂蚁金服的他们这个团队提出来的一个就是安全切面的一个概念，其实安全切面这个概念是是非常之好的，在现在呃应用架构变化的这种情况之下，他试图在。就是拿出一个安全切面，从安全切面的这个角度呢，对于程序的呃，安全的这个状况呢，去做度量，并且能够有干干涉的能力，这从决种挑战的种想本身就和个全概念呢，是比较好的一种合的一种具。

呃，这个是信通院所提的云原生相关的技术的这种发展的这种趋势，这个里面呢，其实都用到了一个cycle，这里面可以看到呢，是在云原生里面是有非常多的这个呃，这种呃。技术。那这里面我们再来看ER所发布的这个CC的，呃，这个云计算安全的2021的，这里面呢，也是涉及到非常多的内容，在这里呢，我就不呃一个一个来讲了，我们直接来看一下呢，就所谓的原生这个我叫它叫全家桶。

它呢就是呃，从最早的一个CSM，这个云安全的态势管理这样的一个东西，然后到后来的一个云负载的保护平台。到它的这个开比加SWG加Z，所谓的一个SSE，然后呢，在两边再配上一个SSPM和SP，然后这这么来看，它是怎么区分这个事儿的，一个是CSM，它是做合规性评估，风险识别，操作监控，SS集成策略执行，威呃威胁防控等等，威和威胁防护等等，这个叫CSM。然后呢，是一个CWPP，呃，云负载保护平台，它这个主要是过去更多的就像是这个主机一层的这样的防护漏洞的利用，防护应用的白名单，系统的一致，一致性，网络分段，系统监控工作负载配置等等这些东西，像CWPPT的话，像在国内的就是像呃青腾云啊等等这些东西，它就这个主打CCP这样的一个概念。

那么在比这个，呃，在中国呢一直没有能兴起，在美国呢，有一些这种比的厂商做的比较成功，但在中国呢，呃，因为这个应用的这个模式的这样的一些区别啊，比一直没有能够火起来，SWG和ZZ呢是尤其像Z这个零的架构等这方面呢，是在国内现在是创业的一个非常热的一个方向，SWG呢也是有比较多的这样的这种应用。它在这里呢，实现那个自适应的防控制，由BA胁防护等等这样的这个东西，然后呢，这个呃speed，它有一定的做数据防泄漏的这样的这种呃这种能力，那么具体呃来来说呢，就是一个是呃云安全的态势管理，这个呢，它就是有做呃这个身份的管理，网络配置，存储配置，呃这个管理员访问等等这样的这样的这个这个CSPM。然后呢，CWPP。

这一层是这个工作负载的这个，这两个之间呢，会有一点点的这个重叠，你比如像这个呃，像抗，像balance，像负载均衡等等这方面的，这是有一个重叠的区域。我们来看这个国内在CP这个领域呢，这个企业相对来说比较多，你比如说像这个，呃，前面提到的青藤，像呃信旗下的焦图，它现在呢，都是在打CWP的概念。那这个里面呢，就是一个是在开发这个阶段的一些扫描，你比如它的有呃漏洞的，就是说组件的漏洞，它的呃云的配置和一些这种密钥啊等等这种东西的，它的恶意代码还API发现等等这种是这个。还有他在运行态的时候呢，做各种各样的漏洞管理，配置管理，做这个呃网络分段做他的一次性的监控，做应用的控制，做这个行为的监控，还有做主机的呃入侵防护，做这种各种呃这个反呃反恶意软件等等这样这种。

那么。呃了呢，就是又推出来一个概念叫C。云原生应用保护平台，云原生应用保护平台呢，它是把CSPM和CWP加在一起，再加上更多的呃安全的增强的工具，这种呢就叫C，所以今天呢，就过去做呃这个呃CCSMCWPB的厂商呢啊，又都纷纷的号称自己在做做S。但其实呢，这个过程中间呢，我们的感受呢，是有不太一样，你比如说这个呃。做这个CSPM和做CP的，过去的很多是就搞安全的人。真正的是开发背景出来的人比较少，样就会出现了一个和用户去进行交的时候呢，谈就经常的是不仅仅是用户的安全人员，而是是做开发的团队，开发的团队呢，就会和这个就安全的供应商去谈，就会谈到他的一些开发方法，看你能怎么样能更好的支持，而做安全的团队呢，其实在云原生的开发方法了解够。

这种情况就会觉得你对我的开发方式，区的运营方式都不是足够了解，你怎么可能能能很好的做好我的这个防护，这就是今天在做云原生的，呃，安全保护平台或者这种产品的这样的这个朋友们所容易遇到的一个问题。我们再来看一下在现在这个这种情况的语音上的应用安全到底解决的时候会碰到什么样的问题，我们从底向上来看。在。这个我们把这个云上的应用呢，分成四种场景，一种是host在虚拟机上的应用。第二种呢，是hosts在虚拟机上的容器上的应用。

第三种是host在容器托管服务上的应用，第四个是直接host在容器服务上的应用，好那么在最下面的两层，这个是一样的，这是云层的基础设施和控制面，这个是在传统的概念，也是CSM去这个做管理的这样的这个层面。在这个之上，它会有CWPP这个所云云负载这个保护平台的这样的这种能力，这个时候呢，它是在前两种在虚拟机上的应用，它host在虚拟机上的容器上的应用，这层会有这样的这种能力，就CRPP提供这两种应用场景下的操作系统和云工作负载的保护能力。如果再往上看。这里面呢，就是有面向于容器的CWP的能力，这个里面呢，它是由CSPM的功能评估的，容器运行时和这个编排的这个这个控制这种呢，主要是在后面的三种情况，对于容器和容器的运行，你比如说这个情况下，像小游科技它做的容器安全，像探针搞的容器安全，它就是这个就是起在这部分防护的这种作用好。

那么再上如果就到了API这一，因为你不管是还是说我在容器的应用这里，我都可能会把我的服务是部署在呃上面，部署在容器上面，或者是这个so这个上面，那这时候呢，其实就会需要wapp服务。Wap的服务wa API网关，API发现，行为分析，安全保护工具这一级来提供API级的这样防护，那么如果在API防护之上，再往上面呢，是应用层的，应用层这时候其实就进入到了开发安全的这个这个领域，那这时候呢就是说各种ast工具。像呃呃，SS等等这种W，还有各种可用的CWPB的应用控制，这时候能够在里面起起作用，以及在应用层如果要再做到安全防护的话，可能会有这样的一些应用能够在里面能够起作用。

可以说从这张图来看呢，云上应用的安全其实涉及的范围非常的广泛，从我们这个CSTMCWPP，以及后来所这个就是加上增强工具的s snap这样的这种能力之外，其实还涉及到开发安全的这个领域，像各种各样的ST工具，像呃，P等等这样的这个方法，都是在现在的这个原生的应用上所需要关注到的这样的内容。我们过去这么多年呢，看这个呃，RC的创新沙盒，近年来云原生方向的这个，呃，创业方向我们看2019年是一个这个高峰，这个这里面呢，就是除了容器安全之外呢，它还包括了API安全防护，云安全平台等在内的这个平台技术呢，这是一个一个还有呃另外一个就是今年今年的R创新沙盒的最后十强里面。

有四家直接就是做呃，云原生的安全的，还有三家是云原生的安全是相关的。我们来看今年的这个呃创新沙盒的事项里面呢，第一个I networks，它是做云原生的威胁管理的，尤其它是用EPPF这种方式来去管理这个，呃，这个云上的这样的这个安全，还有第二个是呃开security，这是做云原生平台的这个取证的和响应的。第三个是let SP是做云原生安全平台的，第四个是是做云原生资产管理平台的，那除了这四个直接就是云原生安全之外，还有有三个。是和云相关的，一个是云上数据治理与运维A。呃。第二个是na，这个是做这个A安全的，刚才从前面一张我们看到它的，呃，API安全其实也是云上的做安全的一种方法。

那么。呃，最后一个是CYC扣的，CYC扣的是开发安全，这是在前面那个分层图里面呢，最上面一层就是应用层的这个安全里面，这个在开发与软件供应链安全这个，这个时候它能够提供等这样的这些能力。那这是可以说今年的呃RC的创新沙盒前十名里面有七家都是和这个呃云原生的安全相关的这样的这种领域，虽然到最后的他的这个获得冠军的，最后这这几家都没有获得冠军，呃，但是呢，这里面我们可以从这个比重里面和云相关的是历史上这个所占的最高的比重，然后我们再来看这个数出安全在前不久发呃这个呃发表的这个2022年网络安全全景图中间的云安全部分。

这时候你看呢，我们在国内的把云安全相关的分成了八个不同的产品的，产品的此类分别是虚拟化安全产品，容器安全、云工作负载保护平台，云桌面。云安全、资源池、微隔离、云身份管理、云抗力和云。大家看了这个之后能有什么感觉呢？其实呢，我是看了这个，呃这些呃，就是全景图中间分类，以及在前不久的腾讯的。数字安全创新大赛以及安全创客会这两个比赛，参赛的厂商里面呢，也有一些云的这个厂商，但是呢，呃，普遍的感觉是我们家在云原生安全方面其实是落后于美国的。除了在呃前两天的比赛里看到安逸科技。他的是一个纯粹是以开发背景呃为呃，就云云的就是基于原生开发背景的这样的一组人，他们做出来的安全产品确实是能够比较好的能跟上这个时代的节奏之外呢，我们的云安全产品呢，其实这个和美的这些云安全的这个产品呢，是有比较大的差距的。

我们现在呢，就是能看到一些云工作C的这样的一些一些厂商，真正做C的厂商是非常非常之少。像小右等等这样的这些体验呢，其实还在，呃，就是更加关注在我们的容器安全这样的这种这种这种角度是在对于对于snap的这种应用呢，其实呃，我们可以说自己是做snap的厂商，但是只是做了其中的一些方面，从覆盖度来说是不的，在原生还常大个进空创空间。那在这种情况之下呢，我们遇到的挑战呢，主要就是原有的安全产品与解决方案呢，仅能部分的解决问题。我们的云原生的安全的要求，既懂安全又懂云原生开发，这个呢，其实就给今天的在国内的云原生安全的这个赛道上呢，提供了一些创新和创业的机会。

同时呢，呃，作为一个这个老的开发人员，我这个在过去的十年里面也是算是带了一个呃呃这种开发团队的云云就包括360的云的基础设施也是我带团队建的，但是最近三四年时间，觉得在云上的技术演进速度非常之快。而且呢，这个我们的这个就是现在就开始出现了云的开发和云安全两个技术脱节的这种情况，那这个呢，就是就需要我们引起重视的一个一个方向。同时的话，我们又面临着非常大的机遇，就是这个，呃，云计算，尤其是云原生，因为它的一些优势所带来的这种用户需求，会非常快速的向这个方向去进行转移，面对非常巨大的市场，作为云安全这方面的这个呃，创业呢，也会遇到会有非常大的这个机遇。还有呢，是我们在国内的这个方式，一直都特别痛苦的说，订阅式的安全一直没有能够像西方那样能够得到广泛的这个采用，但是在现在这种情况之下，订阅式的这方式就随着云原生的这样的这种这种发展，我们安全去走向订阅式，有可能会借助这个云原生的发展，能够去能够得到比较快速的铺开，对于我们的云的安全的这个产业的发展，对于安全产业的发展都是一个非常大的利好。

谢谢大家，我今天的分享就到这里。好，感谢谭校长带来的精彩分享啊，分享了关于云原生应用的趋势和安全策略，那我们也看到啊，云原生技术的应用啊，将为更多企业创造更多的新的发展机会，好，那么如何通过云原生技术为企业创造更多的业务价值，助力企业发展创新呢？我们每一期的研讨会啊，都会邀请到一个甲方的Co来做分享，那本期呢，我们欢迎到的是高途集团Co董一西为我们带来的高途集团云原生安全实践分享，欢迎董总带来的精彩分享，您可以打开您的摄像头和麦开始分享了，谢谢。

各位线上的伙伴和嘉宾大家啊，下午好啊，嗯，很高兴能够参加C呃Co时代的这次关于云安全的一个实践的一个分享啊我嗯简单做一个自我介绍啊，我是一西，然后目前在高途这边负责整个集团的一个信息安全啊，这边主要是做一些嗯，企业的一些新鲜圈的一些规划，还有一些技术相关的一些工作啊，我今天主要分享的一个议题就是近十年的一个工作，嗯，经验来我对整个云安全的一个理解啊，包括我们在高途这边啊，然后整个云安全方面的一个呃实践的一个情况啊，跟大家做一个啊分享啊。

然后我今天分享呢，主要有三个方向，第一个方向就是整个云安全的一个架构啊，主要是基于我们在嗯，高途集团这边的整个的云安全的一个。架构的一个落地啊，第二个就是基于这个云架，呃，云安全架构，我们在高途这边真正的一个落地的一个情况，跟各位伙伴，然后做一个嗯，做一个分享，第三个就是我是觉得在源泉方面一个特别重要的一个点，就是我们的合作啊，就是因为有一部分工作我觉得是靠我们自己啊，或者说是呃，无论我们做的多好，靠我们自己可能都解决不了的问题，可能需要一些合作伙伴一起去解决。啊，那么第一个问题就是关于云安全的一个架构的问题啊，因为我这边是负责整个高途集团的一个安全，所以我们其实不会说单独的把嗯云上专门拉出来做一个嗯，做一个划分，所以我们在整个整体的体系规划的过程中啊，我们是参照整个ISO和。

嗯，27001啊，7799等等的一些，呃，国际上或者说国内的一些安全的一些标准，然后我们制定的是整个集团的一个安全体系啊，那么我这边是根据整个呃，以往的一个经验，包括也是结合咱们。各大互联网厂商整个安全体系建设的一个标准，然后我这边制定的是一个RSMS的一个四层的一个安全体系的一个架构，在这个体系架构里面，我们其中就包括云环境的整个架构啊，就包括整个云，整个云环境的架构，那么在整个云环境区里面啊，就是我的这个四层体系架构里面，你看有个一层矩证，二层矩证啊，二层举证，在二层矩证里面有个云环境区，那么这个云环境区里面，其实就是我们的整个呃，云上的一个架构的一个情况啊，然后我们整个架构的体系是说从外层到内层，会把整个公司去细里度的去划分啊，一层一层去呃剥离啊，然后去划分出来之后，然后我们最终的去做一个落地，然后我们呃重点今天因为咱们主要是讲和云安全相关的一些呃实践分享嘛，所以我就重点把云环境区里面其中的。

一呃，我们要做的一些东西啊，包括我们在在在云环境上面，我们做的一些实验的东西，跟大家去做一个啊分享。呃，整个云架构就是我的前面的二层矩阵器里面云环境区的一个架构，大概我们是分为六个部分啊，主要是分为六个部分，那么第一个部分就是我们的云的一个基础安全啊，那么整个云的基础安全啊，我们其实主要是呃，因为我们大部分的业务是用的现在是阿里云和那个腾讯云啊，我们是在。云环境上及整个云底层的啊，包括我们主机啊，包括容器啊，包括它的整个网络层的一个安全，那么整个主机安全的话，其实我们现在主要呃真正时间落地的其实就是基于呃两个云厂商本身的提供的主机安全，H hids啊等等的一些，包括一些呃在云的ecs服务器上，我们可能会去装一些agent去收集一些相关的流量，我们自己做一些分析，那么容器安全也是基于云环境本身提供的一个容器扫描，镜像扫描，然后来去发现它的呃安全问题啊，然后我们再去做一些相关的一些修复，那么呃网络安全是基于云pass层的一些流量，包括一些云防火墙啊，包括一些。

啊，流量啊，隔离啊，就包括比如说呃，每个VPC之间的隔离啊，应该怎么去，应该怎么去实现整个跨VPC的一些访问啊，如果说遇到这种的话，应该怎么去去做啊，这个我们都是基于云本身啊，就是基于云厂商本身提供的一个能力，然后去做一些防护，在这个基础上，如果说我们有一些需要去做定制的啊，我们一些比如说像底层的一些pass层的一些流量，那我们可能会专门去提些需求，然后从从。

呃，从跟厂商那边去沟通，然后我们拿出来我们去做一些分析，那么第二个大的方向就是整个呃，应用层的一个就是整个应用安全，就是云上的应用安全，这个也是我们呃很重要的一个一个环节，也是我们投入精力可能最大的一个环节啊，因为我们的核心的业务，特别核心的业务全部都是在云上啊，全部都是提供的一个SaaS服务啊，那么这一部分我们其实呃在整个架构层面啊，整个架构层面我们其实最关键的其实就是从攻击者的角度去出发，从攻击者呃，从攻击者的视角去出发，就是说攻击者最先能够接触到的，也是我们最先关注的啊，那第一个就是我们的整个资产地图啊，那么这个资产主要包括我们的外网的一些域名啊，包括一些IAPP，包括一些端口，包括一些服务啊，那这块我们要自研了，我们的定时的一些扫描啊，每天都会。

定时的去做一个全量的扫描，包括。从DNS层面，包括从一些黑盒的探测方面等等的啊，会有很多的维度去扫描，扫描出来的结果我们去做一些汇总，比如说有没有有没有新增的资产啊，有没有就是说未经过我们同意啊，然后私自上线的一些域名啊，或者一些IP啊，有没有没经过我们同意，然后开放到呃，公网的一些危险的一些端口啊，比如说一些像22对吧？啊，像一些少量一些什么呃，3389啊啊。啊等等的啊，像像还有像像像像red的一些呃端口啊，还有像一些有没有出现，比如像red没有做一些未授权访问啊这种的啊，这个是我们云山的一些资产，那么第二个就是我们有了这个资产之后。

我们会对这个资产做一个资产的一个健康的一个画像啊，就是每一个资产啊，不管是域名IP啊，还是一些其他的一些资产，我们这些资产的，比如说它的健康度到底是个什么样子的啊，那么这个健康啊，这个资产健康的画像主要是依赖于我们的，比如说我们的漏漏洞扫描啊，这个漏洞扫描啊，不光是纯黑合的扫描，其中也包括我们的，比如说深度测试啊，就是我们自己做的一些，呃嗯，深度测试啊，就是一些漏洞。上面的一些挖掘呀，啊，第二个就是比如代码审计啊，你代码在上线的过程中。当中我们会严格的执行内部的，比如说SDC的一些流程啊，包括SDC些David setups的一些流程啊，包括你的应用在上线的时候，你的配置是不是OK的啊，所以通过呃各个维度，我们会对整个资产做一个健康的划线，这个健康度到底是什么样子的啊，那么同时我们的资产会有一个分级啊，会有一个分级，比如说我们的API资产，对吧，那整个API资产可能承承载着我们整个数据的，比如说整个数据的交互过程当中，特别敏感数据的一些传输，那这样的资产可能是我们特别核心的资产，或者说特别重要的资产，那我们会对这些资产做一个重点关注啊，它的健康度一定要达到我们内部设置的一个一个标准啊，比如说80分以上啊，比如90分以上等等的，那么第三部分就是说，呃，我们是从防护的层面去做一个那。

呃，做一些工作啊，那这个防护的主要的一个架构的一个理念，就是说，呃，你不管是呃，不管是我们做多少工作，比如说我们自己做了什么代码审计，对吧，我们做整个SDLC的流程，我们做整个LC的体系，我们做整个漏扫的体系啊等等等等啊，但是终归是还是会有一些比如说。啊，一些问题可能我们发现不了，可能要借助于比如说自动化的工具啊等等啊，那这一部分我们主要其实就是做的就是啊，就是挖在应用层啊，在应用层我们主要做的就是袜和一些蜜罐啊，当然我们在呃过往嗯在以往的经验当中啊，包括最近这两年我们也接触到了一些新的一些产品，包括比如说像浏览器隔离啊，一些新的一些产品啊，那它的比如说。

主要是考虑到一些流量啊方面的一些压力啊，可能在我们实际用的过程当中可能发现啊，并不能满足我们的需求啊，这个是我们应用就是整个应用级别的一个安全的一个架构，那么第三个就是我们在业务层面的一个云安全的一个啊架构，那么这个业务层面的安全架构，其实我们最重要的其实关心的是什么底层逻辑，其实我们最重要关心的其实在业务层面就是合规啊，那这合规这合规其实展开来讲，涉及到的问题可能比如说内容安全啊，那么比如业务风控。啊，那么内容啊，比如说爬虫啊，比如说oss存储啊，比如说CN的恶意使用了啊，那么内容安全这一块，比如说就其实比如说你的课程的发布对吧？啊，你的课程的发布是不是符合国家的整个双减的一些要求。

啊，你的内容的发布有没有涉及到一些违规的一些课程啊等等啊那一些。啊，业务风控上面，比如说啊，你的整个的业务，呃，整个的访问的来源，比如说你的整个。IP的访问来源啊，是不是存在比如说这种大量的，比如说买课呀，因为我们比如说如果我们是直播课的话，对吧，那我们的直播课的，比如说一个一个班级里面的课程，比如说有多少人对吧，他是他都是固定的对吧，那比如说就有30个人对吧，那可能会有一些黑产，可能大量的通过这种虚拟的账号啊，然后去去买这种低价的课呀，然后去把这个名额会去占掉，导致正常的用户可能会进不来啊，可能会是这种情况。那比如说oss的，还有一些比如业务方面的，比如呃，比如说oss的一个存储啊，那么我们我们最近这一两年发现就是一些比如说。一些呃灰尘啊，他可能会利用一些，比如说他为了降低他自己的存储的一些成本，他会把它把它的一些，比如说一些嗯电视剧呀啊一些业务，它会切成很多很多小的一些碎片啊，把这些碎片可能会存储在各个呃云环境上面啊，然后利用各个正常的互联网的这种呃oss的存储，然后去去降低他们的成本，然后他他远程的这种去调用啊，那类似这样的问题，所以这个是我们业务安全可能要去解决的问题。

嗯。啊，第四个部分就是我们的数据安全要去解决的部分，那么数据安全这一块的话，其实在我们的呃，云环境这一块，呃，就是在我们的云架构这一块来讲，它是跟我们的业务安全，应用安全这个是密切是关联的，也是我们最核心的一个资产啊，那这一块的话。主要就是做对线上的数据，或者说我们对C端的数据。做数据分类分级啊，那么做脱脱敏，从整个数据安全的生命周期开始，我们做整个API的监控啊。做整个API的监控，然后做整个比如说数据的加密存储，数据库的审计，应用的审计啊，一些数据资产的地图，KMS等等等等等，嗯，我这边所列的一部分工作就是并没有说是我们现在已经全部都做完了啊，只是这个在我们的整个架构，在我们的方案当中是会有涉及啊，那么有一部分现在是已经比如说已经落地了，有一部分是已经完成了，有一部分是正在推进的过程当中，有一部分可能还没有开始啊，这个我们在呃，下一节的我们整个的落地的过程当中，会给大家去详细的去介绍这个东西。

啊，那么第第五部分就是我们的账号安全，整个云账号这一块的，比如说身份认证啊，啊，你的账号是不是做的一个权限的划分，比如说啊，啊I'm啊，啊访问控制啊，包括一些云账号的一些管理，包括一些堡垒机的一些管理啊，堡垒机的一些管理。管理，因为线上的就是云环境当中的服务器，我们其实是不允许通过，比如说像22啊，或者说像嗯SSH啊这种服务直接去登录的啊，我们的一个管理的要求就是说必须要通过堡垒机的一个审计，通过堡垒机的一个认证，然后去做一个做一个管理啊，那么结合这五部分啊，然后我们内部自己建了整个的一个安全的一个运营中心啊运营中心那在这里面会有一些比如说呃应急响应啊，发现比如说技术安全可能扫，就是云的技术安全扫描出来的一些问题啊，一些漏洞啊，啊一些新的一些比如说啊告警啊，比如说发对吧啊，比如说呃，前段时间影响比较大的，比如像呃log斯沟等等这种漏洞，那我们可能会去做一些应急响应啊，包括一些威胁的一些检测啊，包括我们的整个，比如说挖P的一些检测的一些配置啊，啊包括一些扫描的一些配置，比如说我们的呃，基础资产的一些扫描的一些配置啊，应该怎么去去扫什么。

直接去扫啊，对，去扫哪些资产等等，包括这里面我们可能会去收集一些比如说日志啊，对这个日志做一些综合的一些分析，日志的一些审计啊，那么最终的最终的目的就是为了满足我们整个安全的一个合规啊，那么安全合规这一块可能对我们来讲，目前比较比较重要的就是比如说等保啊，比如隐私合规，还有一些安全认证啊，包括一些教育，教育备案相关的一些啊工作啊，这个就是我们整个，呃，基于我们整个RSMS4层体现全架构的，呃，这个大的架构在整个集团的这个架构下，我们的云安全架构大概。

嗯，要做的几个方向啊，那么在这在这几个方向里面，具体比如说呃，落地的一个情况，我跟大家也，嗯。一起分享一下啊。呃，这个是我们整个四层体系架构里面的第四层啊，第四层体系就是我们整个最终的一个落地的一个体系啊，那这个可能嗯。大家看的不是？特别明白，我跟大家讲一讲，大家就就就清楚了，就是说呃，首先我们是这样的，我们在四层的矩阵里面，我们会去，在四层的矩阵里面我们会去把，呃，在这里，这里我只讲云上的一些其他的一些非云的一些一些一些资产什么，我我就不讲了，比如说我们云上的一些环境里面，我们会把。

呃，每一个，呃每一个比如说中间键啊，每一个比如说。单独的case我们都会单独拉出来，我举一个最简单的例子啊，比如说呃，我们三层里面我们遇到的一个问题，比如说我们的生产环境里面啊，比如说生产环境不环境里面，那么这个生产环境里面我们。啊，要去看，比如生产环境里面，其中有一项资产啊，就是比如说我们的access k access k啊，那么这项资产我们在整个。对应分类的时候啊，就是我们的会分到比如说它的应用安全和数据安全里面啊，那我们在对这个access以往的过程当中，我们会发现它出现，它会出现什么问题啊，那么出现就是说因为我们的线上的资源特别多，我们线上的业务会非常复杂啊，会有。

十几条，几十条甚至上百条业务线啊，那么每一条业务线他都会去。开通他自己的access k，那么这个access k我们在起诉的时候，他的管理是非常混乱的啊，他是怎么管理的，他会把access k从一开始他会硬编码到它的代码里面啊，这个是因为历史的原因，是因为历史遗留的原因啊，会硬编码到它的代码里面，那会造成一个什么问题啊，那所以它的脆弱性就是它的access界的管理非常混乱啊，那他的威胁就是说。如果说这一段代码被泄露了，这个我们曾经也是遇到过被泄露的一个情况，被泄露了，举个例子，比如说研发人员啊，因为他的安全意识不足，他把他的access k，比如说上传到，呃，他把他的代码直接上传到比如说gith up上面了。哎，那么在get harm上面这个代码我们就可以看到XK啊，那么通过这个X，因为通过X accessk，我们直接可以通过API的方式去调用。

操作云上的服务器啊，所以它的风险就是会造成，比如说我们的数据泄露啊，代码泄露啊，服务器被被入侵啊，那么错失什么，因为有这个风险，有这个问题啊，有这个危险，那我们会。作为安全来讲，我们最终要落地，我们会提一个措施，这个措施我们就啊建议对整个SK做一个的管理，那么我们的指标体系我在后面来讲，那么如果我们有了这个措施之后，我们会对整个access k，我们会专门会做一个项目啊，专门会起一个单独的项目，叫access k的一个专项啊，那么这个项目会有一个目标啊，那么这个项目的目标对吧，最终要达到一个什么目标，包括这个项目，这个目标最终产生的一个价值收益是什么，然后这个项目会有一个owner呢，然后专门去跟。啊，那么这个项目最终做得好或者不好，或者说我们怎么来评价呢？那么我们通过我们的指标体系来评价啊，我们的指标体系主要是有两个，一个叫建设指标，一个叫运营指标，啊那么建设指标里面啊，主要是有两个参数，一个参数是我们的。

覆盖率。啊，另一个是我们的完成率啊，那么我们的运营指标里面也是有两个指标，一个是响应时间啊，一个是响应时间，一个是发现时间啊，一个是发现时间，一个是响应时间啊，如果说这两个指标就是建设指标和我们的运营指标都完成的比较好的话啊，那么这一栏会。啊，变成绿色或者深绿色啊会变，你看我们就最终我们来关注的话，就最终落地，比如说这个做的好不好，有没有达成我们的预期，那我们直接看指标体系就行了，那么指标体系里面如果说颜色是偏绿色的，或者那么这一块就。就来相对来讲是我们做的比较好的，比如说像等等啊，比如说隐私合规啊，因为这个可能在教育行业里面，自从那个去年七月份们双减之后，这个是国家可能特别特别重视的一部分啊，然后所以我们对这一块其实也是下了很大的功夫去做啊，所以这一块的内容到到目前来讲，我们其实是做的比较好的啊，那你。

还比如像access k这一块啊，为什么呃，我们的建设指标其实是也是做的，其实也也也算可以，但不算是特别好的，原因就是因为呃，我们百分之比如说80%的业务可能已经全部都达成了我们的要求啊，但是有一些特别特别边缘的一些小的业务啊，因为历史的原因，可能还没有完全接过来，统一的接到我们的统一管理的平台里边啊，呃，我们内部叫阿系统还没有统一。呃，管理到我们的平台里面，所以可能就是说还没有完，还没有完全满足我们的需求，所以它的颜色可能就会稍微，呃呃稍微浅一些，那么其他的一些，比如说没有标颜色的呀，嗯。啊，因为这个表比较早了啊，不是我们呃近期的一些表，所以可能呃，就有一些项目可能还没有开始啊，有有有一些比如说像这种黄色的可能我们已经在做了，但是做的比如说效果呀，包括它的整个运营啊，整个整体的一个情况，可能并没有达成我们的一个达成我们最初设定的一个情况，那这块可能就是需要啊，最终可能需要完善的啊，这个就是我们整个整个云环境，也是整个集团在安全这方面的一个最终落地的一个，最终落地到底一个情况是怎么样的一个啊一个一个统一的一个管理的一个表啊，那么针对这个项目，单独的项目，比如说如果我们起的这个项目会有一个单独的一个项目管理的一个一个流程，我们按照项目管理流程去去跟进就行了啊，这个是我们在高途这边整个云，嗯源泉时间落地的一个一个情况会把，嗯，你像云环境这边，我们现在整个起的一个项目，总共有已经有大概超过有有有有有50多个了啊，就每一项大概做的情况都是怎么样，已经有超过50。

个了，嗯。嗯，最后一个我就分享一下，关于就是说整个云安全合作这一块，因为在整个实际在做的过程当中，不管是我们通过整个SDRC的体系，或者这UPS的体系，或者说一些其他的一些体系啊，然后我们去比如说杜绝这个漏洞啊，对吧，我们内部的人员去挖漏洞啊，啊做也好，但是我们最终还是发现有一部分工作，其实无论我们投多少精力，其实我们或者说我们的产出比，或者说我们的OI其实并并不高的，那这一块，比如说像DDOS对吧，像CC这一块，比如说你们自己投人力去，比如说去建一个迪道S的平台啊，或者说建一个迪道S的产品啊，其实相对来讲它的成本是比较大的，所以这块我们可能会依赖于比如说跟一些云厂商的一些合作，甚至一些第三方厂商的一些合作，然后来共同帮帮助完成啊，那比如说加消费一些情报啊，那相对来讲它的专业性可能会比较强啊，它外部的情报的一个溯源能力啊，一个增踪啊，在这一块其实我们自己来做的话，其实整个的效果可能并不能达到一个，比如说咱们。

呃，目前的一个比如说一些企业，像像像咱们现像，像咱们其他的乙方厂商可能做的那么专业啊，那么这块我们就会选择去跟云厂商去做一些合作，还有一些像像呃ipt的一些一些专业的PT溯源的一些工具的一些服务啊，啊对，还有一些政策，那么我们其政策主要是可能有一部分比如说。

为了弥补我们自己在漏洞这方面可能一些不足啊，呃，这个就是我们，我这个就是我今天从三个层面啊，大概简单跟大家因为时间的关系啊，简单跟大家去分享啊，跟大家去分享一下我们在高途这边整个。呃，云安全这一块大概去做的一些事情啊，我今天的分享就到此结束啊，谢谢大家。好的，感谢依西带来的精彩分享啊，那刚刚也有嘉宾呃反馈说想获取我们比较清晰的这个PPT内容，那也欢迎我们的嘉宾可以添加我们视频号以及我们在群里发布的小助手z times，后续呢，我们跟嘉宾确认以后呢，会同步相应的呃资料给大家，那同时呢，在稍后的圆桌对话环节呢，我们今天分享的几位嘉宾啊，也都会跟大家做互动交流，如果大家有什么问题啊，欢迎在我们的视频号上以及在我们的微信群里面可以同步的留言，我们收集上来以后呢，会给我们的嘉宾啊，稍后在圆桌对话环节的时候来做现场的解答，再次感谢一些带来的呃高途集团云原生安全实践分享好，我们知道啊，云原生已然成为企业重要的基础设施。在目前的企业云原生应用中，有哪些价。

创新和实践呢，下面我们请到的嘉宾啊，是来自中科院计算所高级工程师李明宇，那明宇给我们带来的分享主题呢，是基于原生的架构创新及实践，欢迎明宇老师，您可以打开摄像头和麦开始您的分享了，谢谢。好的，嗯，非常感谢刘老师。那个非常荣幸今天能够在这个场合跟大家来分享关于云原生的架构创新和实践，我的整个的分享内容呢，可能跟这个。呃，安全就是。

没有特别直接的这个关系，但是也是呼应一下前面两位专家的这个分享吧，就是。在在这个从传统架构往呃过去的这种架构已经往现在和未来的这种架构的这个过程当中，实际上应用和开发，尤其是开发它的呃重要性，或者说是呃，它所带来的灵活性，新的挑战越来越明显，那实际上我的这个这个分享呢，其实也是扣一下这个前面的呃这这样一些观点吧，就是讨论一下在云原生的这种新的这种模式下的架构创新及实践，大家会看到开发在里。它的作用和地位，以及以及所带来的一些新的挑战，然后后面也会讨论一下安全，但是呃，我讨论这个安全呢，可能跟咱们今天会上的另外几位专家，呃，讨论安全的这个视角有点不太一样，我觉得也是一个非常有益的补充吧，对，我也是之前也是看了呃，另外几位专家的这个分享的主题，然后我想可能可以从另外角度来补充一下。

所以我的整个的分享的内容是有这么四个部分。呃对，我个人呢是呃现在呃这个供职单位是中科院计算所，那呃中呃前面有几年我是一直在企业工作，就是呃从创业公司啊，然后到上市公司，其实都待过，所以也服务了很多客户吧，各行各业的的客户，所以也是对。呃，云计算技术本身一直在研究，然后对于在行业上的应用有一定的体会，所以也是结合这个啊一些体会吧，所以啊来去设计了今天的这个分享内容主要是由四个部分，第一部分就是呃，从原先的这种机器的架构到这个云原生的架构的演进和创新，然后呢，另外就是讨论一下这个，呃，有一个案例拿出来看一看，然后后面呢，我们再说在这个创新的过程当中遇到的挑战，以及呃，我们现在在研究的一个事情叫云原生应用设计模式。

那实际上我今天不准备把设计模式详细来展开，因为那些更多的是给开发推，而我我想是从另一个角度就是讨论一下，就设计模式其实对于呃，我们企业啊，或者组织啊，对运转型中间它它它的作用，其实它不仅仅是面向开发，对运维其实也是有定的这个。助力或者帮助的，因为在新的这种云原生的模式下，其实运营和开发的关系，合作的方式，其实它是在不断在转变。最后就是讨论一下这个云原生应用保护的，呃，一些思考，那中间也会体现出来，就是现在整个这个基于云原生去构建it，构建数字化系统，它的模式的一个变化，所带来的安全应用保护方面的一些一些变化，以及我们一些应对的方法。那首先就是我的一个理解，机器原生到云原生，其实在第一个主题的报告中。

韩总就提到了一个事情，他说实际上我们现在云的这个模式的演进，在云主机，大家用云主机和虚拟机的那个时代，其实对于应用的影响，以及对于我们it构建的这种方式的影响，其实没有那么大，没有那么特别大，呃，或者说当时也是大家也是觉得在变，在发展，但是到云原以后回头再看的话，其实之前的这个变化其实没有那么的。没有那么大，而到了云以后，整个的这个事情，它发生了一个，呃，不叫翻天覆地吧，它也是非常大的一个转变，那其实其实在哪呢？就是我们最初其实构建我们的呃，一套it系统的时候，我们可能是要准备机器啊，准备物体，然后在上面去装软成I系统，那后来其实这个机器变成了虚拟机和云主机，然后我们基于这种。虚拟机和云主机在上去构建我们的应用系统，但是这个虚拟机和云主机说到底它也是一个机器，它的一个很大的转变在呢，在底层的这个资源。

或者说底层这个资源，它不再是以一个个的物理机为单位或者边界，而是整个一个资源池，所以在资源池的基础之上。我们再去构建应用软件，那呃，到今天云原生的这个时代呢，我们其实背后有一个驱动力，就是应用软件，随着我们的发展，随着我们数字化的发展，随着我们基础设施的这种能力的供给更加的灵活。呃，这个规模更大，可扩展性更强，所以我们的应用也能够越来越好的发挥它的作用，所以应用的规模也在增长，那现在我们看到的以微服务架构为代表的这样的一些新一代的应用，那可以可以从某个角度来说，就应用它也是分布式的，对吧，你微服架构构建一个应用，不再像以前一样一个单体应用，它是有很多的微服在一起去。去做治理，做交互，做上下之间，上下游服务之间的调用，最终形成一个大的应用，那这个应用它是分布式的。

所以我们这时候就会发现一个问题，就是底层的资源已经是资源化，上面应用也是分布式的，也就是说你搞一台两台机器，或者搞几台机器，其实也已经不足以支持这个应用的运行。那我们把这个资源池再分成机器，然后再给应用去多台机器上再搭建一个应用，这中间这个这个中间有没有一些环节是多余的或者说是不必要的呢？这个值得思考，因为我们完全有种方式，就是直接由底层这个资源池提供API知识应用去运行。那应用也不用再去以机器为它的单位或者去部了，应当有一种更的方式。所以这个实际上是。我们今天说的这种原生的模式，以底层平接提供A用，然后我们基于这个A基平台去构建我们的这种大规模的分布式的。数字化的应用，所以这是我们今天讨论云原生的模式，而我个人把之前的这种模式，包括基于云主机的这些模式，还有过去的这种模式都统称为模式媒体，就是机器原生模式，所以今天我们正在经历一个从机器原到云原生的这种架构创新，而在这种架构过程当中，我们可以想见那传统的这种开发方式，以及传统的这种应用的构建的技术。实际上。

对吧，基于机器的，它肯定是跟我们说的新的这种模式，它不是完全匹配的，技术也是不一样的。所以实际上为。为了实现这种转变，实际上我们会引入一些新的技术，那下面我们基基于一个呃实际案例来看一下，那这个案例的背景是这样的，就是有一个集团下面呢，有很多个这个，那呃实际上呃在经过一段时间的发展以后。一开始当然是这个快速的发展和扩张啊，那当然建了很多厂以后呢，呃，实际上就进入了更加精细化运营的这样的一个阶段，那在这个阶段中间就会发现其实是有些厂它的能效的这个这个或者投入产出比是不够优化的，那这个怎么优化呢？那实际上有一个方法，就是现在也是数字化转型中经常提的这个方法，就是在生产环境中数据数据，然后对这些数据进行分析，最后得出一个优化的方案，那实际上中间会得出来一些对生产过程优化的参数，是直接可以自动化的下到生产线上的，不需要去人为的去看报表，再然后再去，再去通过一些人为的手段去调整，那这也是一个非常好的一个数字化的一个一个思路吧，所以为了实现这个。

呃，事情那呃这个团就开发件个怎么样开发的，它采用的是一个机身架构那。啊，基于这样这样的，呃，Java的这样的集成架构去开发的一个软件，那在这个软件开发过程当中，实际上它非常有必要就是多方合作，因为对于这个集团来说，他在这一块他更重要的角色，它是一个用户单位，那他不可能说把所有的这个软件的开发，数据分析的工作都自己来做，为什么？因为这个构建生产线的时候，很多设备本身也是采购，所以他的很多生产环节本身也是非常专业的，他得请专业的团队来去合作开发，所以他以这一套软件能够，呃。

从提出想法到开发完成，到部署到现场，那中其实是很多团队，第三的外部团队，内部团队一起来合作完成，而且由于这是一个本身是一个创新的一个事情，所以其实是没有办法说，哎，我一开始就把需求分析好，然后就怎么怎么样，就能够定义出来一个软件我们要做成什么样，他我它实际上是需要在这个。开发的，在这个在这个应用的过程当中不断的去。去总结需求，不断的去迭代，不断的去完善，对吧，然后包括数据分析的算法流程啊等等优化的方法需不需要去调整，都需要不断在实践中去总结，所以它是一个不断迭代开发的这个过程，这也是就像谭总一开始在第一个中间分享的那样，就是说过去我们说三边工程，边设计边开发，然后用户边用，那这个以前是需要避免的，但现在到这个新的一个数字化转型的时代，其实这是一个需要去。

克服其中的困难，需要去推广应用的一种方式，因为他数字化这个事情本身就要这样去做，那呃对我们回到这个话题上来，就是说这个软件还是说开发完了以后部到用户现场，注意它是通过集成框架集成的一个软件部署到用户现场。所以实际上也就是说传统它的做法是一个典型的么，是native的做法，它并不是一个native，那他做这的效果怎么样呢？其实一开始效果时是很好的，它中间集成的算法不是很多，数据分析流程不是很复杂，部署的这个工也也不太多，管理的生产流程也不太多的时候，那他这时候他诶我在每个厂里面装一套或装两套软件是吧，搞两台机器，甚至有的厂是力旧的工控机，其实都这都是可以的。没有问题，但是当这个事情做的不错，开始推广的时候，就发现实际上问题就来了，当这整个的这个这个一个一套数据分析流程变得越来越复杂，中间引入的算法的数据分析组件越来越多，那管理的这个生产流程涉及到的这个环节越来越多，当它部署到不同的厂，不同的厂它的它的需求可能是不一样，生产线是不一样，生产的产品是不一样的，它同一个产品的。

生产线两个厂建设，由于建设时期不一样，他们所引入的设备，整个生产线的流程可能也都是不一样，甚至说设备之间可能还有差。所以。其实传统的方法就会导致说实际上这个集团维护N多个分支版本，部署到不同的里面去，然后做数据分析，这时候就会出现大家就能想想象，就能想到一个问题，那在这样他要维护十多个分支版本，部署到各个区，然后还要不断的迭代，不断的引入新的这种算法，然后不断的根据新的厂，新的生产线建设的时候，或引入一些新的需求。那这个。

就很难去维护了，所以后来就导致说这个塑造这个项目其实进展到一定阶段以后，再往后去深化推进就非常的困难，这段遇到的这个具体困难这块也用红字列出来了，我就不去不去念，大家也大家也能够作位，呃，嘉宾也都是行业内的专家，其实都可能都多多少少对类似的场景有所体会，所以。怎么解决呢？后来我后来这个事情，就因为前面其实还是一个行业应用软件的一个一个工作，那实际上我们接触到这个项目的时候，正是这种传统模式的模式，遇到挑战的时候，那怎么把这推荐下去，要不要在架构方面，当时其实甲方或者说这个集团其实也没有一个明确的一个想法，他只是找到我们的尝试性的说，能不能在架构方面有些改进，能够突现在的问题，开发方法上有些改进，能够突破现在的问题，有没有办法？于是我们进行了一些讨论，那实际上后来我们采用的这种方法，就是用现在我们说的原的方式来对它进行重，那怎么做的呢？

实际上就是把一个算法模块，原先我们是大家可能都做一个类，一个函数，对吧，然后集成到一起，实际上我们后来写了一个这个封装的框架。然后呢，让各个算法开发的这个服务商，或者说供应商，他们，或者说这个内部团队，它基于这个框架来把这个算法封装进去，能够形成一个能够独立运行的微服务，或者类似于微服务这样一个东西，把它打包到一个。一开始是镜像，后来实际上是都是容器镜像，打包到容器镜像里，然后另外呢到这种集成框架，我们后来做了一个这个服务编排的一个引擎，然后通过这个引擎来实现算法的编排，而不打破了原先的这个这个传统的这种集框架，这样的话我们就能做到什么。呃。如果我们要有一套分流程的。通过这个编排引擎把这样一些算法给编排出来，就能实现这个这个这个这套新的这个分析流程，那这个编排引擎，它编排引擎的输入是什么呢？是主要是一个编排模板文件。

所以它是这样一种架构，那实施的时候我们也不用到各个部署了，我们是让各个厂把数据传上来，我们在这个过程当中，我们其实也是一开始也是有所担心，所以我们去去用户现场做了调研，后来我们发现因为他是做一个能效优化的一个项目，他跟现场实时控制是不一样的，就他对时效性的要求没有那么高，而数据量呢，其实也没有那么大，虽然传感器很多，数据点很多，但这些都是时数据和结构化数据，所以总体量并不太大，所以把呃，通过这个。网络把各个生产线上的一些我们需要的这些数据传到云端，统一的存储，统一做分析，然后把这个分析以后的结果统一分别下发到各个厂，各个生产线的，各个生产线上面是可行的，所以就部署实施，我们就呃不再是往各个去部署了，而是在云端，我们在集团这边，它实际上有它的有它的这个云环境在上面部署一套。

然后给各个厂上面去开户。开租户，那呃，我们要有一个厂，然后有一套业务流程，有一套生产流程，要做相应的数据分析和能效分析的话，那就在上面建一个，建一个租户，或者说是现在其实云原生一个呃，更常用的一个术语叫namespace，其实就是建一个namespace，它跟传统的这种强隔离的这种呃租户还不太一样，它的隔离性弱一些，但是呢，它又能够起到区分不同的这个呃用户啊，不同业务流程的这样的一个作用。然后，然后每个租户里边如果要实一到数据分析流程的话，就提交这个编排模板，就可以去把这一堆算法编排出来，然后呢，能够针对他的需求做数据分析，所以这样的我们在这个部署的时候，我们经常遇到一个问题，就是会问这个，呃，这套软件的提供方说，哎，我要给你准备一套什么样的机器，对吧，准备几台，然后存储了多少资源。那这个机器呢，能不能就实际上就会涉及到资源规划的问题，你到底要用多少CPU，多少存储资源，其实这个这个对各个各个厂来说，其实你就反复需要讨论，他们所面对的这种数据的规模不一样，所解决的问题不一样，可能资源规划这个得到结果也不一样，但是如果你都部署到云端的话，这个问题就很好解决了。因为你的。

用的都是从云资源池里面取的这个资源，所以你没必要说针对每个厂每条业务线或者每条生产线去确定，哎，我到底要用多少资源，多少存储，多少计算资源，其实不需要，所以资源规划也没有太大的问题，那前面提到的算法更新的问题啊，版本更新的问题，实际上这些都比较好解决了，你算法更新你需要更新容器，或者以前用的一开始用的虚机更新这个镜像就好了，更新完镜像以后呢，如如果你希望说大家用新的版本。可以用滚动发布的方式把它发布到线上去，那这样的话，你不论是说新上线的这个算法编排流程，还是说已经在运行的，实际上都可以去去通过这种滚动更新的方式，用到你的算法的新的版本，而不需要中断业务，不需要重新部署，这些都不需要，那你的这个版本的维护，其实也不用需要维护那么多分支版本了，我们不需要说有一个算法更新了，到各个厂里面去更新一遍，那有的厂他不愿意说你经常动它的系统，他可能还会拒绝你这次更新，所以这种这种版本维护。

就会非常的困难，当当我们用云原生的方式以后，那实际上这个问题就不存在了，因为我们在云端可以让以用户不感知的方式，就把这个这一些算法都给更新掉，做成像现在我们很多互联网应用，呃，同样的能够达到这种效果，对吧？我们的互联网应用，不论是电商的还是呃网约车的，我们都知道他在不断的去更新它的系统，但是我们作为用户来说是没有明显的感受。所以。达到这样一种效果，然后另外就是数据和数据，数据的存储，我们以前存成这种结构化数据，存到各厂里面，要求有它的数据库，我们有时候他自己没有数据库，我们可以去用的话，或者说不允许我们用的话，我们还需要去有D维护这套数据库，其实这些都是非常麻烦的事情，那现在云原生的方式可以都拿到云端来用云存储来解决了，所以可以用统一的，呃这种。

数据库存储服务，或者对象存储服务，把这些文件存储啊，数据存储的问题给解决掉，不需要再去维护本地的存储系统，所以这样的话，我们实际上是把前面我们提到的这样一些问题给成功的通过从传统模式云原生模式的转型来把它克服掉了，让这个造转型项目能够成功的推进下去，所以这是云原生模式的带来的好处，那前面我们也提到了，我们要想构建这样一套应用，包括想实现从传统的模式的转型，那实际上我们需要需要一些新的技术来支撑的。这就是前面我们其实做这样一个转型，其实我们也会看到需要有些新的技术来支撑，那这些技术有哪些呢？其实云生计算基金会也给了我们一个全景图，那这个全景图呢，也是在不断的更新的，因不断有新的技术出现，还被替代那。啊，这时候我们在。进行一些云原生的这个创新，还有我在服务一些客户的过程当中，那我也深刻体会到这个挑战，就是整个云原生技术体系，其实它新东西还是蛮多的，然后呢，他其实整个it现在不仅数据中心，整个it。

方向上去转，对吧，我们以前说数据中心，其实更关注的是数据中心作为基础设施，来来去来去提供提供他的能力，那现在应用其实也在变，应用的开发模式也在变，再到这个我们提到从云到到端，其实它都希望说能够具备我们说的云原生模式带来的这样的敏捷性，呃，可扩展性的好处。所以。所以其实带动着边缘。甚至也在。某种程也在借鉴一些云原生的技术和模式，所以整个它的设的方面面非常的多，就导致很多技术其实都要更新，所以整个的云原生技术体系还是蛮庞大和复杂。但是从另一个视角呢，我们也会看到说其实这些技术系它并不是完全的独立生长出来，比如说这里面也涉及到要用数据库，其实它跟以前的数据库其实是有很强的关联的，里面也会涉及到存储，社交网络，其实跟以前的网络和存储的方案也是有很强的关联。

所以它在复杂的过程当中也是一种渐变的。但是。就是说怎么让用用户再去做转型的时候，怎么样能够充分的去体会到这里边我们到底哪些是可以用，哪些是我需要需要创新和转变的，那其实他把整个技术体系捋清楚，还是相当有挑战，那另外就是新带来的这个。这个比如说我们传统应用构建变成微服务应用构建，那微服务应用的部署和运行，所考虑到这个事情跟传统的部署和运行是不是一样的，是不是说我们两个团队开发和这个运维团队在一起，我们讨论完了以后，我们有一个部署方案，按照这个去干。那我们既然要实现这种频繁的迭代和更新，那难道我们也要频繁的去开会嘛，对吧？但这个话题对于呃参会的诸位嘉宾来说的话，肯定都是老生常谈，都知道这个里边肯定不能说在像以前那种模式去做啊，那由此其实在其他的方面也是一样，比如说容错，容错这个事情，我们说这个这个微微服务价或者云架构，我们提供应用的这种可用性，那可用性其实在呃在某些场合也把它作为安全的一个很重要的一个方面。

那实际上提高可用性的一个前提呢，是我们要要能够发现错误，要能够去容错，能够发现甚至预见错误，那这个发现了，遇见错误怎么去发现，以前我们说这台机器宕机了，或者怎么样检查一些指标，那现在微服务各种各样的服务有很多，那每种服务它其实如果要发生故障，如果发生故障或者快要发生故障的时候，它的表现可能都是不一样的，这谁最多？实际上是开发者最清楚，那还有其他的问题，比如说我就遇到有客户，他抱怨说搞了云以后，用了这个原视，用了Co，然后上面这个应用更新的时候，大家都说这东西好，但是我们更新的时候反而出现问题了，对吧？因为我们的工作协作方式变了，那实际上应用更新时候有时候也不通知，也不通知运维，然后他更新频率也高，但是更新的时候引起的这个用户的投诉，为什么？因为他连的好好的，为什么断下来，这往回一查，发现断下来时候都是去做update，就是这种滚动发布的时候，那也做了滚动发布，为什么还会有问题？

实际上这些都涉及到和开发之作带问题。这就。我去赘述了，那这些还有像像前面也提到了服务网格，呃，中间经常我经常会遇到一个问题，说有了服务网格，我们还要不要API getway getateway从某种程度上来说也是云原生技术。那要不要嘛，那如果说不要的那个可能根本不够大，那那这个不够大这块在哪补，那如果要的话，API getway可能本身是一个集中式的入口，这个东西它也不是分布式。然后在上面可能会做一些非常复杂的配置，因为涉及到应用，就是东西调用的时候不去展开来去讨论了，因为今天时间有限，所以也也也有问题，那这个里面这个矛盾怎么去解决？所以。实际上我最近实际上在研究这个问题，就是呃，我们面向企业能不能提供更更加直观的一种方式，我们我们实际上在也看到了，在过去的我服务过的几十个云生的客户当中。

几十家云生大，几十家云产生的客户当中，其实他遇到的问题。参齐就是原始能力参差不齐，其实很大程度上能不能把这些问题解决的好，取决于那个。单位里边或者他那个公司里边有没有高水平的云原生架构师，那我们能不能有办法说把这个云原生架构师的能力能给用，能够给呃，给他推广或者复制出去，所以我在尝试做一个方，做一个设计云原生的这个或者云原生应用的设计模式，呃，我们要在云原生应用里面，可能我们就会涉及到一些场景，那这样一些场景呢，我们就按照某种方式去做，那可能就是比较好的，我们这个场景里面，比如说前面提到的，我们要要是践行微服务，那微服务就可以作为一个场景，那这个微服务，你要做微服务，其实就要考虑刚才提到的。种种这种不同方面的一些问题，那这些问题我们有没有答案，实际上是有的，庞大的云原生技术体系里边已经给了我们，其实对目前云原生里边很多问题他都已经给了答案，但是这些答案可能他的用用怎么样，不要去用，不知道在什么合下用，可能就取决于这个，呃，行原生的这个客户，或者行行原生的这个企业里边原生架构师的程的水平。所以。

我们也尝试着说把解决各个问题，它究竟怎么去做，把这个答案呢也给对应起来，那这个地方写的实现实际上是基于实现原里面还有很多技术，其实其他技术也有不同的实现方式，但总之这些问题可能都是在这些场景里面需要解决的，而我们刚才说的这个微服务场景，类似的还有我们要构建外部U的时候，外部API的时候，还有我们传统意义上来讲的一些application server，其实它都有类似的这个这个情况，那他们都可以归为一类是状态服，所以我们就按照这种方式，那其实这种方式也不是我独创的，而是我借鉴了，呃，这本书大家肯定。肯定都是。知道是非常经典的一部分，一部著作，在当年大家对面向对象的软件该怎么做的时候，一脸一脸崩的时候，然后他们撰写了这样一本书啊，四位大神撰写这样一本书，然后给后人一个非常有力，强有力的指导，一直在未来的二三十年里面都让大家受益匪浅。但是当然今天我们到云原生的这个时代的时候，跟过去面向对象是一个时代，今天我们到云原生那个时代，云原生的软件，原生应用软件这个。

大的分布的应用软件应该怎么去构建，其实我们缺少设计模式去借鉴，所以我们正在正在尝试做这样的工作，那这个设计模式我也是尝试着按照呃，传统的这本经典设计模式里面的思路。去提，就是每种模式有个名称，然后讲清楚它应用场景，然后我这个模式要解决哪些问题，这些问题怎么解决，或者说这个场景里面存在哪些问题，这些问题应该怎么去解决，所以这样去这样去构建，那这个这个设计模式，呃，可以用来做，比如说我们内部的这个架构的设计参考，然后呢，可以做用来做架构评审的时候作为参考，然后也可以做开发运维协同的时候遇到问题了，我们怎么去排查，来做一个参考，比如说我们这个问题到底是开发还是运维去解决，其实我们我们其实。

相对于就是有时候开玩笑说会甩锅，但实际上在各个企业里，大家都是更多的协同来解决问题，协同肯定大于甩锅，但是协同解决问题的时候，我们面对新的问题，我们怎么样去讨论一个新的方案出来，实际上这中间需要磨合，需要过程的，我们能不能缩短这个磨合？的开销以及缩短这个过程。那我们可以如果有个考那就更好，所是这个应计模式的一个想法，那我看于状态模式，下面我还举了一个有状态服务模式，那有状态服务模式它会更加的复杂，我就展开来讨论了，呃，所有的这样一些我自己总结的这个应用设计模式呢，都会在我的get上逐渐的这个发布出来，那呃，对。呃，所以大家如果感兴趣的话，也可以去参考一下这个链接，然后我们如果说有其他也可以讨论，其实我更想说的是什么呢？就是这个可能是我个人或者我们团队的一个总结，那呃如就是各企业，其实有些企业它的架构师的水平可能比我要高得多，那实际上我更多的是一个建议，就是我们企业内部其实也可以通过这种方式去总结。

按照设计模式的方式来去总结我们的一些云原生的这个应用应该怎么去构建，然后把这东西作为一个参考，再开给开发去做参考，给运维做参，给开发和运维协同时候解决问题来做参考，就是这是一种更多的觉得这是一种工作方法，可以去推荐，就是我们也可以内部去总结，不一定说我这个总结就都是OK的，那这个里头。或讨论一些，就是扣下今天的这个主题吧，讨论对云生的应用保护的一个思考，那实际上我也看了听了，呃，学习了各位，呃，专家的这个分享，那这里边呢，嗯，很多地方都在讨论这个安全，那实际上实际上我们在应用保护或者安全的时候，我们经常会发现，比如说呃，在等级保护里面，其实除了对面向攻击的防护以外，我们还有一些相对应用可用性的要求。

对应用的数据的这个这个持久性要求数，或者说数据存储可靠性的要求，比如数据不能丢，要做备份等等，所以实际上在应在呃汉语里面我们经常讨论一个词叫安全，或者叫保护，但这个东西对于英语来说可能是两个词，我们今天可能很呃各位专家讨论更多的是security，但实际上安全还有另外一个方面，或者说保护，还有另外一个方面是safety，那safety和security可能都译成安全，但实际上对于对于这个应用来说，它的所使用的技术，所需要考虑的问题是不一样的。那所以今天我就想再花一点时间来讨论一下这个safety的问题，那实际上在等保的这个里面，其实对于security和safety它也都是有有要求的啊，这地方之所以把这个列出来呢，是等保的这个2.0里面，其实对云计算是安全，云计算安全是有扩展要求的，提了很多，但是嗯，但是诸位对等保肯定都有很深刻的理解，对吧？因为大家也都知道等这里面提的云计算安全，其实他没有提到。

原的东西，甚至设计容器东西都不多，但是对于我们用户来讲的话，或者对于我们的厂商。呃，从业者来说的话，现在已经进入到一个云原生的阶段，那我们等保它更多是给大家一个参考，而不是说这里面要求没有我们就不去做，那所以我们实际上某种程度上是不是能够参考等保的这个对云计算安全扩展安全的，呃，云计算安全扩展要求来去思考一下，就是我们云原生。云原生云上应用的保护，云原生平台的保护，到底需要做些什么事情，我们也可以像前面，就像我，就像我我的那个想法就是呃，云云原生应用设计模式一样，其实我们内部建立一个规范。参考这样一些东西，那这里对于CT的东西呢，我想再展开说一下，就是。就是我们传统的这种应用的safety的保护的机制，什么灾啊，高可用啊等等，这样机制能不能够直接都套用过来，包括这个上云以后的一些云的一些保护技术能不能套用过来，实际上是有疑问的。我跟一些。在的厂商去聊人家，人家其实有时候会有一个直观的一个想法，就是。

我们做了主机的保护，做了云主机的保啊，云主机的保护我们能不能把它套用过来，说你现在用容器来承载应用了，你容器就相当于是我们以前保护的那个云主机，虚机，我们以前我们既然能够从传统的时代到保护虚机，保护云主机的时代，呃，这种方式，那我们肯定也能够用类似的方式保护容器，这个实际上是就很值得去打个问号，像前面呃各位专家也讨论了，说这个容器的生命周期可能有时候是分钟级别的。一个分钟级别的东西，里面的应用，里面的代码，里面的数据，对它进行这个C方面的保护有没有意义，对它复制一份做个还有没有意义？实际上是值得去考虑的。然后另外就是。我们的数据库和储原的和是不是一样，怎么去做护，然后还有一个就是原的应用里面分布应用里面还有很重要的东配置。以前我们应用部署在一个，应用部署在一个地方，我们对它做配置，那现在是分布式应用，可能一个服务都有很多实例，我们的配置是通过配置中心去导入的，那这个配置你在哪，要不去保护，你根本不在应用跑到这个地方，它在配置中心里面，所以当我们做防护的时候，保护的时候，不叫防护，保护的时候，或者做数据的这个安全的这个安全的这个这个这个备份的时候，我们是不是也要考虑把那部分东西也给拿出来。

因为它是跟着应用走，因为不同版本发布以后，配置可能要变，但它在配置中心的，不在应用本地，所以保护的时候我们可能要上配置中心，相应的东西也拿出来做做保护，然后还有网络策略。这个就很有意思了，这个网络策略可能它也是会变，所以呃，总是这样的东，然后另外我们在想，其实以前我们做应用保护的时候，可能很多都是从平台层面去入手，我们做开发的人。跟做这个。传统的，比如说我们就说灾吧，做的人可能他之间是相互是。不会对话。但是现在这个用是怎么来的呢？它是敏捷的，是着开发去走的，如果说如果说我们平台的。

人做在备的，做在备的团队做备的供应商，或者说我们作为一个一个一个C，我们如果要去整个这个系统的时候，或者组织整个系统的演进的时候。在位的供应商，平台的供应商跟应用的供应商，应用的开发团队之间要不要去做做对话用的对话很少，我们知道应用不符，在这可能应用备份厂商问的更多的是说你有些什么样的机器，Linux还是Windows的，对吧，你的存储用的是是的。存储属什么情况？对这些门清，但是跟应用开发的部门人对话可能比较少，那反过来现在的应用都是敏捷的。这个一套应用到底要保护哪些数据？还有像刚才提到配置要不要保护，要保护哪些配置，可能是应用开发的人最清楚。所以。我们前面也提到了平台提供API应用去去做，调用去去用，那现在我们的平台有没有支持备份的API？让最清楚自己应用要保护哪些数据的人，也就是开发人员直接去调用。

可能现在我们审视一下，可能会发现很多做了云平台，其实这里面是没有的。所以今天我为什么想提想。这些片子就是我们现在可能平台怎么支持云原应用构建，对，然后支持这个这个云原生的这个OK，支持这个云生的OK，我们也讨论很多了，甚至我们提直接API，让开发的人去去能够去调用，然后我们呃做的团队，做开发团队充分的去交流。但是好像在安全在保护的另外一个方面，就是safety这方面好像类似的的还很少，我们还是希望说有一个备份厂商在厂商能给出答案。但实际上可能这个事情也是需要去审视和思考，所以我也提了一个参考的一个方案。当然这个方案的，我们现在目前还没有的这个产品去落地，但是现在已经在这个在上，那我们也是跟有家企业在合作，在做这样的事情，嗯。

OK，实际上呢，简单来说一下，就是我们首先第一个是以应用为中心，我们充分的考虑说我们构建云原应用下面需要哪些的，这个到底需要保护哪些东西，我存储，那实际上随随这群众哪些存储数据需要保护应用，然后还有就是我们在在这个平台上面，我们要保护一个应用，实际上是一个平台上面有很多租户，然后每个租户里面跑了很多应用上我们要保护什么，是以应用为单位保护，而不是说我们说诶用多少存储券。哪些存储券用了，比如说我们在一个存储里面开了这个库的20个PV 20个PV全部都给它背下来，这20个PV到底是将来到底是恢复的时候，到底对哪个应用是干嘛的。实际上你光背PV是没有意义。那所以要支持应用的模型。那可能要支持容器、应用和命名空间三个层次，因为有的可能用户希望说对整个命名空间都要做保护，那这个里边其实有有一种有一个事情需要去做的，就是支持用户的整个这个。

完整的应用去管理，那这涉及到用户的应用管理模型，因为用户总去定义我哪些容器在一起算是一个应用，哪些容器在一起是另外一个应用，这里面其实ccf有参考模型，就AOAM，但是OAM不一定所有的用户呢都是这么去，都是用的OAM来管理它应用，所以其实在的这个方案要跟或者这种应用保护的方案。Safety的保护的方案要跟这个去匹配出，应用的容灾的方案要跟这个用户的应用管理模型去匹配出来，然后另外还有一点就是用云原生的模式去保护云原生应用，那什么意思？我们可能更多的是要考虑说我们怎么提供API，怎么让这个应用的开发者能够更好的用他们来去。说清楚自己应用需要保护哪些东西，然后这后面我们再通过自动化的这个手段来把相应的需要去保护的东西出来，然后跟这个云原生的基础设施能做一个结合，比如说csi，比前面提到这样一些一些方式。呃，所以今天我的分享就是这样一些。我也欢迎各位多多指。

好老师。好，感谢明老师带来精彩分享啊，分享了云原生的架构创新实践，以及自己基于呃对云原生安全的理解，那稍后呢，也期待在原对话环节我们再有精彩的讨论，企业在应用云原生技术中啊，该如何打造安全、智能、便利的云端安全生态，搭建有效的云原生安全体系呢？那接下来呢，我们就有请到的是来自腾讯安全云顶实验室云原生产品安全总监陶芬女士为我们带来腾讯云原生安全攻守道之路的主题分享，欢迎陶女士您可以打开您的摄像头和麦开始您的分享了，谢谢。好的，谢谢主持人。嗯，能够看到我的PPT吧。主持人，嗯，可以看到我的PPT吗？

可以的可以的，您可以开始了，嗯，好的，嗯，大家下午好，我是来自于腾讯安全云顶实验室的陶分，呃，目前呢，在实验室是负责整个云源设安全的一些方向的研究，还有包括一些产品化的一些落地的工作，那么大家也最近也可能都看到了，现在整个腾讯云的话，目前其实已经实现了一个数千万盒的一个计算规模的一个容器的应用，它全面的去支撑整个腾讯集团所有业务的一个云原生的落地，那么云顶实验室其实一直是致力于在做云原生场景的攻防研究和运营实践，并且把我们的一些安全研究的一些成果，还有一些实践的一些经验集成赋能到我们的腾讯云的云原生安全产品体系中，既服务好腾讯自己的这样一个超大规模业务上云的安全的需求，同时也服务好腾讯云的客户，所以很高兴今天能够有机会跟大家去交流腾讯云的这个攻防研究的一些进展，以及我们这个在攻防实战驱动。

下的一个安全能力的建设和一些实践的一些成果，那么今天我的分享会分为几个部分，第一个部分的话是简单的分析一下整个云原生架构下面临的安全风险和对企业在实际的安全运营能力上会带来一些挑战。第二个是职工，是分享一下我们对云上的就是典型的一些黑产集团的一些在野攻击的调查的一些成果，以及整个云原山安全攻防的实战的一些现状。第三个部分的话是回归防守方，从懂房的角度来看，去分享腾讯自己的这种超大规模容器应用下，它的整个云原生安全能力体系的一些顶层的一些架构设计的思。第四部分的话，其实也是我们的自己的类功能，就是怎么去做云原生的安全管理和运营的一些实践，包括在这个过程中我们面对的一些挑战和应对，最后的话其实是和大家分享一下我们在我们参与贡献的一些行业的标准。还有包括一些人员是安。

能力的一些成熟度的趋势。那么首先我们回到第一个的话，就是整个云原生架构下面临的安全风险。呃，相信大家之前都听说过云原生三驾马车，容器化为服务和div OPS，那么呢，我们通常会把它分为两块，一块是把以容器技术去支撑的整个云原生的一个计算环境，还有相应的div o的工具链，我们把它称为一个云原生的基础设施，那么将上层的微服务S还有API来代表着整个云原生的应用。那么我们认为整个云原生的安全风险如果大大体上去分，主要就是分为第一个，就是在整个云原生的基础设施自身的一些安全风险，以及这个上层的这个应用相关的一些安全风险。那么在这个里面，我们认为容器技术还是整个云原生的基础技术支撑，是它的一个底座，所以容器安全也是实现未来的整个全面的一个云原生安全的一个基石。所以今天的实践当中，我们会围绕着现有的像在容器，还有包括K的一些相关的安全能力，去做一些展开的一些实践的一些交流和分享。

然后我们来看那个整个的云原生的应用，它从构建、部署到运行，它是有一个全生命周期，那么它的我们也能够看到，在这个里面因为带来了容器的集群，容器集群的编排调度，以及容器的pass平台的这一块，所以它的整个攻击面是会被扩大，那么它面临的安全风险也会去更复杂，这里的具体的安全风险就不一一展开了。然后其实安全风险带来的其实是整个的一个安全能力的建设的需求，整体上看的话，我们会看到像传统的一些安全问题，比如说像主机啊，网络边界这些安全问题其实还是在的，但是可能传统的一些安全产品可能可能无法去适配容器场景，可能需要去做一些更新，而且呢，在当然也会有一些新的技术架构，技术和架构会带来一些新的安全风险，比如说像镜像安全，容器逃逸，还有API的安全等，其实是需要企业去建设全新的安全能力来应对的。那么同时呢，因为容器它的生命周期。

啊，以及它相应的更灵活的一些资产的一些标记方式，它的边界也会更模糊，所以啊，我们会带来对东西向的隔离，还有一些网络隔离和防护的一些安全需求，以后会可能会日趋更加强烈。那么呃，这一页其实整体上我们在做一个安全风险面的一个分析和一个安全安全建设一个需求的一个梳理，那么整体我们也来总结一下，就是呃，未来的话，在整个云原生架构逐步的成熟落地的过程中，它会对整个企业的安全运营能力带来的极大的挑战。我们认为第一个的话就是云原生带来的第一个主要的变化就是容器的短生命周期，这个是我们其实基于线上的这个容器化应用真实收集上来的一个数据，我们可以看到它的这个生命周期相比原来传统的主机时代的将近一年300多天的一个平均生命周期，而容器是只有分钟级的，其实这对安全的来讲带来的是一个攻防战术的一个变化，那么呃，在容器场景下的攻击，那么可能容器逃逸就是一个关键的径，而安全色对它的整个逃逸的检测和防护能力也是一个安全建设的一个重点。那么第二个变化的话，其实是容器的密度大，呃平均的容器密度相比主机可能是呃已经达到了30个，这个是基本上成熟化的应用之后，基本上容器的密度都会达到这个几十个这样的一个比例，那么呃，未来的几十倍的增长的这样的一个防护的一个力度，那么怎么去做运营，怎么去降低我们的这个安全运营的成本。当你面。

面对如此大规模，这么大规模的整个的一个防护的对象的时候，可能之前的很多的一些人工的运营的手段可能就不再成立了，那么这个时候怎么去做资产的定位，还有自动化的响应，其实也会是一个关键。第三个的话，其实整个安全其实从div s OS，特别是在于原生下，其整个是更适应整个of的一个安全理念的，那么在于原生的场景下，其实我们的安全能力也要去覆盖到开发还有运营的一个阶段，并且能够实现一个去配整个云原生的的自动化集成和智能化的运营。那么最后一个挑战的话，其实就是我们说的，我面向云原生的架构去做安全，所以我本身的安全能力也要符合云原生的一个理念和一个技术的趋势，就是安全能力也要云原生化去融入到整个云原生的基础设施里面去，安全能力，安全产品本身也能够支持云原生化的一个部署和应用，这块我们也能够看到这几类像。

Coless的security，还有包括未来基于service mesh，基于这些Mar产品去做增强的安全，这些理念也在逐步的发展。嗯，整体来说，我们分析清楚了一些云原生架构下去面临的一些风险面，包括带来的这些安全能力的建设需求之后，再去展开，再去展开具体的安全能力建设的同时，其实我们还做了另外一个事情，那就是我们一直特别想摸清楚，那么真实的面向云延生场景下的攻击威胁是什么，攻击的径，攻击方法是什么，这样才可以使我们的整个安全建设可以更加的一个有的放矢，能够持续的去检验我们的一个安全防护的一个效果。

相信做安全的一直都知道，就是攻防一直是互相博弈，互相驱动的，所以在整个呃云顶实验室，我们从2019年就已经开始了对容器的一个在野攻击去进行一个研究和监测，呃，我们来看一下一些真实的攻击威胁的一些现状数据，这个是我们在二一年的十暂对几百个开始去应用云元生技术的一些行业客户去展开的一些调研的一些结果，那么可以看到其实有将近一半以上的企业其实已经在真实的经历过容器安全的事件了，特别是在201年的2021年底的时候，相信大家还记忆犹新，持续爆出了一系列的重大的漏洞，重大的漏洞利用的最终的黑产攻击也是真实在发生，而且我们持续在腾讯自己内部，还有包括腾讯云的客户去响应和解决了非常多的一些入侵的案例。

呃，我们针对docup这个黑产的监控的分析挖掘，也拿到了一些比较有意思的成果，就是docup的话，它是整个云远生行业大家，它是现在行业内最大的最知名的一个第三方的镜像仓库平台，那么我们已知的像这种黑产的进像投毒之外，我们也发现它本身也是被作为黑产攻击得手后，用于去息传播其自己的恶意进项的一个站点，在我们其实我们在2021年的八暂公布过一个捕获到的一个黑产的一个单个恶意进项的最高传播量其实超过了1900万次，而且累计传播量是1.9亿次之多，怎么理解这个1.9亿次，简单来说可以可以简单的理解就是黑产其实已经贡献了在网的1.9亿个容器，那么通过并且我们通过对dob上超过100万的这个镜像持续的去做一些静态的检测，还有包括我们后台的这个dta动态的沙盒分析去检测。其中我们发。

而且do有将近万%分之七是明确的黑产的恶意进项，而且通过持续的监控，我们看到它的攻击种类还有对抗一直在持续的提升，可以说未来的话，针对于原生应用的这个供应链攻击应该会是持续，是未来安全关注的一个重点。这一页也会有，这一页是我们在2021年的九月份，其实就单月的话，我们自己的这个呃，哨兵系统其实就捕获到了，就是在全球的云厂商上共捕获到了针对容器的在野攻击次数就达到了10.8万次，而且典型的攻击手段我们也可以看到，基本上就是呃，你基本上一旦有一个脆弱性的容器环境上线之后，黑查室它通过这种大规模的自动化的扫描，持续性的这个探测和入侵很快就会被拿下，包括典型的像容器的未授权的一些访问探测的集群的一些组件漏洞的探测，还有包括容器的登录的尝试的这些行为，那么攻击者他很快就会利用这些暴露的漏洞和配置的缺陷发起入侵，一旦入侵成功之后，他就会进行恶意镜像的执行，还有部署特权容器，部署远控，去做容器的逃逸，去做进程的隐藏等一些对抗行为，最终达到完全去控制这个容器及其宿主机，甚至整个集群。而且最后。

错，可能会通过挖矿来牟利这样的一个过程，那么我们我们在捕获的这个攻击产生的相关的一些威胁情报，其实在我们的呃，腾讯安全的云原生安全产品中均有集成和应用，这是当时我们的一个客户真实的一个入侵的案例，然后我们也详细的分析了整个黑产集团，还有包括它的攻击动机，攻击手法，还有对抗的一些趋势，这些都在我们的那个云顶实验室，2021年二零今年上半年发布的容器在野攻击调查报告中都有详细的披露，像这个的话，我们我们就是通过这种黑产镜像的精准的查杀来帮客户定位到他已经被入侵了，并且帮他去完成了整个攻击的一个溯源的分析的过程。

嗯，刚刚其实我们也看到了，就是我们的对手，我们的攻击方一方面是黑产对吧，黑产他其实已经有了非常成熟的这个自动化的攻击手段，而且呢，像通过集群控制权去部署挖矿容器去获利，它其实是有一个非常强大的一个利益驱动，让他去不断的去升级它的攻击方法的，我们最近这个月刚刚抓到的一个就是捕获到的一个知识的攻击案例，就特别有意思，就是他基本上是拿到了集群的控制权之后，他用了K原生的这个demon set的一个方式直接去部署挖矿，Po的demon set代表什么？就是他不需要再去做横向的继续去渗透了，那么他拿到了集群的管理员的凭据之后，直接起一个DEMO set，那么KBUS原生的容器的编排和调度就会自动把他的挖矿的pod在所有的集群的节点上自动的拉起和运行，可以说是基本上我们也可以认为它是一个coless native的attack了。那么除了黑产的自动化攻击外。

我们也看到，呃，这几年持续的一些攻防演练，那么特别是在基于容器场景下的一些渗透测试的能力，包括这块的一些定向的攻击手段，其实已经逐步的再去陈述，我们实验室在二一年其实已经发布了一个云上的一个attack的攻击矩阵，以及包括行业首个云原生安全的一个攻防的全景图。呃，包括这整个的attack的攻击矩阵，其实我们现在已经面向内外部进行了开源，包括它的版本也已经迭到了2.0的一个版本了，然后我们来看最近的r s sa的刚刚结束的r sac的2020年的一个大会，在这个大会上仍然有人员是安全，就像刚才那个谭校长说的，仍然这块上还是一个热点的议题，这是整个在大会上其实一个分享的一个现在面向云原生场景下的一个完整的攻击径，而且坦诚来说，从二零年开始，我们在内外部的攻防演习中已经能够看到这些攻击的路径，已经逐步的投入到了实战了。那么。

可以说一个是企业自己的话，他因为在整个云原生的逐步落地的过程当中，他会去重视和规划相应的云原生安全的建设，另外一方面我们也能够看到攻击方，那么它的整个面向全网的真实的这个攻击的威胁其实是在日趋严峻的，再加上攻防演练不断的去，大家最近已经把云原生的场景已经成为攻防演练的一个突破的热点，还有包括一些得分项的规则都已经增加进去了，我们可以看到，其实不管是说从我们可以看到，就是说整个云原生的安全可能现在面临到了一个很关键的环节，它可能已然已经进入到一个实际上已经进入到一个安全对抗的一个实战的一个阶段了，那么对于我们的企业来讲，包括我们云底，作为整个腾讯云的安全团队来讲，我可能会更关心我们的整个安全检测的，还有包括安全防护的一些真实的效果，以及在企业内部我真正的这个安全运营的成本和一个效率。

我们现在回到防守方的角度，职工是为了更懂防，所以我们现在重新回到防守方的角度，我们来看一下，就是因为就像如刚才所说的腾讯云的容器平台。它本身承载着是整。了腾讯公司全量的云原生业务，我们有着业内最大规模的一个自研上云的一个容器应用，所以呢，在整个容器平台的服务，在它的建设之初的话，我们的云顶实验室就已经承担整个腾讯云的整个云原收架构下，整个容器安全服务的整体的一个安全的架构和设计，呃，这是我们在当时整个的一个设计上的一个体系设计，遵循的一个四大的原则，一个第一个的话就是一个安全能力的原生原生化，第二个是安全左尼，第三个是安全防护的一个全生命周期，最后一个是一个零信任的安全架构，然后基于这样的一个设计原则，我们也完成了整，我们也推出了整个腾讯云的一个云容器安全的一个防护体系的一个框架，那么整个框架的话，其实它也是一个按照整个云原生架构的这样的一个层次化的方式，逐层的去实现安全防护，主要分为就是底层的这个承载，承载整个容器云平台的一些基础设施层的安全，然后包括中间。

的容器，还有容器云平台的基础架构层的安全，以及容器承载的上层的一个应用层的安全，我们当时我们的初衷是希望通过这一套完备的一个安全防护体系，能够去打造出一个能够把能够很好的承载整个腾讯业务的一个原生安全的一个容器云，那么同时也能够助力我们的用户去实现一个安全的，去实现一个云原生的转型，那么相应的整个的我们的一个安全体系的一些架构设计，还有包括一些技术方案，其实我们也贡献给了行业去，包括在信通院的对应的云原设安全架构白皮书，还有相应的云原设安全成熟度模型当中都可以有，都可以看到腾讯的这套设计理念，那么可以作为我，呃，我们也希望这个东西可以作为这个大型企业，大家在面向云原生、融云原生的整个架构转型之后，可以从一个体系化的顶层的架构设计和安全建设需求的一个参考。

然后最后说，最后来总结一下，就是呃，如刚才所说的，我们相关的一些威胁情报，还有包括我们的一些安全能力和我们的一些运营的实践，我们均会都会集成到腾讯云上的云原生安全的容器，安全服务的产品中，可以去实现这种客户的一键启用，实现这样一个原厂和一个原装的一个能力。

最后呃，现在给大家分享一下那个我们自己的一些内功的一些类功方面的，就是包括我们腾讯云自身的云源是安全管理和运营实践，嗯，可以说那个安全运营是目标，安全能力是手段，安全运营会驱动整个安全能力的一个建设，整个呃，我们在内部去推进整个容器安全运营的时候，我们会去参考NT的一个网络安全的框架，将整个容器的安全运营会分为五个并行并且连续的步骤，分别是识别、防护、检测、响应和恢复，并且呢，我们会将整体的技术和流程进行提炼，晨炼和提炼为相应的这个安全管理的一些规范，安全基线的一些要求，包括对应的安全策略和安全规则的库。那么企业类的安全团队在运营实践中，我们也非常，就是我们也推荐大家去重视整个威胁情报的引入，我们希望能够基于真实的威胁情报，比如说漏洞和黑产的攻击情报，来驱动整个运营和响应。

整体来说的话，在识别的阶段，其实主要的是做的一些集群资产的识别，包括这里面也可以去扩展到自建容器的识别，还有业务风险的识别，因为面向整个云原生场景，它的资产其实保。既包括这个coless的这个资源层面的资产，同时也包括像容器、镜像这些应用维度的一些资产信息，那么一旦检测到某个镜像包含一些新的漏洞，或者检测到相应的一些入侵行为，我们希望能够快速的进行所有的资产和人员的一个自动化关联定位，去发现影响范围，去定位安全的责任人，从而可以去进行一个快速进行一个处置。那么在安全防护的阶段，整个云原生架构下，它的一个高风险的配置检测和修复其实是非常重要的，为什么？因为从容器的设计理念来看，它和操作系统的是共享内核的，所以呢，可以给容器的用户会有一个更大的可操作的空间。所以某种程度说，配置的安全与否，其实在很大的程度上就直接决定了你整个系统的安全性，那么另外一个的话，在安全防护的能力上，呃，面向云原生场景，云原生架构的场景其实更强调一个准入控制的能力，因为为什么？因为云原生的架构它可以去借助于容器。

的编排层面的能力，会给我们去进行安全性的控制，会提供一些更充分的一些便利。准入控制的最大的价值其实可以，其实还是在整个安全风险的预防的方面，比如说一旦洛街类的重大的漏洞爆发之后，我们可以通过准入的控制，快速的去控制整个的影响面，去防止一个风险的新增。那么在面向云原生架构下，它的整个准入的控制可以分成从研发和运行时的两个阶段来实施，那么研发阶段的准入其实主要是我们知道是在那个CI的阶段CI。

入库的阶段，我们可以去进行一些漏洞啊，敏感信息之类的一些风险的检测，包括去设立一些相应的安全的门禁，只有通过了才可以去进入到流水线的一个下一个阶段，那么运行时的准入控制其实主要就是体现在比如说应用被部署运行的阶段，那么同样也是只有符合安全机械要求的容器和pod才允许被拉起运行，这里的准入条件我们通常会包括一些对这个容器的这个资源，就是pod运行的一些资源限制的检测，还有包括对一些像CS啊这些关键的这种权限的限制的一些检测的。嗯，当然谈到容器的场景下的安全防护啊，就云原生应用的安全防护，不得不提那个容器的网络的隔离，因为整个云原生网络的在设计之初，它其实它是不具备任何的网络隔离能力的，因此当真正的云原生应用逐步的成熟和落地，未来的企业内部的容器化应用的规模上去之后，那么其实我们是需要去补习相。

相应的网络的隔离的能力的，能够实现精确到这种业务应用之间的一个网络的隔离。当然整个的这个运营框架里面，我们会看到，我们会提到各种的一些安全策略，还有安全配置的管理。呃，其实在企业内部的运营过程中，我相信大家都能够感受到这种策略和配置的管理，持续性的管理其实也本身也就是一个很令人头疼的问题。那么回到云原生本身，我们也发现在云原生架构下，因为它有一个不可变基础设施这一基本的特性，其实也给我们带来了一些新的变化和思，我们可以通过像白名单、行为模式等这些方式自动化的去学习和生成一套安全机械，那么这个安全机械就可以成为各种防护策略配置的一个重要的参考。那么最后是一个应急响应处置和溯源，呃，常见的容器的入侵的处置，包括去做容器网络的隔离。

然后包括去暂停，还有销毁容器的，当然这个里面有一个前提，就是因为容器的生命周期很短，所以呃在去做相应的响应处置和溯源的时候，要去实现，需要具备完善的一个日志，还有一个追踪记录，可以可以实现这个处置之后的一个溯源的取证。刚才的这个运营框架，呃，可以说只是提供的一个体系化的一个运营思路，但是在实际的运营过程当中，我们还是会运遇到一些实际的难点，呃，我们跟很多的那个客户再去交流的时候，行业客户去交流的时候，再去说运营的难点的时候，大家提到的最多的三个难点，呃，相信很多人也也有感同身受。第一个的话就是。就是容器的资产，就是没有办法定位到人，能够快速的去做应急的处置，第二个的话是整个进项的安全的运营的推休非常的难，第三个的话就是容器的pass平台，它的配置类的风险的修复的定义很难，为什么会带来这些我们在实际的运营过程中这些实操方面的一些难点，其实我们来回顾，其实我们整体来看一下，就是我觉得这里面有几方面的原因，一个的话就是整个的话还是有技术门槛的。

技术门槛的，可以说在整个企业的安全运营，还有包括运维当中，我们会出现懂安全的不懂云原生，懂云原生的不懂安全，而且现有的企业内部的安全运营人员需要逐步的去补齐，对于原生的基础知知识和一些运维的相关的一些知识，这个东西是需要有一个持续的学习的，包括这里面其实也有一个门槛的一个过程，然后第二个的话就是流程规范，就是我们也看到就是业务在云原生上，云原生都上的特别的快，然后业务业务都在野蛮的生长，那么其实配套的相应的这个安全能力的建设，还有一些安全运营的一些流程规范，其实是不及时的，包括包括像企业内部的这种业务进项的整个的一个构建和一个管理的过程，如果一旦没有及时去做规范性的构建，到未来其实给安全的运营会带来非常大的一个工作量，第三个的话就是人和资产，就是角色非常的复杂。其实我们可以看到，其实。

面向整个云原生应用，它会贯穿到开发、安全和运维的所有的阶段，而且这个里面还引入了容器的pass的平台，那么在这个里面，一方面是原有的安全技术和安全意识，安全意识的问题，还有包括安全技能的问题，还有一个确实是引入了一个pass平台之后，原有的很多的资产的归属，还有包括安全责任的模型，需要重新去定义，整个运营流程需要重新去梳理。嗯，经过了三年的运营实践，我们自己也总结了一下，我们在落地企业内部的这个面向云原生的整个安全运营能力的四个关键，第一个的话就是做好镜像的安全管控，第二个是主动的集群容器的这个集群层面的一个安全加控，第三个是强大容器运行时的安全防护，第四个是建立基本的容器资产大盘可以应急，并且我们也提炼出来的一些关键的运营的一些流程和规范的要求。嗯，在这个数据当中我们可以看到，其实腾讯内部的云原生应用的规模其实是非常的庞大的，而且我们是涉及到不同的BG，不同的业务，然后在整个绩效安全的管控机制上，我们有落地绩效仓库的全量的监控扫描，包括C的阶段的一些扫描，还有包括质量门禁。

而且我们协同容器的pass团队和操作系统团队去制定了内部的整个的基础镜像的一个构建，还有升级，还有包括它完整的一个安全管控的一个流程。在集群安全的风险管控方面，我们会定期去做集群的组建的漏洞和风险配置的巡检，然后在容器运行时的防控方面，我们是默认覆盖了公司自研上云的全部节点主机，可以基于agent去实现呃精确到容器类的进程文件和网络行为的监测，可以去进行一些恶意行为的检测和异常行为的检测和阻断。

接下来给大家带来一些我们在实际的这个内部的运营上面的一些实际的一些实践，呃，第一个的话就是。目前的安全运营，其实我们也是聚焦在镜像安全的治理，还有漏洞的应急及其安全的加固和容器入侵响应的这些主要场景来进行，第一个分享的是一个镜像安全的治理的一个经验，那么呃，大家都知道，其实整个容器的一个业务镜像，它是一个逐层打包，逐层生成，逐层引用的一个过程，它有点像是一个。错，就是有点像是一个树林，然后基础镜像可以理解，它就是里面的树根，只有把根儿治好了，它的整个上层的业务进像的风险才能够得到一个系统性的收敛和可控。所以我们在内部其实是呃定义了一个整个基础镜像的一个安全管理的一个规范流程，并且明晰了相应的一些安全责任的模型，并且制定的一些机械的一些要求，再结合我们的DEMO DEMO off的平台，CICD的一些插件，还有包括一些门禁的安全，门禁的一些插件去进行一些卡点的落地。

这块的话是另外的话，我们也会对整个镜像层面的一些镜像的一些漏洞的发现，去进行常态的漏洞的运营，还有一个重大的还有包括在一些0DAY的漏洞的一些应急。其实围绕着漏洞的运营和应急的一些响应的场景这块，我们去实现的一个完整的一些漏洞管理的闭环，闭环啊在这里面其实我们也做了一些微创新，就是。也做了一些微创新，比如说像最新版本的镜像过滤，然后镜像治理的一些智能推荐的这些特性，那么在重大漏洞爆发的时候，比如说像log破街，去年的log破街的时候，那么我们也把容器镜像作为整个安全运营的一个主要的抓手，那这块的话，我们有相应的漏洞的预警，并且跟进漏洞的修复方案，包括我们也提供了一个容器环境下的一些在线缓解的方案和一些一键自动缓解的工具，然后把整个从组建到镜像再到容器的一个场景的运营方案也输出给到云上的客户侧，帮助客户去做好这样的一个漏洞的一个应急。

第二，第二类重点的场景是发现集群的环境的漏洞和配置风险，去实施一个安全的加固，这样是保障整个容器的基础设施的安全。除了这个巡检之外的话，我们其实也在内部也在开始去实践整个集群pod的一些权限管控，包括像去落地整个的一些的一些策略，包括对O整个升级的OPA的一些机制，现在也在开始展开一些应用的一些实践。这个的话是运行时，运行时的话，目前我们可以做到深入容器类的入侵检测和防护，可以去深度感知容器类的入侵事件，然后的话可以去实时上报被攻击的容器，自动拦截视线的容器。

嗯，上面整体上分享了腾讯云从攻击方和防守方两个角度左右互搏，以攻促防的一个进展，最后是分跟大家分享一下，就是整体上整个云原生安全在合规标准还有安全成熟度趋势方面的一些进展。首先的话呢，从合规的角度来看，其实呃，我们也看到目前网络安全等级保护中关于这个容器安全的一些扩展要求，现在也是在一个制定的过程当中，当然整个等保的落地周期会比较长，但是我们也相信这块其实已经在已经在逐步的建设中了，那么其实对标等保2.0的要求，我们可以把整个云计算的这个扩展的要求，可以对标到整个容器云的环境，我们也可以看到，其实基本上整个腾讯云的容器安全服务能力已经可以去支持相关的一些相关的一些安全能力，满足等保的2.0的要求。然后另外的话是一个标准相关，就是目前的话，其实像国际上的话，NTC，还有包括美国像C，然后国内的话，像信通院和C也分别在制定一些云原生安全相关的一些标准规范，这个是整个腾讯安全这边主力参与和贡献的一个云原生安全的一个成熟度的模型，以及相应的评估方法，那么这块他们我们会涵盖基础设施、基础架构、云原生应用研发、运营和安全运维等五大安全域，然后其中会细化出来400项安全指标的评估，那么最近腾讯云自身的云原生安全能力也是整体拿到了L4这个优秀级的能力认证，是整个行业的一个最高的水平。

嗯，这个是对标着我们刚才说到的整个架构架构以及相应的能力成熟度，未来的话整个云原生安全能力的一个全景图，当然我们相信整个云原生技术也在逐步的一个发展过程当中，相应的安全能力的建设和需求，它也是一个逐步变化的，所以这块其实还是在一个逐步的一个持续发展的过程当中。

最后的话就是腾讯安全也牵头和信通院和清华一起成立了一个行业首个一个云原生安全实验室，并且发布了首个云原生安全的一个测试平台，这个测试平台的话，目前其实基础框架已经建设完成，目前正在行业在参与到这个测试工具，测试工具的完善和建设过程当中，未来的话，我们在实战演练的阶段，会去扩展到一些实战演练环境去聚焦一些，呃，面向云原生的一些技术能力的一些实战化的一些验证。攻防实战和运营提效其实是整个云顶实验室在去做云原生安全的研究和落地的过程当中，一起坚守的一个主要的一个理念。以上就是我的对整个云原，腾讯的云原是安全攻守道之的分享，感谢大家。好的，感谢陶芬女士带来的精彩分享，那也感谢我们今天分享的四位嘉宾啊，相信通过四位嘉宾带来的精彩分享，大家对如何守护云原始安全的问题有了更全面的了解和更深入的思考，那接下来呢，就进入我们干货满满的圆桌对话环节，圆桌对话环节呢，我们邀请到的是刚刚带来精彩分享的四位嘉宾，北京赛博英杰科技有限公司始人董事长谭小生，高途集团Co董一西，中科院计算所高级工程师李明宇，腾讯安全云顶实验室云院生安全产品总监陶芬女士，四位嘉宾呢，将围绕我们今天原桌对话的这个主题，企业如何搭建有效的云原声安全体系来进入我们的原作对话的探讨环节，同时呢，我也提醒我们线上嘉宾啊，刚刚在四位嘉宾分享的过程中，也有嘉宾在我们的呃，交流群里面有在提问，我们已经工作人员已经。

收集上来了，稍后呢，我们会在这个环节一一给大家进行解答，在我们原则对话环节的时候，也欢迎大家积极留言，积极参与啊，我们可以跟线上的嘉宾一起共同探讨我们今天的圆桌的主题，同时呢，我也提醒一下我们所有的线上参与的嘉宾可以填写我们的调研问卷，之后呢，我们呃会根据大家的意见和建议啊，提供更好更完备的内容提供给大家，好的，那现在呢，我就邀请四位嘉宾打开摄像头和麦进入我们的圆桌对话环节。

好，那首先啊，我想请教一下，嗯，首先我想请教一下谭校长啊，嗯，刚刚您的分享啊，其实也有提及了一些，那我们知道这个云原生的广泛应用啊，企业的呃，系统的架构确实是越来越复杂，我们云计算应用的这种威胁会越来越多，想先请教您一下云原生架构呃，主要会导致哪些安全风险和挑战呢？想这个问题先请教一下您，谢谢。

谭校长，您看一下您的麦，谢谢。OK，好的好的，可以听见了，嗯，好听到了是吗？嗯，其实刚才陶芬在在讲的时候已经是讲的非常全了。他这个我觉得就涵盖了这个就是你的问题的，就所有要回答的这个这个这个东西。呃，对，我我刚刚听唐飞女士确实在PPT里面内容非常全面，所以我是呃主要是想请您看看有没有什么要补充的，所以就这个问题啊，看看您的观点，还是说呃，您也觉得唐女士已经涵盖了几乎所有的内容了，对，是的，他这个东西，而且是不仅仅是非常的成体系，而且呢是呃他讲的内容，其实这个这个非常非常之之详尽。

好的好的，感谢陈校长，从安全，然后到这个从静态的到动态的，呃，基本上全覆盖到了。好的好，谢谢谭校长，那嗯我们知道啊，就是云原生的应用啊，其实在各行各业里面应用的也非常深入了，刚刚也提到了会产生哪些安全问题，那这个问题呢，我想请教一下一些啊我看到你呃也在哈，我我请教一下，在咱们嗯高途集团在构建这个体系之前啊，啊有没有做过一些呃基础能力的，呃建设这个基础能力呢，也是想啊给我们线上的嘉宾一些参考，我们建立这种技术能力的时候，有什么样的好的建议和经验分享呢？

请教一下一嗯，哎可以可以听到吗？啊可以可以，嗯那个营原生安全这一块，比如说我们可能遇到的，嗯，在云原生这个环境下，可能最大的一个挑战，因为我们知道云原生嗯产生的一个依据，可能主要是企业为了快速的，快速的依赖于或者说快速的适应整个云的一个发展，让它它的业务可能它的变动啊，或者说它的横向扩展能力啊，是能够快速的去迭代啊，那那在这种环境下，那可能产生出了比如说像基于刀的对吧，基于KS的这种这种容器或者镜像类的这种快速去比如说能够上线下线啊，那可能产生的问题，其实就是刚才那个咱们云顶的，嗯，咱们云顶这边的老师讲的就是，呃，我们觉得可能产生的新的最大的问题就是比如说这种镜像的深度啊，对于黑产镜像的个深度的一个挖掘，比如说像dog啊这种。

供的仓库啊，那这个东西在企业，呃，比如说对于我们这个，对于我对于我们这种甲方企业来讲啊，虽然比如说因为我们不专门研究这个啊，那我们比说我们不管是投入多少人力啊，或者怎么着不能够去完整的去追踪一个，比如说一个黑产团伙，他对于这个镜向上面的一个一个攻击啊，那我们只能去单点的，如说这次出现了比如说像老沟对吧，这种漏洞，那我们单点的去跟踪去处理这个问题，但是像刚才唐女士讲的啊，那在在整个公开的这种仓库里面可能有呃上亿的这种镜像，本身它就是恶意的镜像，那这种成体系化的这种构建，我觉得是需要专业的安全公司啊，有甚至专业专门研究这方面的人去去去去做的啊，这也是我在前面讲的就是第三第第三个方面就是我们可能需要跟一些更专业的公司去做一些合作啊，所以所以我们在在做基础建设的时候，其实我们主要是评估我们能做什么啊，那我们能做的就是基于嗯，在我们现有的。

业务下及原来的比说我们把原来的比如说S或者SC整个的流程这个体系，我们在的这个环境下啊，我们做的更扎实一些啊，做的更扎实一些，那么新产生的一些比较更加深度的和对抗性的东西，我们可能会选择跟第三方，第三方的呃，更专业的伙伴去去做一个合作啊。好的，感谢西的分享啊，那这个问题我也想请教一下，嗯，再请教一下，呃，陶芬女士啊，您有没有什么补充的，谢谢。抱歉，我刚才这边那个呃，没有电源了，所以离开了一下，对，就是主持人能麻烦把问题再重复一下吗？好的，就是说我们企业在构建我们的云原生安全体系的时候，需要具备哪些基础能力，你有没有什么好的建议？嗯啊呃，其实那个其实刚才在在我的讲述过程当中，其实所有的材料，其实在我们对外也都贡献到的，那个云原是安全的一个架构白皮书，架构白皮书和整个腾讯云的一个云原是安全白皮书里面了，其实在整个安全能力的建设的重点上，我觉得大家也可以去参考一个成熟度的模型，逐步的去建设，因为首先的话，比如说把我们的呃，目前在面向容器和K这个层面的一些基础的安全能力，就像我们刚刚看到的像镜像的安全，像这种运行时的一些基本的入侵检测和防护的能力，还有包括面向容器的集群层面的一些配置和一些漏洞的一些基本的安全配置和加固，我觉得这些基本功可以先做好，因为这块的话，整个的话，目前来看，从我们实践的成果来看，这块其实还是可以有。

落地的虽然会有一些挑战，但这个挑战其实也是整个云原生安全在企业内落地的一个必须经历的一个一个过程，对，然后的话，未来的话，其实随着你的整个云原生应用的这个成熟度逐步的增加，那未来我们可以再去往这个容器的网络这块上，可以去做一些能力的建设和补充，然后包括在面向容器的应用这块，在未来的这个呃，服务的应用的一些安全治理方面也可以去做一些工作，对。

整体来说的话，其实是可以基于一个呃，你的内部的一个建设的一个周期，当然这个一定是一个长期建设的过程，然后逐步的去挑一些基础的一些能力，可以逐步的去做，一边建设一边去运营落地。嗯，好，感谢陶芬女士的分享，那就这个问题我想再请教您一下，就是您，嗯，腾讯安全这边应该是接触和服务了非常多的，呃企业那在选择呃云原生安全产品的时候，是什么样的因素是属于驱动力是最强的，包括您刚刚讲的云原生这个成熟度，它是有一个阶段的，它在不同的阶段这个驱动力会不会有一些差异呢？这个问题也想请教一下您。

其实呃，我觉得在去采购云原生安全相关的安全产品的时候，这个还是从企业自身的需求出发，就是目前其实我们能看到呃有合规性的需求，也有一些自身的一些安全防护建设的一些需求，当然也会有一些在去应对这种攻防对抗，在攻防对抗的一些需求，但是整体上来说的话，整个云原生安全其实从今年的整个变化来看，呃基本上已经进入到了一个呃原有的合规和自身建设在加攻防驱动的一个三重驱动的一个整体的一个状态下了。对，所以的话，在做选型的时候，我觉得还是基于自身的这个需求出发，当然就是云原生安全的整个的一个落地，一定还是要跟放到整个企业的整个云，或者企业内部的整个安全，整个建设体系里面一起来做的。就是他，也就是我们面向云原生场景，肯定也不是割裂的，就是它还是要逐步的去适应，就是在整个企业大的整个建设框架体系类的。

嗯，好，感谢陶芬女士，那这个问题也想请教一下谭校长啊，就在我们云原生产品落地的过程中，有没有一些您见过的啊，失败的案例，或者说嗯，采过的坑啊这种，你有没有一些见解可以跟大家分享一下的？哦，这些我这边确实还没有什么案例，不好意思，好的好的感谢您，嗯，好，那我们看一下，其实那个在我们的视频号和我们的微信群也有一些问题，我在这里挑选一些问题请教一下，嗯，这个问题那我先挑一个问英语老师的一个问题啊，嗯，云原生环境中以应用为中心的称。呃，防护是不是可以详细的讲解一下这个，呃，涉及到哪些产品运行时防护其中有什么样的角色，这个问题请教一下老师好吗，谢谢。

这个因为防护这块，其实我我对于呃，就是就像我的PPT里面写了，就是对于这个防护，我们往往是分为或者是保护吧，往往是分为security和safety，那其实今天的各位呃讨论的很多的是security，当然这是防护中间或者说是因为我们一说防护肯定是考虑这个security的问题，说保护的话呢，或者安全的话，可能更广的安全，它有security方面还有方面，那我个人的这个在安全这块的研究的这个比较。多一点的，或者说稍微呃稍微了解一些的吧，不敢说研究的多，稍微了解一些的，可能主要还是safetyft这方面，Safety方面其实其实现在面对的一个比较大的问题就是就是我那个这片子里面也提到了，是是现在呃已有的这个一些safety的保护的机制，包括这个这个可用性的保护数据的呃备份以及啊等等这样一些方式呢，其实它它都是更加面向传统的这样的。

模式面向云生模式的考虑的，目前来说，嗯，就我看到成熟的方案还是比较少的，其实中间的这个原因跟谭校长之前提到的这个。Security的那方面，应用应用保护做的不足，其实是有相同之处的，就是一个很大程度上原因是因为提供这些解决方案的，就长期以来，比如说在过去的二三十年，30年里边一直提供这个，比如说呃，容灾的方案的这个这个这个高可用方案的这样一些，呃，团队啊，供应商啊，厂商啊，其实其实都是在一个跟开发其实不怎么去交流，就跟应用开发不怎么去交流的这个这种方式下去的。那他的主要的面向的，呃，面向的这个这个这个沟通方，其实主要比如说是基础设施的数据中心的建设团队，基础设施建设团队以及运维团队等等，他跟开发交流的比较少，然后认为这开发其实是应用，无论是内部开发还是第三方采购的，其实都认为是一个东西拿过来，然后搞清楚我要被哪些东西要保护，哪个容灾融哪些东西高可用，去面向谁做高可用它就可以了，但实际上现在整个这个事情其实他不太是这样，所以从safety这方面来看的话。

嗯，Safety这方面来看的话，那其实现在需要做的一个工作就是就是我们这个这个做这个呃，保护的这个这个保护方案或者容灾方案的这些公司厂商，高可能方案厂商可能需要高可能可能还好一点，就是因为它涉及到前面负载均衡，其实一些负载均衡啊，Ad的厂商已经很深入的在研究的这个问题，但是容灾备份其实是很多可能做的工作，还是需要进一步的推进跟开发的交流吧，就真正理解说语原生以后用户，其实其实很多用户他直接用你这东西的人实上。最终平台搭建完了，是要给应用。开发者其实他才是最直接的去用这个产品的人，用这些方案的人，跟他们加强沟通和交流吧，但中间有一个有一个最基本的一个一个一个在产品设计的理念方面的一个转变，就是我们从以前提供一些操作操作性的就就operation这种模式的这样的一些产品功能，往这个提供PI提供这种这种这种这种对提供API的这种方式的这种方向去转动，那这是我我能够分享的，可能更多的是偏向于这个这种就是safety方面的这种这样的保护安全的这个事情，那其实对于应用方面的。

应用方面的这个这个security方面的保护，呃，前面各位嘉宾其实阐述的已经非常的丰富，丰富了，包括像刘老师刚才提到这个问题，就是就是就是咱们有有有可能有听众问的这个护城河如何构建这样一个体系，有哪些方案，其实前面呃各位，特别是谭校长和和陶老师其实讲的已经非常全面了，所以这地方呢，我就。如果有什么就是就是也可以请其他各位嘉宾补充补充。

好，感谢米老师的分享啊，嗯，那还有一个问题想请教一下谭校长啊，因为呃，其实刚刚一西啊，在分享的过程中也讲到了高途集团他们做这个安全策略的时候，有一些是依靠自身能力，有一些更专业的能力啊，也会找一些外部的合作伙伴，那就这个安全策略的这种规划来讲啊，也请谭校长谈一谈，就行业的区别上有什么样的差异吗？比如说呃，像嗯，教育行业啊，金融行业啊等等的，可能是对安全的重视度也是相对比较高的，从您的角度，您可不可以谈一下您的看法？哦，其实就是首先看现在的云原生是在哪些行业使用的比较广，呃，据据我所了解的，目前是金融行业是云原生采取的是呃，这个原生用的比较多的一个一个行业，因为他们的这个技术的力量相对是比较强的，自身的研发力量比较强些，大的银行呢，往往有几千人，或者这个怎么样的这种团队。

他呃本身对于生对他能带来的好处呢，也是也是明显它属于是最早一批采用云生的呃这样技术的，那么因此呢，他也对云原生这个安全的这个也也有这样的需求，他们在做这些东西的时候呢，是一个呢，是自己呃有有人能够去了解一些，另外呢，他是采用第三方的呃安全公司呃提供的这个服务，你比如说他们和安逸科技和这个呃就是青腾等等，这样会会有会有这样的这种合作，这是一种类型的。呃，那么其他的。还有呢，就是比如政府也会有一些原生的应用，但是原生现在就是还是没有全面铺开的。这样的这种这个呃这个应用互联网就是呃，金融企业，互联网企业呃像游戏公司等等这样的，他对云原生的这个呃是最早的一批的这个用户，那么在他们的这个呃情况呢，其实会会有区别，金融呢，他是自己人懂一些，然后呢，再安全的合作伙伴给他这个提提供服务，那么对于互联网公司呢，这个情况又又又不太一样了，你比如说。

这个像大的互联网公司会倾向于自己搞全团队，然后自己很多很很多很多事情都自己搞了。但对于游戏公司来讲呢，的是用。可能是用原生当做他自己的一个服务的基础架构，那这个时候他呃会倾向于是找呃这种安全公司来给他提供服务，或者是由云的合作伙伴直接给供生的的这个这个服。呃，从我对这个，呃，云计算云原生的，再往下面理解，我觉得。随着采用云原生的，呃，用户呢，越来越多，它更多的依赖于这个云服务商本身给他提供的云原生的能力。或者是再加一些这种云原生的这样的这种，呃呃，就是安全的提供安全服务的这样的伙伴，你比如说这个采用多云，这样也是一种需求，就本来是我下面想问这个的一个一个问题啊，等会请请解释一下，就腾讯云在这方面的这个策略是什么样子，因为现在用户有一种需求，它是多云。

那么就是在腾讯云内部，你是可以给他提供云原生的各种各样的这个服务，但是一旦这个用户如果是用多云的时候，他马上就会有麻烦，他比如说他同时用腾讯云，也用阿里云，或者用金山云。那这个时候这个用户的这个安全的这时候该怎么办，那这个也就是国内和国外的这个生态上的不太一样的地方。就是在在美国，你像这个AWS，这个cloud等这样的这个。他们呢，就是这个。第三方的商或者安全服务上有更呃大一点的生存空间，在国内呢，你看刚才腾讯云这个云生自己都做的那么好了，那么安全厂商还有什么样的生存空间啊，不能这样，但是对于这个最终的用户来讲，他其实是有这样的这个需求的，他有呃这种对于小一点的这个企业，他自己没有能力去搞好他原生的安全，他就这个最对他来说最经济的是采购。

这个第三方的安全安全服务，那这安全服务呢，卖家有可能两个，一个是云厂商自己，一个是呃安全厂商。那这个生态这个就是在国内和美国是有有有差别的。但是呢，就是不管是谁，就是由。第三方来提供这个，呃，云安全的这个云原生安全的这个服务，这个应该是一个将来的这个这个主流。嗯。呃，我们现在的话，其实已经也也有服务了不少的客户，他就是像谭校长说的这种多云的场景和混合云的场景，那基本上我们现在可以做到就是呃控制就是整个server的后端控制台可能是在腾讯云上，但是我们的agent其实也可以，就是不管是主机形态的agent，还是呃用户更接受这种以这种云原生的这种容器形态的方式去部署的都可以，而且是可以很方便的部署到它的多云环境的这些其实这块的整个客户需求，而且现在这块也有很多的客户，其实在多云场景下已经有满足了，然后谭校长想说的那个另外一个关于那个生态的问题的话，呃，腾讯安全其实它的整个生态一直是第一个的话就是呃整个云原生嘛，它其实是呃，立足于云的，所以我们的云原生，腾讯自己的安全的云原生安全团队一定是先要服务好腾讯云的客户，这是我们的一个就是云原。

生的一个根本嘛，同时的话，我们也会去更好的去支持客户的这种拓展的这种云场景，就像你说的多云场景和混合云场景，甚至是这种私有云的场景，我们也会逐步的去把我们的能力，服务能力去扩展到客户的这些场景上去，然后。

当那个厂商的合作和生态这块的话，就像那个腾讯安全的话，其实在呃，在自己的这个云原生的这种安全的产品上，同时我们也会有非常广泛的这个saras的这种安全的合作伙伴的厂商的引入，就是在这里面，就是呃，大家一起去整体上去做大整个安全市场吧，就像说整个云原是安全，它未来的整个产品边界也在逐步的扩展，呃，腾讯这边我们自己其实在某些云原生安全的场景上，其实也是和很多的一些合作伙伴的一些安全厂商一起在去，在一起在做，就像我们的像应用安全的这些领域。好，感谢唐女士的精彩分享哈，那这个问题我也想请教一下依西啊，因为刚刚谭校长确实说到这种多云的状态，应该是很多企业，呃都是目前是一个现状，那我相信高速集团应该应该也是这样的一个情况，那我们在呃选择的呃这个云原生安全产品的呃，这个一个考量是什么？另外呢，我们在选择这个安全产品的供应商的时候，有什么样的考量标准呢？也请您来分享一下，谢谢，嗯我嗯，然后我这边作为甲方来讲，我们在选择云原生安全的厂商的时候，我们主要有几个方向啊，就是有有几个方面的考量，第一个考量就是说嗯，我们自己本身能做什么啊，就像刚才谭校长讲到，我们自己本身有安全团队，那我们自己本身的安全团队能够为我们云上的一些业务啊，能够提供哪些保障啊，那么如果这些保障我们自己能够满足，其实我们自己本身就可以。

决这些问题，那么所以更多考量的，其实我们用的第三方的更多考量的就是来补充一下我们的能力，我们解决不了的啊，我然后我这边大概总结了一下，总共是有有三个方向，第一个方向我是觉得就是在供应链攻击这个方向啊，因为整个我们知道基于整个就是云环境啊，基于整个虚拟化，基于容器，在这一块大部分其实是通过一些开源的软件，通过一些开源的底层的东西搭建起来或者组合起来，那这一块的供应链的攻击，它是一个，第一个它的链条非常强，第二个它的技术性很强，那靠我们的团队啊，或者说靠我们团队，不管是呃人力啊或者怎么的，其实是很难去保证整个供应链的供给，那这一块的话，我们可能会选择通过第三方专业的公司啊，有专业的能力去提供保障，那么第二个就是整个容器和镜像安全这一块的一个保障能力啊，因为这一块就是整个容器的是，呃，整个容器底层的研究，它的技术门槛其实也是比较高。

那对我们来讲，比如说我们专门去招一个，呃，我们专门去组建一个专门研究，对一个甲方来讲，就是，而且整个公司就是说，呃，虽然说是一个比较大的上市公司，但是其实还没有说是特别大到在行业里面或者怎么着，呃没有那么多的就是说成本，然后来去投入一个研究的团队，专门来研究，比如说容器安全，镜像安全这一块，所以这一块呃我们会选择用呃云厂商本身提供的这种镜像安全或者或者容器安全的能力，然后来补充我们啊，那么第三个就是一些仓库的问题啊，就是公有公有云仓库的问题，那么这一块其实我们也会选择跟跟云厂商来合作，这块主要是一个呃情报的一个及时分享的一个能力啊，因为这一块，呃，就像刚才那个腾讯的伙伴这边分享的就是说，呃，因为我们没办法去挖掘这种黑产的团伙，或者说专这种专门攻击的，嗯这种嗯长期持续化，持续化攻击的团伙，然。

他们对整个公有公有仓仓库的这种镜像的投毒的一个大概的一个占比是什么样的，但是对研发来讲的话，比如说研发为了快速的，比如说适配这个业务，对吧，他们可能有时候比如说哎，顺手就从一个公有的啊镜像仓库里面，哎，他他他觉得好用，他就马上就就去拉一个镜像，然后去就去用了，但是这个镜像有可能就是比如说可能会有问题的，那导致比如说镜拉下之，可能涉及到一些容器的逃逸什么的，那可能会对我们E呃什么都会有些影响啊，所以主要就是呃，我们大概会去补充我们可能自己不能够去解决的一些问题啊，还有一个比较重要的一个点啊，我觉得可能是可能是在未来，可能我觉得可能会慢慢的凸显的会越来越严重，就是说我们的云环境，或者说云原生安全，其实呃，涉及到云呢，我们大部分的访问啊，或者数据的交互啊，其实都是基于浏览器啊，那么基于浏览器的话，那比如说浏览器本身的安全，或者说基于浏览器互相呃相互间的这个访问啊，那就比如说像浏览器隔离。

啊，这样的新型场景的技术，这个也可能也是我们会考虑的一个方向，比如说像像像外部应用的隔离啊，像这种技术啊，也包括底层虚拟化的一些离啊，就是云服务器的一些隔离，这个也是我们可能会要考虑的一个场景，会选择会和第三方的公司去做一些合作，因为我们自己本身在这方面的投入的话，成本可能会比较大啊。

嗯，好，感谢一心的分享，那下面还有一个问题也想请教一下陶芬女士，那我们其实这可能是安全选择，企业选择安全产品都会遇到问题，就是我们这个安全产品怎么样考量，就是选择它的投入和产出的这个呃比呃来就是它的呃收收益和收效怎么样能够直接的来评判这个你有没有一个好的分享，对请教一下陶芬女士这个问题，嗯，就像我说的就是呃看咱们去采购安全产品的这个，这个驱动力是什么？呃，如果是合规性的驱动的话，那我们肯定就是要先满足那个合规的需求，然后当然这个合规需求满足之后，最终我们还是会会回到这个，他在企业内部实际的这个安全落地的一些效果，就是我实际的一些效果，然后还有包括就是如果是特别是在应对这种攻防实战的场景下，那可能我会更加注重它的安全，就实战下的一个安全防护。

的效果，那么怎么去评估我的这个安全产品采购完了之后，我的实际带来的一个收益和这个我觉得这个事情就是。呃，我们目前其实呃在在今天的那个呃片子里面，其实最后一个一章的话没有展开去讲，就是我们其实也在尝试着和心通院，就是包括跟行业大家一起来做一个事情，就是去做一个整个的一个安全能力的一个有效性的诊断，包括未来的话，可能会以这种呃，包括未来去让这种呃人工的这种渗透测试，或者攻防演练，或者这种自动化的攻击模拟的方式，可以帮助企业去持续的去验证他当前的整个安全能力，就是安全控制的一个有效性，去帮他发现这种真正的这个高风险的问题，就真正的这个问题，安全的一些短板的一些问题，包括帮他去更好的去决策他未来的整个安全建设的投入，这个也是我们，呃，目前也在尝试着去做的一些事情。

嗯，好，感谢曹总的分享啊，那刚刚您提到的几个报告和白皮书啊，如果感兴趣的线上嘉宾啊，后续可以联系我们的工作人员啊，来来这个我们会在群里面做一些分享，那因为时间的关系呢，我就呃选取了以上几位嘉宾的这个问题来请教我们线上的几位嘉宾，那最后的一个问题了，我是想分别请教一下我们线上的四位嘉宾啊，怎么样看待云原生安全，以云原生以及云原生安全未来的发展趋势，就是这个问题想先请教一下谭校长做一下分享，谢谢。我觉得首先云原生呢是一件非常大的事儿，他其实是把软件开发的模式给改变了，你比如我是从30多年前开始做软件开发的，其实真正感觉到最大的冲击就是最近三四年时间。

觉得他的整个的软件从开发的方式到运行的方式，这个都是这个真正是彻底颠覆了这个呢，这是呃。它整个呃，就是整个的这个程序的运行的这个模型都变了，过去就在一台机器内部，或者在一个局域网上，这个能连的多台机器之间做，做这个做这个调用，那么现在呢，就是整个的程序完全都在上了，这整个的这个从编程的方法。到软件的生命周期，还有再再说远一点的话呢，其实把这个软件就是今天的，比如大量的就90%以上的开发会用到开源软件模块，那么这种软件开发的模型呢，就是也改变了，就说有走向呃开源模式以及未来会向群模式等等的，就是呃这个整个这个云计算会会带来它就提供了一种能力，能够让这个这个来的程序呢，可能是呃我有有一些有些功能是自己开发的，有些我就直接在网上去抓了一个什么样的这个。

呃，容器，然后跑起来，或者直接就是采用云上别人提供服务的一段代码，就把某个功能就就就提供了，整个整个方式是首先对于开发的模型是一种是一种颠覆，它是能够满足现在。人们就是对于生产效率提高的这种要求，要非常快的就就来，就要抓来用。这样的，这是一个软件开发模型的这个颠覆这个，呃，这本身也是一个进步，也也省得就是过去我要物理服务器，我要布虚机，其实都有一定程度的资源浪费，那他这个跑的时候呢，我这个才按照需要去拿过来，然后呢，我再按照需要，按照使用资源去付费，这样也是更经济性更强的一种方法，这样子，但这种模型呢，对于安全带来的冲击呢，也是非常之大的，它主要是这个，呃，安全的这种，呃过去呢，是基于边界防御，基于城墙防御的这种思想。

那么现在呢，就是这个资源变得越来越动态了，那么我的防线也要变得，就是要它要实现更细力度的呃控制，然后呢也要做到，比如这个现在的安全就要做到一次函数调用这种级别，我要做到API的这个安全防御，这种本身的对对安全也提提供了更高的要求。在这种呢，我觉得都是说现在的这种一种进步吧，因为他只只有这个过去的你这做城墙级的防御，这个不是说他就是应该就是对的，那他只是说过去因为这个威胁还没有到那种样，他用原来那种防御方法是是是有效的，那么现在你比如说像像零星啊等等这样的这种概念，在云原生里面其实也会涉及到，那那它其实其实提供的就是一个更细力度的一个控制。然后呢，动态的一种，呃，这种威胁的判定和权限的管理。这样的，这个这是我觉得，嗯，在整个基础架构的it，基础架构的变化和安全怎么做，这两个之间是一个互相影响的一个互动的关系。

嗯，这个在这个这个趋势看来是不会不会改变的，这个呃，对云原生或者是云原生下面的安全之类的，我都是是非常看好的，现在包括安全的未来的这种创业的方向，我也觉得就是在呃云原生安全等等这些，这是现在是一个非常大的一个赛道。好的，感谢谭校长的分享，那也请教一下一你也做一下最后的分享，谢谢。嗯，那个基于云原，呃基于云云云原生这个话题啊，就是我，呃刚才谭教也讲了，就是这个就对云原生产生的背景啊，就是说它，嗯研发呀，或者说业务啊，它可以快速的去迭代业务，那么对安全的挑战来讲的话，那就是安全可能不再像以前一样，比如说你你能够去，比如说呃一大块一大块的去做什么啊，那那现在的要求可能会更精细化一些，包括一些容器的管理，对吧，那容器可能比如说像那个像像腾讯的老师讲的容器这边可能对吧，可能就就几个小时对吧，几分钟啊，或者怎么着他上线下线的，所以我们快速的迭代啊，那同时对我们原来的安全的挑战，比如我们原来或者整个S，那它的要求，它的整个自动化的要求的能力啊，会更高啊会更高整个自动化能力，因为什么，因为你要复合业务的一个发展啊，为什么为什么现在大家都比如说业务都要容器化到上云，因为我们我们最近也在做那个成本优化，就是整个成成本优化下来的结论就是说。

通过容器啊，通过这种快速的通过云原生这种东西，我们的成本可以降至少20%啊，那降20%，那这样的话，对安全来讲呢，那你要适应这种变化，所以你的自动化构建的能力啊，包括你快速的比如说这种情报，情报应急响应的能力都需要加强啊，都需要加强，所以说对安全的人员来讲，它的攻防的能力啊，他的攻防能力，包括你思维的认知可能会比以前嗯更高了啊，原来比如说整个外部安全，对吧，你你你做什么入啊，或者那现在的整个在云，在在整个云原生这个环境下，你可能要思考的比如说啊，是整个比如说之间的一些安全方面的问题啊，那原来的比如说特别简单的一些什么赛后注入啊什么的，可能在在。

后面可能会越就就遇到可能会越来越少，它的攻击思路啊，可能是从整个供应链，从整个镜像，从整个底层啊，从整个更更高维度啊。的方面去思考这个问题啊，这个就是对安全来讲，我觉得可能更多的一个挑战就是你需要更多的精细化，你的思维认知不能再停留在以前啊，就是说通过这种模块化的东西啊，而而应该是通过更精细化的东西，然后去去更展现一个一个安全人员更高层面的一个认知啊对。嗯。好，感谢一心的分享，那这里我也请教一下陶陶总，您来先做一下最后的总结分享，谢谢。

嗯，OK，那个呃，我就回到云原生安全吧，对，就是一个的话，从整个技术趋势上来讲，因为我们最近也看到了，就像包括sa最近的一些那个新的一些那个议题嘛，其实可以看到就是呃，安全的这个基于云原生场景下的整个的可观测性，还有包括它未来的整个。大数据的分析，那么这个会对未来的整个安全的能力提升上会所以可以会带来一些重要的优势，因为最近的话，包括我们自己在内部去实现这种呃弹性容器集群的过程当中，会发现原有的这种像新的内核的这种EPF的新的技术会带来更高的性能，这个原来依赖于内核版本的这些技术的一些原有的一些技术限制因素，在未来可能不再存在了，所以未来的话，像基于EPF的这种新的内核的新技术带来的更高性能的一些，呃网网上的一些安全的一些可观测，包括一些网络的一些隔离的能力，这个会带来整个安全技术上未来也会有一个比较大的一个提升，这个是一个从技术层面，第二个的话，就是从安全能力的建设层面上来看，我也能看到，就是说随着整个云原生的一个成熟度和它的一个落地规模的一个不断的提升，那么安全的这个需求就是能力的需求，也可以从就也会逐步从当前的这些，我们重点这种。

从基础设施层面，就像我们刚才说的容器啊，镜像啊这块上会逐步往上去延伸，延展到网络层和应用层，所以未来的话，整个云在云原生这块的网络的隔离啊，微服务的应用的安全，应该也会是接下来的一个建设的一个重点，然后最后的话说一下在落地应用上吧，落地应用上的话就是。呃，整个未来因为整个云原生其实是始于容器而终于应用，可以看到这几年整个云原生技术的发展，更多的都是在强调上层的这个应用嘛，因为技术最终还是会上层的整个应用的一个服务的，所以对于云原生的安全的落地来讲，其实也是一样的，就是呃，整个未来的话，随着它的整个的一个应用的落地，那么我们会发现未来的话，面向云原生场景下，它的一个安全的治理，还有包括安全的运营，也会是未来的整个云员是安全的一个重要的一个趋势，对。

这是从三个方面，一个是从整个人员是安全的一个底层的一个技术上的一个趋势，第二个就是从它的整个安全能力建设的一个成熟度，未来的接下来的一个趋势，最后是一个就是呃，随着它的整个企业类的落地应用，所以未来的话，整个安全治理和安全运营也会是未来的整个云营是安全在企业内落地的一个重要的一个趋势。嗯，好，感谢唐女士非常全面的这个总结和分享啊，那最后请明老师您来做一下总结，谢谢。好的，嗯，安全方面我就。

嗯，不多说了，那个关于这个整个研生的这个这个发展，其实嗯，有一个我我认为还是很重要的一个方面，就是前面虽然咱们诸位，特别是谭校长多次提到这个对开发的知识开发的关注，以及对开发方式已经用构建方式的这种，这种甚至可以说是颠覆性的这种变革，但是现在我们看整个云体系其实对开发的支持还是不够。就是我们既然是要在一个平台上，一个呃构建这种分布式的这种的应用，但实际上我们现在这方面的开发框架还是不够完善。比如说。比如说虽然也提供了一些API来应用的构建，包括的这种误的理啊，生命原应用误理及生命周期管理等等，但它这些API还是比较基础的，那呃，另外一方面呢，像spring cloud等等这样一些这样一些这种微架构应用开发框架，那他们诞生的时候，其实还是严格意义上来说，还不是一个的这样一个时代诞生，它还基于机器模型，所以他会关注一些东西，是只有在机器上会有的东西，而对于这种这种平台化的，这种为真正平台的这些能力，其实它的利用也是不太够的，然后呃，然后我们看整个的这个这个工作的人的这个这个这个一些思，或者说是一些观点，其实现在开发者就是我看到很多呃企业很多客户里面的开发者，其实他对云，云原生的平台的能力，他的关注也是不够，他甚至说我经常听到有包括像呃，像前面几位嘉宾也提到了，说金融行业对云的云原生。

技术的利用是用程度是比较高的，但我其实也是到一些比较大的，当不是四大行，其实也是比较大的银行的开发人员会希望说，诶，你提供的这套能力库上提供的这云原生的这个这一些调试能力是能够等同于我机器上的，我开发完一套代码，我在机器上能这么跑，能这么调试，我在你的也要能这么调试，那你必须得把我以前的机器上，比如说我的一些调试手段的能力，你在Co上，在你的云环里面应该怎么用，要提供给我。

际是的，提供一些额外的能力去支持他们，而且他们应该去改变他们，改变他们思路，就将将来我们的应用应该更好的在云原生的环境里面去运行，而机器的这个环境，如果在必要情况下，我们需要有单机的环境，需要有这种机器的一台或者几台机器的这样环境去这到应用的话，那实际上应该是由机器。上面装额外的这样的一些中间件或者其他软件来兼容原生的那个环境，所以这个事情应该过来。的思路需要转变，而开发框架其实现在还是不够完善，这也是我们为什么看到像前两年像微软的分布式应用运行时会这么会很快的那个热度上升的一个原因，当然这方面的工作如果说仅仅是有待，可能还是。

还是还是相对还是比较单薄，就是其他的可能我们还会还可以期待一下有没有一些更好的框架或者运营时会去出现，然后关于整个整个呃，整个产业从业者的这个思，会不会说可以期待一下什么时候能够更往这个生的方向去演进，因为我们也看到。从这个横向上来说，这个也在扩展，包括边缘的一些一些能力的开发，包括我们以前有项目做过，就是把的能力延伸到边去，这样也能够，那但是你看这这问题就更大了，就是因为在边缘的那些开发者，就是边缘应用的开发者，其实他们很少关注云，他们更更就是云生的这些技术对于他们来说更加的陌生，但是其实有些能力，比如说是呃，是这种动态的更新啊，这种敏捷性啊，其实也是他们未来需要。或者现在已经在很多很多地方需要，但其实他们的边缘一些用的开发者，其实他们可能有更多的这个要是这就是我的一个观点吧，就是我认为未来的趋势可能我们还是会有，论是从人的能力，还是说是一些这个技术方面，呃，还需要进一步的为开发者去赋为真正的构建云人生的这个，嗯。

好。感谢明老师的最后的分享，那我们知道数字世界安全共生，那我们的云原生啊，在各行各业的这个技术的应用更成熟的时候，我们的云院士的安全会面临越来越多的挑战，嗯，那也期待我们今天四位嘉宾的精彩的分享，能给我们线上参与的嘉宾一定的启发，那我们也嗯，希望大家能够持续跟我们保持这种沟通和交流，共同探讨我们在数字世界面临的方方面面的安全问题啊，共同学习，共同分享，那也再次感谢我们今天线上的四位嘉宾的精彩分享，以及我们参与的嘉宾的啊，整个一个下午的线上的学习的守候啊，我也提醒线上嘉宾啊，为了后续能够提供更好的内容，提升我们的活动质量，我也代表主办方啊，真挚的邀请大家可以填写关于本次活动的调研问卷，同时呢，呃，完整填写调研问卷的嘉宾呢，我们也会送出主办方送出的。

享蓝牙无线运动耳机，感谢大家的支持，再次感谢四位嘉宾和嗯，线上嘉宾的参与，同时呢，呃，我也再次感谢我们所有的嘉宾的陪伴，我们四场啊，我们从四暂开始组织的四场不同维度的安全的论坛，如果本期包括往期的精彩的内容，也欢迎大家关注我们时代的公众号，可以听取我们今天的回放的内容。好的，那我们今天本场活动呢，就到此结束，那也期待通过本次的研讨会，助力起在云原生安全领域的创新与实践，构建起安全的护城河，后续呢，我们也会与腾讯安全一起联手打造更多精彩的内活动和内容，欢迎大家持续关注。好的，再次感谢四位嘉宾，那我们今天的活动就到此结束，我们跟线上的嘉宾再见，我们期待下一次活动再见，谢谢。

再见。再见，再见。