1.3 云安全产业与产品

云计算安全与传统信息安全并无本质的区别，许多安全问题并非是云计算环境所特有的，如黑客入侵、恶意代码攻击、拒绝服务攻击、网络钓鱼或敏感信息外泄等，都是存在已久的信息安全问题。在网络安全日益严峻的形势下，传统的网络安全系统与防护机制在防护能力、响应速度、防护策略更新等方面越来越难以满足日益复杂的安全防护需求。面对各类恶意威胁和病毒传播的互联网化，必须要有新的安全防御思路与之抗衡，而通过将云计算技术引入安全领域，将会改变过去网络安全设备单机防御的思路。通过全网分布的安全节点、安全云中心超大规模的计算处理能力，可实现统一策略动态更新，全面提升安全系统的处理能力，并为全网防御提供了可能，这也正是安全互联网化的一个体现。

在传统数据中心的环境中，员工泄密时有发生，而同样的问题极有可能出现在云计算的环境中。由于云计算自身的虚拟化、无边界、流动性等特性，使得其面临较多新的安全威胁；同时，由于云计算应用导致IT资源、信息资源、用户数据、用户应用的高度集中，因此其带来的安全隐患与风险也比传统应用的高很多。例如，云计算应用将企业的重要数据和业务应用都放在云服务商的云计算系统中，云服务商如何实施严格的安全管理和访问控制措施，来避免内部员工、其他用户、外部攻击者等对用户数据的窃取和滥用；如何实施有效的安全审计对数据的操作进行安全监控；如何避免云计算环境中多客户共存带来的潜在风险、数据分散存储和云服务的开放性；如何保证用户数据的可用性等，这些都是对现有安全体系带来的新挑战。

此外，云服务商可能同时经营多项业务，在开展业务和开拓市场的过程中可能会与其他客户形成竞争关系，也可能存在巨大的利益冲突，这都将大幅增加云服务商内部员工窃取客户资料的动机。此外，某些云服务商对客户知识产权的保护是有限制的。因此，在选择云服务商时，除了考虑它与其他客户的竞争关系，还需要审核它提供的合约内容。此外，有些云服务商所在国家的法律规定，允许执法机关未经客户授权直接对数据中心的资料进行调查，这也是在选择云服务商时必须要注意的。欧盟和日本的法律限制涉及个人隐私的数据传送及储存于该地区以外的数据中心。

基于以上云安全的现实环境，云安全产业可以分为两个部分：一部分是服务商直接提供的安全产品，另一部分是第三方安全公司提供的安全产品。前者也被叫作云原生安全产品，指的是云厂商配套云服务提供的安全产品；后者指的是适配云原生服务（如容器、微服务等）的安全产品。

1.3.1 云原生安全产品

云平台本身也是云安全的服务商，这一点毋庸置疑。但是它们与第三方合作厂商的关系及对生态的理解又都是不一样的。而AWS无论是在云计算相关产品上还是在云安全上都做到了行业标杆，其对云安全的定位和做法引领了行业的发展。图1-1-5所示为公有云平台提供的安全产品，可以看出各个云平台提供的安全能力，其中AWS和Google的GCP处于领先地位，接下来是Microsoft和Alibaba。

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

AWS的API相对比较友好，IaaS层的安全思考最多。控制面板有IAM（Identity and Access Management，身份识别与访问管理）类的功能，其中通过inspector可以解决Guest OS的问题、VPC（Virtual Private Cloud，虚拟私有云）可以解决网络隔离的问题、Macie可以解决数据发现和分类的问题。

微软的Azure安全平台的大部分功能都可以通过PowerShell的脚本实现。Azure提供很多安全类产品，也正准备提供无密码验证机制、集成Microsoft Graph开发工具，以及工作负载的安全基线功能。

2019 年的 AWS 云安全报告提到，云安全客户最关注的问题是数据泄露、数据隐私和机密性，如图1-1-6所示。

AWS的安全产品和管理服务如图1-1-7所示，在AWS的原生安全产品中有71%的受访者使用了IAM产品，65%的使用了CloudWatch，45%的使用了CloudTrail。另外，还有42%的使用了AD（Active Directory）管理和35%的使用了Trusted Advisor。

由此可以看出，客户非常关心数据安全的问题，而且大部分客户使用了云计算平台提供的安全产品。

由于AWS对云安全责任共担模型的理解及对安全生态的重视，因此形成了一系列产品。AWS平台提供的云原生安全产品包括五类：身份访问控制类、检测式控制类、基础设施保护类、数据保护类、事故响应类及合规类，如表1-1-2所示，表1-1-3所示为AWS的管理与监管工具。

AWS的安全产品是让客户能够安全地使用云计算，因为很多时候不是AWS的安全性不够，而是客户没有很好地配置而导致安全问题，如S3配置不当引发的数据泄露。

AWS友好且安全的API，让很多云安全厂商可以很好地开发基于AWS的安全产品，这也引导了Azure和GCP的云安全建设思路，这样有利于把云安全生态真正地建立起来。

Google在2015年成立了CNCF（Cloud Native Computing Foundation），这使得云原生受到越来越多的关注。如图1-1-8所示，云原生应用集成的四个概念：DevOps、持续交付、微服务和容器。

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

未来的云原生架构可分为三个方向：新的应用场景、新的技术变革和新的生态发展。如图1-1-9所示。

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

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

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

CNCF 对云原生安全的理解可以简称为4C，即 Cloud（云），Cluster（集群），Container （容器）和Code（代码），如图1-1-10所示。

Cloud 是基础，云平台的安全和安全使用是基础，跟上文提到的 CSPM 一致，但是除去这些还有一些基于Kubernetes的基础安全问题，如Kubernetes Masters不能对外开放、Master节点和Worker节点只能在特定限制下通信、K8S访问云计算API遵守最小权限原则等。

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

Container层面涉及三个安全问题：容器的漏洞扫描、镜像签名与策略和权限控制。

Code层面的安全包括SAST，DAST和IAST的产品，以及SCA对开源软件安全的考虑。

CNCF对云原生安全的理解大部分都是基于K8S进行的，虽然K8S在容器编排层面上已经成为标准，但是也未必全面。

对云原生安全的理解，其实可以从以下四个方面考虑：

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

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

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

第四、微服务安全。其中，API是微服务的基础，也是未来应用的交互方式。而除了API，关注微服务的发现、隔离等安全内容也具有特定的价值。

1.3.2 第三方云安全产品

比较主流的第三方云安全产品有CSPM（Cloud Security Posture Management，云安全配置管理）、CWPP（Cloud Workload Protection Platform，云工作负载保护平台）和CASB（Cloud Access Security Broker，云访问安全代理）三种，其中CSPM适合于多云环境或Iaas+fPaaS的情况，CWPP适合于IaaS或以容器为主的IaaS，CASB适合于SaaS或PaaS的情况。这三种产品都是伴随着云计算的兴起而产生的。

1.CSPM

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

CSPM的典型应用场景包括合规评估、运营监控、DevOps集成、事件响应、风险识别和风险可视化。目前，CSPM的相关功能在其他产品中也有所覆盖，比如在CWPP和CASB类型的产品中也涉及这个领域的功能，同时一些云计算厂商也有基本的设计，包括AWS的Trust Advisor，Azure 的Security Center和GCP的Security Command Center。但是每个云上的安全设计只是解决了自身云的问题，而混合云的情况就需要第三方厂商来统一管理。多云的管理平台有时候也会利用CSPM的能力对多云安全的问题做一些工作。因此，CSPM本身更像是一种能力，被其他产品或者云厂商拥有，但作为单独产品的竞争力不够。

目前，CSPM的厂商还是集中在AWS上，因为AWS的客户数量较大，但是做的深度不够。另外，AWS现在的云计算产品越来越多，而CSPM涉及的产品类型比较少，还是集中在一些基本的产品上，如S3。这种产品的定价是基于云管理平台的管理员账户数量来定的，每个账户的使用费用在1000美金左右。

2.CWPP

在介绍CWPP云工作负载保护平台之前，先说明一下CSPM和CWPP的区别，如图1-1-11所示。在云计算方面，CSPM管理控制层的安全问题，CWPP管理数据层的安全问题。

CWPP主要具有三个方面的安全能力：攻击面减小、执行前防护和执行后防护。

3.CASB

CASB已经进入了Gartner报告的魔力象限图，其比CSPM和CWPP更加成熟，拥有较大的市场空间。

CASB在我国和美国的发展有很大差异，核心原因是IT环境不同。美国的整个办公环境在 SaaS 领导者 Salesforce 的推进下得到了全面发展，如 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 有四个核心方面的支撑：可视化、数据安全、威胁保护和合规。可视化是表示在企业中对所有的应用都有识别的能力，不会遗漏一些未知的SaaS应用。数据安全包括数据分类、数据发现及敏感数据的处理，也被叫作云端的 DLP。针对数据安全保护，还有一些解决方案会使用部分同态加密技术，把数据加密存储在云端，然后直接对密文进行处理，而最终在本地的是明文。威胁保护主要是指访问控制，有的厂商会与UEBA结合建设零信任机制，有的会OEM一些反恶意软件和沙盒类产品来检测威胁。合规的重点就是利用CSPM的一些能力集成来达成合规的一些要求。

CASB的基础架构如图1-1-12所示，数据来源包括IaaS或者SaaS的API、正向代理、反向代理，以及已存在产品的数据，如SWG、FW的数据和API的四个方面。正向代理或者反向代理获取的数据只是技术层面的，而IaaS和SaaS的API及其他产品的数据在国内很难获取。

图1-1-13是CASB的一些经典使用场景，企业内部人员在访问IaaS，PaaS和SaaS时都会受到CASB的监控，外部人员想要进入企业内部也需要CASB的认证，同时CASB也会阻止一些不合法应用的访问。

CSPM，CWPP和CASB在IaaS层面上的部署，如图1-1-14所示，CSPM通过API交互来实现功能，CWPP 在每个工作负载上部署，CASB 既可以使用网络代理的数据也可以使用云平台的API数据。