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)の想定 | 起きやすいこと |
|---|---|---|---|
| サーバーOS | Windows Server、サーバー用途のLinux | 対象。Defender for Servers の自動展開・統合が前提 | 通常は推奨を修正できる(※別の阻害要因があると残る) |
| クライアントOS | Windows 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 のプラン設定 | サブスクリプション単位で ON | ONでも消えない場合は対象外判定を疑う |
| 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)
- Defender(MDE)ポータルで該当デバイスがオンボードされているか確認する
- 脆弱性管理(MDVM)の画面で、CVEと推奨修正(セキュリティ更新、設定変更、アプリ更新)を確認する
- 修正作業は通常の端末運用と同様に、更新管理(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など)を共有する
サポートに渡すと話が早い情報(テンプレ)
サポートに依頼する際、最初のやり取りで情報が揃っていると調査が早く進みます。次の項目を控えておくのがおすすめです。
| 項目 | 例 | 目的 |
|---|---|---|
| サブスクリプションID | xxxx-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なら、導入阻害要因(自動展開、権限、通信、拡張機能)も合わせて確認する
この整理ができると、「直らない推奨」に振り回されず、セキュリティ運用の優先順位を正しく保てます。

コメント