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解決方案不保證比其他產品更能提供安全，理智的供應商都不會夸口說自己的產品包治百病，但瘋狂的供應商營銷方式也確實存在。但是，隨著核心企業應用往云端的遷移，越來越多的公司企業會發現自己需要什么東西來監管愈趨分散的各類資產。
用個比喻來結束本文，城墻雖然不再是趨勢，但這并不意味著城里秩序井然的街道布局就可以被打亂。
【本文是51CTO專欄作者“”李少鵬“”的原創文章，轉載請通過安全牛（微信公眾號id:gooann-sectv）獲取授權】
