A cloud access security broker (CASB) is on-premises or cloud based software that sits between cloud service users and cloud applications, and monitors all activity and enforces security policies.

Wikipedia

CASB 企业的现状

大致是从 2012 年开始，CASB 开始大行其道，自然最先的“始作俑者”还是国外的安全同辈们，以 CipherCloud、Blue Coat 和 Bitglass 为代表。海外网络安全同辈们的发展历程始终让人无比艳羡，剧本也是年年一致，火热的投融资和估值故事，然后在 5-8 年以内完成并购或者倒闭的结局。

当初收藏的书签都还在，全是关于 CASB 的新型企业，今天为了写这篇文章逐一试着打开这些站点，大部分都打不开了，提示域名不存在，还有几个幸运儿变成了更为熟悉的 Forcepoint，也就意味着被并购了。

CipherCloud 被 Lookout 并购了，Bitglass 被 Forcepoint 收购了，并购金额不详。

这些都是海外的 CASB，至少还有成功上岸的。国内的 CASB 怎么样了呢 ？

国内哪有什么 CASB，或者说国内全是 CASB。按照国内网络安全的做法，只要国外出了个新概念，国内统一全部都与时俱进推出了新的网络安全产品，同样的老产品变着花样的不停换标签而已。

CASB 产品的现状

CASB 虽然叫做云端安全访问代理，理论上就是 SaaS 云服务的安全代理，可以做很多网络侧的安全防护。不过最初的 CASB 真正被应用的场景，还是云端数据的加密，因为这是一个空白的场景，其它网络测的安全方案替代品已经很多，并不需要再包装这么一个新的安全概念用以营销。

还是以 CipherCloud 为例，这是当时最大也是最早以 CASB 名义成立的企业，产品也是可圈可点。CipherCloud 官网已经不存在，读者可以通过 Google 去搜索一些还残存在网络上的余孽信息，获得一点当初的线索。作者对这家公司以及其产品无比熟悉，也是因为曾经 4 年的时间视之为竞品，研究也算深入。

上面这张图是 CipherCloud 的核心架构，核心中的核心就是其加密引擎，Cloud Encryption Gateway，负责在流量层透明的加密应用数据，可以是结构化的敏感数据，比如客户信息，也可以是非结构化的数据比如各类网盘的文档。

CipherCloud 要保护的应用，也是那些大行其道的企业级 SaaS 应用，比如 Salesforce、SAP、Dropbox、Office365 等等。加密的效果就像下面这样，假设应用是企业员工使用的客户管理系统（CRM），当员工比如销售人员通过应用客户端（浏览器或者APP）录入客户信息并提交后，CipherCloud 的加密网关自动识别到流量内的敏感数据，如客户姓名、联系方式、家庭住址等等，于是直接将数据加密后再代理提交到服务端存入数据库。这样的效果就是数据库直接存储的就是加密后的密文，可以防止应用开发者看到，防止黑客脱库。如果应用的使用者因为违规或者被识别到有异常行为，那么想要通过应用查看数据的时候，不再解密就行，看到的就是下面这张图里的效果，都是乱码的数据，没有任何意义。

针对各类企业网盘内的文档，处理逻辑一模一样。这就是原始 CASB 真正想干的事。

加密，是七伤拳

在信息安全里，加密是各个环节都无比推崇的方式，但实不相瞒，加密就跟武林绝学七伤拳一样。其效果是“未伤人先伤己”，“杀敌一千，自损八百”。

回到 CipherCloud 的逻辑，其加密成功需要有无数个前提条件，加密后还得带来更多应用障碍。

加密前提：

1. 如果应用本身有针对请求做签名校验，那么加密势必破坏请求结构，致使网络任务失败

2. 加密后数据变化，如果后端服务有校验数据格式，那么加密最终也失败。比如服务端收到客户端的客户邮箱数据的时候，识别出不是一个合法的邮箱地址，就会拒绝该次操作。

3. 数据库字段类型不匹配加密后的数据，导致存储失败。比如存放电话号码的自动最大长度设置为 11 位，加密后的数据转变为 Base64 编码后长度必定是之前的1.5-2倍，甚至之前的数库字段类型为数字，现在变成普通文本，都会导致存储失败。

加密后：

当加密突破层层阻碍，终于成功之后，接下来面临的就是应用可用性的问题。

1. 模糊检索没有了：应用提供了模糊检索的能力，数据库都变成无意义的密文了，比如原本的电话号码 18722221111 变成了现在的 "Pc+UrvfCxBU8JKEgXSpPq+JdsRS3aS/2Hb+TBf=="，用户在应用界面提供的搜索框里输入“187”后，后端数据库将不会返回任何内容。

2. 数据统计与计算影响：同样的数据库里的金额等数字都变成密文了，最简单的求和统计也无法完成，一切依赖统计计算的应用功能也都失效。

因此 CASB 原本设想的路径无法行得通了，不得不开始转向基于网络数据采集而进行的 UEBA 用户异常行为分析，以及数据资产判断，影子 IT 发现等方向，但是做这类方向的企业又是何其的多如牛毛。海外最终的转向定格在了 Cloud DLP，如同下面视频介绍一般。

国内 CASB 能做什么，做了什么

海外 CASB 定义的逻辑还算直观明了，国内安全公司能做什么，做了什么呢？

答案是几乎什么都做不了！

核心的技术原因还是国内没有国外开放的应用生态，国内安全企业有心无力，看这里就知道为什么了国内安全企业造不出通用应用保护产品的原因。

大家想想具体场景就一目了然，比如我要提供一个 CASB 的安全产品，去给使用百度网盘的企业，来自动加密企业的文档。作为一个第三方的安全企业，我怎么把自己的加密网关部署到企业和百度网盘之间呢，没有办法。

那 CipherCloud 怎么解决这个问题呢，比如加密国外的 Dropbox。答案是依赖 Dropbox 无比开放的生态和接口。

Dropbox 提供了丰富应用开发接口，开发者可以订阅网盘内用户的所有行为，比如创建新文件，修改和下载文件等。并且支持实时的拦截和处理，以确保文档的正常加密和解密流程。国内的网盘没有这些能力，也就限制了第三方应用的可能性。

国内优秀的 CASB 尝试

虽说国内做不了通用的 CASB，但是还是出现了些许优秀的探索和创新者，比较认同的是众至科技的产品，这里并不是特意软广，而是真的调不出来别的案例了。这家早期的 CASB 别出心裁地做了针对对象存储的透明加密 casb 产品，非常巧妙。面向开发者，避开了需要模糊搜索和计算的场景，而且客群极其广大，现在还有哪家应用不使用对象存储呢，阿里云的 OSS，腾讯的 COS，AWS 的 S3。

CASB 过去了，SASE 开始了

SASE 与 CASB，无论在技术实现上，还是应用场景里，本质并无差异，当然了并不完全等同，后续再单独针对 SASE 进行分享。

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