Advanced Analytics ベストプラクティス

Netskope Advanced Analyticsダッシュボードのパフォーマンスは、主に基となるクエリの効率性によって左右されます。ダッシュボード上の各ウィジェットはデータベースに対してクエリを実行し、これらのクエリの処理にかかる時間は全体のパフォーマンスに直接影響します。

最適なパフォーマンスを確保するためには、ダッシュボードやウィジェットを設計する際に、いくつかの要素を考慮することが不可欠です。このトピックでは、Netskope Advanced Analyticsで効率的なウィジェットとダッシュボードを作成するためのベストプラクティスについて概説します。

一般的なガイドライン

Netskope Advance Analytics を使用する前に、次の重要な点を考慮してください。これらの一般的なガイドラインとヒントは、効率的なダッシュボードの作成、実行、およびエクスポートに役立ちます。

各ダッシュボードについて

ウィジェットの数に厳密な制限はありませんが、ダッシュボードごとに15個未満のウィジェットを作成することを強くお勧めします。

ダッシュボード内の各ウィジェットについて

ピボットクエリまたはピボットされていないクエリ結果において、最大5000行、200列までをサポートします。
ブラウザのパフォーマンスを考慮すると、20列以下にすることをお勧めします。

エクスプローラ、ウィジェット、またはダッシュボードからトリガーされた各バックエンドクエリ（スケジュール済みレポートとスケジュール外レポートを含む）

データ処理時間については保証いたしかねます。要求するデータ量が多いほど、データ処理に時間がかかる場合があります。
RBAC制御、ユーザーグループ情報の検索、位置情報の検索、アプリケーション情報（CCI、CCLなど）といったデータエンリッチメントは、バックエンドクエリ処理時間の増加にもつながります。

生成されたレポートについて

11MBを超えるクエリ結果は、定期レポートまたはアドホックレポートの受信者に配信できません。電子メール配信の PDF の最大サイズは 11 MB までにしてください。
「すべての結果」オプションは、すべてのケースで利用できるとは限りません。たとえ利用可能であっても、ダウンロードまたはスケジュール設定を行う際は、すべての結果を含めて慎重に行ってください。クエリによっては、数千行、あるいは数百万行にも及ぶ非常に大規模なデータセットが生成されることがあり、これはほとんどの表計算ソフトの制限を超える可能性があります。

パフォーマンス向上のためのデータ量の最適化

分析に必要な最小限のフィールドから開始します。
クエリ結果のサイズを縮小するためにフィルターを適用します。
Netskopeの製品ポリシーを調整して、注意や監査が必要なイベントのみを記録するようにしてください。

ウィジェットには、粗密段階的な戦略を採用する

ウィジェットを設計する際は、まずデータの概要を示すために、上位レベルのフィールドから始めましょう。避ける URL、参照元、オブジェクト名などの過度に詳細なフィールドは、重要な洞察を覆い隠してしまう可能性があるため避けてください。

データを効果的にグループ化する

数値型およびタイムスタンプ型のフィールドについては、常にニーズを満たす最も粗い粒度を使用してください。例えば本当に必要な場合を除き、秒単位の精度ではなく、月次、週次、日次のタイムスタンプなどのタイムスタンプ型のフィールドを使用します。

テーブルビューの列数を制限する

テーブルビューウィジェットを作成する際は、ピボット列であろうと選択フィールドであろうと、列数を20未満に抑えることで、最適なパフォーマンスと使いやすさを確保できます。

データ拡充にはコストがかかる

ユーザーグループ、RBAC、または地理的位置情報に基づいてデータをフィルタリングすることでクエリ結果のサイズを削減できますが、そのような情報を取得して結合すると、データ処理に余分なオーバーヘッドが発生します。結果の統合、カスタムフィールド、テーブル計算などの高度な機能は、データ処理のオーバーヘッドを増加させる要因にもなります。能力向上へのニーズと業績に関する考慮事項とのバランスを取る。
Advanced Analytics 、生データエクスポーターではなく、分析ツールとして使用します。

高度な機能

結果の統合、カスタムフィールド、テーブル計算などの高度な機能は、より多くのバックエンドリソースを消費し、データ処理時間を大幅に増加させます。クエリ後の処理機能が増えるほどダッシュボードの読み込みに必要な時間も長くなります。

Strategies

このセクションは、すべてのダッシュボードおよび基となるウィジェットに適用されます。

データ量がパフォーマンスに最も大きな影響を与える

取得するデータ量は、データ処理時間に大きな影響を与える可能性があります。これには以下が含まれます。

フィールドを選択しすぎています
クエリ結果で過剰に多くのレコードを取得する
非常に大きなデータセットからレコード（フィルタリング済みまたは未フィルタリング）をクエリする

上記の問題を軽減し、パフォーマンスを向上させるために：

フィールドを慎重にSelect :
明確な単一のストーリーを伝えるために不可欠なフィールドを選択します。まず、分析目的を達成するために必要な最小限のフィールドのみを選択してください。
効果的なフィルター：
フィルターを適用してクエリ結果のサイズを制限し、一般ガイドラインのセクションで推奨されているしきい値と一致するようにしてください。さらに、検索を効率化するために、ダッシュボードにデフォルトのフィルタ値を設定することも検討してください。
Netskope製品ポリシーを慎重に調整する:
すべてのデータを無差別に記録するのではなく、注意や監査が必要なイベントに焦点を当てるようにNetskope製品ポリシーを構成します。

単一のダッシュボード内のウィジェットの数を制限する

ダッシュボード上の各ウィジェットは、基となるデータベース上でSQLクエリを実行しますが、その実行には時間がかかります。つまり、1つのダッシュボードにウィジェットが多すぎると、各ウィジェットのデータを完全に読み込むためにすべてのクエリを実行する必要があるため、全体の読み込み時間が長くなります。最適なパフォーマンスを得るためには、ダッシュボード上のウィジェットの数を15個未満に制限することをお勧めします。

テーブルビューウィジェットの列数を制限する

テーブルビューに列が多すぎるクエリ結果を生成するウィジェットは、バックエンドのデータ処理時間を増加させるだけでなく、ブラウザのパフォーマンスを低下させ、動作の遅延につながる可能性があります。さらに、20列を超える表形式のビューでは、詳細が多すぎるために重要な洞察が隠されてしまい、効果的な分析や解釈が難しくなる場合があります。実際、Advanced Analyticsでサポートされているほとんどの視覚化ウィジェットは、最大2列または3列までを効率的に処理できるように設計されています。パフォーマンスと使いやすさを向上させるには、列数を制限したり、データセットを複数のウィジェットやダッシュボードに分割したりすることを検討してください。さらに、データのピボットを行う際には注意が必要です。ピボットに不適切なフィールドを使用すると、列数が大幅に増加し、パフォーマンスに悪影響を与える可能性があります。

例１：DLPインシデント – 粗大な違反 vs. 微細な違反 – どちらがより良い状況を伝えるのか？

過去7日間のDLPインシデントイベントを調査していると想像してください。ユーザー、アラートの種類、アプリケーション、サイト、オブジェクト名などのフィールドを含むテーブルビューは、詳細なビューを提供します。しかし、未解決のインシデントの数、最も影響を受けているアプリケーション、最も多くのインシデントを引き起こしたポリシーなど、重要な質問に、包括的な単一の表で答えるのは難しい場合があります。これらの課題に対処するため、単一のテーブルビューに頼るのではなく、以下に示すように、必要最小限のフィールド数を持つ3つのウィジェットを作成するのがベストプラクティスです。

DLP Incidents by Status:

アラートタイプをDLPに設定してフィルタリングする
DLPインシデントステータスディメンションSelect
DLPインシデント数Select

DLP Incidents by Applications:

アラートタイプをDLPに設定してフィルタリングする
アプリケーションディメンションSelect
DLPインシデント数Select

DLP Incidents by Policies:

アラートタイプをDLPに設定してフィルタリングする
ポリシー名ディメンションのSelect
DLPインシデント数Select

上記の3つのウィジェットは、DLPインシデントステータス監視ダッシュボードのような組み込みダッシュボードを設計するためのアプローチを表しています。

以下のレポートは、フィールドが多すぎる単一のテーブルビューでは、すべての情報を一度に効果的に伝えることが難しいことを示しています。

以下の「ステータス別DLPインシデントレポート」は、現在も処理中のイベントの数を示しています。

以下の「アプリケーション別DLPインシデントレポート」は、どのアプリケーションが最も多くのDLPインシデントを引き起こしているかを示しています。

以下のポリシー別 DLP インシデントレポートは、どのポリシーが最も多くの DLP インシデントを引き起こすかを示しています。

例2：Netskope製品のうち、アプリケーションDLPインシデントを最も多く捕捉するものはどれか？ – データのピボット方法とは？

インシデントイベントのデータ収集では、アプリケーションフィールドをアクセス方法フィールドでピボットし、DLPインシデント数を測定することで、Netskope製品とアプリケーションDLPインシデントの分布を分析できます。ただし、アプリケーションごとにデータをピボットすることは推奨されません。組織によっては数十、あるいは数百もの固有のアプリケーションが存在する可能性があり、結果としてデータセットが過度に広範囲で扱いにくくなるためです。

アプリケーションを選択し、アクセス方法に基づいてピボットすることでDLPインシデントの数を測定すると、以下に示すように明確なビューが得られます。

アクセス方法を選択し、アプリケーションでピボットしてDLPインシデントの数を測定すると、解釈が難しい視覚化結果になる可能性があります。水平スクロールバーが異常に長くなっていることと、「列数の制限に達しました」という警告が表示されていることに注意してください。これは、データがシステムの表示容量を超えていることを示しています。

ウィジェットを作成する際に有効なフィールドを選択する

Advanced Analyticsでデータを分析する際には、最初に高レベルの情報を持つフィールドを選択するという、粗い情報から細かい情報へと段階的に分析を進める戦略を採用することが、実用的な洞察を得るための鍵となります。 URL、参照元、オブジェクト名など、情報が多すぎる断片的なフィールドに頼るのではなく、アプリケーション、イベントタイプ、アプリケーションカテゴリなどのフィールドに焦点を当てましょう。これらのフィールドは、データをより構造化され直感的に把握できるだけでなく、同種のデータをグループ化することでクエリ結果の数を大幅に削減します。この最適化により不要な処理が最小限に抑えられ、クエリのパフォーマンスが向上し、調査ワークフローがより効率的になります。上位レベルのフィールドを優先することで、記述的なフィールド値からグループ化された正確で包括的な結果が保証され、同時にシステム効率が向上します。

例3：クラウドアプリケーションの上位DLPアラートイベント URLまたはアプリケーション名？

アラートデータコレクションでよく使われるケースは、組織内で最も多くの DLP アラートイベントをトリガーするクラウドアプリケーションを分析することです。アラートイベントでは、URLフィールドとアプリケーションフィールドの両方に、ソースとなるクラウドアプリケーションに関する意味情報が含まれます。ただし、レポートの URL フィールドを使用すると、データが断片化されることがよくあります。これは、URL がロードバランシングの目的で使用される意味のない、ランダムに生成された ID またはホスト名で構成されていることが多いためです。イベントを効果的に分析するには、高レベルの情報を提供するフィールドを優先的に処理してください。このケースでは、URLではなくアプリケーションを選択することで、より明確で実用的な洞察が得られる可能性があります。

例えば、「アラート」データコレクションから以下のフィールドを選択して、クラウドアプリケーション関連のDLPイベントを監視します。

「アラート」フィールドグループから「アラートタイプ」フィールドを追加します。
「アプリケーション」フィールドグループから「アプリケーション」を追加します。
「アプリケーション」フィールドグループから「URL」を追加します。
「一般」フィールドグループから「トラフィックタイプ」を追加します。
「#アラート」測定

この例では、URLフィールドは個々のアラートイベントごとに変化するため、概要レベルの分析が複雑になり、クエリ結果のレコード数が増加する可能性があります。URLフィールドを除外することで、以下に示すように、より簡潔で意味のある結果セットを生成できます。なお、上記および下記の例では、適用されたフィルターとクエリ対象のソースデータセットは同じです。

例4：ユーザーごとのダウンロードバイト数上位 – ディメンションかメジャーか？

ネットワークイベントのデータ収集では、ダウンロードされたバイト数、アップロードされたバイト数、送信されたパケット数、受信されたパケット数など、ディメンションとメジャーの両方として存在するフィールドがあることに気づくかもしれません。

これら2種類のフィールドの主な違いは以下のとおりです。

Dimension: 個々のレコードの値を表します
Measure複数のレコードから計算された集計結果を表します。

例えば「ダウンロードされたバイト数」の場合、過去7日間のユーザーごとのダウンロードされた合計バイト数を監視する必要がある場合、「ダウンロードされたバイト数の合計」メジャーは、選択した期間に基づいて各ユーザーのデータを自動的に集計します。

必要に応じて、「アラート数」、「件数」、「ダウンロードされたバイト数」、「結果」などの測定フィールドをクリックすることで、個々の行をドリルダウンしてより詳細な分析を行うことができます。最初に適切なフィールドを選択することは、断片化された情報を減らすだけでなく、明確なデータ分析結果を提供する説得力のあるレポートを作成し、データ処理時間を最小限に抑えるためにも不可欠です。

データを効果的にグループ化する

場合によっては、数値型フィールドまたはタイムスタンプ型フィールドに基づいて分布やヒストグラムを観察する必要があるかもしれません。以下に、これらのタイプのフィールドを含むデータを分析するためのベストプラクティスをいくつか示します。

For numeric-type dimension:
生の値に基づいてデータをグループ化するのではなく、データを範囲で区切ったバケットに分割します。このアプローチは、より明確なパターンと傾向を示すことでデータ分析を強化し、解釈や洞察の抽出を容易にします。
For the timestamp-type dimension:
Advanced Analyticsでサポートされているほとんどのデータコレクションは、さまざまな粒度のイベントタイムスタンプを提供します。よくある使用ケースには、月次のユーザーアラート、週次のアプリケーション DLP インシデント、またはユーザーごとにダウンロードされた毎日のバイト数の監視が含まれます。データを効果的に分析するには、常にニーズを満たす最も粗いタイムスタンプから始めるべきです。秒単位の精度を持つタイムスタンプは、クエリ結果の行数を大幅に増加させ、クエリのパフォーマンスを低下させる可能性があります。

例5：CCL/CCIとアプリケーション番号の比較

アプリケーションイベントにおいて、 Netskope Cloud Confidence Index （ CCI ）は、クラウドアプリケーションのセキュリティ、監査可能性、および事業継続性を考慮して、クラウドアプリケーションのエンタープライズ対応度を評価するための指標です。各アプリには0～100のスコアが割り当てられ、そのスコアに基づいて5段階のクラウド信頼度レベル（CCL）のいずれかに分類されます。クラウドアプリケーションのリスクレベルをより深く理解するためにではヒストグラムまたは円グラフを作成できます CCLディメンションを使用して、以下のようにアプリケーション数を測定します。

場合によっては、 CCIより細かい範囲に分割することで、より詳細なビューが必要になることがあります。しかしながらCCIディメンションをアプリケーション数メジャーと直接組み合わせると、以下に示すように結果が断片化する可能性があります。

CCIディメンションを直接選択する代わりに、カスタムフィールドを使用してデータをビンごとにグループ化し、 CCIフィールドを範囲バケットに分類することで、より読みやすい結果が得られます。

例6：CCLによるアプリケーションイベントの日次トレンド

毎日の傾向を観察するためにタイムスタンプフィールドを組み込んで、上記の使うケースを拡張してみましょう。イベント日付フィールドを選択し、クラウド信頼度レベル（CCL）でピボットし、アラート数で測定することで、以下の情報を提供する積み上げ面グラフを作成できます。

アプリケーションイベントの1日あたりの処理量
各CCLのイベントの割合
過去14日間のデータ動向

積み上げ面グラフを用いることで、観察を簡素化し、信頼度の低い／低いアプリケーションイベントが時間とともに増加しているか減少しているかを解釈できる。こうした傾向を効果的に視覚化するには、データを意味のある形で集計する必要があることに気づいた。イベントタイムスタンプなどの不適切なタイムスタンプタイプのフィールドが CCLによってピボットされた集計結果は疎になり断片化され、グラフの分析が困難になります。

エリアチャートの横軸にイベント日付を設定：クエリ結果は効果的に日単位で集計・カウントされるため、過去14日間のデータの毎日の傾向を簡単に把握できます。

エリアチャートの横軸にイベントのタイムスタンプを使用すると、クエリ結果がまばらになり、断片化され、傾向を特定するための解釈が難しくなります。さらに、行数の制限に簡単に達してしまうため、過去14日間のデータを分析することが困難になります。

トランザクションイベント時間フィルタの動作

Advanced Analyticsプラットフォームは、データ範囲が重複しているにもかかわらず、過去 55 分間のデータを返しますが、過去 1 時間のデータは返しません。これはトランザクションイベントデータセットで発生します。時間フィルターの動作により、「過去55分間」のクエリはデータを返しますが、「過去1時間」のクエリはデータを返します。

「過去1時間」フィルターは、60分間の移動ウィンドウとは異なり、直前の完全な1時間（例：11:00～12:00）に切り詰められます。この時間フィルターのロジックは意図的な設計です。

対応ウェブブラウザ

Netskope最適なパフォーマンスと機能を実現するために、レベル1でサポートされているブラウザ（Chrome、Firefox、Edge、Safari）を推奨します。
Internet Explorer 11 (IE11) は、 Advanced Analyticsではサポートされなくなりました。最適なエクスペリエンスを得るには、Microsoft Edge またはレベル 1 でサポートされている他のブラウザへの移行をお勧めします。

権限

Advanced Analytics機能およびデータへのアクセスは、テナント管理者によって割り当てられた役割と権限によって制御されます。
ユーザーがレポートの表示、データの探索、コンテンツの作成、およびAdvanced Analytics内でのその他のアクションを実行するには、適切な権限が必要です。
ユーザー権限とコンテンツアクセス権限を理解し、適切に設定することは、安全で効率的なユーザーエクスペリエンスを確保するために不可欠です。
- たとえば、ユーザーがAdvanced Analyticsのデバイスクライアントデータコレクションにアクセスするには、テナント UI ページでデバイスを表示する権限が必要です。

データ処理（クライアント側およびバックエンド側）

一度に大量のデータを読み込むと、ハードウェアの制限によりブラウザの動作が遅くなったり、クラッシュ（メモリ不足エラー）したりする可能性があります。これには、（ただしこれらに限定されないが）多数の行を含む結果を生成すること、過剰な数の列を選択すること、または多数のカスタムフィールドを追加することなどが含まれる。このようなクラッシュ問題は、Advanced Analyticsのサポート範囲外です。

Google Chromeで「Aw, Snap!」などのエラーメッセージが表示された場合は、まずクライアント側の問題を特定するために、「Chromeでの接続エラーと読み込みエラーを修正する」を参照してください。