CASB： 一场镜花水月还是云安全的未来？

作者：Yitao，，文章转载自Sec-UN安全村（www.sec-un.org）

脱胎于SaaS的CASB

安全产品一定是伴随着信息化发展而演进。长久以来，和CASB脱不开的一个词—SaaS，已经在美国已经发展了十几年，2008年-2011年IaaS高速发展，随后SaaS迎来了井喷发展期（毕竟IaaS是SaaS爆发式增长的基础）。最早涌现的CRM和HR类的SaaS服务长期以来（2016年以前）占据着市场份额的80%以上。随后协同类（云盘，办公协同），工具类（service desk和文档撰写）逐步成熟，也开始占有自己的相当一部分市场份额。

总结一下企业广泛使用的SaaS，都是属于“后勤保障型”应用。这些应用的特点也是很鲜明：功能标准、几乎无行业差异性、企业刚需、业务逻辑标准化程度高，复用率可以达到70%。同时这些应用也是企业降本增效的关键应用，容易获得付费用户。当然，上述特点的一个支撑是SaaS都是创业公司先做的，因为没钱没人，所以一开始很难切入耗时耗力的行业定制化应用，从而选择这些标准化程度高的领域先做。

美国的CASB公司都是在2011年前后创立，2013年前后开始销售产品。时间和SaaS的爆发时期基本是重合的。SaaS这云上的应用服务，特点是从底层硬件资源到应用软件全都是由服务提供商来提供，用户只需要用（上传数据），这样问题就来了。美国的安全建设理念是风险驱动的，要防范风险，SaaS的使用其实是突破了过去的安全边界，所有处理和存储企业数据的系统（或资源）都是企业无法控制的（不是企业拥有的），安全风险自然就来了。而且，企业员工还会使用很多企业不知道的SaaS，这就是所谓的ShadowIT，让安全风险更大了。

过去，企业能够掌控基础设施、应用软件、数据存储，安全也是围绕这些建立的，但是SaaS来了，不但企业自己采购的SaaS服务资源不受自己控制，还多了很多企业压根不知道的SaaS，被不知道哪个部门的员工使用。而当时已有的，包括现在除了CASB以外的安全手段对于SaaS和衍生的ShadowIT都是无效的。正是云服务的大量使用，让企业安全负责人抓狂，希望能够找到一个方法能够看见到底有多少ShadowIT，用户、设备、数据在云中的活动情况，当然最好还要能够对用户使用（访问）云应用进行控制，这就要回答一个问题：我怎么能保障我的数据在别人的系统里是安全的？就这样，Cloud Access Security Broker来了。

云服务安全治理是CASB的核心作用

云安全目前有两种视角，一个是“Delivery security from the cloud”，另一个是“Securing access to the cloud”。前者通过已有安全产品/技术（比如Web安全，邮件安全，网络安全）云化来实现，后者通过CASB或IDaaS这样的产品/技术来实现。这两者虽然有关系，但是从根本上是不同的，包括作用范围，产品价值，设计理念，部署模式，以及对于用户、数据、动作、会话（session）、事务（transaction）和应用的管理生命周期中的位置都不一样。

简单来说，云上资源企业能掌控的话，会更青睐于用比较熟悉的传统方法，碰到了云上资源全都掌控不了的时候，就得用CASB来解决，因为能做的也就是确保对于云的访问是安全的。

Gartner给出的CASB的4个能力支柱：Visibility（可见性）、Data Security（数据安全）、Threat Protection（威胁防护）、Compliance（合规）。

其实这4个能力支柱的顺序也是有变化的，在早期的CASB Technology Overview中，Compliance的顺序是排在Visibility之后的，而新的报告中，Compliance的顺序被排在最后。原因是云服务的和合规性做的越来越好，以及企业在Cloud Adoption的过程中合规满足的越来越好，进而弱化了Compliance能力在CASB中的地位。与此同时，数据安全问题和云中特有的威胁与日俱增，强化了CASB在这两方面能力的重要性。

在CASB产品的早期，可见性和加密是两个方向，随着时间的推移，可见性成为主流应用场景，当然还伴随着其他应用场景的出现，但不是加密，而是针对云服务的DLP，自适应访问控制和UEBA，对于大多数客户来说，加密仍然没有成为选择CASB主要因素。CASB的价值已经从最早期的提升云服务的可见性，演进为帮助企业完成云服务治理了。

用CASB提升云服务可见性，发现ShadowIT的故事，与NGFW横空出世颠覆传统防火墙时所讲的故事如出一辙。无非一个是云应用（企业级、SaaS），一个是互联网应用（偏向个人、带客户端）。CASB的可见性能做到：通过整合视图展示企业云服务的资源使用情况，谁通过什么设备在哪里访问了云服务（执行了什么操作，使用了什么数据），包括对云服务进行风险评估（计分、打分）。这里的可见性其实隐含了安全的一个典型需求，即识别和访问控制的颗粒度越来越细。

CASB所以提供的数据安全能力，以DLP为核心，辅以加密、令牌化、DCAP、EDRM能力。与精细化的访问控制相结合，防止未期的数据使用发生，比如企业敏感数据共享到外部，或将数据从企业资源转移到到个人资源，亦或在不恰当的时期发布了不恰当的言论等等，使用场景和传统DLP并无本质区别，无非就是DLP的作用环境从本地内网转移到了云上而已。既然核心是DLP，那么云上数据的发现、分类、分级，用户对敏感数据的访问行为监测，以及特权账号的权限扩大等等都要支持。

但是CASB上所支持的DLP只是Lite版本，比如内容识别只支持基础的三板斧（关键词，正则，模式），更高级的内容识别技术并不支持，如果需要，则须与本地部署的DLP设备进行联动，这样的做法十分经济，因为目前看传输到SaaS的内容格式并不复杂，基于三板斧即可覆盖大多数场景。

加密没有成为CASB的主流应用场景，很大程度上是因为用户担心加密后对于业务连续性的影响，同时确定的问题就是会影响一部分应用功能的使用，比如统计类功能。因此只有当用户涉及到严厉的合规要求以及数据主权问题时才会选择加密，比如PCI-DSS，GDPR等等。

CASB的威胁防护核心解决的问题是通过自适应访问控制能力防止未期的设备、用户，也包括未期的版本的应用来与受保护的云服务进行交互，能识别和响应恶意会话或不想其发生的会话（unwanted session），响应动作至少包含：允许、限制、触发多种级别告警、立即发起额外的认证要求、结束会话等等。而要识别什么是“未期”的，则需要利用UEBA的能力来发现异常行为，辅以反病毒、入侵检测、云沙箱、威胁情报等功能来确定威胁。同时要能发现“Cloud-native”的威胁（阻挡专门针对云的攻击，以及云原生的攻击）。比如2017年上半年，某CASB厂商发现超过10万次失败的Office 365登录尝试，来自67个不同的IP地址，其目标是48个不同的企业。虽然发现IP地址是获取证据识别攻击者的种方式。然而，如果攻击源自云端实例，IP地址仅能判断攻击来自哪个云服务提供商，而非租用云服务的企业，更不用说攻击者的身份了。

企业不能因为上云就丢了“合规”，不管是企业的内控合规，还是外部的政策、行业合规都要满足，保证云上云下的合规是连续的、一致的。CASB通过合规模板来检测、审计企业使用云服务过程中不合规的场景，同时通过自身的安全功能帮助企业满足合规要求。

被并购可能是CASB创业公司的好出路

我们从客户选择、市场玩家、投资并购三个指标来看： 

指标1：客户选择情况，或者叫市场发展情况。看一下CASB市场的发展，从两份Gartner的报告中可一探究竟：

Market Guide for Cloud Access Security Brokers （2016.10）：

Magic Quadrant for Cloud Access Security Brokers （2017.11）：

虽然两个报告只相隔1年，但是Gartner把CASB的市场预期从85%下调到了60%（到2020年企业的采购比例），尽管Gartner同时认为到2020年，基本上所有的云安全失败都是企业自己造成的。当然好消息是经过一年时间，多了一倍的大企业选择了CASB，市场规模的增长率还是很高的。

另据CRN 2016年的新闻，CASB是云安全领域增长最快的子市场，到2020年将会达到75亿美金的规模，2015年只有33亿美金，到2024年市场规模会达到130亿美金。

      指标2：市场玩家。首先参考Gartner在2017年11月发布的首个CASB魔力象限报告。

• 领导者：Skyhigh（已被McAfee收购）, Netskope，Symantec（收购了两家CASB厂商）

• 挑战者：CipherCloud, Cisco（收购了CloudLock）

• 远见者：Bitglass

• 利基玩家：Oracle（收购Palerra），Microsoft（收购Adollom），Saviynt，CensorNet，Palo Alto Networks（收购CirroSecure）

11家入选的厂商中CASB独立供应商（Pure Player）只有三家：NetSkope，CipherCloud和Bitglass，其他的都是 “平台型厂商（Platform Vendor）”,其中不乏耳熟能详的知名大厂。其中有两家的CASB是自研产品：

Saviynt虽然也是在2010年成立的（CASB厂商普遍成立的时期），但是其核心产品实际上是基于身份的管理平台，保护目标是众多的云应用，交付形式也是SaaS，实质是IDaaS。其CASB产品只支持API模式，不支持代理，可见CASB只是再其产品线上丰富功能后的产物。

CensorNet是一家老牌做SWG的厂商，还有邮件安全解决方案，CASB是在其SWG产品线上衍生出来的产品。

指标3：投资并购

CASB市场是由VC催生出来的，所有的CASB公司几乎都是有VC投资的创业公司，已经吸引了超过5亿美金的风险投资。2011年自CASB公司成立以来，14家公司中已经有8家被收购了。发起收购方来自网络安全、企业软件领域的知名公司，都是为了补足自身的云安全能力。

上述三个评估指标中的任意一个，都表现出独立CASB厂商的存活形势很严峻。综合分析来看，独立存活下来的CASB厂商已经确认为CASB领域的头部玩家，而他们所提供的产品和解决方案也是代表了此领域的先进水平，和Palo Alto Networks，Symantec类似的大型安全厂商，McAfee已经出手Skyhigh，Check Point和Fortinet各自都已经完成自研CASB产品的正式发布与销售，Forcepoint也已经把Skyfence收购回麾下。目前看，具备收购能力的网络安全TOP级厂商几乎已经没有了。与此同时，头部CASB厂商的估值太贵，越发不具备被收购的可能。剩下的潜在收购方可能来源于企业软件提供商，比如Adobe，SAP等等。

目前CASB市场已经没有新创业团队的机会了（在美国），事实上也没有发现更多创业团队跟进这个方向。不论是从Gartner的预期下调，还是从快速的并购案发生，都表明这不是一个可预期的足以让一家公司从小做到大的市场；从数字上看，市场规模不是很大，不足以容纳很多玩家，收购案披露出来的最高也只有2亿美金（Adollom），最近的McAfee收购Skyhigh，没有披露实际金额，但是从Skyhigh的基本面看，在被收购前完成了D轮1亿美金的融资，4亿美金的估值，据消息人士透露，收购金额在7亿美金左右。这么看来，CASB初创公司对于VC来说虽然变现快，但是普遍回报率不是很高。

对于早期的CASB厂商来说，新产品的溢价红利其实很好的帮助了企业实现营收目标，随着CASB的普及，以及众多大厂的加入，新品溢价红利会逐渐消失，客单价势必会下降，账面上也就不那么好看了。

另外值得注意的是，从技术创新上来看，CASB和已有安全产品相比，最大的创新只有API这一点，CASB上所有支持的安全能力全部是现有安全技术。

随着云服务提供商的API愈发完备，给独立CASB厂商的挑战会随之而来（CSP，Customer，MSP）。首先就是云服务提供商（CSP）自己可以提供增值CASB服务给用户；另外就是有能力的用户（Customer）可以在自己搭建的监控平台上开发插件，完成和云服务的API对接，实现部分CASB能力（Sanction APP管控）；第三个挑战来源就是云服务提供商（MSP），他们对于云具有深刻的理解力和专业能力，同时还是用户上云的服务商，在他们的管理平台（CMP）上集成CASB能力（API模式）也是一个很不错的选择。

从销售层面看，Gartner在CASB魔力象限报告中明确要求，入围的厂商在2016年度至少要达到500万美元营收，至少25家付费企业用户，至少有25,000用户点。由此可见CASB的平均客单价至少在20万刀，单个企业的用户规模在1000个点，不论是从客单价还是用户规模，都显示CASB的用户群至少是中大型企业或更大规模的企业。

同时，CASB所支持的App有两个显著特点：

1. 单个APP可复制性强，覆盖客户多；

2. APP在单个企业内部用户量大，不是局限的（小）部门级应用；

独立CASB厂商所面对的目前还是金字塔尖的TOP级企业，这些企业乐于接受新兴技术，同时对于风险控制和合规有着苛刻的要求。但是从整个市场层面来看，还有大量长尾客户待服务，这些客户对于独立的CASB创业公司来说获客成本较高（或者说性价比相对较低），而大厂们则可以依托其广泛的销售渠道，庞大的Installed-Base客户群体来销售CASB（不论是独立产品还是新的订阅服务）。

无生态，不CASB

CASB是保护云服务访问安全的产品，如果没有丰富的云生态，没有庞大的IaaS和SaaS市场，CASB貌似也不会存在，所以CASB就是生于生态的。

此外，相对于其他现在已经广泛使用的安全产品来说，CASB其实是一个很奇葩的存在。奇葩之处在于，自己是一个独立的产品，却要具备与各种企业级系统整合的能力。

比如已经发展了近8年的CASB产品，DLP和UEBA这两大能力仍然是Lite版本，用户若需要高级的能力，就要与本地部署的DLP和UEBA进行集成。再比如和IDaaS或用户本地部署的企业认证系统（AD、SSO、LDAP、RADIUS）集成，来完善身份认证和授权的能力。更别说CASB支持的那些传统安全检测能力了。

如果说上述安全能力都可以不通过与外部系统集成（不需要生态），CASB都可以实现对应的简化版本，那么对于SaaS的保护，没有生态的支撑就寸步难行。

CASB的能力要求是保护任何用户通过任何设备在任何地点的对于云服务的访问，那么很自然的一个问题就是在企业外部的用户，通过BYOD对于云服务的访问该如何处理？这也是部署CASB产品的时候用户很容易提出的问题，俗称“导流”问题，即如何将流量导入到CASB中。

正是因为这个问题的存在，才限制了传统的正向代理和反向代理在CASB上的使用，让大家更推崇API模式。我们都知道，API模式主动权其实是掌握在云服务提供商手中，作为云源生的交互模式，API模式在美国拥有强大的生态，各家云服务提供商都很乐意把API开放性作为自身产品的基础能力之一，也就早就了CASB的API模式。

通过API，非受控设备的导流成为一件十分容易的事情，用户直接访问云服务，云服务会通过API将流量重定向给CASB（此时CASB充当了反向代理的角色），这就是美国CASB厂商比较推崇的Agentless Reverse Proxy。否则就要强制用户在终端上安装代理软件，而这种做法肯定是无法实现完整访问终端覆盖的。如果云服务提供商不配合开发，那么CASB就无法保护到所有对于云服务的访问了。

再比如，CASB很普遍的一个应用场景是能够识别出一个用户访问云资源是使用的私人账号还是企业账号，以防止敏感数据从企业资源转移到私人资源。这样的识别能力其实也是由CASB和云服务提供商配合来的。如果CASB独立完成这件事情，需要识别所有账号的访问源、行为模式和规律、交叉分析来确定。

再举一个例子，CASB厂商都表示自己的加密功能支持密文检索、排序。如果CASB厂商独立实现，则需要从加密算法入手，对于算法的优化、使用需要投入专业的算法级密码人才，并且对于性能和安全性都会有不同程度的影响。如果有云服务提供商的支持，CASB上就只需要按照以往的做法采用高强度算法进行数据加密，其他的事情都交给云服务提供商来解决，而需要做的事情就是联合定义数据交互的协议，也就是API即可。

事实上，除了传统的安全功能以外，CASB上还表现出了对应用请求的处理能力，而如果没有生态的支持，CASB就需要自己实现很多应用上没有实现的安全功能，这对于产品研发的投入将是巨大的，而且功能模块的复用性很低。因此我们有理由认为生态的支撑是CASB的核心，也是生存的土壤。

从部署模式看，在中美两国都有一些关注CASB的人士认为API模式是CASB的未来，原因更多是因为导流问题。实际上这种看法是不正确的。云中的交互就应该是基于API的，这也解释了为什么Gartner认为API模式是必须要支持的，而代理模式可以选择支持一种即可。代理模式相对传统，和用户现有用法相同，同时对于API支持不完备的情况，代理可以补足安全能力。

另外，CASB作为云服务要支持多租户，海量客户请求，对接后台多个SaaS/IaaS服务，如果全是用代理模式进行处理，对于自身的资源开销是很大的负担，会造成成本上的过度浪费，而API模式更轻，相同的资源投入，CASB可以提供更丰富的展示、分析能力，而不用把资源消耗在请求处理上。随着时间的推移，API会逐渐丰富，随之而来的就是代理模式的需求降低。

云访问安全管理的统一入口

进入2018年，Skyhigh，NetSkope，CipherCloud这三家比较知名的CASB厂商都开始宣传自家产品对于“Custom Application”的支持能力，比如免代码适配集成，从几天变成几小时的适配效率提升等等，做法各异，但核心都是基于对API的理解、积累，通过机器学习或人工智能的方法来提升效率。这种对于Custom Application的支持能力，并不仅是为了支持SaaS，所面向的市场应该是企业在IaaS上自建的应用服务。为什么这么说？

首先，从对云服务的支持进程来看，CASB首先支持的是SaaS服务，然后对IaaS（AWS，Azure，GCP）也开始支持，对IaaS支持的内容其实是对于IaaS资源的控制能力，实际上是IaaS的Console，这个Console其实某种程度上也算是一个应用。

目前在美国市场来看，SaaS已经是一个相对成熟的市场，市场格局相对稳定，意味着两点：

1.    头部SaaS的地位已经牢固到无法撼动，比如O365，BOX，Salesforce这样的，虽然17年开始发现有CASB厂商也开始支持SAP这样老牌软件厂商的SaaS服务，但是也还是在HRM领域，仍然没有跳出SaaS类型格局，也没有发现有真正的生产系统被SaaS化或被大规模以云服务模式交付的。

2.    虽然市场格局相对稳定，但是仍然有层出不穷的SaaS创业公司出现，在Other区域的工具SaaS会呈现更加碎片化，因此对于CASB厂商来说，再通过研发来适配支持更多碎片化的应用，投入产出比太低，因此选择用过去几年的经验积累+机器智能来覆盖更多SaaS服务是一个必然的尝试。

另一方面IaaS的发展仍然如火如荼，企业更加青睐于用云来完成数字化转型。企业要在上面搭建自己的中间件，软件平台，应用系统来开展业务，而这些资源的访问情况也应该被控制，而不只是控制到底层资源的访问，这样做其实是追求对于云资源安全管理的统一性。

当然，传统安全产品通过虚拟化，云化的方式也在IaaS环境中使用，但是不难发现，传统安全手段的云化，只是完成了交付形态的变化，实质能力并没有改变，而CASB所提供的高级会话级别的管理，而且是深入应用的，云原生的这些能力，包括能够对云应用访问提供持续的自适应的风险和信任评估，对于只是完成了基础云化的传统安全产品是无法做到的。

而通过这五年CASB for SaaS的市场教育，客户已经很清晰的理解CASB和传统安全产品的区别，自然也就会提出让CASB保护IaaS上自建应用或者PaaS服务的需求。因此CASB厂商支持Custom Application的能力，实际上是更多为了满足企业对于在IaaS上的自建系统安全管理设计出来的。通过这样的能力，实现IaaS，PaaS，SaaS全覆盖，真正实现云访问安全管理的目标。

随着企业更多地将业务置于云上，企业对于云安全的投入战略会愈发清晰，即IaaS之上自建的云上系统，保护方式仍旧由已有的安全方案负责，即Delivery Security from the Cloud；而对于不可掌控的SaaS，以及IaaS资源的管控，则由CASB来负责，即Securing access to the cloud。

结语

云计算（公有云）相比于传统计算环境来说是一种范式转换（Paradigm Shift），而这种范式转换让企业安全团队不再能够通过传统的安全方法来保护抽象的环境（云计算环境）。在发展中遇到的问题就要用发展的手段来解决，CASB就是这样一种发展的手段、Cloud-native的技术来保护企业用户对于不可掌控的云资源的访问。CASB这项技术在云计算安全领域所扮演角色的重要性，很有可能匹敌传统环境中防火墙的地位。但是从目前的各种情况综合评判，作为独立产品的CASB很有可能是昙花一现，但是作为基础安全能力，会长久存在于安全平台中。

声明：本文来自Sec-UN安全村，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。