Symantec CloudSOC CASBを最大限に活用する方法（パート3）

前回のブログでは、見落とされがちなCASB Auditの実装に関する数多くの詳細情報について解説しました。  今回は、その他の考慮事項や考えられるリスクについて解説し、健全性の判断基準であるAudit導入とはどのようなものかを明らかにしていきます。

リスクを把握し、軽減する

Shadow IT監査プログラムの主な目的は、クラウドアプリケーションの中で、未知のもの、信頼できないもの、制御されていない（未認可）ものなどによるデータ流出のリスクを明らかにして、阻止することです。この目的は、Symantec CASBのCloudSOC Auditコンポーネントで実現することができます。

CloudSOC Auditによって、Shadow ITの導入や使用状況を明らかにし、制御することができます。CloudSOC Auditでは組織やBusiness Readiness Ratings（ビジネスの準備評価、BRR）で使用されているアプリケーションをすべて可視化して、約38,000個ものクラウドアプリケーションでサービスを比較することができます。管理者は、新たに導入したアプリケーションをレビューしたり、CloudSOC Auditデータベースに含まれていない仮想URL用のカスタムアプリケーションを作成することにより、BRRの評価を付けることができます。  これは、組織で業界のインサイトを使用したり、その情報を監査プログラム内で活用したりしたい場合に重要となります。  CloudSOC Auditには、アプリケーションまたはカテゴリーごとにカスタマイズできる機能を備えており、データ管理に役立つ、監査インターフェースへの追加要求や更新を提案する機能を提供します。 

本当にShadow ITプログラムを本当に成功させるのであれば、Shadow ITアプリケーションの中でも、不要なアプリやリスクの高いアプリをブロックしたりリスク管理したりするなど、戦略的かつ統制のとれた手法が必要です。単にアプリケーションにブロックマークを付けたり、アプリケーションの既知のURLをプロキシやファイアウォールに1回だけインポートしてブロックするだけでは不十分です。  アプリがブロックされた状態を維持できるよう、アクションを継続的に監視する必要があります。  新しいURLも出てきます。CloudSOCに組み込まれている「Blocked@NWDevice」タグだけでなく、それ以上のものを使用することをお勧めします。また、アプリの定期的な制御レビューをスムーズに行えるように、日付とトラッキングチケットやその他の関連構造を持つ検証済みブロックタグを使用するのもよいでしょう。  

Shadow ITの問題を克服する

成熟した組織であれば、クラウドアプリケーションの正式な採用がGRC（ガバナンス、リスク、コンプライアンス）に関連した決定事項であることを理解しています。しかし、変化の激しい企業にとっては、問題はそれほど単純な話ではありません。  このような決定には、データに含まれるコンテキスト、アプリケーションのリスク、ビジネスパートナーの状況が大きく影響します。言い換えると、Shadow ITの一番の問題は、「0か100か（許可するかブロックするか）」で決定できるほど単純ではないということです。なぜならユーザーアクセス全体に影響が及ぶ決定になるからです。  最もリスクの高いアプリを除き、すべてのアプリに対する判定が求められます。判定はGRCに基づいて行われ、それを管理者が実装する必要があります。これらの判定に伴う摩擦の一番の原因はツールです。  従来のEndpointやSWG（Webフィルタリング）の手法は、多くの場合、URLごとの単純なブロックルールや許可ルールに依存します。  しかし、この手法は、すべてのテナントに対して同じURLを使用するマルチテナントクラウドアプリケーション向けのため、今日のクラウドアプリケーション中心の世界ではうまく機能しません。アプリケーションを意識した専用のクラウドアプリケーションプロキシーが存在しないため、管理者はGRCの認可を大幅に超えるアクセスルールを実装せざるを得ません。

妥協点はあります。「信頼せよ、されど検証せよ」です。  トラフィックは、必ず詳細に検証してください。許可されているものであっても、リスクが非常に高いからです。クラウドアプリケーションを許可するかどうかの判断は、検証でのコンテキスト認識のレベルに依存する必要があります。ユーザーは誰なのか、どのようなアプリやデータがあるのか、どのようにデータが共有されているのかなどです。クラウドセキュリティに特化したシマンテックの手法では、クラウドアプリケーションに存在する脅威（環境寄生型またはLotL）を排除することもできます。これらを含め多くのことが、考慮しなければならない決定要因となります。クラウドサービスのユーザーやデータ、脅威、アプリケーションアクティビティなどの項目が重要になります。  インライン機能は、これを管理するのに必要な機能です。この機能については、後のブログ記事で詳しく解説します。 

強力な監査プログラムを実装

CASB Auditが問題なく実装されると、GRCチームとAudit 管理者が配置され、両者がアプリの使用状況を日々監視できるようになります。大事なことは、ユーザーがアクセスするアプリケーションのカテゴリーをレビューするとき、「なぜ？」という疑問を持ちながら行うことです。  たとえば、なぜユーザーは会社のネットワークからVPNを利用するのか？  なぜ、会社で認可されていないリモートログインツールをエンドユーザーが使用しているのか？  なぜ、現在会社で正式に使用されていない重要サーバーからAWSバケット（またはAzure Blob）に5TBのアップロードがあったのか？  環境はそれぞれ異なり、特有の特徴や問題が見えてきます。  データのインポートや流出、および脅威の両方の観点からリスクを把握することは、重要なビジネス機能です。プログラムが成熟しても、この機能は定期的に実行し、継続的にレビューを行う必要があります。 その後の重要プロセスはすべてCASB Auditで始まり、監査プログラムが成熟するにつれて進化していきます。

新しいクラウドアプリケーションが見つかった時点で、次のフェーズに移行し、アプリケーションを正式に認可する（または差し替える）かどうか決定する必要があります。 企業としてアプリケーションを積極的に使用しているにもかかわらず、クラウドアプリケーションを正式に認可しておらず、リスクを低減するための強固な管理が行われていない過渡期の状態は、ビジネスにおいても監査プログラムにおいても混乱を招く状態になります。  新しいアプリでは、次の段階への要件をただちに入力する必要があります。これにより、導入状況、ポリシー、リスク管理がフォーマット化されます。 その上でSymantec CloudSOCを使用する場合、SecurletsとGateletsが不可欠となります。  これらについては、本シリーズの記事で追って解説します。

最終的な見解 

多くの場合、CASBの実装は、クラウドの導入を完全になくす目的でのみ使用する場合を除き、監査プログラムにのみ焦点を当てることはできません。  一般的なログ収集やCASBアプリケーション設定のヘルスチェックにより、GRCチームや管理者が、クラウド導入の管理ツールを管理できるようになります。  ビジネスニーズが可視性からきめ細かな制御へとシフトしている中、CASBソリューションの統合やアーキテクチャは、次のステップでますます重要になります。CASB Auditソリューションを最初から選択する場合は、すべての領域を考慮して、別のツールで最初からやり直す必要がないようにしてください。  選択するツールはシンプルなものから始め、組織のニーズの変化に合わせて進化させることができるものでなければなりません。  また、CASBは柔軟に拡張を行い、市場をリードする情報漏えい対策や脅威保護を展開して、クラウドの導入リスクを適切に管理する必要があります。

管理を強化するために、多くの組織が行う次のステップは、認可されたクラウドアプリケーションのAPIを活用することです。  CloudSOCの「Securlets」（Sanctioned Cloud Application TenantのAPI接続）については、本シリーズの次回ブログで詳しく解説します。