Microsoft Defender for Endpointの「デバイスで応答アクションを実行する」機能は、侵害が疑われる端末をすばやく調査・封じ込めるための管理機能です。結論から言うと、管理者が最初に確認すべきポイントは、利用プラン、対象OS、RBAC権限、ネットワーク分離時の業務影響、重要資産への制限設定の5つです。
2026年5月中旬の公式情報では、従来の「デバイス分離」「調査パッケージ収集」「ウイルス対策スキャン」「アプリ実行制限」に加え、自動攻撃中断、重要資産の封じ込め、未検出デバイスのIP封じ込め、ユーザー封じ込め、予測シールド関連のアクションまで整理されています。Microsoft Learnの該当ページは、英語版では2026年5月14日、日本語版では2026年5月17日の更新表示になっているため、本稿では2026年5月中旬更新として、管理者・SOC担当者・運用自動化を担当する開発者が確認すべき実務ポイントをまとめます。(Microsoft Learn)
Microsoft Defender for Endpointの応答アクションで何ができるのか
Microsoft Defender for Endpointの応答アクションは、Microsoft Defenderポータルのデバイスページから実行できるインシデント対応機能です。アラートを見て終わりではなく、対象デバイスに対して「調査する」「隔離する」「実行を制限する」「自動調査を開始する」といった具体的な対処を行えます。(Microsoft Learn)
主な応答アクションは次のとおりです。
| 応答アクション | 主な用途 | 実務での使いどころ |
|---|---|---|
| タグの管理 | デバイスを論理的に分類する | 重要端末、部門、拠点、調査対象などを識別する |
| 自動調査の開始 | 関連アラートをまとめて調査する | 同一デバイスで複数アラートが発生している場合 |
| ライブ応答セッション | リモートシェルで詳細調査する | フォレンジック調査、ファイル確認、スクリプト実行 |
| 調査パッケージの収集 | 端末状態や痕跡をZIPで取得する | 侵害原因の分析、証跡保全、外部専門家への共有 |
| ウイルス対策スキャン | リモートでクイック/フルスキャンを実行する | マルウェア感染疑いの一次確認 |
| アプリの実行制限 | 信頼されたコード以外の実行を抑止する | 侵害端末で追加ペイロードの実行を防ぎたい場合 |
| デバイスの分離 | 端末をネットワークから切り離す | ランサムウェア、横展開、情報流出の緊急抑止 |
| デバイスの封じ込め | 周辺のオンボード済み端末から特定デバイスへの通信を遮断する | 未管理端末や侵害疑い端末がネットワーク内にある場合 |
| 脅威エキスパートへの相談 | Microsoftの専門家に追加分析を依頼する | 高度な標的型攻撃や判断が難しいインシデント |
| アクションセンター | 実行した応答アクションの履歴と状態を確認する | 成功・失敗・実行者・実行時刻の監査 |
重要なのは、すべての操作を「できるから実行する」のではなく、事前に影響範囲を決めておくことです。特に分離、封じ込め、アプリ実行制限、ライブ応答は業務影響が大きいため、SOCだけで完結させず、IT運用、ネットワーク、業務部門との連絡手順を準備しておく必要があります。
今回の確認ポイントは「自動化」と「高影響アクションの制御」
今回の公式情報で管理者が特に注目すべき点は、応答アクションが単なる手動操作の一覧ではなく、自動攻撃中断や重要資産保護と結び付いた運用機能として整理されていることです。
特に次の項目は、既存運用への影響が大きい領域です。
| 確認ポイント | 影響を受ける担当者 | 確認すべき内容 |
|---|---|---|
| 自動デバイス分離 | SOC、端末管理者 | どの端末が自動分離の対象になるか、解除手順があるか |
| 高価値資産の応答制限 | AD管理者、サーバー管理者 | ドメインコントローラーやADFSなどで高影響アクションを許可するか |
| 選択的分離と除外 | ネットワーク管理者 | 分離中も必要な管理ツールや業務アプリが通信できるか |
| デバイス封じ込め | SOC、ネットワーク管理者 | 未管理端末やIP変更時の動作を理解しているか |
| ユーザー封じ込め | ID管理者、AD管理者 | アカウント無効化との違い、GPO変更の影響を把握しているか |
| API・自動化 | 開発者、SecOpsエンジニア | 制限モード端末に対するAPI実行失敗を処理できるか |
Microsoftの公式情報では、価値の高い資産に対して一部の高影響応答アクションを制限できることが説明されています。ドメインコントローラー、ADFSサーバー、その他Tier 0に相当する重要インフラでは、分離やライブ応答を無条件に許可すると業務停止につながる可能性があります。(Microsoft Learn)
利用プランによる違いを最初に確認する
Microsoft Defender for Endpointの応答アクションは、契約プランによって利用できる範囲が異なります。ここを確認せずに運用手順を作ると、インシデント時に「手順書にはあるが、ポータルにボタンが表示されない」という失敗が起きます。
Defender for Endpoint Plan 1では、手動応答アクションとして、ウイルス対策スキャン、デバイス分離、ファイルの停止と検疫、ファイルをブロックまたは許可するインジケーター追加が含まれます。一方、公式ページで説明されているすべての応答アクションを利用するには、Defender for Endpoint Plan 2を含むサブスクリプションが必要です。また、Microsoft Defender for Businessでは現時点で「ファイルの停止と検疫」アクションは含まれないと説明されています。(Microsoft Learn)
プラン確認で見落としやすい点
運用設計では、次の3つを必ず確認してください。
| 確認項目 | 確認理由 |
|---|---|
| テナントで利用しているライセンス | Plan 1、Plan 2、Defender for Businessで使える応答アクションが異なる |
| 対象デバイスのオンボード状態 | オンボードされていない端末には実行できる操作が限定される |
| 管理者ロール | ライセンスがあっても、権限がなければ操作できない |
特に大企業では、部門ごとにライセンスや端末管理方式が混在していることがあります。全社共通のインシデント対応手順を作る場合は、「標準端末」「役員端末」「サーバー」「開発端末」「工場・店舗端末」のように端末種別ごとに使えるアクションを棚卸ししておくと実用的です。
管理者権限とRBACの確認は必須
デバイス分離などの高影響アクションには、適切なロールとデバイスグループへのアクセス権が必要です。公式情報では、デバイス分離には少なくとも Active remediation actions ロールが必要で、さらにデバイスグループ設定に基づいて対象デバイスへアクセスできる必要があると説明されています。(Microsoft Learn)
また、Microsoftは最小権限の原則を推奨しており、グローバル管理者の利用は緊急時などに限定すべきとしています。新しいMicrosoft Defender for Endpoint顧客では、2025年2月16日以降、Unified Role-Based Access Control、つまりURBACのみを利用できる点も確認が必要です。(Microsoft Learn)
実務でおすすめのロール設計
ロール設計では、次のように職務ごとに権限を分けると、誤操作と権限過多を防ぎやすくなります。
| 役割 | 付与する権限の考え方 | 注意点 |
|---|---|---|
| SOC一次対応 | アラート確認、スキャン、調査パッケージ収集 | 分離やアプリ制限は承認制にする |
| SOC二次対応 | デバイス分離、封じ込め、ライブ応答 | 実行時コメントとチケット番号を必須化する |
| サーバー管理者 | サーバー系デバイスグループへの限定アクセス | ドメインコントローラーなどは高価値資産として別管理する |
| セキュリティ管理者 | ロール、デバイスグループ、除外設定の管理 | 日常対応用アカウントと設定変更用アカウントを分ける |
| 自動化担当 | API実行に必要な最小権限 | 制限モード端末で失敗した場合の例外処理を入れる |
運用上の失敗例として多いのは、SOC担当者全員に強い権限を付けすぎるケースです。分離ボタンを押せる人数が多いほど、誤って基幹端末を隔離するリスクが高まります。分離や封じ込めは「誰が」「どの条件で」「誰に通知してから」実行するかを明文化しておきましょう。
デバイスグループとタグは応答アクション運用の土台になる
Microsoft Defender for Endpointでは、デバイスグループを使って、関連するアラートやデータへのアクセス制御、異なる自動修復設定、デバイス一覧のフィルタリングなどを行えます。デバイスグループは、ドメイン、デバイス名、タグ、OSプラットフォームなどの条件で構成でき、デバイスが複数のグループに一致する場合は最も高いランクのグループに追加されます。(Microsoft Learn)
タグ管理は、単なるラベル付けではありません。インシデント時に「これは止めてよい端末か」「誰に連絡すべき端末か」「自動化対象に含めるか」を判断するための運用情報です。
推奨されるタグ設計の例
| タグ例 | 用途 |
|---|---|
critical-asset | ドメインコントローラー、DNS、DHCP、ADFSなど重要資産 |
executive-device | 役員・経営層端末 |
production-server | 本番サーバー |
dev-endpoint | 開発者端末 |
branch-office | 支店・拠点端末 |
isolation-exclusion-required | 分離時も一部通信が必要な端末 |
restricted-response | 高影響アクションを制限してオンボードした端末 |
デバイスグループにMicrosoft Entraグループを割り当てない場合、そのデバイスグループはポータルアクセス権を持つすべてのユーザーからアクセス可能になるため注意が必要です。また、デバイスグループ設定の変更が反映されるまでに数分かかる場合があります。(Microsoft Learn)
調査パッケージ収集は「証跡保全」として使う
調査パッケージの収集は、侵害疑い端末の状態を把握するための基本アクションです。Windowsデバイスの場合、Autoruns、インストール済みプログラム、ネットワーク接続、Prefetch、プロセス、スケジュールされたタスク、セキュリティイベントログ、サービス、SMBセッション、システム情報、Tempディレクトリ、ユーザーとグループ、サポートログ、収集結果のサマリーレポートなどが含まれます。(Microsoft Learn)
macOSやLinuxでも、インストール済みアプリケーション、ディスクボリューム、開いているファイル、ネットワーク接続、プロセス、ユーザーとグループなど、プラットフォームに応じた情報を収集できます。(Microsoft Learn)
収集前に確認すべきこと
調査パッケージは便利ですが、万能ではありません。公式情報では、デバイスのバッテリー残量が低い場合や従量制課金接続の場合、収集が失敗する可能性があると説明されています。(Microsoft Learn)
実務では、次の順番で判断すると安全です。
| 状況 | 推奨アクション |
|---|---|
| 端末がオンラインで業務影響が小さい | まず調査パッケージを収集し、証跡を確保する |
| ランサムウェアの横展開が疑われる | 先に分離し、その後に調査パッケージやライブ応答で調査する |
| ノートPCでバッテリー残量が少ない | 端末状態を確認し、必要に応じてユーザーへ電源接続を依頼する |
| 重要サーバーで高負荷状態 | 収集タイミングをIT運用と調整する |
| 法務・監査対応が必要 | チケット番号、実行者、収集時刻、保管先を記録する |
調査パッケージは、あとから「何が起きていたか」を説明するための証跡になります。インシデント対応では、調査内容だけでなく、誰がいつ何を実行したかも重要です。アクション実行時のコメント欄には、「理由」「チケット番号」「承認者」「想定される影響」を簡潔に残す運用をおすすめします。
ウイルス対策スキャンはCPU負荷と他社製品との併用を確認する
Microsoft Defender for Endpointからは、対象デバイスに対してリモートでMicrosoft Defender Antivirusスキャンを開始できます。スキャン種別はクイックまたはフルを選択し、実行前にコメントを追加します。スキャン情報はアクションセンターに表示され、デバイスタイムラインにもイベントとして反映されます。(Microsoft Learn)
macOSとLinuxでは、クライアントバージョン101.98.84以降でこのアクションがサポートされています。また、Microsoft Defender Antivirusは、アクティブなウイルス対策ソリューションであるかどうかに関係なく、他のウイルス対策製品と併用してスキャンを実行できます。パッシブモードでも利用可能です。(Microsoft Learn)
スキャン実行時の注意点
スキャンは安全な操作に見えますが、フルスキャンはCPU、ディスクI/O、業務アプリに影響する場合があります。公式情報では、Defender for Endpointの応答アクションからスキャンを実行する場合、ScanAvgCPULoadFactor が適用され、未構成の場合はスキャン中の最大CPU負荷の既定値が50%に制限されると説明されています。(Microsoft Learn)
実務では、次の基準で使い分けるとよいでしょう。
| 状況 | スキャン種別の目安 |
|---|---|
| アラートの一次確認 | クイックスキャン |
| マルウェア感染の可能性が高い | フルスキャン |
| 端末が業務時間中で高負荷 | クイックスキャンまたは時間調整 |
| サーバー・VDI・開発端末 | 事前に業務影響と除外設定を確認 |
| 他社EDRやAVと併用 | 競合やパフォーマンス影響を検証環境で確認 |
アプリの実行制限は強力だが業務アプリ停止に注意する
「アプリの実行を制限する」は、侵害端末で悪意のある可能性があるプログラムの追加実行を防ぐためのアクションです。公式情報では、Microsoftが発行した証明書で署名されたファイルのみ実行を許可するコード整合性ポリシーが適用されると説明されています。(Microsoft Learn)
このアクションは、Windows 10 バージョン1709以降、Windows 11、Windows Server 2019以降のデバイスで利用できます。また、組織でMicrosoft Defender Antivirusを使用していること、Windows Defender Application Controlのコード整合性ポリシー形式と署名要件を満たすことが前提です。(Microsoft Learn)
実行前の判断基準
アプリ実行制限は、攻撃者の追加活動を止めるには有効です。一方で、自社開発アプリ、古い業務アプリ、署名のない管理ツールが動作しなくなる可能性があります。
| 実行してよい可能性が高い場面 | 慎重に判断すべき場面 |
|---|---|
| 端末が明らかに侵害されている | 本番サーバーで業務アプリが稼働中 |
| マルウェアが追加ファイルを実行している | 署名なしの社内ツールが多い端末 |
| ユーザー端末で横展開の兆候がある | 開発者端末でビルドツールを多用している |
| 分離だけでは不十分な場合 | 端末を遠隔復旧できる手段がない場合 |
実行後は、アクションセンターとデバイスタイムラインで状態を確認します。解除も可能ですが、解除手順を知らないまま実行すると復旧が遅れます。運用手順には「実行条件」だけでなく、「解除条件」と「解除後の確認項目」も含めてください。
デバイス分離は最重要アクション。VPN・プロキシ・Hyper-Vに注意
デバイス分離は、侵害された可能性がある端末をネットワークから切り離しつつ、Defender for Endpointサービスとの接続を維持して監視を継続する機能です。横展開、データ流出、ランサムウェア拡散の抑止に有効です。(Microsoft Learn)
ただし、分離は業務影響が大きいアクションです。特に以下の環境では事前検証が必要です。
| 環境 | 注意点 |
|---|---|
| Webプロキシ環境 | PAC、WPAD、静的/直接プロキシ構成を含む環境では、分離から回復できない可能性がある |
| フルトンネルVPN | 分離後にDefender for Endpointクラウドサービスへ到達できない可能性がある |
| Hyper-Vホスト | ホストを分離すると、子仮想マシンへのネットワークトラフィックもブロックされる |
| macOS/Linux | 通知や除外機能の挙動がWindowsと異なる場合がある |
| Linux | iptables、ip6tables、必要なカーネル構成を確認する |
| オフライン端末 | 分離アクションは最大3日間再試行されるが、それ以降は再実行が必要 |
公式情報では、Webプロキシ環境では選択的分離の利用、フルトンネルVPN環境ではMicrosoft Defender for EndpointおよびMicrosoft Defender Antivirusのクラウドベース保護関連トラフィックに対するスプリットトンネリングVPNの利用が推奨されています。(Microsoft Learn)
分離前に作るべき確認フロー
デバイス分離は、次のようなフローで判断すると実務に落とし込みやすくなります。
| 手順 | 確認内容 |
|---|---|
| 影響度確認 | 対象端末が役員端末、本番サーバー、Hyper-Vホスト、ドメインコントローラーではないか |
| 通信確認 | VPN、プロキシ、管理ツール、リモートサポート経路を確認する |
| 承認確認 | SOC二次対応者、IT運用責任者、業務部門の承認ルールに合っているか |
| 実行 | コメントに理由、チケット番号、承認者を記録して分離する |
| 状態確認 | アクションセンター、デバイスタイムライン、インシデントのアクティビティを確認する |
| 復旧 | 調査・修復完了後、分離解除し通信・業務アプリを確認する |
分離しただけで対応完了ではありません。分離は「被害拡大を止めるための時間を稼ぐ操作」です。分離後に調査、駆除、資格情報リセット、永続化手段の確認、再発防止策まで進める必要があります。
選択的分離と分離除外は便利だがリスクも増える
選択的分離は、分離状態を維持しながら、特定のプロセス、IPアドレス、サービスなどの通信を許可する機能です。リモート修復ツール、監視ツール、業務継続に必要なアプリの通信を残したい場合に役立ちます。(Microsoft Learn)
ただし、除外は隔離の穴になります。公式情報でも、除外はデバイス分離を弱め、セキュリティリスクを増やすため、厳密に必要な場合のみ設定し、定期的に見直すべきとされています。(Microsoft Learn)
分離除外で特に注意すべき変更
分離除外機能を有効にすると、従来組み込まれていたMicrosoft Teams、Outlook、Skypeの除外は適用されなくなり、除外リストは全プラットフォームで空の状態から始まります。TeamsやOutlookを分離中も使わせたい場合は、手動で除外ルールを定義する必要があります。また、Skypeは非推奨となっており、既定の除外には含まれません。(Microsoft Learn)
除外ルール設計の実務ポイント
| 設計項目 | 推奨 |
|---|---|
| ルール名 | 目的が分かる名前にする。例：allow-remote-support-outbound |
| 説明 | 誰の承認で、どの業務に必要かを記録する |
| プロセスパス | 実行ファイルが存在しないとルールが無視される点に注意する |
| サービス名 | PowerShellの Get-Service で短いサービス名を確認する |
| リモートIP | 可能な限り範囲を狭くする。広いCIDR指定を避ける |
| 方向 | 通信開始元を考え、Inbound/Outboundを正しく指定する |
| 定期レビュー | 業務変更やツール廃止時に削除する |
分離除外の変更は、すでに分離されている端末には反映されません。更新後の除外ルールを適用するには、対象端末を一度分離解除し、再度分離する必要があります。(Microsoft Learn)
自動デバイス分離はプレビュー機能として慎重に扱う
自動デバイス分離は、自動攻撃中断の一部として、侵害が疑われるデバイスをDefender for Endpointが自動的に分離する機能です。侵害端末をネットワークから切り離し、横展開、データ流出、ランサムウェア拡散などのリスク低減を狙います。(Microsoft Learn)
ただし、公式情報ではこの機能はプレビューとして扱われており、自動デバイス分離はDefender for Endpointにオンボードされ、管理されているエンドユーザーワークステーションでのみ機能すると説明されています。(Microsoft Learn)
管理者が確認すべき3つの観点
| 観点 | 内容 |
|---|---|
| 対象範囲 | どの端末が自動分離の対象になり得るか |
| 解除手順 | 調査・修復後に誰が分離を解除するか |
| 除外設計 | 業務停止が許容できない端末を自動攻撃中断の除外に入れるか |
自動分離は、インシデントに関係する特定デバイスを対象とするスコープ付きアクションであり、時間制限付きで自動的に元に戻ることがあります。セキュリティオペレーターは、インシデントの文脈を確認し、安全と判断できる場合に分離解除などの後続アクションを実行できます。(Microsoft Learn)
高価値資産では応答アクション制限を検討する
ドメインコントローラー、ADFSサーバー、DNS、DHCPなどの重要資産では、通常のユーザー端末と同じ応答アクションを許可すると危険です。Microsoftは、Selective Response Actionsという機能により、Tier 0システムや高価値資産に対する高影響セキュリティ操作を制御できると説明しています。(Microsoft Learn)
この機能では、テナント側で機能を有効化したうえで、Defender deployment toolを使って制限付きセキュリティ操作設定を持つオンボードパッケージを作成します。フル機能のオンボードと、制限付き機能のオンボードを選べる点が重要です。(Microsoft Learn)
制限できる主な操作カテゴリ
| カテゴリ | 含まれる操作の例 |
|---|---|
| Basic response | ウイルス対策スキャン、ファイル収集、調査パッケージ収集 |
| Advanced response | デバイス分離、アプリ実行制限、修復要求 |
| Live response | ライブ応答セッション |
| Device protection | 自動調査と修復、AIR |
制限付きモードでオンボードされたデバイスでは、検出、アラート、センサー範囲には影響しません。一方で、Live Responseのスクリプト実行は、Live Responseを有効にしていても設計上無効になります。(Microsoft Learn)
重要な移行上の注意点
一度制限付き設定でオンボードしたデバイスのセキュリティ操作設定は、あとから変更できません。応答機能を変更するには、対象デバイスをオフボードし、新しい設定のオンボードパッケージで再オンボードする必要があります。デバイスIDは同じままで、履歴データは保持されます。(Microsoft Learn)
この仕様は、移行計画に大きく影響します。いきなり本番の重要サーバーへ適用するのではなく、代表的なサーバー種別ごとに検証し、次のような一覧を作ることをおすすめします。
| 資産種別 | 推奨方針 |
|---|---|
| ドメインコントローラー | 分離やライブ応答を無条件許可しない。制限付きオンボードを検討 |
| DNS/DHCPサーバー | 業務影響を評価し、封じ込め・分離の承認手順を明確化 |
| ADFS/認証基盤 | ID管理チームと共同で解除手順を作成 |
| 本番DBサーバー | アプリ影響、バックアップ、復旧手順を確認 |
| 一般ユーザー端末 | 標準の応答アクションを許可し、自動化対象にしやすい |
デバイス封じ込めは「未管理端末」対策として有効
デバイス分離はオンボード済みデバイス自体を切り離す操作ですが、デバイス封じ込めは、侵害された可能性がある未管理デバイスとの通信を、オンボード済みデバイス側でブロックする考え方です。公式情報では、デバイスを封じ込めると、Microsoft Defender for Endpointにオンボードされたデバイスが、そのデバイスとの受信・送信通信をブロックすると説明されています。(Microsoft Learn)
これは、社内ネットワークに未管理端末、持ち込み端末、古い機器、オンボード漏れ端末がある環境で有効です。
封じ込め時の注意点
| 注意点 | 内容 |
|---|---|
| 対象数 | Microsoftは任意の時点で最大100台までの封じ込めを推奨している |
| 反映時間 | 新しく封じ込めたデバイスの詳細がオンボード済みデバイスへ届くまで最大5分かかる場合がある |
| IP変更 | 封じ込め対象のIPが変わると、新しいIPへのブロックが始まり、元のIPはブロックされなくなる |
| IP重複 | 同じIPを別デバイスが使っている場合、警告が表示される |
| ネットワーク機器 | ルーターなどを封じ込めると接続障害につながる可能性がある |
| BFEサービス | 期待どおり動作しない場合、Base Filtering Engineサービスを確認する |
封じ込めは強力ですが、ネットワーク機器や共有IPを誤って対象にすると、広範囲に影響します。SOC手順では、封じ込め前に「対象がエンドポイントか、ネットワーク機器か」「IPが共有されていないか」を確認するステップを入れてください。
ユーザー封じ込めはアカウント無効化とは異なる
ユーザー封じ込めは、侵害された可能性があるIDの悪用を、エンドポイント層で抑止する機能です。公式情報では、Defender for EndpointはIDプロバイダー上のアカウントを無効化するのではなく、保護されたデバイス上で侵害IDの利用をブロックし、認証ベースのアクセス、ファイルシステムアクセス、ネットワーク通信パスを制限すると説明されています。(Microsoft Learn)
具体的には、ネットワークログオン、RPC、SMB、RDPなど攻撃に関連するプロトコルの受信トラフィックをブロックし、進行中のリモートセッションや既存のRDP接続を終了します。自動攻撃中断によってユーザーが封じ込められた場合、今後5日間で自動的に封じ込めから削除されると説明されています。(Microsoft Learn)
AD管理者が特に注意すべき点
ドメインコントローラーに対してユーザー封じ込めアクションが適用されると、Default Domain Controller PolicyでGPO更新が開始され、ドメインコントローラー間で同期が発生します。これは想定された動作ですが、AD GPO変更を監視している環境では通知が出る可能性があります。解除時にもGPO変更が以前の状態に戻り、再度同期が発生します。(Microsoft Learn)
ユーザー封じ込めの解除には、Microsoft Entra権限のグローバル管理者ロールが必要とされています。グローバル管理者は強い権限であるため、緊急対応アカウント、承認フロー、監査ログ確認を事前に整えておきましょう。(Microsoft Learn)
ネットワーク接続とプロキシ設定は展開前に検証する
応答アクションを正しく使うには、Defender for Endpointクラウドサービスとの接続が維持されている必要があります。Microsoftは、簡素化された接続方式として *.endpoint.security.microsoft.com などの簡素化ドメインや、静的IP範囲による接続構成を説明しています。(Microsoft Learn)
この簡素化接続方式は、Defender for Endpointの機能やエンドユーザー体験を変更するものではなく、利用するURLやIPが変わるものです。既存の標準接続URLは廃止予定ではなく、標準接続でオンボードされたデバイスは引き続き機能します。(Microsoft Learn)
プロキシ・TLS検査で確認すべきこと
公式情報では、サービス接続は証明書ピンニングとTLSを使用し、トラフィック検査はサポートされないと説明されています。また、接続はデバイス起点であり、ユーザー起点ではないため、プロキシのユーザー認証を強制すると接続が壊れる可能性があります。(Microsoft Learn)
Linuxでは、PAC、WPAD、認証プロキシはサポートされず、SSLインスペクションやインターセプトプロキシもセキュリティ上の理由でサポートされません。Linux端末を分離やスキャンの対象にする場合は、静的または透過プロキシ構成を含め、事前に接続性を確認してください。(Microsoft Learn)
開発者・SecOpsエンジニアが確認すべきAPIと自動化の注意点
応答アクションをSOAR、チケットシステム、社内ポータルから実行している場合、今回の情報は開発者にも影響します。
高価値資産の応答アクション制限では、制限されたアクションをPublic APIから実行しようとすると、そのデバイスでは操作が許可されていないことを示すエラーが返されます。また、高度なハンティングの RestrictedDeviceSecurityOperations プロパティで、どのセキュリティ操作が制限されているかを確認できます。(Microsoft Learn)
自動化で実装すべき例外処理
| 自動化対象 | 実装すべき処理 |
|---|---|
| デバイス分離API | 対象が制限モードか、高価値資産か、デバイスグループ権限があるかを確認する |
| 選択的分離API | IsolationType をSelectiveに設定し、除外ルールが想定どおりか確認する |
| 調査パッケージ収集 | 失敗時にバッテリー、従量制接続、オフライン状態を確認する |
| アクションセンター連携 | 成功・失敗・保留の状態をチケットに反映する |
| ユーザー封じ込め調査 | DeviceEvents テーブルで contain から始まるアクションタイプを検索する |
| 高価値資産 | 自動実行ではなく、承認待ちに切り替える |
自動化のゴールは、対応を速くすることだけではありません。誤操作を防ぎ、監査に耐える形で「なぜその操作をしたか」を残すことも重要です。分離や封じ込めを自動化する場合は、必ず手動解除手順と緊急連絡先をセットで整備してください。
展開前チェックリスト
Microsoft Defender for Endpointの応答アクションを本番展開・運用見直しする前に、次の項目を確認してください。
| チェック項目 | 確認内容 |
|---|---|
| ライセンス | Plan 1、Plan 2、Defender for Businessのどれか |
| 対象OS | Windows、macOS、Linux、Windows Server、Azure Stack HCIのサポート範囲 |
| エージェント状態 | オンボード済みか、Defender for Endpointに正常報告しているか |
| RBAC/URBAC | 最小権限で応答アクションを実行できるか |
| デバイスグループ | 端末種別、部署、重要度ごとに整理されているか |
| タグ | 重要資産、分離除外、制限付き応答の識別に使えているか |
| プロキシ/VPN | 分離後もDefenderクラウドへ到達できるか |
| 分離除外 | Teams、Outlook、管理ツールなど必要通信を手動定義しているか |
| 高価値資産 | 制限付きオンボードや承認制を検討しているか |
| アクションセンター | 実行履歴、失敗、保留を確認する運用があるか |
| 自動化 | API失敗、制限モード、オフライン端末への例外処理があるか |
| 解除手順 | 分離、封じ込め、アプリ制限、ユーザー封じ込めの解除条件が明確か |
よくある失敗と回避策
分離した端末を復旧できない
プロキシ、VPN、クラウド接続の設計が不十分な場合、端末を分離したあとに復旧操作が難しくなることがあります。特にフルトンネルVPN環境やPAC/WPADを使う環境では、選択的分離やスプリットトンネル設計を事前に検証してください。
重要サーバーを通常端末と同じ扱いにしてしまう
ドメインコントローラーや認証基盤に対して、ユーザー端末と同じ分離ポリシーを適用すると、業務停止につながる可能性があります。重要資産はタグとデバイスグループで分け、高影響アクションの制限や承認フローを入れてください。
分離除外を広く設定しすぎる
「復旧しやすくするため」に広いIP範囲や多数のプロセスを除外すると、分離の効果が弱まります。除外は必要最小限にし、期限付きでレビューする運用が必要です。
アクションの実行理由が残らない
緊急対応時にコメントを空欄にしたり、「対応のため」とだけ書いたりすると、後から判断根拠を追えません。コメントには、チケット番号、実行理由、承認者、想定影響を残しましょう。
API自動化が制限モード端末で失敗する
高価値資産を制限付きモードでオンボードしている場合、Public APIから制限された応答アクションを実行すると失敗します。自動化側で RestrictedDeviceSecurityOperations を確認し、承認フローや手動対応に切り替える実装が必要です。
管理者が次に取るべき対応
Microsoft Defender for Endpointの応答アクションは、インシデント対応の速度を大きく高める一方で、誤った実行が業務停止につながる強力な機能です。まずは、現在のテナントで利用できる応答アクション、対象OS、RBAC、デバイスグループ、ネットワーク接続を棚卸ししてください。
次に、重要資産と一般端末を分け、分離・封じ込め・アプリ実行制限・ユーザー封じ込めの実行条件と解除条件を手順化します。最後に、SOCや自動化システムで使うAPIについて、制限モード、オフライン端末、プロキシ/VPN環境での失敗パターンを検証しておくと、実際のインシデント時に迷わず対応できます。
コメント