大家好，我是来自 Aqua 的工程师陈宇，明天次要想跟大家一起探讨下对于多云平安的问题。
具体的分享内容，我将从上面几个问题开展：
- 什么是多云？
- 针对多云场景呈现的平安运维方面的问题有哪些？
- 如何利用好的工具和办法解决这些问题？
什么是多云，怎么去定位多云场景？
多云平安是云和平安之间的一个穿插畛域，是这两个畛域之间穿插的一个新的细分。同时，这两个行业有一个很大特点，就是它十分可能造词！有十分十分多的新的名词在每年涌现进去，阐明这个行业十分欣欣向荣，蓬勃发展。
然而，也会带来一个不好的问题，它会使得每一个人对一些雷同的词有不同的认知。所以，咱们明天来说说这个 Scope 到底是什么？
明天的多云场景，依照大多数了解来讲，多云就是多个私有云。数据中心全副是在云上，例如有一部分在 AWS，有一部分在阿里云，这是一个典型的多云场景。
提到多云，大多数时候指的是云基础架构，这是介于基础架构的技术个性。如果一个基础架构具备一些原生云的个性，这种基础架构就是一个云基础架构。原生云的能力例如多租户、按需扩大、无中断部署、高弹性、高可用等，像 AWS，AirCloud，腾讯云的确是云，但多云场景下其实也有几个不同的分支。
第一个分支：私有云，没有线下的数据中心，所有数据中心的基础架构全副都在私有云上。
第二个分支：一部分数据在私有云上，一部分数据在线下的公有云上。
接下来，咱们探讨下第二个问题，在多云的场景之下，咱们会遇到什么样的问题？在讲之前，有两种场景，一种是纯私有云，一种是私有云和公有云的混合云，咱们在探讨的时候把这两种场景离开来看。
第一种场景：纯私有云，没有一个用户，没有线下的数据中心，所有的基础架构全副都在私有云上。
一部分在 AWS，一部分在阿里云。这时候能够看到很多表象上平安运维的问题，例如问题响应速度慢，施行安全措施复杂度低等问题。背地的起因到底是什么呢？一个是不同的云服务商在某一些技术的实现性上，它的技术栈是不一样的，导致了企业外部的一些既有的的规范没有方法在这些不同的云厂商上实现统一标准的残缺落地。坦白说，这个问题很难解决，然而又对平安非常的重要。
平安是一个十分难以量化的过程，这也是它的一个痛点。当初做平安更多的实现的办法是面加点的治理办法。面指的是攻击面，升高攻击面能够无效升高危险，但如果把攻击面降到最低，那失常的业务可能就没法开展。平安和业务之间是相互拉扯的关系。
平安事件做的越多，业务效率就越容易受到影响。所以当初把攻击面降到一个可控的规范之下，再把裸露进去的攻击面当做一个一个的点去解决，这也是目前采纳的最平安的一种治理方法。
一般来讲，企业外部都会有一套跟本人理论状况相匹配的基线规范。这套基线规范的订立十分麻烦，因为它须要经营，须要运维，须要平安 team 三方拉扯来产生一个基线配置的后果。这套基线的规范一旦订立下来之后，将来在业务扩容和业务新上线的的过程之中，要做的事件就很简略，只有 follow 之前定制好的基线，就能保障新上线的利用或是新扩大进去的的基础架构的攻击面都是可控的。
然而这个过程十分麻烦，当呈现多云环境之后，另一个问题就呈现了。同一套规范在一个单云环境下容易落实，但私有云和私有云之间对于某一些技术的实现上有差别，会导致在某一个云上能够实现的一些平安形式放到另一个云下来实现，会呈现问题。
举个例子：
有位客户在 AWS 上定了一个规范，因为客户应用是 AWS 的 kubernetes 的 EKS 服务，在 EKS 服务上，利用是分不同的等级的，有一类利用，二类利用，三类利用。
随着利用等级的晋升，利用等级的级别越低，平安水平反而越高，他们定了一个规范，对于一类利用，要做到的安全级别是做到容器级的微隔离。但客当户抉择另外一家云厂商做迁徙的时候发现，一类利用迁徙下来之后，没有方法做到容器级的隔离。
这个时候订立好的规范在另一个云上无奈施行。这其实是在多云场景下会遇到的问题。各个云厂商有一些通用性的规范，然而在技术的实际上有差异，一套对立的治理规范很难去落地，这就是咱们当初私有云上存在的一些问题。
在公有云和私有云的混合云的状态下，以上说到的问题全副存在。除此之外，还有一些其余的问题也就是私有云上的责任共担的问题。
私有云的责任是共担的，当呈现平安问题的时候，要去看产生这个问题的责任到底是什么，是由用户的责任导致？还是由私有云的厂商的责任导致？最终再确定这个责任到底在哪一方。
当然，责任的边界并不一样，这是在多云场景下比拟头疼的问题。那么，咱们能够怎么去解决呢？
首先，如果要去构建多云环境下的平安，有一些教训上的倡议。
如果要在混合云、多云状态下做平安，能够抉择的工具分为三个大类。
第一大类，一些传统的 vendorr 所提供的平安计划，例如防火墙，IPS 等。传统 vendor 比拟善于在线下数据中心去搭建架构。
第二大类，私有云厂商提供本人相应的平安计划。AWS，阿里，腾讯都有本人的平安管控计划。相比于第一种形式，这种计划最大的劣势在于能够利用到私有云本人的后盾。
第三大类，比拟新兴的云 vendor。当初这个畛域，所能看见的的分支基本上是分为五个：CWPP、CSPM、CASB、SSPM（针对 SaaS 服务的配置查看)以及 CDN。
因为这两个畛域自身十分靠近，所以 Gartner 也把这两个畛域齐全合并在一起，出了一个新的畛域，叫 CNAPP。所以 CNAPP 它不是一个新名词！它其实就是 CWPP 和 CSPM 的一个合并。
那么，在 CSPM 和 CWPP 这些畛域内如何去做平安建设呢？
先来看 CSPM 的的领域，CSPM 最次要目标是做私有云上平安的配置查看。因为私有云上提供了很多平安 feature，例如 AWS、硬盘加密、数据库加密等。
它提供的这些平安 feature，最终是否用好是用户本人的责任，因为没有配置实现而导致的平安问题，是应该由用户本身去负责的，这也是有 CSPM 畛域呈现的一个重要起因。
CSPM 的查看的最大特点在于它是无需借助 Agent 实现，因为 CSPM 查看的是治理立体，不应该跟数据打交道。整个的过程对于用户来讲是一个通明的无装置的过程。这也是 CSPM 当初的一个根本方向。
第二块，大家对于 CWPP 的定义始终比拟含糊，什么属于 CWPP，这个 Workload 代表的是什么？Workload 其实是一种云的根底资源。
云的根底资源通过几代不同的演变，产生了一些变动。最早的云根底资源可能会应用一些虚机。在前几年，咱们会更多的应用 Container，kubernetes 服务，ECS 服务或者 Azure 上的 ACI 服务都属于 Container 服务。在将来，大家会更多的接触到 Serverless 服务。
Serverless 服务比如说 AWS Lambda，Azure Function 这些也会变，这也是 Workload 的一部分，所以，CWPP 涵盖的局部是从虚机开始，始终到 Serverless 完结，这些都属于 CWPP 所涵盖的爱护范畴。
对于 CWPP 如何做爱护？这个外面所包含的货色太多，暂不开展来讲，因为它包含很多跟 CI/CD、kubernetes、主机底层打交道的内容。
要实现平安爱护，有哪些工具能够去抉择？
A 路线是开源组建的路线，比如说 CSPM 的开源组件 cloudsploit，针对 IaC 的安全检查的组件 trivy，在 GitHub 上能够看到应该是一万两千 star 得分，还是相当高的。这些是针对 CSPM 比拟好的组件。
针对 CWPP 的开源组件，比拟闻名的有 Falco。Aqua tracee 新出的 Tetragon 是在数据的立体借助 eBPF 做观测十分好用的组件，都是开源的。大家有趣味的话也能够去测试应用，在 GitHub 上都能找到它的应用和源码。
B 路线是商业套件，抉择比拟多，像 Aqua 本身其实也有商业套件，还有很多厂商都会有。
最初，在抉择商业套件或开源套件的时候，最须要留神的是对于老本。
掂量老本时，购买老本是所有的老本外面最低的，之后还有相应的保护老本或集成老本，以上所有的老本加在一起才是抉择套件的总成本。
这两条路线的抉择自身没有对与错，只有适宜不适宜，如果自身的平安团队能力比拟强，齐全能够去应用开源套件，十分好用。如果心愿更多的精力 focus 在业务平安上，能够去选用商业的一些套件，看企业本身的理论状况去抉择。
获取完整版 PPT，请填写问卷：
https://wenjuan.feishu.cn/m?t…
视频回放链接：
前线沙龙第 26 期——平安→云平安 →多云平安
https://www.bilibili.com/vide…
前线平安平台：https://www.huoxian.cn/
前线 Zone 社区：https://zone.huoxian.cn/?sort…