云计算、大数据、5G等等一系列新的技术呼啸而来，快速发展成熟，并逐步落地应用于各行各业。从忽略、观望、犹豫，到现在，上云成为了政企业务发展、IT演进的必选项。在这样的大背景下，如何充分应用云计算的能力和因应云发展的潮流，让其更好的服务于业务，成为了热门的新课题。“云原生”的概念应运而生，并必然贯穿这个时代IT演进的始终，带动所有应用领域出现颠覆式的变革。
作为网络安全的从业者，我们也身处云计算所带来的变革大潮之中。如何正确判断云原生所带来的云安全市场的机遇，并把握准确的时机蓄势而动，是我们需要关注与思考的课题。近两年，我们与包括Gartner和IDC在内的多家业界分析机构交流，和安全领域的最顶尖权威分析师团队做了很多碰撞，拓展视野；参考国际最领先市场的安全技术与市场发展轨迹，并在这个过程中不断的介绍与映证我们的产品技术方向和应用价值等等。另一方面，公司在此期间也一直为业务快速增长、IT架构不断升级的各行业客户提供产品服务，我们不断地分析市场需求，修正自身定位，从技术前瞻等各方面来规划技术和产品的发展演进，并从这个思考迭代过程中积累了很多沉淀。本文是对计算格局和云安全的一些随笔畅想。
简介
我们梳理过去五十年IT发展的各个板块，会发现处理器、存储、网络这几个关键要素的迭代发展，让“计算”像历史上的交流电和自来水一样，在管道铺好了、集群集中做到位后，逐渐往Utility的方向发展，“云计算”即随之得名。2005年美国国家标准与技术研究院NIST提出和确定了云计算IaaS、PaaS、SaaS的模型，2006年亚马逊最早推出了EC2和S3。从那之后，云计算对科技行业基础设施的影响是颠覆性的。公有云、私有云、混合云在各种云的建设中被反复提及，而美国的SaaS业务在2014年标志性的首次超越IaaS后，亚马逊、微软、谷歌和IBM带领的美国公有云软件即服务业务，就从此一飞冲天。
信息安全一直是跟随IT基础设施和业务发展的。云计算的颠覆性发展，带来了对应用“云原生（Cloud Native）”的需求，也带来了对安全机制“云原生”的需求。传统的以数据中心、网络和端点为主要保护对象的安全思路和产品，在云原生的要求下，必须在开发、部署、管理等多个方面都跟上云设施和云应用的演进。
时至今日，在安全市场整体的发展中，云安全的重要性越来越高。据Gartner在2020年一季度的预测显示，全球2018-2024年信息安全市场中，云安全及其相关子领域的年复合增长率在30%左右，其发展速度远远超过其它类型的安全产品。2020年的旧金山RSA大会上，“Cloud Security（云安全）”也在安全热门词排名中，超过“Privacy（隐私）”、“Network Security（网络安全）”、“Governance and Compliance（监管和合规）”等领域，高居榜首。
云计算市场的发展，在全球呈现出“美国”和“美国之外”两个板块的两极趋势。中国的云计算和云安全市场，跟美国比存在较大区别，这其中有发展阶段的原因，建设习惯的原因，也有生态环境和竞争等原因。即使如此，我国在云计算整体大趋势上的发展，基本是与我国经济体量和发展水平对称的。
云原生和云安全是什么
“云原生（Cloud Native）”这个词，在云计算模式中，经常被冠在不同子领域前来作为形容词定语，这也引来了很多使用者的困扰。本文从最终使用者的视角，来阐述笔者的一种理解。
云使用者最为关注的，其实是他们要运行的云应用，因为这涉及到运行的业务是啥，以及要付多少钱。因此，如果以云原生应用（Cloud Native Application）作为讨论的基础，那么宽泛的说，“云原生”描述的是充分利用原生云能力（自动scale-out、无中断部署、自动化管理、弹性，等等）来进行应用设计和部署的方法。在这个形而上的框架下，微服务、容器技术、云数据库技术、K8S、弹性搜索、遥测Telemetry等技术，都是形而下的技术。那么在这个框架下，可以想象，简单的把原有企业网的环境和虚机迁移到IaaS云里，或者把原有应用直接打包到虚机里来跑，乃至做些API对外提供接口，这些做法离云原生都还远。一句话，云原生应用为了这个“云原生”属性，需要在发布、服务方式、随需弹性、数据和工作负载（workload）管理等多方面都重新构建。
在IT发展历史上，安全产品一直是跟随IT基础设施和业务来为其服务的。云安全也不例外——云安全处理的就是面向访问和使用云系统云应用的流程机制。
云安全与传统企业网络安全机制的最大不同在于，云安全的管理责任是在云运营商和用户之间分享的，从IaaS到PaaS再到SaaS这三个云业务层级上，云运营商的责任越来越大。最“轻量”的情况下，使用SaaS的用户只需管理自己的数据和用户接入权限，其余的都交给运营商。有关云计算下安全责任分配方面的资料描述已经非常详实，本文也就不赘述，直接引用加拿大政府《云安全与风险管理流程指南》中的相关责任范围描述，如图 1所示。
图 1 云安全的责任范围（来源：www.canada.ca）
从责任共享这一点出发，云安全产品就可以非常直观的分成两个大类：一方面是云运营商配套云服务而直接提供的安全产品，也可称为“云运营商原生提供的安全（Native Cloud Security）”；另一方面则是第三方安全厂商提供的安全产品。无论哪一类云安全，为了更好的支持云服务，都要做到支持和适配“云原生”这个属性。
对于以上基于责任共享而定义的云安全产品分类，一个很自然的问题是，目前已经存在的网络安全产品，有哪些未必需重新大改架构，可以直接服务于云安全或被云运营商直接采用？这也是对于安全厂商和很多云租户的CISO们来说非常关心的现实问题。Gartner对于云安全机制，基于现实情况增加统计了这个维度，下图是2019年的分类。
图 2 云安全的服务和组件，2019（来源：Gartner）
云安全的需求是由云业务发展驱动的，具体体现在逻辑安全架构和技术组件上。从上图左侧可以看出，防火墙、防入侵、端点安全、服务器监控、终端检测响应和SIEM等，对云原生的要求没那么高，因此很多安全产品会由运营商直接从第三方安全厂商拿来部署上云。而威胁检测、工作负载安全、用户行为监控、合规与风险管理，云运营商往往需要自行提供这些工具来满足“云原生”的要求。第三方安全厂商提供的和云具有较好亲和力的产品，Gartner这里在图右侧提到了云工作负载保护平台CWPP（Cloud Workload Protection Platform）、云安全态势管理CSPM（Cloud Security Posture Management）、云访问安全代理CASB（Cloud Access Security Broker）、微隔离Micro-segmentation和CDN。
以上的分类法，只是诸多对云安全机制试图归类的一种。安全一直是一个非常零散的市场，据统计，美国2019年存在5000多家安全厂商，而中国同期这个数字是3000余家。这也导致安全产品给自己的定位可以相当灵活，乃至模糊。因此，云安全产品分类还有很多种，比如基于IaaS、PaaS和SaaS的云安全，基于上云（of the cloud）和云上（in the cloud）的安全，基于防御深度模型的云安全机制分类，等等。这些不同的分类法，并非严格的科学定义问题，因此本文不再赘述。本文后面章节将继续从“云原生”要求的角度来展开，介绍云原生环境对安全在业务、管理和部署上的新要求，及相应所催生的云安全厂商的机会。
厂商的云安全机会
前文提到，无论中国还是美国，安全市场都看起来高度分散。但是高度分散和海量的新企业，背后反映的是蓬勃发展的市场板块，以及资本市场对于安全企业的青睐。并购、上市等活动在安全市场非常活跃，这种活跃会随着云计算的普及，持续数年。
我们冷静的分析一下安全厂商在云安全领域的机会。首先，既有的安全机制中，能直接被云运营商采用搬上其云环境的这部分，是传统厂商的静态存量市场（搬一块少一块）。其次，云运营商为了适配其云原生服务（容器、微服务、存储、记录和监测等），也采购或自研来提供安全产品给自己和云租户。最后，第三方安全厂商为了云原生则可开发在特性上更通用的安全产品，在配置和部署上则贴近云运营商和云租户做适配。
上文的后两个领域，是安全市场的创新和整合频繁出现的地方：
创新厂商同时服务多家云应用来拓展业务（例如，创业公司Inky为G-suites，Office365和Exchange都提供邮件反钓鱼业务，估计最后押宝被微软或者谷歌收购）；
创新企业被安全大厂并购（例如，身份认证厂商DUO在上市前，收到Cisco一张比IPO预期更高价位的支票，于是决定不敲钟了，同意被收购；CASB厂商Skyhigh被McAfee收购后，重新包装成MVISION Cloud）；
云供应商实在觉得顺手，就自己买下个把安全公司（例如VMware买下终端安全大厂CarbonBlack来拓展端点安全和工作负载安全）；
头部大型安全厂商服务多家云，结成捆绑战略（例如，Palo Alto Networks买下PureSec、Twistlock、Aporeto等一篮子公司后，组建了其云安全产品线Prisma Cloud，适配亚马逊AWS、微软Azure、谷歌GCP、IBM Cloud、VMware Tanzu、阿里云等天下几乎所有头部云运营商）。
云原生环境对安全在业务、管理和部署上的新要求，就是云安全厂商的机会。最重要的几个要求包括：
（1）云业务持续不断的交付要求，需要持续不断的安全保障。时至今日，微服务、容器等已经成为云业务的主流，弹性和无中断成为标配要求。亚马逊、沃尔玛、Target（美国第二大综合零售商，大家戏称靶子店）等在其云上的店面部署更新能做到每日数百次——因此安全必须也做到轻量化、持续不断，并嵌入部署工具中各个环节来确保成为“检查点”。
（2）对工作负载（Workload）的安全防护是必须的，而且要随着工作负载的演进而不断演进。传统企业安全防护，端点、网络、边界，各个层级是比较清晰的。云环境下，这些边界界限变得很模糊，而承载计算的工作负载则是直面威胁的对象。
工作负载，大致可以定义为：运行特定应用需要的资源和进程。比如，一个云工作负载包括程序、其使用和产生的数据、以及需要连接用户和其他相关程序的网络资源。
随着云计算和云原生需求的发展，工作负载的形式越来越抽象灵活，同时其部署和运行的生命周期也可越来越短。如图 3中的描述所示，工作负载从最初的物理服务器，发展到虚拟机。到今天，容器和微服务已经成为主流。而正在出现和发展的工作负载新形式Serverless（无服务程序），直接对应用run-time虚拟化，改变了传统意义上的服务进程监听-运行模式，是更加精细粒度的瞬态工作负载（ephemeral Workload）。
多种形式和生命周期的云工作负载，会长期共存，目前并没出现彼此淘汰的情况。因此，工作负载的安全，是一个需要横向保护多种负载，也需要纵向对每类负载深入做好保护的问题。
图 3 云工作负载的形式和演进（来源：Gartner）
（3）多系统和Hybrid Stack支持，自动化配置。Hybrid这个词，既描述了云的公有、私有、混合等形态，也描述了当前云工作负载的多样性和抽象演进，同时还反映着对多种操作系统提供支持的需求。举个例子来说，笔者曾从事过real-time应用研究，mission-critical任务是一类有特定时间要求（sojourn time constraints）的应用，这种任务往往对操作系统本身的实时属性有要求。把用于实时通信的mission-critical容器部署在云虚机里，就会涉及到很多这类问题。比如，虚机本身的OS是否满足real-time层面的要求，虚机的OS是否有最新的安全补丁，如何做到虚机和容器层面的可视化，如何保证对主机、虚机、容器和程序的检测响应，等等。更为重要的是，复杂的应用往往给配置增加难度，而70%以上的攻击事件，都是从用户的不当配置上产生的。因此自动化（automation）这个要求，在云原生的背景下有格外重要的意义。
CWPP与CSPM：业务面和管理面的解析
CWPP的能力集和分类
如前文所述，云工作负载在抽象化、灵活和弹性上历经演进,多种形式和生命周期的云工作负载，目前并没出现彼此淘汰的情况。因此，出于其特性，云工作负载的安全要兼顾对多种工作负载全面覆盖的横向保护，以及对每类工作负载更精细深入的纵向保护。
对云工作负载的保护机制，业界有多种定义分类法。Gartner定义其为“云工作负载保护平台CWPP（Cloud Workload Protection Platforms）”，意指在现代混合多云数据中心架构下，以工作负载为中心的安全机制。更简单点说，就是保护租户在云上工作负载的安全机制。
CWPP的定义是一个足够宽泛的框架，框架里面包含的能力包括：在云原生架构下持续评估风险的能力，在部署前和运行中识别薄弱点和误配置的能力，在运行后及时发现和分析响应的能力，以及支持多种云运营商平台运行环境和配置环境的能力等。
在这个框架下， 2019年全球的CWPP市场收入为12.44亿美元，在2018年10亿美元的基础上，增长超过20%。这个市场内，三个最大的玩家分别是：趋势科技、赛门铁克和McAfee，占了一半的营收。
随着工作负载的演进，Gartner对CWPP的能力描述也在不断演进。从2016年开始，CWPP领域有了独立发布的市场指南，CWPP与聚焦终端安全的EPP分开，开始强调混合数据中心中多云工作负载的管理能力，从技术角度最看重的是跟云平台的原生对接。
2020年4月Gartner发布的CWPP市场指南中，业界已经很熟悉的CWPP能力金字塔进一步精简，文件加密和防病毒干脆就从能力要求中移除了。目前的能力，从最核心的开始，按照重要性逐渐递减的排序，包括八层：
（1）加固、配置和漏洞管理，
（2）基于身份的隔离和网络可视化，
（3）系统一致性保证，
（4）应用控制/白名单，
（5）预防漏洞利用和内存管理，
（6）服务器工作负载行为监测、威胁检测和响应，
（7）主机防入侵和漏洞屏蔽，
（8）扫描恶意软件。
不同的安全厂商针对特定领域，聚焦一种或多种能力，这也造就了CWPP具体产品实现的不同基因。Gartner据此把厂商分成七大类：广泛能力和多系统支持，漏洞扫描和配置合规，基于身份的隔离和可视化与管控，应用管控与状态执行，服务器行为监测和威胁检测和响应，容器和K8S保护，以及对Serverless的保护。比如，志翔科技的至明®安全探针产品（ZS-ISA），对服务器、虚拟机和容器都能监测和保护，并支持基于用户角色的精细管控RBAC和安全可视化，因此被归类为CWPP中的“基于身份的隔离和可视化与管控”。
CSPM：硬币的另一面
自从软件定义网络SDN（Software Defined Network）的概念在2010年正式提出并流行起来之后，“软件定义某业务”就随之扩展到各个领域，软件定义安全、软件定义存储、软件定义广域网、软件定义边界等概念和技术都相继出现。控制面和转发面分离，是SDN中的一个重要概念。网络策略在控制面计算并下发到转发面，转发面不用具备复杂计算能力，直接执行策略做转发即可。当然，这个概念在做光传输的同仁来看，不过是绕回了二十多年前传输网早就实践的理念，没啥新鲜的，本文此处不细述网络界的技术八卦。
控制面和转发面的分分合合，在CPU设计中有，在网络设计中有，在云安全中同样有，而且以马甲出现——很多时候称之为“管理面”和“业务面”。CWPP是对云工作负载进行保护，是对业务面的安全防护。那么其对应的管理面，要配置策略和管理工作负载、监控合规性、保障调用云运营商API完整性等等，这些同样需要安全防护。而且几乎所有的云安全事件都涉及配置错误和管控失当，而目前IaaS和PaaS服务中的自动化和用户自助之普及，更凸显正确配置和合规的重要性，这就让管理面的安全机制变得越加重要。
根据Gartner定义，云安全态势管理CSPM（Cloud Security Posture Management）就是专注管理面的安全属性，包括安全配置、安全评估、合规监控等等，解决的核心问题是云平台在使用过程中的配置安全问题。CSPM通常通过调用云运营商提供的API，使用其原生能力来自动检测和发现配置错误，及时发现上云的风险并提前预警和敏捷响应。CSPM的典型能力包括：身份识别、合规评估、运营监控、可视化与策略强化、DevOps 集成、威胁防护和风险发现、风险评估和运营安全验证等。作为使用云服务的安全管理面，CSPM还需要适配多种云运营商、借助其管理API来自动扫描和侦知风险。
CSPM和CWPP几乎是同一块硬币的两面。从技术细节上说，CSPM和CWPP干的是不同的事情。但是从云应用的实际运行中来看，这两者密不可分。图 4从云租户的视角，解释了这几个层面安全机制之间的关系。云运营商原生就会提供一些基础的安全机制来保护上云的安全。CSPM负责管理面的安全问题，检查和强化正确的配置；CWPP负责业务面的安全问题，保护好各种云工作负载，两者配合的目的，都是为了云计算业务的正常开展和租户敏感数据得到妥善保护。实际上这种“策略配置检查-策略下发执行-业务过程防护”的逻辑，其内在哲学与通信网络中的做法完全一致。
图 4 CWPP和CSPM分别负责业务面和管理面
CSPM目前在美国云运营商中，大量应用在头部的亚马逊AWS上，在微软Azure和谷歌GCP的应用也在迅速增长。由于云基础架构仍然在改进，各国的行业标准和合规要求也一直在提升，CSPM策略也对应贯穿云应用的整个生命周期，从开发测试，到上线运行，一直延伸到运维和终结。
很自然的，业务面和管理面的云安全产品会融合组成解决方案来服务多种云和多租户。很有意思的是，从CWPP和CSPM的融合趋势来看，从业务面往管理面发展的厂商很多，而反之则较少。笔者的解读是，CWPP在操作系统、平台和网络层面有较多特性，属于“通才”基础能力，而CSPM往往是和某个云运营商在配置和API能力上深度绑定的。从通识教育向某个方向垂直发展，符合我们求知和教育的一贯做法，大学里大家都是先上公共基础课，再学专业基础课，最后本科高年级才到专业课。
安全机制在IaaS、PaaS和SaaS层面运用解析
为了完整性，笔者再提一下云访问安全代理CASB（Cloud Access Security Broker）。CASB主要服务于SaaS场景，在美国随着SaaS的业务从2014年开始占据云计算主流，SaaS化的应用也带来CASB市场空间的极大拓展，其规模是远大于CWPP和CSPM的。SaaS的应用场景如微软Office365用于办公，Salesforce用于CRM，ServiceNow用于运维，Slack和Teams用于工作协同，这些也正是CASB厂商面向的重点领域。因此Gartner甚至提出，CASB对于云的作用，就相当于防火墙对于数据中心的作用。
而中国的云计算市场与美国有着显著不同（实际上欧洲也和美国明显不同）,公有云和SaaS的发展，变成了“美国”和“世界其他各地”两个市场。从供给侧说，我国IT产业长期聚焦硬件设备，结构性有点失衡，产业链相对分散，缺乏大量强有力的软件公司来主导和推动云化办公。从需求侧来说，我国企业数字化和信息化程度并不高，很多企业主要的IT应用停留在OA和简单的生产管理和财务管理上。只有互联网新兴行业客户和少数IT重度依赖的传统行业客户（如金融、政务等）有较强的IT投入意愿，愿意尝试云化办公，而不同行业、区域之间壁垒相对更高。
因此到2019年，我国云计算的市场营收，仍然以IaaS为主，至今SaaS还没有广泛流行。在这种情况下，CASB的需求就并不凸显，因此CASB在我国目前还显得“水土不服”。可以想象的是，我国在云计算的下半场，公有云+私有云结合的混合云仍然会是主要形态。互联网公司布局公有云，传统行业客户出于政策监管考虑，会选安全性和可控性更强的私有云/专有云，并需要深度定制的方案和服务支持。因此即使CASB最后在中国落地开花，其形态和特性也会跟今天美国市场的同类产品很不一样。
图 5描述CWPP、CSPM和CASB这三种云安全工具的适用业务模式。CWPP保护云工作负载，是典型的IaaS领域安全机制。CSPM作为云工作负载的管理面，是IaaS安全领域的补充，同时CSPM也适用于多云环境，可在PaaS层面作为配置和完整性检测的业务提供安全防护。CASB则主要应用于SaaS领域，在IaaS和PaaS有少量场景，主要来自于CASB产品本身的特性延展到了这两个领域。从云租户使用的角度来说，如果租户企业使用SaaS服务并存储敏感数据，应该考虑上CASB。如果企业主要使用IaaS服务的算力来处理敏感数据，则上CWPP来保护云工作负载，并使用CSPM来保证配置无误。
图 5 三种云安全工具适用的云业务模式（来源：Gartner）
云安全的趋势：无边界、云原生、融合构筑防护深度
我们再一次回顾信息安全的发展史，仍然要强调的是，信息安全是跟随IT基础设施和业务来发展的，也就是说，安全跟随其服务的对象而演进。
业务数字化转型和云计算的发展，改变了网络安全的设计理念。传统物理边界变得模糊后，安全不再围绕企业数据中心和终端来设计部署，安全边界也不再是数据中心边缘和企业网边缘的某个盒子。在云计算时代，应该基于以数据为中心（Data-centric）的原则来部署安全，关心的问题应该是：谁，能访问什么业务和数据，应该授予何种访问权限，为什么需要这些权限，在授权范围访问是如何进行的，等等，而不再是“业务在哪里”和“边界在哪里”。换句话说，传统安全边界变成了无处不在的边界能力——动态创建、策略强化、权限管控、安全访问。
云计算的颠覆性发展，带来了对应用“云原生（Cloud Native）”的需求，也带来了对安全机制“云原生”的需求。云原生应用和云原生安全的市场前途光明。根据Gartner的数据，2020年全球公有云服务市场规模将达到2630亿美元，同比增长16.4%。以发达国家安全投入占IT投入的10%左右计算，这是个超过250亿美元的市场。而根据中国信息通信研究院发布的《云计算白皮书（2018年）》显示，到2021年，我国公有云、私有云建设年复合增长率将分别达到43.7%、23.0%，市场规模将达到902.6亿元、955.7亿元。可以看出，与美国不同，我国的公有云和私有云市场规模接近。这两块云安全市场加起来也是一个接近200亿人民币的市场。
无论中国还是美国，安全市场都是碎片化严重、技术分支众多、业务极其纵深，是名副其实的“离散关键赛道”——又小又重要。“一顿操作猛如虎，签了合同两万五”是安全从业者经常自嘲的话。但从云计算给信息基础设施带来的变革来看，加上5G、物联网和传统产业数字化（产业互联网）的发展，“云原生”带来的是极为广阔的市场容量，对安全的需求极为庞大。因此高度分散和海量的新企业，背后反映的是蓬勃发展的安全细分领域，以及资本市场对于安全企业的青睐。
安全厂商要抓住“云原生”这个机遇。信息安全的防护纵深洋葱模型，在data-centric的云原生安全时代一样存在，如图 6所示。当物理安全边界逐渐模糊消亡并变成了无处不在的云原生安全边界能力，这个洋葱模型，从外到内，无论政策、可视化、运维和安全管理，还是南北向和东西向的网络、基础架构、身份安全、数据安全等，实际上给安全市场带来了更多的机遇。
图 6 云安全防护纵深的“洋葱”模型
从安全生态上而言，细分领域的厂商可以做深做精，而在全环节解决方案上，融合、合作、联盟，就成为必然选项。比如，CWPP和CSPM本来就是亲和力很好的邻近领域，出现融合的趋势是情理之中的。业务面和管理面的安全机制融合协同，可能出现一个新的市场，Gartner称之为云原生应用保护平台CNAPP（cloud native application protection platforms），在开发和运行运营阶段对云原生应用的配置和工作负载做安全防护。比如，机器学习、可视化、用户实体行为分析UEBA等技术，会逐渐成为各项安全产品背后的技术，特别是提升日志分析、SIEM、特权账号管理的能力。又如，软件定义边界SDP和其演进出来的零信任安全框架，融合身份权限、访问控制、安全管理等，将成为新的云业务访问方式，逐渐取代传统VPN等。
作者：志翔科技联合创始人、市场战略副总裁，伍海桑博士
声明：本文来自安全内参，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。
