オンプレミスIDを保護するための ITDR と Microsoft Defender for Identity（MDI）徹底解説

どうも、株式会社ソフトクリエイト で情報屋やってます。山口です。
普段は企業様向けに Microsoft 365 活用のご支援をおこなっています。

突然ですが、サイバー攻撃って「壁をぶち破って入ってくる」みたいなイメージ、ありません？ …実はもう、そういう時代じゃなかったりするんです(^^;
いまの攻撃者は 「盗んだ ID で普通にログインしてくる」 んですよね。 しかも正規のアカウントを使っているので、見た目上は"ただのログイン"にしか見えない。ファイアウォールもすり抜けるし、EDR でもなかなか引っかからない。「いやいや、不正アクセスって検知できるもんじゃないの？」って思うかもしれませんが、正規アカウントで入ってこられると、本人と攻撃者の区別をつけるのが めちゃくちゃ難しい んです。

そこで ITDR（Identity Threat Detection and Response） という考え方と、それを実現する Microsoft Defender for Identity（MDI） というサービスです。(^^

Microsoft 365
使いこなせてますか？

ソフクリ365倶楽部では、記事では語りきれない深掘り情報や実践ノウハウを発信中！

本記事の執筆者・山口が発信する最新情報をお届けします。 詳しくはこちら ソフクリ365倶楽部について ＞

オンプレミスIDを保護するための ITDR と Microsoft Defender for Identity（MDI）徹底解説

■ ITDR とは？まず "ID を狙う攻撃" の全体像を押さえよう!

ITDR（Identity Threat Detection and Response）とは、ユーザーやサービスアカウントなどの ID に対する脅威 を「検知 → 調査 → 対応」するためのセキュリティフレームワークです。
「EDR」や「XDR」はよく耳にするかもしれませんが、ITDR は ID に特化したバージョン みたいなイメージですね(^^

いずれも共通しているのは 「正規 ID を悪用する攻撃」 が中心だということ。攻撃者は自分で新しいアカウントを作るのではなく、すでにある誰かの ID をこっそり使ってくるわけです。

■ なぜ ITDR が重要なのか ? ID が "新しいセキュリティ境界" になった話

最近のサイバー攻撃にはこんな傾向があります。

1. 攻撃者は「侵入」ではなく「ログイン」を狙う → フィッシングやパスワードスプレーで正規の資格情報を手に入れて、"堂々と"ログインしてくるパターンが主流です。
2. 正規アカウントを使うため検知がものすごく難しい → 正規ユーザーと攻撃者の動きの区別が、ログ上からは見分けにくいんです。
3. 従来の防御（ファイアウォール / EDR）では見逃されやすい → ネットワーク境界を突破する攻撃を前提にしたツールは、"正面玄関から入ってくる人"を止めるのが苦手です。

つまり、 ID こそが "新しいセキュリティ境界" になっているということです(^^;

「それって IAM とか EDR でなんとかならないの？」と思いますよね。残念ながら、それぞれに得意・不得意があるんです。

IAM は「正しい人にアクセスを許可する」仕組みですが、 「侵害された後」を検知する力はほとんどありません。
ここを埋めるのが ITDR の役割です。EDR が端末のセキュリティ特化なのと同じように、ITDR は "ID のセキュリティ"に全振りしたフレームワーク ですね(^^

■ MDI とは？ - オンプレ AD を守るクラウドの目

ここからが本題です。Microsoft Defender for Identity（MDI） は、オンプレミスおよびハイブリッド環境の ID 関連攻撃を検出・調査・対応 するクラウドサービスです。

MDI は以下のような流れで動きます。

① ドメインコントローラーにセンサーを配置
↓
② センサーが以下の情報を収集
・認証ログ（Kerberos / NTLM）
・Windows イベント
・ネットワークトラフィック
↓
③ クラウド（Defender ポータル）で分析
・振る舞い分析（ベースライン比較）
・脅威インテリジェンス
・シグナル相関
↓
④ 異常を検知したらアラート＆対応

MDI は、DC にセンサーに配置することで、ID の脅威を検知→分析→対応まで対応し、ITDR の考え方に即した動作で脅威に対応します。

■ MDI の特徴とメリット :センサー設置から始まる高度分析

MDI の大きな強みをざっくり 3 つです。
• ID ベースの攻撃検知 :特権昇格、横移動、Pass-the-Hash、Golden Ticket など、AD を狙ったさまざまな攻撃を検出できます。
• 行動分析（UEBA）ベースの検知 :「このユーザーの普段の行動パターン」を学習して、いつもと違う動き を異常として検知します。
• Microsoft Defender XDR との統合 : MDI 単体ではなく、MDE（Endpoint）・MDO（Office 365）などを関連付けて横断的に相関分析 できます。

■ 必要ライセンス

契約上は、1ライセンスからのご契約が可能ですが、製品を決定し、運用いただく場合には、組織内で利用するユーザー(Entra ID)分のライセンスの契約とユーザー割り当てが必要です。

MDI はテナントレベルで有効化されるサービスで、特定ユーザーだけに機能メリットを厳密に制限できない種類のテナントサービスです。
そのため、ライセンス設計では「監視・保護の恩恵を受けるユーザー」に対して適切にライセンスを割り当てる必要があります。

・MDI はクラウドのユーザーライセンスであり、割り当て先は Entra ID 上のユーザーです。
・オンプレミス AD のみのアカウントへ直接割り当てることはできません。

■ MDI センサーのインストール対象 :どこに入れるべき？

MDI センサーは 原則としてすべてのドメインコントローラーに導入 します。
• すべてのドメインコントローラー（DC）
• RODC（読み取り専用 DC）も含む
「メインの DC だけ入れればいいかな？」と思いがちですが、攻撃者は RODC 経由でも活動する可能性があるので、漏れなく全 DC が対象になります。(^^;

また、以下のサーバーもセンサーとして追加 できます。
• AD FS（Active Directory Federation Services） : フェデレーション認証を使っている場合
• AD CS（Active Directory Certificate Services） : 証明書サービスを使っている場合
• Microsoft Entra Connect : オンプレ AD とクラウドの同期サーバー
※ v3.x センサーは DC 上にインストールする前提です。
※ AD FS / AD CS / Entra Connect といった ID ロールを持つ DC にも対応しています。※ ただし、DC ではないサーバーで AD FS、AD CS、または Entra Connect を実行している場合は、v2.x センサーを使用します。

■ センサー導入先のスペック要件 ── 事前確認を忘れずに

センサーを入れる先のサーバーが、最低限以下のスペックを満たしているか確認する必要があります。

ネットワーク要件
• HTTPS（TCP 443） でのクラウド通信が必須
• DNS / RPC / SMB などの内部通信が必要
⚠️ 注意： 通信が未許可だと 検知精度が低下 します。特にプロキシ環境では、事前にエンドポイント URL のホワイトリスト設定をしっかり確認してください。

スペック表を見て「大丈夫そう」と思っても、実際のトラフィック量によってはリソース不足になるケース があります。
Microsoft が提供している容量計画ツール（Sizing Tool）を使えば、DC サーバーが MDI センサーに十分なリソースを持っているかどうかを判定できます。

■ MDES（Defender for Endpoint Server）のオンボード

「オンボード」というのは、デバイスを Microsoft Defender for Endpoint Server（MDES）に登録して、セキュリティテレメトリ（端末のセキュリティ情報）をクラウドに送信できるようにする作業です。
※ クライアント版は、MDE です。MDE のサーバー版は、Microsoft Defender for Endpoint Server（MDES） ですが、Defender 管理センター等で一括管理できる点は、同じです。
異なるのは、ライセンスとオンボード方法です(^^;

なぜ v3 センサーに MDE オンボードが必要なのか?
v3 センサーは v2 のようなスタンドアロンのエージェントではありません 。MDE（SENSE サービス）の 上で動作する統合コンポーネント です。
つまり、MDES がベースにあって、その上に MDI の機能が載る イメージです。MDES なしに v3 は動かないということですね。

必須条件
v3 センサーを有効化するには、以下が必要です。
• サーバーが MDE へオンボード済み であること
• Microsoft Defender Antivirus（Defender AV）が有効 であること（Active モードでも Passive モードでも OKです。）

◆ MDES のオンボード手順

Microsoft Defender 管理センターにアクセスします。
https://security.microsoft.com/

[設定] → [エンドポイント] に移動します。

図1-1　Defender ポータルでのオンボード手順

「オンボーディング」に移動し、OS を選択（Windows Server 2019/2022 など)します。

図1-2　オンボード手順（続き）

「オンボード パッケージのダウンロード」をクリックします。

図1-3　オンボード手順（続き）

対象サーバー(DC等)で 管理者権限でスクリプトを実行します。

図1-4　オンボード用スクリプトの取得

“Press (Y) to confirm and continue or (N) to cancel and exit: Y” のメッセージが表示されたら、「Y」キー →「Enter」キーを押して有効化を開始します。

図1-5　「Y」→「Enter」で有効化を開始

“Successfully onboarded machine to Microsoft Defender for Endpoint” のメッセージが表示されたら、「Enter」キーを押します。

図1-6　オンボード完了（Successfully onboarded）

スクリプト実行後、Defender 管理センターの [デバイス のインベントリ]画面 に対象サーバーが表示されれば、オンボード成功です(^^

図1-7　オンボード後の確認画面

■ MDI センサー v3 のインストール : MDES の上に MDI を有効化する

「v2 と v3 って何が違うの？」という疑問は当然ですよね。ざっくりまとめるとこうなります。

v3.x センサーはローカル システム ID を使用して動作し、Directory Service Accounts（DSA）やグループ管理サービスアカウント（gMSA）を使用しません。
v2 ではサービスアカウントの管理等を含めた設定が面倒だったんですが、v3 では LocalSystem で自動的に処理してくれる ので導入がかなり楽になります(^^

v3.x センサーを有効化する前に、以下を確認してください。
・Defender for Endpoint Server がサーバーにオンボードされていること
・Defender for Identity v2.x センサーがまだインストールされていないこと
・Windows Server 2019 以降を実行していること、2026 年 3 月以降の累積更新プログラムが含まれていること
⚠️ 注意： v3.x は VPN 統合をサポートしていません。また、syslog 通知もサポートしておらず、Azure ExpressRoute には制限があります。

◆ MDI センサーのインストール手順（v3）

v2 と違って、v3 は インストーラーをダウンロードして実行する…という手順ではありません。Defender 管理センターから"有効化"するだけ、というのが大きな特徴です(^^

Microsoft Defender 管理センターにアクセスします。
https://security.microsoft.com/

[設定] → [ID] に移動します。

図2-1　Defender管理センターの「ID」にアクセス

「オンプレミス」→「アクティブ化」をクリックします。

図2-2　v3 センサーのインストール手順

MDI センサーを有効化する DC サーバーを選択し、「+アクティブ化」をクリックします。

図2-3　v3 センサーのインストール手順（続き）

「アクティブ化」をクリックします。

図2-4　v3 センサーのインストール手順（続き）

「サーバーが正常にアクティブ化されました」のメッセージを確認します。

図2-5　v3 センサーのインストール手順（続き）

「センサー」タブをクリックし、対象のサーバーが表示されるかを確認します。

図2-6　v3 センサーのインストール手順（続き）

v3 インストール後に確認しておきたいこと
v3 センサーを有効化したら、以下のポイントもチェックしておきましょう(^^
• センサーのステータス確認: Defender ポータルのセンサー一覧で「正常」と表示されているか
• テレメトリの送信確認: MDE 経由でクラウドにデータが正常に送信されているか

v3 センサーは主に Windows イベントとイベント トレーシングに依存するため、ネットワークプロセスが中心だった v2 と比べてリソース要件が大幅に軽減されており、MDES の利用前提なら、簡単に導入が可能です。ただし、ご利用の環境に応じては、サーバーのリソースの余裕がない状態になっている可能性もあるため、サーバーのパフォーマンスの推移を定期的に確認して、環境における必要スペックを見極めましょう(^^

図2-7　v3 センサーのインストール完了

■ まとめ

ID が新しいセキュリティ境界となった今、正規アカウントの悪用を見抜く ITDR は欠かせない仕組みです。MDI は、ドメインコントローラーにセンサーを置くだけで、その ITDR をクラウド側の高度な分析とともに実現します。

• 原則としてすべての DC（RODC 含む）が対象。AD FS / AD CS / Entra Connect は条件付きで追加
• 導入先のスペック（CPU 2 コア・メモリ 6GB・ディスク 6GB 以上）と TCP 443 の通信を事前に確認
• 容量計画ツールを必ず実行してから設計する
• v3 センサーは MDES 上で動くため、まず MDES へのオンボードが前提
• v3 は Windows Server 2019 以上・CU 適用済み・v2 未導入が条件
• Windows Server 2016 以前や DC 以外については、v2版のインストールが必要。v3と比較すると必要な対応が多くなる。

ID を狙った攻撃は今後ますます増えていくと思います。 「うちはまだ大丈夫でしょ」と思っているうちに、攻撃者は組織内の利用アカウントにログインしてきている かもしれません。
このような攻撃について、MDI と ITDR で、"見えない攻撃"を見えるように していきましょう(^^