【技術補講】ディランが見ていた「3つの監視ダッシュボード」をMicrosoft Sentinelで再現してみた

連載『Project Zero Trust』Vol.5では、主人公ディランが「数億行のログの洪水」から脱却し、「本当に見るべき3つの指標」に絞り込む様子を描きました。

Identity Risk（アイデンティティのリスク）
Privileged Access（特権IDの動き）
Lateral Movement（内部での感染拡大）

「概念はわかった。でも、Azure（Microsoft Sentinel）でそれをどう書けばいいの？」
今回はそんな現場のエンジニアのために、コピペで使えるKQL（Kusto Query Language）を用意しました。

この記事は『Project Zero Trust』特集の一部です。全記事一覧はこちら↓

【総力特集】Project Zero Trust 実践・解体新書

米国のセキュリティ名著『Project Zero Trust』を題材に、日本の中堅企業がゼロトラストを実装するための全ノウハウを体系化した特集ページ。物語連載、理論要約、技術実装ガイド（Excel/KQL/演習台本）を完全網羅。

前提条件：ログの蛇口を開く
1. Identity Risk：そのログイン、本人ですか？
1. 🛠 再現クエリ (KQL)
2. Privileged Access：王冠の鍵を守れ
1. 🛠 再現クエリ (KQL)
3. Lateral Movement：横移動を許すな
1. 🛠 再現クエリ (KQL)
まとめ：可視化こそが「武器」だ

前提条件：ログの蛇口を開く

このクエリを実行するためには、以下のログがMicrosoft Sentinelに取り込まれている必要があります。

環境: Microsoft Sentinel が有効化されていること。
ログソース:
- Identity系: Microsoft Entra ID (旧 Azure AD) の SigninLogs (サインインログ) および AuditLogs (監査ログ)。
- Endpoint系: Windows Security Event (SecurityEvent) または Microsoft Defender for Endpoint のログ。

これらが「データコネクタ」設定でONになっていれば準備完了です。

1. Identity Risk：そのログイン、本人ですか？

ディランが最初に固めたのは「ID」です。ここでは「パスワードスプレー」や「ブルートフォース（総当たり）」攻撃の兆候を捉えます。
「何度も失敗した後に、ようやく成功した」というパターンは、正規ユーザーがパスワードを忘れただけか、攻撃者が突破したかのどちらかです。

🛠 再現クエリ (KQL)

// 過去1時間で、5回以上パスワードを間違えた後に成功したユーザー（ブルートフォース成功の疑い）
let timeRange = 1h;
let failureThreshold = 5;
SigninLogs
| where TimeGenerated > ago(timeRange)
| where ResultType != 0 // 失敗のみ抽出
| summarize FailureCount = count() by UserPrincipalName, IPAddress, AppDisplayName
| where FailureCount >= failureThreshold
| join kind=inner (
    SigninLogs
    | where TimeGenerated > ago(timeRange)
    | where ResultType == 0 // 成功のみ抽出
    | project UserPrincipalName, SuccessTime = TimeGenerated, SuccessIP = IPAddress
) on UserPrincipalName
| project UserPrincipalName, FailureCount, FailureIP, SuccessIP, SuccessTime
| order by SuccessTime desc

解説:
このリストに載ったユーザーには、即座にMFA（多要素認証）の再確認を行うか、本人にチャットで確認を入れるべきです。

2. Privileged Access：王冠の鍵を守れ

「ドメイン管理者（Domain Admins）」や「グローバル管理者（Global Administrator）」は、攻撃者が喉から手が出るほど欲しい特権です。
本来、特権グループのメンバーが増えたり減ったりすることは、日常的にはありえません。

🛠 再現クエリ (KQL)

Entra ID (Azure AD) の監査ログから、最強権限である「Global Administrator」へのメンバー追加を検知します。

// "Global Administrator" ロールへのメンバー追加を検知
AuditLogs
| where TimeGenerated > ago(24h)
| where OperationName == "Add member to role"
| where Result == "success"
| mv-expand TargetResources
| extend RoleName = tostring(TargetResources.modifiedProperties[1].newValue) // ロール名抽出
| where RoleName contains "Global Administrator" or RoleName contains "Company Administrator"
| project TimeGenerated, Actor = Identity, AddedUser = tostring(TargetResources.userPrincipalName), RoleName

解説:
このクエリがヒットしたら、それは「誰かが勝手に神の権限を手に入れた」ことを意味します。ディランなら、この検知と同時に管理者のスマホへ電話をかけるでしょう。

3. Lateral Movement：横移動を許すな

ゼロトラスト・アーキテクチャでは、「クライアントPC同士の直接通信」は異常とみなします。
経理部のPCが、人事部のPCに接続しに行っている……それはマルウェアが感染拡大（ラテラルムーブメント）を狙っている兆候です。

🛠 再現クエリ (KQL)

Windowsイベントログ（4624: ログオン成功）から、PC間の不審な接続を探します。

// クライアントPC同士の通信（Logon Type 3 = Network）を検知
// ※サーバーIPのホワイトリスト除外が必要
SecurityEvent
| where TimeGenerated > ago(1h)
| where EventID == 4624
| where LogonType == 3 // ネットワーク経由のログオン
| where AccountType == "User"
// 以下の行で、本来アクセスされるはずのファイルサーバー等を「除外」する
| where Computer !in ("FileServer01.corp.local", "PrintServer.corp.local") 
| project TimeGenerated, SourceComputer = WorkstationName, TargetComputer = Computer, Account

解説:
「PCからサーバー」への通信は正常ですが、「PCからPC」への通信は、管理用ツール以外ではほぼマルウェアの挙動です。このダッシュボードが赤くなったら、対象端末のネットワーク隔離（Isolation）を検討してください。