Microsoft Defender XDRの「Exclude assets from automated response in attack disruption」は、自動攻撃中断による封じ込め対象から、特定のユーザー、デバイスグループ、IPアドレス、またはタグベースのポリシー適用を除外するための設定です。結論から言うと、これは「止めてはいけない重要資産を守るための例外設定」ですが、安易に広げるとMicrosoft Defenderの自動防御効果を下げます。2026年6月28日に更新されたMicrosoft Learnでは、除外対象の考え方、必要な権限、設定場所、削除方法、プレビュー扱いのポリシー適用除外が整理されています。(Microsoft Learn)
この記事では、Microsoft Defenderの管理者が「どの資産を除外すべきか」「どの設定変更が必要か」「移行期限はあるのか」「運用前に何を確認すべきか」を、実務で判断できる形に整理します。
Microsoft Defender XDRの自動攻撃中断とは
Microsoft Defender XDRの自動攻撃中断は、ランサムウェアや高度な侵害など、進行中の攻撃を高い信頼度で検出したときに、攻撃者が使っている資産を自動的に封じ込める機能です。Microsoft Defenderは、エンドポイント、ID、メール、アプリ、ファイルなど複数のシグナルを相関し、インシデント単位で攻撃を判断します。(Microsoft Learn)
従来の「単一のIoCをブロックする」対策とは異なり、自動攻撃中断は攻撃全体の流れを見て、侵害されたユーザーやデバイス、IPアドレスなどを封じ込めます。これにより、横展開やリモート暗号化の進行を早い段階で止めることを狙います。
代表的な自動対応には、次のようなものがあります。
| 自動対応 | 主な対象 | 実務上の意味 |
|---|---|---|
| デバイスの封じ込め | 侵害が疑われる端末 | 他のDefender for Endpointオンボード済みデバイスから通信を遮断する |
| IPアドレスの封じ込め | 未管理端末や不明な送信元IP | 指定IPとの通信を防ぎ、横展開を抑える |
| デバイスの分離 | 侵害端末 | セキュリティサービスとの通信を残しつつ、通常のネットワーク通信を制限する |
| ユーザーの無効化 | 侵害されたID | 追加サインインや権限悪用を防ぐ |
| ユーザーセッションの取り消し | Microsoft Entra IDのセッション | 進行中のアクセスを中断する |
Microsoftの説明では、自動攻撃中断は「高い信頼度」で侵害資産を特定して自動対応を行う設計です。ただし、自動対応が業務に影響する可能性はあるため、今回の「Exclude assets from automated response in attack disruption」が重要になります。(Microsoft Learn)
今回の更新で押さえるべきポイント
今回確認すべきポイントは、「自動攻撃中断を止める」のではなく、「本当に止められない資産だけを限定的に除外する」運用に寄せることです。
Microsoft Learnの対象ページでは、除外ポリシーにより、特定の資産やアクションを自動対応から除外できると説明されています。一方で、Microsoftは自動対応から資産を除外することを推奨していません。除外により、高度で影響の大きい攻撃から環境を守る自動攻撃中断の効果が低下する可能性があるためです。(Microsoft Learn)
実務上は、次のように捉えると分かりやすいです。
| 確認項目 | 管理者が取るべき判断 |
|---|---|
| 重要サーバーを止めたくない | いきなり広範囲に除外せず、対象サーバーの役割、代替手段、SOCの監視体制を確認する |
| 緊急管理者アカウントを無効化されたくない | 除外対象にする前に、Break Glassアカウントの数、MFA、利用監査、保管手順を確認する |
| レガシー機器やOT環境がある | IP除外やデバイスグループ除外を検討するが、通信監視やEDR外の検知手段を併用する |
| 例外が増えている | 四半期ごとに棚卸しし、不要な除外を削除する |
| 全体をオプトアウトしたい | 原則避け、個別除外で代替できないか検討する |
特に重要なのは、除外は「安全な資産だから除外する」のではなく、「自動封じ込めの業務影響が大きく、別の監視・対応策を用意できる資産だけを除外する」という考え方です。
影響範囲：対象になるのはID、デバイス、IP、ポリシー適用
「Exclude assets from automated response in attack disruption」で扱う影響範囲は、大きく4つに分けられます。
ユーザーアカウントの除外
ユーザーアカウントの除外は、特定のIDが攻撃検出時に自動的に無効化されることを防ぐ設定です。Microsoftの例では、サービスアカウント、緊急管理者アカウント、重要な業務プロセスを支えるIDが想定されています。(Microsoft Learn)
ただし、これは非常に慎重に扱うべき設定です。たとえば、ドメイン管理者相当のアカウントや特権サービスアカウントを除外すると、そのアカウントが侵害された場合に攻撃者の活動を止めにくくなる可能性があります。
実務では、次の条件を満たすアカウントだけを候補にします。
| 除外候補 | 除外前に確認すべきこと |
|---|---|
| Break Glassアカウント | 通常業務で使われていないか、利用時に必ず通知されるか、資格情報の保管手順があるか |
| サービスアカウント | 人間がサインインできない設計か、最小権限か、パスワードや証明書の管理責任者が明確か |
| 基幹連携用アカウント | 停止時の業務影響、代替処理、手動復旧手順があるか |
避けるべきなのは、「管理者が困るから」「問い合わせが増えそうだから」という理由だけで広範囲に除外することです。自動攻撃中断は攻撃の初動を止める機能なので、特権IDの除外は攻撃者に逃げ道を与える場合があります。
デバイスグループの除外
デバイスグループの除外では、グループ単位で自動化レベルを調整します。Microsoft Learnでは、重要インフラ、レガシーシステム、ミッションクリティカルなアプリケーションを実行するデバイスなどが例として挙げられています。(Microsoft Learn)
設定できる自動化レベルは、次のように整理できます。
| 自動化レベル | 意味 | 向いているケース |
|---|---|---|
| Full – remediate threats automatically | 脅威検出時に自動修復を行う | 標準端末、一般的な業務PC、サーバー以外の管理端末 |
| Semi – require approval for core folders | コアシステムフォルダーの修復には承認が必要 | OS領域への変更を慎重に扱いたい端末 |
| Semi – require approval for non-temp folders | 一時フォルダーやダウンロードフォルダー以外の対応に承認が必要 | 業務アプリのフォルダー変更を慎重に扱いたい端末 |
| Semi – require approval for all folders | すべての修復に承認が必要 | 自動修復の影響を人が確認したい端末 |
| No automated response | 自動調査・自動対応を行わない | ごく一部の重要端末。ただし原則は限定利用 |
注意すべき点は、デバイスグループを自動対応から除外すると、攻撃中断だけでなくAutomated Investigation and Response、つまり自動調査と対応のアクションにも影響することです。(Microsoft Learn)
そのため、デバイスグループ除外は「サーバーだから全部除外」「役員PCだから全部除外」といった単純な分類で決めるべきではありません。端末の重要度、侵害時の影響、監視の代替策、復旧手順をセットで評価する必要があります。
IPアドレスの除外
IPアドレスの除外は、特定のIPアドレス、IP範囲、サブネットが自動的に封じ込められることを防ぐ設定です。Microsoft Learnでは、重要インフラのIP範囲、レガシーシステム、外部サービスなどが例として示されています。(Microsoft Learn)
IP除外は便利ですが、管理が甘いと危険です。特に、次のような設定は避けるべきです。
| 避けたい設定 | 問題点 |
|---|---|
| 広すぎるサブネットを除外する | 攻撃者がその範囲内で活動した場合、自動封じ込めが効きにくくなる |
| 一時的な検証環境のIPを残し続ける | 利用終了後も例外が残り、攻撃面が広がる |
| 外部ベンダーのIPを根拠なく除外する | ベンダー側の変更や侵害時に検知・対応が遅れる可能性がある |
| 名前やメモを空欄に近い形で作成する | 後から棚卸しできず、不要な例外を削除できない |
IP除外を作る場合は、名前とメモに「理由」「依頼部署」「期限」「代替監視」を必ず残す運用にするのが現実的です。
Policy applications and exclusions（Preview）
今回の内容で特に注目したいのが、Previewとして記載されている「Policy applications and exclusions」です。これは、タグを使ってデバイス群を定義し、そのタグに対して特定の攻撃中断ポリシー制御を無効化する仕組みです。Microsoft Learnでは、動的タグを使って複数デバイスをグループ管理し、ほとんどの中断制御を有効にしたまま、特定の制御だけを選択的に無効化できると説明されています。(Microsoft Learn)
従来の「このデバイスグループは自動対応を弱める」という考え方よりも、細かい制御に向いています。
たとえば、次のような使い方が考えられます。
| シーン | 使い方の例 |
|---|---|
| 製造ライン端末 | 製造部門の端末に動的タグを付け、特定の封じ込め制御だけを除外する |
| 監視サーバー | 監視継続が必要なサーバー群をタグ化し、完全除外ではなく一部制御の除外に留める |
| レガシーOS端末 | OSやデバイス属性を条件に動的タグを作り、例外対象を自動管理する |
| 検証用端末 | 一定条件に一致する検証端末だけに限定的なポリシーを適用する |
Preview機能は仕様や管理画面が変わる可能性があります。そのため、本番環境で使う場合は、小さい範囲で検証し、変更履歴と復旧手順を用意してから展開するのが安全です。
必要な権限：Unified RBACの有効・無効で確認ポイントが変わる
除外設定の管理権限は、Microsoft Defender XDR Unified RBACが対象ワークロードで有効かどうかによって変わります。Microsoft Learnでは、デバイス除外とID除外について、Unified RBACの状態に応じた必要権限が整理されています。(Microsoft Learn)
整理すると、実務上は次のようになります。
| 対象 | Unified RBACの状態 | 必要な権限の考え方 |
|---|---|---|
| デバイス除外 | 無効 | Security AdministratorまたはGlobal Administrator |
| デバイス除外 | 有効 | Security Operator以上のグローバルMicrosoft Entraロール、またはUnified RBACのCore security settings（manage）権限 |
| ID除外 | ID・エンドポイントともに無効 | Security AdministratorまたはGlobal Administrator |
| ID除外 | IDまたはエンドポイントで有効 | Security Operator以上のグローバルMicrosoft Entraロール、またはUnified RBACのCore security settings（manage）権限 |
Security Readerは除外やタグを表示できますが、編集はできません。(Microsoft Learn)
ここで重要なのは、「ポータルが見えること」と「除外を編集できること」は別だという点です。SOC担当者に閲覧だけを許可し、除外の作成・変更・削除は限られた管理者だけに許可する運用が望ましいです。
なお、Microsoft Defender Unified RBACは、Microsoft Defender XDR、Defender for Endpoint、Defender for Identity、Defender for Office 365など複数サービスの権限管理を一元化するモデルです。Microsoft Learnでは、2025年以降、新しいDefender for EndpointテナントおよびDefender for IdentityテナントではUnified RBACが既定の権限モデルになると説明されています。(Microsoft Learn)
設定変更の手順
ここでは、管理者が確認しやすいように、Microsoft Defenderポータルでの主な設定手順を整理します。
ユーザーアカウントを除外する手順
ユーザーアカウントを自動対応から除外する流れは次の通りです。
| 手順 | 操作 |
| -: | ————————————— |
| 1 | Microsoft Defenderポータルにサインインする |
| 2 | Settings > Microsoft Defender XDR に移動する |
| 3 | Automated response で Identities を選択する |
| 4 | Add user exclusion を選択する |
| 5 | 除外するユーザーアカウントを検索・選択する |
| 6 | Exclude users で保存する |
設定後は、除外理由をチケットや変更管理台帳にも残しておくべきです。ポータル上の設定だけでは、「誰が、なぜ、いつまで除外したのか」が運用上追跡しにくくなります。
デバイスグループの自動化レベルを変更する手順
デバイスグループを対象にする場合は、単純な除外というより、自動化レベルを調整する操作になります。
| 手順 | 操作 |
| -: | ————————————— |
| 1 | Microsoft Defenderポータルにサインインする |
| 2 | Settings > Microsoft Defender XDR に移動する |
| 3 | Automated responses で Devices を選択する |
| 4 | Device groups タブで対象グループを選択する |
| 5 | フライアウトで自動化レベルを選ぶ |
| 6 | Save で保存する |
「No automated response」は分かりやすい反面、最もリスクの高い選択です。まずはSemiレベルで承認を挟む運用が可能かを検討し、それでも業務上許容できない場合だけNo automated responseを検討するのが現実的です。
IPアドレスを除外する手順
IPアドレスの除外では、IPアドレス、IP範囲、サブネットを指定できます。複数のIPやサブネットはカンマ区切りで追加できます。(Microsoft Learn)
| 手順 | 操作 |
| -: | ————————————— |
| 1 | Microsoft Defenderポータルにサインインする |
| 2 | Settings > Microsoft Defender XDR に移動する |
| 3 | Automated responses で Devices を選択する |
| 4 | IP除外の作成操作を行う |
| 5 | IPアドレス、IP範囲、サブネットを入力する |
| 6 | 名前とメモを入力し、Createで保存する |
名前には「EXCL-IP-OT-LineA-2026Q3」のように、用途と期限が分かる命名を使うと棚卸しが楽になります。メモには「依頼部署」「業務影響」「承認者」「見直し予定日」を入れておくと、後から削除判断がしやすくなります。
タグベースのポリシー適用除外を作成する手順
Policy applications and exclusionsを使う場合は、先にタグを作成し、そのタグに対してポリシー適用ルールを作成します。
| 手順 | 操作 |
| -: | —————————————————- |
| 1 | Microsoft DefenderポータルのAsset rule managementでタグを作成する |
| 2 | デバイス種別、OS、その他属性などを条件に動的ルールを定義する |
| 3 | Settings > Microsoft Defender XDR に移動する |
| 4 | Automated responses > Devices を開く |
| 5 | Policy application タブで Create rule を選択する |
| 6 | ポリシー名と説明を入力する |
| 7 | 適用するタグを選択する |
| 8 | 無効化したい除外ポリシー制御を設定する |
| 9 | 内容を確認して送信する |
この方式の利点は、個別端末を手作業で例外管理するのではなく、条件に基づいて対象を管理できることです。端末の入れ替えが多い組織では、静的なリストよりも運用負荷を抑えやすくなります。
移行期限はあるのか
2026年6月28日時点の対象Microsoft Learnページでは、「Exclude assets from automated response in attack disruption」自体について、特定の日付までに移行が必要だとする期限は示されていません。確認すべきなのは、移行期限よりも、現在のテナントでUnified RBACが有効か、既存のRBACモデルで誰が除外を編集できる状態か、そして既存のデバイスグループ自動化レベルがどうなっているかです。(Microsoft Learn)
一方で、Unified RBACについては、2025年以降の新しいDefender for EndpointテナントおよびDefender for Identityテナントで既定の権限モデルになることがMicrosoft Learnに記載されています。既存テナントでは、過去に割り当て・エクスポートされたロールと権限構成を維持するケースがあるため、自社テナントの状態を確認する必要があります。(Microsoft Learn)
つまり、管理者が確認すべきポイントは次の3つです。
| 確認項目 | 理由 |
|---|---|
| Unified RBACが有効か | 除外設定を編集できる権限が変わるため |
| 既存の除外があるか | 不要な例外が残っていると自動防御の穴になるため |
| デバイスグループの自動化レベル | 攻撃中断だけでなく自動調査・対応にも影響するため |
「移行期限がないから何もしなくてよい」ではなく、「除外と権限の棚卸しを今行うべき」と考えるのが適切です。
管理者が最初に確認すべきチェックリスト
Microsoft Defenderの運用管理者は、設定変更前に次のチェックリストを確認してください。
| チェック項目 | 確認内容 |
|---|---|
| ライセンス | 自動攻撃中断に必要なMicrosoft Defender関連ライセンスを満たしているか |
| Defender製品の展開状況 | Defender for Endpoint、Defender for Identity、Defender for Office 365、Defender for Cloud Appsなど必要な製品が展開済みか |
| デバイス検出 | Defender for Endpointのデバイス検出やオンボード状態に問題がないか |
| Sense Agentバージョン | Contain Userアクションに必要なSense Agentのバージョンを満たしているか |
| ID連携 | Active Directory、Microsoft Entra ID、同期アカウントの動作を理解しているか |
| 監査ログ | メールボックス監査やドメインコントローラー監査が有効か |
| 権限 | 除外を編集できる管理者が過剰に多くないか |
| 変更管理 | 除外の理由、期限、承認者を記録する仕組みがあるか |
| 復旧手順 | 自動対応後に端末やIDを復旧する手順が整備されているか |
| 通知 | 自動対応が発生したときにSOCや管理者へ通知されるか |
自動攻撃中断の設定には、対象サブスクリプション、Defender製品の展開、Defender for Endpointの標準検出、外部プラットフォーム連携時のMicrosoft Sentinel構成など、複数の前提条件があります。Microsoft Learnでは、自動攻撃中断を構成するための前提条件として、Microsoft 365 E5/A5、Defender for Endpoint Plan 2、Defender for Identity、Defender for Cloud Apps、Defender for Office 365 Plan 2などの関連ライセンスや展開条件が説明されています。(Microsoft Learn)
除外すべき資産と除外すべきでない資産の判断基準
除外の判断で迷った場合は、「業務影響」と「侵害時リスク」を分けて考えると整理しやすくなります。
| 資産タイプ | 除外を検討しやすい条件 | 除外を避けたい条件 |
|---|---|---|
| 緊急管理者アカウント | 通常利用されず、厳格な監査と保管手順がある | 日常的に管理作業で使っている |
| サービスアカウント | 人のサインインが禁止され、権限が限定されている | 広範な管理権限を持ち、利用実態が不明 |
| 重要サーバー | 停止すると重大な業務停止が起き、別の監視策がある | 重要という理由だけで監視・復旧設計がない |
| OT・工場系端末 | 自動分離が物理設備へ影響し、運用チームと合意済み | ネットワーク分離や代替検知がない |
| 外部サービスIP | 固定IPで契約・用途・期限が明確 | ベンダー任せで変更管理されていない |
| 検証端末 | 期限付きで例外が必要 | 検証終了後も放置される |
独自の観点として、除外対象は「重要度が高い資産」ではなく、「自動対応を止めても総合リスクを下げられる資産」と定義するのがおすすめです。重要な資産ほど攻撃者にも狙われるため、重要だから除外するという判断は逆効果になることがあります。
よくある失敗と対策
例外設定を作ったまま棚卸ししない
最も多い失敗は、一時対応で作った除外がそのまま残ることです。特にIP除外や検証端末の除外は、時間が経つと作成理由が分からなくなります。
対策として、除外設定には必ず期限を設定し、月次または四半期ごとに見直します。ポータル上のメモだけでなく、変更管理チケットや運用台帳にも記録しておくと、監査時にも説明しやすくなります。
デバイスグループ除外の影響を過小評価する
デバイスグループの自動化レベルを下げると、攻撃中断だけでなく自動調査・対応にも影響する場合があります。(Microsoft Learn)
「このサーバーは止められない」という判断だけでNo automated responseにすると、攻撃発生時に調査や修復の初動も遅れる可能性があります。まずSemiレベルで承認を挟む運用を検討し、完全に自動対応を止める範囲は最小限にすべきです。
Break Glassアカウントを通常利用している
緊急用アカウントを除外すること自体は検討対象になりますが、そのアカウントを日常運用で使っている場合は危険です。攻撃者がそのアカウントを侵害したとき、自動無効化の対象外になり、被害が拡大する可能性があります。
Break Glassアカウントは、通常業務では使わず、利用時には必ず通知・記録される設計にします。利用後の資格情報ローテーションも手順化しておくべきです。
IP範囲を広く取りすぎる
IP除外でサブネットを広く指定すると、意図しない端末や将来追加される端末まで除外対象になる可能性があります。
対策として、除外はできるだけ狭い範囲で設定します。ネットワーク変更が多い組織では、IP除外だけに頼らず、デバイスタグやデバイスグループを組み合わせて管理すると安全です。
オプトアウトを安易に選ぶ
Microsoft Learnでは、自動攻撃中断からのオプトアウトはセキュリティリスクを大きく高める可能性があり、代わりに特定エンティティの除外を検討するよう説明されています。どうしてもオプトアウトする場合は、Microsoft Defenderポータルでサポートケースを開き、件名に「Attack disruption opt-out」を指定する流れです。(Microsoft Learn)
全体オプトアウトは、セキュリティ運用の例外中の例外です。通常は、個別のユーザー、デバイスグループ、IP、タグベースのポリシー除外で要件を満たせないかを先に検討します。
グローバル組織での運用ポイント
グローバル企業や複数リージョンでMicrosoft Defenderを運用している組織では、除外設定を各国・各拠点任せにしないことが重要です。
たとえば、日本拠点では重要システムとして除外したサーバーが、欧州拠点では通常サーバーとして扱われている場合、インシデント時の対応方針が分裂します。また、SOCがグローバルで統合されている場合、どの除外がどの国の判断で作られたのか分からないと、対応判断が遅れます。
最低限、次の情報は共通フォーマットで管理しましょう。
| 管理項目 | 記録例 |
|---|---|
| 除外タイプ | User、Device group、IP、Policy application |
| 対象 | アカウント名、デバイスグループ名、IP範囲、タグ名 |
| 対象リージョン | Japan、APAC、EMEA、Globalなど |
| 業務理由 | 基幹決済システム、工場制御端末、監視基盤など |
| セキュリティ代替策 | 24時間監視、ネットワーク分離、手動封じ込め手順など |
| 承認者 | CISO、SOC Manager、業務責任者など |
| 有効期限 | 2026-09-30など |
| レビュー頻度 | 月次、四半期、半期 |
除外設定は、技術設定であると同時にリスク受容の記録でもあります。セキュリティ部門だけで決めず、業務責任者、IT運用、SOC、監査部門が確認できる形にしておくと、後の説明責任を果たしやすくなります。
管理者が次に取るべき行動
まず、Microsoft Defenderポータルで現在の除外設定を確認します。特に、ユーザー除外、デバイスグループの自動化レベル、IP除外、Policy applicationタブのルールを確認し、不要な例外がないかを洗い出してください。
次に、除外を次の3分類に分けます。
| 分類 | 対応 |
|---|---|
| 継続する除外 | 理由、承認者、期限、代替監視を明記する |
| 一時的な除外 | 期限を設定し、期限到来時に自動的に見直す |
| 不要な除外 | 削除し、自動攻撃中断の対象に戻す |
最後に、新しい除外を作る前の承認フローを整備します。申請者が「業務影響」だけを書くのではなく、「除外しない場合の影響」「除外した場合の侵害リスク」「代替監視」「期限」を必ず記載する形にすると、安易な例外拡大を防げます。
Microsoft Defender XDRの「Exclude assets from automated response in attack disruption」は、業務継続とセキュリティ自動化のバランスを取るための重要な設定です。ただし、例外は増えるほど防御力を下げます。2026年6月28日時点の公式情報を踏まえると、管理者が行うべきことは、除外を増やすことではなく、既存の除外を棚卸しし、必要最小限に絞り、理由と期限を管理することです。
コメント