Sentinelの認証アラートをKQLで調査
AI SOC 調査ユースケース · 開発中・先行相談
連携製品一覧 → AI SOC for Microsoft Sentinel → この調査業務
提供状況：開発中・先行相談
Sentinelのアラートに含まれるアカウントやIPは、関連ログへ進むための手掛かりです。認証結果を確認するには、そのアラートを生成したデータがどのワークスペース・テーブルに保存されているかを揃える必要があります。アラートが見えることと、追加調査に必要なログを読めることは別々に確認します。
この調査の流れ
検知・ログ：SecurityAlertに保存された認証関連アラート
AIが確認する内容：アカウント・IP・時刻を起点に、指定したサインインテーブルをKQLで検索。
判断に使う情報：アラートと関連ログの整合性、本人確認が必要な点を整理。
使用するデータと検索の起点
アラートの取得元はSecurityAlertが初期値です。追加調査では、同じLog Analyticsワークスペース内で接続時に指定したテーブルを単独で検索します。対象アカウント・IP・発生時刻を手掛かりにしますが、フィールドや利用可能なテーブルは導入済みコネクタとデータ収集設定に依存します。
SecurityAlertの対象アカウント
対象IP・検知時刻
指定テーブルの認証結果
アラートから追加調査までの手順
SecurityAlertの内容から調査対象と期間を特定する。
接続時に指定したテーブルを単独で検索し、認証結果を確認する。
確認できた記録と、未取得・権限不足で確認できない範囲を区別する。
具体的な調査の考え方
以下は説明用の仮想例です。顧客事例や実環境での実演結果ではありません。
認証に関するSecurityAlertから、対象アカウントのサインインを確認する場面を想定します。アラートの時刻を中心に調査期間を設定し、指定テーブルをアカウントと接続元で絞ります。認証の失敗理由や成功の有無を、応答に含まれる情報から整理します。対象テーブルが読めない場合は、認証がなかったという結論にはしません。
担当者へ引き継ぐ情報
観測事実：対象アカウント、検索条件、期間、取得された認証結果をまとめる。
判断保留：ログの未収集、保持期間外、権限不足、応答の不完全性を確認不足として示す。
次の確認：本人確認、接続元の確認、適切なテーブルと権限の追加を担当者に引き継ぐ。
接続条件と対応範囲
Public AzureのLog Analytics APIを使う設計です。ワークスペースIDと、対象ログを読み取るアプリの認証・権限を設定します。接続テストはSecurityAlertの検索を確認しますが、それだけですべての追加調査テーブルにアクセスできることを証明するものではありません。
連携は開発中です。対象ログが同じLog Analyticsワークスペースにあり、テーブルと権限を指定できることが前提です。
導入前に確認すること
想定したSecurityAlertと認証ログが、同じ対象ワークスペースで読めるか。
単一テーブルのKQL検索で、指定した期間と対象に絞れているか。
最大500行の検索範囲、検索失敗、不完全な応答が判断時に分かるか。
比較時は同じアラート・同じ期間を使い、参照した記録、確認できない情報、担当者が追加で行った作業を残します。調査時間の比較だけでなく、結論の根拠を担当者が確認できるかを評価します。
よくある質問
テーブルを結合した調査はできますか？
この連携では単一テーブルごとに調べる設計です。テーブル結合、複数文、外部ワークスペースや外部データへの照会は対象外です。
KQLを使うDefender連携と同じものですか？
検索言語が共通でも、接続先API・保存データ・権限・取得範囲が異なります。Sentinelでは対象Log Analyticsワークスペースを確認します。
この調査を自社の環境で検討する
Microsoft Sentinelの利用環境と、困っているアラートの種類、使えるログの範囲をお知らせください。取得する情報と担当者が判断する範囲を整理し、確認する接続条件をご案内します。
AI SOC for Microsoft Sentinelの連携全体を見る · 別の製品・調査例を探す
参考情報
Microsoft：Azure Monitor Logs Query API
確認・更新：2026年9月13日。ベンダーAPIの仕様とヤグラの接続・調査範囲は区別して記載しています。
