Microsoft Defender for Cloud の Defender for Servers を利用している管理者が最初に確認すべき点は、サーバー保護の中心が「Defender for Endpoint 統合」と「エージェントレス スキャン」に整理されていることです。2026年5月20日に更新された公式ページでは、Log Analytics エージェントと Azure Monitoring Agent（AMA）は Defender for Servers でサポートされなくなり、多くの機能はエージェントレス スキャンと Microsoft Defender for Endpoint 統合で置き換えられると明記されています。(Microsoft Learn)
この記事では、Microsoft Defender for Cloud の Defender for Servers について、変更点、影響範囲、P1/P2の選び方、展開時の注意点を管理者目線で整理します。結論として、既存環境でまず行うべきことは、対象サーバーの棚卸し、プラン選定、Azure Arc のオンボード状況、Defender for Endpoint の自動プロビジョニング、P2で有効になるエージェントレス機能の確認です。
Microsoft Defender for Cloud の Defender for Serversとは
Defender for Servers は、Microsoft Defender for Cloud に含まれるサーバー保護プランです。Azure VM だけでなく、AWS、Google Cloud Platform（GCP）、オンプレミス環境の Windows / Linux マシンを対象に、セキュリティ態勢の改善提案、脆弱性評価、脅威検出、アラート連携などを提供します。(Microsoft Learn)
単なるウイルス対策ではなく、クラウドとオンプレミスを横断して「どのサーバーにリスクがあるか」「どの設定を直すべきか」「攻撃の兆候が出ていないか」を一元的に確認するためのサービスです。
特に今回の公式情報で重要なのは、次の3点です。
| 確認ポイント | 管理者が理解すべき意味 |
|---|---|
| Log Analytics エージェント / AMA への依存が整理された | Defender for Servers の多くの機能は、Defender for Endpoint 統合とエージェントレス スキャン中心で考える必要がある |
| P1とP2で利用できる機能が大きく異なる | EDR中心ならP1、エージェントレス脆弱性評価・シークレットスキャン・FIMなども必要ならP2を検討する |
| 展開スコープに制約がある | P1はリソース単位で有効化できるが、P2はリソース単位で有効化できず、リソース単位の無効化のみ可能 |
今回の更新で管理者が見るべき変更点
Log Analytics エージェントとAMA前提の運用を見直す
公式ページでは、Defender for Servers が Log Analytics エージェントと Azure Monitoring Agent（AMA）をサポートしなくなったことが明記されています。多くの機能では、エージェントレス マシン スキャンと Defender for Endpoint 統合が代替になります。(Microsoft Learn)
ここで注意したいのは、「AMAが完全に不要になる」という意味ではないことです。たとえば、Plan 2 の一部データ型で500MBの無料データ インジェストを利用する場合、AMAとLog Analytics ワークスペースへの接続が必要とされています。(Microsoft Learn)
つまり、移行時の判断基準は次のようになります。
| 現在の運用 | 判断 |
|---|---|
| Defender for Servers の保護機能のためだけに旧エージェントを使っている | Defender for Endpoint 統合とエージェントレス スキャンへの移行を優先する |
| Log Analytics ワークスペースで監査ログや運用ログを収集している | すぐ削除せず、収集目的と依存するクエリ・アラートを確認する |
| FIMやデータ インジェスト特典を使う予定がある | Log Analytics ワークスペースやAMA要件を個別に確認する |
| 「エージェント削減」を目的にP2を導入する | エージェントレスで取得できる範囲と、Defender for Endpoint エージェントが必要な範囲を切り分ける |
失敗しやすいのは、「Defender for ServersではAMAが不要」とだけ読んで、既存の監視基盤やFIMのワークスペース設定まで削除してしまうケースです。移行時は、Defender for Servers の保護機能、ログ分析、コンプライアンス監査を分けて棚卸ししてください。
Defender for Endpoint統合が保護の中核になる
Defender for Servers では、Microsoft Defender for Endpoint と Microsoft Defender Vulnerability Management が Defender for Cloud と統合されます。これにより、EDR、脆弱性管理、ソフトウェア インベントリ、統合アラートなどを Defender for Cloud 側でも扱えるようになります。(Microsoft Learn)
管理者が確認すべきポイントは、Defender for Endpoint センサーの自動プロビジョニングです。Defender for Cloud は、サポート対象マシンに Defender for Endpoint センサーを自動的にプロビジョニングできます。(Microsoft Learn)
本番サーバーで有効化する前に、次を確認しましょう。
| 確認項目 | 具体的な確認内容 |
|---|---|
| 自動プロビジョニング | どのサブスクリプション、AWSアカウント、GCPプロジェクト、Arc対応サーバーに適用されるか |
| 既存EDRとの重複 | 既に別のEDRやウイルス対策を導入している場合、競合や運用分担を確認する |
| アラート運用 | Defender for Cloud、Defenderポータル、SIEMのどこで一次対応するか |
| 脆弱性管理 | 推奨事項を誰が確認し、どのSLAで修正するか |
特に開発環境や検証環境を含むサブスクリプションでは、「本番だけ守るつもりが、全サーバーに自動展開された」という状況が起きやすくなります。サブスクリプション単位で有効化する前に、対象リソースのタグ設計と除外方針を決めておくと安全です。
影響範囲：AzureだけでなくAWS、GCP、オンプレミスも対象
Defender for Servers の対象は、Azure VMに限定されません。公式情報では、Azure、AWS、GCP、オンプレミス環境で実行される Windows / Linux マシンを保護対象としています。(Microsoft Learn)
| 環境 | 影響範囲 | 管理者が確認すべきこと |
|---|---|---|
| Azure VM | Defender for Servers の主要な対象 | サブスクリプション単位の有効化範囲、P1/P2、除外対象 |
| AWS EC2 | Defender for Cloud への接続とArcオンボードが重要 | AWSアカウント接続、必要なポート443通信、Arc状態 |
| GCP Compute | GCPプロジェクト接続とArcオンボードが重要 | GCPコネクタ、必要URLへの通信、プロジェクト単位の適用範囲 |
| オンプレミスサーバー | Azure Arc 対応サーバーとしてのオンボードが推奨 | Arcエージェント、ネットワーク、OSサポート |
| Windows / Linux | OSごとに対応機能や要件が異なる | サポートバージョン、Defender for Endpoint の導入状態 |
オンプレミスやマルチクラウドで全機能を使いたい場合は、Azure Arc 対応VMとしてオンボードすることが推奨されています。直接オンボードでは、Defender for Servers Plan 2 の機能にフルアクセスできない点に注意が必要です。(Microsoft Learn)
P1とP2の違い：どちらを選ぶべきか
Defender for Servers には、Plan 1（P1）とPlan 2（P2）があります。P1はDefender for Endpoint統合によるEDR機能を中心としたプラン、P2はP1の機能に加えて、エージェントレス スキャン、OS構成評価、ファイル整合性監視、シークレットスキャン、マルウェアスキャンなどを含む上位プランです。(Microsoft Learn)
| 判断基準 | P1が向いているケース | P2が向いているケース |
|---|---|---|
| 主目的 | EDRと基本的なサーバー保護を導入したい | 脆弱性、構成ミス、シークレット、マルウェア、FIMまで広く見たい |
| 対象範囲 | 特定サーバーから段階導入したい | サブスクリプションやクラウド環境単位で包括的に保護したい |
| エージェントレス機能 | 基本的に対象外 | エージェントレス脆弱性評価、シークレットスキャン、マルウェアスキャンを使いたい |
| コンプライアンス | 最低限の可視化から始めたい | FIMやOS構成評価を含めて監査対応を強めたい |
| 展開粒度 | リソース単位で有効化しやすい | リソース単位の有効化はできず、必要に応じてリソース単位で無効化する |
実務では、まず本番サーバー群をP2で評価し、開発・検証サーバーはP1または除外にする、といった設計が現実的です。ただし、P2はリソースレベルで「有効化」はできないため、細かく対象を分けたい場合はサブスクリプション設計やタグベースの除外方針を先に決める必要があります。(Microsoft Learn)
有効化後に自動で起きること
Defender for Servers を有効化すると、いくつかの動作が自動的に始まります。特に、試用期間、自動プロビジョニング、P2の既定機能は事前確認が必要です。
| 有効化後の動作 | 注意点 |
|---|---|
| 30日間の試用期間が始まる | 停止、一時停止、延長はできないため、評価項目を決めてから開始する |
| Defender for Endpoint 拡張機能が自動インストールされる | サポート対象マシンに自動展開されるため、既存のエンドポイント保護と運用設計を確認する |
| Defender Vulnerability Management が既定で有効になる | 脆弱性やソフトウェア インベントリの確認体制を決める |
| P2ではエージェントレス スキャンが既定で有効になる | スキャン対象、検出結果の確認先、対応フローを決める |
| P2のOS構成評価には拡張機能が必要 | Azure Machine Configuration 拡張機能の導入状況を確認する |
| FIMは有効化後に別途設定する | Log Analytics ワークスペースや監視対象ファイルを設計する |
公式情報では、Defender for Servers プランを有効化すると30日間の試用期間が始まり、停止・一時停止・延長はできないとされています。また、P2ではエージェントレス スキャンが既定で有効になります。(Microsoft Learn)
エージェントレス スキャンで確認できること
Plan 2で重要なのが、エージェントレス マシン スキャンです。エージェントをインストールせず、ネットワーク接続にも依存せず、マシンのパフォーマンスに影響を与えない方式として説明されています。(Microsoft Learn)
エージェントレス スキャンでは、主に次のような確認ができます。
| 機能 | 実務での使いどころ |
|---|---|
| EDR設定の評価 | Defender for Endpoint が正しく構成されているか確認する |
| ソフトウェア インベントリ | サーバー上のソフトウェアを把握し、脆弱性管理に使う |
| 脆弱性スキャン | パッチ未適用や脆弱なソフトウェアの把握に使う |
| シークレット スキャン | 平文の資格情報、キー、トークンなどの検出に使う |
| マルウェア スキャン | Defender Antivirus を使ったマルウェア検出に使う |
| KubernetesノードVMの評価 | Defender for Servers P2またはDefender for Containers有効時に利用する |
スキャンはVMディスクのスナップショットを使って行われ、コピーされたスナップショットはVMと同じリージョンに保持され、必要なメタデータ取得後に削除されます。(Microsoft Learn)
開発者にとって特に重要なのは、シークレット スキャンです。アプリケーションの設定ファイル、古いデプロイスクリプト、バックアップファイルに平文の接続文字列やAPIキーが残っていると検出対象になり得ます。検出された場合は、単にファイルを削除するだけでなく、該当するキーやパスワードのローテーションまで実施してください。
ファイル整合性監視はP2有効化だけでは終わらない
ファイル整合性監視（FIM）は、OSファイル、Windowsレジストリ、アプリケーションソフトウェア、Linuxシステムファイルなどの変更を検出し、攻撃の兆候を見つけるための機能です。(Microsoft Learn)
ただし、Defender for Servers Plan 2を有効にしただけで、すべてのFIM運用が完成するわけではありません。監視対象ファイル、Log Analytics ワークスペース、変更イベントの確認方法を設計する必要があります。
| FIMで決めること | 例 |
|---|---|
| 監視対象 | /etc/ssh/sshd_config、重要なアプリ設定ファイル、Windowsレジストリキー |
| 通知条件 | 本番環境の重要ファイル変更、管理者以外の変更、夜間の変更 |
| 連携先 | Defender for Cloud、Microsoft Sentinel、運用チケット |
| 例外 | 正規のデプロイ、パッチ適用、構成管理ツールによる変更 |
FIMでは、Defender for Endpoint エージェントとエージェントレス スキャンで収集したデータを使い、変更ログはLog Analytics ワークスペースに保存されます。Defender for Endpoint経由の変更イベントはほぼリアルタイム、エージェントレス スキャン経由の変更イベントは24時間間隔でストリーミングされます。(Microsoft Learn)
そのため、インシデント対応目的で即時検知を重視するサーバーでは、Defender for Endpoint エージェントの導入状態を必ず確認してください。
展開スコープで失敗しないための設計
Defender for Servers は、基本的にはサブスクリプション単位で有効化することが推奨されます。ただし、特定のサーバーだけ有効化・無効化したい場合は、リソースレベルの設定を使う場面があります。(Microsoft Learn)
| 操作 | P1 | P2 |
| ——————– | -: | -: |
| Azureサブスクリプション単位で有効化 | 可能 | 可能 |
| リソース単位で有効化 | 可能 | 不可 |
| リソース単位で無効化 | 可能 | 可能 |
細かい制御が必要な場合は、タグとAzure Policyを組み合わせるのが現実的です。公式手順では、選択したタグを持つリソースに対してP1を有効化するAzure Policyや、タグに基づいてDefender for Serversを無効化するAzure Policyが紹介されています。(Microsoft Learn)
実務では、次のようなタグ設計を先に決めておくと運用が安定します。
| タグ例 | 用途 |
|---|---|
security-tier=defender-p2 | P2対象の本番サーバーを識別 |
security-tier=defender-p1 | P1対象の検証・業務サーバーを識別 |
defender-exclusion=true | 一時的な除外対象を明示 |
owner=team-name | 推奨事項やアラートの対応責任者を明確化 |
重要なのは、除外タグを無秩序に増やさないことです。除外理由、期限、承認者をチケットや台帳で管理しないと、「保護されていない重要サーバー」が残り続けます。
マルチクラウドとオンプレミス展開の注意点
AWS、GCP、オンプレミス環境では、Azure Arc の状態が機能差に直結します。公式の計画ガイドでは、AWS/GCPとオンプレミスのマシンを Azure Arc VM としてオンボードすると、Defender for Servers のすべての機能を使えるようになると説明されています。(Microsoft Learn)
展開前に、次を確認してください。
| 項目 | 確認内容 |
|---|---|
| Azure Arc | 対象サーバーがAzure Arc対応サーバーとして接続されているか |
| ネットワーク | Azure Arcやクラウドコネクタに必要な送信通信が許可されているか |
| AWS | SSM関連エンドポイント、gbl.his.arc.azure.com などへの通信を確認する |
| GCP | osconfig.googleapis.com、compute.googleapis.com、agentonboarding.defenderforservers.security.azure.com などへの通信を確認する |
| オンプレミス | 直接オンボードではなく、Arc経由で全機能を使える構成にする |
AWS/GCP環境では、ポート443で必要なURLへ到達できることがサポート要件として示されています。(Microsoft Learn)
ネットワーク制限が厳しい環境では、Defender for Servers の有効化そのものよりも、Arcエージェントやコネクタの通信許可に時間がかかります。セキュリティ部門、ネットワーク部門、クラウド運用部門で事前に許可リストを共有しておきましょう。
コストと試用で確認すべきこと
Defender for Servers は、サブスクリプションで有効化すると、マシンの電源状態に基づいて課金対象が変わります。Azure VMでは、実行中や停止済みは課金対象、割り当て解除済みは課金対象外です。Azure Arcマシンでは、Connected Machine エージェントからハートビートを受け取っている接続済み状態が課金対象になります。(Microsoft Learn)
評価時は、次の順で確認すると無駄なコストを抑えやすくなります。
| 手順 | 確認内容 |
|---|---|
| 対象サーバーを棚卸しする | 実行中、停止済み、割り当て解除済み、Arc接続済みを分ける |
| P1/P2の候補を決める | 本番はP2、検証はP1など、用途別に整理する |
| 30日試用の評価項目を決める | 脆弱性検出、アラート、FIM、シークレット検出、運用負荷を測る |
| 有効化後すぐに結果を見る | 推奨事項、アラート、インベントリ、課金対象を確認する |
| 試用終了前に継続判断する | 全面展開、限定展開、除外、プラン変更を決める |
既に Microsoft Defender for Endpoint for Servers のライセンスを持っている場合、Defender for Servers P1またはP2のライセンスの一部について支払い対象外となる場合があります。ただし、割引はサポートリクエストで申請し、承認日以降に有効になるため、後から自動的に遡及適用される前提で計画しない方が安全です。(Microsoft Learn)
管理者・開発者向けチェックリスト
Defender for Servers の更新内容を受けて、まず確認すべき項目をまとめます。
| 役割 | 今すぐ確認すること | 完了の目安 |
|---|---|---|
| クラウド管理者 | 対象サブスクリプション、AWSアカウント、GCPプロジェクトの一覧化 | 保護対象と除外対象が明確になっている |
| セキュリティ管理者 | P1/P2の選定、Defender for Endpoint自動プロビジョニング | 既存EDRとの重複やアラート運用が整理されている |
| インフラ管理者 | Azure Arc、ネットワーク、OSサポート、拡張機能 | AWS/GCP/オンプレミスの接続要件を満たしている |
| SOC担当者 | アラートの確認先、重大度、エスカレーションルール | Defender for CloudとDefenderポータルの役割分担が決まっている |
| 開発者 | 平文シークレット、設定ファイル変更、CI/CDの影響 | 検出時のローテーション手順と変更管理がある |
| コスト管理者 | 課金対象の電源状態、P1/P2の対象範囲、試用終了日 | 試用後の継続判断ができる |
特に開発者は、シークレット スキャンとFIMを「セキュリティ部門だけの機能」と考えないことが重要です。検出される平文キー、古い接続文字列、未管理の設定変更は、アプリケーションの運用リスクに直結します。検出後のキー更新、デプロイ手順の修正、設定ファイルの管理方法まで含めて対応してください。
まとめ：まずは棚卸し、次にP1/P2とArcを確認する
Microsoft Defender for Cloud の Defender for Servers は、Azure、AWS、GCP、オンプレミスのサーバーを横断して保護するための重要な機能です。今回の公式情報で特に重要なのは、Log Analytics エージェントやAMA中心ではなく、Defender for Endpoint統合とエージェントレス スキャンを中心に設計を見直す必要がある点です。
次に取るべき行動は明確です。
- Defender for Servers の対象になるサーバーを棚卸しする
- 本番・検証・開発ごとにP1/P2の方針を決める
- AWS、GCP、オンプレミスはAzure Arcのオンボード状態を確認する
- Defender for Endpointの自動プロビジョニング範囲を確認する
- P2を使う場合は、エージェントレス スキャン、OS構成評価、FIM、Log Analytics ワークスペースの要件を確認する
- 30日試用を始める前に、評価項目と継続判断の基準を決める
まずは小規模な本番相当のサーバー群でP2を評価し、検出結果、運用負荷、コスト、既存監視との重複を確認してから段階展開するのが、失敗しにくい進め方です。
コメント