Microsoft Defender for Cloudの「Kubernetes Nodes Protection」は、AKSクラスターを動かすノードVMに対して、脆弱性評価とマルウェア検出を行う保護機能です。結論から言うと、管理者がまず確認すべきなのは「対象がコンテナではなくKubernetesノードVMであること」「Agentless scanning for machinesが有効か」「検出後にノードイメージ更新やKubernetesアップグレードを実行できる運用になっているか」の3点です。Microsoft Learnの公式情報では、対応するAKSノードに対し、Defender for Cloudが脆弱性の推奨事項とマルウェアのセキュリティアラートを提示すると説明されています。(Microsoft Learn)
Microsoft Defenderのセキュリティ更新、管理者が確認すべき影響範囲と対応ポイント
今回確認すべきポイントは、Microsoft Defender for CloudがKubernetesの「アプリケーション」や「コンテナイメージ」だけでなく、それらを実行するノードVMの状態も可視化することです。
Kubernetes環境では、Podやコンテナイメージの脆弱性に目が向きがちです。しかし、実際のワークロードはノード上で動きます。ノードOS、インストール済みソフトウェア、ノードプールのVMイメージが古いままだと、アプリケーション側で対策していてもリスクが残ります。
公式ドキュメントの変更履歴を見ると、概要ページは2026年4月に構成が整理され、Kubernetesノード保護の対象、保護内容、Agentless scanningとの関係、責任分界がより明確に書き直されています。新しい機能名を覚えるよりも、「Defender for Cloudの推奨事項とアラートを、AKSノード運用にどう組み込むか」を確認することが重要です。(GitHub)
| 確認項目 | 内容 | 現場での意味 |
|---|---|---|
| 対象 | サポート対象のAKSノードVM | コンテナ単体ではなく、ノードプールを構成するVMが対象 |
| 主な保護 | 脆弱性評価、マルウェア検出 | CVE対応とインシデント対応の両方に関係する |
| 方式 | エージェントレスのスナップショットベーススキャン | ノードに追加エージェントを入れる前提ではない |
| 結果の表示先 | Recommendations、Security alerts | セキュリティチームとAKS運用チームの確認導線を分ける必要がある |
| 是正方法 | ノードイメージ更新、Kubernetesアップグレードなど | アプリ改修ではなく、基盤更新が必要になるケースがある |
Kubernetesノード保護とは何か
Kubernetesノード保護は、Microsoft Defender for CloudがAKSノードを構成するVMをスキャンし、既知の脆弱性やマルウェアの兆候を検出する機能です。
公式情報では、Defender for CloudはKubernetesノードを支えるVMに対して次の保護を提供するとされています。脆弱性評価はノードソフトウェア上の既知の脆弱性を特定し、修復に役立つ推奨事項を表示します。マルウェア検出はノードをスキャンし、マルウェアが検出された場合にセキュリティアラートを生成します。(Microsoft Learn)
ここで重要なのは、Kubernetesノード保護が「コンテナイメージのスキャン」とは別の観点であることです。
| 領域 | 主な対象 | 代表的な確認内容 | 主な対応者 |
|---|---|---|---|
| コンテナイメージ | ACRなどのレジストリ内イメージ | ベースイメージ、ライブラリ、言語パッケージの脆弱性 | 開発者、DevSecOps |
| 実行中コンテナ | 実行中のワークロード | 稼働中イメージのリスク、構成不備 | 開発者、SRE |
| Kubernetesノード | AKSノードVM、ノードプール | OSやノードソフトウェアの脆弱性、マルウェア | インフラ管理者、AKS管理者 |
| コントロールプレーン/設定 | Kubernetes設定、RBAC、ポリシー | 構成ミス、権限過多、攻撃経路 | セキュリティ管理者、クラウド管理者 |
開発者が「アプリのコンテナイメージを直したのに、Defenderの推奨事項が消えない」と感じる場合、ノード側の脆弱性が残っている可能性があります。逆に、ノード脆弱性の修復で必要になるのは、アプリのコード修正ではなく、ノードプールのVMイメージ更新やKubernetesバージョン更新であることが多くなります。
対象範囲と利用条件
公式のサポートマトリクスでは、Runtime Node VA、つまりKubernetesノードの脆弱性評価はAKSノードを対象とし、Agentless scanning for machinesが必要です。対応プランとしては、Defender for Containers、Defender for Servers Plan 2、Defender CSPMが挙げられています。(Microsoft Learn)
一方、Kubernetesノードのマルウェア検出はAKSノードを対象とし、こちらもAgentless scanning for machinesが必要です。サポートマトリクスでは、Defender for ContainersまたはDefender for Servers Plan 2が対象プランとして示されています。(Microsoft Learn)
整理すると、管理者は次のように確認すると実務で迷いにくくなります。
| 確認項目 | 脆弱性評価 | マルウェア検出 |
|---|---|---|
| 主な対象 | AKSノードVM | AKSノードVM |
| Agentless scanning for machines | 必要 | 必要 |
| Defender for Containers | 対応 | 対応 |
| Defender for Servers Plan 2 | 対応 | 対応 |
| Defender CSPM | 対応 | 基本的には脆弱性評価側で確認 |
| 主な出力先 | Recommendations | Security alerts、Defender XDR |
なお、サポート対象や提供リージョンは時期によって変わる可能性があります。特に中国リージョンについては、Microsoft Defender for Cloud機能が2026年8月18日にAzure in Chinaで正式に廃止予定である旨がサポートマトリクスに記載されています。該当する環境では、一般的な手順をそのまま適用せず、契約窓口や最新の公式情報で影響を確認してください。(Microsoft Learn)
仕組みはエージェントレスのスナップショットスキャン
Kubernetesノード保護は、ノードプールのディスクをスナップショットベースでスキャンします。Defender for CloudのAgentless machine scanningは、VM上にエージェントをインストールしたり、VMからのネットワーク接続を要求したりせず、VMパフォーマンスにも影響しないと説明されています。(Microsoft Learn)
仕組みとしては、Defender for CloudがVMディスクのスナップショットを取得し、OS構成やファイルシステムをアウトオブバンドで解析します。取得したディスクコピーはVMと同じリージョンに保持され、必要なメタデータ取得後に削除されます。スキャン環境はリージョン内で一時的かつ隔離された環境として説明されています。(Microsoft Learn)
この方式には、運用上のメリットと注意点があります。
| 観点 | メリット | 注意点 |
|---|---|---|
| 導入 | ノードごとにエージェントを配布する必要がない | Agentless scanningの有効化と権限確認は必要 |
| 性能影響 | スキャンがVM性能に影響しにくい | ディスクや暗号化方式がサポート外だと対象外になる可能性がある |
| ネットワーク | VMから外部接続できない環境でも設計しやすい | スキャン結果は即時ではなく、スケジュールに依存する |
| セキュリティ | スナップショットから解析するためノードへの直接操作が少ない | CMK暗号化ディスクではKey Vault権限の確認が必要 |
Agentless scanningは一度有効にすると、個別の機能だけを細かく無効化することはできません。また、スキャンは停止中のVMには実行されず、非構成可能なスケジュールで24時間に1回実行されると説明されています。(Microsoft Learn)
管理者が最初に確認すべき設定
Kubernetesノード保護を利用する前に、Azure管理者またはセキュリティ管理者は次の順番で確認すると効率的です。
| 手順 | 確認内容 | 判断基準 |
| -: | ———————————— | ———————————————————————- |
| 1 | AKSクラスターとノードプールを棚卸しする | 本番、検証、共有基盤、重要システムを分ける |
| 2 | Defender for Cloudの有効プランを確認する | Defender for Containers、Defender for Servers P2、Defender CSPMのどれが有効か確認 |
| 3 | Agentless scanning for machinesを確認する | 対象サブスクリプションまたは環境でOnになっているか確認 |
| 4 | ディスク構成を確認する | サポート外ディスクやエフェメラルOSディスクがないか確認 |
| 5 | Recommendationsを確認する | AKS nodes should have vulnerability findings resolved が出ていないか確認 |
| 6 | Security alertsを確認する | Kubernetesノードに関するマルウェアアラートがないか確認 |
| 7 | ノード更新手順を整備する | メンテナンス時間、Pod退避、ロールバック方針を決める |
Azureポータルでは、Defender for CloudのEnvironment settingsから対象サブスクリプションを選び、該当プランのSettingsでAgentless scanning for machinesを有効化する流れが案内されています。Azure VMのサポート条件として、合計ディスクサイズ、ディスク数、暗号化方式などの制約も記載されています。(Microsoft Learn)
特に注意したいのは、AKS Ephemeral OS Disksがサポート外ディスクとして記載されている点です。パフォーマンスやコストの理由でエフェメラルOSディスクを使っているAKS環境では、Defenderのノードスキャン対象になるかを必ず確認してください。(Microsoft Learn)
脆弱性が検出された場合の対応
Kubernetesノードの脆弱性は、Defender for CloudのRecommendationsから確認します。公式手順では、AzureポータルでMicrosoft Defender for CloudのRecommendationsに移動し、AKS nodes should have vulnerability findings resolved という推奨事項を選択します。その後、影響を受けるノードプールやクラスター、CVEの一覧、CVEごとの詳細情報を確認します。(Microsoft Learn)
修復手順としては、同じ推奨事項からFixを選択し、最新のパッチ済みノードプールVMイメージを適用するためのUpdate image、または新しいKubernetesバージョンへ移行するUpgrade Kubernetesを選択する流れが示されています。(Microsoft Learn)
実務では、すべてのCVEを同じ優先度で処理すると運用が詰まります。次の基準で優先順位を付けると、セキュリティチームとAKS運用チームの合意が取りやすくなります。
| 判断軸 | 優先度を上げる条件 | 対応例 |
|---|---|---|
| 深刻度 | Critical、HighのCVE | 本番ノードプールの更新計画を前倒しする |
| 攻撃可能性 | 外部公開サービスや重要APIを処理するノード | 影響範囲を限定し、早期にノードイメージを更新する |
| 影響範囲 | 複数クラスター、複数ノードプールにまたがる | 共通ノードイメージやAKSバージョンの方針を見直す |
| 業務影響 | 停止できないワークロードが載っている | PodDisruptionBudget、レプリカ数、メンテナンス枠を調整する |
| 修復方法 | Kubernetesアップグレードが必要 | 検証環境で互換性を確認してから本番へ展開する |
ノードイメージ更新は、セキュリティ対応であると同時にインフラ変更です。Podの再スケジュール、DaemonSet、ストレージ、Ingress、オートスケール設定に影響する可能性があります。脆弱性対応を「セキュリティチームだけの作業」にせず、SREやアプリ担当者を巻き込むことが重要です。
マルウェアが検出された場合の対応
Kubernetesノードのマルウェア検出では、Defender for ContainersがMicrosoft Defender Antivirusのマルウェア対策エンジンを使ってKubernetesノード上の悪意あるファイルをスキャンします。マルウェアが検出されると、Defender for CloudとDefender XDRで調査・修復できるセキュリティアラートが生成されます。(Microsoft Learn)
公式手順では、Defender for CloudのSecurity alertsから該当するKubernetesノードのマルウェアアラートを選択し、View full detailsで影響を受けるノードプールやマルウェアファイルを確認します。その後、Next: Take Actionから修復ガイダンスを開き、推奨手順に従います。(Microsoft Learn)
現場では、アラート確認後に次の観点で切り分けます。
| 確認項目 | 見るべきポイント | 次の行動 |
|---|---|---|
| 影響ノード | 単一ノードか、ノードプール全体か | ノードの隔離、退避、再作成方針を判断 |
| 影響ワークロード | どのPod、Namespace、アプリが稼働していたか | アプリログ、監査ログ、イメージ履歴を確認 |
| ファイルパス | ノードOS側か、コンテナ由来のパスか | 侵入経路の仮説を立てる |
| 認証情報 | Secret、環境変数、マウント済み資格情報の露出可能性 | キー、トークン、接続文字列のローテーションを検討 |
| 再発防止 | 不審なイメージ、CI/CD、外部接続の有無 | レジストリ、ビルドパイプライン、ネットワーク制御を見直す |
緊急時にノードを操作する場合は、いきなり削除するのではなく、組織のインシデント対応手順に従って証跡保全の要否を判断してください。可用性を優先する環境では、以下のような操作も検討対象になりますが、本番ではPodDisruptionBudgetや重要Podの配置を確認してから実行する必要があります。
kubectl get nodes
kubectl get pods -A -o wide
kubectl cordon <node-name>
kubectl drain <node-name> --ignore-daemonsets --delete-emptydir-dataこれらはあくまで運用例です。Defenderのアラート内容、組織のフォレンジック方針、AKSの設計によって適切な対応は変わります。
展開・移行時に失敗しやすいポイント
今回の公式情報から、既存環境に対する強制的な移行や廃止が発表されたとは読み取れません。ただし、実務上は「Defenderで検出できる状態にする」「検出後に更新できる状態にする」という2つの移行作業が発生します。
Agentless scanningを有効にしただけで終わらせない
Agentless scanningをOnにしても、サポート外ディスク、停止中VM、対象外リージョン、権限不足があると期待通りにスキャンされません。特にCMKで暗号化されたAzure VMディスクでは、Key Vaultに追加権限が必要になる場合があります。公式情報では、AzureのAgentless scanningで使われる組み込みロールや、CMK暗号化ディスクで必要になるKey Vault関連権限が説明されています。(Microsoft Learn)
ノード更新の影響をアプリチームに共有する
脆弱性修復でUpdate imageやUpgrade Kubernetesを行う場合、ノードの再作成やPodの再配置が発生する可能性があります。アプリチームには、次の項目を事前に確認してもらいましょう。
- レプリカ数が1の重要Podがないか
- Readiness probeとLiveness probeが正しく設定されているか
- PodDisruptionBudgetが現実的な値になっているか
- emptyDirに重要データを置いていないか
- nodeSelector、taints、tolerationsで特定ノードに依存していないか
- メンテナンス時間帯にバッチやリリース作業が重ならないか
セキュリティ修復のためのノード更新であっても、アプリケーション停止が発生すれば障害として扱われます。Defenderの推奨事項を見つけた段階で、運用カレンダーとリリース予定に組み込むことが大切です。
Defender sensorが必要な機能と混同しない
Defender for Containersには、Defender sensorを使うランタイム保護機能もあります。一方、Kubernetesノードの脆弱性評価やマルウェア検出は、Agentless scanning for machinesを前提に説明されています。サポートマトリクスでも、機能ごとに必要な有効化方法が分かれており、Runtime Node VAやKubernetesノードのマルウェア検出ではAgentless scanning for machinesが必要とされています。(Microsoft Learn)
「Defender for Containersを有効化したから全部見えているはず」と判断せず、対象機能ごとの前提条件を確認してください。
開発者が知っておくべき影響
Kubernetesノード保護は、主にインフラ管理者やセキュリティ管理者が扱う領域です。ただし、開発者にも影響があります。
ノード脆弱性の修復では、ノードイメージ更新やKubernetesアップグレードが必要になる場合があります。これにより、Podの再スケジュール、接続断、バッチの中断、ステートフルワークロードの再配置が起こる可能性があります。開発者は「セキュリティチームが勝手に基盤を更新する作業」と捉えるのではなく、自分のアプリがノード入れ替えに耐えられるかを確認する必要があります。
特に次のようなアプリは注意が必要です。
| アプリの状態 | 起こりやすい問題 | 事前対策 |
|---|---|---|
| 単一Podで稼働 | ノード更新時に停止しやすい | レプリカを増やし、ローリング更新に耐える構成にする |
| Graceful shutdown未対応 | 接続中リクエストが失敗する | SIGTERM処理、preStop、terminationGracePeriodSecondsを見直す |
| readiness未設定 | 準備前のPodに通信が流れる | readiness probeを設定する |
| ローカル一時領域依存 | drain時にデータを失う | 永続ボリュームや外部ストレージへ移す |
| 古いKubernetes API依存 | アップグレード時に動かない | 非推奨APIを事前に確認する |
開発者側の実務では、Defenderのノード推奨事項が出たときに「アプリ改修が必要か」「ノード更新だけでよいか」を切り分けることが重要です。ノードOSやノードソフトウェアのCVEであれば、通常はインフラ側の更新が中心です。一方、同時にコンテナイメージやライブラリの脆弱性が出ている場合は、アプリ側の修正も必要になります。
管理者向けチェックリスト
最後に、Microsoft Defender for CloudのKubernetesノード保護について、今日確認すべき項目を整理します。
| チェック | 確認内容 |
|---|---|
| 対象確認 | AKSクラスター、ノードプール、本番/検証の分類を一覧化したか |
| プラン確認 | Defender for Containers、Defender for Servers P2、Defender CSPMの有効状態を確認したか |
| スキャン設定 | Agentless scanning for machinesが対象環境で有効か |
| サポート条件 | ディスクサイズ、ディスク数、暗号化方式、エフェメラルOSディスクの有無を確認したか |
| 推奨事項 | AKS nodes should have vulnerability findings resolved を確認したか |
| アラート | Kubernetesノード関連のマルウェアアラートを確認したか |
| 更新手順 | Update image、Upgrade Kubernetesの検証環境手順を用意したか |
| 影響調整 | アプリチームとメンテナンス時間、Pod退避、ロールバックを調整したか |
| 例外管理 | スキャン対象外のノードやサポート外構成を記録したか |
Microsoft DefenderのKubernetesノード保護は、導入しただけで完結する機能ではありません。価値が出るのは、Defenderの検出結果をノードプール更新、Kubernetesアップグレード、インシデント対応、アプリの可用性設計に接続できたときです。
まずはDefender for Cloudで対象サブスクリプションのプランとAgentless scanning for machinesを確認し、次にRecommendationsとSecurity alertsを見て、実際に対応が必要なノードプールがないか確認してください。検出結果がある場合は、セキュリティ担当、AKS管理者、アプリ開発者で対応範囲を分け、検証環境からノードイメージ更新やKubernetesアップグレードの手順を固めるのが安全です。
コメント