CASB的四大支柱和容易踩上的“坑”

云访问安全代理(CASB)技术是个快速成长的市场，该技术旨在帮助公司企业在云端应用各种安全策略。CASB是云端安全这个老大难问题的解决方案，但选择哪种CASB最适合自己？又如何规避一些常见的陷阱？

万里长城曾是抵御侵略的坚实基础，是以城墙为主体，同大量城、障、亭、标相结合的中国古代第一军事工程，赋予了中华先民莫大的安全感。如今，长城的防御作用消退，城墙也演变成了历史遗迹、旅游胜地。这种边界防御控制力消退的感觉，技术主管们应该不会陌生。

在云技术诞生前，公司企业以边界圈住自身资产加以控制和保护。边界之内皆我所有，边界之外非我族类。在边界内实施安全策略，确保没有任何恼人的东西翻墙而过，安全人员的工作就算完美搞定。

云技术落地开花的当下，公司数据和系统分布各地，往往技术主管自己都不知道他们的数据存放在哪儿，也不知道是跟谁共享自身关键系统所依托的服务器。

如此离散的系统，要怎么应用公司的安全原则呢？

答案之一，就是云访问安全代理(CASB)。

CASB是帮助公司企业在云端实现安全策略的系统，位于云服务提供商和消费云服务的公司企业之间。CASB概念近几年逐渐引人瞩目，很多咨询公司都预测，到2020年其市场将达75亿美元规模。

市面上的CASB提供商很多，迈克菲（2018年1月并购 SkyHigh Networks）和赛门铁克这种传统安全供应商、微软和Oracle这样的软件巨兽，以及Netskope和Okta之类新兴专业CASB提供商都在场中竞争。

何处着手？

技术主管实现CASB时要跨越的第一道障碍，就是理解从何处着手。

Gartner云安全研究总监 Steve Riley 建议公司企业从特定于客户具体需求的用例详单开始。

要考虑终端用户将会怎样与云服务交互，与何种设备交互：CASB能为托管设备和非托管设备提供不同的SaaS功能。

这有助于终端用户从个人设备访问公司敏感数据。CASB解决方案能将信息转换为更安全的只读格式，比完全禁止访问更利于公司业务开展。

可以多设想一些员工与数据互动的场景和对公司而言非常重要的云服务的种类。然后你就能理出一套概念验证，大幅减轻CASB实现的难度。

CASB的三种主要模式

CASB解决方案主要有三种：仅API、仅代理，或多模式（即有API也有代理）。

基于API的CASB为企业用户定义出可以访问的一些云应用。举例来讲的话，CASB会接管其客户 Office 365 (O365)用户的管理权限。用户登录后，该应用的流量会被转移到CASB提供商处，由CASB提供商负责在发往O365前检查所有数据。

Netskope欧洲、中东和非洲片区副总裁 André Stewart 说：“数据不在网上，而是发给应用，我们在那儿查看所有文件，扫描任何恶意软件迹象。”

仅代理CASB模式下，所有流量先流经该安全提供商的云，在其上经受企业策略合规检测，然后再发往互联网或本应发往的云应用。

这两种模式的区别在于，基于代理的CASB能处理经批准的和未经批准的应用，来自任意类型设备的所有流量都转发到提供商的云。

第三种模式——多模式，则根据用例为终端用户提供API和代理选项。

那么，有没有明确的“最佳”选择呢？

这就要看具体用例是什么了。最终选择要根据企业的云应用和连接来做出。因为能处理任意应用而不仅仅是IT部门单列出的那些，基于代理的架构更为全面一些。但是，特别注重安全的企业，或者监管超严的行业，会想要限制云流量仅发往他们认为合适的应用。于是，所选为何，还是要落实到具体用例上。

CASB是干什么的？

CASB主要做4件事：发现公司在用哪些云应用；保护数据；抵御威胁；确保合规。Gartner将这四点视作CASB的四大支柱。

CASB市场竞争激烈，供应商都想在这4个方面脱颖而出。有些供应商这4个方面均衡发展，有些则重点发展其中几个方面但仍保持全部4个方面的基本功能都有。最初，CASB要么专注可见性，要么重在加密。随着产品日渐成熟，可见性继续保持重要用例地位，但新增用例也达到了相同甚至有过之而无不及的重要程度。

虽然没有任何一种CASB产品能完美贴合每个用例，但专业独立CASB平台（未必总是来自独立CASB供应商）正推出更多功能，覆盖更多云服务，支持更多企业用例。

其敏捷性远胜云服务提供商交付服务的速度，也远远超出在已有安全技术上将部分CASB功能作为插件提供的其他厂商。而且，主流CASB供应商的平台根植于云，为云而生，对用户、设备、应用、交易和敏感数据的理解比传统网络安全产品及服务的CASB插件强的不是一点半点。

一些案例

于是，供应商选择再次归结到用例上。但是，到底该看哪些用例？公司企业决定部署CASB解决方案的最常见原因是什么呢？

通常，尝试解决云安全问题的终端用户有两种。一种是向云端迁移或意识到自己大半数据已经在云端的传统大型企业。另一种是几乎没有什么现场基础设施的云优先企业。CASB供应商视线所及更多的是前者。

前者想要知道自己的数据都在哪儿。因为他们的影子IT往往会催生出可见性用例。

这种企业中的各种业务会不断引入新AWS实例，或者在云端为HR部署各种应用，而IT部门就试图确定自家公司的云应用规模到底有多大。

大多数IT主管都会被审计结果大为震惊，惊讶于自家员工使用的云应用数量，只有极少数CIO会在被问及影子IT问题时表示自家公司对此牢牢把控。《Computing》最新的调查研究揭示，8%的欧洲公司在公共云服务使用上完全是个人用户的自主行为。

公司规模越大，情况越糟糕。拥有5万以上员工的大企业，通常会发现自家员工在用的云应用有3000-5000个之多。

仅云存储应用，大多数大企业就在用Box、DropBox、WeTransfer等等。专业CASB供应商Netskope分析过的某公司甚至在用40多个未经批准的云存储应用。

有些人可能会觉得这么做挺好的：然而，只要我们知道云提供商在确定用户身份上的孜孜不倦，我们就会意识到这么做是短视而危险的。

公司企业往往不知道其员工使用这些服务时都签下了哪些条款，有时候这意味着他们甚至都不再拥有自己的数据了。

以上便是发现用例存在的原因了。接下来，公司企业还想对所用数据施加一定的控制。当公司发现员工在用3种不同HR工具做同样的事时，就会想要整合这些工具，封掉那些有风险的，教导用户使用经过批准的那些。

而一旦有了“合法”应用列表，比如说，把原来的40多种云存储应用整合成仅能使用Box、OneDrive和DropBox，公司企业就会想要对这些云存储服务中的数据加以控制——不同等级的访问权限之类的。之后，公司就能控制哪些数据可以公开共享，哪些需要应用数据丢失防护(DLP)规则了。这样一来，在遭遇恶意软件攻击时，至少云端数据还是干净而安全的。

很多公司开始在向O365迁移时考虑部署CASB，作为传统现场办公套件的微软Office，如今正将其部分客户推向云端。

公司企业之前可能一直在用Salesforce之类的东西，但出于某些原因没觉得自己的数据是在云端。O365强调出一个事实：公司企业应将安全边界覆盖到数据和应用领域，而不仅仅保持在物理边界的定义上。

另外，随着BYOD的逐渐深化，甚至核心业务过程也开始有员工用自己的智能手机和平板处理，这就让设备控制也成为了颇具吸引力的想法。

GDPR是推动公司企业迈向CASB的另一个原因。在数据发往云端之前就加密，能降低个人可识别信息(PII)泄露的风险。更不用说高达至多4%年总营业额的巨额罚款对CASB采纳的推动作用了。

最后，DLP也是常见的用例。

关键是要确保机密信息只能被正确的人访问而不会公开共享。有些公司特别担忧自己的数据会流向哪里，应用CASB就能设置合理的过滤，只要数据去往不该去的地方，就能立即追踪并加以处理。

即便是故意忽略了有效用例的情况，供应商们也会敦促公司企业部署CASB的。大多数大型企业软件提供商就正在将现有客户迁往云服务，无论愿不愿意，软件更新周期最终都会落到云端。安全团队不得不求助于CASB功能来应对新的环境。

小心陷阱

接受了CASB概念，通过了商业案例，下拨了购置预算后，CASB购买就成了顺理成章的下一步举动。与很多服务协商类似，购买中需要注意的是许可条款，否则很容易掉进“坑”里。

这是因为CASB供应商使用的许可模式在复杂度和细节方面区别很大。如果可以的话，尽量选择简单许可模式。Gartner建议采用基于2个简单指标的模式：云服务数量和用户数量。

CASB定价通常按每个受保护云服务所用的功能（或功能集）来算。如果DLP是关键CASB用例，很多供应商会要求每个云服务都购买一份。Salesforce买一份，O365再买一份，ServiceNow还得另买。好的许可模式应能在当前预算周期内覆盖所有云服务和用户所需的CASB功能。新云应用的上线使用，不应造成需得根据预算在哪些应用和数据可享受CASB保护上做出取舍。

部署之后也有陷阱，有些陷阱是加密环节上的。如果你的CASB解决方案会加密数据，那你的故障恢复、云应用访问很有可能马上无法使用。

同理，如果CASB对云服务功能的映射因某个云服务更新而过时，CASB可能会中断该云服务。更重要的是，数据加密或数据令牌化往往会影响SaaS应用的终端用户功能，尤其是搜索、索引、排序、现场级数字运算和企业文件同步共享(EFSS)中文档预览一类的功能——如果对象级附件被加密的话。鉴于此，除非是监管有要求，否则任何时候就不要考虑采用外部云数据防护。

有些公司企业甚至会被其SaaS供应商建议不要安装CASB解决方案。比如说，微软就不喜欢代理、缓存和WAN优化器这样的产品部署在他们的服务之前。微软的考虑是，这些产品会引入延迟或其他问题，而微软服务本身就成了代罪羔羊。当然，客户没必要取悦自己的供应商，该怎么办还怎么办就好。

CASB部署后也不可急功冒进，妄想瞬间掌控一切。

CASB项目不应试图从一开始就控制和监视所有可能的云应用。云使用可见性基线建立起来后，最好是基于风险给所有云服务排个序，确定出最先进行监视和控制的云服务。

可以考虑定出一两个托管了公司最敏感信息的云服务，以此为起点，逐步扩展到所有云服务。

比如说，很多企业从单个最重要云应用开始——通常是Salesforce或O365。CASB项目还应包括从一开始就为关键服务启动DLP的计划。另一个扩展CASB项目的方法是先从仅限制托管设备访问开始，再慢慢覆盖到非托管设备。因为未来总会增加新的云服务，所以CASB合同中要为将来的扩充留有余地。

还有个常见问题是，买了全能型CASB解决方案，却只使用其中某几个功能。

确保用好用全自己的CASB。功能那么多，你可以控制下载到非托管设备上的数据，查找可能昭示着非法用户或凭证窃取的流量异常，还可以用上数据丢失防护。CASB是有多种功能选项的工具集，然而有些客户却只使用其中少数功能，这是个令人伤心的景象。

最后，不仅仅是CASB，任何采购都适用的一条最佳建议是，问供应商索要来自同等规模同样需求的公司客户的参考案例。如果供应商给不出，那就值得三思了。

CASB解决方案不保证比其他产品更能提供安全，理智的供应商都不会夸口说自己的产品包治百病，但疯狂的供应商营销方式也确实存在。但是，随着核心企业应用往云端的迁移，越来越多的公司企业会发现自己需要什么东西来监管愈趋分散的各类资产。

用个比喻来结束本文，城墙虽然不再是趋势，但这并不意味着城里秩序井然的街道布局就可以被打乱。