以前コチラのページでCASBとは？ということで全体的な概要をまとめましたが、本記事では構成についてもう少し詳細に紹介しようと思います。
CASBのサービス
CASB自体はクラウドサービスとして提供されており、CASBでできることは主に
1. クラウドアプリの可視化＆リスク評価
2. クラウドアプリの各種操作の検知・ブロック・データ保護
の2つに大別できます。ライセンス形態も上記の分類となっていることが多いです。
上記のうち、1.の可視化についてはオンプレミスのファイアウォールやプロキシのログをCASBのWebサイトにアップロードし、自動で解析・レポーティングする機能になりますので、構成などは意識する必要はありません。
2.のケースでの構成としては
2-1. API型
2-2. プロキシ型
がありますのでこちらを説明します。
API型の構成
API型はOffice365などのクラウドアプリが用意しているAPIをCASBがキックし、データを収集・解析する形式で、すべてユーザーに影響のないところで行われるため、導入障壁が低いのが特長です。
また、過去格納されたファイルやメールなどを後追いで検査することができるのもメリットです。
一方、APIをキックするのは数分おきになるため、リアルタイムではなくニアタイムでの解析になり、アクセスをブロックするなどの制御もできないところがデメリットになります。
そのため、API型でDLP機能を使用する場合、機密情報を含むファイルの通信を遮断するのではなく、ファイルを別の場所に移動させたり、削除したりして実現する形になり、outlookでのメール送信を止めることなどは困難です。
プロキシ型の構成
プロキシ型はクライアントから見てCASBがクラウドのプロキシ(もしくはリバースプロキシ)として動作し、通信経路に入る形式です。そのため、リアルタイムでの操作の検知・ブロックが可能で、メールに対してDLPを機能させることも可能です。
また、OSやブラウザなどのクライアント情報を取得・利用できる点もメリットです。一方、インラインの構成になるため、導入障壁が高いのがデメリットです。
プロキシ型についても、クライアント側の設定方式がいくつかあります。
[2-2-1. pacファイルを使用する場合]
ブラウザのプロキシ設定にpacファイルを設定する方式です。プロキシを設置し、はpacファイルを使用しているユーザーではpacファイルのマージで対応ができます。
ただし、デメリットとしては、CASB側でSSLを復号化するため、ルート証明書をブラウザにインストールする必要がある点と、クラウドアプリ側のドメインが変更になった都度、pacファイルのメンテナンスが必要になる点が挙げられます。
[2-2-2. エージェントを使用する場合]
CASBが提供するエージェントをクライアントにインストールする方式です。
この場合、エージェントが自動的にクラウドアプリの通信を識別し、CASB側に振り分けてくれるため、pacファイルの設定が不要になります。また、エージェントがCASB故障時にはCASBを経由しないかたちで通信を継続してくれるため、pacファイルに比べて耐障害性が高いです。その他、outlookなどのアプリやモバイル端末に対応している点もメリットになります。
一方、エージェントのインストールを行うため、他のアプリとの干渉が読めないところがデメリットになります。
[2-2-3. オンプレミスでサーバを立てる場合]
クライアント側の設定が困難である場合、CASBが提供している仮想アプライアンスを使用して、オンプレミスでクラウドアプリの通信を
CASBに振り分けるプロキシ（もしくはリバースプロキシ）を構築します。既存でプロキシがある場合には、多段プロキシにすることでクライアント側の変更を一切せずに導入できます。
一方、独自にサーバを構築する必要がある点がデメリットです。
最後に全体とまとめてみると、
1. クラウドアプリの可視化＆リスク評価
1-1. オンプレミスのFWやプロキシログを読み込む形式
2. クラウドアプリの各種操作の検知・ブロック・データ保護
2-1. API型
2-2. プロキシ型
2-2-1. pacファイル
2-2-2. エージェント
2-2-3. オンプレミスサーバ
という構成パターンになります。
■こちらの記事もぜひお読みください！
Elastica CloudSOCは何ができる？
コメント