Microsoft Defender for Containersは、Kubernetesクラスター、ノード、ワークロード、レジストリ、コンテナーイメージをまとめて保護するためのMicrosoft Defender for Cloudのコンテナー向けセキュリティ機能です。今回確認すべきポイントは、単なる「概要ページの更新」ではなく、エージェントレス脆弱性評価、ランタイム保護、サプライチェーン保護、ゲート付きデプロイ、Microsoft管理コンテナーイメージの運用が管理者・開発者の実務にどう影響するかです。Microsoft Learnの該当ページは2026年5月6日更新と表示されており、2026年5月7日前後の更新情報として扱う場合も、実運用では公式ページの最終更新日とあわせて確認してください。(Microsoft Learn)
とくにAKS、EKS、GKE、Azure Arc対応Kubernetesを使っている組織では、Defender for Containersを「有効にしたか」だけでは不十分です。どのコンポーネントを有効化しているか、どのレジストリがスキャン対象か、センサーが未展開のクラスターがないか、CI/CDで危険なイメージを止められるかまで確認する必要があります。
Microsoft Defender for Containersとは
Microsoft Defender for Containersは、Microsoft Defender for Cloudに含まれるクラウドネイティブなコンテナー保護ソリューションです。対象はKubernetesクラスターだけではありません。ノード、ワークロード、コンテナーレジストリ、イメージなど、コンテナー運用に関わる複数の資産を横断して保護します。対応範囲はAzureだけに限定されず、マルチクラウド環境やオンプレミス環境にも広がっています。(Microsoft Learn)
実務上は、次のような悩みをまとめて扱うための機能と考えると分かりやすいです。
- AKSやEKS、GKEに脆弱なコンテナーイメージが展開されていないか確認したい
- Kubernetesの設定ミスや過剰な権限を継続的に検出したい
- 実行中のコンテナーで不審なプロセスやDNS通信を検知したい
- CI/CDの段階で危険なイメージを止めたい
- Microsoft Defender XDRやDefender for Cloudの推奨事項と連携して調査したい
従来のコンテナーセキュリティは、イメージスキャン、Kubernetes設定監査、ランタイム検知、CI/CDチェックが別々のツールに分かれがちでした。Defender for Containersは、これらをMicrosoft Defender for Cloudの画面や推奨事項、セキュリティグラフ、XDR連携に寄せて管理できる点が特徴です。
今回の更新で押さえるべき変更点
今回の公式情報では、Defender for Containersの役割がより明確に整理されています。大きく見ると、管理者が見るべき「クラウド・Kubernetes・レジストリ・実行時」の保護と、開発者が見るべき「ビルド・CI/CD・デプロイ前チェック」の両方が強調されています。
| 確認ポイント | 内容 | 実務上の影響 |
|---|---|---|
| セキュリティ体制管理 | クラウドAPI、Kubernetes API、ワークロードを継続監視 | 設定ミスや危険な構成を推奨事項として確認しやすくなる |
| 脆弱性評価 | レジストリイメージ、実行中コンテナー、対応ノードをエージェントレスで評価 | センサー導入前提ではなく、対象設定の有無が重要になる |
| ランタイム脅威保護 | クラスター、ノード、ワークロードの不審な挙動を検出 | 侵害後の早期検知やXDR調査に関わる |
| サプライチェーン保護 | Defender for Cloud CLIやゲート付きデプロイと連携 | 開発・CI/CD段階で危険なイメージを止める運用が必要になる |
| デプロイと監視 | センサー不足や未保護リソースの可視化 | 「一部のクラスターだけ未保護」を防ぐ棚卸しが重要になる |
注目したいのは、Defender for Containersが単なる「コンテナーの脆弱性スキャナー」ではない点です。公式ページでは、セキュリティ体制管理、脆弱性評価、ランタイム保護、ソフトウェアサプライチェーン保護、デプロイと監視という5つの領域が整理されています。(Microsoft Learn)
影響範囲はAKSだけではない
Defender for Containersの影響範囲は、Azure Kubernetes Service（AKS）だけではありません。Microsoftのデプロイ概要では、AKSはAzureネイティブ統合、EKSとGKEはマルチクラウドコネクタやAzure Arc対応Kubernetes、環境別コンポーネントを使う構成として整理されています。(Microsoft Learn)
| 環境 | 主な連携方法 | 管理者が見るべき点 |
|---|---|---|
| AKS | Azureネイティブ統合 | サブスクリプションでContainersプランが有効か、Defender sensorやAzure Policyが必要に応じて有効か |
| Amazon EKS | AWSコネクタ、Azure Arc、センサー | AWS側の権限、CloudFormation更新、監査ログ連携、ECRスキャン対象 |
| Google GKE | GCPコネクタ、Azure Arc、センサー | GCP側のオンボーディングスクリプト、Artifact Registry/GCR連携、APIアクセス |
| オンプレミス・その他Kubernetes | Azure Arc対応Kubernetes | Arc接続、拡張機能、アウトバウンド通信、ポリシー適用範囲 |
特に見落としやすいのは、EKS、GKE、オンプレミスKubernetesではAzure Arcやクラウドコネクタが保護の前提になるケースがあることです。AKSだけを見て「Defender for Containersは有効」と判断すると、マルチクラウド側のクラスターが未保護のまま残る可能性があります。
管理者が最初に確認すべき設定
管理者は、まずMicrosoft Defender for CloudのEnvironment settingsで、対象サブスクリプションまたはクラウドコネクタのContainersプランが有効になっているか確認します。そのうえで、必要なコンポーネントが有効かを見る必要があります。AKSでは、Agentless scanning for machines、Defender sensor、Azure Policy、Kubernetes API access、Registry accessなどの設定項目が用意されています。(Microsoft Learn)
確認すべき設定チェックリスト
| 設定 | 確認内容 | 無効のままだと起きること |
|---|---|---|
| Containersプラン | 対象サブスクリプション、AWS/GCPコネクタ、Arcリソースで有効か | そもそも保護・推奨事項・アラートが出ない |
| Registry access | ACR、ECR、GAR/GCRなどのレジストリスキャンが有効か | コンテナーイメージの脆弱性評価が不足する |
| Kubernetes API access | インベントリ、構成分析、Kubernetesメタデータ利用が可能か | クラスター状態に基づく分析が弱くなる |
| Defender sensor | ランタイムテレメトリ収集が必要なクラスターに展開済みか | ワークロードやノードのランタイム検知が不足する |
| Azure Policy | Kubernetesの構成評価や推奨事項に使うか | 設定ミスの継続評価が不足する |
| Agentless scanning for machines | ノードや実行中コンテナーの評価に必要か | エージェントレスの脆弱性・シークレット検出が使えない |
ここで重要なのは、すべてを機械的にオンにすることではありません。たとえば本番クラスターではランタイム保護とゲート付きデプロイを重視し、開発環境ではまず監査モードで影響を把握するなど、環境ごとに段階的に有効化する判断が必要です。
脆弱性評価で確認すべきこと
Defender for Containersの脆弱性評価は、レジストリ内のイメージだけでなく、対応環境では実行中コンテナーやKubernetesノードにも広がっています。公式情報では、ACR、Amazon ECR、Google Artifact Registry、Google Container Registry、対応する外部イメージレジストリがスキャン対象として説明されています。AKS環境では、実行中のすべてのコンテナーを毎日スキャンする機能がパブリックプレビューとして案内されています。(Microsoft Learn)
脆弱性評価で管理者が確認すべき観点は、次の3つです。
スキャン対象のレジストリが実態と一致しているか
本番環境で使っているイメージがACRだけとは限りません。ECR、Artifact Registry、GCR、外部レジストリ、移行途中の古いレジストリが残っていることがあります。Registry accessを有効にしていても、実際に使われているレジストリが接続対象外なら、脆弱性評価は抜けます。
確認時は、KubernetesのDeploymentやHelm values、GitOpsリポジトリを見て、実際に参照しているイメージのFQDNを棚卸ししてください。
実行中コンテナーの評価条件を満たしているか
公式情報では、実行中コンテナーイメージの脆弱性評価は、Agentless scanning for machinesに加えて、K8S API accessまたはDefender sensorが有効な場合に実行されると説明されています。レジストリ由来に依存しない評価もあるため、「レジストリスキャンだけで十分」と判断しないことが大切です。(Microsoft Learn)
特に、次のような環境では実行中コンテナーの評価が重要です。
- 古いタグのイメージが長期間動き続けている
latestタグや動的タグを使っていて、ビルド時点の証跡が追いにくい- 外部レジストリや一時的なミラーからイメージを取得している
- 開発チームごとにレジストリ運用が分かれている
サポート対象外のイメージを把握しているか
コンテナー脆弱性評価には、サポート対象と対象外があります。Microsoftのサポートマトリックスでは、Docker V2形式やOCI形式のイメージがサポートされる一方、scratchのような極小イメージ、公開リポジトリ、Manifest listsなどはサポート外として示されています。(Microsoft Learn)
軽量イメージを使うこと自体は悪いことではありません。ただし、スキャンできないイメージを本番で使う場合は、別の検証手段やベースイメージ管理、SBOM、署名検証などを組み合わせる必要があります。
ランタイム保護で確認すべきこと
ランタイム保護は、Kubernetesクラスター、ノード、ワークロードで発生する不審な挙動を検出する領域です。Defender for Containersでは、Defender sensorを使うセンサーベースの検知と、Kubernetes監査ログの分析に基づくエージェントレスの検知が使われます。なお、セキュリティアラートはDefender for Containersを有効にした後に発生したアクションやデプロイに対してトリガーされます。(Microsoft Learn)
実務で確認すべきイベント例は、次のとおりです。
- 公開されたKubernetesダッシュボード
- 高権限ロールの作成
- 機密性の高いマウントの作成
- 不審なDNS通信
- コンテナー内でイメージに含まれない外部プロセスが実行されるバイナリドリフト
- マルウェア検出
特にバイナリドリフトは、コンテナー運用では重要です。コンテナーイメージは本来イミュータブルに扱うべきですが、実行中に外部から持ち込まれたバイナリが起動する場合、攻撃や不正操作の兆候になることがあります。Microsoftの説明では、Binary drift detectionはイメージ由来ではない実行ファイルを検出し、Binary drift blockingは承認されていない外部プロセスの実行をブロックします。(Microsoft Learn)
ただし、いきなりブロックを有効にすると、運用上必要な一時処理やデバッグ手順まで止める可能性があります。最初は検知・監査でアラート傾向を確認し、namespace、pod label、image nameなどで除外や許可リストを調整してからブロックへ進むのが現実的です。
サプライチェーン保護は開発チームも対象になる
今回の内容で開発者にとって重要なのは、Defender for Containersが「運用中のクラスターを守る機能」だけではなく、ビルドからデプロイまでのサプライチェーン保護にも関わる点です。公式ページでは、Microsoft Defender for Cloud CLIにより、GitHub ActionsやAzure PipelinesなどのCI/CD、またはローカル開発環境でコンテナーイメージをスキャンできると説明されています。(Microsoft Learn)
Defender for Cloud CLIは、開発者向けのコマンドラインツールとして、CI/CDパイプラインやローカル端末でセキュリティスキャンを実行し、その結果をDefender for Cloudへアップロードできます。公式情報では、GitHub Actions、Azure DevOps、Jenkins、Bitbucketなどのパイプラインで使えることも説明されています。(Microsoft Learn)
開発チームで導入する場合は、次の順番が実務的です。
| ステップ | やること | 判断基準 |
|---|---|---|
| ローカル検証 | 開発者が主要イメージをスキャンする | 誤検知や修復負荷を把握する |
| CIで監査 | パイプライン上で結果を出すが、ビルドは止めない | 影響範囲と頻出CVEを把握する |
| 重要度で制御 | CriticalやHighなど条件を絞って制御する | 修復可能なルールから始める |
| デプロイ制御 | ゲート付きデプロイで危険なイメージを止める | 本番・重要namespaceから段階導入する |
セキュリティ部門だけでルールを作ると、開発現場では「急にデプロイが止まった」と受け止められます。導入時は、どの重要度のCVEで止めるのか、例外申請は誰が承認するのか、修復期限をどう設定するのかまで決めておく必要があります。
ゲート付きデプロイの導入は監査モードから始める
ゲート付きデプロイは、KubernetesのAdmission Controllerと連携し、組織のセキュリティ要件を満たさないコンテナーイメージをクラスターに入れないための仕組みです。公式情報では、AKS、EKS、GKEがサポート対象として示され、ACR、ECR、Google Artifact Registryなどの対応レジストリの脆弱性スキャン結果を使って評価すると説明されています。(Microsoft Learn)
運用で大切なのは、最初からDenyで止めないことです。Microsoftの説明でも、Auditモードで影響を評価してからDenyモードへ移行する流れが示されています。(Microsoft Learn)
よくある失敗パターン
| 失敗例 | 起きる問題 | 対策 |
|---|---|---|
| 本番でいきなりDenyにする | 緊急リリースや既存ワークロード更新が止まる | Auditで2〜4週間程度の傾向を見てから段階適用する |
| 例外ルールを用意しない | 修復に時間がかかる脆弱性で開発が停止する | 期限付き・スコープ限定の例外を定義する |
| namespace単位の違いを無視する | 開発・検証・本番で同じ制御になり過ぎる | namespace、cluster、image単位でルールを分ける |
| スキャン対象外イメージを考慮しない | ゲート評価できないイメージが残る | 対象外イメージの代替検証手段を用意する |
| 開発者へのメッセージを整備しない | なぜ止まったか分からず問い合わせが増える | CIログ、Admissionイベント、修復手順をセットで案内する |
ゲート付きデプロイは、セキュリティ強化として有効ですが、運用設計なしに有効化するとリリース障害に見えてしまいます。まずは「どの条件なら止める価値があるか」を決めることが重要です。
Microsoft管理コンテナーイメージの扱いに注意する
Defender for Containersは、ランタイム保護コンポーネントとしてMicrosoftが管理・更新するコンテナーイメージをデプロイします。これらのイメージはMicrosoft Container Registry（MCR）に公開され、顧客が直接変更したりパッチを当てたりするものではありません。MicrosoftがDefender for Containersのリリースプロセスの中で維持・更新します。(Microsoft Learn)
公式ページでは、たとえば次のようなコンポーネントが示されています。
| イメージ | 役割 |
|---|---|
security-publisher | Kubernetes環境から収集したセキュリティ結果を発行 |
low-level-collector | Kubernetesノードの低レベルランタイムテレメトリを収集 |
pod-collector | 脅威検出に使うPodランタイムデータを収集 |
anti-malware-collector | コンテナーワークロードのマルウェア検出シグナルを収集 |
audit-logs-enabler | 対応環境の監査ログ収集を有効化 |
defender-admission-controller | Kubernetesワークロードにゲーティングポリシーを適用 |
ここで管理者が注意すべきなのは、社内のコンテナーイメージ脆弱性管理ルールとMicrosoft管理イメージを混同しないことです。自社アプリのイメージであればDockerfile修正やベースイメージ更新で対応しますが、Defender for ContainersのMicrosoft管理イメージは直接修正しません。脆弱性を検出した場合は、イメージ名、タグ、CVE識別子を含めてAzureサポート要求を開く流れが示されています。(Microsoft Learn)
また、更新の配信経路も環境によって異なります。AKSアドオンを使う場合はAKSのリリースライフサイクルを通じて更新され、Helmを使う場合は更新されたチャートバージョンを通じて配信されると説明されています。(Microsoft Learn)
展開前に確認すべきネットワークと権限
Defender for Containersの展開でつまずきやすいのは、機能そのものよりもネットワークと権限です。Azure CLIでDefender sensorやAzure Policyを展開する公式手順では、Azure CLI 2.40.0以降、適切なRBAC権限、対応クラスター、OIDC issuerなどの前提条件が示されています。(Microsoft Learn)
特に閉域構成や制限付きegressのクラスターでは、Defender sensorがMicrosoft Defender for Cloudへセキュリティデータやイベントを送信できるように、必要なアウトバウンド通信を許可する必要があります。AKSの制限付きegress環境では、必要なFQDNを許可するよう案内されています。(Microsoft Learn)
EKSやGKE、Arc対応Kubernetesでは、Azure Arc拡張機能としてセンサーやAzure Policyを展開するケースがあります。AWSやGCP側のコネクタを更新した場合、必要な権限を反映するためにCloudFormationテンプレートやオンボーディングスクリプトの再生成・再デプロイが必要になることがあります。(Microsoft Learn)
展開時の実務チェック
| 項目 | 確認内容 |
|---|---|
| RBAC | ContributorまたはSecurity Adminなど、展開に必要な権限があるか |
| CLI | Azure CLIのバージョンが要件を満たしているか |
| Arc接続 | EKS、GKE、オンプレミスKubernetesがAzure Arcに接続されているか |
| egress | Defender for Cloudへ通信できるか |
| Private Link | Private Link構成時の経路が設計済みか |
| 自動プロビジョニング | 既にセンサーが入っていないか確認してから手動展開するか |
| サポートバージョン | AKS、EKS、GKEのKubernetesバージョンがクラウドベンダーのサポート対象か |
「ポータルでオンにしたのにアラートが出ない」という場合、実際にはセンサー未展開、Kubernetes API access無効、レジストリアクセス未設定、通信遮断、Arc未接続のいずれかが原因になりがちです。
移行・既存環境での注意点
既にMicrosoft Defender for Containersを使っている組織でも、今回の内容を踏まえて設定を棚卸しする価値があります。特に、以前は「イメージスキャンができているか」だけを見ていた環境では、ランタイム保護やゲート付きデプロイ、CI/CD連携が未整備のままになっている可能性があります。
既存環境で確認したいポイント
- Containersプランがすべての対象サブスクリプション、AWS/GCPコネクタ、Arc接続環境で有効か
- センサー未展開のKubernetesクラスターが残っていないか
- Registry accessが実際に使っているレジストリをカバーしているか
- Defender for Cloudの推奨事項が大量に放置されていないか
- Microsoft Defender XDRでKubernetes関連アラートを調査する運用が決まっているか
- CI/CD側でDefender for Cloud CLIやスキャン結果の扱いが決まっているか
- ゲート付きデプロイを使う場合、AuditからDenyへ移行する基準が決まっているか
- 例外ルールの期限、承認者、対象namespaceが定義されているか
移行で避けたいのは、セキュリティ機能の有効化を「運用変更なし」で進めることです。Defender for Containersは、開発フロー、レジストリ運用、Kubernetesデプロイ、インシデント対応に関わります。管理者だけでなく、SRE、DevOps、アプリ開発者、セキュリティ運用担当者を巻き込んで設計する必要があります。
開発者が確認すべき実装・CI/CD上のポイント
開発者にとっての影響は、主にコンテナーイメージの作り方とパイプラインです。Defender for ContainersやDefender for Cloud CLIを導入すると、脆弱性や構成ミスが「本番に出た後」ではなく「ビルド中」や「デプロイ前」に見えるようになります。
Dockerfileとベースイメージの見直し
脆弱性の多くは、アプリケーションコードだけでなくベースイメージやOSパッケージからも発生します。対応としては、次のような基本を徹底します。
- サポート切れOSのベースイメージを使わない
- 不要なパッケージをインストールしない
- ビルド用パッケージを実行イメージに残さない
latestタグに依存せず、更新管理できるタグを使う- マルチステージビルドで成果物だけを実行イメージに入れる
- 実行ユーザーをroot以外にする
- 特権コンテナーや不要なcapabilitiesを避ける
Defender for Containersの推奨事項に対応するだけでなく、再発を防ぐためにDockerfileテンプレートやベースイメージポリシーを整備することが重要です。
CI/CDでの止め方を決める
CI/CDでは、最初からすべての脆弱性でビルドを止めると開発が回らなくなります。実務では、以下のように段階的に基準を上げる方法が現実的です。
| フェーズ | 制御内容 | 目的 |
|---|---|---|
| 初期 | スキャン結果を出すだけ | 現状把握と頻出問題の整理 |
| 試行 | Criticalのみ警告 | 開発者が修復手順に慣れる |
| 準本番 | Criticalで失敗、Highは期限付き対応 | 重要リスクを優先的に減らす |
| 本番 | Critical/Highや悪用可能性ありを制御 | リリース前に重大リスクを止める |
セキュリティルールは、厳しければよいわけではありません。修復可能性、悪用可能性、インターネット公開有無、稼働中ワークロードへの影響を合わせて判断する必要があります。
管理者向けの推奨対応手順
今回の更新を受けて、管理者は次の順番で確認すると効率的です。
現在の保護範囲を棚卸しする
まず、Defender for CloudのEnvironment settingsとWorkbooksを使い、対象サブスクリプション、クラウドコネクタ、Arc接続クラスターを一覧化します。AKSだけでなく、EKS、GKE、オンプレミスKubernetes、検証環境のクラスターも含めて確認します。
見るべきポイントは、Containersプランの有効化状況、Defender sensorの展開状況、Azure Policyの有無、Registry access、Kubernetes API accessです。
スキャン対象と実行中イメージを突き合わせる
次に、実際に稼働しているコンテナーイメージと、Defender for Containersがスキャンできているレジストリを突き合わせます。GitOpsやHelmで管理している場合は、マニフェスト上のイメージ参照も確認してください。
この段階で、古いレジストリ、外部レジストリ、一時的なミラー、スキャン対象外形式のイメージが見つかることがあります。
ランタイム保護を段階的に有効化する
ランタイム保護は、本番環境ほど重要ですが、最初からブロック系機能を強く入れると運用影響が出る可能性があります。まずはアラートを確認し、正常な業務処理との違いを整理します。
Binary drift blockingやゲート付きデプロイは、監査・検知で傾向を確認してから、対象namespaceや重要システムに絞って適用するのが安全です。
開発チームと例外運用を決める
セキュリティ機能でデプロイを止める場合、必ず例外運用が必要です。例外は「無期限」ではなく、対象イメージ、CVE、namespace、期限、承認者を明確にします。
例外が多すぎる場合は、ルールが現実に合っていない可能性があります。逆に例外がまったく使われない場合は、開発チームが回避策を別ルートで作っている可能性もあります。
まとめ：まずは「有効化」ではなく「保護範囲の可視化」から始める
Microsoft Defender for Containersの今回の公式情報で重要なのは、コンテナーセキュリティをレジストリスキャンだけで考えないことです。Kubernetesの設定、実行中ワークロード、ノード、レジストリ、CI/CD、ゲート付きデプロイまでを一連の流れとして見る必要があります。
管理者は、まずAKS、EKS、GKE、Arc対応Kubernetesを含めた保護範囲を棚卸ししてください。そのうえで、Registry access、Kubernetes API access、Defender sensor、Azure Policy、Agentless scanning for machinesの有効化状況を確認します。
開発者は、Defender for Cloud CLIやCI/CDスキャンを使い、脆弱性を本番デプロイ前に発見できる流れを整えましょう。ゲート付きデプロイを導入する場合は、Auditモードから始め、影響範囲を把握してからDenyへ進むのが安全です。
最初に取るべき行動はシンプルです。Defender for CloudでContainersプランの対象範囲を確認し、未保護クラスター、未接続レジストリ、センサー未展開環境を一覧化してください。そこから、リスクの高い本番クラスターと外部公開ワークロードを優先して、段階的に保護を強化するのが現実的な進め方です。
コメント