SaaS

NetskopeのログをMicrosoft Sentinelに取り込む — 新コネクタ「Netskope Alerts and Events」接続手順

Shinsuke Murota
Shinsuke Murota

はじめに

こんにちは、セキュリティチームのむろです。

今回はNetskopeの各種ログ（AlertやSkopeITのEvents）をMicrosoft Sentinelに取り込む方法をご紹介します。

なお、古い「Netskope (using Azure Functions)」コネクタを利用中の場合は本記事の新しいコネクタに切り替える方がメリットがあります。

若干の車輪の再発明感はありますが、実際に試してみたことによる、気づきもあるのでブログで紹介します。

前半で前提知識を整理し、後半で実際の接続手順を解説していきます。

最初にまとめ

  • 古い「Netskope (using Azure Functions)」コネクタはすでに非推奨となっている
  • NetskopeとSentinel連携のコネクタは大きく3種類あり、まず接続を最初に試すなら「Netskope Alerts and Events」コネクタがおすすめ
    • 大規模な組織の場合やTransaction Eventsを取り込む場合は有償アドオンのLog Streaming方式の選択肢がある
  • Sentinelの費用はLog Analyticsへの取り込み量が大部分を占めるため、どのログ種別を取り込むかを先に設計することが重要
  • 長期保管の形式も3種類あり、再利用性が低い単純な長期保管は「アーカイブ」がおすすめ

本記事の接続手順の前提

  • サブスクリプションは既存のものを利用する
  • 新規でリソースグループを作成する
  • 新規でSentinelのワークスペースを作成する
  • 利用するコネクタは「Netskope Alerts and Events」（APIプル方式）
  • インタラクティブ保持期間は「90日」（既定・無償枠内）
  • 長期保管の方式は「アーカイブ」、保存期間は「1年」（91日以降をアーカイブに配置）
  • 接続対象のログ（テーブル名）は以下
    • Alert全種別（NetskopeAlerts_CL）
    • Application Events（NetskopeEventsApplication_CL）
    • Audit Events（NetskopeEventsAudit_CL）
    • Network Events（NetskopeEventsNetwork_CL）
    • Page Events（NetskopeEventsPage_CL）

前置きを飛ばして手順を見たい方は「実際の接続手順」へ飛んでください！

本記事で対象とできるログ種別

  • SkopeITのApplication Events／Page Events／Network Events、Alert、管理操作のAudit Eventsなどが対象にできます
  • Transaction Events（Web Transactions）は有償アドオンが必要なため、本記事では対象外とします

NetskopeのログをSentinelに取り込むとどんな良いことがある？

分析の再現性や柔軟性が上がる

  • NetskopeのAlertチューニングを進める際、SkopeITの標準UIフィルタやAdvanced Analytics だけでは同じ条件での反復分析がしづらい場面があります
  • Sentinel（Log Analytics）に取り込めば、KQLで再現性のあるクエリベースの分析・集計ができるようになります
  • クエリベースであるため、条件の組み方の柔軟性が向上します

分析ルール（Analytics Rules）で複雑な検知を組める

  • Netskope単体のアラートは基本的に「1イベント＝1検知」ですが、Sentinelの分析ルールならKQLで表現できるものは何でも検知条件にできます
    • 例：Real-Time Protectionポリシーが変更されたことを検知して通知する
    • 例：特定のユーザーが管理コンソールへログインしたら通知する
    • 例：「同一ユーザーでDLP Alertが1時間に一定件数以上」といったしきい値型、「未許可アプリへのアップロードの後に大量ダウンロード」といった複数イベントの組み合わせ（相関）型の検知が作れます
  • Entra IDのサインインログやDefender系など他のログソースとの横断相関も同じワークスペース上で書けるため、「不審なサインインの直後に大量のデータ持ち出し」のような、単一製品では見えない一連の流れを検知・調査できます

インシデント対応の自動化（SOAR）につなげられる

  • 分析ルールの検知結果はインシデントとして起票され、オートメーションルールやプレイブック（Logic Apps）と組み合わせて、Teams/Slackへの通知、チケット起票、担当者の自動アサインといった対応フローを自動化できます
  • 検知→通知→対応記録までをSentinelのインシデント管理に集約できるため、対応漏れや属人化の防止にもつながります

可視化・定点観測がしやすい

  • Workbooksでダッシュボード化すれば、アプリ利用状況やAlert傾向の定点観測・報告にそのまま使えます

ガバナンス（保持・権限）をログ種別単位で設計できる

  • 種別ごとにテーブルが分かれるため、保持期間や参照権限（RBAC）をログ種別単位で作り分けられるのも利点です
  • 監査要件のあるログだけ長期保管する、機微度の高いテーブルだけ参照者を絞る、といった作り分けがテーブル単位の設定だけで実現できます

コネクタの種類の解説

NetskopeのログをSentinelへ届ける経路は、大きく以下の3種類があります。

1. APIプル方式

  • Sentinel上のコネクタ名は「Netskope Alerts and Events」
  • Sentinel側のCodeless Connector Framework（CCF／CCP）がNetskopeのREST API v2（dataexportエンドポイント）を直接プルする方式です
  • 接続に必要なのはAPIトークンとテナントURLのみで、Blob Storageなどの中継インフラは不要です
  • 基盤はMicrosoft管理のため、障害時に自分たちが面倒を見る範囲が小さく済みます
  • ログ種別ごとにテーブルが分割される（Alerts／Application／Page／Network／Audit／DLPなど最大9テーブル）ため、テーブル単位で取り込みのON/OFFや保持期間・RBACの統制がしやすいです
  • dataexportはiterator方式（サーバー側が「どこまで読んだか」を覚えている）のため、一時的な障害やトークン期限切れが起きても再開時に続きから自動取得され、取りこぼしが起きにくい仕組みです
  • 本記事の手順はこの方式を採用しています

2. Log Streaming（Blob Storage経由）方式

  • Sentinel上のコネクタ名は「Netskope Alerts & Events Connector (via Blob Storage)」（Web Transactions用は「Netskope Web Transaction Connector (via Blob Storage)」）
  • NetskopeテナントのLog Streaming機能で自社のAzure Blob Storageへログを書き出し、SentinelがCCFコネクタ（Netskope Alerts & Events Connector (via Blob Storage)）でBlobから取り込む方式です
  • なお、Log Streaming機能の利用には追加ライセンス（アドオン）が必要です。採用を検討する場合は、事前にNetskopeの担当営業（アカウントチーム）への確認・有効化依頼が必要です
  • 自社のAzureインフラ（Blob Storageに加え、Blob作成通知用のEvent GridやStorage Queue等）の構築・保守が必要になる分、運用負荷は増えます
  • 取り込み先は単一テーブル（NetskopeAlertEvents_CL）となり、方式1のようなログ種別ごとのテーブル分割（9テーブル）にはならない点は把握しておきましょう
  • 制約として、ログを受けるBlob Storageアカウントにはネットワークアクセス制限をかけられない点にも注意が必要です
  • このAlerts & Events版のBlobコネクタは執筆時点ではContent Hubに掲載されておらず、GitHubで配布されているARMテンプレートを「カスタムテンプレートのデプロイ」から手動デプロイする必要があります
  • 一方で自社側にバッファを持てるため、長時間障害への耐性が高く、大量ログの取り込みにも向いています。Web Transactionsについては同じ経路の専用ソリューション「Netskope Web Transaction Events」（コネクタ名：Netskope Web Transaction Connector (via Blob Storage)）がContent Hubで公開されています
  • なお、名前が紛らわしい「Netskope Web Transactions Data Connector」（本記事で使うソリューションに同梱されている、Google Pub/Sub LiteからDockerコンテナでプルする旧方式）は、基盤であるGoogle Pub/Sub Liteのサービス終了に伴いすでにEOLとなっているため、選ばないようにしましょう
  • 大規模環境や欠損を絶対に許容できない要件がある場合の選択肢です

3. Cloud Exchange（CE）のLog Shipperプラグイン利用

  • Netskope Cloud Exchangeという中継基盤を立て、Log Shipperプラグインで各種SIEMへログを転送する方式です
  • CEは自前で用意したサーバー（Linux＋Docker環境）にデプロイして運用する製品であり、VMの確保・OSパッチ適用・死活監視といったサーバーとしてのインフラ運用が発生します（なお、Netskopeが構築・運用を代行するマネージド提供もあります）
  • CE本体のバージョン単位のEOLサイクルも比較的短いため、継続的なバージョンアップ作業も見込む必要があります
  • Sentinel以外の複数の宛先へ同時配信したい場合などに有効ですが、中継基盤そのものの運用が増えるため、Sentinel単体連携には機能過剰になりがちです

コネクタ比較表

観点APIプルLog Streaming（Blob経由）CE Log Shipper
Sentinel上のコネクタ名「Netskope Alerts and Events」「Netskope Alerts & Events Connector (via Blob Storage)」、「Netskope Web Transaction Connector (via Blob Storage)」なし
（CEがログを直接プッシュするため、Sentinel側に専用コネクタは不要）
向いているケースAlert／SkopeIT Eventsの取り込みが目的の場合の標準の選択肢
（追加ライセンス・追加インフラ不要で最小の運用負荷）		Transaction Events（Web Transactions）を取り込みたい場合や、大規模環境で欠損を許容できない要件がある場合Sentinel以外を含む複数の宛先へ同時配信したい場合
（すでにCEを他のプラグイン用途で運用しているなら有力）
取り込み経路SentinelがREST API v2を直接プル自社Azure Storage経由Cloud Exchange中継
利用API（取得の仕組み）REST API v2
（dataexport）		API不使用（Log Streamingがファイルをプッシュ配信。レート制限の影響なし）REST API v2
（dataexport）
Netskope側の追加ライセンス不要必要
（Log Streamingアドオン）		不要
Azure側の追加インフラ不要必要
（Blob Storage＋Event Grid／Queue）		不要
サーバー環境（自前サーバーの要否）不要不要
（Storage関連リソースのみ）		必要
（Linux＋DockerのCEサーバー）
基盤運用不要
（Microsoft管理の基盤）		必要
（Blob Storage／Event Grid等の自社リソースを保守）		必要
（CEサーバーを自前で運用）
取り込み停止時の欠損耐性Netskope側のiterator保持期間に依存自社バッファで回避しやすいNetskope側のiterator保持期間に依存
＋CEの構成に依存

本記事では、最小構成で始めやすい「Netskope Alerts and Events」コネクタを使った手順を解説します。

補足：非推奨のコネクタ

Content Hubのソリューションをインストールすると、Data Connectors一覧には推奨コネクタ以外に以下の旧方式コネクタも表示されます。

いずれも新規に接続する理由はないため、「未接続（Disconnected）」のままで問題ありません。

「Netskope Data Connector」

  • 本記事で使うソリューションに同梱されている、Azure Functionsベースの旧方式コネクタです（自社サブスクリプションにFunction Appをデプロイし、NetskopeのAPIをプルする構成）
  • 推奨しない理由：同じソリューション内に後継の「Netskope Alerts and Events」（CCF方式）があり、同等のログを追加インフラなしで取り込めるため、Function Appの構築・保守・実行費用をかける意味がないためです

「Netskope Web Transactions Data Connector」

  • 同じく本記事で使うソリューションに同梱されている、Transaction Events（Web Transactions）をGoogle Pub/Sub LiteからDockerコンテナでプルする旧方式コネクタです
  • 推奨しない理由：基盤であるGoogle Pub/Sub Liteのサービス終了に伴いすでにEOLとなっており、継続利用できないためです。Web Transactionsを取り込みたい場合は、方式2で紹介した「Netskope Web Transaction Connector (via Blob Storage)」を利用します

「Netskope (using Azure Functions)」

  • 「Netskope Data Connector」の旧名称です
  • 新しいコンテンツハブ内にはすでに含まれていません
  • 過去にNetskopeとSentinelを接続している環境はこのコネクタを利用している可能性があります
  • 推奨しない理由：同じソリューション内に後継の「Netskope Alerts and Events」（CCF方式）があり、同等のログを追加インフラなしで取り込めるため、Function Appの構築・保守・実行費用をかける意味がないためです

長期保管方法の比較（90日を超えて保存したい場合）

Sentinel（Log Analytics）のAnalyticsテーブルは、既定で90日間のインタラクティブ保存が無償で含まれます。

それを超えて保管したい場合、91日以降の置き場所には大きく3つの選択肢があります。

1. アーカイブ保管

  • 91日以降のデータを低コストなアーカイブ（長期保存）に自動で移す方式です
  • ストレージ単価は3方式で最安（約$0.02/GB/月）で、置いておくだけなら費用は保存量に比例するだけです
  • ただしアーカイブ上のデータは通常のKQLでは直接参照できず、参照するには検索ジョブ（Search Job）または復元（Restore）という非同期の操作と都度課金が必要です
  • 「監査要件などで保管は必要だが、古いデータを参照するのは稀」という典型的な長期保管用途に向いています
  • 本記事の手順はこの方式を採用しています

2. インタラクティブ延長

  • 90日の無償枠を超えて、全期間をインタラクティブ保存のまま延長する方式です
  • 保存期間内はいつでも通常のKQLで即時にクエリでき、クエリ自体は何度実行しても無料です。検知ルール（Analytics Rules）の対象にもできます
  • その代わりストレージ単価は最も高く（約$0.10/GB/月）、保存量が増えるほど固定費が積み上がります
  • 「古いデータも日常的にヘビーに分析する」場合に向いています

3. データレイクtier

  • 長期データのコピーをSentinelデータレイクtierに保持する新しい方式です
  • ストレージ単価はアーカイブ並みに安く（約$0.026/GB/月）、復元のような事前操作なしにデータレイク探索のKQLで分析できます
  • ただしクエリやジョブの処理量に応じた都度課金があり、広範囲のスキャンを繰り返すと費用が積み上がる点に注意が必要です
  • 検知ルールへの適用は原則できず、定期的・範囲限定の履歴分析（生成AIによる分析など）向けの位置づけです
  • 2025年9月にGA（一般提供）となった比較的新しい機能のため、採用時は提供リージョン・料金の実確認が必要です

長期保管方法の比較表

観点アーカイブインタラクティブ延長データレイクtier
向いているケース古いデータの参照が稀な長期保管
（監査要件などで保管は必要だが参照は稀）		全履歴を常時ヘビーに分析する場合
（クエリ無料・即時の価値が大きい）		定期的・範囲限定で履歴分析する場合
（生成AIによる履歴分析など）
古いデータのクエリ手段検索ジョブ／復元（非同期・要操作）通常のKQLで即時データレイク探索KQL
クエリ課金モデルスキャン課金
（都度）		無料
（回数無制限）		処理量課金
（都度）
KQL機能の範囲限定（復元すればフル）フルKQLフルKQL
検知ルール／アラート適用不可
（要復元）		可不可
（分析・探索向け）
長期ストレージ単価最安
（約$0.02/GB/月）		高い
（約$0.10/GB/月）		安い
（約$0.026/GB/月）
取り出し時（復元・検索）のコスト検索ジョブ＝スキャン量課金
復元＝約$0.10/GB/日（最低2TB・12時間分から）		なし（取り出し操作自体が不要）復元操作は不要（クエリの処理量課金のみ）
意図しない課金のリスク復元の閉じ忘れと_SRCHテーブルの消し忘れ（操作しない限り費用は発生しない）保存量に比例する固定的な費用で予測しやすい
（ただし、ベースの費用は最も高額）		クエリ・ジョブの処理量課金が積み上がりやすく、広範囲スキャンで高額課金になった事例もある
成熟度枯れている枯れている新しい
（2025年9月GA・運用実績はまだ浅い）

本記事では、最も安価でシンプルな「90日無償＋91日以降アーカイブ」の構成を前提に手順を解説します。

具体的な設定手順は後半の「アーカイブを設定する（90日を超えて保管する場合）」を参照してください。

実際の接続手順

Phase 1：Azure側の準備

Step 1. 専用リソースグループを作成する

  • 既存サブスクリプション内にNetskope連携専用のリソースグループを作成します（例：rg-sentinel-netskope-prod）
  • 専用リソースグループに分けておくことで、リソースの管理やコストの把握がしやすくなります

Step 2. Log Analyticsワークスペースを作成する

  • 作成したリソースグループ内にLog Analyticsワークスペースを作成します（例：law-sentinel-netskope-prod）
  • リージョンはお好みのリージョンを選択してください
    （例：Japan East）

Step 3. Microsoft Sentinelを有効化する

  • Azure Portalで「Microsoft Sentinel」→「作成」→作成したワークスペースを選択して有効化します
  • 有効化後、Content HubやData Connectorsのメニューが利用可能になります

Phase 2：Netskope側の準備

Step 4. テナント情報の確認

  • テナントURLから接続先のFQDNを控えます
    （例：<tenant>.goskope.com）

Step 5. ロールを作成する

  • APIトークンは Settings > Administration > Administrators & Roles から、「ロールの作成」→「サービスアカウントの作成」→「トークンの発行」の流れで発行します
  • RBACv3では権限（スコープ）をトークンではなくロール側に定義するため、まず取得対象のログに対する参照（View）権限のみを持つカスタムロールを作成します
  • ロールの権限（Function）設定では、まずすべてのFunctionを「なし（None）」に設定し、余計な権限が付かない状態にします
  • そのうえで、取得対象のログに対応する以下のFunctionだけを「View」に変更します
    • Infrastructure：Infrastructure Log
    • Skope IT：Alerts／Application Events／Endpoint Events／Network Events／Page Events
    • Administration：Audit Log
    • DLP：Incidents
  • 設定後は、権限一覧のフィルタで「View」を指定して絞り込み、意図したFunctionだけがViewになっていることを確認します
  • なお、保存時に以下の追加の権限が必要な旨のメッセージが表示されるので、「同意して保存」を選択します

Step 6. サービスアカウントを作成し、トークンを発行する

  • 作成したロールを割り当てたサービスアカウントを作成します
  • サービスアカウントはWeb UIにログインできないAPI専用のアカウントのため、管理者アカウントのトークンを流用するより安全です
  • サービスアカウントに対してAPIトークンを発行します。有効期限（日数）を設定し、「Create」を選択します
  • 発行されたトークンは「Copy Token」を選択して控えます。トークン値は発行時に一度しか表示されないため、必ず安全な場所に保管しましょう
  • 発行したトークンには有効期限があるため、有効期限と更新運用（誰がいつ更新するか）を必ず記録しておきましょう。期限切れは取り込み停止の代表的な原因です

Step 7. APIの疎通を確認する

  • PostmanやPowerShellでAPIの疎通を事前に確認しておくと、コネクタ設定時のトラブルシュートが楽になります
powershell
Invoke-RestMethod `
  -Uri "https://<tenant>.goskope.com/api/v2/events/dataexport/events/application?index=connectivity-test-20260708&operation=next" `
  -Headers @{ "Netskope-Api-Token" = "<APIトークン>" }
  • indexには任意のiterator名を指定できます。実行するとNetskope側にその名前の実iteratorが作られて読み取り位置が記録されるため、疎通確認では本番コネクタと被らない使い捨ての名前（用途＋日付など）を指定しましょう
  • 同じ名前を再利用すると2回目以降は「続きから」の取得になり、直近ログがないと空レスポンスが返って「疎通できていない？」と誤解する原因になります

Phase 3：Sentinelコネクタの導入

Step 8. Content HubからNetskopeソリューションをインストールする

  • Sentinelの Content Hub で「Netskope」を検索し、「Netskope Alerts and Events」を含むソリューション（Netskope Data Connector）をインストールします
  • 検索結果には似た名前のソリューション（旧Azure Functions方式やBlob Storage経由方式）が並ぶため、インストール対象を間違えないよう注意してください

Step 9. コネクタを設定する

  • Data Connectors から「Netskope Alerts and Events」を開き、以下を入力して接続します
    • テナントURL（Organisation Url）
    • APIトークン
    • 取り込むログ種別の選択
    • Index（iterator名。本記事では明示指定を推奨）
  • ログ種別はテーブル単位で選択できます。費用は取り込み量に支配されるため、目的に必要な種別だけをONにするのがコスト管理の要です
  • 例として、Alertチューニングと利用状況分析が目的の場合の、コネクタ設定画面の各項目・設定値・取り込み先テーブルのマッピングは以下のとおりです
コネクタ画面の設定項目設定値対象テーブル主な用途・補足
Organisation Url<tenant>.goskope.com—ホスト名のみを入力し、https://は付けない。コネクタが内部でhttps://を自動付与するため
API KeyStep 6で発行したAPIトークン—RBACv3方式のサービスアカウントのトークン
Netskope Alerts ◯◯（Remediation／Uba／Security Assessment／Quarantine／Policy／Malware／Malsite／DLP／CTEP／Watchlist／Compromised Credentials／Content／Deviceの全13項目）YesNetskopeAlerts_CLAlert分析・チューニングの主データ。Alert系は種別を問わず単一テーブルに入る。未使用機能の種別はそもそもデータが発生せず費用も増えないため、一括Yesで問題ない
Netskope Events ApplicationYesNetskopeEventsApplication_CLクラウド/Webアプリ上のユーザー操作の分析
Netskope Events AuditYesNetskopeEventsAudit_CL管理コンソール操作の監査
Netskope Events ConnectionNoNetskopeEventsConnection_CLNetworkイベントで分析が完結するなら不要
Netskope Events DLPNoNetskopeEventsDLP_CLDLPポリシー未構成なら発生しない
Netskope Events EndpointNoNetskopeEventsEndpoint_CLEndpoint DLPライセンスがなければ発生しない
Netskope Events InfrastructureNoNetskopeEventsInfrastructure_CLオンプレアプライアンス未構成なら発生しない
Netskope Events NetworkYesNetskopeEventsNetwork_CLNPA／Cloud Firewall通信の分析
Netskope Events PageYesNetskopeEventsPage_CLWebアクセス傾向・カテゴリ別トラフィックの分析
Index（OPTIONAL）宛先ワークスペース名ベースの一意な名前を指定する（例：sentinel-law-sentinel-netskope-prod）—OPTIONAL扱いだが明示指定を推奨。指定した値はAPIトークン台帳に併記し、再設定時は必ず同じ値を使う
  • Events系はテーブル単位で取り込み量＝費用に直結するため、Alerts系と違って「とりあえずYes」にせず、目的に必要な種別だけをONにします

Step 10. 接続テストとログ流入を確認する

  • 接続成功後、数十分〜1時間程度でログの流入が始まります
  • 以下のようなKQLで到達を確認します
javascript
search *
| where TimeGenerated > ago(1h)
  • データの流入が開始するとコネクタ画面上でも対象のテーブルのアイコンが緑になります

Phase 4：データ確認

Step 11. テーブルと中身を確認する

  • Logs画面でNetskope系テーブルが作成されていることを確認します
javascript
union Netskope*_CL
| summarize count() by Type, bin(TimeGenerated, 1d)
  • なお、NetskopeEventsAudit_CLは管理コンソールの操作ログのため、特性上ほかのテーブルよりデータが流れ始めるのが遅くなります
  • すぐに流入を確認したい場合は、管理コンソールへのログインやログアウトを行って、Audit Eventsを意図的に発生させるのがおすすめです

Step 12. 取り込み量を実測する

  • 費用見積りの答え合わせとして、テーブル別・日別の取り込み量を実測しておきます
javascript
Usage
| where TimeGenerated > ago(14d)
| where DataType startswith "Netskope"
| summarize IngestedGB = sum(Quantity) / 1024 by DataType, bin(TimeGenerated, 1d)
| order by TimeGenerated asc
実測結果をエクスポートして、月額試算は生成AIに任せる
  • KQLの結果はCSVにエクスポートできます。上記のUsageクエリの結果をそのまま生成AIに渡せば、月額換算の面倒な計算（曜日変動の補正や月間換算）を任せられます
  • エクスポート手順は以下のとおりです
    1. 上記のUsageクエリを実行する
    2. 画面右上の「共有」→「エクスポート 宛先 CSV (すべての列)」を選択する（環境によっては結果グリッド上部に「エクスポート」ボタンが表示される場合もあります）
    3. ダウンロードしたCSVを生成AIに添付し、以下のようなプロンプトで試算を依頼する
      markdown
      添付のCSVは、Microsoft Sentinel（Log Analytics）のUsageテーブルを
テーブル別・日別に集計した取り込み量です（IngestedGB列の単位はGB）。
以下の条件で月額費用を試算してください。
・接続初日は1日分に満たないデータのため、集計から除外する
・平日と休日でログ量が大きく変わる前提で、それぞれの1日あたり平均を分けて算出する
・「平日22日＋休日8日」として月間の合計取り込み量（GB）を算出する
・単価は $4.4/GB（PAYG・Japan East目安。最新の実単価に要差し替え）とし、
　月額をUSDと日本円（1USD=150円）で示す
・テーブル別の内訳も表で示し、取り込みをやめた場合の削減額が大きい順に並べる
  • 単純な「1日分×30」の掛け算は、接続初日の部分データや曜日変動で大きくズレます。数日〜2週間分たまったCSVを渡すほど試算の精度が上がります
  • Usageテーブルはテーブル名とデータ量だけの集計情報のため、ログの中身（機微情報）を生成AIに渡さずに試算できるのも利点です

アーカイブを設定する（90日を超えて保管する場合）

  • 前半の「長期保管方法の比較」のとおり、本記事では91日以降をアーカイブに置く構成とします
  • 保持期間はテーブル単位で設定できます。「インタラクティブ保持期間＝90日／合計保持期間＝365日」と設定すると、91日以降のデータが自動的にアーカイブへ移ります（コネクタ接続後、対象テーブルが作成されてから設定します）
  1. Azure Portalで対象のLog Analyticsワークスペースを開く
  2. 左メニューの「設定」→「テーブル」を選択
  3. 対象のNetskope系テーブル（NetskopeAlerts_CL 等）の右端の「…」から「テーブルの管理」を選択
  4. 「インタラクティブ保持期間」は90日（既定）のまま、「合計保持期間」を365日など必要な期間に変更して保存
  • 対象テーブルが多い場合はAzure CLIで設定することもできます
powershell
az monitor log-analytics workspace table update `
  --resource-group rg-sentinel-netskope-prod `
  --workspace-name law-sentinel-netskope-prod `
  --name NetskopeAlerts_CL `
  --retention-time 90 `
  --total-retention-time 365

おまけ：アーカイブからデータを取り出して使う

  • アーカイブに移ったデータは通常のKQLで直接参照できないため、参照したくなったときの取り出し方をあらかじめ把握しておきましょう。方法は検索ジョブ（Search Job）と復元（Restore）の2つです

方法1：検索ジョブ（Search Job）— 範囲を絞ったスポット調査向け

  • アーカイブを含む合計保持期間内のデータを非同期で検索し、結果を新しいテーブルとしてワークスペースに取り込む機能です
  • 手順は以下のとおりです
    1. Log Analyticsワークスペースの「ログ」画面で、取り出したい条件のKQLを書く（対象テーブルと条件で範囲をできるだけ絞るのがコツ）
    2. 「実行」ボタンのプルダウンから「検索ジョブとして実行」を選択（または画面右側の「…」→「検索ジョブ」）
    3. 時間の選択で対象期間（合計保持期間内の任意の範囲）を指定する
    4. 結果テーブル名を入力して実行する。完了すると<指定名>_SRCHという名前のテーブルが作成される
  • 作成された_SRCHテーブルはインタラクティブ保存のAnalyticsテーブルなので、以降は通常のKQLで自由に分析できます
javascript
NetskopeAlerts_Incident20260708_SRCH
| summarize count() by alert_type_s, bin(TimeGenerated, 1d)
  • 課金はスキャンしたデータ量に対する都度課金です。対象テーブル・期間を絞るほど安くなります
  • _SRCHテーブル自体にも保存費用がかかるため、調査が終わったらテーブルを削除しましょう

方法2：復元（Restore）— 大量データを反復分析するインシデント調査向け

  • テーブルの特定期間をホットキャッシュに戻し、_RSTサフィックスのテーブルとしてフルKQLで分析できるようにする機能です。復元中のクエリ自体は何度実行しても無料です
  • ただし課金は「復元データの保持量×日数」（約$0.10/GB/日）で、最低でも2TB・12時間分から課金されるため、少量データの取り出しには不向きです
  • 分析が終わったら必ず復元を閉じる（破棄する）のを忘れないようにしましょう。閉じるまで課金が続きます

使い分けの目安

観点検索ジョブ復元
向いている用途範囲を絞ったスポット調査大量データの反復・フル分析
課金スキャン量に応じた都度課金保持量×日数（最低2TB・12時間分）
結果の置き場所_SRCHテーブル（要・後片付け）_RSTテーブル（要・復元を閉じる）
  • Netskopeログの規模感であれば、まずは検索ジョブで足りるケースがほとんどです。復元は「2TB分課金されても割に合う」大規模調査のときだけ検討しましょう

コミットメント階層について

  • コミットメント階層は最小でも50GB/日からのため、数GB/日規模では対象外です。まずはPAYGで始めて、取り込み量が育ってきたら再検討で十分です
  • なお、最小の50GB/日の階層は2025年10月にパブリックプレビューとして追加された比較的新しい階層のため、採用を検討する時点でGA状況・提供リージョンをあわせて確認してください
  • 逆にすでに50GB/日以上になる見込みがある場合はコミットメントの課金体系に切り替えることを検討します

さいごに

APIプル方式の「Netskope Alerts and Events」コネクタは、トークンとテナントURLだけで接続できる手軽さと、テーブル単位で取り込み・保持・権限を統制できるバランスの良さが魅力です。

まずは必要なログ種別だけを絞って小さく始め、実測した取り込み量をもとに保持期間や課金モデルを育てていく段階導入がおすすめです。

タグ

この記事をシェア

Shinsuke Murota
Shinsuke Murota

関連記事

SaaS

SaaS管理で何に困っているのか分からないとき、最初に見るべきポイント
SaaS

自社の Okta がどのセルにあるか、3分で確認する方法
SaaS

Intune Suite が Microsoft 365 E3 / E5 に追加！追加される機能と提供時期を解説
SaaS

IntuneでMicrosoft 365 Apps を ODT × Win32 で配布する手順を解説！ 再パッケージ不要で運用負荷軽減
SaaS

Jamf Connect はまだ必要？WWDC 2026後のPlatform SSOとmacOSログイン設計を整理する
SaaS

IruのWindows管理、どこまでできるか