Microsoft Defenderの公式ドキュメント更新「Clarify installation notes for customized Linux OS」で最初に押さえるべき結論は、カスタマイズされたLinux OSへのインストールが全面的に新しくサポートされたわけではないという点です。今回の更新は、Microsoft Defender for Endpoint on LinuxをカスタムLinux環境で使う場合の「導入可否」と「サポート範囲」をより明確にしたものです。公式ドキュメントでは、条件を満たすカスタムOSではインストールやオンボードが可能な場合がある一方、Microsoftの検証済み・保守対象のサポートベースラインには含まれないと説明されています。(GitHub)
特にsecurity admins、compliance teams、enterprise IT readersが確認すべきなのは、技術的に動くかどうかではなく、障害発生時にMicrosoftサポートで調査を継続できる状態か、標準のサポート対象Linuxディストリビューションで再現確認できるか、社内の例外管理として記録できているかです。既存環境をすぐに移行する必要があるとは限りませんが、カスタムLinux OSでDefender for Endpointを運用している企業は、サポート境界・検証証跡・移行計画を見直すべきタイミングです。
Microsoft Defenderの公式ドキュメント更新「Clarify installation notes for customized Linux OS」で何が変わったか
今回の更新は、MicrosoftDocsのdefender-docsリポジトリにあるdefender-endpoint/mde-linux-prerequisites.mdへの変更です。GitHub上のコミットでは、変更対象は1ファイル、差分は4行追加・4行削除で、説明文も「カスタマイズされたLinux環境におけるMicrosoft Defender for Endpointのインストール注記を、明確性と一貫性のために更新した」とされています。つまり、エージェント機能そのものの追加や、Linux対応範囲の大幅拡張を示す更新ではありません。(GitHub)
実務上のポイントは、次の3つです。
| 確認ポイント | 読み取るべき意味 |
|---|---|
| 「MDE」ではなく「Defender for Endpoint」という表記に整理 | 製品名の一貫性を高める文書更新であり、別製品への変更ではない |
| カスタムLinux OSでもインストールや実行がブロックされない場合がある | 技術的にオンボードできる可能性はある |
| ただし、検証済み・保守対象のサポートベースラインには含まれない | 「動く」ことと「標準サポートされる」ことは別問題 |
この更新を読むときに避けたい誤解は、「カスタムLinux OSも正式サポート対象になった」と判断してしまうことです。公式ドキュメントは、明示的に一覧化されていないディストリビューションやバージョンはサポート対象外であるとしたうえで、カスタム環境についてはサポート上「custom OS configurations」として扱うと説明しています。(Microsoft Learn)
カスタムLinux OSでDefender for Endpointを使う場合の公式な扱い
Microsoft Learnの前提条件ページでは、Microsoft Defender for Endpoint on Linuxは、最小カーネル要件を満たし、Microsoftがサポートする既知の標準的なベンダー提供Linuxディストリビューションから派生しているカスタムOSでは、インストールでき、動作する可能性があると説明されています。あわせて、Microsoftはそのような環境でのオンボードや実行をブロックしないとも記載しています。(Microsoft Learn)
ただし、ここで重要なのは次の一文です。カスタマイズされた環境は、Microsoftの検証済みまたは保守対象のサポートベースラインには含まれません。そのため、サポート観点ではカスタムOS構成として扱われます。問題が発生した場合、顧客側でカスタム環境内のDefender for Endpointを検証し、必要に応じてサポート対象の標準・未変更Linuxディストリビューションで再現することが求められます。標準ベースディストリビューションで再現できない場合、Microsoftは調査や修正を進められない可能性があります。(Microsoft Learn)
運用担当者向けに言い換えると、判断基準は次のようになります。
| 公式ドキュメント上の表現 | 現場での解釈 |
|---|---|
| インストールでき、動作する可能性がある | 導入テストの対象にはできる |
| オンボードや実行はブロックされない | Defenderポータルに登録できる可能性はある |
| 検証済み・保守対象のサポートベースラインではない | 標準サポート対象と同じ扱いにはできない |
| 顧客側で検証が求められる | テスト結果、構成差分、例外承認の記録が必要 |
| 標準ディストリビューションで再現が必要な場合がある | 障害調査用に標準OSの再現環境を準備すべき |
「カスタマイズされたLinux OS」とは何を指すのか
今回の更新でいうカスタマイズされたLinux OSは、単に設定ファイルを変更した通常のLinuxサーバーだけを指すわけではありません。標準ディストリビューションをベースにしていても、OSイメージ、カーネル、セキュリティ機能、パッケージ構成、ファイルシステム、起動方式などに大きな変更が加えられている環境は、カスタムOS構成として扱われる可能性があります。
たとえば、次のような環境は確認対象に入れるべきです。
- RHEL、Ubuntu、Debian、SUSEなどをベースにした独自アプライアンスOS
- CIS BenchmarkやSTIG対応のために強くハードニングしたLinuxイメージ
- 不要パッケージを大幅に削除した最小構成のサーバーイメージ
- 独自カーネル、独自パッチ、オンラインカーネルパッチを利用する環境
- コンテナホスト向けに調整した専用Linuxイメージ
- クラウド環境で社内標準として配布しているゴールデンイメージ
- ベンダーが提供するが、一般的な標準ディストリビューションとは差分が大きいLinux
注意したいのは、「カスタムLinux OS」と「カスタムインストール場所」は別の論点だという点です。Defender for Endpoint on Linuxには、カスタムパスへインストールするための別ドキュメントがあり、そこではインストール先ディレクトリの権限、ディスク容量、SELinux利用時のsemanageなどが前提条件として説明されています。OS自体のサポート境界と、インストール先パスの変更を混同しないようにしましょう。(Microsoft Learn)
まず確認すべき技術要件
カスタムLinux OSでMicrosoft Defender for Endpointを使っている、またはこれから導入する場合は、最初にOS情報と前提条件を棚卸しします。公式ページでは、CPU、ディスク、メモリ、systemd、ネットワーク、サポート対象ディストリビューションなどが前提条件として示されています。たとえば、システム要件としては最小1 CPUコア、2 GB以上のディスク、1 GB以上のRAMが記載されています。(Microsoft Learn)
現場では、まず以下のコマンドで実態を確認します。
cat /etc/os-release
uname -r
uname -m
systemctl --versionDefender for Endpoint導入済みのサーバーでは、ヘルス状態も確認します。
mdatp health
mdatp health --output jsonmdatpコマンドはJSON出力にも対応しているため、構成管理ツールや監査レポートに組み込む場合は--output jsonを使うと扱いやすくなります。公式リソースページでも、コマンドラインで主要な設定確認や操作ができること、必要に応じてmdatp helpで利用可能なコマンドを確認することが案内されています。(Microsoft Learn)
サポート対象ディストリビューションとの関係を確認する
Microsoft Defender for Endpoint on Linuxの前提条件ページでは、サポート対象のLinuxサーバーディストリビューションが一覧化されています。2026年4月30日時点のページでは、Red Hat Enterprise Linux、CentOS、CentOS Stream、Ubuntu LTS、Ubuntu Pro、Debian、SUSE Linux Enterprise Server、Oracle Linux、Amazon Linux、Fedora、Rocky Linux、AlmaLinux、Marinerなどが、バージョンやアーキテクチャ別に掲載されています。(Microsoft Learn)
ただし、一覧に名前が似ているからといって、自社環境が自動的に同じ扱いになるわけではありません。たとえば「RHELベース」と称するアプライアンスOSでも、カーネル、パッケージ、セキュリティモジュール、リポジトリ、ファイルシステム構成が大きく変わっている場合は、標準のRHELと同じサポート体験を期待できない可能性があります。
チェック時は、次のように整理すると判断しやすくなります。
| 確認項目 | 確認方法 | 判断の目安 |
|---|---|---|
| ベースOS | /etc/os-release、ベンダー資料、イメージ設計書 | Microsoftのサポート対象一覧に近いか |
| バージョン | VERSION_ID、パッケージリポジトリ | 対象バージョン範囲内か |
| アーキテクチャ | uname -m | x64またはARM64の対応範囲内か |
| カーネル | uname -r、カーネル変更履歴 | 最小カーネル要件を満たすか |
| カスタム差分 | イメージ作成手順、ハードニング手順 | Defenderの動作に影響する変更がないか |
| 再現環境 | 標準OSの検証VM、クラウドイメージ | 障害時に標準OSで再現できるか |
特に、公式ページでは最小カーネル要件として3.10.0-327以降が記載されています。ただし、カーネル要件を満たすだけで、すべてのカスタムディストリビューションがサポート対象になるわけではありません。公式のサポート対象一覧と、カスタムOSの差分をセットで確認する必要があります。(Microsoft Learn)
運用影響：既存環境で何を見直すべきか
今回のMicrosoft Defender公式ドキュメント更新は、カスタムLinux OS上のDefender for Endpoint運用に対して、すぐにエージェントを入れ替えるよう求める内容ではありません。むしろ、既に運用している環境で「どこまでが標準サポートとして扱えるのか」を明文化するきっかけとして見るべきです。
見直すべき対象は、主に次の4つです。
| 対象 | 見直す内容 | 放置した場合のリスク |
|---|---|---|
| 本番Linuxサーバー | カスタムOSか標準OSかを台帳化する | 障害時にサポート境界を説明できない |
| セキュリティ監視 | mdatp healthの状態と競合アプリを確認する | 保護が期待どおり有効でない可能性がある |
| サポート手順 | 標準OSでの再現手順を用意する | Microsoftサポートで調査が進みにくい |
| コンプライアンス | 例外承認、検証結果、リスク受容を記録する | 監査時に根拠を示せない |
企業環境では、「Defenderポータルに表示されているから問題ない」と判断しがちです。しかし、オンボードできていること、検知イベントが上がっていること、Microsoftの標準サポート対象として扱えることは同じではありません。特に金融、医療、公共、製造など、監査証跡やサポート契約の説明責任が重い環境では、カスタムOSであること自体をリスク項目として管理する必要があります。
障害対応時に準備しておくべき情報
カスタムLinux OSでDefender for Endpointに問題が出た場合、原因がDefender側にあるのか、OSのカスタマイズに起因するのかを切り分ける必要があります。公式ドキュメントでは、問題を再現できる場合にログレベルを上げ、診断情報を収集する手順が案内されています。また、インストール問題の詳細ログは/var/log/microsoft/mdatp/install.logに保存されると説明されています。(Microsoft Learn)
サポート問い合わせ前に、少なくとも次の情報を揃えておくと調査が進めやすくなります。
| 情報 | 具体例 |
|---|---|
| OS情報 | ディストリビューション名、バージョン、アーキテクチャ、カーネル |
| カスタム内容 | 変更したカーネル、削除パッケージ、SELinux/AppArmor設定、独自リポジトリ |
| Defender情報 | インストール方法、チャネル、設定、mdatp health結果 |
| ネットワーク条件 | プロキシ、ファイアウォール、SSLインスペクション有無 |
| 再現条件 | 発生操作、時刻、対象プロセス、再現頻度 |
| 標準OSでの結果 | サポート対象の未変更ディストリビューションで再現するか |
| 診断ログ | mdatp diagnostic createで作成した診断ファイル、インストールログ |
障害対応の観点では、カスタムOS上のログだけでは不十分な場合があります。今回の更新で明確になったように、必要に応じてサポート対象の標準Linuxディストリビューションで再現確認できる体制を作ることが重要です。(Microsoft Learn)
Fanotifyベースのセキュリティ製品との競合にも注意する
Linux環境でDefender for Endpointを運用する場合、カスタムOSだけでなく、他のセキュリティ製品との共存にも注意が必要です。公式ドキュメントでは、Defender for Endpoint on Linuxと他のFanotifyベースのセキュリティソリューションを同時に実行することはサポートされず、システムハングを含む予測不能な動作につながる可能性があると警告されています。(Microsoft Learn)
これは、既存のアンチウイルス、EDR、ファイルアクセス制御、監査系エージェントを併用している企業で特に重要です。カスタムLinux OSでは、標準OSよりも監視系コンポーネントが多く組み込まれていることがあります。導入前のチェックでは、Defenderだけを見るのではなく、ファイルアクセスをフックする他製品やカーネル周辺の拡張も確認してください。
確認の観点は次のとおりです。
| 確認対象 | 見るべきポイント |
|---|---|
| 既存EDR・AV | リアルタイム保護が競合しないか |
| ファイルアクセス制御 | Fanotifyをブロッキングモードで使っていないか |
| 監査・改ざん検知 | 同じファイルイベントを過剰に監視していないか |
| カーネル拡張 | 独自モジュールやパッチがないか |
| 例外設定 | 相互除外が過剰または不足していないか |
Defender for Endpointの保護レベルをpassiveにする選択肢もありますが、これは単なる逃げ道ではありません。既存製品との役割分担、検知範囲、SOC運用、インシデント対応手順まで含めて設計する必要があります。
ネットワークとプロキシ設定も確認する
カスタムLinux OSのトラブルでは、OSそのものよりもネットワーク制御が原因になることがあります。公式ドキュメントでは、LinuxエンドポイントがDefender for Endpointのクラウドサービスへ接続できる必要があると説明されています。また、PAC、WPAD、認証付きプロキシはサポートされず、静的または透過プロキシを使うこと、SSL inspectionやintercepting proxyはセキュリティ上サポートされないことが明記されています。(Microsoft Learn)
特に企業ネットワークでは、次のような構成が問題になりやすいです。
- サーバーセグメントだけ外部通信が厳しく制限されている
- プロキシ認証が必須になっている
- SSLインスペクション対象にDefender通信が含まれている
- DNS解決や時刻同期が不安定
- ゴールデンイメージ作成時のプロキシ設定が本番環境と異なる
カスタムOS環境でDefender for Endpointを評価するときは、オンボード成功だけでなく、クラウド接続、セキュリティインテリジェンス更新、EDRイベント送信、アラート生成まで確認してください。
新規導入時の推奨フロー
新しくカスタムLinux OSへMicrosoft Defender for Endpointを導入する場合は、いきなり本番全体へ展開しない方が安全です。公式の手動展開ドキュメントでは複数の展開方法が案内されており、Defender Deployment Toolによる展開が推奨されています。手動展開では、リポジトリ設定、アプリケーションインストール、オンボードパッケージ、クライアント設定などの工程が必要です。(Microsoft Learn)
実務では、次の順番で進めると失敗を減らせます。
| ステップ | 実施内容 | 成果物 |
|---|---|---|
| 環境分類 | 標準OS、カスタムOS、アプライアンスOSを分ける | 対象サーバー一覧 |
| 前提条件確認 | OS、カーネル、systemd、CPU、メモリ、ディスクを確認 | 要件適合チェック表 |
| 差分整理 | 標準ディストリビューションからの変更点を洗い出す | カスタム差分一覧 |
| 小規模検証 | 検証環境でインストール、オンボード、ヘルス確認 | 検証ログ |
| 性能確認 | CPU、メモリ、I/O、アプリ影響を確認 | 性能影響レポート |
| セキュリティ確認 | 検知、隔離、EDRイベント、アラートを確認 | 機能確認結果 |
| 再現環境準備 | 標準OSで同等テストを行う | サポート用比較結果 |
| 展開判断 | 本番展開、例外管理、移行計画を決める | 承認記録 |
この流れにより、「導入できたか」だけでなく、「運用できるか」「サポートできるか」「監査で説明できるか」まで確認できます。
継続利用か移行かを判断する基準
カスタムLinux OSでDefender for Endpointを使っている場合、すべてを標準OSへ即時移行する必要はありません。しかし、サポート境界が明確になった以上、リスクに応じて判断する必要があります。
| 判断 | 向いている条件 |
|---|---|
| 継続利用 | ベースOSがサポート対象に近い、差分が小さい、検証結果が安定している、標準OSで再現環境を用意できる |
| 条件付き継続 | 業務上すぐ移行できないが、検証証跡と例外承認を残せる、障害時の切り分け手順がある |
| 段階的移行 | カスタム差分が大きい、標準OSで再現できない、監査要件が厳しい、本番重要度が高い |
| 利用見直し | ベースOSが不明、カーネルやパッケージが大幅に独自化されている、他セキュリティ製品と競合する、サポート説明が困難 |
おすすめは、すべてのLinuxサーバーを一律に扱わないことです。インターネット公開サーバー、基幹システム、個人情報や決済情報を扱うサーバー、監査対象システムは優先度を高くします。一方で、検証環境や一時的なワークロードでは、例外管理を前提に運用する選択肢もあります。
コンプライアンスチームが確認すべき文書化ポイント
今回の更新は、セキュリティ運用だけでなく、コンプライアンスや監査対応にも影響します。カスタムLinux OSでDefender for Endpointを利用する場合、単に「導入済み」と記録するだけでは不十分です。サポート対象外または標準サポート外の構成である可能性を踏まえ、リスク受容の根拠を残す必要があります。
文書化するなら、次の項目を最低限含めてください。
| 文書化項目 | 記載例 |
|---|---|
| 対象範囲 | カスタムLinux OSを利用するサーバー名、役割、環境 |
| 公式要件との差分 | ベースOS、バージョン、カーネル、カスタム内容 |
| Defenderの状態 | オンボード状況、ヘルス、保護設定、EDR連携 |
| 検証結果 | インストール、検知、更新、性能、業務影響 |
| サポート制約 | 標準OSで再現が必要になる可能性 |
| リスク評価 | 影響度、発生可能性、代替策 |
| 承認者 | セキュリティ責任者、システムオーナー、コンプライアンス担当 |
| 見直し頻度 | 半年ごと、OS更新時、Defender更新時など |
監査向けには、次のような説明文を社内標準として用意しておくと便利です。
カスタムLinux OS上のMicrosoft Defender for Endpointは、技術的にインストールおよびオンボード可能な場合がある。ただし、Microsoftの検証済み・保守対象のサポートベースラインには含まれない可能性があるため、当社では対象サーバーごとに前提条件、検証結果、標準OSでの再現可否、リスク受容を記録する。
このように書いておくと、セキュリティ管理者、監査担当、システムオーナーの認識をそろえやすくなります。
よくある誤解と失敗しやすいポイント
オンボードできたから正式サポート対象だと思い込む
最も多い誤解は、Microsoft Defenderポータルにデバイスが表示され、アラートが上がるため「正式サポートされている」と判断してしまうことです。公式ドキュメントは、オンボードや実行をブロックしない場合がある一方で、カスタム環境は検証済み・保守対象のサポートベースラインではないと説明しています。(Microsoft Learn)
カーネル要件だけを見て判断する
最小カーネル要件を満たしていても、ディストリビューション、パッケージ、ファイルシステム、セキュリティ機能、他社エージェントとの組み合わせによって問題が出ることがあります。カーネルだけでなく、公式のサポート対象一覧とカスタム差分を確認してください。
ゴールデンイメージでの検証を省略する
クラウドや大規模サーバー運用では、ゴールデンイメージにDefenderを組み込んで展開するケースがあります。このとき、イメージ作成時点では正常でも、実際の本番ネットワーク、プロキシ、ファイアウォール、SELinuxポリシー、業務アプリのI/O負荷で問題が起きることがあります。検証はイメージ単体ではなく、本番に近い条件で行うべきです。
標準OSの再現環境を用意していない
今回の更新で特に重要なのは、問題発生時にサポート対象の標準・未変更Linuxディストリビューションで再現が必要になる可能性がある点です。再現環境がないと、サポート問い合わせの途中で調査が止まる可能性があります。(Microsoft Learn)
プロキシやSSLインスペクションを軽視する
Defender for Endpoint on Linuxはクラウドサービスとの通信が前提です。PAC、WPAD、認証付きプロキシ、SSLインスペクションなど、企業ネットワークで一般的な構成がそのまま使えないケースがあります。カスタムOS検証では、ネットワーク要件を最初から確認してください。(Microsoft Learn)
いま実施すべきチェックリスト
今回のMicrosoft Defender公式ドキュメント更新を受けて、まずは次のチェックを進めてください。
| 優先度 | チェック項目 | 対応 |
|---|---|---|
| 高 | カスタムLinux OS上でDefenderを使っているか | サーバー台帳と照合する |
| 高 | ベースOSが公式のサポート対象一覧に近いか | OS名、バージョン、アーキテクチャを確認する |
| 高 | カスタム差分を説明できるか | イメージ作成手順やハードニング内容を整理する |
| 高 | mdatp healthが正常か | JSON出力で記録する |
| 高 | 他のFanotify系セキュリティ製品と競合していないか | 併用製品と保護モードを確認する |
| 中 | 標準OSの再現環境があるか | RHEL、Ubuntu、Debianなどで検証VMを用意する |
| 中 | プロキシとSSLインスペクションの例外が適切か | ネットワーク担当と確認する |
| 中 | 障害時の診断ログ取得手順があるか | mdatp diagnostic createを手順化する |
| 中 | 例外承認とリスク受容を記録しているか | コンプライアンス文書に反映する |
| 低 | 将来的に標準OSへ移行できるか | 移行候補と時期を整理する |
まとめ：カスタムLinux OSでは「導入可」より「説明可能性」を重視する
2026年4月30日のMicrosoft Defender公式ドキュメント更新「Clarify installation notes for customized Linux OS」は、カスタムLinux OSでDefender for Endpointを使う企業にとって重要な確認材料です。今回の更新は、製品機能の大幅な変更ではなく、カスタムLinux環境におけるインストール、実行、サポート境界を明確にするものです。
実務で取るべき次の行動は明確です。まず、Defender for Endpointを導入しているLinuxサーバーを棚卸しし、標準OSかカスタムOSかを分類します。次に、OS要件、カーネル、systemd、ネットワーク、Fanotify競合、mdatp healthを確認します。そのうえで、カスタムOS環境については検証結果、標準OSでの再現可否、リスク受容を文書化します。
カスタムLinux OSでMicrosoft Defenderを運用する際のゴールは、「とりあえず動かすこと」ではありません。障害時に切り分けられ、Microsoftサポートに必要な情報を提示でき、監査でも説明できる状態を作ることです。今回の公式更新をきっかけに、セキュリティ運用とコンプライアンスの両面から、自社のLinux Defender運用を見直してください。
コメント