Microsoft Defender for Identity の「What’s new」でまず押さえるべき結論は、2026年5月の更新が 検知範囲の拡大 と センサー運用の大規模化 に直結する内容だという点です。特に、ワークスペースあたりのセンサー上限が従来の350個から1,000個へ拡大し、Entra ID 関連の新しいセキュリティアラートが追加されました。大規模な Active Directory 環境や、Entra ID とオンプレミス AD を併用している組織では、単なる新機能紹介として読むのではなく、監視設計・アラート運用・センサー移行計画を見直すきっかけにするべき更新です。(Microsoft Learn)
Microsoft Learn の「Microsoft Defender for Identity の新機能」は頻繁に更新されるページで、機能は顧客テナントへ段階的に展開されます。つまり、公式ページに記載があっても自社テナントですぐ表示されるとは限りません。管理者は「まだ見えない＝未契約・設定ミス」と早合点せず、展開状況、ライセンス、センサー構成、RBAC 権限を切り分けて確認することが重要です。(Microsoft Learn)
Microsoft Defenderのセキュリティ更新、管理者が確認すべき影響範囲と対応ポイント
2026年5月時点の Microsoft Defender for Identity の更新で、管理者が優先して確認すべきポイントは次の3つです。
| 確認ポイント | 何が変わったか | まず取るべき対応 |
|---|---|---|
| センサー容量 | ワークスペースあたり最大1,000センサーに拡大 | 現在のセンサー数、ワークスペース分割方針、将来の増設計画を確認 |
| Entra ID 関連アラート | セッション Cookie、条件付きアクセス、MFA 方法追加などに関する検知が追加 | SOC の一次対応手順、SIEM 連携、通知ルールを見直す |
| センサー v3.x 運用 | v2.x から v3.x への移行、Windows イベント監査、RPC 監査が重要に | 移行前提条件、監査設定、gMSA 利用有無を棚卸しする |
この更新は「新しい画面が増えた」というより、ID 攻撃を検知するための土台が広がったと見るべきです。特に、侵害されたセッション Cookie、条件付きアクセスの回避、不審な MFA 追加は、従来のパスワード漏えい対策だけでは見落としやすい領域です。Entra ID のサインインログ、Defender XDR のインシデント、Defender for Identity のアラートを別々に見ている組織では、運用フローの分断が検知遅れにつながります。
2026年5月の主な変更点
センサー上限がワークスペースあたり1,000個に拡大
2026年5月の更新では、Defender for Identity がワークスペースあたり最大1,000個のセンサーをサポートするようになりました。従来の上限は350個だったため、大規模企業、複数拠点を持つ組織、M&A により Active Directory 環境が複雑化している組織にとって影響が大きい変更です。1,000個を超えて追加する場合は、Defender for Identity サポートへの問い合わせが必要です。(Microsoft Learn)
ただし、上限拡大は「無計画にセンサーを増やしてよい」という意味ではありません。センサー数が増えるほど、障害時の切り分け、バージョン管理、監査設定の一貫性、アラート件数の増加が運用負荷になります。まずは Microsoft Defender ポータルでセンサー一覧を確認し、次の観点で整理しましょう。
| 確認項目 | 判断基準 |
|---|---|
| センサー数 | 350個に近い、または超える見込みがあるか |
| ドメイン構成 | フォレスト、ドメイン、拠点単位で監視範囲が整理されているか |
| センサー状態 | 正常性アラートが放置されていないか |
| バージョン | v2.x と v3.x が混在している場合、移行計画があるか |
| 運用体制 | センサー増加に伴うアラート対応者、保守担当者が明確か |
特に、センサー数の上限だけを見てワークスペース統合を進めるのは危険です。監視責任、管理権限、ログの取り扱い、子会社・海外拠点との分掌が曖昧な場合は、技術的に統合できても運用上の責任分界でつまずきます。
Entra ID関連の新しいセキュリティアラートが追加
2026年5月の更新では、Entra ID に関連する新しい Defender for Identity セキュリティアラートが追加されています。公式情報では、資格情報の不正使用試行、ランダム化されたユーザーエージェントからの悪意あるサインイン、盗まれたセッション Cookie の可能性や再生検出、非準拠デバイス経由の条件付きアクセスバイパスの疑い、サードパーティ MFA 方法の疑わしい追加が挙げられています。(Microsoft Learn)
管理者が注意すべきなのは、これらのアラートが「ID 侵害後の横展開」だけでなく、「認証のすり抜け」や「正規ユーザーに見える不正利用」に関係する点です。たとえば、パスワードリセットだけで完了していた従来の対応では、盗まれたセッション Cookie や MFA 方法の不正追加に十分対応できない可能性があります。
運用上は、次のように対応レベルを決めておくと実務で使いやすくなります。
| アラートの種類 | 想定されるリスク | 推奨される初動 |
|---|---|---|
| 盗まれたセッション Cookie 関連 | 正規認証後のセッション悪用 | セッション失効、該当ユーザーのサインイン履歴確認、端末調査 |
| 条件付きアクセス回避の疑い | 非準拠デバイスからのアクセス | 条件付きアクセスポリシー、デバイス準拠状態、例外設定の確認 |
| サードパーティ MFA 方法の追加 | 攻撃者による認証手段の乗っ取り | MFA 方法の棚卸し、ユーザーへの確認、認証情報のリセット |
| ランダム化されたユーザーエージェント | 自動化ツールや不審クライアントの利用 | IP、端末、アプリ、ユーザーエージェントの相関分析 |
アラート追加後にありがちな失敗は、重大度だけで通知ルールを作ることです。ID 系のアラートは、単独では低く見えても、サインイン元、端末状態、権限、直近の管理操作と組み合わせると優先度が大きく変わります。特権ユーザー、管理者ロールを持つアカウント、サービスアカウントは、通常ユーザーとは別の対応基準を用意しましょう。
直近の関連更新もあわせて確認すべき理由
2026年5月の更新だけを見ると、センサー容量と新規アラートが中心に見えます。しかし、実際の管理では2026年3月から4月の更新もあわせて確認する必要があります。理由は、センサー v3.x、Windows イベント監査、Identity Security 関連機能が連続して強化されているためです。
2026年4月には、Microsoft Sentinel Data Lake ライセンスを持つ顧客向けに Identity Explorer プレビューが追加され、ID 攻撃パスや露出シナリオをグラフで可視化できるようになりました。また、カスタムアカウント相関ルールにより、命名規則の異なる特権アカウントなどを同じ ID に関連付けられるようになっています。センサー v3.x の Windows イベント監査の自動構成も一般提供されています。(Microsoft Learn)
2026年3月には、Microsoft Entra Connect を実行するドメインコントローラーで Defender for Identity センサー v3.x がサポートされ、Microsoft Defender ポータルから v2.x センサーを v3.x へ直接移行できるようになりました。対象サーバーは「移行の準備完了」と表示され、移行中も v2.x センサーが稼働し続けるため、通常は監視を中断せずに進められます。(Microsoft Learn)
この流れから見ると、Microsoft Defender for Identity は、単なるオンプレミス Active Directory 監視ツールではなく、Entra ID、SaaS、非人間 ID、条件付きアクセス、ID リスクを含む統合的な ID セキュリティ基盤へ寄っていると考えられます。管理者は「AD のセンサー管理」だけでなく、「ID 全体の攻撃面管理」として運用を見直す必要があります。
センサー v3.x 移行で確認すべき前提条件
Defender for Identity センサー v3.x を使うには、いくつかの前提条件があります。公式ドキュメントでは、v3.x センサーは VPN 統合と syslog 通知をサポートせず、Azure ExpressRoute での利用にも制限があると説明されています。また、サーバー要件として Microsoft Defender for Endpoint の展開、既存の v2.x センサーが未展開であること、Windows Server 2019 以降、2026年3月以降の累積更新プログラムが必要とされています。(Microsoft Learn)
移行ページでは、v2.x から v3.x へ直接移行する場合の前提条件として、追加の ID ロールを持たないドメインコントローラー、Defender for Identity センサー v2.x バージョン 2.254.19112.470 以降、Windows Server 2019 以降、Microsoft Defender for Endpoint の展開、2026年3月以降の累積更新プログラムが挙げられています。(Microsoft Learn)
ここで混同しやすいのが、「v3.x センサーがサポートするサーバー」と「ポータル移行の対象条件」は同じではない点です。v3.x センサー自体は、AD FS、AD CS、Microsoft Entra Connect の ID ロールを持つドメインコントローラーもサポート対象として説明されています。一方で、ポータルからの移行条件では「追加の ID ロールを持たないドメインコントローラー」が示されています。移行計画を立てる際は、サーバーの役割ごとに手順を分けて確認しましょう。(Microsoft Learn)
移行前チェックリスト
| チェック項目 | 確認内容 |
|---|---|
| OS | Windows Server 2019 以降か |
| 更新プログラム | 2026年3月以降の累積更新プログラムが適用済みか |
| Defender for Endpoint | 対象サーバーに展開済みか |
| 既存センサー | v2.x のバージョンが移行条件を満たすか |
| サーバーロール | AD FS、AD CS、Entra Connect など追加ロールの有無 |
| 通信要件 | Defender for Endpoint と同じ URI への接続が許可されているか |
| メモリ・仮想化 | VM の動的メモリやメモリ予約設定に問題がないか |
| gMSA | v2.x で利用していた gMSA を残していないか |
移行は Microsoft Defender ポータルの「Settings > Identities > On-premises > Sensors」から、移行準備完了のサーバーを選択して実行します。通常、移行には最大20分かかり、その間 v2.x センサーは v3.x センサーの準備が整うまで稼働し続けます。移行後は v2.x センサーサービスが無効になりますが、ソフトウェアは残るため、不要な v2.x センサーと Npcap の削除も運用手順に入れておきましょう。(Microsoft Learn)
Windowsイベント監査とRPC監査は後回しにしない
Defender for Identity は、特定のアクティビティを検出するために Windows イベントログを使用します。このデータは検出シナリオだけでなく、高度なハンティングクエリにも使われます。監査構成が不適切な場合、Defender for Identity は正常性アラートを生成します。(Microsoft Learn)
センサー v3.x を使うドメインコントローラーでは、Windows イベントの自動監査がサポートされています。自動監査は、現在の監査構成を確認し、構成ギャップを識別し、必要な変更を適用し、構成状態に関する正常性アラートを送信します。処理は24時間に1回実行されます。(Microsoft Learn)
有効化は、Microsoft Defender ポータルで「設定」から「ID」に進み、「高度な機能」で「Windows の自動監査構成」をオンにします。自動監査を有効にしない場合は、手動または PowerShell で Windows イベント監査を構成する必要があります。なお、GPO の設定がセンサーによるローカル設定と競合する可能性があるため、既存の監査ポリシーを持つ環境では事前確認が欠かせません。(Microsoft Learn)
RPC 監査も重要です。統合センサー RPC 監査タグをデバイスに適用すると、セキュリティの可視性が向上し、より多くの ID 検出を利用できるようになります。ルール条件に一致する既存および将来のデバイスへ構成が適用され、ルールが有効になるまで最大1時間かかる場合があります。(Microsoft Learn)
実務では、Windows イベント監査と RPC 監査を「移行後に落ち着いたら設定する」扱いにしないことが大切です。センサーが動いていても、監査が不足していれば検知カバレッジは限定されます。v3.x 移行の作業計画には、センサー移行、監査設定、正常性アラート確認、検知テストまでを1セットで入れてください。
SOCと運用チームが見直すべきアラート対応
新しい Defender for Identity セキュリティアラートが追加されると、SOC の現場では通知件数、分類ルール、一次切り分けの手順に影響します。特に Entra ID 関連アラートは、オンプレミス AD のイベントだけでは判断できないことが多く、Defender XDR、Entra ID サインインログ、条件付きアクセスポリシー、端末の準拠状態を横断して確認する必要があります。
見直すべき運用項目は次のとおりです。
| 運用項目 | 見直し内容 |
|---|---|
| インシデント分類 | セッション Cookie、MFA、条件付きアクセス回避を別カテゴリとして扱う |
| 通知ルール | 特権ユーザー、管理者、サービスアカウントは優先通知にする |
| チケット起票 | 新アラート名が既存ルールから漏れないよう分類条件を更新する |
| SIEM連携 | アラート名、重大度、ユーザー、端末、IP、アプリ情報を連携対象にする |
| プレイブック | セッション失効、MFA 方法確認、パスワードリセット、端末隔離の順序を定義する |
よくある失敗は、「新アラートをすべて高優先度にする」ことです。最初は安全側に倒す判断もありますが、アラート疲れが起きると本当に危険な兆候を見逃します。導入初期は2〜4週間ほど検知傾向を観察し、特権アカウント、外部公開アプリ、非準拠デバイス、未知の国や地域からのアクセスなど、組織にとって危険度の高い条件を組み合わせて優先度を調整すると実用的です。
開発者・自動化担当が確認すべきポイント
開発者や自動化担当者にとっても、今回の更新は無関係ではありません。アラート連携、Graph API、Advanced Hunting、チケットシステム連携を行っている場合、新しいアラート名や ID 関連テーブルの追加が既存の処理に影響する可能性があります。
2026年1月の更新では、Microsoft Defender の高度なハンティングに IdentityAccountInfo テーブルが追加され、Microsoft Entra ID など複数ソースのアカウント情報と、アカウントを所有する ID へのリンクが確認できるようになっています。2025年12月の更新では、Graph API の sensorCandidate リソース種別に domainName と senseClientVersion が追加され、API プレビュー版で利用できるとされています。(Microsoft Learn)
自動化で確認したいポイントは、次の3つです。
| 対象 | 確認内容 |
|---|---|
| アラート連携 | 新しいアラート名がフィルターや正規表現から漏れていないか |
| ハンティングクエリ | ID、アカウント、デバイス、サインイン情報を結合するクエリを更新するか |
| API利用 | プレビューAPIや追加プロパティに依存する処理を本番運用に直結させていないか |
特に注意したいのは、アラート名の文字列をハードコードしている処理です。Microsoft Defender 系のアラートは追加・名称変更・一般提供化が発生するため、固定文字列だけでルーティングすると新しい検知が運用から漏れる可能性があります。可能であれば、カテゴリ、サービスソース、エンティティ、MITRE ATT&CK の関連情報など、複数条件で分類する設計にしましょう。
失敗しやすいポイントと回避策
Microsoft Defender for Identity の更新対応で失敗しやすいのは、機能確認と運用確認を分けてしまうことです。管理画面で新機能が見えたとしても、検知に必要な監査設定、センサー正常性、権限、通知ルールが整っていなければ効果は限定的です。
| 失敗しやすいポイント | 起きる問題 | 回避策 |
|---|---|---|
| 公式ページの記載だけで利用可能と判断する | 自社テナントで機能が見えず混乱する | 段階的展開であることを前提に、テナント表示とライセンスを確認 |
| v3.x 移行だけを実施する | 監査不足で検知カバレッジが不足する | Windows イベント監査と RPC 監査を同時に確認 |
| gMSA 設定を残す | 応答アクションが機能しない | v3.x ではローカルシステム ID 利用を前提に構成を見直す |
| セキュリティスコアの変化を脆弱化と誤解する | 不要な調査や説明対応が増える | カテゴリ再分類によるスコア変動かを確認 |
| 新アラートを運用に組み込まない | 重要な ID 侵害の兆候を見落とす | SOC プレイブックと通知条件を更新する |
2026年4月の更新では、一部のセキュリティ推奨事項が Cloud apps ではなく Identity カテゴリに分類されるようになり、合計の Secure Score は変わらないものの、個別の ID やアプリのスコアが変わる可能性があると説明されています。スコア変化を見たときは、実際のリスク増加なのか、分類変更による見え方の変化なのかを切り分けましょう。(Microsoft Learn)
まず実施すべき対応手順
最後に、管理者が実際に進める順番を整理します。
| 優先度 | 対応 | 目的 |
|---|---|---|
| 高 | センサー数と正常性アラートを確認 | 上限拡大の恩恵を受けられる環境か把握する |
| 高 | 新しい Entra ID 関連アラートを SOC 手順に追加 | Cookie 盗用、MFA 不正追加、条件付きアクセス回避に備える |
| 高 | v3.x 移行対象サーバーを棚卸し | OS、累積更新、Defender for Endpoint、サーバーロールを確認 |
| 中 | Windows イベント監査の自動構成を検討 | 検知に必要な監査設定の抜け漏れを減らす |
| 中 | RPC 監査タグの適用範囲を決める | 高度な ID 検出に必要な可視性を確保する |
| 中 | SIEM・チケット連携ルールを更新 | 新アラートを運用から漏らさない |
| 低 | Secure Score のカテゴリ変化を関係者に共有 | スコア変動の誤解を防ぐ |
今回の Microsoft Defender for Identity の更新は、単体の新機能追加ではなく、ID を中心にした検知・調査・対応を強化する流れの一部です。まずはセンサー数、v3.x 移行条件、Windows イベント監査、RPC 監査、新アラートの運用反映を確認しましょう。そのうえで、特権アカウントや非人間 ID を含めた ID セキュリティ全体の棚卸しに進むと、更新内容を実際の防御力向上につなげやすくなります。
コメント