2026年4月30日の公式更新「Microsoft Defender documentation update: Update mde-linux-prerequisites.md」でまず押さえるべき結論は、新機能追加というより、Linux版Microsoft Defender for Endpointの前提条件まわりを再確認すべき更新だという点です。
GitHub上の差分では、対象は defender-endpoint/mde-linux-prerequisites.md の1ファイルで、変更量は6追加・6削除です。内容としては表記修正が中心ですが、触れられている箇所は、カスタムLinux環境のサポート境界、Fanotifyベースのセキュリティ製品との競合、対応ファイルシステム、mdatp ユーザーのUID/GID管理など、企業運用では見落とすと障害や監査指摘につながりやすい領域です。(GitHub)
Microsoft Defenderの公式ドキュメント更新「Update mde-linux-prerequisites.md」で何が変わったか
今回の更新は、Microsoft Defender for Endpoint on Linuxの前提条件ページに対するドキュメント更新です。Microsoft Learn側の該当ページも「Last updated on 2026-04-30」と表示されており、LinuxサーバーにDefender for Endpointを展開・オンボードするためのライセンス、システム要件、ソフトウェア要件、ネットワーク要件、サポート対象ディストリビューションなどを整理するページです。(Microsoft Learn)
差分だけを見ると、文法や表記の調整が多く、大きな仕様変更には見えません。しかし、更新対象になった本文の意味は運用上かなり重要です。特に以下の4点は、security admins、compliance teams、enterprise IT readersが確認すべきポイントです。
| 確認項目 | 更新で触れられた内容 | 実務上の確認ポイント |
|---|---|---|
| カスタムOS環境 | サポート対象ディストリビューション由来のカスタムOSではインストール・動作する可能性があるが、Microsoftの検証済みサポートベースには含まれない | 「導入できる」ことと「標準サポートされる」ことを分けて判断する |
| Fanotify競合 | Fanotifyベースの他のセキュリティ製品との併用はサポートされず、システムハングを含む予測不能な動作につながる可能性がある | 既存EDR、アンチウイルス、ファイル監視製品との二重監視を事前に洗い出す |
| ファイルシステム | リアルタイム保護、Quick/Full scan、Custom scanでサポート対象が異なる | NFS、FUSE、クラウドストレージ系マウントなどを一律に扱わない |
mdatp ユーザー | LinuxではDefender for Endpointが mdatp ユーザーを作成し、UID/GIDがランダムになる。制御したい場合はインストール前に作成する | ゴールデンイメージ、UID/GID管理、監査要件がある環境では事前設計が必要 |
これは「Linux版Microsoft Defender for Endpoint」の前提条件更新として読む
今回の更新対象は、Windowsクライアント向けのMicrosoft Defenderではなく、Microsoft Defender for Endpoint on Linuxの前提条件です。対象はLinuxサーバー運用、EDR導入、クラウド・オンプレ混在環境、SAPなどの重要ワークロードを含む企業サーバー保護の文脈で読む必要があります。
公式ドキュメントでは、LinuxサーバーにDefender for Endpointを展開する前提として、CPU、ディスク、メモリ、systemd、ネットワーク接続、対応ディストリビューション、対応ファイルシステムなどが整理されています。たとえば、サポート対象ディストリビューションの一覧にはRed Hat Enterprise Linux、Ubuntu LTS、Debian、SUSE Linux Enterprise Server、Oracle Linux、Amazon Linux、Fedora、Rocky Linux、Alma Linuxなどが含まれていますが、明示されていないディストリビューションやバージョンはサポート対象外とされています。(Microsoft Learn)
ここで重要なのは、「Linuxなら何でも同じように保護できる」と考えないことです。サーバーOSの種類、カーネル、マウント構成、既存セキュリティ製品、プロキシ構成が違えば、Defender for Endpointの導入リスクも変わります。
カスタムLinux環境は「動く」と「サポートされる」を分けて判断する
今回の更新で最も重要なのは、カスタマイズされたLinux環境に関する説明です。
公式ドキュメントでは、最小カーネル要件を満たし、Microsoftがサポートする標準的なベンダー提供Linuxディストリビューションに由来するカスタムOSであれば、Defender for Endpoint on Linuxをインストールでき、動作する可能性があると説明されています。一方で、そのようなカスタム環境はMicrosoftの検証済みまたは保守済みのサポートベースには含まれず、サポート上はカスタムOS構成として扱われます。(Microsoft Learn)
つまり、実務では次のように判断する必要があります。
| 環境 | 判断の目安 | 推奨対応 |
|---|---|---|
| 公式サポート対象の標準ディストリビューション | 通常の導入候補 | 前提条件、ネットワーク、権限を確認して展開 |
| 標準ディストリビューションにCIS Hardeningや社内設定を加えた環境 | カスタム環境として検証が必要 | ステージングで mdatp health、スキャン、再起動、負荷を確認 |
| カスタムカーネル、独自アプライアンス、派生OS | サポート境界が曖昧になりやすい | Microsoftサポートへ問い合わせる前提で、標準OS上での再現環境を準備 |
| コンテナホストや特殊なファイルシステムを多用する環境 | ファイル監視・スキャン範囲に注意 | マウント構成、除外設定、パフォーマンスを個別に評価 |
特に注意したいのは、障害発生時です。公式ドキュメントでは、カスタム環境で問題が起きた場合、サポート対象の標準Linuxディストリビューションで問題を再現することが期待され、標準環境で再現できない場合は、Microsoftが追加調査や修復を進められない可能性があると説明されています。(Microsoft Learn)
そのため、移行計画では「本番環境に入れて動いた」で終わらせず、以下を記録しておくと実務で役立ちます。
/etc/os-releaseの内容uname -rで確認したカーネルバージョンmdatp healthの出力- 使用しているファイルシステムとマウントポイント
- 既存セキュリティ製品との併用状況
- 標準ディストリビューション上での再現可否
Fanotifyベースの製品競合は、導入前に必ず確認する
LinuxサーバーでMicrosoft Defenderを運用する場合、Fanotifyの競合は非常に重要です。
公式ドキュメントでは、Defender for Endpoint on Linuxを他のFanotifyベースのセキュリティソリューションと並行して実行することはサポートされず、システムハングを含む予測不能な動作につながる可能性があるとされています。また、Fanotifyをブロッキングモードで使うアプリケーションは、mdatp health コマンド出力の conflicting_applications フィールドに表示されると説明されています。(Microsoft Learn)
ここで失敗しやすいのは、「既存のアンチウイルスも残し、Defenderもリアルタイム保護で有効化する」という設計です。多層防御のつもりでも、同じファイルアクセス監視領域を複数製品が取り合うと、安定性やパフォーマンスを損なうことがあります。
導入前には、以下のように整理してください。
| 確認対象 | 見るべきポイント |
|---|---|
| 既存アンチウイルス | リアルタイムスキャンがFanotifyを使っていないか |
| EDR・ファイル監視製品 | ブロッキングモードでファイルアクセスを監視していないか |
| FIM製品 | ファイル変更監視がDefenderと競合しないか |
mdatp health | conflicting_applications に該当プロセスが出ていないか |
| 運用方針 | Defenderをactiveにするのか、passiveにするのか |
併用が必要な場合、公式ドキュメントではDefender for Endpoint on Linuxのアンチウイルス適用レベルをpassiveに設定する選択肢にも触れています。passiveではリアルタイム保護や自動修復は行われませんが、オンデマンドスキャン、セキュリティインテリジェンス更新、アラート、EDR機能は利用できます。(Microsoft Learn)
なお、FAPolicyDについては例外があります。公式ドキュメントでは、FAPolicyDもFanotifyをブロッキングモードで使用しますが、RHELおよびFedoraプラットフォームでは、mdatp health が正常状態を報告していることを条件に、Defender for Endpointのactive modeとの併用がサポートされると説明されています。(Microsoft Learn)
ただし、この例外を他のディストリビューションや他のセキュリティ製品に広げて解釈しないでください。監査や障害対応の観点では、「なぜactiveで併用してよいと判断したのか」を文書化しておくことが重要です。
ファイルシステムの違いはスキャン設計に直結する
今回の差分には、ファイルシステム一覧の説明文にあるタイポ修正も含まれています。一見小さな修正ですが、該当セクションは実務上かなり重要です。
公式ドキュメントでは、リアルタイム保護およびQuick/Full scanでサポートされるファイルシステムと、Custom scanで追加的にサポートされるファイルシステムが分けて整理されています。たとえば、ext4、xfs、btrfs などの一般的なLinuxファイルシステムに加え、Custom scan側では S3fs、Blobfuse、sshfs、cifs、smb、gcsfuse なども一覧に含まれています。(Microsoft Learn)
企業環境では、次のようなケースで判断を誤りやすくなります。
| よくある構成 | 注意点 |
|---|---|
| NFSマウント | NFS v3では no_root_squash export optionが必要。ない場合、権限不足でスキャンに失敗する可能性がある |
| S3fsやBlobfuse | Custom scanの対象になっても、ローカルディスクと同じ挙動とは限らない |
| コンテナホストのoverlay | コンテナ実行基盤のI/O負荷や除外設定を含めて検証する |
| SMB/CIFSマウント | スキャン対象、ネットワーク遅延、権限の影響を確認する |
| 一時領域やバックアップ領域 | スキャンで業務処理が遅延しないように時間帯や除外を設計する |
特に、クラウドストレージ連携やネットワークファイルシステムを使っている場合は、「マウントされているから保護される」と単純に判断しないことが大切です。どのスキャン方式で対象になるのか、リアルタイム保護の対象なのか、Custom scanでのみ確認すべきなのかを整理しましょう。
mdatp ユーザーのUID/GID管理はインストール前に決める
Linux版Defender for Endpointでは、インストール時に mdatp ユーザーが作成されます。公式ドキュメントでは、このユーザーのUIDとGIDはランダムに作成されるため、値を制御したい場合は、インストール前に /usr/sbin/nologin シェルオプションを使って mdatp ユーザーを作成するよう説明されています。(Microsoft Learn)
これは、セキュリティ管理者だけでなく、compliance teamsにも関係します。たとえば、次のような環境ではUID/GIDの事前設計が必要です。
- UID/GIDの範囲を全社標準で管理している
- ゴールデンイメージを複数クラウドや複数リージョンで使い回す
- 監査ログ上のユーザーIDを統一したい
- NFSなどでUID/GIDの整合性が業務に影響する
- 構成管理ツールでOSユーザーを厳格に管理している
実務では、Defender導入手順に以下を追加しておくと安全です。
sudo groupadd -g <GID> mdatp
sudo useradd -u <UID> -g <GID> -d /home/mdatp -s /usr/sbin/nologin mdatp<UID> と <GID> は、社内のID管理ルールに従って決めてください。すでにDefenderを導入済みのサーバーで後からUID/GIDを変更すると、ファイル所有者やサービス起動に影響する可能性があります。新規展開、移行、ゴールデンイメージ更新のタイミングで決めておくのが現実的です。
ネットワーク要件もあわせて見直す
今回の差分そのものはネットワーク要件を大きく変えるものではありませんが、Linux版Defender for Endpointの前提条件確認ではネットワーク設定も外せません。
公式ドキュメントでは、LinuxサーバーがDefender for Endpointのクラウドサービスへ接続できる必要があり、必要に応じて静的プロキシを構成することが案内されています。一方で、PAC、WPAD、認証付きプロキシはサポートされず、SSL inspectionやintercepting proxyもセキュリティ上の理由でサポートされないと説明されています。(Microsoft Learn)
企業ネットワークでは、ここが導入トラブルの原因になりがちです。特に以下の環境は事前確認が必要です。
| 環境 | 確認ポイント |
|---|---|
| プロキシ必須のデータセンター | 静的プロキシまたは透過プロキシで通信できるか |
| SSL復号を行う境界プロキシ | Defender関連通信をインターセプト対象から除外できるか |
| 閉域・制限付きネットワーク | 必要URLへの匿名通信を許可できるか |
| 多拠点・多クラウド | 拠点ごとのプロキシ差異でオンボード失敗が起きないか |
| 本番移行直前の導入 | mdatp health とクラウド接続確認を移行判定に含める |
セキュリティ製品の導入では、OS要件だけを満たしていても通信要件で失敗することがあります。特にグローバル企業では、国・リージョン・クラウド環境ごとにプロキシやSSL inspectionの設計が異なるため、標準手順書に「通信確認」を明記しておくべきです。
security admins向けの確認チェックリスト
今回のMicrosoft Defender公式ドキュメント更新を受けて、security adminsは次の順番で確認すると効率的です。
| 優先度 | 確認内容 | 具体的な作業 |
|---|---|---|
| 高 | サポート対象OSか | ディストリビューション名、バージョン、カーネルを棚卸しする |
| 高 | カスタムOSか | 標準ディストリビューションとの差分、カスタムカーネル、ハードニング内容を記録する |
| 高 | Fanotify競合がないか | mdatp health の conflicting_applications を確認する |
| 高 | 既存セキュリティ製品との役割分担 | Defenderをactiveにするかpassiveにするか決める |
| 中 | ファイルシステム | NFS、FUSE、SMB、クラウドストレージ系マウントを洗い出す |
| 中 | mdatp ユーザー | UID/GIDをランダム作成でよいか、事前作成が必要か判断する |
| 中 | ネットワーク | プロキシ、SSL inspection、許可URLを確認する |
| 中 | 展開方式 | Defender deployment tool、Ansible、Puppet、Chef、手動展開などを選ぶ |
| 低 | 文書化 | 例外、検証結果、ロールバック方針を変更管理に残す |
重要なのは、ドキュメント更新を「読んだ」で終わらせないことです。影響を受けるサーバー群を特定し、既存の標準導入手順、構成管理テンプレート、監査証跡に反映するところまで行う必要があります。
compliance teamsが確認すべき監査・証跡ポイント
compliance teamsにとって、今回の更新で注目すべき点は「Microsoft Defenderが導入されているか」だけではありません。サポートされる構成で導入されているか、例外が管理されているか、サポート境界を理解しているかが重要です。
監査観点では、次の証跡を残しておくと説明しやすくなります。
- サポート対象ディストリビューションとバージョンの一覧
- カスタムOSまたは派生OSを使っているサーバーの一覧
- 標準OSでの再現検証方針
- Fanotify競合の確認結果
- Defenderをpassiveにした理由と対象サーバー
- FAPolicyD併用の判断根拠
mdatpユーザーのUID/GID管理方針- ネットワーク要件の確認結果
- 例外設定や除外設定の承認履歴
特にカスタムLinux環境では、サポートインシデントが起きたときに「この構成は標準サポート対象なのか」「問題を標準ディストリビューションで再現できるのか」が問われます。導入後に慌てて調べるのではなく、移行前に証跡化しておきましょう。
よくある誤解と失敗しやすいポイント
「更新されたので新しいLinuxがサポートされた」とは限らない
今回のGitHub差分は、対応ディストリビューション一覧を大きく追加する内容ではありません。サポート対象OSを判断する場合は、必ず最新の公式ページでディストリビューション名、バージョン、アーキテクチャを確認してください。差分タイトルだけで「新しいOS対応が追加された」と判断するのは危険です。
「インストールできるならサポート対象」と考えない
カスタムOSでは、Defender for Endpointをインストールでき、動作する可能性があります。しかし、それはMicrosoftの検証済みサポートベースに含まれることを意味しません。公式ドキュメントでも、カスタム環境はサポート上カスタムOS構成として扱われると説明されています。(Microsoft Learn)
「複数のセキュリティ製品をactiveにすれば安全」とは限らない
ファイルアクセス監視を複数製品が同時に行うと、検知力が上がるどころか、I/O遅延、スキャン競合、システムハングにつながる可能性があります。Fanotifyベースの製品がある場合は、Defender側をpassiveにする、既存製品を外す、対象サーバーを分けるなど、役割分担を明確にしてください。
「passiveは無意味」と考えない
passiveではリアルタイム保護や自動修復は無効になりますが、オンデマンドスキャンやEDRなどは引き続き利用できます。既存セキュリティ製品をすぐに置き換えられない移行期間では、passiveを使って段階的にDefender for Endpointへ移行する設計が現実的です。(Microsoft Learn)
「UID/GIDは後から直せばよい」と考えない
mdatp ユーザーのUID/GIDを監査やNFS運用に合わせる必要がある場合、インストール前に決めるべきです。後から変更すると、サービス、ファイル所有権、構成管理ツールとの整合性に影響する可能性があります。
移行準備でやるべき次のアクション
今回のMicrosoft Defender公式ドキュメント更新を受けて、企業IT部門が次に取るべき行動は明確です。
まず、Linuxサーバーの棚卸しを行い、OS、カーネル、ファイルシステム、既存セキュリティ製品、プロキシ構成を確認します。次に、カスタムOSや派生ディストリビューションを使っているサーバーを分け、標準サポート対象として扱える環境と、個別検証が必要な環境を切り分けます。
そのうえで、Fanotify競合、mdatp ユーザーのUID/GID、ファイルシステムごとのスキャン範囲、ネットワーク要件を確認し、ステージング環境で mdatp health、オンボード、スキャン、負荷、再起動後の状態を検証してください。
今回の更新は、差分量だけを見ると小さな表記修正に見えます。しかし、更新箇所はLinux版Microsoft Defender for Endpointを安定運用するうえで重要な前提条件です。特にグローバル環境や大規模サーバー群では、公式ドキュメント更新をきっかけに、サポート境界、競合リスク、監査証跡、移行手順を見直す価値があります。
コメント