パート1となる最初のブログでは目標の設定について解説しました。今回は、CASB Auditの結果全体に影響する重要な考慮事項やよくあるミスについて解説します。  組織でシャドーITを検出したり、リスクを評価したり、全体的な健全性を評価したりできるようになるうえで、CASB Auditは不可欠です。 

CASB Auditの実施にあたり、よくあるミスで最も多いのが、不完全なデータです。情報システムとは、ごみを入れればごみしか出てこないものです。システムがデータの漏れが無いように、正しくプラミング（配管）されていることを確認することが極めて重要です。期待される結果に到達するまでに、無関係な情報や不完全な情報が結果的に大きな妨げ要因の1つになっていたことが後に判明することは少なくありません。特定の重要なコンテキストが不足していたために、データが役に立たなくなることもよくあります。  不要なデータがあるとリスクが見えなくなる傾向があり、後に実施する監査で修正作業が発生し、コストがかかってしまう可能性があります。

可視性と制御－ログ

すべての使用可能なログのソースからあらゆる関連のトラフィックログがCASB Auditに入力されるようにすることが非常に重要です。

CloudSOCへトラフィックログを送信する場合、Symantec CloudSOCでは複数の方法をサポートしています。たとえば、複数のクラウド間での送信、オンプレミスデバイスからクラウドへの直接送信、オンプレミスデバイスからSymantec CloudSOCアプライアンスを経由したクラウドオプションへの送信などがあります。Symantec CloudSOCでは、SpanVA仮想アプライアンスを無料で提供し、オンプレミスデバイスからオンプレミスアプライアンスへのシナリオに対応します。

SpanVAでは、オンプレミスの仮想アプライアンスアーキテクチャを使用して、ネットワークデバイスやプロキシからファイアウォールやプロキシのログを収集およびフィルタリングし、それらをCloudSOC CASBに送信します。その後、監査アプリケーションと併用して、シャドーITなどのリスクを評価します。 

あらゆる資産、ビジネスユーザーを表すWebトラフィック、ファイアウォールログ、プロキシログなどを含むすべてのログが必要です。これらのトラフィックログは、少なくともユーザー、ソースIP、宛先IP、宛先URL、アップロードバイト、ダウンロードバイト数、参照URL、許可またはブロックのステータスで構成されている必要があります。

ログにコンテナやサーバー群からのトラフィックが含まれていることことを必ず確認してください。また、重要な情報がシステムやアプリケーションから不正なクラウドアプリにエクスポートされないように注意してください。組織に可視性や制御力がないと、手遅れの状態になるまで誰も気付くことができないでしょう。

ブロックのステータスも同様に重要です。ブロックされたトラフィックをレビューすることで重要なインサイトが得られるからです。たとえば、アクセスの試行は、不正な振る舞いを示す可能性があります。正式には2週間前に通知するところを、デジタルで3週間前に通知するユーザーなどがその例として挙げられます。 

プライバシーへのアプローチ－Tokenization（トークン化）とAnonymization（匿名化）

特定のプライバシー要件を有する組織では、実際のユーザー名やIPアドレスをトークン化する「Tokenization」を使用するかどうかを慎重に検討する必要があります。   

SpanVAは、Auditの「Tokenization」もサポートしています。この機能について、詳細はこちらを参照してください。 

APIベースのポリシーの実施（Securlets）やインラインでの実施（Gatelets）などのCASB機能を使用する場合、CASBは実際のユーザー情報を可視化するため、トークン化は適していません。    

さらに、トークン化されたShadow IT Auditが導入されている場合、データをトークン化したアプライアンスが使用できなくなると、データの難読化を解除できなくなります！これは「Anonymization」の場合とは異なります。

その代わりとして、組織で検討が必要になる別の機能が「Anonymization」です。Anonymizationでは、組織がロールベースアクセス制御（RBAC）を使用して、CASBデータ保護責任者（DPO）ユーザーなどの管理者が実際のユーザー/IP情報を確認できるようにする必要があるかどうかや、「anon-1111」のようにマスクされた表示を確認する必要があるかどうかを決定できます。これにより、組織はRBACを使用して、必要なときにユーザー識別情報を利用できるようにすることができます。また、CASB Auditへのアクセスだけでなく、他の多くのCASB管理関連タスクも大幅に簡素化され、全体的な導入リスクが軽減されます。

もう1つの重要な要素は、ゲストネットワークトラフィックをログのソースに含めるか除外するかです。SpanVAでは、ログの処理時に包含フィルタと除外フィルタの両方を適用でき、管理者は同じログを異なるデータソースに送信して、異なる用途のレポートを作成することができます。

例：  

• 可視性とリスクを目的とした、ゲストネットワークのログのみを含む1つのデータソース。
• ゲストネットワークのログを除外した1つのデータソース。

これにより、特定のアプリのトラフィック元に関する混乱や論争を防ぐことができます。また、レポートのユースケースに基づいて、適切な監査データソースを選択（複数可）することができます。

CASB Auditにデータを取り込む主な方法は2つ

1－CloudSOCで直接、IPロケーションと監査データソースを設定。  これにより、事前定義されたIPソースアドレスのロケーションから、SCP/SFTP経由でCloudSOCの監査データソースへ直接アップロードできるようになります。

2－CloudSOCでSpanVA 監査アプライアンスを設定、およびSpanVA 監査データソースを設定。これにより、ネットワークファイアウォールルールで許可されているロケーションから、SCP/SFTP経由でSpanVAへアップロードできるようになります。他にも、SpanVAはSyslogやFTPなどの一般的な形式や、ファイアウォールベンダー独自の形式も受信できます。

重要！  直接のアップロードを使用するか、SpanVAデータソースを使用するかの最初の判断ポイントは、ログの送信元となるソースIPアドレスが静的で予測可能かどうか、またはより動的かどうかです。  

• CloudSOCのSFTPおよびSCPサービスでは、CloudSOCポータルに登録されているロケーションからのアップロードのみが許可されています。どのIPからでもアップロードできるわけではありません。   
• 組織のファイアウォールポリシーで、必要なSpanVAへのアクセスが許可されている場合、SpanVAは動的アドレスからのログのアップロードを許可することができます。

考慮すべきことは確かに多いでしょう。しかし、それは、クラウド環境内に存在するデータを完全に把握することが重要だからです。これを実現するには、CASB AuditとSpanVAが不可欠です。それでも、リスクはまだ存在します。これについては、次のブログで解説します。