買収の裏にあるクラウドセキュリティとWebセキュリティの違い

CASBベンダーが買収される訳

前回は「正しいCASBの選択ポイント」について説明したが、実は今、純粋なCASBベンダーは非常に限られてきている。その理由と背景について少し説明しよう。

CASBにフォーカスした新興企業がシリコンバレーを中心にビジネスを伸ばしていったのは2013年頃だ。Adallom, CloudLock, Elastica, Skyhigh Networks, Netskopeと名だたるCASBベンダーがCASB市場を賑わせていたその数年のうちに、ほとんどのCASBベンダーは大手セキュリティベンダーに買収、統合されていった。

AdallomはMicrosoftが買収し、CloudLockはCisco Systemsが、ElasticaはBlueCoatが買収後にSymantecがBlueCoatを買収。今年に入りMcAfeeがSkyhigh Networksを買収し、残る主要CASBベンダーはNetSkopeのみとなっている。

こうした買収が行われる背景は非常にシンプルだ。世界的にクラウドシフトが急速に進んでいることからクラウドセキュリティのニーズが高まっているとともに、「クラウドは安かろう悪かろう」といった昔の観点と異なり、クラウドに対してセキュリティの投資を行うことは妥当という潮流がCASBのニーズを牽引しているからだ。

マルチクラウドにおいて各クラウド側で異なるレベルのセキュリティに投資するよりも、CASBをブローカー(仲介者)とし、マルチクラウドに対して一元的なセキュリティポリシーをかけることで、運用面・投資効果においてメリットとなる。これこそが、企業がCASBを受け入れる大きな理由だ。

そしてセキュリティベンダー側としては、CASBベンダーの技術を統合することがユーザーのニーズに対応できる手段として最適解となるからこそ、純粋なCASBベンダーは軒並み姿を消しつつある。買収される先は必ずと言っていいほど、「Webセキュリティ」関連の製品やサービスを持つセキュリティベンダーだ。

CASBと従来のWebセキュリティの関係

そもそも、CASBはどのようにしてユーザーが利用しているクラウドサービスを認識するのだろうか。

クラウドサービスはユーザーから見れば、インターネット上に存在するウェブWebサーバと何ら変わりはない。よって、各クラウドサービスにひもづくログインURLやIPをもとにしたデータベースをCASBは日々更新し、新たなクラウドサービスを認識できるような仕組みになっている。これはいわゆるWebフィルタリング(URLフィルタリング)と似て非なる判定ロジックに基づいている。

Webフィルタリングでは、一般的にURLやIPからそのWebサイトの属性(カテゴリー)を判定し、例えばGoogleならSearch Engine(検索サイト)といった具合に自動的に整理、各属性に従ったポリシーの適用により、業務上望ましくないサイトアクセスを制御する形を取るのはご存じだろう。

昨今では、正規のサイトですら攻撃者の改竄行為などにより、ユーザーがサイトを訪れただけで感染するような手口もある(最新の仮想通貨のマイニング被害はこの手口)。こうしたことから、単純なサイト属性判定では感染リスクを防ぐことは難しいため、フルパスURL(ドメイン配下のパスまで含んだURL：http://xxx.com/path/zzz.phpなど)に基づくリスク判定が提供されるWebフィルタリングが登場している。

一方、CASBはクラウドサービスをWebサイトの属性判定とは異なる視点で評価する。データセンターの場所(国)や、各種コンプライアンスへの対応状況(ISO27001、PCI DSS、GDPRなど)、データ管理上のセキュリティ対策(暗号化や鍵管理)、サービスの脆弱性対応状況、ユーザーアクセス制御や監査ログの提供など多岐にわたる。

これらの項目について、企業としてどの項目が「必須」であり、利用するにあたり「信頼」できるサービスとなりうるかの基準を決定する。設定された基準を満たさないクラウドサービスは「Shadow IT」と見なされ、自動的にCASB側でブロック対象となるような形を取ることで、企業として望ましくないサービスへのアクセスを制御することとなる。

• CASBとWebフィルタリングの連携の仕組み

つまり、Webセキュリティベンダーは、従来のWebフィルタリングとは異なる視点でクラウドサービスを評価するCASBデータベースを自社のWebセキュリティに統合することで、企業の「クラウドを含むWeb全体に対するセキュリティ」を提供できるようになったのだ。 裏を返せば、単純にCASBだけを導入した場合、CASBベンダーが提供するデータベースに対応していないクラウドサービスを利用すると、CASBの制御から「漏れる」こととなり、情報流出もマルウェアの侵入も対応しきれなくなる。

これに対し、Webセキュリティに統合されたCASBの場合、CASBデータベースにマッチしなかったサービスはWebアクセスと判断され、Webフィルタリングによって分類・属性判定される。その上で、コンテンツ分析やDLP(情報流出対策)ポリシーが掛けられ、証跡も残すことが可能だ。何よりも大きなメリットは、クラウドサービス上でやり取りされるWebアクセス(メールの埋め込みURLやクラウドサービス上のリダイレクトURLリンクなど)についてWebフィルタリング機能を利用できるため、クラウドとWebの通信のセキュリティにも対応可能な点だ。

これからのCASBはSecure Web Gateway(SWG)統合へ

このような背景があることから、導入済みのWebセキュリティ製品(プロキシなど)やサービスがある企業の場合、それらがCASBと連携できるのかどうかを確認すべきだ。仮にWebセキュリティ製品が未導入であれば、CASBを包含したWebセキュリティを検討すべきだ。そのソリューションこそが、実は、過去10年来存在していたソリューション「Secure Web Gateway(SWG)」になる。

• Secure Web Gatewayの仕組み

SWG自体はオンプレミスのWebセキュリティを各拠点、モバイルユーザーに対して適用するための技術で、URLフィルタやコンテンツ分析、SSL可視化、サンドボックスやDLP機能を包含する、ハイブリッド型のWebプロキシになる。SWGにより、Webやクラウドの違いを意識することなく、社内・社外問わず、企業のセキュリティ管理を一元化することが可能となるのだ。

第3回でも触れたように、SWGの利用においては「企業の機密情報を正しく判別できるDLPエンジンの精度」のほか、CASBデータベースが未対応のサービスに対して「正確な属性判定やリスク判定ができるURLフィルタの精度」、この2点が運用に跳ね返ってくる。そのため、導入後に後悔しないためにも、SWGを評価する際は価格や表向きの機能に引きずられないよう注意されたい。