Symantec Endpoint Security から Microsoft Defender 系製品へ移行する際、とくに悩ましいのが「インターネットに出られないオンプレサーバーをどう守るか」です。Defender for Endpoint と Defender for Servers の違い、そして完全オフライン環境・プロキシ経由環境・インターネット到達可能環境の3パターン別に、現実的な製品選定と構成の考え方を整理します。
Symantec から Microsoft Defender へ移行するときの前提
まず押さえておきたいのは、Symantec Endpoint Security と Microsoft Defender ファミリーの思想の違いです。
- Symantec：オンプレ中心のエンドポイント保護（EPP）＋一部クラウド連携
- Microsoft Defender：クラウドを前提とした EDR/XDR プラットフォーム
特にサーバー向けの EDR/XDR は、ほぼ例外なくクラウド側にログとテレメトリを送信することを前提に設計されています。そのため、
- 「完全にインターネットに出られないエアギャップ環境」
- 「直接インターネットには出られないが、プロキシやゲートウェイ経由なら許可」
- 「インターネットへ直接またはファイアウォール越しに到達可能」
といったネットワーク条件ごとに、取れる選択肢が大きく変わります。
Defender for Endpoint と Defender for Servers の違い
最初に、よく混同される 2 つの製品の役割を整理します。
役割のざっくりイメージ
- Microsoft Defender for Endpoint（MDE）
エンドポイント（PC・サーバー・一部モバイル/デバイス）向けの EDR 製品。動作そのものはクライアント・サーバー共通で、クラウド側（Microsoft Defender XDR ポータル）で検知・相関・自動対応を行います。 - Microsoft Defender for Servers
Azure Defender for Cloud（旧 Azure Security Center）の一機能として提供される、サーバーワークロード向けのセキュリティプラン。MDE をサーバーに自動展開しつつ、脆弱性管理や CWPP（Cloud Workload Protection）機能をまとめて提供する「サーバー総合パック」のような位置付けです。
製品比較表
| 比較項目 | Defender for Endpoint | Defender for Servers |
|---|---|---|
| 想定対象 | PC・サーバー共通の EDR | サーバー特化のセキュリティプラン（オンプレ・Azure・他クラウド） |
| 主な役割 | EDR / 次世代 AV / 自動調査・応答 / TVM | サーバーの EDR＋脆弱性管理＋ワークロード保護（JIT、FIM など） |
| ライセンス | クライアント：MDE Plan 1/2（Microsoft 365 E5 等に含まれる場合あり） サーバー：クライアント向け MDE P1/P2 だけでは不可で、Defender for Servers Plan 1/2 や MDE for Server などサーバー向けライセンスが別途必要 | Defender for Servers Plan 1 / Plan 2 （いずれもサーバー用の MDE P2 相当機能を含む） |
| 管理コンソール | Microsoft Defender XDR ポータル | Defender for Cloud ポータル＋Microsoft Defender XDR ポータル |
| 必須通信 | Microsoft Defender クラウドサービスへ直接またはプロキシ経由で HTTPS 通信 | Azure Arc / Log Analytics / Defender for Endpoint 経由で Microsoft クラウドへ HTTPS 通信 |
| 真にオフラインでの EDR | 不可（クラウド接続が前提） | 不可（Defender for Cloud もクラウド前提） |
| オフラインで可能なこと | Microsoft Defender Antivirus のローカルスキャンのみ。定義更新は WSUS / ConfigMgr / Linux 用ミラーサーバー等でオフライン配布可能 | 基本は左に同じ（中身は MDE エージェント＋Defender AV） |
ポイントは、どちらの製品も「クラウドとつながらないと本来の EDR としては動かない」という点です。Defender for Servers を選んだからといって、完全オフラインになるわけではありません。
Defender for Endpoint の特徴
MDE は、以下のような機能を持つクラウドネイティブな EDR です。
- 振る舞い検知による高度な攻撃検出
- タイムライン表示・プロセスツリーなどの詳細なインシデント分析
- 自動調査・自動修復（自動隔離・サービス停止など）
- 脆弱性管理（ソフトウェア・設定のリスク可視化）
- クエリベースの高度なハンティング機能
これらはすべて、端末から収集したテレメトリが Microsoft クラウドに送信されることを前提に設計されています。そのため、インターネットに一切到達できないサーバーではこれらの機能は動作しません。
Defender for Servers の特徴
Defender for Servers は、Azure やオンプレサーバーを「サーバーワークロード」として守るための統合プランです。
- MDE の EDR 機能（Plan 2 相当）をサーバーに提供
- サーバー向けの脆弱性管理（ソフトウェア・設定・証明書など）
- ファイル整合性監視（FIM）や OS 構成評価
- Just-In-Time VM アクセスなどの攻撃面の削減機能
- Agentless スキャンによる脆弱性・マルウェアチェック（Plan 2）
現在の仕様では、Plan 1 も Plan 2 も MDE P2 の EDR 機能を含みますが、Plan 2 が Plan 1 の上位互換であり、より多くのサーバー側機能（Agentless スキャンや詳細な脆弱性管理、FIM など）を提供します。
完全オフライン（エアギャップ）環境での現実的な選択肢
「インターネットへの経路が一切ない」「プロキシやゲートウェイもNG」という完全エアギャップ環境では、Microsoft 純正の EDR / XDR は基本的に利用できません。
なぜ MDE / Defender for Servers は動作しないのか
主な理由は次のとおりです。
- MDE はクラウド上で検知・相関・インシデント生成を行うため、テレメトリ送信が必須
- Defender for Servers も Defender for Cloud（Azure）の機能であり、Azure 側との通信が前提
- オフラインでの「登録」「テナント紐付け」「センサー更新」の仕組みが提供されていない
そのため、完全オフライン環境では以下のような制約になります。
| やりたいこと | MDE / Defender for Servers | 現実的な代替策 |
|---|---|---|
| EDR による振る舞い検知・インシデント管理 | 不可 | オフライン対応のサードパーティ製 EDR を検討 |
| ウイルス・マルウェア対策（シグネチャ＋一部挙動） | Defender Antivirus のローカルスキャンは可 | Defender AV のみ利用し、定義をオフライン更新 |
| 脆弱性管理・資産管理 | クラウド連携前提のため不可 | オンプレ専用の脆弱性スキャナ（例：オフラインスキャン可能製品）を導入 |
オフラインで実現できる Microsoft 製品の使い方
完全オフライン環境でも、以下のように Defender Antivirus をスタンドアロン AV として利用すること自体は可能です。
- Windows サーバー：WSUS や ConfigMgr を利用して定義ファイルをオフライン配布
- Linux サーバー：インターネット側に配置したミラーサーバーから定義を取得し、それを隔離ネットワークに持ち込む形で更新
この場合のポイントは、
- 「EDR ではなく、あくまでアンチウイルス製品として割り切る」
- ログの集中管理やインシデントタイムラインといった EDR らしい機能は期待しない
- 補完として OS パッチ管理、ハードニング、アクセス制御などの基本対策を強化する
という割り切りです。
どうしても EDR が必要な場合の選択肢
規制業界などで「オフラインでも EDR が必須」という要件がある場合、現時点での現実的な選択肢は次のどちらかです。
- Microsoft にこだわらず、オフライン対応の EDR 製品を採用
一部ベンダーは、EDR データをローカルアプライアンスに蓄積する方式の製品を提供しており、真にエアギャップでも使えるケースがあります。 - 「完全オフライン」から「限定的な外部通信あり」へセキュリティ方針を見直す
Defender 用にのみ、プロキシ／ゲートウェイ経由で Microsoft クラウドへの HTTPS 通信を許可し、その他の外部通信は引き続き遮断する、というアプローチです。
後者を選ぶ場合、次の章で解説する「プロキシ／中継ありの環境設計」が重要になります。
「外へ出られないがプロキシ／中継は許可」の環境設計
多くの企業で現実的なのが、
- サーバーは直接インターネットに出さない
- ただし、社内のプロキシサーバーやゲートウェイを経由した限定的な外部通信は許可
というパターンです。この場合、MDE も Defender for Servers も運用が可能です。
典型的なネットワーク構成イメージ
文章で図を表すと、次のような流れになります。
- オンプレサーバー（Windows / Linux）
- ▼
- 社内プロキシ or Log Analytics ゲートウェイ（旧 OMS Gateway）
- ▼
- インターネット／Microsoft クラウド（Defender for Endpoint, Defender for Cloud 等）
この構成で注意すべきポイントは以下の通りです。
- プロキシは MDE 用の URL / FQDN 一覧を「認証なしで」通過させる
- Defender 関連通信には HTTPS インスペクション（SSL 復号）を行わない
- できるだけ経路をシンプルにし、二重 NAT や多段プロキシは避ける
この環境での製品選定の考え方
プロキシ経由で Microsoft クラウドに出られる前提で、一般的には次のように考えると整理しやすくなります。
| サーバー台数 / 要件 | 推奨プラン | コメント |
|---|---|---|
| 台数少なめ、EDR 中心でよい | MDE for Server（または Defender for Servers Plan 1） | サーバーにも MDE の EDR を導入。脆弱性管理などは別製品や手作業で補完。 |
| 台数多め、脆弱性管理やコンプライアンスも重視 | Defender for Servers Plan 2 | MDE EDR＋サーバー向け脆弱性管理＋CWPP を統合的に利用できるため、運用負荷を下げやすい。 |
| Azure / 他クラウド / オンプレのハイブリッド環境 | Defender for Servers Plan 2 ＋ Azure Arc | クラウド・オンプレ混在環境を Defender for Cloud で一元監視する構成が取りやすい。 |
プロキシ接続設計のチェックポイント
プロキシ／ゲートウェイ経由で MDE / Defender for Servers を動かす場合、次の点を意識するとトラブルを減らせます。
| 項目 | 推奨・注意点 |
|---|---|
| 認証方式 | MDE のサービスはローカルシステムアカウントで動作するため、ユーザー認証必須のプロキシは非推奨。Defender 通信については IP / サブネット単位で認証なし許可とするのが現実的。 |
| HTTPS インスペクション | Defender 用の URL / FQDN には SSL インスペクションをかけない。中間証明書のすり替えで通信が失敗する原因になりやすい。 |
| URL / FQDN の許可 | Microsoft が公開している Defender 向け URL / FQDN 一覧を、プロキシとファイアウォールの両方で許可する。 |
| 経路のシンプルさ | 二重 NAT や多段プロキシはトラブルの温床。可能な限り「サーバー → プロキシ → インターネット」の最短経路にする。 |
| 疎通確認 | Defender 用の接続テストツール（クライアントアナライザー）などを活用し、テナントへの接続可否を事前に検証する。 |
Windows サーバーでのプロキシ設定の考え方
Windows サーバーでは、次のような方針で設定を整理すると管理しやすくなります。
- OS 全体の WinHTTP プロキシを「サーバー → 社内プロキシ」に向ける
- MDE 用にはレジストリベースの静的プロキシ設定を使い、プロキシを明示的に指定する
- ユーザー毎の IE/Edge のプロキシ設定（WinINET）は、MDE の通信とは切り離して考える
たとえば、WinHTTP プロキシは次のようなコマンドで設定します。
netsh winhttp set proxy proxyserver.example.local:8080
そのうえで、MDE の構成プロファイルや GPO を使って、Defender 専用の静的プロキシをレジストリに流し込む構成にすると、大規模環境でも管理しやすくなります。
Linux サーバーでのプロキシ設定の考え方
Linux ではディストリビューションごとに細部は異なりますが、概ね次のようなポイントを押さえます。
- MDE エージェントのサービス単位で HTTP_PROXY / HTTPS_PROXY 環境変数を設定する
- systemd 環境であれば、サービスの override ファイルにプロキシ設定を記述
- OS 全体の yum/apt 用プロキシとは切り分けて管理する（MDE 専用にする）
これにより、OS アップデートの通信経路と MDE テレメトリの通信経路を独立して制御でき、トラブルシュートも容易になります。
インターネット到達可能な環境でのベストプラクティス
サーバー自身がインターネットへ直接、またはシンプルなファイアウォール越しに出られる環境であれば、構成は比較的シンプルです。
基本方針：Defender for Servers Plan 2 を軸にする
インターネット到達可能なサーバーについては、Defender for Servers Plan 2 を標準プランとする構成が最もシンプルです。
- MDE による EDR・自動調査・自動修復
- サーバー向け脆弱性管理（ソフトウェア・設定・証明書など）
- OS 構成評価やセキュリティベースライン準拠状況の可視化
- ファイル整合性監視（FIM）、Just-In-Time アクセス、Agentless スキャン など
これらをまとめて利用できるため、個別に製品を組み合わせるよりも運用工数と可視性のバランスがよいのが利点です。
Microsoft 365 E5 / E5 Security とのライセンス重複に注意
クライアント PC 側で既に Microsoft 365 E5 や E5 Security を契約している場合、多くのケースで MDE Plan 2 が含まれています。そのため、次のような整理が必要です。
- クライアント PC：Microsoft 365 側の MDE P2 ライセンスを使用
- サーバー：Defender for Servers Plan 1 / Plan 2 など、サーバー専用ライセンスでカバー
サーバーに対してクライアント向け MDE P1/P2 ライセンスを流用することはできないため（サーバー用ライセンスが別に必要）、「どの製品でどのエンドポイントをカバーしているか」を一覧化しておくことが重要です。最終的な条件は契約形態によって変わりうるため、正式にはライセンスガイドやリセラーに確認するのが安全です。
サーバー種別ごとの構成パターン例
ここまでの内容を踏まえ、代表的なサーバー種別ごとの構成パターン例を挙げます。
| サーバー種別 | ネットワーク条件 | 推奨構成 | 補足 |
|---|---|---|---|
| ドメインコントローラー（AD） | プロキシ経由で外部通信可 | Defender for Servers Plan 2（MDE 有効） | 攻撃の標的になりやすいため、EDR＋脆弱性管理を優先。Proxy 設計と FQDN 許可を慎重に。 |
| 基幹系アプリサーバー | プロキシ経由で限定的な外部通信可 | Defender for Servers Plan 2 または Plan 1＋別途脆弱性スキャナ | 業務影響を避けるため、一部の自動修復アクションは監査モードから開始するのが無難。 |
| ファイルサーバー | インターネット到達可 | Defender for Servers Plan 2 | ランサムウェア対策として EDR＋AV＋FIM が有効。バックアップとの組み合わせも重要。 |
| 研究・検証用サーバー | インターネット到達可 | MDE for Server（または Defender for Servers Plan 1） | コストを抑えたい場合は、最低限の EDR を優先し、詳細な脆弱性管理は対象外とする判断もあり。 |
| 規制ネットワーク内サーバー（完全オフライン） | 外部通信不可 | Defender AV スタンドアロン＋オフライン定義更新 | EDR は別ベンダーを検討するか、ネットワークポリシーを見直して限定的な外部通信を許可するかの判断が必要。 |
製品選定・設計を進める手順例
最後に、実際に Symantec から Microsoft Defender へ移行する際の進め方を、手順としてまとめます。
サーバーをネットワーク条件で分類する
- 完全オフライン（エアギャップ）
- プロキシ／ゲートウェイ経由なら外部通信可
- インターネット到達可
この分類を棚卸ししたうえで、どのカテゴリに何台あるかを Excel などで一覧化しておくと、その後の設計・見積もりがスムーズです。
サーバーごとの「求める保護レベル」を決める
- アンチウイルスだけでよいのか
- EDR（インシデントタイムライン・ハンティング）が必要か
- 脆弱性管理や構成評価まで Microsoft 製で統一したいか
「すべてのサーバーで最高のプランを入れる」のが理想ではありますが、現実にはコストと運用負荷のバランスが必要です。たとえば「ドメインコントローラー・重要基幹サーバーは Plan 2、それ以外は Plan 1」というように、リスクと重要度でレベル分けするのが現実的です。
ライセンスと構成パターンをマッピングする
ここまで決めた内容をもとに、次の観点でマッピングします。
- クライアント PC は Microsoft 365 側の MDE ライセンスでカバーできているか
- サーバーには Defender for Servers Plan 1/2 などサーバー用ライセンスを割り当てているか
- 完全オフラインサーバーは「Defender AV のみ」と割り切れているか
- プロキシ設計や FQDN 許可方針がネットワークチームと合意できているか
この段階まで整理できれば、あとはパイロット導入 → 検証 → 本番展開のステップを踏むだけです。特にプロキシ周りは、最初に 2～3 台のテストサーバーで「テレメトリがクラウドに届くか」「インシデントが見えるか」を確認してから一気に展開するのがおすすめです。
まとめ：オフライン環境サーバーでの Microsoft Defender 製品選定の要点
- Defender for Endpoint も Defender for Servers もクラウド前提であり、「Defender for Servers ならオフラインで動く」という理解は誤りです。
- 完全エアギャップ環境では、Microsoft 製 EDR/XDR は基本的に利用できず、Defender Antivirus のスタンドアロン利用＋オフライン定義更新が現実的な選択肢になります。
- 「外へ出られないがプロキシ／中継は許可」の環境であれば、プロキシ設計と FQDN 許可を適切に行うことで MDE / Defender for Servers を運用可能です。
- サーバーがインターネット到達可能な環境では、Defender for Servers Plan 2 を軸に EDR＋脆弱性管理＋CWPP を統合する構成がもっともシンプルかつ強力です。
- 最後に、クライアントとサーバーでライセンスのカバー範囲をきちんと棚卸しし、Microsoft 365 E5 など既存契約との重複や抜けをなくすことが、コスト最適化の鍵となります。
Symantec から Microsoft Defender への移行は、単なる製品置き換えではなく、「クラウドネイティブな検知・対応基盤への移行」でもあります。本記事の内容をベースに、自社のネットワーク制約と求めるセキュリティレベルを整理し、最適な Defender 構成を検討してみてください。
コメント