Microsoft Defender for Identity の「Overview」更新ポイントで最も重要なのは、Defender for Identity が単なるオンプレミス Active Directory 監視ではなく、Microsoft Entra ID、外部 IAM、非人間 ID まで含めた「ID 脅威検出・調査・対応」の中核として整理されている点です。管理者は、センサー構成、Microsoft Defender ポータルでの統合インシデント運用、Microsoft Secure Score の推奨事項、センサー v3.x への移行可否を優先して確認する必要があります。なお、指定された Overview ページは Microsoft Learn 上では 2026 年 2 月更新として表示され、2026 年 6 月の変更点は Defender for Identity の新機能ページ側で確認できます。公開日・更新日の扱いは、社内周知や監査資料では必ず公式ページの表示日とあわせて確認してください。(Microsoft Learn)
Microsoft Defender for Identity Overview の更新ポイント
Microsoft Defender for Identity は、オンプレミス、クラウド、ハイブリッド環境にまたがる ID ベースの攻撃を検出、調査、対応するためのサービスです。攻撃者がユーザー、アプリケーション、サービスアカウントなどの ID を悪用し、アクセス権の取得、特権昇格、横移動、永続化を狙う前提で設計されています。(Microsoft Learn)
今回確認すべきポイントは、Defender for Identity の説明が「Active Directory 向けの検知ツール」から、「Microsoft Defender ポータル上で ID シグナルを統合し、Microsoft Defender XDR のインシデント対応につなげる仕組み」として明確化されていることです。オンプレミス AD だけを見ていればよい時代ではなく、Entra ID、Okta などの IAM、サービスプリンシパル、同期アカウント、アプリケーション ID まで含めて監視範囲を整理する必要があります。(Microsoft Learn)
影響範囲：オンプレ AD 管理者だけでなく、Entra ID・SOC・運用チームも対象
Microsoft Defender for Identity の影響範囲は、ドメインコントローラーを管理するインフラ担当者だけにとどまりません。アラートや調査情報は Microsoft Defender ポータルに集約され、エンドポイント、メール、SaaS アプリ、クラウドワークロードなどのシグナルと相関されます。そのため、SOC、Entra ID 管理者、M365 セキュリティ管理者、インシデント対応担当者が同じ前提で運用ルールをそろえることが重要です。(Microsoft Learn)
| 確認対象 | 主な影響 | 管理者が確認すべきこと |
|---|---|---|
| Active Directory | 認証、権限変更、横移動、ドメイン侵害の兆候を検出 | すべてのドメインコントローラーに適切なセンサーが導入されているか |
| Microsoft Entra ID | 特権ロール、危険なサインイン、クラウド ID の挙動を監視 | グローバル管理者やアプリ管理者など高権限 ID の棚卸し |
| 非人間 ID | サービスアカウント、同期アカウント、アプリケーション、サービスプリンシパルを監視 | 未使用・過剰権限・外部公開された ID の有無 |
| Microsoft Defender ポータル | ID アラートを統合インシデントとして調査・対応 | SOC のトリアージ手順と通知ルール |
| Microsoft Secure Score | ID セキュリティ体制の推奨事項を確認 | 推奨事項を例外処理せず、改善タスクとして管理 |
特にグローバル環境では、国やリージョンごとに Active Directory ドメイン、Entra ID テナント、SaaS 利用状況、外部 IAM の導入状況が異なることがあります。Defender for Identity を導入済みでも、買収企業の AD、検証用ドメイン、旧認証基盤、放置されたサービスアカウントが監視対象から漏れると、攻撃経路として残ります。
機能面で押さえるべきポイント
Defender for Identity の主要機能は、ID セキュリティ体制の評価、リアルタイム脅威検出、疑わしいアクティビティの調査、侵害された ID に対する修復アクションです。これは「検知して終わり」ではなく、事前のリスク低減から、検知、調査、対応までをつなぐ設計です。(Microsoft Learn)
ID セキュリティ体制の評価
Defender for Identity は、攻撃者が悪用しやすい ID 構成の弱点を可視化し、Microsoft Secure Score を通じて ID セキュリティ体制の評価や推奨事項を提示します。たとえば、危険な構成、露出、横移動パスの分析は、侵害後の被害拡大を防ぐうえで重要です。(Microsoft Learn)
実務では、Secure Score の点数だけを追うのではなく、次のように優先順位を付けると運用しやすくなります。
| 優先度 | 対応すべきリスク例 | 判断基準 |
|---|---|---|
| 高 | ドメイン管理者、グローバル管理者、同期アカウントの危険な構成 | 侵害時に全社影響が出る |
| 中 | 古いサービスアカウント、未使用アプリ、過剰な権限 | 悪用されると横移動や永続化に使われる |
| 低 | 影響範囲が限定的な構成改善 | 他の高リスク対応後に計画的に処理 |
ID ベースの脅威検出
Defender for Identity は、単一イベントだけで判断するのではなく、行動分析、脅威インテリジェンス、既知の攻撃パターンを使って ID 攻撃ライフサイクル全体の不審な動きを検出します。監視対象には、認証と承認、資格情報の悪用、特権昇格、疑わしいロールやグループメンバーシップ変更、横移動、サービスアカウントなどの非人間 ID の異常動作が含まれます。(Microsoft Learn)
| 攻撃段階 | Defender for Identity で見たい兆候 | 管理者の初動 |
|---|---|---|
| 偵察 | ユーザー、グループ、IP、リソースの列挙 | 対象アカウントと実行元端末を確認 |
| 資格情報侵害 | ブルートフォース、失敗認証の増加、不審な権限変更 | サインイン履歴、MFA 状態、端末健全性を確認 |
| 横移動 | 複数サーバー・複数 ID への不自然なアクセス | 影響範囲を Defender ポータルで関連付けて確認 |
| AD ドメイン支配 | DCSync、DCShadow、Golden Ticket などの兆候 | ドメイン管理者、DC、Kerberos 関連ログを優先調査 |
この表で重要なのは、アラート名だけで判断しないことです。たとえば「失敗認証が多い」だけなら運用ミスの可能性もありますが、直後にグループ変更、特権ロール追加、別端末からの認証が続けば、侵害シナリオとして扱うべきです。
2026年6月時点であわせて確認したい新機能
2026 年 6 月の Defender for Identity 新機能では、ID リスクスコアの一般提供、新しいセキュリティアラート、非人間 ID インベントリの強化、AI エージェントが使用するサービスプリンシパルの可視化などが示されています。これらは Overview の「ID セキュリティを統合的に守る」という方向性を具体化する更新です。(Microsoft Learn)
ID リスクスコアは 0 から 100 の範囲で、ID の重要度や特権ロール割り当てをもとに、侵害される可能性と侵害時の影響を示します。管理者は、リスクスコアが高い ID を「監視対象」ではなく「改善対象」として扱い、不要な特権削除、条件付きアクセス強化、MFA の再確認、所有者確認を進めるべきです。(Microsoft Learn)
また、2026 年 6 月の新規アラートには、グローバル管理者昇格後の異常なアクティビティ、資格情報追加後の疑わしいサービスプリンシパルサインイン、DCSync 攻撃、疑わしい Entra Connect アカウント認証などが含まれます。これは、クラウド特権、オンプレ AD、同期基盤、非人間 ID をまたいだ攻撃検知が強化されていることを示します。(Microsoft Learn)
設定変更で確認すべきポイント
Overview そのものは機能説明が中心で、管理者に即時の設定変更を強制する内容ではありません。ただし、実運用ではセンサー、監査設定、権限、応答アクションの構成が検知品質に直結します。特にセンサー v3.x を利用する場合は、Microsoft Defender for Endpoint のオンボード、Windows Server 2019 以降、2026 年 3 月以降の累積更新プログラムなどの前提条件を確認する必要があります。(Microsoft Learn)
| 項目 | 確認内容 | 失敗しやすいポイント |
|---|---|---|
| センサー配置 | RODC を含むドメインコントローラーにセンサーを導入 | 一部の拠点 DC、検証用 DC、旧ドメインが漏れる |
| v3.x 前提条件 | Defender for Endpoint オンボード、OS、累積更新プログラム | Defender for Endpoint が入っているだけでオンボード済みと誤解する |
| 監査設定 | Windows イベント監査と RPC 監査 | 監査が不足し、高度な検出が有効に機能しない |
| サービスアカウント | v3.x は LocalSystem を使用 | v2.x 時代の gMSA 前提で応答アクションを設計してしまう |
| 通知・連携 | v3.x の VPN 統合、syslog 通知の制限 | 既存 SIEM 連携やネットワーク設計を見直さず移行する |
Defender for Identity センサー v3.x では、v2.x で使っていた DSA や gMSA ではなく LocalSystem が使われます。v2.x から移行した環境で gMSA が残っている場合、構成によっては応答アクションが期待どおり機能しない可能性があるため、移行後のアクションアカウント設定を必ず確認してください。(Microsoft Learn)
センサー v3.x 移行と期限の考え方
現時点で確認できる Overview ページからは、「特定日までに必ず移行しなければならない」という強制的な移行期限は読み取れません。一方で、公式のデプロイ情報では、Windows Server 2019 以降かつ 2026 年 3 月以降の累積更新プログラムを含むドメインコントローラーでは、センサー v3.x が推奨される構成として整理されています。(Microsoft Learn)
v2.x から v3.x への移行は Microsoft Defender ポータルから実行でき、条件を満たすサーバーは [センサー] ページで [移行の準備完了] と表示されます。移行中も v2.x センサーは v3.x の準備が整うまで動作し、通常は最大 20 分で完了すると説明されています。(Microsoft Learn)
ただし、Windows Server 2025 を実行しているドメインコントローラーの v2.x から v3.x への移行は、公式情報では現在サポートされていません。該当する環境では、無理に移行作業を進めず、v2.x の継続利用とサポート状況の確認を優先してください。(Microsoft Learn)
管理者が今すぐ確認すべきチェックリスト
まず行うべきことは、「Defender for Identity を有効にしているか」ではなく、「守るべき ID が正しく見えているか」を確認することです。特にグローバル企業や複数拠点の組織では、ドメイン、テナント、管理者ロール、サービスアカウントの棚卸しが不十分なまま運用されがちです。
| チェック項目 | 確認方法の例 | 優先度 |
|---|---|---|
| すべてのドメインコントローラーにセンサーがあるか | Microsoft Defender ポータルの Sensors 画面で確認 | 高 |
| Entra ID の高権限ロールが把握されているか | グローバル管理者、特権ロール管理者、アプリ管理者を棚卸し | 高 |
| 非人間 ID が可視化されているか | サービスプリンシパル、同期アカウント、サービスアカウントを確認 | 高 |
| Secure Score の ID 推奨事項を処理しているか | 推奨事項を運用チケット化 | 中 |
| SOC のアラート対応手順が更新されているか | 新規アラートをトリアージ基準に追加 | 中 |
| v3.x 移行対象と対象外を分けたか | OS、MDE、累積更新プログラム、ID ロールを確認 | 高 |
| 応答アクションが動作するか | テスト用アカウントで無効化・パスワードリセットの手順確認 | 中 |
このチェックリストを使うときは、単に「対応済み」と記録するのではなく、対象外にした理由を残すことが重要です。たとえば、Windows Server 2025 の制限、非ドメインコントローラー上の AD FS、レガシー OS、拠点閉鎖予定など、移行しない理由を明文化しておくと、監査や引き継ぎで混乱を防げます。
実務での活用シーン
Defender for Identity の価値が出やすいのは、インシデント発生後の「点の調査」を「線の調査」に変える場面です。たとえば、あるユーザーの不審なサインインだけを見るのではなく、そのユーザーがどのグループに追加されたか、どの端末から認証したか、どのサービスアカウントや管理者ロールに接近したかを Microsoft Defender ポータル上で追えるようになります。(Microsoft Learn)
また、非人間 ID の管理にも有効です。近年は AI エージェント、アプリ連携、自動化スクリプト、CI/CD、SaaS 連携により、人間が直接ログインしない ID が増えています。2026 年 6 月の新機能では、非人間 ID インベントリや AI エージェントが使用するサービスプリンシパルの可視化が強化されているため、セキュリティ担当者は「ユーザーアカウントだけを見る」運用から脱却する必要があります。(Microsoft Learn)
導入・運用で失敗しやすいポイント
よくある失敗は、Defender for Identity を導入しただけで ID セキュリティ対策が完了したと考えてしまうことです。センサーが一部のドメインコントローラーにしか入っていない、監査設定が不足している、Secure Score の推奨事項を見ていない、アラート対応が SOC の手順に組み込まれていない場合、検知できても初動が遅れます。
もう一つの失敗は、オンプレミス AD と Entra ID を別々のチームが管理し、アラート対応も分断されることです。攻撃者はオンプレミスとクラウドの境界を意識せず、同期アカウント、特権ロール、アプリ権限、サービスプリンシパルを横断的に狙います。Defender for Identity の Overview が示す方向性も、まさにこの横断的な ID 保護です。(Microsoft Learn)
まず取るべきアクション
管理者は、最初に Microsoft Defender ポータルで Defender for Identity のセンサー状態、アラート、ID インベントリ、Secure Score の推奨事項を確認してください。次に、v3.x へ移行できるドメインコントローラーと、現時点では v2.x を維持すべきサーバーを分けます。最後に、新しい ID リスクスコアや非人間 ID の情報を、インシデント対応手順と定期レビューに組み込みます。
Microsoft Defender for Identity の更新ポイントは、新しい画面やアラートを覚えることではありません。自社の ID がどこにあり、どの ID が危険で、侵害時にどこまで影響が広がるかを把握し、検知から対応までを Microsoft Defender ポータルでつなぐことです。まずは「全ドメインコントローラーのセンサー状態」「高権限 ID」「非人間 ID」「v3.x 移行可否」の 4 点から確認を始めると、実務に落とし込みやすくなります。
コメント