Microsoft Defender for Identity センサーの展開で最初に判断すべきことは、v3.xを使うサーバーと、v2.xを継続するサーバーを分けることです。2026年5月18日時点で確認した公式情報では、Windows Server 2019以降かつ2026年3月以降の累積更新プログラムを適用したドメインコントローラーではv3.xが推奨されます。一方、ドメインコントローラーではないAD FS、AD CS、Microsoft Entra Connectサーバーや、Windows Server 2016環境ではv2.xが引き続き対象です。導入前にOS、更新プログラム、Defender for Endpointのオンボード状態、監査設定、移行可否を確認しないと、「センサーを入れたのに検出が不十分」「移行ボタンが出ない」「対応アクションが動かない」といった問題につながります。(Microsoft Learn)
Microsoft Defender for Identity センサー展開の結論
Microsoft Defender for Identityは、オンプレミスのActive DirectoryやID基盤からシグナルを収集し、特権昇格、高リスクなラテラルムーブメント、危険なKerberos委任などのID脅威を検出するサービスです。センサーはその監視の入口であり、原則としてすべてのドメインコントローラー、RODCを含む監視対象サーバーに展開します。AD FS、AD CS、Microsoft Entra Connectを使っている環境では、それらがドメインコントローラー上で動いているか、専用サーバー上で動いているかによって選ぶセンサーが変わります。(Microsoft Learn)
実務上の結論は次のとおりです。
| サーバー構成 | OS・条件 | 推奨センサー | 管理者の判断ポイント |
|---|---|---|---|
| ドメインコントローラー | Windows Server 2019以降、2026年3月以降の累積更新プログラム適用済み | v3.x | Defender for Endpointのオンボードが必須 |
| AD FS、AD CS、Microsoft Entra Connectロールを兼ねるドメインコントローラー | Windows Server 2019以降、2026年3月以降の累積更新プログラム適用済み | v3.x | 新規展開ではv3.xを検討。ただし既存v2.xからの移行可否は別途確認 |
| ドメインコントローラー | Windows Server 2016以降 | v2.x | v3.x前提を満たさない場合はv2.x |
| ドメインコントローラーではないAD FSサーバー | Windows Server 2016以降 | v2.x | v3.xではなくv2.xを使う |
| ドメインコントローラーではないAD CSサーバー | Windows Server 2016以降 | v2.x | 証明機関ロールの監査設定も確認 |
| ドメインコントローラーではないMicrosoft Entra Connectサーバー | Windows Server 2016以降 | v2.x | アクティブ、ステージング双方の対象確認が必要 |
大事なのは、v3.xが登場したからといって、全サーバーを一律にv3.xへ置き換えるわけではない点です。Microsoft Defender for Identityはv2.xとv3.xの混在環境をサポートしており、たとえば新しいドメインコントローラーはv3.x、古いOSや非DCのID関連サーバーはv2.xという構成も可能です。(Microsoft Learn)
2026年5月時点の主な変更点
今回の展開情報で管理者が特に見るべき変更点は、v3.xセンサーを中心にした展開・移行の整理です。v3.xはDefender for Endpointと連携して動作するため、従来のv2.xセンサーを単体インストールする発想とは確認項目が変わります。
v3.xはドメインコントローラー向けの主軸になる
v3.xセンサーは、Windows Server 2019以降の対応ドメインコントローラーで利用します。条件として、2026年3月以降の累積更新プログラムが必要で、さらに対象サーバーがMicrosoft Defender for Endpointにオンボードされている必要があります。Defender for Endpointを「導入しただけ」では不十分で、センサーを動かすサーバー自体がオンボード済みであることが条件です。(Microsoft Learn)
この変更により、セキュリティ管理者はDefender for Identityだけでなく、Defender for Endpoint側のデバイス登録、SENSEサービス、ネットワーク到達性もセットで確認する必要があります。
AD FS、AD CS、Microsoft Entra Connectロールを持つDCもv3.x対象に入る
公式情報では、v3.xセンサーはドメインコントローラーに加え、AD FS、AD CS、Microsoft Entra Connectロールを兼ねるドメインコントローラーも対象に含めています。特に2026年3月の更新では、Microsoft Entra Connectロールを持つドメインコントローラーでv3.xサポートが拡張されています。(Microsoft Learn)
ただし、ここで混同しやすい点があります。非ドメインコントローラーのAD FS、AD CS、Microsoft Entra Connectサーバーはv2.x対象です。ロール名だけで判断せず、「そのサーバーがドメインコントローラーかどうか」を必ず確認してください。
v3.xには未対応・制限事項がある
v3.xは展開と管理を簡素化できる一方、すべての機能がv2.xと同じように使えるわけではありません。公式情報では、v3.xはVPN統合、syslog通知をサポートせず、Azure ExpressRoute利用時にも制限があるとされています。また、Windows Server 2025のドメインコントローラーについては、v2.xからv3.xへの移行が現時点でサポートされていません。(Microsoft Learn)
SIEM連携や既存のsyslog通知を運用に組み込んでいる組織では、v3.x化によって監視フローが変わる可能性があります。センサー更新をセキュリティ製品側の作業だけで完結させず、SOC、ネットワーク、AD運用担当者を含めて影響を確認しましょう。
拡張RPC監査とセンサー上限の変更も確認対象
2026年5月の新機能として、v3.xセンサー向けにExtended RPC auditing capabilitiesがプレビュー提供され、Advanced identity detections向けの可視性強化が進んでいます。また、Defender for Identityは1ワークスペースあたり最大1,000センサーまでサポートするようになったとされています。1,000を超える場合はサポートへの相談が必要です。(Microsoft Learn)
大規模なグローバルAD環境や、複数フォレストを持つ組織では、この上限変更により設計の自由度が上がります。ただし、センサー数が増えるほど監査設定、更新状態、ネットワーク許可、健全性アラートの管理も複雑になります。数を増やす前に、ワークスペース単位で運用責任と監視ルールを整理してください。
影響を受ける管理者と環境
今回の情報で特に影響を受けるのは、オンプレミスActive Directoryを運用し、Microsoft Defender XDRやMicrosoft 365 E5系ライセンスでID保護を強化している組織です。
| 影響を受ける対象 | 確認すべきこと | 放置した場合のリスク |
|---|---|---|
| AD管理者 | DCのOS、累積更新プログラム、RODC、追加IDロールの有無 | 対象サーバーの監視漏れ |
| セキュリティ管理者 | Defender for Endpointオンボード、センサー健全性、監査設定 | 検出精度低下、アラート欠落 |
| SOC担当者 | syslog通知、SIEM連携、検出ロジックの変更 | 既存運用フローが機能しない |
| インフラ担当者 | 仮想マシンのメモリ予約、CPU・メモリ負荷、電源設定 | ドメインコントローラーの性能劣化 |
| ID基盤担当者 | AD FS、AD CS、Microsoft Entra Connectの配置 | 適切なセンサー選択ミス |
| 移行担当者 | v2.xからv3.xへの移行条件、gMSA削除、移行後クリーンアップ | 移行失敗、対応アクション不備 |
特に注意すべきなのは、Defender for Identityを「入れれば終わり」の製品として扱わないことです。ID攻撃の検出は、Windowsイベント監査、RPC監査、ディレクトリ読み取り、ネットワーク通信、センサー正常性がそろって初めて機能します。
v3.xセンサー展開前に確認すべき前提条件
v3.xセンサーを有効化する前に、対象ドメインコントローラーで次の条件を確認します。
| 確認項目 | 実務での確認方法 | 注意点 |
|---|---|---|
| OS | winver、サーバー資産管理台帳 | Windows Server 2019以降が前提 |
| 累積更新プログラム | Windows Update、更新履歴、ビルド番号 | 2026年3月以降の累積更新プログラムが必要 |
| Defender for Endpoint | Microsoft Defenderポータル、SENSEサービス、デバイスID | オンボード済みであることが必要 |
| 既存v2.xセンサー | Sensorsページ、プログラム一覧 | 新規v3.x有効化対象にv2.xが入っていないか確認 |
| 権限 | Security Administrator、Unified RBAC | 設定変更権限が不足すると展開できない |
| 仮想化設定 | Hyper-V、VMware、その他ハイパーバイザー設定 | 動的メモリや未予約メモリに注意 |
| 時刻同期 | NTP、ドメイン時刻同期 | サーバー間で5分以内に同期 |
| 電源設定 | OSの電源プラン | High Performance推奨 |
v3.xセンサーはCPU使用率を30%、メモリ使用量を1.5GBに制限する仕組みがありますが、ほかのサービスが大量にリソースを使っている場合、ドメインコントローラー全体の負荷は無視できません。仮想マシンで動かす場合は、Hyper-Vの動的メモリを無効にする、VMwareでは予約メモリを構成するなど、メモリを常時割り当てる設計が必要です。(Microsoft Learn)
v2.xを継続すべきケース
v3.xへの移行を急がず、v2.xを継続すべきケースもあります。代表例は次のとおりです。
| v2.xを使うべきケース | 理由 |
|---|---|
| Windows Server 2016のドメインコントローラー | v3.xのOS要件を満たさない |
| 非DCのAD FSサーバー | v3.x対象ではない |
| 非DCのAD CSサーバー | v3.x対象ではない |
| 非DCのMicrosoft Entra Connectサーバー | v3.x対象ではない |
| Windows Server 2025 DCでv2.xからv3.xへ移行したい場合 | 現時点では移行未対応 |
| syslog通知やVPN統合を前提にした運用 | v3.xでは未サポートの制限がある |
v2.xセンサーでは、Windows Server 2016以降のドメインコントローラー、非DCのAD FS、AD CS、Microsoft Entra Connectサーバーが対象です。必要な最低リソースとして、ドメインコントローラーでは2コア、6GB RAM、6GBディスク容量が示され、10GBのディスク容量が推奨されています。(Microsoft Learn)
なお、Windows Server 2012および2012 R2は延長サポートが終了しています。センサーが動作し続けるケースがあっても、OS機能に依存する一部機能が使えない可能性があるため、長期的にはOSアップグレードを前提に計画するべきです。(Microsoft Learn)
v3.xセンサーの展開手順
v3.xセンサーは、従来のようにセンサーインストーラーを手動で配布するというより、Microsoft Defenderポータルから対象ドメインコントローラーを有効化する流れです。
展開前に対象サーバーを棚卸しする
最初に、Active Directory環境全体を棚卸しします。最低限、次の情報を一覧化してください。
| 棚卸し項目 | 記録例 |
|---|---|
| サーバー名 | DC01、DC02、ADFS01 |
| 役割 | DC、RODC、AD FS、AD CS、Microsoft Entra Connect |
| OS | Windows Server 2019、2022、2025 |
| 累積更新プログラム | 2026年3月以降かどうか |
| Defender for Endpoint状態 | オンボード済み、未オンボード |
| 既存センサー | v2.xあり、なし |
| 移行可否 | Ready for migration、Not ready |
| 監査設定 | 自動監査、GPO、PowerShell、未設定 |
この棚卸しをしないまま展開すると、非DCのAD FSにv3.xを入れようとしたり、v3.x対象なのにDefender for Endpointが未オンボードで有効化できなかったりします。
Test-MdiReadiness.ps1で前提条件を確認する
Microsoftは、環境が必要な前提条件を満たしているか確認するためにTest-MdiReadiness.ps1スクリプトを案内しています。このスクリプトはGitHubから入手できるほか、Microsoft Defender XDRのIdentities > Toolsページにもプレビューとして用意されています。(Microsoft Learn)
展開前のチェックでは、次の観点を確認します。
| チェック対象 | 確認内容 |
|---|---|
| OS・更新 | Windows Server 2019以降、2026年3月以降の累積更新プログラム |
| MDE状態 | Defender for Endpointのオンボード、SENSEサービス |
| センサー状態 | v2.xの有無、実行状態、バージョン |
| ネットワーク | 必要なサービスエンドポイントへの通信 |
| 権限 | Security Administratorまたは必要なUnified RBAC権限 |
| 監査 | Windowsイベント監査、RPC監査の設定準備 |
レポートに問題が出た場合は、センサー有効化より先に修正します。特に累積更新プログラムとDefender for Endpointオンボードは、移行可否にも直結します。
Microsoft Defenderポータルからセンサーを有効化する
v3.xセンサーの有効化は、Microsoft Defenderポータルで行います。手順は次の流れです。
| 手順 | 操作 |
| -: | ———————————————— |
| 1 | Microsoft Defenderポータルを開く |
| 2 | System > Settings > Identities > Activationへ移動 |
| 3 | 対象ドメインコントローラーを選択 |
| 4 | Activateを選び、確認画面で承認 |
| 5 | 有効化後、Sensorsページでセンサー正常性を確認 |
Activationページには、デバイスインベントリから検出されたサーバーと状態が表示されます。Activate new sensorならDefender for Endpointにオンボード済みで、有効化対象です。Install classic sensorならv2.xセンサーの展開対象、OS upgrade is requiredならOS更新が必要です。(Microsoft Learn)
初回の有効化では、SensorsページでRunningと表示されるまで最大1時間かかる場合があります。以降の有効化は通常5分以内に表示され、アクティベーション自体に再起動は不要とされています。(Microsoft Learn)
Windowsイベント監査の設定で検出精度を落とさない
Defender for Identityの検出は、Windowsイベントログに強く依存します。センサーが正常に動いていても、必要な監査イベントが記録されていなければ、NTLMサインイン、セキュリティグループ変更、ディレクトリサービス変更などの検出精度が下がります。
v3.xをドメインコントローラーに展開する場合は、Automatic Windows auditing configurationを使うのが推奨です。この機能は、現在の監査設定を確認し、不足している設定を適用し、設定状態に関するヘルスアラートも生成します。(Microsoft Learn)
自動監査を有効化する手順
| 手順 | 操作 |
| -: | ———————————————— |
| 1 | Microsoft DefenderポータルでSettingsを開く |
| 2 | Identitiesを選択 |
| 3 | Advanced featuresを開く |
| 4 | Automatic Windows auditing configurationをオンにする |
自動監査はv3.xセンサーを実行するドメインコントローラー向けの機能です。v2.xのドメインコントローラー、非DCのAD FS、AD CS、Microsoft Entra Connectサーバーでは、手動設定またはPowerShellによる設定が必要です。(Microsoft Learn)
注意点として、GPOで監査設定を強制している環境では、センサーが適用するローカル設定と競合する可能性があります。既存の監査GPOをそのまま残す場合は、Defender for Identityが必要とするイベントIDが実際に記録されているか、イベントビューアーやレポートで確認してください。
RPC監査タグの設定を忘れない
v3.xセンサーでは、RPC監査の設定も重要です。RPC監査タグをデバイスへ適用すると、追加のID検出に必要な可視性を有効化できます。公式情報では、Unified Sensor RPC Auditと、プレビューのExtended Sensor Auditが示されています。Extended Sensor Auditは追加の高度な検出向け機能で、最新の累積更新プログラムが必要です。(Microsoft Learn)
RPC監査タグの適用手順
| 手順 | 操作 |
| -: | ———————————————————————————————- |
| 1 | Microsoft DefenderポータルでSystem > Settings > Microsoft Defender XDR > Asset Rule Managementへ移動 |
| 2 | Create a new ruleを選択 |
| 3 | ルール名と説明を入力 |
| 4 | Device name、Domain、Device tagなどで対象DCを指定 |
| 5 | v3.xセンサーが展開済みのデバイスを対象にする |
| 6 | Unified Sensor RPC AuditまたはExtended Sensor Auditタグを追加 |
| 7 | 内容を確認してSubmit |
ルールの反映には最大1時間かかる場合があります。展開直後にアラートが出ない、タグが見えないと判断せず、反映時間を考慮して確認しましょう。(Microsoft Learn)
v2.xからv3.xへ移行する場合の注意点
既存のv2.xセンサーをv3.xへ移行する場合、Microsoft Defenderポータルから移行できます。移行中はv2.xセンサーが動作し続け、v3.xが準備できるまで保護が維持されます。公式情報では、移行は通常最大20分とされています。(Microsoft Learn)
ただし、移行できるサーバーは限定されています。移行対象サーバーは、追加IDロールを持たないドメインコントローラーで、v2.xセンサーのバージョンが2.254.19112.470以降、Windows Server 2019以降、Defender for Endpoint展開済み、2026年3月以降の累積更新プログラム適用済みである必要があります。(Microsoft Learn)
移行可否の判断表
| 状態 | 意味 | 管理者の対応 |
|---|---|---|
| Ready for migration | 前提条件を満たし移行可能 | 対象を選択してMigrate |
| Not ready for migration | いずれかの条件を満たしていない | OS、更新、MDE、v2.xバージョンを確認 |
| Migrating | 移行中 | 完了まで監視。途中で不要な操作をしない |
| Migration failed | 移行失敗 | MDE Client Analyzerやセンサー状態を確認 |
| Up to date | v3.xで稼働中 | 監査設定、RPC監査、ヘルス状態を確認 |
特に見落としやすいのは、追加IDロールを持つドメインコントローラーの扱いです。AD FS、AD CS、Microsoft Entra Connectを兼ねるドメインコントローラーは新規v3.x展開の対象になり得ますが、既存v2.xからのインプレース移行は現時点で対象外とされています。移行計画では、「新規展開の対応」と「既存v2.xからの移行対応」を分けて判断してください。(Microsoft Learn)
gMSAを残すと対応アクションが動かない
v3.xセンサーでは、Active Directoryおよび対応アクションにローカルシステムIDを使用します。Directory Service AccountやgMSAはサポートされず、LocalSystemのみがサポート対象です。v2.xから移行する環境で、過去にアクションアカウント用のgMSAを構成していた場合は削除が必要です。gMSAが残っていると、attack disruptionを含む対応アクションが動作しない可能性があります。(Microsoft Learn)
これは移行後に発覚しやすいポイントです。センサーがRunningになっていても、対応アクションが期待通り動くとは限りません。移行チェックリストに「gMSA設定の削除」と「対応アクションのテスト」を必ず入れてください。
移行後はv2.xセンサーとNpcapを整理する
移行後、v2.xセンサーサービスは無効化されますが、v2.xセンサーソフトウェア自体はサーバーに残ります。公式情報では、不要になったv2.xセンサーソフトウェアのアンインストールと、v3.xでは不要なNpcapの削除が案内されています。Npcapを他アプリケーションが使っていない場合は削除を検討します。(Microsoft Learn)
移行後のクリーンアップを怠ると、後日のトラブルシュートで「どのセンサーが有効なのか」が分かりにくくなります。変更管理台帳にも、移行日時、旧バージョン、新状態、削除済みコンポーネントを記録しておきましょう。
ネットワークとプロキシ設定の確認
v3.xセンサーはMicrosoft Defender for Endpointと同じURIを使用します。そのため、Defender for Endpointの接続要件に従って、必要なサービスエンドポイントへ通信できるか確認します。(Microsoft Learn)
v2.xセンサーでは、Defender for IdentityクラウドサービスへのアウトバウンドHTTPS通信が必要です。ワークスペースのセンサーAPI URLは、https://<your-workspace-name>sensorapi.atp.azure.comの形式です。プロキシを使う場合は、対象URLの許可、明示的な許可リスト、SSL検査の扱いを確認してください。v2.xの要件では、プロキシ利用時のSSL検査はサポートされないとされています。 (Microsoft Learn)
ネットワーク確認でありがちな失敗は、管理端末からのアクセスだけを確認して、ドメインコントローラー自身からの通信を確認しないことです。センサーが動くサーバー上で名前解決、プロキシ、HTTPS通信、ファイアウォールログを確認してください。
展開後に確認すべきセンサー状態
展開が完了したら、Microsoft DefenderポータルのSensorsページで状態を確認します。Settings > Identities > On-premises > Sensorsから、センサー種別、移行状態、サービス状態、センサー状態、ヘルス状態を確認できます。(Microsoft Learn)
| 確認項目 | 正常な状態の例 | 異常時の見方 |
|---|---|---|
| Service status | Running | Stopped、Disabled、Unknownなら通信やサービス状態を確認 |
| Sensor status | Up to date | Outdated、Update failed、Not Configuredに注意 |
| Health status | Healthy | 黄色、オレンジ、赤のNot healthyは重大度別に確認 |
| Migration state | Up to date | Not ready、Migration failedは前提条件を再確認 |
| Type | Domain controller sensorなど | 想定したサーバーロールと一致するか確認 |
v3.xセンサーはDefender for Endpointのコンポーネントとして提供され、Windows Updateを通じて自動更新されます。v3.xでは手動のセンサー更新プロセスは不要です。一方、v2.xには通常更新と遅延更新リングの考え方があり、Delayed updateを有効化したセンサーは通常より72時間遅れて更新されます。(Microsoft Learn)
運用では、v3.xとv2.xが混在している期間が長くなる可能性があります。その場合、更新方法、ヘルスアラート、トラブルシュート手順がセンサー世代ごとに違うことを運用手順書へ明記してください。
管理者向け展開チェックリスト
展開や移行の前後で、次のチェックリストを使うと抜け漏れを減らせます。
| タイミング | チェック項目 | 完了基準 |
|---|---|---|
| 計画時 | 全DC、RODC、AD FS、AD CS、Microsoft Entra Connectサーバーの棚卸し | サーバー一覧と役割が確定 |
| 計画時 | v3.x対象とv2.x対象の分類 | OS、ロール、更新状態に基づき分類済み |
| 展開前 | Defender for Endpointオンボード | 対象DCがMDEデバイスとして登録済み |
| 展開前 | 2026年3月以降の累積更新プログラム | 対象DCに適用済み |
| 展開前 | Test-MdiReadiness.ps1実行 | 重大な前提条件エラーなし |
| 展開前 | 権限確認 | Security Administratorまたは必要なUnified RBAC権限あり |
| 展開時 | v3.xセンサー有効化 | Activationページから対象DCを有効化 |
| 展開後 | Windowsイベント監査 | 自動監査または手動監査が有効 |
| 展開後 | RPC監査タグ | Unified Sensor RPC Auditなどを適用 |
| 移行後 | gMSA削除 | v3.xでLocalSystem運用に統一 |
| 移行後 | v2.xソフトウェア整理 | 不要なv2.xセンサーとNpcapを確認 |
| 運用時 | Sensorsページ監視 | Running、Up to date、Healthyを確認 |
| 運用時 | アラートと検出の確認 | 監査イベントと検出状況を定期確認 |
このチェックリストで特に優先度が高いのは、v3.x対象の分類、Defender for Endpointオンボード、監査設定、gMSA削除です。センサーの有効化だけを完了条件にせず、検出と対応アクションが機能するところまで確認しましょう。
よくある失敗と回避策
v3.xを全サーバーに展開しようとする
v3.xは便利ですが、非DCのAD FS、AD CS、Microsoft Entra Connectサーバーにはv2.xを使います。ロール名ではなく、サーバーがドメインコントローラーかどうかで判断してください。
Defender for Endpointのオンボードを見落とす
v3.xはDefender for Endpointが展開済みで、対象サーバーがオンボードされている必要があります。Defender for Endpointのライセンスやポリシーがあるだけでは不十分です。SensorsページでReadyにならない場合は、MDE Client Analyzer、SENSEサービス、デバイスID、オンボード情報を確認します。(Microsoft Learn)
監査設定を後回しにする
Windowsイベント監査とRPC監査が不足していると、センサーは動いていても検出能力が不足します。v3.xでは自動Windows監査を有効にし、RPC監査タグの適用までを展開作業に含めるべきです。
GPOと自動監査の競合を確認しない
既存GPOで監査ポリシーを強制している場合、Defender for Identity側が必要とする設定と食い違う可能性があります。設定後はイベントIDの記録有無、ヘルスアラート、監査レポートを確認してください。
移行後にgMSAを残す
v3.xではLocalSystemがサポートされます。v2.x時代のgMSAを残すと、attack disruptionを含む対応アクションが動作しない可能性があります。移行後の動作確認では、検出だけでなく対応アクションも確認してください。
Windows Server 2025の移行可否を誤解する
Windows Server 2025ドメインコントローラーでは、v2.xからv3.xへの移行は現時点でサポートされていません。Windows Server 2025だから新しいセンサーへ移行できる、と単純に判断しないよう注意してください。(Microsoft Learn)
開発者・自動化担当者が見るべきポイント
Defender for Identityセンサー展開はインフラ作業に見えますが、開発者や自動化担当者にも関係します。特にMicrosoft Graph API、資産管理、自動タグ付け、監査レポートを扱う場合は、次の観点を確認してください。
| 観点 | 確認ポイント |
|---|---|
| デバイスインベントリ | 対象DCがDefenderポータルに正しく表示されるか |
| 動的ルール | Asset Rule Managementで対象条件を誤って広げていないか |
| タグ運用 | RPC監査タグが対象DCだけに適用されているか |
| 変更管理 | センサー有効化、移行、タグ適用の履歴を残せるか |
| API連携 | センサー候補や状態取得のAPI変更を追跡するか |
| アラート連携 | SOCやチケットシステムへの通知経路が変わらないか |
Asset Rule Managementの動的ルールは便利ですが、条件指定を誤ると想定外のデバイスへタグが付く可能性があります。DomainやDevice tagを使う場合は、対象がドメインコントローラーに限定されているか確認し、まず少数の検証対象で反映結果を確認するのが安全です。(Microsoft Learn)
まず取るべき次のアクション
Microsoft Defender for Identity センサー展開で今すぐ行うべきことは、センサーのインストール作業ではなく、対象サーバーの分類と前提条件チェックです。
最初に、全ドメインコントローラー、RODC、AD FS、AD CS、Microsoft Entra Connectサーバーを棚卸しします。次に、Windows Server 2019以降か、2026年3月以降の累積更新プログラムが入っているか、Defender for Endpointにオンボードされているかを確認します。そのうえで、v3.x対象、v2.x継続対象、移行対象外を分けてください。
v3.xを使う環境では、センサー有効化後に自動Windows監査とRPC監査タグを設定し、SensorsページでRunning、Up to date、Healthyを確認します。v2.xから移行する場合は、移行条件を満たしているか、gMSAを削除したか、v2.xソフトウェアとNpcapの整理が必要かまで確認しましょう。
センサー展開の目的は、製品を入れることではなく、ID攻撃を見つけて対応できる状態を作ることです。v3.xとv2.xを適切に使い分け、監査設定と運用確認まで含めて展開計画を作ることが、Microsoft Defender for Identityを有効に機能させる近道です。
コメント