集計ルールを使用してMicrosoft Sentinel データを集計する

適用対象: Microsoft Sentinel in the Microsoft Defender portal, Microsoft Sentinel in the Azure portal

Microsoft Sentinelの概要ルールを使用して、バックグラウンドで大量のデータセットを集計し、すべてのログ層にわたってよりスムーズなセキュリティ操作エクスペリエンスを実現します。サマリーデータはカスタムログテーブルでプリコンパイルされ、低コストのログ層から派生したデータに対してクエリが実行されるなど、高速なクエリパフォーマンスが提供されます。サマリールールは、次の目的でデータを最適化するのに役立ちます。

セキュリティとインシデント分析、月単位または年次ビジネスレポートなどに必要な、特に大規模なデータセットと時間範囲に対する分析とレポート。
詳細ログのコストを削減します。このログは、コストの低いログ層で必要なだけ、または必要な限り保持でき、分析とレポートのために集計データとして Analytics テーブルにのみ送信できます。
セキュリティとデータのプライバシー。要約された共有可能なデータのプライバシーの詳細を削除または難読化し、生データを含むテーブルへのアクセスを制限します。

Microsoft Sentinelでは、集計ルールの結果が Analytics データプランのカスタムテーブルに格納されます。データプランとストレージコストの詳細については、「ログテーブルプラン」を参照してください。

この記事では、概要ルールを作成するか、Microsoft Sentinelに事前構築済みのサマリールールテンプレートを展開する方法について説明し、サマリールールを使用するための一般的なシナリオの例を示します。

重要

2027 年 3 月 31 日以降、Microsoft SentinelはAzure portalでサポートされなくなり、Microsoft Defender ポータルでのみ使用できるようになります。 Azure portalでMicrosoft Sentinelを使用しているすべてのお客様は、Defender ポータルにリダイレクトされ、Defender ポータルでのみMicrosoft Sentinelを使用します。 2025 年 7 月以降、多くの新規顧客が自動的にオンボードされ、Defender ポータルにリダイレクトされます。

Azure portalでMicrosoft Sentinelを引き続き使用している場合は、スムーズな移行を確保し、Microsoft Defenderによって提供される統合セキュリティ操作エクスペリエンスを最大限に活用するために、Defender ポータルへの移行の計画を開始することをお勧めします。詳細については、「移動する時間: セキュリティを強化するためにMicrosoft SentinelのAzure portalを廃止する」を参照してください。

前提条件

Microsoft Sentinelでサマリールールを作成するには:

Microsoft Sentinelは、少なくとも 1 つのワークスペースで有効にし、ログをアクティブに使用する必要があります。
共同作成者のアクセス許可を持つMicrosoft Sentinel Microsoft Sentinelアクセスできる必要があります。詳細については、「Microsoft Sentinelのロールとアクセス許可」を参照してください。
Microsoft Defender ポータルでサマリールールを作成するには、まずワークスペースを Defender ポータルにオンボードする必要があります。詳細については、「Microsoft Defender ポータルにMicrosoft Sentinelを接続する」を参照してください。

ルールを作成する前に、[ログ] ページでサマリールールクエリを試することをお勧めします。クエリがクエリの制限に達していないか、または近くに達していないことを確認し、クエリが目的のスキーマと予想される結果を生成することをチェックします。クエリがクエリの制限に近い場合は、小さな binSize を使用して、ビンあたりのデータ処理量を減らすことを検討してください。クエリを変更して、返されるレコード数を減らしたり、ボリュームが多いフィールドを削除したりすることもできます。

新しいサマリールールを作成する

特定の大きなデータセットを動的テーブルに集計する新しいサマリールールを作成します。ルールの頻度を構成して、集計データセットが生データから更新される頻度を決定します。

概要ルールウィザードを開きます。
- Defender ポータルで、[構成Microsoft Sentinel >>概要ルール] を選択します。
- Azure portalの [Microsoft Sentinel] ナビゲーションメニューの [構成] で、[概要ルール] を選択します。例:
[ + 作成] を 選択し、次の詳細を入力します。
- 名前。ルールのわかりやすい名前を入力します。
- 説明。省略可能な説明を入力します。
- 変換先テーブル。データを集計するカスタムログテーブルを定義します。
  - [ 既存のカスタムログテーブル] を選択した場合は、使用するテーブルを選択します。
  - [ 新しいカスタムログテーブル] を選択した場合は、テーブルのわかりやすい名前を入力します。完全なテーブル名では、次の構文が使用されます: <tableName>_CL。
ワークスペースで SummaryLogs 診断設定を有効にして、履歴の実行とエラーを可視化することをお勧めします。 SummaryLogs 診断設定が有効になっていない場合は、[診断設定] 領域で有効にするように求められます。

SummaryLogs 診断設定が既に有効になっているが、設定を変更する場合は、[高度な診断設定の構成] を選択します。 [概要ルールウィザード] ページに戻ったら、[更新] を選択して設定の詳細を更新してください。

重要

SummaryLogs 診断設定には追加のコストがあります。詳細については、「Azure Monitor の診断設定」を参照してください。
続行するには、[次へ: サマリーロジック >を設定する] を選択します。
[ 概要ロジックの設定 ] ページで、サマリークエリを入力します。たとえば、Google Cloud Platform のデータを要約するには、次のように入力します。
```
GCPAuditLogs
| where ServiceName == 'pubsub.googleapis.com'
| summarize count() by Severity
```
詳細については、「Azure Monitor のサンプルサマリールールシナリオとKusto 照会言語 (KQL)」を参照してください。
[ プレビュー結果 ] を選択すると、構成されたクエリで収集するデータの例が表示されます。
[ クエリスケジューリング ] 領域で、次の詳細を定義します。
- ルールを実行する頻度
- 任意の種類の遅延でルールを実行するかどうか (分単位)
- ルールの実行を開始する場合
スケジュールで定義された時間は、データ内の timegenerated 列に基づいています
[次へ]: [確認と作成] >>[保存] を選択して、サマリールールを完了します。

[概要ルール] ページに既存の サマリールール が表示され、ルールの状態を確認できます。ルールごとに、行の末尾にあるオプションメニューを選択して、次のいずれかのアクションを実行します。

クエリをすぐに実行するかのように、[ ログ ] ページでルールの現在のデータを表示する
選択したルールの実行履歴を表示する
ルールを無効または有効にします。
ルール構成を編集する

ルールを削除するには、ルール行を選択し、ページの上部にあるツールバーの [削除] を選択 します 。

注:

Azure Monitor では、API または Azure Resource Monitor (ARM) テンプレートを使用したサマリールールの作成もサポートされています。詳細については、「概要ルールを作成または更新する」を参照してください。

事前構築済みのサマリールールテンプレートをデプロイする

サマリールールテンプレートは、そのままデプロイしたり、ニーズに合わせてカスタマイズしたりできる、事前に構築されたサマリールールです。

サマリールールテンプレートをデプロイするには:

[コンテンツハブ] を開き、[概要ルール] で [コンテンツタイプ] をフィルター処理して、使用可能なサマリールールテンプレートを表示します。
サマリールールテンプレートを選択します。

概要ルールテンプレートに関する情報を含むパネルが開き、説明、サマリークエリ、変換先テーブルなどのフィールドが表示されます。
[ インストール] を選択してテンプレートをインストールします。
[概要ルール] ページの [テンプレート] タブを選択し、インストールしたサマリールールを選択します。
[ 作成 ] を選択して、すべてのフィールドが事前入力されているサマリールールウィザードを開きます。
概要ルールウィザードを実行し、[ 保存] を選択してサマリールールを展開します。

概要ルールウィザードの詳細については、「新しいサマリールールを作成する」を参照してください。

Microsoft Sentinelでの概要ルールのシナリオの例

このセクションでは、Microsoft Sentinelでサマリールールを作成するための一般的なシナリオと、各ルールを構成する方法に関する推奨事項について説明します。詳細と例については、「補助テーブルの生データから、補助ログインジェストに使用するMicrosoft Sentinelおよびログソースの分析テーブルへの分析情報の要約」を参照してください。

ネットワークトラフィック内の悪意のある IP アドレスをすばやく見つける

シナリオ: 脅威ハンターであり、チームの目標の 1 つは、アクティブなインシデントのネットワークトラフィックログで悪意のある IP アドレスが過去 90 日間に対話したときのすべてのインスタンスを特定することです。

課題: Microsoft Sentinel現在、1 日に複数テラバイトのネットワークログを取り込みます。悪意のある IP アドレスの一致を見つけるには、それらを迅速に移動する必要があります。

解決策: サマリールールを使用して、次の操作を行うことをお勧めします。

SourceIP、DestinationIP、MaliciousIP、RemoteIP、IPType、FirstTimeSeen、LastTimeSeenなど、インシデントに関連する各 IP アドレスの概要データセットを作成します。

サマリーデータセットを使用すると、特定の IP アドレスをすばやく検索し、IP アドレスが見つかった時間範囲を絞り込みます。これは、検索されたイベントが 90 日以上前に発生し、ワークスペースの保持期間を超えた場合でも実行できます。

この例では、クエリが有効期限が切れるまで毎日新しいサマリーレコードを追加するように、サマリーを毎日実行するように構成します。

概要データセットに対して 2 分以内に実行される分析ルールを作成し、悪意のある IP アドレスが会社のネットワークと対話したときに特定の時間範囲をすばやく掘り下げる。

さまざまなサマリーペイロードサイズに対応するために、少なくとも最大 5 分の実行間隔を構成してください。これにより、イベントインジェストの遅延が発生しても損失が発生しません。

例:

let csl_columnmatch=(column_name: string) {
summarized_CommonSecurityLog
| where isnotempty(column_name)
| extend
    Date = format_datetime(TimeGenerated, "yyyy-MM-dd"),
    IPaddress = column_ifexists(column_name, ""),
    FieldName = column_name
| extend IPType = iff(ipv4_is_private(IPaddress) == true, "Private", "Public")
| where isnotempty(IPaddress)
| project Date, TimeGenerated, IPaddress, FieldName, IPType, DeviceVendor
| summarize count(), FirstTimeSeen = min(TimeGenerated), LastTimeSeen = min(TimeGenerated) by Date, IPaddress, FieldName, IPType, DeviceVendor
};
union csl_columnmatch("SourceIP")
    , csl_columnmatch("DestinationIP") 
    , csl_columnmatch("MaliciousIP")
    , csl_columnmatch("RemoteIP")
// Further summarization can be done per IPaddress to remove duplicates per day on larger timeframe for the first run
| summarize make_set(FieldName), make_set(DeviceVendor) by IPType, IPaddress

後続の検索または他のデータとの相関関係を実行 して、攻撃ストーリーを完了します。

ネットワークデータに対する脅威インテリジェンスの一致に関するアラートを生成する

脅威インテリジェンスに関するアラートを生成し、ノイズの多い、大量の、セキュリティの低い値のネットワークデータと一致させます。

シナリオ: 脅威インテリジェンスドメイン名リストに対してアクセスされたシステム内のドメイン名と一致するように、ファイアウォールログの分析規則を構築する必要があります。

ほとんどのデータソースは、ノイズが多くボリュームが多い生ログですが、IP アドレス、Azure Firewall トラフィック、Fortigate トラフィックなど、セキュリティ値は低くなります。 1 日あたり約 1 TB の合計ボリュームがあります。

課題: 個別のルールを作成するには、複数のロジックアプリが必要であり、追加のセットアップとメンテナンスのオーバーヘッドとコストが必要です。

解決策: サマリールールを使用して、次の操作を行うことをお勧めします。

サマリールールを作成します。
1. クエリを拡張して、ソースアドレス、宛先アドレス、宛先ポートなどのキーフィールドを 、補助 プランの CommonSecurityLog であるCommonSecurityLog_CL テーブルから抽出します。
2. アクティブな脅威インテリジェンスインジケーターに対して内部参照を実行して、ソースアドレスとの一致を特定します。これにより、既知の脅威とデータを相互参照できます。
3. 生成された時間、アクティビティの種類、悪意のあるソース IP、宛先の詳細など、プロジェクト関連情報。クエリを実行する頻度と、対象テーブル ( MaliciousIPDetection など) を設定します。このテーブルの結果は分析レベルにあり、それに応じて課金されます。
アラートを作成します。

Microsoft Sentinelで分析ルールを作成し、MaliciousIPDetection テーブルからの結果に基づいてアラートを生成します。この手順は、プロアクティブな脅威検出とインシデント対応に不可欠です。

サンプルの概要ルール:

CommonSecurityLog_CL
| extend sourceAddress = tostring(parse_json(Message).sourceAddress), destinationAddress = tostring(parse_json(Message).destinationAddress), destinationPort = tostring(parse_json(Message).destinationPort)
| lookup kind=inner (ThreatIntelligenceIndicator | where Active == true ) on $left.sourceAddress == $right.NetworkIP
| project TimeGenerated, Activity, Message, DeviceVendor, DeviceProduct, sourceMaliciousIP =sourceAddress, destinationAddress, destinationPort

フィードバック

このページはお役に立ちましたか?

Last updated on 2026-04-23

集計ルールを使用してMicrosoft Sentinel データを集計する

前提条件

新しいサマリー ルールを作成する

事前構築済みのサマリー ルール テンプレートをデプロイする

Microsoft Sentinelでの概要ルールのシナリオの例

ネットワーク トラフィック内の悪意のある IP アドレスをすばやく見つける

ネットワーク データに対する脅威インテリジェンスの一致に関するアラートを生成する

関連コンテンツ

フィードバック

その他のリソース

新しいサマリールールを作成する

事前構築済みのサマリールールテンプレートをデプロイする

ネットワークトラフィック内の悪意のある IP アドレスをすばやく見つける

ネットワークデータに対する脅威インテリジェンスの一致に関するアラートを生成する