云安全的未来

自2006年AWS推出EC2之后，云计算的破坏性力量改变了整个科技行业。随后国外Google的GCP、Microsoft的Azure和国内的阿里云，进一步带动了整个云市场的发展。IaaS、PaaS、SaaS的云计算分层结构被大家所熟知，公有云、私有云、混合云在每个单位云的建设中被反复提及。随着云计算技术对科技行业的重塑性影响之下，其对安全的要求也是具有突破性的，传统的安全思路和产品已经很难适应云的环境。换言之，传统数据中心的安全方案在云计算时代下已经不适用。在云计算发展的十来年中，已经出现了不少针对于云安全的产品。随着云计算的逐渐普及，云安全的重要性越来越高，在安全市场整体的发展中，发展的速度比其它类型的安全产品都要迅速，这也是信息基础设施改变所带来的强有力的推动力。目前针对云安全类型的产品已经面向了市场，受到了市场的认可，不过国际上的产品和市场跟中国的产品和市场还是存在很大的区别。这其中有各种各样的原因，有云计算发展阶段的原因，也有云计算建设习惯的原因，也有云计算生态比较恶劣等原因。即使如此整个大趋势还是不变的，在这里可以畅想一下云安全的未来。

云安全的市场趋势

_Forrester_咨询机构预测云安全整体市场2018年56亿美元市场，到2023年会到127亿美元，年复合增长率在17.6%。其中在2018年，公有云原生平台安全占到70%左右的营收。国外的公有云的采用率远远高于中国，所以这个数据也能说明一定的问题，公有云确实才能发挥真正云计算的优势。但是在国内问到采用安全方案的时候，更多的是采用第三方的安全供应商、云平台本身提供的安全产品以及外采服务三种形式混搭的情况，同时第三方安全产品的选择比例高于另外两者。

图1：不同类型云服务采用安全产品比例

从收入层面来看，虽然在国外公有云平台提供的安全占比很高能到70%左右，这跟云计算发展的阶段有关，国外已经成为云计算双头垄断AWS和Azure，而在国内私有云和行业云的占比更高，跟本身技术和投入有关，大部分还会依赖于第三方的安全公司。主要分了三大部分的产品，除了平台提供的安全产品之外，一部分是云工作负载方面的安全产品，另外一部分是云安全网关类型的产品。这个数据国内跟国外出入比较大。

图2：全球云安全市场超速发展

如下图所示，按照行业来分，可以看出来金融服务、专业服务（律所、会计事务所、研发机构等）、运营商和政府合起来占了近一半市场。这个数据跟国内很接近。

图3：2023年全球不同行业云安全方案发展

云安全的主流产品

云安全产品可以从两个方面进行分类，一方面是云计算提供方直接提供的安全产品，另一方面是第三方提供的安全产品。前者也叫云计算服务方原生安全cloud native security，这里指的是云厂商配套云服务提供的安全产品，跟下文提到的cloud-native security还是有区别的，后者指的是适配云原生服务（容器、微服务等）的安全产品，注意区分。

• 云平台的安全产品

云平台本身也是云安全的供应商，这点毋庸置疑。但是跟第三方合作厂商的关系以及生态的理解，每一家云厂商又都是不一样的。AWS无论在是云计算相关产品还是云安全上都做到了行业标杆，其对于云安全的定位和做法引领行业。如下图所示，可以看出来云平台提供的安全能力，AWS和GCP是领导者，接下来是微软和阿里云。

图4：公有云平台提供安全产品WAVE图

Forrester这篇报告中提及Google在GCP中不断投入安全能力，无论是在控制台还是API方面都有细粒度的安全配置策略，同时有大量的安全认证和广泛的安全生态，也提供Guest OS的安全以及K8S和容器的安全。但是没有硬件的安全支持，也缺少安全总览视图。

AWS的API是最友好的，在IaaS层思考的安全最多。控制台有IAM类的功能，通过inspector这种产品解决Guest OS的问题，VPC解决网络隔离的问题，Macie解决数据发现和分类的问题。但是KMS很难用，Hub也无法灵活配置。

微软的Azure安全结合了Powershell的能力。大部分Azure的安全能力都可以通过Powershell的脚本实现。提供很多安全类产品，包括MFA、RBA、KMS、IPDS、FW等，正准备提供无密码验证机制，集成Microsoft Graph开发工具，以及提供工作负载的安全基线功能。

阿里云安全有很高的SLA以及简单的Guest OS加密机制。缺少ISO 270017/19 认证体系并且安全生态伙伴比较缺乏，同时并不支持容器原生的安全。计划增加数据安全，DevSecOps的相关内容。

这篇报告内容较为简单，我们从AWS的年度报告和目前的原生安全产品可以看出来了一些内容。2019年AWS云安全报告提及，数据泄漏，数据隐私，以及机密性是客户关注云安全的最重要的三个问题。

图5:云安全最关注的问题

公有云最大的威胁被认为是错误配置、非授权访问、不安全的接口和API以及账号、服务或者流量被劫持。

图6：公有云最大的安全威胁

AWS的原生安全产品中71%的受访者使用了IAM产品，65%使用了CloudWatch，45%使用了CloudTrail，还有42%使用AD管理以及35%使用了Trusted Advisor。

图7：AWS安全产品和管理服务事情情况

对于传统网络安全产品，85%的人认为无法工作在云上或者发挥很有限的功能。

图8：对于传统网络安全工具在云上使用效果

采用基于云的安全方案，主要是基于快速部署，节省成本以及可以在任何地方接入保证安全的考虑。

图9：对云安全方案选型考虑因素

以上节选的几点说明了几个问题，使用云计算的时候，客户非常关心数据安全的问题，大部分客户使用了云计算平台提供的安全产品，客户对于传统安全产品对于云的适配有清醒的认知，无法直接用概念洗白，更喜欢采用基于云平台的安全产品。

AWS平台提供的原生的安全产品包括五个方面：身份访问控制类、检测式控制类、基础设施保护类、数据保护类以及合规类型。

表1：AWS平台提供的安全产品

可以看出来AWS自身的安全产品还是比较齐全的，但是做其深度又如何呢？可以看几个例子。Trust Advisor的安全功能极其微弱，只有S3 存储桶权限、安全组、IAM 使用、根账户上的MFA等。

图10：AWS的Trust Advisor产品包含的功能

Inspector是一款CWPP类型的产品，但是由于功能很少被Gartner定义为漏洞扫描和配置及合规产品。

图11：Inspector产品介绍

GuardDuty算是利用AWS自身数据源做的安全检测产品，利用了CloudTrail、VPC Flow和DNS的日志，并结合威胁情报来进行报警。

图12：GuardDuty产品介绍

Macie算是一个数据安全类产品，进行数据的发现、分类和保护AWS的敏感数据。

图13：Macie如何工作

Security Hub像是个小型的AWS的SIEM产品，集合了GuardDuty、Macie和Inspector的产品，同时还可以集成相关合作伙伴的产品。

图14：Security Hub产品介绍

AWS这些安全产品的真正目的不是全面保障客户的安全，出发点是如何让客户使用云的时候能够安全，简单来说就是如何安全的使用云计算。因为很多情况不是AWS自身的安全性不够，而是客户没有很好的配置导致的安全问题，比如很多S3的配置不当引发的数据泄漏的问题。

AWS对于云安全责任共担模型的理解以及安全生态的重视，形成了目前的一系列合作伙伴产品在market place上售卖。AWS友好的安全类型的API，让很多云安全厂商可以很好的利用这些API来开发基于AWS的安全产品，这也引导了Azure和GCP的云安全建设思路，这样可以把云安全生态能够真正的建立起来。国外的很多云安全公司都在利用这些平台的API来开发自己的安全产品，在基础数据收集以及展示方面能极大的减少开发的复杂度。

反观国内，无论公有云和私有云在安全上都在大包大揽，首先云安全责任共担模型都没有充分认知，更没有将其传导到消费者那里，导致安全建设的思路还停留在数据中心安全的层面。其次，这种投入并不是经济的做法，安全行业本来就是个细分的市场，CSP对每个安全产品分4-5 个人来开发维护，提供的真正的安全价值也有限。最后，在生态建设中的思路及其不合理，不开放API和相关接口，只对自身产品开放，这种云安全的做法感觉就像作茧自缚。

• 第三方云安地方全产品

说到云安全的第三方产品，上面也有简单提到，目前来看新兴的比较主流的安全产品为CASB（Cloud Access Security Broker）、CWPP_（Cloud Workload Protection Platform）和CSPM（Cloud Security Posture Management）_三种，也可以叫他们为云安全三剑客。三者的关系可以通过下图可以表示出来，在云计算的IaaS、PaaS、SaaS三层的适用性可以区分出来。CSPM适合于多云环境或者是Iaas+fPaaS的情况；CWPP适合于IaaS或者容器为主的IaaS；CASB适合于SaaS或者是aPaaS的情况。这三个产品都是伴随着云计算的兴起而产生新的安全产品。

图15：云安全产品使用场景和使用效果

CSPM叫做云安全态势管理，核心解决的是云计算平台在使用过程中的配置安全问题，这类配置问题包括了几种类型：访问控制类、网络类、存储类、数据加密类等。CSPM能够自动化的扫描及时发现上云的风险，本质就是使用云服务的安全控制台。

图16:CSPM使用场景和效果

最常见的就是存储类的问题，AWS因为S3的配置问题，导致敏感数据对外引发了很多起安全事件，如下图所示。

图17：S3因配置问题引发的敏感数据泄露事件

网络的控制包括RDP或者SSH是否对外的问题也是一个应该考虑的问题，还有包括一些API的对外的管理，还有密钥的管理也是很大的一个问题。CSPM的典型使用场景包括：合规评估、运营监控、DevOps 集成、事件响应、风险识别和风险可视化。下图表示在多云模式下CSPM的部署方式。

图18：CSPM部署方式

目前CSPM相关功能在其它产品中也有所覆盖，比如CWPP和CASB类型的产品有涉及这个领域的功能，同时一些云计算厂商也有基本的设计，包括上面介绍的AWS的Trust Advisor就是类似的功能，Azure 的Security Center和GCP的Security Command Center。但是每个云上安全设计的只解决了自身云的问题，混合云的情况就需要第三方厂商来统一管理。多云的管理平台有时候也会有这种能力来加强对多云安全的问题做一些工作，也会覆盖一些CSPM的能力。所以这个产品本身更像是一种能力被其它产品或者云厂商拥有，作为单独产品的竞争力不够。目前CSPM的厂商还集中在AWS上面做，毕竟AWS的客户数量还是占大多数，但是做的深度并不够，AWS现在的云计算产品越来越多，但是CSPM涉及到的产品类型比较少，还集中在一些基本的产品上，比如S3。这个产品的定价是基于云管平台的管理员账号数量，每个账号的使用费用大概在1000美金左右。

在介绍CWPP云工作负载保护平台之前，说明一下CSPM和CWPP产品的关系，如下图所示。CSPM在云计算方面是管理控制层的安全问题，CWPP是控制数据层面的安全问题。

图19：CSPM和CWPP区别

关于CWPP产品类型的演进，笔者之前的文章已经涉及，这里就不做展开。对于混合云下CWPP类型的产品部署模式示意图如下：

图20：混合云场景下CWPP部署模式

但是这个图还是相对简单，只是一种VPN的方式进行连接服务端，青藤产品遇到的情况比这种情况更复杂，有代理模式，有分级模式也有NAT模式，目的就是为了统一纳管。CWPP产品现在分为三个大方面的安全能力：攻击面减小、执行前防护和执行后防护。

图21：CWPP三大安全能力

CWPP演进至今，跟上面提到能力结合一起分为了七个小的门类：广泛能力、容器、微隔离、内存和进程保护、Serverless、EDR、漏洞加固和配置合规类型。

图22:CWPP基于三大能力的七个变体

最后介绍一个在国内“水土不服”的安全产品：CASB（云访问安全代理）。CASB这个产品在Gartner是已经有魔力象限的产品了，成熟度比起前两个产品来说更成熟，市场的空间已经较大，肯定是作为一个独立产品而存在的，而不是一个功能。为什么在中国的环境下“水土不服”，核心原因跟我们的IT环境有很大的原因。美国的整个办公环境在SaaS领导者Salesforce推进下，得到了全面的SaaS化办公环境，例如CRM使用Salesforce，HRM使用Workday，运维使用ServiceNow，安全使用Crowdstrike，市场人员使用Hubspot，办公使用office365 或者Google Docs，存储使用Box或者Dropbox，IM用Slack，视频会议用Zoom。这些SaaS化的办公产品完全支撑了SMB甚至一些大客户的日常办公，这些SaaS应用的安全就变得更加重要起来。本质来说SaaS化的应用场景带来了CASB这种产品的需求，乃至Gartner断言CASB对于云就相当于防火墙对于传统的数据中心这么高的评价。

反观国内的办公环境，虽说已经有一些国内公司在SaaS化办公环境下做了一些内容，但是还不成气候，渗透率一直不高，主流还是传统的办公环境和本地化部署的软硬件，在这种情况下CASB的需求并没有凸显出来，甚至有些时候国内把CASB理解为传统办公环境的应用安全。

CASB这个产品有四个核心方面支撑：可视化、数据安全、威胁保护和合规。所谓的可视化是表示在企业中发现影子IT，对于所有的应用都有识别的能力，不会遗漏一些未知的SaaS应用。数据安全包括了数据分类、数据发现、以及敏感数据处理，可以叫做云端的DLP。还有些比较硬核的能力会使用部分同态加密技术，把数据加密存储在云端，然后直接对密文进行处理，最终在本地的又是明文。威胁保护这块主要是访问控制，这里提到的访问控制会跟UEBA结合，本质上来说就是零信任机制，同时有些厂商也会OEM一些反恶意软件和沙箱类产品来检测威胁。合规来说重点的就是CSPM的一些能力集成来达成合规的一些要求。对CASB厂商评估的六大能力也在这四个方面之中，如下图所示：云风险评估、适应性访问控制，DLP、应用可视化、CSPM、加密和脱敏。

图23：CASB厂商能力评估六个维度

CASB的基础架构如下图所示，数据来源可以来自四个方面：1. IaaS或者SaaS的API；2.正向代理；3.反向代理；4.已存在产品的数据，包括SWG或者FW的数据和API。对于正向代理或者反向代理获取的数据只是技术层面的，但是IaaS和SaaS的API以及其它产品的数据是在国内很难获取的。

图24：CASB基础架构

下图是一个CASB的一些标准使用场景，企业内部的人员被CASB产品安全保护着，在访问IaaS、PaaS还是SaaS上都会过CASB的监控，外部人员想要进入企业内部也需要CASB的认证，CASB也防止了一些不合法应用的访问。

 图25：CASB典型使用场景

最终总结一张这三个产品在IaaS层面的部署图：CSPM通过API交互来实现功能，CWPP在每个工作负载上部署，CASB既使用网络代理的数据也使用云平台的API数据。

图26：CSPM、CWPP、CASB在IaaS层面部署

云安全与SD-WAN的结合

今年的云安全炒作曲线出现了一个新的产品方向SASE（Secure Access Service Edge）安全访问服务边缘，也是需要重点介绍的云安全领域重磅产品。说它是纯粹的安全产品又不尽然，它还有网络的属性，比如在企业网络和边缘计算的炒作曲线中，它也赫然在目。虽然属于一个比较初步的阶段，但是这个产品的未来可期。

图27：2019年云安全炒作曲线

图28：2019年企业网络炒作曲线

图29：2019年边缘计算的炒作曲线

Gartner今年有一篇重要的报告叫做《The Future of Network Security Is in the Cloud》，《网络安全的未来在云端》国内已经有人做了相关翻译，网上可直接查阅。传统的数据中心的Hub-spoke这种轮毂结构很难适用于现在的数据化业务，导致业务生产力低效、用户体验低下以及建立专线成本高昂等。“以数据中心为核心”的传统网络和网络安全体系架构已经过时，已经成为了数字化业务需求的阻碍。未来会从传统的重分支迁移到云为核心的轻分支、重云端的方式演进。

在灵活地支持数字化转型的同时，SD-WAN技术的大范围使用，这是SASE 新市场的主要驱动因素。这个市场将网络即服务（如，SD-WAN [软件定义的广域网]）和网络安全即服务（如，SWG、CASB、FWaaS [防火墙即服务]）融合在一起。我们将其称为“安全访问服务边缘”。它主要是作为基于云的服务交付的。企业对基于云的SASE 能力的需求、市场竞争与整合，将重新定义企业网络和网络安全体系架构，并重塑竞争格局。所以说网络安全的未来在云端。SASE是一个结合SD-WAN网络和云安全的产品，更像一个杂交品种，如下图所示，左边是网络即服务，右边是网络安全即服务。

图30：SASE产品特点

SASE产品核心组件包括：SD-WAN、SWG、CASB、ZTNA、FWaaS等，所有这些都具有识别敏感数据、恶意软件的能力，并且能够以在线速度对内容进行加密、解密，同时持续监控风险和信任级别的会话。可以看出都是云端的安全能力要求，SWG指的是安全网关，CASB上文有介绍，ZTNA是零信任机制解决认证问题，FWaaS是防火墙作为服务。

目前提供SASE解决方案的既有网络公司也有安全公司，比如Cisco和Fortinet。收费模式在网络侧是按照带宽收费，但是云端的安全产品都是按照账号来收费，可能后面会演进到按照保护对象来进行收费。

随着SD-WAN技术对网络的深刻改造中，网络安全相关的内容可能会发生深刻的变化，本质上是对于云安全的要求，SASE在这个进程中会发生重要的作用。不过目前的结合点还比较少，都是all-in-one的解决方案，安全公司想要有参与这个市场必须要有一些SD-WAN的建设能力，如果只是跟在SD-WAN厂商后面可能需要寻找工具链的管理模式。

云原生安全

云原生(Cloud Native) 最初是由Pivotal 公司的Matt Stine 于2013 年提出的。Pivotal公司先后开源了云原生的Java 开发框架Spring Boot 和Spring Cloud。随后，Google 在2015 年成立 了CNCF(Cloud Native Computing Foundation)，使得云原生受到越来越多的关注。

Pivotal公司说明云原生应用的要集成四个概念：DevOps、持续交付、微服务和容器。

图31：云原生四个概念

CNCF对云原生技术的定义是：有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式API。可见云原生是一种专门针对云上应用而设计的方法，用于构建和部署应用，以充分发挥云计算的优势。

未来的云原生架构的可分为三个方向：新的应用场景，新的技术变革还有新的生态发展。如下图所示：

图32：云原生架构未来三个方向

新的应用场景在混合云和多云环境的依赖上降低，因为容器这种技术会让工作负载和应用变的完全平台无关，所以在云的各种环境下都能得到很好的适配。边缘计算考虑到计算和网络资源的有限，使用容器和简单的编排工具更适用于这种场景。

新的技术变革有Service Mesh这种微服务运行时架构，包括了控制层面的技术Consul, Istio 和SmartStack以及数据层面的技术Envoy, HAProxy 和NGINX以及将两者合并的技术Linkerd。无服务的fPaaS也是一种云计算导致的应用方向，这种类似AWS的lamba都是基于Kubernetes和container的技术。目前的容器都是运行在VM上面，很好的结合了两者的优点，一个应用分发和一个安全隔离，但是VM导致虚拟化的资源消耗后面还是需要解决，可能未来就是直接在裸机上直接运行容器，可以降低资源的实际损耗。比如Kata container和gVisor都是这种技术。

新的生态发展需要更多的厂商进行支持。有对于ISV的容器化交付，目前的容器化交付的软件还是开源的为主，比如Elasticsearch, NGINX and Postgres。商业化软件的也在做相关努力，比如IBM在对Websphere和Db2在做容器化的交付方案。另一方面之前的容器运行的都是无状态的服务，为了支持有状态的服务需要有存储的加成，出现了软件定义存储SDS（software-defined storage）以及云存储服务。除了Kubernetes这个项目之外还需要更多成熟的项目。目前CNCF毕业的项目有Kubernetes（编排）、Promethus（监控）、Envoy（网络代理）、CoreDNS（服务发现）、Containerd（容器运行时）、Fluentd（日志）、Jaeger（调用追踪）、Vitess（存储）、TUF（软件升级）。还有很多孵化的项目在进化成成熟的项目。

云原生安全的理解在Pivotal总结为3R，Repair、Repave和Rotate。这三个“R”针对的是三个安全问题：Repair修复对应的恶意软件或者是对有漏洞的软件进行修复。Repave重新部署是对于APT攻击进行系统和应用的重新部署。Rotate更换是对于凭证泄漏进行的凭证更换。这显然对云原生安全的理解不够深入，哪怕对照这云原生的定义去理解安全，会更加全面和深入。

CNCF对于云原生安全的理解简称为4C：Cloud、Cluster、Container和Code。Cloud是基础，云平台的安全或者安全使用是基础，跟上文提到的CSPM一致，但是除去这些部分还有一些基于Kubernetes的基础安全问题，比如说Kubernetes Masters不能对外开放，其Master节点和Worker节点在特定限制下通信，K8S访问云计算API遵守最小权限原则等。这都是围绕着K8S的基础配置安全来说明。

Cluster（集群）分为两个方面：集群本身的安全，以及在集群上运行的业务的安全。集群自身安全有四个部分的安全需要考虑，K8S的API访问安全、Kubelet访问安全、工作负载运行时安全以及相关组件安全。K8S的API访问安全主要做到API的认证和授权控制以及TLS加密支持。对于Kubelete的API也需要做到认证和授权控制。对于运行时的工作负载要限制使用资源和控制权限以及禁止加载非需要内核模块，除此之外还需要还要限制网络访问以及云平台的API访问和Pod在Node上运行的控制。其它组件的安全考虑需要etcd的访问控制、开通审计日志、限制alpha和beta的功能访问、经常更换架构的认证凭据、对于第三方的集成需要安全评估、密钥进行加密和定期更新漏洞。

Container容器这个层面有三个安全问题：容器的漏洞扫描，以及镜像的签名、策略和权限控制。这里面讲的比较简单，其实可以展开的很多，之前的文章里面有讲到相关的安全问题，友商的研究部门也出过翔实的安全研究报告，我这里就不赘述了。

Code代码层面安全更像是之前笔者写过的DevSecOps相关的内容，包括了SAST、DAST和IAST的产品以及SCA这种对于开源软件安全的考虑都算是代码层面的安全解决方案。

图33：CNCF对于云原生安全的理解

 这个对于云原生安全的理解大部分都是基于K8S的前提下进行的，虽然K8S对于容器编排层面已经成为事实标准，但是未免也不够全面。

结合这两个机构对于云原生安全的理解，其实就是四个方面的安全考虑：

第一、云原生基础设施安全，包括了K8S和container。

第二、DevSecOps的安全加成，也就是整个流程的安全工具链。

第三、CI/CD的持续集成和持续交付的过程，可以让整个安全的修复做到非常自然，在一次持续交付过程中就可以把相关漏洞修复上线，可以跟着整个软件交付的周期来内生植入安全的考虑，同时也可以做凭证的更换等。在之前系统上线之后的很难仅针对安全进行变更，而在这个敏捷开发的过程中有了很好的流程上的保证。

第四、微服务安全，这个领域目前越来越受到关注，前段时间业内人士也发表了一篇关于API安全的文章，API确实是微服务的基础，也是未来应用的交互方式。除了API本身，对于微服务的发现、隔离等安全内容也有其特定价值。

总结

笔者先从云安全市场的趋势来说明云安全市场发展速度是跟着云计算的发展速度蓬勃发展，然后介绍了一些云安全的主流产品，包括了云计算提供商自身提供的安全产品和生态以及主流的第三方安全产品CWPP、CASB和CSPM。然后，提到了在SD-WAN的推动下基于云的安全产品SASE，最后说到了云原生安全这个全新的话题，云原生也是一种软件开发和交付在云计算环境下的变革，所以相关的安全解决方案也需要提前考虑。本文主要关注了云安全的未来一段时间内的发展方向，这些内容已经在国外有落地，根据国内的发展情况可能会有差别，或者会发展到另外的一种状态也未可知，但是也会有一定的参考价值，毕竟IT技术的发展还是比较一致。

-The End-