Microsoft Sentinel で事前構築済みまたはカスタム の概要ルール を使用して、 補助ログ層を含む任意のログ層の大規模なデータ セットから定期的に分析情報を集計します。 集計データを操作すると、クエリのパフォーマンスが向上し、次の目的でデータを最適化できます。
- 分析とレポート。特に、セキュリティおよびインシデント分析、月次または年次ビジネス レポートなどに必要な、大規模なデータ セットと時間の範囲が対象。
- 詳細ログのコスト削減。低コストのログ層に必要な期間だけ保持し、集計データは分析およびレポート用分析テーブルにのみ送信できます。
- セキュリティとデータ プライバシー。集計された共有可能なデータのプライバシーの詳細を削除または難読化し、生データを含むテーブルへのアクセスを制限することで確保します。
Microsoft Sentinel では、 Analytics データ プランを使用して、集計ルールの結果をカスタム テーブルに格納します。 データ プランとストレージ コストの詳細については、「 ログ テーブル プラン」を参照してください。
この記事では、概要ルールを作成する方法、または Microsoft Sentinel で事前構築済みの概要ルール テンプレートをデプロイする方法について説明し、概要ルールを使用するための一般的なシナリオの例を示します。
重要
集計ルールは現在、プレビュー段階です。 ベータ版、プレビュー版、または一般提供としてまだリリースされていない Azure の機能に適用される法律条項については、「Microsoft Azure プレビューの追加使用条件」を参照してください。
Microsoft Sentinel は、Microsoft Defender XDR または E5 ライセンスを持たないお客様を含め、Microsoft Defender ポータルで一般提供されています。 2026 年 7 月以降、Microsoft Sentinel は Defender ポータルでのみサポートされ、Azure portal を使用している残りの顧客は自動的にリダイレクトされます。 Azure で Microsoft Sentinel を使用しているお客様は、Microsoft Defender によって提供される完全な統合セキュリティ操作エクスペリエンスのために、Defender ポータルへの移行の計画を開始することをお勧めします。 詳細については、「 すべての Microsoft Sentinel ユーザー向けの Microsoft Defender ポータルへの移行の計画 (ブログ)」を参照してください。
前提条件
Microsoft Sentinel で集計ルールを作成するための前提条件は、以下の通りです。
Microsoft Sentinel を少なくとも 1 つのワークスペースで有効にし、ログをアクティブに使用する必要があります。
Microsoft Sentinel 共同作成者のアクセス許可を使用して Microsoft Sentinel にアクセスできるようにする必要があります。 詳細については、「Microsoft Sentinel のロールとアクセス許可」を参照してください。
Microsoft Defender ポータルで集計ルールを作成するには、最初にワークスペースを Defender ポータルにオンボードする必要があります。 詳細については、「Microsoft Defender ポータルに Microsoft Sentinel を接続する」を参照してください。
ルールを作成する前に、[ログ] ページで集計ルールクエリを試しておくことをお勧めします。 クエリがクエリの制限に達していないか、まだしばらく到達することはないことを確認し、クエリによって目的のスキーマと期待した結果が生成されるかチェックします。 クエリがクエリの制限に近づいている場合は、小さな binSize
を使用して、ビンごとに処理するデータを減らすことを検討してください。 また、クエリを変更して、返されるレコード数を減らしたり、ボリュームが大きいフィールドを削除したりすることもできます。
新しい概要ルールを作成する
新しい集計ルールを作成して、大規模な特定のデータ セットを動的テーブルで集計します。 ルールの頻度を設定して、集計されたデータ セットが生データから更新される頻度を決定します。
概要ルール ウィザードを開きます。
[+ 作成] を選択し、以下の詳細を入力します。
名前。 ルールのわかりやすい名前を入力します。
説明。 必要に応じて説明を入力します。
[ターゲット テーブル]。 データが集計されるカスタム ログ テーブルを定義します。
[既存のカスタム ログ テーブル] を選択した場合は、使用するテーブルを選択します。
[新しいカスタム ログ テーブル] を選択した場合は、テーブルにわかりやすい名前を入力します。 完全なテーブル名には、
<tableName>_CL
構文を使用してください。
ワークスペースで SummaryLogs 診断設定を有効にして、実行とエラーの履歴を表示することをお勧めします。 SummaryLogs 診断設定が有効になっていない場合は、[診断設定] 領域で有効にするように求められます。
SummaryLogs 診断設定が既に有効になっていて、設定を変更する場合は [Configure advanced diagnostic settings]\(詳細な診断設定の構成)\ を選択します。 [集計ルール ウィザード] ページに戻ったら、必ず [更新] を選択して設定の詳細を更新してください。
重要
SummaryLogs 診断設定には追加のコストがかかります。 詳しくは、「Azure Monitor の診断設定」をご覧ください。
[Next: Set summary logic]\(次へ: 集計 ロジックの設定)\> を選択して続行します。
[Set summary logic]\(集計ロジックの設定)\ ページで、集計クエリを入力します。 たとえば、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) テンプレートを使用した集計ルールの作成もサポートされています。 詳細については、「集計ルールの作成または更新」を参照してください。
事前構築済みの概要ルール テンプレートをデプロイする
サマリー ルール テンプレートは、as-is をデプロイしたり、ニーズに合わせてカスタマイズしたりできる事前構築済みの概要ルールです。
概要ルール テンプレートをデプロイするには:
コンテンツ ハブを開き、概要ルールでコンテンツ タイプをフィルター処理して、使用可能なサマリー ルール テンプレートを表示します。
概要ルール テンプレートを選択します。
概要ルール テンプレートに関する情報が表示されたパネルが開き、説明、サマリー クエリ、変換先テーブルなどのフィールドが表示されます。
[ インストール] を選択してテンプレートをインストールします。
[概要ルール] ページで [テンプレート] タブを選択し、インストールした概要ルールを選択します。
[ 作成 ] を選択して概要ルール ウィザードを開きます。ここでは、すべてのフィールドが事前設定されています。
概要ルール ウィザードを実行し、[ 保存] を選択して概要ルールを展開します。
概要ルール ウィザードの詳細については、「 新しい概要ルールを作成する」を参照してください。
Microsoft Sentinel の概要ルール シナリオの例
このセクションでは、Microsoft Sentinel で集計ルールを作成するための一般的なシナリオと、各ルールの構成方法に関する推奨事項について説明します。 詳細と例については、「補助テーブルの生データを Microsoft Sentinel (プレビュー) の分析テーブルに要約して分析する」 および 「補助ログの取り込みに使用するログ ソース」をご参照ください。
ネットワーク トラフィック内の悪意のある IP アドレスをすばやく見つける
シナリオ: あなたは脅威ハンターです。チームの目標の 1 つは、ネットワーク トラフィック ログでアクティブなインシデントから過去 90 日間に使用された悪意のある IP アドレスの、すべてのインスタンスを特定することです。
課題: Microsoft Sentinel は現在、1 日に数テラバイトのネットワーク ログを取り込みます。 悪意のある IP アドレスと一致するアドレスを見つけるには、大量のログを迅速に調査していく必要があります。
ソリューション: 集計ルールを使用して、次の手順を実行することをお勧めします。
インシデントに関連する各 IP アドレスに集計データ セットを作成します。これには
SourceIP
、DestinationIP
、MaliciousIP
、RemoteIP
や、IPType
、FirstTimeSeen
、LastTimeSeen
などの重要な属性のリストが含まれます。集計データセットを使用すると、特定の 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 のボリュームがあります。
課題: 個別のルールを作成するには複数のロジック アプリが必要であり、そのためには追加のセットアップとメンテナンスに対するオーバーヘッドとコストが必要となります。
ソリューション: 集計ルールを使用して、次の手順を実行することをお勧めします。
集計ルールを作成する:
クエリを拡張し、CommonSecurityLog_CL テーブルからソース アドレス、宛先アドレス、宛先ポートなどのキー フィールドを抽出します。これは、Auxilairy プランを使用した CommonSecurityLog です。
アクティブな脅威インテリジェンス インジケーターに対して内部検索を実行して、ソース アドレスとの一致を特定します。 これにより、既知の脅威でデータを相互参照できます。
生成された時間、アクティビティの種類、悪意のあるソース IP、宛先の詳細などの関連情報を射影します。 クエリを実行する頻度と、ターゲット テーブル (MaliciousIPDetection など) を設定します。 このテーブルの結果は分析レベルにあり、それに応じて課金されます。
アラートを作成する:
MaliciousIPDetection テーブルからの結果に基づいてアラートを生成する分析ルールを Microsoft Sentinel で作成します。 この手順は、プロアクティブな脅威検出とインシデント対応に不可欠です。
集計ルールの例:
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