Microsoft Defender for Identityの「Remediation actions」は、侵害が疑われるユーザーに対して、アカウント無効化、セッション取り消し、パスワード変更要求などをMicrosoft Defenderポータルから実行するための機能です。今回のポイントは、単に“ボタンが増えた”という話ではありません。どのID基盤で、どのセンサーが、どの権限で、どの操作を実行できるのかを管理者が正しく把握しておかないと、インシデント対応時に期待した封じ込めができない可能性があります。(Microsoft Learn)
特に確認すべきなのは、Active Directoryではドメインコントローラー上のDefender for Identityセンサーだけが修復アクションを実行する点、sensor v3.xではローカルシステムアカウントの利用が前提になる点、Microsoft Entra IDやOktaでは実行できるアクションと必要なロールが異なる点です。この記事では、2026年6月上旬時点の公式情報をもとに、変更点、影響範囲、移行・展開時の注意点を実務目線で整理します。
Microsoft Defender for IdentityのRemediation actionsとは
Microsoft Defender for IdentityのRemediation actionsは、侵害された可能性があるIDに対して、セキュリティ担当者がMicrosoft Defenderポータルから直接対応するための機能です。
たとえば、以下のような場面で使います。
- 不審な横展開が検知されたユーザーを一時的に無効化する
- 盗まれた可能性がある資格情報の悪用を止めるため、パスワード変更を強制する
- Microsoft Entra IDやOktaのアクティブセッションを取り消す
- Microsoft Entra ID上でユーザーを「侵害済み」としてマークする
- Automatic Attack Disruptionによって、自動的に攻撃の進行を止める
操作は、Microsoft Defenderポータルのユーザーページ、ユーザーのサイドパネル、Advanced hunting、Action centerから実行できます。実行後の状態はAction centerで追跡できます。(Microsoft Learn)
重要なのは、Remediation actionsは「Microsoft Defenderが勝手にADやEntra IDを書き換える機能」ではないという点です。操作はポータル上のユーザー操作、または自動攻撃妨害の仕組みから開始され、実行前にRBACで権限が確認されます。権限が足りない場合、アクションは実行前にブロックされます。(Microsoft Learn)
今回の公式情報で管理者が押さえるべき変更点
今回の公式情報で特に重要なのは、Remediation actionsの実行主体と対象範囲がより明確になったことです。従来の運用で「Defender for Identityセンサーが入っていれば実行できる」と大まかに理解していた環境では、確認が必要です。
| 確認ポイント | 管理者への影響 |
|---|---|
| Active Directoryの修復アクションはドメインコントローラー上のセンサーが実行する | AD FS、AD CS、Microsoft Entra Connectサーバー上のセンサーだけではADへの修復アクションは実行されない |
| sensor v3.xではローカルシステムアカウントを使用する | v2.xでgMSAを前提にしていた運用は見直しが必要 |
| Microsoft Entra IDではMicrosoft管理のエンタープライズアプリを使用する | アプリケーション棚卸しや監査時に、正当なアプリとして識別できるようにしておく |
| Oktaなどの非Microsoft IdPでは連携先IdPのAPIを使用する | 連携資格情報、API権限、IdP側の制限を確認する必要がある |
| Automatic Attack DisruptionでもRemediation actionsが使われる | 手動対応だけでなく、自動封じ込めの影響も運用手順に含める必要がある |
Microsoftのドキュメントでは、Active DirectoryへのアクションはドメインコントローラーにインストールされたDefender for Identityセンサーが実行し、AD FS、AD CS、Microsoft Entra Connectサーバー上のセンサーは修復アクションを実行しないと説明されています。sensor v3.xを含む環境では、「Automatically use the sensor’s local system account」を選択することが必須または推奨されています。(Microsoft Learn)
対応できるアクションと対象ID基盤
Remediation actionsで実行できる内容は、Active Directory、Microsoft Entra ID、Oktaで同じではありません。インシデント対応手順を作る際は、「この操作はどのID基盤に効くのか」を分けて考える必要があります。
| アクション | 主な効果 | 対応するID基盤 | 使うべき場面 |
|---|---|---|---|
| Disable | 対象IDまたは関連アカウントを無効化する | Active Directory、Microsoft Entra ID、Okta | 侵害が強く疑われ、サインインやリソースアクセスを止めたい場合 |
| Enable | 無効化されたアカウントを再有効化する | Active Directory、Microsoft Entra ID、Okta | 誤検知や復旧後に業務利用を再開する場合 |
| Revoke session | アクティブセッションを取り消す | Microsoft Entra ID、Okta | パスワード変更前後に既存セッションの悪用を止めたい場合 |
| Mark as compromised | Entra ID上で侵害済みとしてマークする | Microsoft Entra ID | Entra IDのリスク対応フローと連携したい場合 |
| Force password change | 次回サインイン時のパスワード変更を強制する | Active Directory | 盗まれた可能性があるAD資格情報を無効化したい場合 |
| Deactivate | 不正な悪意あるアカウントを恒久的に非アクティブ化する | Okta | 正当なユーザーではない悪性アカウントを停止したい場合 |
| Set account risk to High / Medium / Low | アカウントリスクを指定レベルに設定する | Okta | OktaのRisk Scoringを使ってリスクベース対応を行う場合 |
Disableはサインインやネットワークリソースへのアクセスを防ぎますが、ユーザープロファイルやメール、予定表、ドキュメントなどの関連データを削除するものではありません。業務影響は大きい一方で、削除操作ではないため、緊急時の封じ込め手段として使いやすいアクションです。(Microsoft Learn)
一方で、Force password changeはActive Directory向け、Revoke sessionはMicrosoft Entra IDとOkta向け、Mark as compromisedはMicrosoft Entra ID向けです。ハイブリッドID環境では、1つの操作だけで全経路を止められるとは限りません。
Active Directory環境で確認すべき設定
Active Directoryを利用している環境では、最初に確認すべきなのはセンサーの配置です。修復アクションを実行できるのは、ドメインコントローラー上のDefender for Identityセンサーです。AD FS、AD CS、Microsoft Entra Connectなどにセンサーが入っていても、それらがドメインコントローラーでなければADへの修復アクションは実行されません。(Microsoft Learn)
sensor v3.xではローカルシステムアカウントの扱いに注意する
Microsoftの公式情報では、sensor v3.xは修復アクションにgMSAアクションアカウントを使用せず、常にドメインコントローラーのローカルシステムアカウントを使用すると説明されています。v3.xセンサーが1台でもある場合は、「Automatically use the sensor’s local system account」を選択する必要があります。(Microsoft Learn)
確認場所は以下です。
| 項目 | 確認内容 |
|---|---|
| ポータル | Microsoft Defenderポータル |
| メニュー | Settings > Identities > Microsoft Defender for Identity > Manage action accounts |
| 確認する設定 | Automatically use the sensor’s local system account |
| 特に確認すべき環境 | sensor v3.x環境、v2.xとv3.xの混在環境、過去にgMSAアクションアカウントを使っていた環境 |
v2.xでgMSAアクションアカウントを細かく設計していた組織ほど、v3.x移行時に「以前のgMSA設定がそのまま使われる」と誤解しがちです。公式情報では、v3.xセンサーはv2.x向けに構成されたgMSAアカウントを使用しないとされています。移行前後でテストユーザーを使い、Disable、Enable、Force password changeが期待どおり実行されるかを必ず確認してください。(Microsoft Learn)
gMSAを使う場合の失敗しやすいポイント
sensor v2.xで専用gMSAを使う場合でも、設計を誤るとセキュリティリスクになります。Microsoftは、ドメインコントローラー以外のサーバーで同じgMSAを使うことや、読み取り用のDirectory Service Accountと書き込み権限を持つManage Action Accountを兼用することを避けるよう推奨しています。(Microsoft Learn)
実務では、次のような設計ミスが起きやすいです。
| 失敗例 | 何が問題か | 対応 |
|---|---|---|
| Directory Service AccountとAction Accountを兼用する | 読み取り専用でよいアカウントに不要な書き込み権限を持たせる | 用途別にアカウントを分ける |
| 複数用途のサーバーで同じgMSAを使う | サーバー侵害時にAD操作権限が奪われるリスクがある | ドメインコントローラー用途に限定する |
| 複数フォレストで信頼関係を確認していない | 一部フォレストで修復アクションが失敗する | フォレストごとに信頼または個別gMSAを設計する |
| v3.x移行後もgMSA前提で手順書を残す | 実際の実行主体と手順書がずれる | v3.xではローカルシステムアカウント前提に更新する |
Microsoft Entra ID環境で確認すべき設定
Microsoft Entra IDに対するRemediation actionsでは、Defender for IdentityがMicrosoft管理のエンタープライズアプリケーションを作成し、使用します。公式情報では、アプリケーション名は「Microsoft Defender for Identity」、古いテナントでは「Radius Aad Syncer」と表示される可能性があり、アプリケーションIDは 60ca1954-583c-4d1f-86de-39d835f3e452 とされています。(Microsoft Learn)
この情報は、セキュリティ監査やアプリケーション棚卸しで重要です。見慣れないエンタープライズアプリとして誤って削除したり、条件付きアクセスやアプリ制御の対象として不用意にブロックしたりすると、Entra ID側の修復アクションに影響する可能性があります。
Entra IDで操作できる内容を誤解しない
Entra IDでは、Disable、Enable、Revoke session、Mark as compromisedなどが利用できます。ただし、操作ごとに必要なMicrosoft Entra IDロールは異なります。たとえば、ユーザー無効化や有効化にはGlobal Administrator、User Administrator、Authentication Administrator、Privileged Authentication Administrator、Directory Writersなどが関係し、Mark as compromisedではGlobal Administrator、Security Administrator、Security Operatorが関係します。(Microsoft Learn)
ここでの注意点は、Global Administratorを安易に付与しないことです。インシデント対応のスピードを重視するあまり、SOC担当者に広すぎる権限を付与すると、通常運用時のリスクが増えます。Microsoft Defender unified RBACのカスタムロールを使い、Response manageに必要な権限を最小限で設計するのが現実的です。Defender unified RBACでは、特定の権限を持つカスタムロールを作成し、ユーザーやグループに割り当てられます。(Microsoft Learn)
Oktaなど非Microsoft IdPを利用している場合の確認点
公式情報では、サポートされる非Microsoft IDプロバイダーでは、構成済みの統合資格情報にもとづいて、連携先IdPのAPIを使ってアクションが実行されると説明されています。OktaではDisable、Enable、Revoke session、Deactivate、Set account risk to High / Medium / Lowなどが対象です。(Microsoft Learn)
Okta連携で特に確認したいのは、次の3点です。
| 確認項目 | 見るべきポイント |
|---|---|
| API連携の資格情報 | 有効期限、権限不足、ローテーション後の更新漏れがないか |
| Okta側のロール | Security Operator、Security Administrator、Global Administratorなど、必要な権限を持つ担当者に限定されているか |
| Risk Scoring | Set account riskを使う場合、Okta側でRisk Scoring機能が有効か |
OktaのアクションはMicrosoft Defenderだけで完結しているように見えても、実行の成否はOkta側のAPI、ロール、機能設定に依存します。障害時の切り分け手順には、DefenderのAction centerだけでなく、Okta側の監査ログ確認も含めておくべきです。
Automatic Attack Disruptionによる自動実行の影響
Remediation actionsは、管理者が手動で実行するだけではありません。Microsoft DefenderのAutomatic Attack Disruptionでも利用されます。Microsoftの説明では、進行中の攻撃を高い信頼度で検知した場合、Defenderは攻撃者が使用している侵害済み資産を自動的に封じ込め、横展開や被害拡大を抑えるとされています。(Microsoft Learn)
これは非常に強力ですが、運用面では注意が必要です。たとえば、ランサムウェアや高度な横展開の疑いがある場合、対象ユーザーやセッションが自動的に封じ込められる可能性があります。セキュリティ面では有効でも、業務部門から見ると「突然ログインできない」「アプリにアクセスできない」という問い合わせになります。
自動封じ込めに備えて決めておくべきこと
| 決めておく項目 | 具体例 |
|---|---|
| 一次確認の担当 | SOC、ID管理チーム、ヘルプデスクのどこが最初にAction centerを見るか |
| 業務影響の連絡先 | 対象ユーザーの所属部門、システムオーナー、緊急連絡先 |
| 復旧判断 | Enableやセッション再確立を誰が承認するか |
| 監査証跡 | Defender監査ログ、IdP側ログ、チケット番号をどう紐づけるか |
| 誤検知時の対応 | 解除手順、ユーザー通知、パスワード再設定の要否 |
Automatic Attack Disruptionは、攻撃の進行を止めるための仕組みです。止めること自体を恐れて無効化するのではなく、止まった後に誰が確認し、誰が復旧を判断するかを事前に決めておくことが重要です。
RBACと権限設計で確認すべきポイント
Remediation actionsは、実行前にMicrosoft Entra IDロールにもとづくRBACで承認されます。Defender for Identityのアクションを実行するには、Response manage権限を持つカスタムロール、または該当するMicrosoft Entra IDロールが必要です。(Microsoft Learn)
権限設計では、次のように役割を分けると運用しやすくなります。
| 役割 | 推奨される権限設計の考え方 |
|---|---|
| SOCアナリスト | アラート確認、影響範囲調査、必要に応じたResponse manage |
| ID管理者 | AD、Entra ID、Okta側のアカウント復旧と恒久対策 |
| ヘルプデスク | ユーザー本人確認、パスワード変更支援、問い合わせ一次対応 |
| セキュリティ管理者 | ロール設計、監査、例外承認、ポリシー変更 |
| 開発・自動化担当 | SIEM、SOAR、チケット連携、監査ログ連携の実装 |
避けたいのは、「誰でも押せる」または「誰も押せない」状態です。前者は誤操作や過剰対応のリスクがあり、後者はインシデント時に封じ込めが遅れます。最小権限を基本にしつつ、夜間・休日でも実行できる当番体制を整えることが現実的です。
管理者が今すぐ確認すべきチェックリスト
Remediation actionsを安全に使うために、管理者は次の順番で確認すると効率的です。
| 優先度 | 確認項目 | 判断基準 |
|---|---|---|
| 高 | ドメインコントローラー上にDefender for Identityセンサーがあるか | ADへの修復アクションを実行できる構成になっている |
| 高 | sensor v3.xまたは混在環境か | v3.xがある場合はローカルシステムアカウント利用設定を確認する |
| 高 | Manage action accountsの設定 | Automatically use the sensor’s local system accountが選択されている |
| 高 | RBACとEntra IDロール | Response manage権限を持つ担当者が明確 |
| 中 | Microsoft管理エンタープライズアプリ | 正当なDefender for Identity関連アプリとして棚卸し済み |
| 中 | Okta連携 | API資格情報、ロール、Risk Scoringの設定を確認済み |
| 中 | Action centerの確認手順 | 実行済み、保留、失敗したアクションを追える |
| 中 | 監査ログの保存 | Defender監査ログとIdP側ログを突合できる |
| 低 | 手順書の用語 | Response actionsではなくRemediation actionsとして統一 |
このチェックリストは、本番障害が起きてから確認するものではありません。テスト用ユーザーを用意し、Disable、Enable、Revoke session、Force password changeなどを実際に試して、期待したログとチケットが残るかまで確認してください。
移行・展開時に見落としやすい注意点
v2.xからv3.xへの移行ではアクションアカウントの前提が変わる
sensor v2.xで専用gMSAを使っていた場合、v3.xへの移行後も同じgMSAが使われると考えるのは危険です。公式情報では、sensor v3.xはgMSAアクションアカウントを使用せず、ローカルシステムアカウントで修復アクションを実行するとされています。(Microsoft Learn)
移行時は、センサーのバージョン確認だけでなく、以下をセットで確認してください。
- 修復アクションの実行主体
- Manage action accountsの設定
- テストユーザーへのDisable、Enable、Force password changeの実行可否
- Action centerに残る結果
- AD側の監査ログ
- 旧gMSAを無効化・削除してよいかの判断
AD FSやAD CSのセンサーを過信しない
Defender for IdentityのセンサーがAD FSやAD CSに入っていること自体は重要です。しかし、Remediation actionsの実行という観点では、ドメインコントローラー上のセンサーが必要です。センサー配備表を作るときは、「検知目的のセンサー」と「修復アクションを実行できるセンサー」を分けて管理すると、誤解を防げます。
開発者はAPI連携と監査ログの前提を見直す
SIEM、SOAR、チケットシステムと連携している開発者は、Remediation actionsの成否をDefender側だけで判断しない設計にするべきです。公式情報では、アクションは実行されたIDシステムに記録され、Microsoft Defenderの監査ログにも表示されます。(Microsoft Learn)
実装では、次のような設計が実用的です。
| 実装項目 | 推奨する考え方 |
|---|---|
| チケット起票 | Action centerの状態、対象ID、実行者、実行時刻を記録する |
| ログ相関 | Defender監査ログとAD、Entra ID、Okta側ログを突合する |
| エラー処理 | RBACでブロックされた場合とIdP側APIで失敗した場合を分ける |
| 用語統一 | 画面・手順書・自動化スクリプトでRemediation actionsに統一する |
| 復旧処理 | DisableとEnableを対にして、復旧承認フローを残す |
インシデント対応での使い分け例
Remediation actionsは強力ですが、すべての疑わしいユーザーを即座にDisableすればよいわけではありません。業務影響と攻撃リスクのバランスで使い分けます。
| 状況 | 推奨される初動 |
|---|---|
| 資格情報漏えいの疑いがあるが、横展開の証拠は弱い | Revoke session、Force password change、追加調査 |
| ランサムウェアや横展開が進行中 | Disableを含む強い封じ込め、Automatic Attack Disruptionの結果確認 |
| Entra IDのリスク検知と連携したい | Mark as compromisedを検討 |
| Okta上の不正アカウントが確認された | DeactivateまたはDisableを検討 |
| 誤検知または復旧済み | Enable、セッション再確立、ユーザー通知 |
判断に迷う場合は、「攻撃者が今も使える経路を先に止める」と考えると整理しやすくなります。クラウドセッションが残っているならRevoke session、AD資格情報が疑わしいならForce password change、横展開中ならDisableを優先します。
運用手順に入れておきたい確認フロー
実際の運用では、次の流れを手順書にしておくと、夜間対応や担当者交代時にも迷いにくくなります。
| 手順 | 作業内容 | 確認先 |
|---|---|---|
| 検知 | Defenderのインシデント、アラート、Advanced huntingで対象IDを確認 | Microsoft Defenderポータル |
| 判断 | 対象ID、端末、サインイン、横展開の有無を確認 | Defender XDR、Entra ID、AD、Okta |
| 実行 | Disable、Revoke session、Force password changeなどを選択 | ユーザーページ、サイドパネル、Advanced hunting、Action center |
| 追跡 | アクションの実行状態を確認 | Action center |
| 監査 | 実行者、時刻、対象、結果を記録 | Defender監査ログ、各IdPログ |
| 復旧 | Enable、パスワード再設定、ユーザー通知を実施 | ID管理チーム、ヘルプデスク |
| 改善 | 誤検知、遅延、権限不足を振り返る | インシデントレビュー |
このフローで重要なのは、実行前の判断と実行後の追跡を分けることです。緊急時にはDisableやRevoke sessionをすばやく実行する必要がありますが、その後に誰が復旧判断をするのかを決めていないと、業務停止が長引きます。
よくある疑問
Disableはユーザー削除と同じですか？
同じではありません。Disableはサインインやネットワークリソースへのアクセスを防ぐ操作であり、IDプロファイルや関連データを削除するものではありません。復旧時にはEnableで再有効化できます。(Microsoft Learn)
Force password changeはMicrosoft Entra IDにも使えますか？
公式情報上、Defender for IdentityのForce password changeはActive Directory向けのアクションとして整理されています。Entra IDではRevoke sessionやMark as compromisedなど、Entra ID側で対応するアクションを組み合わせて考える必要があります。(Microsoft Learn)
sensor v3.xでもgMSAアクションアカウントは必要ですか？
sensor v3.xでは、修復アクションにgMSAアクションアカウントを使用しません。常にドメインコントローラーのローカルシステムアカウントを使用するため、v3.x環境では「Automatically use the sensor’s local system account」の確認が重要です。(Microsoft Learn)
どのログを見れば実行結果を確認できますか？
実行状態はAction centerで追跡できます。また、アクションは実行されたIDシステムに記録され、Microsoft Defenderの監査ログにも表示されます。運用では、Defender側の記録とAD、Entra ID、Okta側のログを突合できるようにしておくと、監査や事後分析がしやすくなります。(Microsoft Learn)
まず実施すべきこと
Microsoft Defender for IdentityのRemediation actionsは、侵害されたIDをすばやく封じ込めるための実践的な機能です。ただし、ID基盤、センサー配置、RBAC、アクションアカウント、IdP連携のどこかに認識違いがあると、本番のインシデント時に機能しません。
まずは次の3つを優先してください。
- ドメインコントローラー上のDefender for Identityセンサーとsensor v3.xの有無を確認する
- Microsoft DefenderポータルでManage action accountsとRBACを確認する
- テストユーザーでDisable、Enable、Revoke session、Force password changeの実行とログ記録を検証する
Remediation actionsは、導入して終わりの機能ではありません。インシデント対応手順、ヘルプデスク連携、監査ログ、復旧判断まで含めて設計して初めて、Microsoft Defenderの防御力を実務で活かせます。
コメント