Linuxサーバーに Microsoft Defender for Endpoint を展開している管理者にとって、今回のポイントは「インストール」と「オンボーディング」を分けて考えていた従来運用を、Defender deployment tool でより簡素化できる点です。2026年5月27日に更新された Microsoft Defender for Endpoint の新機能情報では、Defender deployment tool が Windows と Linux の両方に対応するプレビュー機能として整理されています。ツールは前提条件の確認、オンボーディングの効率化、複雑なスクリプト運用の削減を目的としています。(Microsoft Learn)
ただし、まだプレビュー段階であるため、本番環境へ一括適用する前に、対応ディストリビューション、ネットワーク接続、プロキシ、既存セキュリティ製品との競合、展開後の検証手順を必ず確認する必要があります。この記事では、Linux デバイス向け Defender deployment tool の変更点、影響範囲、管理者が取るべき対応を実務目線で整理します。
Microsoft Defender の Linux 展開で何が変わったのか
Defender deployment tool は、Microsoft Defender for Endpoint を Linux デバイスへ展開するためのプレビュー版ツールです。従来は、Linux に Defender エージェントをインストールし、その後に Microsoft Defender ポータルから取得したオンボーディングパッケージを適用する、というように作業が分かれがちでした。
今回のツールでは、Microsoft Defender ポータルからダウンロードした単一のパッケージを使い、インストールとオンボーディングをまとめて進められます。公式ドキュメントでも、インストーラースクリプトや CLI コマンドで個別にインストールし、その後ポータルのオンボーディングパッケージを別途適用する必要を減らせる、と説明されています。(Microsoft Learn)
特に影響が大きいのは、次のような環境です。
| 対象環境 | 影響 |
|---|---|
| Linux サーバーを多数運用している企業 | 展開手順の標準化、作業ミスの削減が期待できる |
| Ansible、Chef、Puppet、SaltStack などで構成管理している環境 | 既存の自動化基盤に組み込みやすい |
| オンプレミス、クラウド、ハイブリッドで Linux が混在している環境 | Defender 展開方式を統一しやすい |
| 既存の手動オンボーディング手順を使っている環境 | 手順書、検証項目、運用フローの見直しが必要 |
| プロキシや閉域ネットワークに近い構成 | 接続先 URL、プロキシ設定、SSL インスペクション例外の確認が重要 |
管理者が最初に判断すべきことは、「すぐ本番展開するか」ではなく、「このツールを今後の標準展開手段にできるか」です。プレビュー機能のため、まずは検証用サーバーや一部の低リスクな Linux サーバーで動作確認し、既存のインストール方式と比較するのが安全です。
Defender deployment tool でできること
Defender deployment tool は、単に Defender をインストールするだけのスクリプトではありません。前提条件の確認、接続テスト、インストール場所の指定、チャネル選択、特定バージョンの展開、アップグレード、ダウングレード、アンインストール、オンボーディングのみの実行など、運用で必要になりやすい操作をコマンドオプションで扱えます。(Microsoft Learn)
代表的な使い方を整理すると、次のようになります。
| 目的 | 使用する操作の例 | 実務での使いどころ |
|---|---|---|
| 事前チェック | --pre-req、--pre-req-non-blocking | メモリ、ディスク、依存関係などを展開前に確認する |
| 接続確認 | --connectivity-test | ファイアウォールやプロキシで通信が遮断されていないか確認する |
| 通常展開 | sudo bash defender_deployment_tool.sh | 最新の production チャネルのエージェントを導入し、ポータルへオンボードする |
| インストール先指定 | --install-path | 標準パス以外に導入したいサーバーで利用する |
| チャネル指定 | --channel prod、--channel insiders-slow | 本番用と検証用で更新チャネルを分ける |
| バージョン指定 | --mdatp <version> | 検証済みバージョンへそろえて展開する |
| 既存環境の整理 | --upgrade、--downgrade、--remove | バージョン管理や切り戻し、削除に使う |
| オンボーディングのみ | --only-onboard | すでに Defender が入っている端末をポータルへ登録する |
| オフボーディング | --offboard | 管理対象から外す際に使う |
ここで重要なのは、ツールを「初回インストール専用」と見なさないことです。大規模環境では、導入後のアップグレード、切り戻し、チャネル変更、アンインストールまで含めて運用設計する必要があります。
展開前に確認すべき前提条件
Linux 向け Microsoft Defender for Endpoint の導入では、OS、リソース、ネットワーク、権限の条件を満たしている必要があります。公式の前提条件では、CPU は最低 1 コア、ディスクは最低 2GB、メモリは最低 1GB とされています。高負荷ワークロードでは、これ以上のリソースを見込むべきです。(Microsoft Learn)
また、Defender deployment tool 側でも、メモリが 1GB を超えていること、利用可能なディスク容量が 2GB を超えていること、glibc が 2.17 より新しいことなどをチェックし、条件を満たさない場合は展開処理を中止します。(Microsoft Learn)
管理者向けチェックリスト
本番展開前には、最低限次の項目を確認してください。
| 確認項目 | 確認内容 | 見落とした場合のリスク |
|---|---|---|
| ライセンス | Defender for Servers、Defender for Endpoint for servers、Defender for Business servers など、対象に合うライセンスがあるか | オンボーディング後の管理・保護が想定どおり使えない |
| OS サポート | 対象 Linux ディストリビューションとバージョンがサポート対象か | 動作してもサポートを受けにくい |
| CPU・メモリ・ディスク | 最低要件だけでなく、実ワークロードに余裕があるか | スキャン時の性能低下、展開失敗 |
| systemd | Linux サーバーに systemd があるか | エージェント管理に支障が出る |
| ネットワーク | Defender for Endpoint の必要 URL に到達できるか | ポータルに表示されない、定義更新できない |
| プロキシ | 静的プロキシまたは透過プロキシで要件を満たすか | 接続テスト失敗、オンボーディング失敗 |
| 既存セキュリティ製品 | 他の AV、EDR、Fanotify 利用製品と競合しないか | システムハング、検知漏れ、性能劣化 |
| 管理権限 | Linux サーバー上で管理者権限を使えるか | インストールや設定変更ができない |
特に注意したいのは、プロキシと SSL インスペクションです。公式の前提条件では、PAC、WPAD、認証付きプロキシはサポートされず、SSL インスペクションやインターセプト型プロキシもセキュリティ上の理由でサポートされないと説明されています。該当するネットワークでは、Defender for Endpoint の通信を直接通す例外設定が必要です。(Microsoft Learn)
実際の展開手順
Defender deployment tool を使った基本的な流れは、Microsoft Defender ポータルから Linux Server 用のパッケージを取得し、対象サーバーで展開して実行する、というものです。公式手順では、Microsoft Defender ポータルの Settings > Endpoints > Device management > Onboarding から Linux Server（Preview）を選び、パッケージをダウンロードする流れが示されています。(Microsoft Learn)
基本手順は次のとおりです。
| 手順 | 作業 | 管理者が確認すべきこと |
|---|---|---|
| 1 | Defender ポータルから Linux Server 用パッケージをダウンロード | 対象テナントが正しいか確認する |
| 2 | ZIP ファイルを対象 Linux サーバーへ配置 | 配布経路とアクセス権を確認する |
| 3 | unzip GatewayLinuxDefenderDeploymentTool.zip で展開 | 展開後に defender_deployment_tool.sh があるか確認する |
| 4 | chmod +x defender_deployment_tool.sh を実行 | 実行権限が付与されたか確認する |
| 5 | sudo bash defender_deployment_tool.sh を実行 | インストールとオンボーディングの完了を確認する |
| 6 | Defender ポータルのデバイスインベントリを確認 | 表示まで数分から十数分かかる前提で待つ |
ここで避けたい失敗は、ダウンロードしたパッケージを別テナントで使い回すことです。公式ドキュメントでは、このパッケージはエージェントのインストールとオンボーディングを行うテナント固有のパッケージであり、テナントをまたいで使用してはいけないとされています。(Microsoft Learn)
複数テナントを管理している MSP やグループ会社の情報システム部門では、パッケージ名だけで判断せず、「どのテナントから取得したか」「どのサーバー群へ配布するか」を台帳で管理してください。
展開後に必ず実施したい検証
Defender deployment tool を実行しても、それだけで作業完了と判断するのは危険です。展開後は、ポータル登録、リアルタイム保護、検知テスト、EDR イベントの確認まで行う必要があります。
公式手順では、Microsoft Defender ポータルのデバイスインベントリに対象デバイスが表示されるまで 5〜20分程度かかる場合があるとされています。また、リアルタイム保護が有効かどうかを mdatp health --field real_time_protection_enabled で確認し、必要に応じて mdatp config real-time-protection --value enabled で有効化する流れが示されています。(Microsoft Learn)
展開後の確認項目は、次の順番で進めると実務上スムーズです。
| 確認順 | 確認内容 | コマンド・確認場所 |
|---|---|---|
| 1 | エージェントの状態 | mdatp health |
| 2 | リアルタイム保護 | mdatp health --field real_time_protection_enabled |
| 3 | ポータル登録 | Microsoft Defender ポータルのデバイスインベントリ |
| 4 | AV 検知 | EICAR テストファイルを使った検知確認 |
| 5 | 脅威一覧 | mdatp threat list |
| 6 | EDR 検知 | Microsoft Defender XDR のアラート、デバイスタイムライン |
| 7 | ログ確認 | /tmp/defender_deployment_tool.log |
特に本番サーバーでは、検知テストの実施タイミングに注意してください。EICAR のようなテストファイルであっても、監視システムや SOC のアラート運用に影響する場合があります。事前に検証対象、時間帯、通知先を決めてから実施しましょう。
大量展開での注意点
Defender deployment tool は、手動実行だけでなく、Chef、Ansible、Puppet、SaltStack などのサードパーティ製ツールを使った一括オンボーディングにも対応しています。公式ドキュメントでも、手動と大量オンボーディングの両方をサポートすると説明されています。(Microsoft Learn)
ただし、大量展開では「コマンドが実行できるか」よりも「失敗した端末をどう検出し、どう再実行するか」が重要です。
一括展開時の設計ポイント
| 設計項目 | 推奨される考え方 |
|---|---|
| 展開単位 | いきなり全台ではなく、検証用、低リスク本番、一部拠点、全体の順に広げる |
| 失敗時の扱い | 終了コード、ログ、mdatp health の結果を収集する |
| 再実行 | 冪等性を意識し、すでに導入済みの端末で想定外の再インストールが起きないようにする |
| バージョン | 本番は prod、検証は insiders-slow など、チャネルを分ける |
| プロキシ | 拠点やネットワークセグメントごとの差異を事前に洗い出す |
| 台帳 | ホスト名、OS、エージェントバージョン、オンボーディング日時、テナントを記録する |
Ansible で展開する場合は、単にシェルを実行するだけでなく、事前に --connectivity-test を実行し、失敗したサーバーを別リストへ分ける運用が現実的です。通信できない端末に対してインストールだけ成功しても、ポータルに表示されなければ監視対象としては不完全です。
チャネルとバージョン管理の考え方
Defender deployment tool では、prod、insiders-slow、insiders-fast のチャネルを指定できます。公式ドキュメントでは、既定では prod チャネルが構成され、早期機能の検証やフィードバック目的で一部端末を insiders 系チャネルにすることが推奨されています。(Microsoft Learn)
本番環境では、基本的に prod を使うのが安全です。一方で、すべての端末を prod に固定すると、新機能や仕様変更の影響を事前に把握しにくくなります。おすすめは、次のような役割分担です。
| チャネル | 向いている端末 | 注意点 |
|---|---|---|
prod | 本番サーバー、重要業務サーバー | 安定運用向け。原則として本番の標準にする |
insiders-slow | 検証環境、一部の先行確認サーバー | 新機能の影響確認に使う |
insiders-fast | セキュリティ検証チーム、ラボ環境 | 変更頻度が高いため、本番には慎重に扱う |
チャネルを切り替える場合は、単に別チャネルを指定して再実行するだけではありません。公式手順では、現在のチャネルを削除し、既存のリポジトリをクリーンアップしたうえで、新しいチャネルからインストールする流れが示されています。(Microsoft Learn)
既存の Linux Defender 運用への影響
すでに Microsoft Defender for Endpoint on Linux を導入している環境では、今回のプレビュー機能によって直ちに既存環境を移行する必要があるとは限りません。むしろ、既存のインストーラースクリプト、Ansible ロール、ゴールデンイメージ、Defender for Cloud 経由のオンボーディングと、Defender deployment tool の役割を整理することが重要です。
Microsoft Defender for Endpoint on Linux には、Defender deployment tool、インストーラースクリプト、Ansible、Chef、Puppet、SaltStack、ゴールデンイメージ、手動展開、Defender for Cloud での直接オンボーディングなど複数の展開方法があります。公式の前提条件ページでは、Deployment Tool based deployment が推奨の展開方法として挙げられています。(Microsoft Learn)
判断基準は次のとおりです。
| 現在の運用 | 推奨対応 |
|---|---|
| 手動で個別にオンボーディングしている | Defender deployment tool への移行を優先的に検討する |
| Ansible などで安定運用できている | 検証環境でツールを試し、置き換えメリットを確認する |
| Defender for Cloud でサーバー保護を統合している | Defender for Cloud の自動オンボーディング方針と重複しないよう整理する |
| ゴールデンイメージに組み込んでいる | イメージ複製時の端末識別子やオンボーディング手順を再確認する |
| 複数テナントを管理している | テナント固有パッケージの誤配布防止を最優先にする |
移行の目的は「新しいツールを使うこと」ではありません。展開ミスを減らし、検証を自動化し、セキュリティ監視に入っていない Linux サーバーをなくすことです。
セキュリティ製品の競合とパフォーマンスに注意する
Linux サーバーでは、既存のアンチウイルス、EDR、ファイル監視、アプリケーション制御製品がすでに動作していることがあります。特に Fanotify を使うセキュリティ製品との競合は注意が必要です。
公式の前提条件では、Defender for Endpoint on Linux と他の Fanotify ベースのセキュリティソリューションを同時に実行することはサポートされず、システムハングなど予測できない動作につながる可能性があると説明されています。ただし、RHEL と Fedora 系の FAPolicyD については、条件を満たす場合に例外的にサポートされます。(Microsoft Learn)
既存製品と併用する場合は、次の流れで確認しましょう。
mdatp healthで競合アプリケーションの表示を確認する- 既存製品側に Microsoft Defender for Endpoint の除外を設定する
- Defender 側にも必要な除外を設定する
- 本番同等の負荷で CPU、メモリ、I/O、アプリケーション応答時間を測定する
- 初期段階では passive mode の利用も検討する
特に DB サーバー、SAP、コンテナホスト、CI/CD ランナー、ファイルサーバーのように I/O が多い環境では、単に導入できたかどうかではなく、業務負荷時のパフォーマンス確認が欠かせません。
開発者・SRE が確認すべきポイント
Microsoft Defender の Linux 展開は、情報システム部門やセキュリティ担当だけの作業ではありません。開発者や SRE にも影響があります。
たとえば、CI/CD サーバーやビルドエージェントに Defender を導入すると、ビルド成果物、依存パッケージ、コンテナイメージの展開ディレクトリがスキャン対象になります。通常は保護の観点で望ましい一方、短時間に大量のファイルを生成する処理ではパフォーマンス影響が出る場合があります。
開発・運用チームでは、次の観点を確認してください。
| 役割 | 確認すべきこと |
|---|---|
| 開発者 | ビルド、テスト、パッケージ復元、コンテナビルドに遅延が出ないか |
| SRE | 監視アラート、CPU・I/O 使用率、サービス再起動時の影響 |
| セキュリティ担当 | 検知イベントが Defender XDR に上がるか、SOC の運用に乗るか |
| インフラ担当 | プロキシ、DNS、ファイアウォール、リポジトリ到達性 |
| 運用担当 | 障害時のログ取得、アンインストール、オフボーディング手順 |
除外設定を入れる場合は、「遅いからディレクトリごと除外する」という判断は避けるべきです。除外は攻撃者に悪用される可能性があるため、対象パス、プロセス、理由、期限、承認者を記録し、定期的に見直しましょう。
トラブル時に見るべきログと確認コマンド
Defender deployment tool の実行ログは /tmp/defender_deployment_tool.log に記録されます。公式ドキュメントでも、インストールで問題が起きた場合はまずこのログを確認するよう案内されています。(Microsoft Learn)
トラブル時は、次の順に切り分けると原因を見つけやすくなります。
| 症状 | 最初に確認すること | 次の対応 |
|---|---|---|
| インストールが失敗する | /tmp/defender_deployment_tool.log | 前提条件、権限、ディスク容量を確認 |
| ポータルに表示されない | --connectivity-test | URL 許可、プロキシ、DNS を確認 |
| リアルタイム保護が無効 | mdatp health --field real_time_protection_enabled | 設定ポリシーや競合製品を確認 |
| 脅威検知されない | mdatp threat list | 定義更新、スキャン対象、保護モードを確認 |
| 性能が落ちる | CPU、メモリ、I/O、mdatp health | 除外、スキャン設定、ワークロード特性を確認 |
| 既存製品と競合する | mdatp health の conflicting applications | passive mode や相互除外を検討 |
通信の問題が疑われる場合は、ツールの --connectivity-test を使うのが近道です。Defender for Endpoint が必要とする URL へ到達できるかを確認できるため、ネットワーク担当へ依頼する際の根拠にもなります。
本番展開前の推奨アクション
今回の Defender deployment tool は、Linux サーバーの Defender 展開を標準化するうえで有力な選択肢です。一方で、プレビュー機能であること、Linux 環境はディストリビューションやネットワーク構成の差が大きいことから、段階的な導入が前提になります。
管理者が次に取るべき行動は、次の5つです。
- 対象 Linux サーバーの OS、バージョン、CPU、メモリ、ディスク、ネットワーク条件を棚卸しする
- Microsoft Defender ポータルから取得するパッケージがテナント固有であることを運用ルールに明記する
- 検証環境で
--pre-reqと--connectivity-testを実行し、失敗パターンを洗い出す - Ansible などの自動化基盤へ組み込む前に、ログ収集と再実行設計を決める
- 展開後に
mdatp health、EICAR テスト、Defender XDR のアラート確認まで実施する
Defender deployment tool の価値は、Linux への Microsoft Defender 導入を「担当者ごとの手作業」から「検証可能で再現性のある展開プロセス」に変えられる点にあります。まずは少数の Linux サーバーで検証し、接続、性能、検知、運用手順に問題がないことを確認したうえで、段階的に本番展開へ広げるのが現実的です。
コメント