李磊:OCBC框架下企业云化CSPM落地思考和实践探索

// 文丨作者介绍

本文作为《新视角下企业云化安全治理框架OCBC》B基准（云产品安全基准中安全基线子项）的纵向阐释篇，细化在云产品和服务风险管控中的一些个人理解、思考和落地实践。

CSPM历史

CSPM的产生

很早以前，随着云市场的蓬勃发展，与云相关的概念应运而生。Gartner敏锐的捕获到了类似的变化，早早创立了以C字母打头为缩写的与云市场密切关联的各种领域词汇，像Cloud Computing、Cloud Security Solution等。CSPM（即Cloud Security Posture Management）是其云安全解决方案家族中的普通一员。

根据Gartner历年发布的“云安全技术成熟度曲线”数据，笔者粗绘了图1 CSPM及其关联技术成熟度炒作曲线时间轴。大约在2017年时，Gartner提出了CSPM一词。为什么是大约呢？因为在2018年Gartner发布的“云安全技术成熟度曲线”中，Gartner将CSPM定位在期望膨胀期，所以至少在2017年以前Gartner应该已经提出了类似概念。不过，在2017年或更早前的相关报告中，并未发现CSPM这个缩略词。

CSPM（图1绿色字体部分）从提出到现在，短短几年，经历大起大落。当前正处于所谓“稳步爬升恢复期”，看似一片大好。

图1 CSPM及其关联技术成熟度炒作曲线时间轴

为什么要花这么长的时间去梳理CSPM产生的时间线呢？笔者希望通过拉开时间的维度，来看具体是在什么样的诱因下Gartner提出了CSPM一词，这样更有利于理解CSPM最初是寄希望于解决怎样的问题。

回顾2017-2018年，与云相关几个重大事件有：

1.根据《2017年云计算行业市场发展分析报告》数据显示，当年全球云计算巨头收入增长惊人；

2.2017年，中国工信部正式颁布云牌照监管政策，让很多云厂商的合规之路顺利上岸。而且在2018年，BAT云计算战略升级，云部门被提升到一个新的高度。如阿里云事业群升级为阿里云智能事业群。全新的阿里云智能事业群，将中台的智能化能力（包括机器智能的计算平台、算法能力、数据库、基础技术架构平台、调度平台等核心能力）将和阿里云全面结合。

3.根据ITRC数据泄露报告内容显示，2017年的数据泄露事件较2016年增加44.7%，达到一个创历史的记录。同时，云上数据占TOP数据泄露比例为28%，并呈逐步上升趋势。

4.根据统计，云上数据泄露由于云服务配置错误的占比约为40%，而这一趋势仍在增长

通过这些与云相关的重大事件，可见云的发展高歌猛进，企业云化带来高价值数据集中，但云上因为配置问题导致的数据泄露频发。可以发现，Gartner最初提出CSPM的理念最希望解决的是configuration of cloud services中的问题。

神奇的点在于，这是谁的责任？

甲方云化企业以为是云企业的问题，云厂商以为甲方已经知道了这个是它自己的责任。

实际上，多数上云的甲方是不清楚的，很多云化的企业或安全从业者本来是尚未准备好应对云带来的安全变化，在如何更安全的用云和云上的责任划分存在着认知偏差，事实上亦是如此。根据2020年 CISO MAG 调查显示, 76%的用户认为云厂商是要为云上安全负所有责任的。显然，这是不现实的。

作为云厂商的乙方，其实早早看透了这一点，很早就发布了自己的“责任共担模型”。所以，我们还是再看下它到底说了什么。

云上责任共担模型

责任共担模式的出现，本质上是因为基建和服务的提供方发生了变化。

责任共担模型是定义云服务提供者及其客户之间的安全责任的框架。基本每家云厂商都推出了自己的责任共担模式，但是实质的内容大同小异。笔者的理解主要是两个点：

1、云“基建”的安全责任属于云厂商，可以理解为冰山下的。

2、云“使用”的安全责任属于云用户，可以理解为冰山上的。

我们以图2 AWS责任共担模型为例，来简要做下解释。

如果我是云用户，但是在自己的租户环境下，发现可以通过私网方式访问到其他与我无任何业务关系云租户的环境或资源，或者直接访问到AWS云环境的Infrastructure管控端，那这个属于漏洞，修洞的责任或出现问题的背责方肯定是云厂商。说白了，云厂商要为自己的基建安全性负责。

如果我是云用户，买了AWS的S3，类似阿里云的OSS。我在S3中存了很多的数据，但是我却把S3桶sec-data的权限设置为Public，造成互联网上的任何用户都可以访问。那么，这个责任肯定是属于云用户自身的。因为，作为云厂商提供了丰富的Identity&Access management机制，而且事实上我也完全可以通过这些机制将sec-data设置为Private来规避这个问题。其实，这个问题本质是云用户没有做好图2中Identity&Access management。

通过这个简单的例子，其实是想表达，把云用好的安全责任是归属云用户的。即，上述云配置的安全风险责任是需要甲方自己关注的，甲方需要根据自己的业务特点，使用云服务或产品的功能来安全的服务自身业务。

笔者在《新视角下企业云化安全治理框架OCBC》一文中，已提到云产品安全基线，本质上也是希望解决云产品使用中的配置安全问题。

图2 AWS责任共担模型

CSPM介绍

CSPM定义

好了，了解以上的背景后，我们现在看一下，Gartner对CSPM的具体定义。刚看到图1时，部分读者可能会非常好奇，为什么讲CSPM，还要关联带上CWPP、CIEM、CNAPP等名词。因为从现在的时间看来，Gartner自身对CSPM的定义也是日趋丰富和完善。

另一个希望表达的是，无论是CSPM抑或CIEM、CWPP等间都存在着关联性。这点，笔者后面会再讲。

为免翻译带来的理解差异，笔者直接引用Gartner的原文最新定义

Cloud security posture management (CSPM) consists of offerings that continuously manage IaaS and PaaS security posture through prevention, detection and response to cloud infrastructure risks.

在上述的定义中，可以清晰的看到几点：

1.CSPM管控对象为IaaS、PssS，注重的是infra的风险

2.CSPM管控的是对象的Security Posture

3.CSPM管控能力覆盖prevention、detection和response

4.CSPM具备持续管控的能力

现在基本可以理解CSPM的定义和定位了。

这里也说下关于CSPM的中译，看到不少文章将其翻译为云安全态势感知。笔者很早前看到这个翻译的时候，最大的疑惑是既然翻译成态势，Gartner为什么要用Posture，而非用situational。在相关介绍中，笔者亦发现Gartner解释CSPM应视为一个持续改进和适应云安全配置的过程。综合可见，CSPM中的Posture是指配置，而非态势，所以将CSPM翻译为云上安全配置管理是恰当的。

另外，从当前多数CSPM实现管控的原理也能看到，其对接的是对应云管控环境中的配置审计等日志信息，所以本质上也是配置或云产品或服务基线管控的一部分。

当然，乙方厂商在落地CSPM时也一直在夹“私货”，这里我主要CSPM的一些通用能力。

CSPM功能

根据笔者调研来看，CSPM一般具备如下通用能力

1.云服务配置风险安全检测能力。这个属于CSPM的最基础能力，是真正考验乙方厂商CSPM好坏的一个最根本指标。同时，该能力需要能够支持自定义和调整。

2.合规检测能力。例如可以支持国际上常见的PCI DSS、SOC 2、GDPR、RMiT金融标准合规检测；国内常见的等保三级、网络合规管理检测等。

3.多云管理能力。支持跨云检测，如同时支持阿里云、AWS、GCP等

4.自动修正的能力。发现了云服务配置风险，支持自动进行修复。

5.报表能力。各种炫酷的展示等等，算是Plus项了。

当然，随着2020年CNAPP的产生，CSPM的功能和定位也在持续扩大。正如图1显示的那样，CSPM出现后，Gartner又提出了CIEM、CNAPP等名词，希望更广的覆盖云原生的安全防护。但是，确实名词太多，各名词功能定位有重叠。笔者就与CSPM关联性比较高的2个做下对比介绍。

CSPM关联对比

CSPM与CIEM

正如图1所示，2020年，Gartner又提出了CIEM，即Cloud infrastructure entitlement management ，寄希望于解决账号权限的风险。这里还是直接放下Gartner的原文定义：

CIEM offerings are specialized identity-centric SaaS solutions focused on managing cloud access risk via administration-time controls for the governance of entitlements in hybrid and multicloud IaaS. They typically use analytics, machine learning (ML) and other methods to detect anomalies in account entitlements, like accumulation of privileges, dormant and unnecessary entitlements. CIEM ideally provides remediation and enforcement of least privilege approaches.

原文就不做解释了。谈下个人对CIEM的理解，

本质上，CIEM 关注的是身份或账号，这里的身份不仅仅是从用户侧来看，同时还关注云基础设施和服务的权限。通过以最小权限原则来解决身份权限过大或不当的风险。不过，目前看到多数实现CIEM的商用产品，仍是以采用事中或事后监控的逻辑来实现身份风险管理，这本质上与甲方诉求是有差距的。

另外，更尴尬的点出现了，CSPM其实也可以用来解决这个问题，而且在CNAPP云原生应用保护平台解决方案中，也能发现这个控制点也被揉到了CSPM的功能中。所以，从这个维度上看，CIEM的地位是略尴尬的，但是它的重要性不言而喻，CSPM也扛不起这个大旗，后面会进一步解释。

CSPM与CNAPP

Gartner视CNAPP为统一化的云安全管理平台。在《CNAPP创新洞察》报告中，针对云原生应用保护平台（CNAPP）解决方案其认为是涉及基础设施即代码（IaC）扫描、容器扫描、云工作负载保护（CWPP）、云安全态势管理（CSPM）等跨越开发和生产环境的关键能力。

从作用上看，CNAPP能够为云原生客户真正提供端到端的云原生应用保护，提高云原生应用的安全可见性、改进了兼容性、加快了风险识别能力、实现了风险和合规检测自动化。

从图3可以看到，CSPM是CNAPP整体解决方案中一环，而且扮演着非常重要的角色。但CNAPP出现的时间落后于CSPM几年，或者Gartner也是看到了云管控的复杂性，孤立的点状解决，不如来一个大一统“集大成”的便捷。

另外，在“安全左移”理论的作用下，CSPM的功能在前面提到的通用能力基础上，又增加了IaC扫描、云威胁检测和响应、恶意软件/敏感数据扫描等功能属性，有点“既要又要还要”的味道。但这种类似自闭环的小SOC，如何在甲方安全架构体系下生存是个问题。

图3 CNAPP云原生应用保护平台

CSPM挑战与实践

前面介绍了CSPM的前世今生，而且亦对与CSPM密切关联的CIEM、CNAPP做了对比。笔者最后介绍下自身在实践中面临的一些挑战和当前的探索。

挑战

由于我们的业务完全依托公有云而建，所以在讲挑战之前还是介绍下云厂商在这块已经做的事情。以某云上此块已有的类似CSPM的能力为例。

1、配置审计，重点关注的也是配置风险问题，无论国内还是海外的云厂商，一般都会有config类产品。

配置审计中已内嵌了部分合规包，而且也支持自定义规则，相对来讲属于低成本的一个实现逻辑，作为辅助快检还是可以的。当然，它也带一定自修正的能力，敢不敢用属于另外一个维度的问题。

图4 配置审计功能示例

2、针对基础设施权限管理，在其云安全中心中提供了云平台配置检查模块，涵盖CIEM、常规云产品安全风险和合规风险。出现的时间不长，但是功能迭代和丰富度进步蛮快。

图5 云安全中心功能示例

我们当前是结合这2类产品的部分功能辅助做一定检测使用。但仍然会面临一些挑战：

1.无论的云厂商提供的类CSPM功能产品或商用产品，本质上仍处于事中/事后监控的管控逻辑。云上的基础设施权限和云服务配置管控的特殊点，天然的决定了监控管控逻辑带来的治理成本高昂，尤其业务上线跑起来。我们更希望以事前的阻断逻辑去做好管控，辅助以事中/事后监控逻辑来做好检测。

2.多云不是我们面临的场景，但多账号是。当有20+以上的云账号需要去管控的时候，监控Detection管控逻辑带来的运营成本和压力是巨大的。

3.配置审计功能一般云厂商可能会免费提供，但是云安全中心云平台配置检查功能是收费的，费用也是不低的，尤其在海外区域。

4.云厂商或商用产品是站在通用逻辑和风险维度去做这块能力，虽然云厂商的此块能力的进化速度很快。但仍然无法结合企业云上架构自动生成足够可信的风险检测结果，误报率是绕不开的问题。另外，商用产品完全依赖云厂商API的开放程度，这块的瓶颈是在选用商用产品时不得不考量的点。毕竟要想看得深，首先需要看到见。

5.无论云厂商或商用产品，此块能力完全依赖对云infra风险的认知程度，主要看2个维度。

1）覆盖度。覆盖度是指检测能力对云上产品和服务的覆盖面，是否能实现多数覆盖是个挑战，这块对商用产品挑战更大。

2）丰富度。丰富度是指针对单一产品或服务检测的维度和深度能达到多少，规则数是一个衡量指标。

这块云厂商是有天然优势的，但仍然会面临其他的问题，怎么去整合关联方同时跟进节奏。在《新视角下企业云化安全治理框架OCBC》一文中，笔者也曾提到，云厂商各个产品是独立的，每个产品多数时候是站在自身的维度来考量功能实现，安全不是第一选项。同时针对多产品组合使用的安全性和风险问题，更不是第一考量项；加之各云产品的迭代速度出奇的快，一个新功能点的引入都有可能对甲方安全架构产生影响。因为，作为用云企业，是无法和云厂商提出云产品的升级迭代与否由自己企业来自主决定的要求的。

实践

基于CSPM仍偏向事中/事后的管控逻辑，与实际业务场景事前管控、与内部平台强耦合的特性有着较大的差异，我们结合业务特点，针对云权限和配置安全管控我们采用如下的管控逻辑来实现自身的诉求。

图6 云权限和配置风险安全管控

云权限和配置风险安全管控整体上遵循事前、事中和事后的思路逻辑，功能上

1.覆盖常规CSPM通用功能、云基础设施权限管理等

2.针对云产品自身风险治理，管理更前置化。在云产品选（评估）的阶段安全就进行介入，保证先评估，后准入，再购买机制。

3.针对人员、应用的云服务和产品权限使用以自建化能力，遵循最小化权控原则，并确保AK自动化托管，实现事前风险收口

4.采用基线风险监测和有效性检测二重机制，确保基线可靠性落地，绕过基线管控风险检测。

当前部分功能仍在建设阶段，后续会结合控权逻辑再综合进行介绍。

写在最后

CSPM的出现本质上是为了解决云配置安全风险的问题，Gartner在CSPM的定义中也强调其能力覆盖prevention、detection和response。但是在甲方复杂的业务场景下，prevention实现的难度和复杂度甚高，对乙方厂商要求产品通用性和可复制性的原则指导下，更不会愿意去介入前置的动作。

但是，依赖事后追着治理的思路对甲方来讲是非常被动的。仅仅作为事后监控的机制，显得略鸡肋，毕竟云厂商已经提供了类似的功能点，而且商用产品又完全依赖云厂商的API开放能力来构建规则，本身是存在弱势的。另外，就是对国内云厂商的支持力度参差不齐。

最佳实践往往是在特定基建上的落地，可以参考，但不一定能借鉴。作为甲方，结合自身业务特点，选择最适宜的方案才是上册，博众家之所长，补已之短。

-------------------------------------------------------------

‍