Azure Defender for Cloudの「Machines should have a vulnerability assessment solution」が消えない原因と対処法(Windows 11 VM/対象外の見分け方)

Azure仮想マシンで「Machines should have a vulnerability assessment solution」が何度修正しても消えない…。その原因は設定ミスではなく、VMのOS種別とDefender for Serversの対象範囲のミスマッチで起きることがあります。本記事では切り分けと現実的な運用対処をまとめます。

目次

症状:Azureの推奨「Machines should have a vulnerability assessment solution」が消えない

Microsoft Defender for Cloud(以下、Defender for Cloud)では、Azure VM に対してセキュリティ推奨(Recommendation)が表示されます。その中でも相談が多いのが、次の推奨が修正(Remediate)を実行しても「未解決のまま」残り続けるパターンです。

  • Machines should have a vulnerability assessment solution(マシンには脆弱性評価ソリューションを導入すべき)

「[修正] ボタンを押した」「エージェントや拡張機能の導入を試した」「Defender for Servers プラン 2 を使っているのに反映されない」──それでも状況が変わらない場合、まず押さえるべきポイントは“そのVMがサーバー扱いできる対象かどうか”です。

結論:クライアントOSのVMでは“直しようがない推奨”として出てしまうことがある

この推奨は本来、Defender for Cloud のDefender for Servers(サーバー向け)の文脈で、脆弱性評価(Vulnerability Assessment)を有効にしてサーバーの既知脆弱性を継続的に検出するためのものです。

ところが現状、Azure上で動くVMでも、OSがWindows 11 / Windows 10などのクライアントOSだった場合、Defender for Servers バンドルの正式対象外であるにもかかわらず、サーバー向け推奨が表示されてしまうことがあります。これが「何をやっても消えない」状態の代表例です。

やろうとしていること起きていることなぜそうなるか(要点)
Defender for Cloud の推奨から脆弱性評価を有効化修正を実行しても推奨が未解決のまま対象VMがクライアントOSで、サーバー向けの自動展開(MDE/VA)が走らない
Defender(MDE)ポータル側で脆弱性は見えるDefender for Cloud 側の「サーバー向け脆弱性評価」に反映されない評価データの集約先がサーバー前提のため、クライアントOSのVMでは紐づかない

「Machines should have a vulnerability assessment solution」とは何を求めているのか

この推奨が求めるのは、対象マシンに対して脆弱性評価ソリューションを導入し、OSやアプリの既知脆弱性(CVEなど)を継続的に棚卸しできる状態にすることです。Defender for Servers プラン 2 の文脈では、Microsoft Defender for Endpoint(MDE)と連携した脆弱性管理(MDVM: Microsoft Defender Vulnerability Management)を使って、次のような運用ができることが期待されています。

  • 脆弱性(CVE)を自動検出し、優先度(深刻度・露出・悪用状況)でトリアージ
  • 修正すべき更新プログラムや設定を可視化
  • サブスクリプション全体/管理グループ全体での是正状況を追跡

つまりこの推奨は、単なる「拡張機能が入っていません」という話ではなく、脆弱性評価の仕組みが“サーバーとして”機能しているかをチェックしている、と捉えると理解しやすくなります。

なぜWindows 11などのVMで起きるのか:対象範囲のミスマッチ

ポイントは、Azure VM であっても OS には大きく2系統あることです。

VMのOS系統例Defender for Cloud(Defender for Servers)の想定起きやすいこと
サーバーOSWindows Server、サーバー用途のLinux対象。Defender for Servers の自動展開・統合が前提通常は推奨を修正できる(※別の阻害要因があると残る)
クライアントOSWindows 11 / Windows 10 など正式対象外になりやすい(サーバー向けの仕組みが前提ではない)推奨が出ても修正できない/消えない

クライアントOS VM では、Defender for Cloud 側の「サーバー向け脆弱性評価」の仕組みが前提どおりに動かないため、Azure ポータルから修正を試してもMDE拡張機能(エージェント)が自動展開されない、または展開できたとしても推奨の評価パイプラインに乗らないことがあります。

結果として、Defender(MDE)ポータルのデバイス一覧では脆弱性が見えているのに、Defender for Cloud の推奨がいつまでも「未解決」のまま、という“二重管理に見える矛盾”が起きます。

この事象はユーザー設定の問題ではなく、プラットフォーム側の不整合で起きる

今回のように「対象外のVMに推奨が出る」状態は、設計上は推奨の適用対象フィルタが適切に効いていない(あるいは対象判定がサーバー前提で実装されている)ことが原因になります。ここが重要で、ユーザー側でどれだけ操作しても次の状態に陥りがちです。

  • 推奨が「解決済み」にならない
  • Azure ポータルの [修正] から有効化できない(押しても変化がない/失敗する)
  • ライセンスやプラン(Defender for Servers プラン 2)が正しくても改善しない

つまり「自分の設定が間違っているのでは?」と悩むより、まずは“そのVMが推奨の前提条件を満たす種類か”を確認したほうが早い、ということです。

最短で切り分ける方法:まずOS種別を確定させる

切り分けはシンプルです。対象VMがサーバーOSかクライアントOSかで、取るべきアクションが変わります。

Azureポータルで確認する

  • VM の「概要」や「OS」の表示で、Windows Server なのか Windows 11 なのかを確認
  • Marketplace イメージの場合は、イメージの Offer / SKU から判断できることが多い

台数が多い場合は Azure Resource Graph で棚卸しする

管理対象が多いと、GUIで1台ずつ確認するのは現実的ではありません。Marketplaceイメージを使っている場合は、Azure Resource Graph でおおよそ判別できます。

Resources
| where type =~ 'microsoft.compute/virtualmachines'
| extend offer = tostring(properties.storageProfile.imageReference.offer)
| extend sku   = tostring(properties.storageProfile.imageReference.sku)
| project name, resourceGroup, location, offer, sku
| where offer has 'windows' and (sku has '11' or sku has '10')

※カスタムイメージや一部のデプロイ方式では offer / sku が空になることがあります。その場合はOSの実体(インベントリ情報)側での判定が必要です。

確認ポイント一覧:どこを見れば「対象外」だと判断できるか

確認項目確認場所(例)見え方判断
OSがクライアントかサーバーかAzure VM の概要 / イメージ情報Windows 11 / Windows 10 などクライアントOSなら本事象の可能性が高い
Defender for Servers プラン 2 の有効化Defender for Cloud のプラン設定サブスクリプション単位で ONONでも消えない場合は対象外判定を疑う
MDE(Defender for Endpoint)へのオンボード状況Defender ポータルのデバイス一覧デバイスが表示される表示されるならMDEとしては管理できている
Defender for Cloud 側の脆弱性結果Defender for Cloud の推奨 / 資産インベントリ結果が出ない、推奨だけ残るサーバー向け評価の連携が噛み合っていない

クライアントOS(Windows 11 / Windows 10)VMでの現実的な運用

クライアントOS VM でこの推奨が消えない場合、重要なのは「推奨を消すこと」よりも、脆弱性管理そのものを止めないことです。Defender for Endpoint(MDE)側で脆弱性管理(MDVM)を回し、サーバーとクライアントで見る場所(KPI)を分けるのが現実解になります。

運用の基本方針

  • クライアントOS VM:Defender(MDE)ポータルで脆弱性・露出・推奨修正を追う
  • サーバーOS VM:Defender for Cloud(Defender for Servers + MDVM)で推奨の是正を追う
目的サーバーOS VMクライアントOS VM
脆弱性(CVE)の一覧と優先度付けDefender for Cloud でも追える(構成次第)Defender(MDE)ポータル中心で追う
Azure上の推奨(Recommendation)を消し込む実施可能(通常は消える)消し込みに固執しない(Not Applicable 化待ち/サポート依頼)
運用上のレポート(経営指標)MDCの推奨是正率MDE/MDVMの露出スコアや修正率

すぐにやるべきチェック(クライアントOS VM)

  1. Defender(MDE)ポータルで該当デバイスがオンボードされているか確認する
  2. 脆弱性管理(MDVM)の画面で、CVEと推奨修正(セキュリティ更新、設定変更、アプリ更新)を確認する
  3. 修正作業は通常の端末運用と同様に、更新管理(WSUS / Intune / 構成管理ツール等)で計画的に実施する

ここまでできていれば、「Azure 側の推奨が消えない」こと自体はノイズであり、セキュリティ実務(脆弱性の是正)は継続できます。

サーバーOS VMでも消えない場合に見るべき“別の原因”

この記事の主題は「クライアントOSが原因で直せないケース」ですが、同じ推奨がサーバーOSで残る場合は、原因が別にあることもあります。次は追加の切り分け観点です。

ありがちな阻害要因症状確認・対処の方向性
自動プロビジョニング(エージェント導入)が無効修正を押しても展開されないDefender for Cloud の設定で自動展開が有効か確認
拡張機能/エージェントの導入失敗VMの拡張機能が失敗状態VMの拡張機能状態、イベント、診断ログを確認
ネットワーク制限(プロキシ/閉域)エージェントがクラウドへ通信できない必要な通信先/ポートが許可されているかを確認
権限不足修正実行が失敗するサブスクリプション/リソースグループのロールを確認

サーバーOSでこの推奨が消えない場合は、上記のような「導入が走っていない」問題の可能性もあるため、クライアントOSのケースと混同しないように注意してください。

Microsoft側の対応:対象外は Not Applicable(該当なし)にする方向

「対象外のVMに推奨が出る」という状態はユーザーの努力で解決しづらいため、最終的にはMicrosoft側でのバックエンド修正が必要になります。想定される落としどころは次のとおりです。

  • 対象外のデバイス(VM)を推奨の適用対象から除外する
  • Defender for Cloud 上ではNot Applicable(該当なし)として扱い、運用ノイズを減らす

この形になれば「直らないアラート」ではなく、「この推奨は当てはまりません」という扱いになるため、現場の混乱が大幅に減ります。

今ユーザー側で取れるアクション

根本修正はプラットフォーム側になるため、ユーザー側でできることは大きく分けて2つです。「セキュリティ実務を回す」ことと、「運用ノイズを減らす」ことを分けて考えるのがポイントです。

セキュリティ実務を回す(脆弱性を放置しない)

  • クライアントOS VM:Defender(MDE)ポータルでMDVMを確認し、脆弱性の修正計画を作る
  • サーバーOS VM:Defender for Servers + MDVM の構成が正しいかを確認し、推奨が正常に消えるかをチェックする

運用ノイズを減らす(サポートに寄せる)

  • すでにサポートチケットがある場合:Microsoft側のバックエンド対応(Not Applicable化など)の進捗を追う
  • まだない場合:同様の事象としてサポートにケースを起票し、再現条件(OS種別、VMの種類、推奨IDなど)を共有する

サポートに渡すと話が早い情報(テンプレ)

サポートに依頼する際、最初のやり取りで情報が揃っていると調査が早く進みます。次の項目を控えておくのがおすすめです。

項目例目的
サブスクリプションIDxxxx-xxxx-xxxx課金プラン/設定スコープの確認
VMのリソースID/subscriptions/…/resourceGroups/…/providers/Microsoft.Compute/virtualMachines/…対象リソースの特定
OS種別とバージョンWindows 11 など対象外判定の裏付け
該当推奨の名称Machines should have a vulnerability assessment solution推奨の種類(サーバー向け)を特定
実施した操作と結果[修正] 実行、変化なし など切り分け(導入失敗か対象外か)
MDEポータル側の状況デバイスが表示される/脆弱性が見えるセンサー稼働有無の確認

よくある疑問:Windows 11のVMにも推奨が出るのはおかしくない?

違和感は正しいです。この推奨は「サーバー向けのベースライン」的な性格が強く、クライアントOSにそのまま適用すると、“直せないのに警告だけ出る”状態が起きます。

VMという形態が同じでも、Defender for Cloud の推奨は内部的に「サーバー前提」で設計されているものがあり、クライアントOSが混ざるとミスマッチが表面化します。したがって、Windows 11 などに推奨が出ているからといって、即「重大なセキュリティ欠陥」ではなく、まず適用対象の判定ミス(または未対応)を疑うのが合理的です。

まとめ:推奨を“消す”より、脆弱性管理を“止めない”ことが優先

「Machines should have a vulnerability assessment solution」が消えないとき、原因がクライアントOS VM(Windows 11 等)の対象外であれば、ユーザー側で完璧に直すのは難しいです。一方で、脆弱性管理そのものはDefender(MDE)ポータル側で継続できます。

  • まずOSがサーバーかクライアントかを切り分ける
  • クライアントOSなら、MDE/MDVMで脆弱性是正を回しつつ、サポート経由でNot Applicable化(対象外扱い)を依頼する
  • サーバーOSなら、導入阻害要因(自動展開、権限、通信、拡張機能)も合わせて確認する

この整理ができると、「直らない推奨」に振り回されず、セキュリティ運用の優先順位を正しく保てます。

この記事を書いた人

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows/Office(Teams・Excel)からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

コメント

コメントする

目次