Microsoft Defender for Endpoint on Linuxの公式情報は、LinuxサーバーをMicrosoft Defenderで保護している管理者にとって、展開方法・対応機能・更新管理・パフォーマンス対策を見直すべき内容です。結論から言うと、今回確認すべきポイントは「Deployment Toolを前提にした展開」「Linuxで使える応答アクションと使えない機能の切り分け」「9か月で期限切れになるエージェント更新」「高I/Oワークロードへの影響」「オフライン環境のセキュリティインテリジェンス更新」です。Microsoft Learnの該当ページは英語版で2026年5月18日、日本語版で2026年5月20日の更新表示があり、GitHub上のドキュメント履歴でも2026年5月18日の更新コミットが確認できます。(Microsoft Learn)
この記事では、Microsoft Defender for Endpoint on Linuxの最新公式情報をもとに、Linuxサーバー管理者、SOC担当者、DevOps担当者が実務で確認すべき影響範囲と対応ポイントを整理します。
Microsoft Defender for Endpoint on Linuxの更新でまず押さえるべきこと
Microsoft Defender for Endpoint on Linuxは、Linuxサーバー上の高度な脅威を防止、検出、調査、対応するためのエンドポイント保護機能です。脆弱性管理、次世代ウイルス対策、EDR、高度なハンティング、デバイス分離、Live Responseなどを利用できますが、Windows版と完全に同じ機能セットではありません。Linuxでは、自動調査と応答、EDR in block mode、ファイルやプロセスのブロック・停止・検疫などは利用できないため、運用手順をWindows前提で流用しないことが重要です。(Microsoft Learn)
| 確認項目 | 管理者が見るべきポイント | 放置した場合のリスク |
|---|---|---|
| 対応機能 | Linuxで利用できる機能とプレビュー機能を切り分ける | Windowsと同じ対応ができると誤解し、インシデント対応が遅れる |
| 展開方法 | Deployment Toolベースの展開を優先する | 手動作業が増え、オンボード漏れや設定差分が発生する |
| 更新管理 | エージェントの期限切れ、チャネル、バージョンを確認する | 修正や機能改善を受けられず、ヘルス状態が悪化する |
| ネットワーク | プロキシ、SSLインスペクション、接続先URLを確認する | クラウド連携、定義更新、テレメトリ送信が失敗する |
| 高I/Oワークロード | Jenkins、Jira、OracleDB、Postgresなどの影響を検証する | CPU・ディスクI/O負荷が増え、業務アプリの性能低下につながる |
2026年5月更新で明確化された主な変更点
2026年5月のドキュメント更新では、製品そのものの緊急修正というより、Linux版Microsoft Defender for Endpointの機能範囲と運用上の注意点がより明確に整理されています。特に重要なのは、ネットワーク保護とWeb保護がLinuxではプレビューであること、カスタムIP・URLベースの侵害インジケーターもLinuxではプレビューであること、Linuxで利用できる応答アクションと利用できない応答機能が明記されたことです。(GitHub)
ネットワーク保護とWeb保護はLinuxではプレビュー扱い
Microsoft Defender for Endpoint on Linuxでは、ネットワーク保護とWeb保護により、悪意のあるサイトや望ましくないサイトへの接続制御を支援できます。ただし、公式情報ではLinuxにおけるネットワーク保護、Web保護、カスタムネットワークインジケーターはいずれもプレビューとして扱われています。(Microsoft Learn)
本番環境で使う場合は、「有効化できるか」だけでなく、次の観点で検証してください。
| 検証観点 | 確認内容 |
|---|---|
| 通信影響 | 業務システム、API通信、パッケージリポジトリへの接続が遮断されないか |
| ログ確認 | Defenderポータルや高度なハンティングで期待どおりイベントが見えるか |
| 除外設計 | 誤検知時にどの単位で例外化するか |
| ロールバック | 問題発生時にポリシーを戻す手順があるか |
| SOC運用 | アラートが増えた場合のトリアージ基準が決まっているか |
プレビュー機能は、すべての環境で安定運用できると決め打ちせず、まずは限定したサーバーグループで評価するのが安全です。
Linuxで使える応答アクションと使えない機能を分けて考える
Linux版で利用できる主な応答アクションには、ウイルス対策スキャンの実行、デバイス分離、調査パッケージの収集、詳細分析用ファイルの収集、Live Responseによるリモートシェル接続があります。一方で、自動調査と応答、EDR in block mode、ファイルやプロセスのブロック・停止・検疫はLinuxでは利用できません。(Microsoft Learn)
この違いは、インシデント対応手順に直結します。たとえばWindows端末向けのプレイブックに「プロセスを停止して隔離」と書かれていても、Linuxサーバーでは同じ自動対応を前提にできません。Linux向けには、次のような手順を別途用意しておくべきです。
| インシデント時の作業 | Linuxでの実務上の考え方 |
|---|---|
| 初動確認 | Defenderポータルでアラート、デバイスタイムライン、関連ファイルを確認する |
| 被害拡大防止 | デバイス分離が業務影響を与えないか判断し、必要に応じて実行する |
| 証跡取得 | 調査パッケージやLive Responseでログ、プロセス、ファイルを確認する |
| 復旧判断 | 検疫や停止が自動でできない前提で、OS側のプロセス停止やサービス停止手順を準備する |
| 再発防止 | IoC、除外、設定、脆弱性修復を見直す |
最新リリースで注目すべきLinuxエージェントの変更
リリースノートでは、Linuxビルド101.26032.0000、リリースバージョン30.126032.0000.0が2026年4月のリリースとして掲載されています。このリリースでは、Linuxカーネルモジュール（.ko）ファイルアクティビティの可視性拡張、オフラインセキュリティインテリジェンス更新の冗長ダウンロード削減、RHELベースの一部LinuxシステムにおけるSELinuxポリシークリーンアップ問題の修正が示されています。(Microsoft Learn)
| 変更点 | 影響を受けやすい環境 | 管理者の対応 |
|---|---|---|
.koファイル活動の可視性拡張 | カーネルモジュールを利用するサーバー、セキュリティ監視を強化したい環境 | カーネルモジュール作成・変更・削除イベントがSOC監視にどう出るか確認する |
| オフライン定義更新の挙動変更 | インターネット非公開環境、閉域網、ミラーサーバー利用環境 | 更新間隔、ミラーサーバー負荷、再起動時の更新挙動を確認する |
| SELinuxポリシークリーンアップ修正 | RHEL系Linux、SELinux有効環境 | アップグレード前に検証環境でSELinuxポリシーと業務アプリの動作を確認する |
特にRHEL系の本番サーバーでは、セキュリティ製品の更新がSELinuxポリシーに影響する場合があります。アップグレード直後に業務アプリのアクセス拒否が起きると原因特定が難しくなるため、ausearchやaudit.logの確認手順も含めて事前に検証しておくと安心です。
影響範囲：Linuxサーバー管理者だけの問題ではない
Microsoft Defender for Endpoint on Linuxの更新は、Linuxサーバー担当者だけで完結しません。SOC、ネットワーク、ID管理、DevOps、アプリケーション運用の担当者にも影響します。
| 関係者 | 影響範囲 | 確認すべきこと |
|---|---|---|
| Linux管理者 | インストール、更新、OS要件、エージェント正常性 | 対応ディストリビューション、カーネル、systemd、mdatp health |
| SOC担当者 | 検知、調査、応答、Live Response | Linuxで使える応答アクションと使えない機能 |
| ネットワーク担当者 | クラウド接続、プロキシ、SSLインスペクション | 静的または透過プロキシ、必要URL、SSL検査除外 |
| DevOps担当者 | CI/CD、ビルドサーバー、高I/O処理 | Jenkins、Jira、DBワークロードへの性能影響 |
| セキュリティ管理者 | ポリシー、除外、更新チャネル | Defenderポータル、Intune、JSON構成、除外スコープ |
| 監査・統制担当 | ライセンス、ログ、脆弱性管理 | サーバーライセンス、デバイス正常性、ソフトウェアインベントリ |
展開前に確認すべき前提条件
Microsoft Defender for Endpoint on Linuxを展開するには、サーバーライセンス、最小システム要件、対応ディストリビューション、ネットワーク接続、権限を確認する必要があります。公式情報では、CPUは最小1コア、ディスク容量は最小2GB、メモリは最小1GBとされていますが、高負荷ワークロードではより多くのリソースが必要になる可能性があります。(Microsoft Learn)
対応ディストリビューションを必ず公式一覧で確認する
対応ディストリビューションには、RHEL、CentOS、CentOS Stream、Ubuntu LTS、Ubuntu Pro、Debian、SUSE Linux Enterprise Server、Oracle Linux、Amazon Linux、Fedora、Rocky Linux、Alma Linux、Marinerなどが含まれます。ARM64でもUbuntu、RHEL、Debian、SUSE Linux、Amazon Linux、Oracle Linuxなどがサポート対象として整理されています。(Microsoft Learn)
ただし、カスタマイズOSや派生ディストリビューションでは、インストールや実行ができてもMicrosoftの検証済みサポートベースラインに含まれない場合があります。障害時に標準ディストリビューションで再現できないと、調査や修復が進まない可能性があるため、本番サーバーでは「動くか」ではなく「サポートされるか」を基準に判断してください。(Microsoft Learn)
プロキシとSSLインスペクションは失敗しやすい
Linuxエンドポイントは、Microsoft Defender for Endpointのクラウドサービスへ接続できる必要があります。公式情報では、PAC、WPAD、認証付きプロキシはサポートされず、静的プロキシまたは透過プロキシを使用すること、SSLインスペクションやインターセプトプロキシはセキュリティ上の理由でサポートされないことが示されています。(Microsoft Learn)
プロキシ環境では、次の失敗がよく起きます。
| 失敗例 | 原因 | 対応 |
|---|---|---|
| オンボード後にポータルへ表示されない | 必要URLへの通信が遮断されている | 接続テストを実施し、ファイアウォールとプロキシを確認する |
| 定義更新が遅れる | Microsoftクラウドまたはミラーサーバーに到達できない | 更新元URL、プロキシ、名前解決を確認する |
| テレメトリが欠落する | SSLインスペクションで通信が中断される | Defender関連通信をSSL検査の対象外にする |
| プロキシ認証で失敗する | 認証付きプロキシを前提にしている | 静的または透過プロキシ構成に見直す |
展開方法はDeployment Toolベースを優先する
公式情報では、Microsoft Defender for Endpoint on Linuxの展開方法としてDeployment Toolベースの展開が推奨されています。Deployment Toolは、新規インストール、アップグレード、アンインストールをサポートし、手動作業を減らせるため、大規模展開や移行時の設定差分を抑えやすくなります。(Microsoft Learn)
Deployment Toolを使う場合は、展開前に次の順序で確認すると失敗を減らせます。
| 手順 | 作業 | 確認ポイント |
|---|---|---|
| 事前棚卸し | 対象Linuxサーバーを一覧化する | OS、バージョン、CPU、メモリ、用途、ネットワーク制約 |
| 前提条件チェック | --pre-reqや接続テストを実行する | ディスク、メモリ、glibc、URL到達性 |
| パイロット展開 | 代表的なサーバーに限定して導入する | DB、CI/CD、アプリサーバーを含める |
| 本番展開 | Ansible、Puppet、Chef、SaltStackなどで展開する | チャネル、プロキシ、オンボードパッケージの管理 |
| 検証 | ポータル表示、RTP、EDRテストを確認する | デバイスインベントリ、アラート、mdatp health |
| 運用移行 | 更新、除外、ヘルス監視を定常化する | 期限切れ、定義更新、パフォーマンス劣化 |
Deployment Toolでは、接続テスト、カスタムパスへのインストール、プロキシ指定、特定バージョンへのアップグレード・ダウングレード、アンインストール、オンボードのみの実行などのシナリオが用意されています。展開ログは/tmp/defender_deployment_tool.logに記録されるため、失敗時は最初にこのログを確認してください。(Microsoft Learn)
mdatpユーザーのUID/GIDはインストール前に決める
Linuxでは、Microsoft Defender for Endpointがmdatpユーザーを作成します。公式情報では、UID/GIDはランダム値になるため、値を制御したい場合はインストール前に/usr/sbin/nologinシェルオプションを使ってmdatpユーザーを作成するよう案内されています。(Microsoft Learn)
これは地味ですが、企業環境では重要です。特に次のような環境では、UID/GIDの事前設計をおすすめします。
| 環境 | 理由 |
|---|---|
| NFSや共有ストレージを使うサーバー | UID/GIDの不一致が権限トラブルにつながる |
| 構成管理でユーザーIDを標準化している環境 | 監査やベースライン管理と整合しなくなる |
| コンテナホストやCI/CDサーバー | ファイル所有者の差分がビルドやデプロイに影響する |
| 厳格な監査環境 | ランダムなシステムユーザー作成が変更管理上の指摘対象になる |
更新管理：9か月期限切れを前提に運用する
Microsoft Defender for Endpoint on Linuxの各バージョンは、9か月後に自動的に期限切れになります。期限切れ後もセキュリティインテリジェンス更新は継続されますが、利用可能な修正や機能改善を受けるためには最新バージョンへの更新が推奨されています。(Microsoft Learn)
まず、現在の製品期限を確認します。
mdatp health --field product_expirationヘルス状態全体を確認する場合は、次を実行します。
mdatp health手動更新はディストリビューションごとに異なります。
| ディストリビューション | 更新コマンド |
|---|---|
| RHEL、CentOS、Oracle Linuxなど | sudo yum update mdatp |
| SLES系 | sudo zypper update mdatp |
| Ubuntu、Debian系 | sudo apt-get install --only-upgrade mdatp |
Defender for CloudがLinuxサーバーにMicrosoft Defender for Endpointエージェントをプロビジョニングしている場合、クライアントは自動的に更新されるとされています。ただし、自動更新任せにせず、デバイス正常性レポートやmdatp healthでバージョン、ライセンス状態、定義更新状態を定期確認する運用が必要です。(Microsoft Learn)
オフライン環境ではセキュリティインテリジェンス更新の設計が重要
インターネット接続が制限されたLinuxサーバーでは、オフラインセキュリティインテリジェンス更新を設計する必要があります。公式情報では、ローカルのミラーサーバーがMicrosoftクラウドからセキュリティインテリジェンス更新を取得し、Linuxエンドポイントが定義された間隔でミラーサーバーから更新を取得する方式が説明されています。(Microsoft Learn)
2026年5月の新機能情報では、DefenderポータルとIntuneポータルからLinuxのオフラインセキュリティインテリジェンス更新設定を構成できるようになったことがGAとして掲載されています。(Microsoft Learn)
| 設計項目 | 確認内容 |
|---|---|
| ミラーサーバー | HTTP/HTTPSサーバー、NFS、ネットワーク共有などを使うか |
| 更新頻度 | 既定の間隔でよいか、業務要件に合わせて短縮・延長するか |
| フォールバック | ミラー失敗時にMicrosoftクラウドへフォールバックするか |
| 検証端末 | 全台展開前に定義更新をテストするサーバーを用意するか |
| 障害対応 | ミラー停止時にどの手順で復旧・切り戻しするか |
設定確認には次のコマンドが使えます。
mdatp health --details definitions手動で定義更新を実行する場合は、次を実行します。
mdatp definitions update閉域網では「エージェントは入ったが定義が古い」という状態が起きやすくなります。オンボード完了だけで安心せず、definitions_status、definitions_updated、offline_definition_url_configuredを確認してください。
セキュリティ設定はポータル管理かJSON構成で標準化する
Microsoft Defender for Endpoint on Linuxの設定は、Defender for Endpoint Security Settings Managementを使ってMicrosoft Defenderポータルから管理する方法と、mdatp_managed.jsonを使う構成プロファイル方式があります。公式情報では、JSON構成ファイルは通常/etc/opt/microsoft/mdatp/managed/に配置され、エンタープライズ管理の設定はローカル設定より優先されます。(Microsoft Learn)
特に確認すべき設定は次のとおりです。
| 設定 | 推奨される確認内容 |
|---|---|
| リアルタイム保護 | 本番保護が必要なサーバーでreal_timeになっているか |
| パッシブモード | 他社製品併用や移行期間で意図的にpassiveにしているか |
| クラウド保護 | プロキシ経由でもクラウド保護が機能するか |
| 自動定義更新 | オンライン・オフライン環境のどちらでも更新できるか |
| PUAブロック | 望ましくない可能性のあるアプリをブロックするか |
| スキャンスケジュール | 業務ピーク時間を避けているか |
| eBPF | 既定有効のセンサーが業務アプリと競合しないか |
| ネットワーク保護 | プレビュー機能として限定展開しているか |
リアルタイム保護の状態は次で確認できます。
mdatp health --field real_time_protection_enabledLinux版のウイルス対策エンジン適用レベルには、real_time、on_demand、passiveがあります。passiveではリアルタイム保護や自動修復は無効になりますが、EDRは有効です。移行期間に便利な一方、保護レベルが下がるため、恒久運用にする場合はリスクを明確にしてください。(Microsoft Learn)
除外設定は「epp」と「global」を使い分ける
Linuxでパフォーマンス問題や誤検知が発生した場合、除外設定を検討できます。ただし、除外は保護を低下させるため、信頼できるファイル、フォルダー、プロセスだけに限定する必要があります。公式情報では、ウイルス対策除外のスコープeppと、ウイルス対策およびEDRの両方に影響するグローバル除外globalが説明されています。(Microsoft Learn)
| 除外スコープ | 影響範囲 | 使う場面 |
|---|---|---|
epp | オンデマンドスキャン、リアルタイム保護、動作監視 | 誤検知やスキャン負荷を抑えたいが、EDRの可視性は残したい場合 |
global | ウイルス対策とEDRの可視性を停止 | 重大な性能問題があり、リスク評価済みの信頼プロセスだけを除外する場合 |
失敗しやすいのは、性能問題を解消するために安易にglobal除外を広げることです。global除外はEDRアラートや検出の可視性も止めるため、SOCの監視範囲に穴が空きます。まずはepp除外で対応できるか検討し、どうしても必要な場合だけ完全パスを指定してglobal除外を使うべきです。
高I/Oワークロードではパフォーマンス検証を必ず行う
公式情報では、Jenkins、Jira、OracleDB、Postgresなど、高I/Oワークロードのアプリケーションで、Defender for Endpointのインストール後にパフォーマンス問題が発生する可能性があるとされています。(Microsoft Learn)
導入前後で次の指標を比較してください。
| 指標 | 具体例 |
|---|---|
| CPU使用率 | mdatp関連プロセス、ビルド時のCPUスパイク |
| ディスクI/O | DBのWAL、ログ出力、CI成果物生成時の遅延 |
| メモリ | Defender導入前後の常駐メモリ差分 |
| ビルド時間 | Jenkinsジョブの平均・最大実行時間 |
| DB性能 | クエリ遅延、チェックポイント、WAL書き込み |
| アラート数 | 除外前後で検知が減りすぎていないか |
パフォーマンス問題を切り分けるには、リアルタイム保護統計やホットイベントソースを使います。リアルタイム保護統計では、どのプロセスが多くのスキャンを引き起こしているか確認できます。(Microsoft Learn)
mdatp config real-time-protection-statistics --value enabled
mdatp diagnostic real-time-protection-statistics --sort --top 4ファイルや実行可能ファイル単位でリソース消費の多いイベントを確認する場合は、ホットイベントソースを使います。
sudo mdatp diagnostic hot-event-sources files検出結果を見ずに除外を追加するのは避けてください。たとえばPostgresで負荷が高い場合でも、データディレクトリ全体を広く除外するのではなく、実際にスキャン負荷を生んでいるパス、プロセス、ファイル種別を確認し、最小範囲で除外するのが安全です。
複数のセキュリティ製品を併用する場合の注意点
Linuxで他のFanotifyベースのセキュリティソリューションとMicrosoft Defender for Endpointを同時に実行することはサポートされず、システムハングなど予期しない動作につながる可能性があります。ブロッキングモードでFanotifyを使うアプリケーションは、mdatp healthのconflicting_applicationsに表示されます。(Microsoft Learn)
移行期間に他社製品と併用する場合は、次の順序で進めるとリスクを抑えられます。
| フェーズ | 対応 |
|---|---|
| 事前調査 | 既存セキュリティ製品のリアルタイム保護方式を確認する |
| パイロット | Defenderをpassiveで導入し、EDR可視性と性能影響を見る |
| 除外設計 | 相互除外を設定し、競合や二重スキャンを避ける |
| 切り替え | 既存製品のリアルタイム保護を停止し、Defenderをreal_timeへ移行する |
| 監視 | mdatp health、CPU、I/O、アラートを確認する |
RHELおよびFedoraのFAPolicyDについては、条件付きで例外が示されていますが、mdatp healthが正常であることなど前提があります。例外があるからといって、すべてのFanotify系ソリューションを併用できるわけではありません。
管理者が今日確認すべきチェックリスト
Microsoft Defender for Endpoint on Linuxを導入済み、またはこれから展開する場合は、まず次の項目を確認してください。
| 優先度 | チェック項目 | 確認方法 |
|---|---|---|
| 高 | エージェントが期限切れではないか | mdatp health --field product_expiration |
| 高 | デバイスが正常状態か | mdatp health |
| 高 | リアルタイム保護が意図どおりか | mdatp health --field real_time_protection_enabled |
| 高 | 対応ディストリビューションか | 公式の前提条件ページとOS棚卸しを照合 |
| 高 | プロキシやSSL検査で通信が妨げられていないか | 接続テスト、プロキシ設定、ファイアウォール設定 |
| 中 | Deployment Toolで標準展開できるか | --pre-req、--connectivity-test |
| 中 | 高I/Oサーバーで性能劣化がないか | ビルド時間、DB I/O、RTP統計 |
| 中 | 除外が広すぎないか | eppとglobalの範囲を確認 |
| 中 | オフライン定義更新が機能しているか | mdatp health --details definitions |
| 中 | SOC手順がLinuxの機能制限に合っているか | 応答アクション、Live Response、デバイス分離手順 |
よくある疑問
Microsoft Defender for Endpoint on LinuxはWindows版と同じように使える？
同じMicrosoft Defender for Endpointの一部として管理できますが、機能は完全に同じではありません。Linuxでは、デバイス分離、ウイルス対策スキャン、調査パッケージ収集、Live Responseなどを利用できます。一方で、自動調査と応答、EDR in block mode、ファイルやプロセスのブロック・停止・検疫は利用できません。(Microsoft Learn)
Linuxサーバーにはどのライセンスが必要？
サーバーをDefender for Endpointにオンボードするには、Microsoft Defender for Servers Plan 1またはPlan 2、Microsoft Defender for Endpoint for servers、または中小企業向けのMicrosoft Defender for Business serversなどのサーバーライセンスが必要です。ライセンス条件は契約や提供形態で変わるため、最終確認は製品条項やアカウントチームで行うべきです。(Microsoft Learn)
更新は自動で任せてよい？
Defender for Cloudでプロビジョニングされている場合、Linuxサーバーのクライアント更新は自動的に維持されるとされています。ただし、各バージョンは9か月で期限切れになるため、mdatp healthやデバイス正常性レポートで期限切れや異常を監視する運用は必要です。(Microsoft Learn)
パフォーマンスが悪化したら、まず除外すればよい？
いきなり除外するのは危険です。除外は保護を低下させ、特にglobal除外はEDRの可視性も止めます。まずリアルタイム保護統計やホットイベントソースで負荷の原因を特定し、必要最小限のepp除外から検討してください。(Microsoft Learn)
まとめ：Linux版Microsoft Defenderは「導入後の標準運用」が重要
Microsoft Defender for Endpoint on Linuxは、LinuxサーバーをMicrosoft Defenderの統合管理に組み込み、脆弱性管理、ウイルス対策、EDR、調査、応答を強化できる有力な選択肢です。ただし、Windows版と同じ機能を前提にした運用、プロキシやSSLインスペクションの見落とし、期限切れエージェントの放置、広すぎる除外設定、高I/Oワークロードの未検証は、導入後のトラブルにつながります。
管理者が次に取るべき行動は明確です。まずmdatp healthで現在の状態を確認し、対応ディストリビューション、エージェント期限、定義更新、プロキシ接続、除外設定を棚卸ししてください。そのうえで、Deployment Toolを使った標準展開、限定サーバーでのパイロット、SOC手順のLinux向け見直し、高I/Oサーバーの性能検証を進めることで、Microsoft Defender for Endpoint on Linuxを安定して運用できます。
コメント