Microsoft Defenderの公式ドキュメント更新「Learn Editor: Update mde-linux-prerequisites.md」は、Linux向けMicrosoft Defender for Endpointの導入・運用条件を見直すきっかけになる更新です。結論から言うと、派手な新機能追加として読むよりも、Linuxサーバーが現在の前提条件を満たしているか、サポート対象・ネットワーク・競合製品・ファイルシステム・更新運用を再点検する更新として扱うべきです。
特に、security admins、compliance teams、enterprise IT担当者は、オンボーディング済みのLinuxサーバーだけでなく、今後展開予定のゴールデンイメージ、SAP用途のLinux、カスタムOS、プロキシ配下の閉域寄り環境まで確認しておく必要があります。
今回のMicrosoft Defender公式ドキュメント更新でまず押さえるべきこと
今回確認対象となるのは、MicrosoftDocsのdefender-docsリポジトリにあるmde-linux-prerequisites.md、つまり「Microsoft Defender for Endpoint on Linuxの前提条件」に関するドキュメントです。GitHub上の該当コミットは、2026年4月30日に「Learn Editor: Update mde-linux-prerequisites.md」として記録されています。コミット画面では「0 file changed」と表示されているため、大きな差分が公開コミット上で明確に示されている更新というより、Microsoft Learn上の現行前提条件を再確認するための更新として扱うのが安全です。(GitHub)
Microsoft Learnの英語版ページは「Last updated on 2026-04-30」と表示されており、日本語版ページは「Last updated on 2026-05-01」と表示されています。日本語環境の管理者も、日本語ページだけでなく英語版の原文を併せて確認すると、翻訳表現による誤読を避けやすくなります。(Microsoft Learn)
今回の更新を受けて、最初に見るべきポイントは次の5つです。
| 確認項目 | 見るべき内容 | 運用上の影響 |
|---|---|---|
| サポート対象Linux | RHEL、Ubuntu、Debian、SLES、Oracle Linux、Amazon Linux、Fedora、Rocky Linux、Alma Linux、Marinerなどの対象バージョン | サポート外OSでは障害調査や移行計画に影響する |
| ネットワーク要件 | 合理化された接続URL、プロキシ、SSL検査、認証プロキシの扱い | 通信不可、センサー不正常、オンボーディング失敗につながる |
| Fanotify競合 | 他のセキュリティ製品との並行稼働 | パフォーマンス低下やシステムハングのリスクがある |
| ファイルシステム | リアルタイム保護、スキャン対象、NFS v3の条件 | ファイルサーバー、コンテナ基盤、特殊マウントで影響が出やすい |
| 更新運用 | Linuxエージェントの更新、期限切れ、チャネル管理 | 古いクライアントのまま運用すると修正や機能改善を取り逃がす |
Linux向けMicrosoft Defender for Endpointの前提条件で確認すべき範囲
Microsoft Defender for Endpoint on Linuxの前提条件は、単に「インストールできるか」だけを見るものではありません。実務では、ライセンス、OS、CPU・メモリ・ディスク、ネットワーク、プロキシ、ファイルシステム、権限、更新方式まで含めて確認する必要があります。
公式ドキュメントでは、サーバーのオンボーディングにはサーバー向けライセンスが必要とされ、システム要件として最小1 CPUコア、2GB以上のディスク領域、1GB以上のRAMが示されています。ただし、高負荷ワークロードでは追加リソースやパフォーマンスチューニングが必要になる場合があります。(Microsoft Learn)
ここで重要なのは、最小要件を満たしていることと、実運用で安定することは同じではないという点です。たとえば、CI/CDサーバー、SAP関連サーバー、コンテナホスト、大量ログを扱うファイルサーバーでは、ファイルアクセスやプロセス生成が多く、Defenderのリアルタイム保護が性能面に影響する可能性があります。導入前後でCPU、I/O、メモリ、スキャン頻度を比較できるようにしておくと、トラブル時の切り分けが速くなります。
サポート対象Linuxディストリビューションを棚卸しする
公式ページでは、サポートされるLinuxサーバーディストリビューションとして、Red Hat Enterprise Linux、CentOS、CentOS Stream、Ubuntu LTS、Ubuntu Pro、Debian、SUSE Linux Enterprise Server、Oracle Linux、Amazon Linux、Fedora、Rocky Linux、Alma Linux、Marinerなどが掲載されています。ARM64対応の有無もディストリビューションごとに異なります。(Microsoft Learn)
運用担当者は、まずサーバー台帳と実機情報を突き合わせます。特に注意したいのは、クラウドイメージ、コンテナホスト、古いCentOS、独自カーネルを使うアプライアンス系Linuxです。
確認コマンドの例は次のとおりです。
cat /etc/os-release
uname -r
hostnamectl
systemctl --version棚卸しでは、単に「Ubuntu」や「RHEL」と書くのではなく、次の粒度で記録します。
| 記録項目 | 例 | 理由 |
|---|---|---|
| ディストリビューション名 | Ubuntu LTS、RHEL、Debian | サポート対象判定の基本になる |
| メジャー・マイナーバージョン | Ubuntu 22.04、RHEL 9.x | 対象範囲外の古い環境を見つけるため |
| アーキテクチャ | x64、ARM64 | ARM64対応はOSごとに差がある |
| カーネルバージョン | uname -rの結果 | カスタムカーネルや古いカーネルを識別するため |
| 用途 | DB、SAP、CI/CD、ファイルサーバー | パフォーマンス影響を判断するため |
| 展開方式 | 手動、Ansible、Defender for Cloud、ゴールデンイメージ | 修正や再展開の手順が変わるため |
カスタムOSやベンダー提供イメージを改変した環境では、さらに慎重な確認が必要です。公式ドキュメントでは、最小カーネル要件を満たし、Microsoftがサポートする標準的なLinuxディストリビューションに由来するカスタムOSでは、Defender for Endpointをインストールして動作する可能性はあるものの、Microsoftの検証済み・保守済みサポートベースラインには含まれないと説明されています。問題が発生した場合、標準の未改変ディストリビューションで再現確認を求められる可能性があります。(Microsoft Learn)
ネットワークとプロキシ要件は最優先で確認する
Microsoft Defenderはクラウド連携を前提とするため、LinuxサーバーがDefender for Endpointのクラウドサービスに到達できることが重要です。公式ドキュメントでは、商用環境向けと米国政府機関環境向けの合理化された接続URLを参照するよう案内されています。また、必要に応じて静的プロキシを構成することも示されています。(Microsoft Learn)
特に見落としやすいのは、プロキシの種類です。公式ドキュメントでは、PAC、WPAD、認証済みプロキシはサポートされず、静的または透過的なプロキシを使用すること、SSL検査やインターセプトプロキシはサポートされないことが明記されています。(Microsoft Learn)
企業ネットワークでは、セキュリティ強化のためにHTTPS通信を検査していることがあります。しかし、Defender for Endpointの通信に対してSSL検査をかけると、エージェントが正しくクラウドへ通信できない原因になります。証明書をOSの信頼ストアに追加すれば解決する、という理解も危険です。公式ドキュメントでは、関連URLに対してインターセプトなしの直接データパススルーを許可するよう求めています。(Microsoft Learn)
ネットワーク担当と確認する項目は、次のように整理できます。
| 確認項目 | OKの目安 | NGになりやすい例 |
|---|---|---|
| 接続先URL | 公式URLリストに基づき許可されている | 古いStandard URLだけを許可している |
| プロキシ方式 | 静的プロキシまたは透過プロキシ | PAC、WPAD、認証必須プロキシ |
| SSL検査 | Defender通信は検査対象外 | 全HTTPS通信を一律で復号検査 |
| 匿名通信 | 必要な宛先に対して許可 | プロキシ認証が必須 |
| 変更管理 | FW・プロキシ例外のチケットが残っている | 属人的な設定で証跡がない |
コンプライアンスチームは、許可したURLや例外設定を「例外的な緩和」ではなく、「Microsoft Defenderの公式要件に基づく通信要件」として記録すると、監査時の説明がしやすくなります。
Fanotifyベースのセキュリティ製品との競合を確認する
Linuxサーバーでは、Defender for Endpoint以外のEDR、アンチウイルス、ファイル監視製品が同時に動いていることがあります。ここで重要なのがFanotifyです。
公式ドキュメントでは、Defender for Endpoint on Linuxを他のFanotifyベースのセキュリティソリューションと並行して実行することはサポートされず、システムハングを含む予期しない動作につながる可能性があると警告しています。ブロッキングモードでFanotifyを使用するアプリケーションは、mdatp healthコマンド出力のconflicting_applicationsフィールドに表示されると説明されています。(Microsoft Learn)
確認時は、次のように進めると実務的です。
mdatp health出力の中で、次の観点を確認します。
| 見る項目 | 判断のポイント |
|---|---|
healthy | Defenderエージェントが正常状態か |
health_issues | ライセンス、接続、構成などの問題がないか |
conflicting_applications | Fanotify競合の可能性がある製品が表示されていないか |
| リアルタイム保護の状態 | 意図した保護レベルになっているか |
| クラウド接続 | オンボーディング後に通信できているか |
なお、公式ドキュメントでは例外として、LinuxのFAPolicyD機能は、RHELおよびFedora環境でmdatp healthが正常状態を報告している場合、アクティブモードのDefender for Endpointと併用できるとされています。(Microsoft Learn)
この例外を誤解して、「Fanotifyを使う製品ならすべて併用できる」と判断してはいけません。FAPolicyDの例外は、対象プラットフォームと正常性条件が明示された限定的な扱いです。
ファイルシステムとNFS v3の条件を見落とさない
Linuxサーバーでは、標準的なext4やxfsだけでなく、NFS、overlay、fuse、tmpfs、cifs、smb、Blobfuse、gcsfuseなど、用途に応じてさまざまなファイルシステムが使われます。公式ドキュメントでは、リアルタイム保護およびクイック/フルスキャンでサポートされるファイルシステムと、カスタムスキャンで追加サポートされるファイルシステムが整理されています。(Microsoft Learn)
特に注意したいのがNFS v3です。公式ドキュメントでは、NFS v3マウントポイントをスキャンするにはno_root_squashエクスポートオプションを設定する必要があり、このオプションがないと権限不足によりスキャンが失敗する可能性があるとされています。(Microsoft Learn)
ファイルサーバーや業務アプリケーション基盤では、次の確認を行います。
findmnt
cat /proc/filesystems
mount | grep nfs確認対象は、サーバー全体ではなく、実際に保護・スキャンしたいパス単位で見ることが大切です。たとえば、OS領域はxfsでも、業務データはNFSマウント、コンテナ領域はoverlayという構成は珍しくありません。
| 利用シーン | 確認すべき点 |
|---|---|
| ファイルサーバー | NFS、SMB、CIFSの扱いとスキャン範囲 |
| コンテナホスト | overlayや一時領域の監視負荷 |
| SAP・DBサーバー | 大量I/Oと除外設定の妥当性 |
| クラウドストレージ連携 | Blobfuse、gcsfuseなどのマウント方式 |
| 開発・CI環境 | ビルド成果物や依存パッケージの大量生成 |
スキャン対象を広げすぎると性能問題が起きやすく、狭めすぎると検知漏れのリスクが高まります。業務影響とリスクの両方を見て、除外設定やスキャン方針を決める必要があります。
mdatpユーザーのUID・GID管理を事前に決める
Linux向けMicrosoft Defender for Endpointでは、インストール時にmdatpユーザーが作成されます。公式ドキュメントでは、Linux上でDefender for EndpointがランダムなUIDとGIDを持つmdatpユーザーを作成し、これらを制御したい場合はインストール前に/usr/sbin/nologinシェルオプションを使ってmdatpユーザーを作成するよう案内しています。(Microsoft Learn)
これは大規模運用では見逃せないポイントです。UID/GIDが環境ごとにランダムになると、次のような問題が起きることがあります。
| 問題になりやすい場面 | 影響 |
|---|---|
| ゴールデンイメージ展開 | サーバーごとにUID/GID管理がばらつく |
| ID管理ルールが厳格な環境 | 予約済みUID/GIDと衝突する可能性がある |
| ファイル権限監査 | 所有者の解釈が環境ごとに変わる |
| 構成管理ツール | AnsibleやChefの期待値と実機がずれる |
大規模展開では、インストール前の標準手順にmdatpユーザー作成を含めるか、ランダムUID/GIDを許容するかを事前に決めておきます。どちらが正しいというより、監査・運用・構成管理の方針と一致していることが重要です。
更新プログラムとクライアント期限切れを確認する
今回のmde-linux-prerequisites.md更新は前提条件の確認が中心ですが、運用担当者はLinuxエージェントの更新状態も同時に見るべきです。
Microsoftの更新ドキュメントでは、Defender for Endpoint on Linuxの各バージョンは9か月後に自動的に期限切れとなり、期限切れ後もセキュリティインテリジェンス更新は受け取るものの、利用可能な修正や機能強化を得るには最新バージョンをインストールするよう説明されています。期限確認にはmdatp health --field product_expirationを使います。(Microsoft Learn)
mdatp health --field product_expiration
mdatp health手動更新コマンドはディストリビューションによって異なります。公式ドキュメントでは、RHEL系ではsudo yum update mdatp、SLES系ではsudo zypper update mdatp、UbuntuおよびDebianではsudo apt-get install --only-upgrade mdatpが示されています。Defender for CloudがLinuxサーバーにエージェントをプロビジョニングしている場合は、クライアントが自動的に更新されると説明されています。(Microsoft Learn)
| 環境 | 確認ポイント |
|---|---|
| 手動インストール | 更新手順が運用手順書にあるか |
| Ansible・Chef・Puppet等 | 更新タスクが自動化されているか |
| Defender for Cloud連携 | 自動更新の前提と例外を理解しているか |
| 検証環境 | 本番前に更新後の性能・検知・通信を確認できるか |
| 長期停止サーバー | 起動後に期限切れや通信失敗が起きないか |
古いクライアントを放置すると、見かけ上はエージェントが動いていても、最新の修正や改善を取り込めていない状態になります。月次のサーバーパッチ運用にmdatp healthと期限確認を組み込むと、後追い対応を減らせます。
デプロイ方式は「今後の運用」から選ぶ
公式ドキュメントでは、Microsoft Defender for Endpoint on Linuxの導入方法として、Deployment Tool based deployment、Installer script、Ansible、Chef、Puppet、SaltStack、ゴールデンイメージ、カスタムロケーション、手動展開、Defender for Cloudによる直接オンボードなどが挙げられています。現行ページではDeployment Tool based deploymentが推奨され、オンボーディング、アップグレード、アンインストールを含む幅広いシナリオを簡素化できると説明されています。(Microsoft Learn)
導入方式は、単に「今すぐ入れやすい方法」ではなく、今後の更新、証跡、標準化、ロールバックまで含めて選びます。
| デプロイ方式 | 向いている環境 | 注意点 |
|---|---|---|
| Deployment Tool | 新規展開、複数台展開、標準化したい環境 | プレビュー表記や利用条件を確認する |
| Installer script | 比較的少数のLinuxサーバー | 手順の属人化を避ける |
| Ansible・Chef・Puppet・SaltStack | 大規模・構成管理済み環境 | OS別条件と変数管理が重要 |
| ゴールデンイメージ | クラウドやVDI的な大量展開 | オンボーディング情報の扱いに注意 |
| 手動展開 | 検証・一時対応 | 本番標準にしない方がよい |
| Defender for Cloud直接オンボード | Azure・ハイブリッドサーバー管理 | 自動更新や対象範囲を確認する |
インストーラースクリプト方式では、展開前に--pre-reqオプションでメモリ、CPU、ディスク、サポートOSなどの最小要件をチェックすることが推奨されています。展開前チェックを標準手順に入れておくと、オンボーディング後の失敗を減らせます。(Microsoft Learn)
Compliance teamsが残すべき証跡
コンプライアンスチームにとって、今回の更新は「公式ドキュメントが変わったかどうか」だけでなく、「自社環境が公式前提条件に照らして説明可能か」を確認する機会です。
最低限、次の証跡を残しておくと監査対応がしやすくなります。
| 証跡 | 内容 |
|---|---|
| 公式ドキュメント確認日 | 英語版・日本語版の確認日、ページ更新日 |
| 対象サーバー一覧 | OS、バージョン、アーキテクチャ、用途 |
| サポート対象判定 | 対象、要確認、対象外の分類 |
| ネットワーク例外 | FW、プロキシ、SSL検査除外の設定根拠 |
| エージェント正常性 | mdatp healthの確認結果 |
| 更新期限 | product_expirationの確認結果 |
| 競合製品確認 | Fanotify利用製品、併用方針 |
| 例外承認 | カスタムOS、特殊ファイルシステム、性能除外の承認 |
監査では、「公式ドキュメントに書かれているから」だけでは不十分な場合があります。どのサーバーに、いつ、誰が、どの根拠で確認したかを記録しておくことで、変更管理・セキュリティ統制・リスク受容の説明ができます。
運用影響を判断するチェックリスト
今回のMicrosoft Defender公式ドキュメント更新を受けて、すぐに大規模な移行が必要とは限りません。ただし、次のいずれかに該当する環境では、早めに影響調査を行うべきです。
| 該当条件 | 優先度 | 推奨アクション |
|---|---|---|
| サポート一覧にないLinuxを使っている | 高 | 対象OSへの移行計画を作る |
| カスタムOSや独自カーネルを使っている | 高 | 標準ディストリビューションで再現確認できる体制を用意する |
| PAC、WPAD、認証プロキシに依存している | 高 | 静的または透過的プロキシへ見直す |
| SSL検査を一律適用している | 高 | Defender通信の検査除外を設計する |
| 他社EDRやAVと併用している | 高 | Fanotify競合と保護モードを確認する |
| NFS v3をスキャン対象にしている | 中 | no_root_squash条件と権限を確認する |
| UID/GID管理が厳格 | 中 | mdatpユーザーの事前作成方針を決める |
| エージェント更新を手動で放置している | 中 | 月次更新・期限確認を標準化する |
| ゴールデンイメージで展開している | 中 | イメージ更新とオンボーディング情報の扱いを確認する |
優先度が高い項目は、単なる設定漏れではなく、通信不能、検知不備、性能問題、サポート時の調査停滞につながります。特にプロキシとSSL検査は、オンボーディング時には見落とされやすく、後からセンサー不正常として発覚しやすい領域です。
移行準備として進めるべき手順
今回の更新をきっかけに、Microsoft Defender for Endpoint on Linuxの運用を見直すなら、次の順番で進めると安全です。
| 手順 | 作業内容 | 成果物 |
|---|---|---|
| 現状把握 | Linuxサーバー、OS、用途、エージェント状態を棚卸し | 対象サーバー一覧 |
| ギャップ判定 | 公式前提条件と照合 | 要対応リスト |
| 通信確認 | URL、プロキシ、SSL検査除外を確認 | ネットワーク設定証跡 |
| 競合確認 | 他社製品、Fanotify、性能影響を確認 | 併用方針 |
| パイロット | 代表環境で更新・再オンボーディングを検証 | 検証結果 |
| 本番展開 | 構成管理ツールやDeployment Toolで展開 | 変更管理記録 |
| 運用監視 | mdatp health、期限、アラート、性能を継続確認 | 月次点検記録 |
移行準備で失敗しやすいのは、検証対象を「標準的な1台」だけにしてしまうことです。実際には、ネットワークセグメント、OSバージョン、ファイルシステム、業務負荷、他社セキュリティ製品の有無によって結果が変わります。
最低でも、次の代表パターンを1台ずつ検証対象に含めると、後戻りを減らせます。
| 代表パターン | 検証理由 |
|---|---|
| 標準的なLinuxアプリサーバー | 基準となる正常パターンを作る |
| 高I/Oサーバー | パフォーマンス影響を確認する |
| プロキシ配下サーバー | クラウド接続の失敗を検出する |
| 他社EDR併用サーバー | Fanotify競合を確認する |
| NFS利用サーバー | スキャン権限とファイルシステム条件を見る |
| ARM64サーバー | 対応範囲と運用差分を確認する |
よくある誤解と失敗しやすいポイント
「エージェントが入っているから問題ない」と判断する
インストール済みであることと、正常に保護・通信・更新できていることは別です。mdatp health、クラウド接続、更新期限、ポータル上のデバイス状態を確認して初めて、運用上の正常性を判断できます。
日本語ページだけを見て判断する
日本語版のMicrosoft Learnは便利ですが、更新タイミングや翻訳表現が英語版と完全に同時とは限りません。今回のように公式更新を確認する場合は、英語版の原文と日本語版を併読する方が安全です。
SSL検査を証明書追加で回避できると思い込む
Defender for Endpoint on Linuxの通信では、SSL検査やインターセプトプロキシがサポートされないと明記されています。OSの証明書ストアに社内CAを追加すればよい、という発想で設計すると、通信不良やオンボーディング失敗につながります。(Microsoft Learn)
カスタムOSを「動いたからサポート対象」と見なす
カスタムOSでインストールや実行ができても、Microsoftの検証済みサポートベースラインに含まれるとは限りません。障害時に標準ディストリビューションで再現確認が必要になる可能性を、運用設計とリスク管理に入れておく必要があります。(Microsoft Learn)
競合製品の確認を後回しにする
他社EDRやアンチウイルスとの併用は、性能問題やシステムハングの原因になります。Fanotifyを使う製品がある場合は、オンボーディング前に併用方針を決め、必要に応じてDefenderの保護モードや除外設定を検討します。
この記事を読んだ後に取るべき次のアクション
今回のMicrosoft Defender公式ドキュメント更新「Learn Editor: Update mde-linux-prerequisites.md」は、Linux向けMicrosoft Defender for Endpointの前提条件を見直すよいタイミングです。すぐに全台を変更する必要があるとは限りませんが、少なくとも次の3つは早めに実施してください。
まず、Linuxサーバー台帳を作り、OSバージョン、アーキテクチャ、カーネル、用途、ファイルシステム、展開方式を整理します。次に、プロキシ、SSL検査、許可URL、Fanotify競合、mdatp healthの状態を確認します。最後に、更新期限とデプロイ方式を見直し、月次運用にmdatp healthとproduct_expirationの確認を組み込みます。
Microsoft Defenderの公式ドキュメント更新は、単なる情報更新ではなく、実環境のセキュリティ運用を点検するためのシグナルです。特にLinuxサーバーをグローバル規模で運用している組織では、サポート対象・通信要件・競合製品・更新期限を証跡付きで確認しておくことが、障害対応と監査対応の両方で役立ちます。
コメント