オンプレミスサーバーやAzure以外のVMをMicrosoft Defender for Cloudで監視したい場合、基本方針はAzure ArcでマシンをAzureリソースとして接続し、Defender for ServersとDefender for Endpoint連携を有効にすることです。既にMicrosoft Defender for Endpointを導入済みのサーバーなら、Azure Arcを使わない直接オンボーディングも選択肢になります。ただし、Azure PolicyやGuest ConfigurationなどのAzure管理機能まで使いたい場合は、Azure Arc経由を優先して検討すべきです。Microsoft Learnの「Connect on-premises machines – Microsoft Defender for Cloud」では、Azure Arcによるオンボーディングが推奨手段として整理されています。(Microsoft Learn)
この記事では、2026年5月時点の公式情報をもとに、Microsoft Defender for Cloudへオンプレミスマシンを接続する際の変更点、影響範囲、管理者が確認すべき設定、移行・展開時の注意点を実務目線で整理します。サーバー管理者、セキュリティ担当者、クラウド運用担当者が「どの接続方式を選ぶべきか」「導入前に何を確認すべきか」を判断できる内容です。
Microsoft Defender for Cloudのオンプレミスマシン接続で押さえるべき結論
Microsoft Defender for Cloudでオンプレミス環境を保護する目的は、Azure上のVMだけでなく、社内データセンター、拠点サーバー、Azure VMware Solution、他クラウド上のVMも含めて、セキュリティ態勢と脅威検知を一元管理することです。
公式ドキュメントでは、Azure以外のマシンを接続する方法として、主に次の流れが示されています。
| 接続方式 | 向いているケース | 主なメリット | 注意点 |
|---|---|---|---|
| Azure Arc経由 | オンプレミスサーバーを標準的に管理したい | マシンがAzureリソースとして扱われ、Defender for Cloudのインベントリ、ポリシー、拡張機能と連携しやすい | Azure Arc Connected Machine agentの導入、ネットワーク許可、権限設定が必要 |
| Microsoft Defender for Endpointによる直接オンボーディング | 既にDefender for Endpointをサーバーに展開済み | 追加エージェントなしでDefender for Cloudに表示できる | Azure PolicyやGuest ConfigurationなどのAzure管理機能は使えない |
| AWS/GCPコネクタ | AWS・GCPアカウント単位で接続したい | マルチクラウドコネクタがAzure Arc展開を扱う | クラウドアカウント側の権限、リージョン、ネットワーク要件を確認する必要がある |
実務では、新規にオンプレミスサーバーをDefender for Cloudへ接続するならAzure Arc経由を第一候補にし、既にDefender for Endpointを展開済みで短期間に可視化したい場合は直接オンボーディングを検討する、という判断が分かりやすいです。Azure Arc対応サーバーはAzureリソースとして扱われ、Defender for Serversが有効なサブスクリプションに接続されるとDefender for Cloudに表示されます。(Microsoft Learn)
2026年5月時点で管理者が見るべき変更点
オンプレミスマシン接続の基本はAzure Arcですが、周辺機能の更新により、運用上の確認ポイントが増えています。特に重要なのは、Microsoft Defenderポータルへの統合、直接オンボーディングの扱い、Azure Arcエージェントの更新管理です。
Defender for Cloudのアラート確認先がMicrosoft Defenderポータルに寄っている
Defender for Cloudを有効にすると、Defender for CloudのアラートはMicrosoft Defenderポータルに統合されます。これにより、SOCやセキュリティ運用チームは、クラウド環境のアラート、関連付け、リスクをMicrosoft Defender XDR側で確認しやすくなります。(Microsoft Learn)
さらに、2026年5月のDefender for Cloudリリースノートでは、Microsoft DefenderポータルへのDefender for Cloud統合が一般提供として案内されています。Azure、AWS、GCPを含むハイブリッド・マルチクラウド環境のセキュリティ態勢管理と脅威保護を、単一の体験にまとめる方向性が明確になっています。(Microsoft Learn)
このため、オンプレミスマシン接続後の確認作業は、Azure portalのDefender for Cloudだけで完結させず、Microsoft Defenderポータル側のインシデント、アラート、デバイス情報もあわせて確認する運用に変える必要があります。
直接オンボーディングは便利だが、Azure Arcの代替とは考えすぎない
Microsoft Defender for Endpointによる直接オンボーディングは、オンプレミスサーバーやマルチクラウドVMをDefender for Cloudに表示するための方法です。追加エージェントを必要とせず、既にDefender for Endpointを導入しているサーバーを統合ビューに載せやすい点がメリットです。(Microsoft Learn)
ただし、直接オンボーディングされたサーバーは、Azure PolicyやGuest ConfigurationのようなAzure管理機能には対応しません。Defender for Cloudは選択したサブスクリプションをライセンス、課金、アラート、セキュリティ分析に使いますが、Azure Arc対応サーバーと同じ管理対象になるわけではありません。(Microsoft Learn)
つまり、短期的な可視化には直接オンボーディングが有効ですが、ポリシー適用、構成評価、拡張機能管理、ハイブリッド運用の標準化まで考えるなら、Azure Arc経由を優先するのが現実的です。
Azure Arc Connected Machine agentの更新管理が重要になる
Azure Arc経由でオンプレミスマシンを接続する場合、Azure Connected Machine agentの状態がセキュリティ可視化の土台になります。公式情報では、Azure Connected Machine agentは直近1年以内にリリースされたバージョンのみが正式サポート対象とされ、最新バージョンへの更新または自動アップグレードの利用が推奨されています。(Microsoft Learn)
2026年5月のAzure Connected Machine agent 1.64では、Arc Gatewayのバイパスリスト対応、構成ファイルの信頼性向上、帯域幅削減、Linuxディストリビューションのコンプライアンス報告修正などが含まれています。エージェントは単なる接続部品ではなく、ポリシー、拡張機能、接続状態、セキュリティ評価に関わる重要コンポーネントとして扱うべきです。(Microsoft Learn)
影響範囲はサーバー管理だけでなく、SOC・課金・ネットワークにも及ぶ
Microsoft Defender for Cloudへのオンプレミスマシン接続は、サーバーにエージェントを入れるだけの作業ではありません。影響は複数のチームに広がります。
| 影響を受ける領域 | 確認すべき内容 | 放置した場合のリスク |
|---|---|---|
| サーバー管理 | OS対応、ローカル管理者権限、エージェント導入方式 | 接続失敗、MDEセンサー未展開、インベントリ未表示 |
| セキュリティ運用 | Defender for CloudとDefender XDRのアラート確認先 | アラートを見落とす、インシデント対応が遅れる |
| ネットワーク | Azure Arc、Defender for Endpoint、プロキシ、443番通信 | エージェントが通信できず、状態が不健全になる |
| 課金・契約 | Defender for Servers Plan 1/Plan 2、直接オンボーディングのサブスクリプション | 想定外の課金、必要機能の不足 |
| ガバナンス | Azure Policy、Guest Configuration、タグ、リソースグループ | スコープ管理が曖昧になり、例外管理が難しくなる |
| 開発・運用 | 自社アプリ、ビルドサーバー、除外設定、脆弱性対応 | 過剰な除外、検知漏れ、パッチ優先度の混乱 |
特に注意したいのは、オンプレミスマシンを接続すると、セキュリティデータの見え方や対応フローが変わる点です。Azure portalのインベントリに表示されるだけでなく、Microsoft Defenderポータル側でアラートやインシデントとして扱われるため、監視担当者の運用手順書も更新する必要があります。(Microsoft Learn)
接続前に確認すべき前提条件
オンプレミスマシンをMicrosoft Defender for Cloudへ接続する前に、最低限次の条件を確認します。
Azure側の前提条件
Azure Arcでオンプレミスマシンを接続するには、Azureサブスクリプション、Defender for Cloudの利用設定、対象マシンへのアクセスが必要です。公式手順でも、Azureサブスクリプション、Defender for Cloudのセットアップ、オンプレミスマシンへのアクセスが前提条件として示されています。(Microsoft Learn)
加えて、Azure Arcのクイックスタートでは、対象サブスクリプションに Microsoft.HybridCompute、Microsoft.GuestConfiguration、Microsoft.HybridConnectivity、Microsoft.AzureArcData などのリソースプロバイダー登録、対応OS、必要なAzure組み込みロール、対応リージョン、ファイアウォールやプロキシで必要URLがブロックされていないことが確認事項として挙げられています。(Microsoft Learn)
サーバー側の前提条件
対象サーバーでは、Azure Connected Machine agentをインストール・構成できる権限が必要です。Linuxではroot、WindowsではローカルAdministratorsグループのメンバーであることが求められます。(Microsoft Learn)
また、Azure Arc対応サーバーは、Azure外の物理サーバーや仮想マシンを対象にしています。VMware、Azure VMware Solution、Azure Local、他クラウド環境などは対象になりますが、Azure VM、Azure Stack Hub、Azure Stack Edge上のVMには通常インストールすべきではありません。既に同様の管理機能があるためです。(Microsoft Learn)
ネットワークとプロキシの前提条件
Azure ArcやDefender for Endpointは、クラウドサービスと継続的に通信します。Defender for Serversのサポート情報では、マルチクラウド展開時にAzure Arcで必要なアドレスとポートを開放すること、AWSやGCPコネクタでは各クラウドのAPIやArc関連URLに443番で通信できることが案内されています。(Microsoft Learn)
Defender for Endpointセンサーはシステムコンテキストから通信するため、プロキシで匿名通信を許可する必要がある場合があります。Microsoft Defenderポータルへ支障なくアクセスさせるには、サービスURLへの通信も許可しておく必要があります。(Microsoft Learn)
Defender for ServersのPlan 1とPlan 2はどう選ぶべきか
オンプレミスマシンを接続するだけでは、期待する保護機能がすべて有効になるとは限りません。Defender for Serversのプラン選択が重要です。
| 判断軸 | Plan 1が向いているケース | Plan 2が向いているケース |
|---|---|---|
| 主目的 | EDRと基本的なサーバー保護を始めたい | 脆弱性、構成、コンプライアンス、改ざん監視まで広く見たい |
| 代表的な機能 | Defender for Endpoint連携によるEDR中心 | Plan 1の機能に加え、エージェントレススキャン、コンプライアンス評価、OS構成評価、OS更新評価、File Integrity Monitoring、Just-in-timeアクセスなど |
| 展開単位 | リソース単位で有効化・無効化しやすい | サブスクリプション単位での有効化が基本 |
| 注意点 | 高度な構成評価や一部の追加機能は不足 | リソース単位でPlan 2を有効化することはできず、必要に応じてリソース単位で無効化する |
公式情報では、Plan 1はDefender for Endpoint連携によるEDR機能に重点を置いたエントリープラン、Plan 2はPlan 1の機能に加えて、エージェントレススキャン、コンプライアンス評価、Microsoft Defender Vulnerability Managementのプレミアム機能、OS構成評価、OS更新評価、File Integrity Monitoring、Just-in-timeアクセスなどを提供するプランとして説明されています。(Microsoft Learn)
運用の判断としては、まず重要サーバーやインターネット公開サーバー、認証基盤、業務停止影響が大きいシステムはPlan 2を検討します。一方、短期間でEDRの監視範囲を広げることが目的ならPlan 1から始める選択も現実的です。
ただし、直接オンボーディングを使う場合は注意が必要です。直接オンボーディングではPlan 1相当の機能は利用できますが、Plan 2の機能は制限され、追加で利用できるのは主にプレミアムDefender Vulnerability Management機能に限られます。Plan 2の効果を十分に使いたい場合は、Azure Arc経由での接続を前提に設計するべきです。(Microsoft Learn)
Azure Arc経由でオンプレミスマシンを接続する手順
ここでは、実務で使いやすい流れに整理します。画面名や仕様は変更される可能性があるため、実施前にはMicrosoft Learnの最新手順も確認してください。
対象サーバーを棚卸しする
最初に、接続対象のサーバーを一覧化します。最低限、次の情報を整理します。
| 項目 | 確認内容 |
|---|---|
| サーバー名 | ホスト名、資産管理番号、設置場所 |
| OS | Windows Server、Linuxディストリビューション、バージョン |
| 役割 | AD、DB、Web、ファイルサーバー、業務アプリ、監視サーバーなど |
| 重要度 | 停止影響、外部公開有無、個人情報・機密情報の有無 |
| ネットワーク | インターネット直接通信、プロキシ経由、閉域網、ファイアウォール制御 |
| 既存セキュリティ | Defender for Endpoint導入有無、他社EDR、ウイルス対策、除外設定 |
| 運用責任者 | サーバー管理者、アプリ担当、セキュリティ担当 |
棚卸しをせずに一括展開すると、業務アプリの除外設定、プロキシ制御、古いOS、既存EDRとの競合などでつまずきやすくなります。特にファイルサーバー、DBサーバー、ビルドサーバーは、セキュリティセンサーや除外設定の影響を事前に検証してください。
Defender for Serversを有効化する
Azure portalでMicrosoft Defender for Cloudを開き、Environment settingsから対象サブスクリプション、AWSアカウント、GCPプロジェクトを選択し、Serversプランを有効化します。公式手順では、既定でPlan 2が有効になり、必要に応じてPlan 1へ切り替えられる流れが示されています。(Microsoft Learn)
サブスクリプション全体で有効化するのが管理しやすい一方、段階導入ではリソースグループやタグで対象を分ける設計が重要です。Plan 1はリソース単位で有効化・無効化できますが、Plan 2はリソース単位で有効化できず、リソース単位で無効化する形になります。(Microsoft Learn)
Azure Arc Connected Machine agentを展開する
単一サーバーで検証する場合は、Azure portalからインストールスクリプトを生成し、対象サーバーで実行する方法が分かりやすいです。複数サーバーへ展開する場合は、スクリプト、構成管理ツール、ソフトウェア配布基盤、運用自動化ツールを使って標準化します。
Azure Connected Machine agentは、Azure外のWindows/Linuxマシンを管理するためのエージェントです。HIMDS、Machine Configuration agent、Extension agentなどのコンポーネントを含み、Azureとの接続、ポリシー評価、拡張機能管理を担います。(Microsoft Learn)
展開時は、次の順番で進めると失敗を減らせます。
| ステップ | 作業 | 確認ポイント |
|---|---|---|
| 事前検証 | 代表サーバー1〜3台で検証 | OS、プロキシ、ファイアウォール、権限、接続状態 |
| 小規模展開 | 部門または用途別に数十台へ展開 | Azure Arcリソース作成、Defender for Cloud表示、MDE展開状況 |
| 本番展開 | タグやリソースグループ単位で展開 | 例外管理、障害時の切り戻し、運用手順 |
| 定着運用 | 定期的にエージェントとセンサー状態を確認 | バージョン、ハートビート、アラート、脆弱性、構成推奨事項 |
Defender for Endpoint連携を確認する
Defender for Serversを有効化すると、Defender for Endpoint連携は既定で有効になります。これにより、Defender for Endpointエージェントが対象マシンに自動展開されます。(Microsoft Learn)
ただし、古いサブスクリプションや特定のOSでは、手動での有効化が必要になる場合があります。Windows Server 2012 R2/2016のUnified Solution、Linuxマシンの統合などは、既存サブスクリプションの時期によって手動対応が必要になるケースがあります。(Microsoft Learn)
Linuxでは、次のコマンドでDefender for Endpointセンサーの状態を確認できます。
mdatp health期待する状態の例は次の通りです。
healthy : true
licensed: trueAzure portal側では、Linuxマシンに MDE.Linux 拡張機能が表示されることも確認ポイントになります。(Microsoft Learn)
インベントリで接続状態を確認する
オンプレミスマシンが接続されたら、Azure portalでMicrosoft Defender for Cloudを開き、Inventoryから資産インベントリを確認します。公式手順では、Azure VM、Azure以外のマシン、Azure Arc対応サーバーをフィルターして表示できる流れが示されています。(Microsoft Learn)
接続確認では、単に「表示されたか」だけでなく、次の状態を見ます。
| 確認項目 | 見るべきポイント |
|---|---|
| リソース種別 | Azure Arc-enabled serverとして表示されているか |
| サブスクリプション | 想定したサブスクリプションに紐づいているか |
| リソースグループ | 命名規則や管理単位に沿っているか |
| タグ | 部門、環境、本番/検証、管理者、重要度などが付与されているか |
| Defender for Servers | Plan 1/Plan 2が意図通りか |
| Defender for Endpoint | センサーが正常に展開・通信しているか |
| 推奨事項 | 重大度の高い推奨事項が出ていないか |
直接オンボーディングを使う場合の判断基準
Defender for Endpointによる直接オンボーディングは、すでにDefender for Endpointを導入済みのサーバーをDefender for Cloudに統合したい場合に便利です。直接オンボーディングを有効にすると、同じMicrosoft Entraテナント内でDefender for Endpointにオンボード済みの既存・新規サーバーが、選択したサブスクリプション配下に表示されます。(Microsoft Learn)
直接オンボーディングが向いているケース
直接オンボーディングは、次のような状況で有効です。
| 状況 | 理由 |
|---|---|
| 既にDefender for Endpointを全社サーバーへ展開済み | 追加エージェントなしでDefender for Cloud側へ可視化しやすい |
| まずアラート、脆弱性、インベントリを統合したい | 短期間でセキュリティ運用の可視性を高められる |
| Azure Arcの展開設計に時間がかかる | 暫定的な可視化手段として使える |
| Azure管理機能よりEDR中心で見たい | Plan 1中心の運用に合いやすい |
直接オンボーディングは、Defender for Servers Plan 1とPlan 2の両方で使えますが、Plan 2では制限があります。Plan 2を有効にしても、直接オンボーディングされたサーバーではPlan 1機能とDefender Vulnerability Managementの一部機能が中心になるため、フル機能を期待する場合はAzure Arc経由を検討してください。(Microsoft Learn)
有効化時に確認すべき権限と反映時間
直接オンボーディングを有効にするには、選択するサブスクリプションのSubscription Owner権限と、Microsoft EntraのSecurity Administrator以上の権限が必要です。設定後、対象サーバーが選択したサブスクリプションに表示されるまで、最大24時間かかる場合があります。(Microsoft Learn)
急いでいる場合でも、設定直後に見えないだけで失敗と判断しないことが重要です。24時間を過ぎても表示されない場合は、テナント、サブスクリプション、Defender for Endpointオンボーディング状態、OSサポート、プロキシ通信を確認してください。
二重オンボーディングと課金に注意する
Azure Arc経由と直接オンボーディングを同時に使う環境では、古いDefender for Endpointエージェントのバージョンによっては、まれに重複課金につながる可能性があると公式ドキュメントで注意されています。(Microsoft Learn)
2026年5月時点の公式記載では、同時オンボーディング時の相関処理には最低エージェントバージョンの条件が示されています。導入前には、Windows Server 2019以降、Windows Server 2016/2012 R2のUnified Solution、Linux AMD64、Linux ARM64それぞれについて、公式のCurrent limitationsにある最低バージョン以上であることを確認してください。バージョン表は変更される可能性があるため、展開直前に最新のMicrosoft Learnで再確認するのが安全です。(Microsoft Learn)
管理者が必ず確認すべき設定チェックリスト
本番展開前後に、次のチェックリストを使って確認します。
| 分類 | チェック項目 | 判断基準 |
|---|---|---|
| サブスクリプション | Defender for Cloudが有効か | 対象サブスクリプションでDefender for Cloudを利用できる |
| Defender for Servers | Plan 1/Plan 2が意図通りか | 重要サーバーに必要な機能が有効 |
| Azure Arc | 対象マシンがArc-enabled serverとして表示されるか | Inventoryに想定どおり表示される |
| MDE連携 | Endpoint protectionがOnか | MDE.WindowsまたはMDE.Linuxが展開され、正常通信している |
| ネットワーク | 必要URL・ポートが許可されているか | プロキシ、FW、SSL inspectionで通信が阻害されない |
| 権限 | 展開担当者に必要権限があるか | Azure側、サーバー側の権限不足がない |
| タグ | 管理用タグが付与されているか | 部門、環境、重要度、所有者で絞り込める |
| アラート | Defenderポータルで確認できるか | SOCの監視手順に組み込まれている |
| エージェント更新 | Arc agentとMDEが最新方針に沿っているか | 直近1年以内のArc agent、MDEの自動更新または運用更新がある |
| 例外設定 | 除外が過剰でないか | 業務影響を避けつつ、検知漏れを増やしすぎない |
Windows Serverでは、Azure Connected Machine Agentの更新をMicrosoft Update、Microsoft Update Catalog、Microsoft Download Centerから取得できます。既存のWSUSやMicrosoft Configuration Managerを使う場合は、Azure Connected Machine Agentの製品と分類を同期し、通常のOS更新運用に組み込むと管理しやすくなります。(Microsoft Learn)
Linuxでは、Microsoftのパッケージリポジトリから更新します。Defender for Endpoint for Linuxについては、MDE.Linux拡張機能を使う場合、自動更新が既定で有効です。手動更新にしたい場合は、対象マシンのタグで制御できます。(Microsoft Learn)
移行・展開で失敗しやすいポイント
Inventoryに表示されない
オンプレミスマシンがInventoryに表示されない場合、原因は大きく4つあります。
| 原因 | 確認方法 |
|---|---|
| Azure Arc接続が完了していない | Arc-enabled serverとしてAzure portalに表示されるか確認 |
| サブスクリプションが違う | 接続時に指定したサブスクリプション、リソースグループを確認 |
| ネットワークが遮断されている | プロキシ、FW、必要URL、443番通信を確認 |
| 反映待ち | 直接オンボーディングでは最大24時間待つ |
特に直接オンボーディングでは、サーバーが表示されるまで最大24時間かかる場合があります。設定直後の確認だけで失敗と判断せず、時間を置いた再確認を運用手順に含めてください。(Microsoft Learn)
Defender for Endpointが正常に動いていない
Defender for Endpoint連携は既定で有効になりますが、古いサブスクリプション、Windows Server 2012 R2/2016、Linux環境では追加対応が必要になることがあります。LinuxではPythonが必要で、RHEL 8.xやUbuntu 20.04以降ではPython 3が求められます。また、fanotifyを使うサービスが動いているLinuxマシンでは、自動展開が期待どおりに動かない場合があり、手動インストールが必要になることがあります。(Microsoft Learn)
「Defender for Serversを有効にしたのにセンサーが入らない」という場合は、まずEndpoint protectionの状態、対象OSの対応状況、プロキシ、既存セキュリティ製品、拡張機能の展開状態を確認してください。
Plan 2の機能が期待通りに使えない
Plan 2を契約していても、直接オンボーディングのサーバーでは利用できる機能に制限があります。エージェントレススキャン、構成評価、File Integrity Monitoringなどを広く使いたい場合、Azure Arc経由での接続が前提になるケースが多くなります。(Microsoft Learn)
「Plan 2を有効にしたのに推奨事項が少ない」「構成評価が出ない」といった場合は、プランだけでなく、接続方式も確認してください。
Azure VMにAzure Arcを入れてしまう
Azure Arc対応サーバーは、Azure外の物理サーバーや仮想マシンをAzureに接続するための仕組みです。Azure VM、Azure Stack Hub、Azure Stack Edge上のVMには通常インストールしないでください。テスト目的でAzure VMをオンプレミス環境の代替として使うことはありますが、本番管理の設計では混同しないことが重要です。(Microsoft Learn)
エージェント更新を後回しにする
Azure Connected Machine agentのバージョンが古いと、サポート対象外、接続不良、ポリシー評価の不整合、既知不具合の影響を受ける可能性があります。公式情報では、直近1年以内のバージョンのみが正式サポート対象とされています。(Microsoft Learn)
オンプレミスサーバーはクラウドVMよりも更新サイクルが遅くなりがちです。Arc agentとMDEセンサーの更新を、月次パッチ、構成管理、変更管理プロセスに必ず組み込みましょう。
開発者・アプリ担当者が確認すべきポイント
Microsoft Defender for Cloudへの接続は主にインフラ・セキュリティ領域の作業ですが、開発者やアプリ運用担当者にも影響があります。
まず、ビルドサーバー、CI/CDランナー、アプリケーションサーバー、DBサーバーでは、Defender for Endpointの検知やスキャンがプロセス、ファイルI/O、ネットワーク通信を可視化します。業務影響を避けるために除外設定を入れる場合でも、フォルダー単位で広く除外するのではなく、対象プロセス、パス、拡張子、業務要件を確認して最小限にすることが重要です。
次に、Defender for Cloudの推奨事項や脆弱性情報は、開発チームのパッチ優先度にも影響します。単にCVSSが高い順ではなく、インターネット公開、認証情報へのアクセス、横展開リスク、本番影響を合わせて判断すると、対応の優先順位が現実的になります。
また、アラートがMicrosoft Defenderポータルに統合されると、サーバー上の不審なプロセス、Webシェル疑い、認証攻撃、マルウェア検知などがインシデントとして扱われます。アプリ担当者は、SOCから問い合わせを受けたときに、通常運用のプロセス名、デプロイ時間、バッチ処理、管理ツールの通信先を説明できるようにしておくと、誤検知と真の攻撃を切り分けやすくなります。
本番展開のおすすめ順序
いきなり全社サーバーへ展開するのではなく、次の順序で進めると安全です。
| フェーズ | 対象 | 目的 | 成功条件 |
|---|---|---|---|
| 検証 | 代表的なWindows/Linux各1〜3台 | 接続方式、通信、権限、MDE展開を確認 | Inventory表示、MDE正常、アラート確認先の把握 |
| パイロット | 重要度が中程度の部門サーバー | 運用手順と例外設定を固める | 監視手順、問い合わせフロー、タグ設計が機能する |
| 重要サーバー展開 | 本番Web、DB、認証、ファイルサーバー | 高リスク資産を保護する | Plan 2の必要機能、脆弱性対応、アラート運用が回る |
| 全体展開 | 残りのオンプレミス・拠点サーバー | 可視化範囲を広げる | 未接続サーバー、異常エージェント、未対応推奨事項を継続管理できる |
検証フェーズでは、通信許可と権限だけでなく、アラートがどこに出るかを必ず確認してください。Defender for Cloud、Microsoft Defenderポータル、既存SIEM、チケットシステムのどこで運用するかが曖昧だと、導入後にアラートが増えても対応品質が上がりません。
接続後に継続的に見るべき運用指標
オンプレミスマシンを接続した後は、次の指標を定期的に確認します。
| 指標 | 見る理由 |
|---|---|
| Azure Arc接続状態 | 切断されたサーバーはポリシーや拡張機能が正しく反映されない |
| MDEセンサー正常性 | EDR検知、脆弱性、ソフトウェアインベントリに影響する |
| 未解決の高リスク推奨事項 | 構成不備や脆弱性の放置を防ぐ |
| インターネット公開資産 | 攻撃対象になりやすいサーバーを優先対応する |
| OS・ミドルウェアの脆弱性 | パッチ適用計画に反映する |
| エージェントバージョン | サポート対象外や既知不具合を避ける |
| タグ未設定リソース | 所有者不明の資産をなくす |
| アラート対応時間 | SOC運用の実効性を測る |
Defender for Serversでは、Defender for Endpointエージェントのインストール問題やハートビート問題など、ヘルス状態の可視化も提供されています。ヘルス状態は定期的に更新され、問題がある場合はエラー内容や修正手順を確認できます。(Microsoft Learn)
まず管理者が取るべきアクション
Microsoft Defender for Cloudにオンプレミスマシンを接続する際は、Azure Arcを基本に、既存のDefender for Endpoint導入状況に応じて直接オンボーディングも検討します。重要なのは、接続方式、Defender for Serversのプラン、MDE連携、ネットワーク、エージェント更新、アラート運用をセットで設計することです。
まずは、次の順番で着手してください。
- オンプレミスサーバーを棚卸しし、OS、役割、重要度、既存EDR、ネットワーク条件を整理する。
- Defender for ServersのPlan 1/Plan 2を、必要機能とコスト管理の観点で決める。
- 標準方式をAzure Arc経由にするか、既存MDE環境では直接オンボーディングを併用するか判断する。
- 代表サーバーでAzure Arc接続、MDE展開、Inventory表示、Microsoft Defenderポータルでのアラート確認を検証する。
- タグ、リソースグループ、例外設定、エージェント更新、SOC対応手順を整えてから段階展開する。
オンプレミス環境の保護は、接続して終わりではありません。Microsoft Defender for Cloudで見えるようになった資産、脆弱性、構成不備、アラートを、日々のパッチ管理とインシデント対応に結びつけることで、初めて実効性のあるセキュリティ運用になります。
コメント