陈宇（Aqua）-安全-＆gt;云安全-＆gt;多云安全

大家好，我是来自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=svCwWH1yEyDi-67t2&mode=sidebar-semi

视频回放链接：火线沙龙第26期——安全→云安全 →多云安全https://www.bilibili.com/video/BV1VF411F7o6/