Defender for Identity（MDI）パラメータ設計 完全ガイド

— 基本指標／通信・依存／イベント収集／タグ＆欺瞞／誤検知チューニング／KPI

MDIは「NNR（解像度）× イベント（文脈） × タグ（意味付け） × 欺瞞（早期検知）」の掛け算です。どれか1つが弱いと、検知は“鳴るけど刺さらない”状態になります。本ガイドでは、数値とパラメータで回る設計に落とし込みます。

0. ゴールと基本指標（KPIを“最初に”決める）

0-1. 運用KPI（毎日回るか）

• NNR成功率 ≥ 98%（95〜98%＝要観察、＜95%＝即是正）

• センサー重大ヘルス = 0 を日次確認

• 未調査アラート > 24h = 0（High/Medium）

0-2. 結果KPI（守れたか）

• Honeytoken 発火 = 0（>0 は P1、15分以内封じ込め）

• 横展開封じ込め中央値 ≤ 15分（検知→隔離までの実測）

0-3. ガバナンスKPI（語れるか）

• 接続・NNR・イベントの欠測 = 0（週次レビュー）

• タグ網羅率（Sensitive/Honeytoken）= 100%（四半期棚卸）

KPIは“ダッシュボードに貼る”前提で定義します。各KPIに取得KQLと**証跡棚（保存先）**を紐づけるのがコツ。

1. センサーと接続（通信・プロキシ・クラウド到達性）

1-1. センサー配置の方針

• 第一選択：DC 直載せ（軽量センサー）

  • NTLM/Kerberos の文脈が最短で取れ、ETWイベントも拾える。

• 代替：スタンドアロンセンサー

  • ミラーポート/タップでトラフィックを給電。ETW非対応ゆえカバレッジは落ちる。

• 配置密度

  • ドメインコントローラーの地理/ネットワーク境界ごとに最低1。負荷が高いDCは段階導入。

1-2. クラウド到達性（プロキシ含む）

• 宛先：<workspace>sensorapi.atp.azure.com:443 ほか *.atp.azure.com:443

• TLS：中間解除（SSL検査）をバイパス。ピン留め/証明書検証が前提のため。

• プロキシ：認証が挟まると通信確立が不安定になりやすい。**例外（バイパス）**を作る。

• 疎通テスト：センサーからの ping/ヘルス確認（ポータルの接続テスト機能）を定例化。

1-3. センサー⇔AD/周辺

• LDAPS（636/3269）：可能なら暗号化を検討。ただしログ量・依存調整を要す。

• センサー更新ポート：ローカル 444/TCP（サービス更新）。

• 監視：センサー重大ヘルス = 0 を日次で確認し、異常は当日中に是正。

まず“繋がる・解像できる・吐ける”を固める。これで偽陰性と誤検知の土台が一段減ります。

2. NNR（Network Name Resolution）設計

—「誰が（どの端末が）」「どこへ」「どう認証したか」を名前で語れるようにする

2-1. 方式と必須ポート

• NTLM over RPC：135/TCP

• NetBIOS：137/UDP

• RDP 初回握手：3389/TCP（カスタムRDPポートは非対応）

• 逆引きDNS（PTR）：53/UDP（センサー→DNS）

“いずれかが通れば良い”ではなく“複数方式を有効”が原則。冗長化で成功率と安定性が上がる。

2-2. ファイアウォール／DNS 設計

• FWルール（最小スコープ）：

  • センサーIP → 管理対象セグメントへ 135/TCP・137/UDP・3389/TCP 許可

  • センサーIP → DNSサーバーへ 53/UDP（逆引きクエリ）許可

• 逆引きゾーン：新規セグメント追加時は正引きと同時にPTRゾーンを作成。

• RDP：ポリシー上リモート不可の端末であっても、初回握手用途の3389/TCPは到達させる。

2-3. 運用KPIとアラート

• NNR成功率 ≥ 98% を維持。95〜98%は要観察（週次レビュー）、<95% は即是正（当日中）。

• ヘルス“Active name resolution が低下”は最優先で是正（ポート/DNS/経路を方式別に切り分け）。

• 「成功率が時間帯で落ちる」のはネットワーク混雑・セグメント単位のフィルターが多い。

2-4. トラブル時の切り分け

1. センサー→端末へ 135/137/3389 の到達を確認（許可/拒否/タイムアウト）

2. センサー→DNS の PTR 応答を確認（NXDOMAIN/無応答）

3. 方式別で成功/失敗を色分け（“1方式でも通ればOK”の罠を除去）

4. 経路でキャリア/NAT/IPSが握っていないかを点検

NNRは検知の母音です。成功率が落ちた環境は、アラートが“匿名化”し、調査工数が爆発します。

3. イベント収集（AD／AD FS／AD CS／同期基盤）

— ネットワークの“絵”に**ログの“字幕”**を重ねて真偽を取る

3-1. DC（ドメインコントローラー）

• Kerberos：4768（TGT）、4769（TGS）、4771（プレ認証失敗）

• NTLM：4776（認証試行）、8004（NTLM監査）

• アカウント／グループ：4726/4728/4729/4730/4732/4733 など

• 構成変更：5136（ディレクトリ変更）、7045（サービス作成）

3-2. AD FS（フェデレーション）

• 1202/1203（トークン発行／検証）、4624/4625（サインイン成否）

• フェデレーション経由のパススルー型の奇妙なログオンを押さえる。

3-3. AD CS（証明書サービス）

• 4870/4882/4885/4887/4888/4890/4896（テンプレ変更、発行、失効 等）

• DCOM 誤用／不正テンプレでの横展開リスクを押さえる。

3-4. 同期基盤（Entra Connect）

• 4624/4625（直接ログオン／失敗）

• 同期アカウントの権限過多・予期せぬ直接ログオンを見逃さない。

3-5. 収集の実務

• 監査ポリシーの標準化（GPO）

• 収集先：MDIセンサー→Defender XDR→Sentinel（SIEM）

• イベント欠測 = 0 をKPIに。週次で空白時間を棚卸。

MDIは“ネットワーク＋Windowsイベント”の二重構図。両輪が噛むほど、誤検知は減り、真のP1が浮きます。

4. タグと欺瞞（Sensitive／Honeytoken）

— 「大事なものを“大事”だと教える」「触ったら即バレる餌を置く」

4-1. Sensitive タグ（高価値エンティティ）

• 対象：EA/DA/Schema Admins、PKI/IDP/財務・会計システム、Exchange/ドメインコントローラ 等

• 網羅：100%タグ付け（ネスト・委譲・旧グループまで拾う）

• 棚卸：四半期。入替・廃止・業務移管を追随。

4-2. Honeytoken（ユーザー／デバイス）

• 最小密度：各フォレスト ≥ 3（各ドメイン1＋冠ジュエルOU1）

• 性質：権限なし／普段は無活動／使われたら即P1

• ネーミング：“古い業務名”でリアル感（例 svc_legacy_bi, svc_old_backup）

• 管理：資格情報は金庫保管、誰も使わない文化を徹底

4-3. P1 ランブック（発火時）

T+0  : MDI「Honeytoken 認証」High 発報 Auto : セッション失効／端末隔離（XDR SOAR） T+5  : 初報ドラフト自動生成→法務レビューへ（72hライン） T+15 : 横展開の兆候ハント（同IP/同ユーザーの Kerberos/NTLM 連鎖） D+1  : 再発防止（パスワードリセット、経路遮断）、Evidence 保管

「餌を食ったら即罠が閉じる」状態をPlaybookで作ります。人の承認は“復帰”だけ。

5. 誤検知チューニング（Exclusion / Alert Tuning）

— “静かで鋭い”アラートに育てる

5-1. 原則

• 除外は“最後の手段”。まずはAlert Tuningでルール単位の抑制を選ぶ。

• スキャナ／管理端末など“騒音源”は、IP/端末/ユーザー単位でチューニング。

5-2. 進め方

1. ノイズ・アラートの上位を抽出（週次）

2. 資産台帳と突合（スキャナ／バックアップ／監視装置）

3. ルール単位で抑制（“このIPからの〇〇検知のみ”を下げる）

4. 変更は30日限定→延長は承認・理由・ログ必須（例外の負債を作らない）

5-3. しきい値の扱い

• 検収期間だけ高感度（PoC/導入直後は“拾い過ぎ”で良い）

• 本番運用に入ったら既定へ戻す（過検知でL1が疲弊すると本物を落とす）

6. ダッシュボード / KQL（即使えるクエリ）

6-1. 未調査×高深刻度（24h超）棚卸

kusto

SecurityIncident | where Severity in ("High","Medium") | where Status in ("Active","New") and CreatedTime < ago(24h) | summarize Count = count() by ProviderName, Severity | order by Count desc

6-2. MDI NNR 失敗トレンド（日次）

kusto

IdentityDirectoryEvents | where ActionType == "ActiveNameResolutionFailed" | summarize Failures = count() by bin(Timestamp, 1d)

6-3. Honeytoken 認証の検知（直近7日）

kusto

let HoneyUsers = IdentityInfo | mv-expand tag = Tags | where tostring(tag) contains "Honeytoken" | project AccountUpn; IdentityLogonEvents | where Timestamp > ago(7d) | join kind=inner (HoneyUsers) on AccountUpn | summarize Attempts = count(), Protocols = make_set(Protocol), From = make_set(DeviceName) by AccountUpn, DestinationDeviceName | order by Attempts desc

6-4. Sensitive 失敗ログオン集中検知

kusto

let Sensitive = IdentityInfo | mv-expand tag = Tags | where tostring(tag) contains "Sensitive" | project AccountUpn; IdentityLogonEvents | where Timestamp > ago(24h) and FailureReason != "" | join kind=inner (Sensitive) on AccountUpn | summarize Fails = count(), Reasons = make_set(FailureReason) by AccountUpn, DeviceName | order by Fails desc

ダッシュボードは「一画面＝一判断」。L1向け（今日やること）とCISO向け（健全度）を分けると運用が軽くなります。

7. 証跡（Evidence-first）と監査パッケージ

— 監査は“運用の副産物”にする

7-1. Evidence Vault（保管の作法）

• 棚（Workspace/Container）→箱（Table/Folder）→索引（KQL/ID）を設計

• 保持 ≥ 365日（規制要件に応じ延長）＋ 改ざん耐性（WORM/Immutable）

• 目次（Evidence Catalog）に “統制 → KQL → 保管先 → 保持” を一列で記載

7-2. 最低限の“監査パック”

• 接続証跡：クラウド到達のログ／センサー疎通テスト結果

• NNR 設計と実績：FW ルール／PTR ゾーン設計／成功率グラフ／是正履歴

• イベント監査：DC/AD FS/AD CS/同期の有効化手順と出力例

• タグ台帳：Sensitive/Honeytoken の付与・削除の履歴

• ランブック／72h 初報テンプレ：埋め込みサンプル付

• 例外台帳：理由・承認・期限・失効ログ（誤検知チューニングの記録を含む）

「監査質問→KQL→出力→提出」まで10分で終わるのが設計品質の指標です。

8. 30/60/90 日 ロードマップ（現実的な進め方）

Day 0–30（基礎固め）

• センサー設置／クラウド到達のTLS検査バイパス

• NNR 3方式 + 逆引き DNS を到達化、成功率計測を開始

• DC/AD FS/AD CS/同期の監査イベント有効化

• Sensitive の初回付与、Honeytoken ≥ 3/フォレスト

• Evidence Vault 雛形／監査パック目次

Day 31–60（検知前提へ）

• ダッシュボード初版（未調査24h=0、NNR、イベント欠測、Honeytoken）

• SOAR 直列化（発火→隔離→初報ドラフト→法務レビュー）

• 誤検知チューニング（ルール単位）、例外は30日期限

Day 61–90（定着）

• 机上演習（Honeytoken 発火台本）／ゲームデー（NNR劣化シナリオ）

• 四半期棚卸のスケジュールにタグ/NNR/イベントを組み込み

• 監査パック初版レビュー→**“10分で証跡”**の到達を確認

9. ありがちな詰まりと回避策

• NNR成功率が上がらない

  • 3方式の到達性を方式別に切り分け。RDP カスタムポートの非対応に注意。

  • DNS 逆引きゾーンの欠落／分割脳（サブネット新設時のPTR忘れ）を潰す。

• クラウド未到達／ヘルスが赤

  • *.atp.azure.com:443 の SSL検査バイパス／プロキシ認証の例外化／pingテストを定例化。

• イベント欠測

  • 監査ポリシーの適用範囲（リンクの優先度／継承ブロック）と収集経路を確認。

  • スタンドアロンのみ構成はETW欠落が出る。可能ならDC常駐を増やす。

• Honeytoken が業務で使われた（あるある事故）

  • ルール：**“誰も使わない”**を教育し、資格情報は金庫。

  • 名寄せでジョブ／スクリプトの参照を強制排除。使われたら即再生成。

• 除外が増え続ける

  • まずAlert Tuning、全体除外は“最後”。

  • 除外には期限・理由・承認・失効の四点セット。月次棚卸で負債を減らす。

10. ミニ FAQ（導入現場でよく出る質問）

Q. RDP を閉じたいのに、3389/TCP を開けろというのは矛盾では？A. RDP“接続”を許す必要はありません。初回ハンドシェイクのみを MDI が参照します。FW でセンサーIP に対してのみ 3389/TCP を許可し、ユーザーからのRDPは引き続きポリシーで禁止にできます。

Q. スタンドアロンセンサーは本当にダメ？A. “ダメ”ではありませんが、ETWが無い分カバレッジが落ちるのは事実。運用簡素・配線制約などの理由がなければDC直載せが第一選択です。

Q. Honeytoken はどれくらい置くべき？A. 各フォレスト≥3が下限。クラウンジュエルの近傍 OU に1、各ドメインに1。攻撃面の広さや拠点数で密度を上げるほど早期検知の質が上がります。

Q. NNR成功率の閾値 98% に根拠は？A. 組織規模やネットワーク構造で最適点は揺れますが、95% を割り込むと可観測性が急落し、誤検知・調査コストが跳ね上がるのが実感則。98% を目標に据えると運用が安定します。

11. 付録：運用テンプレ（そのまま使える）

11-1. 日次点検（10分）

• センサー重大ヘルス=0

• 未調査アラート（High/Medium）= 0

• 当日の Honeytoken イベント= 0

• 前日からの NNR 成功率グラフの落ち込み無し

11-2. 週次点検（30分）

• 方式別 NNR 成功率の比較（135/137/3389/PTR）

• イベント欠測の空白時間（DC/AD FS/AD CS/同期）= 0

• 誤検知トップ5 のチューニング進捗（期限付き）

11-3. 月次レビュー（60分）

• Honeytoken 配置密度／検知テストの結果

• 例外台帳（期限切れ=0）／サプレッションの過剰累積なし

• 監査パックの10分提示演習（ランダム質問で実施）

12. まとめ：数字で“回す”、証跡で“語る”

• NNR ≥ 98%／3方式＋PTRで解像度を担保。

• クラウド到達はTLS中間解除なし、ヘルス=0を日次で維持。

• イベントは欠測ゼロ。DC/AD FS/AD CS/同期の字幕を重ね、偽陽性を削る。

• Sensitive で“何が大事か”を宣言、Honeytoken で侵入を尖鋭に検知。

• 誤検知は Alert Tuning → 期限付き例外の順序で静かで鋭いアラートへ。

• KPI（NNR≥98%、重大ヘルス=0、未調査>24h=0、Honeytoken発火=0）をダッシュボードと証跡棚で回す。