Microsoft Defender for Cloudは、AzureだけでなくAWS、GCP、オンプレミス、DevOps環境まで含めて、クラウド資産のリスク可視化、推奨事項、脅威検出、ワークロード保護をまとめて扱うクラウドセキュリティ基盤です。今回押さえるべき結論は、Microsoft Defender for CloudがDefenderポータルへ統合され、セキュリティ担当者はクラウド、コード、脆弱性、インシデントをより一元的に確認できるようになるという点です。
ただし、すべての運用がすぐDefenderポータルに移るわけではありません。Azureポータル側の機能も引き続き重要で、権限管理、Secure Scoreの見え方、推奨事項の粒度、Kubernetesセンサーの展開方法などは、管理者が事前に確認すべきポイントです。この記事では、Microsoft Defender for Cloudの概要、2026年5月上旬の公式更新で変わること、管理者・開発者が確認すべき設定と移行時の注意点を実務目線で整理します。
Microsoft Defender for Cloudとは
Microsoft Defender for Cloudは、Microsoftが提供するCloud Native Application Protection Platform、つまりCNAPPです。CNAPPは、クラウド環境の設定ミス、脆弱性、権限リスク、ワークロードへの攻撃、DevOpsパイプライン上の問題を、バラバラのツールではなく一体で管理するための考え方です。
公式ドキュメントでは、Microsoft Defender for Cloudはクラウドとオンプレミスのリソース全体を可視化し、マルチクラウド環境やハイブリッド環境の保護、DevOpsワークフローへのセキュリティ統合を支援するサービスと説明されています。主要コンポーネントは、CSPM、DevSecOps、CWPPの3つです。(Microsoft Learn)
| 領域 | 役割 | 実務での使いどころ |
|---|---|---|
| CSPM | クラウドリソースのセキュリティ体制を評価し、推奨事項やスコアで改善点を示す | 公開ストレージ、過剰権限、暗号化不足、コンプライアンス違反の洗い出し |
| DevSecOps | GitHub、Azure DevOps、GitLabなどのコード・パイプライン環境のリスクを管理する | IaCの設定ミス、シークレット露出、コードからクラウドまでのリスク追跡 |
| CWPP | VM、コンテナー、ストレージ、データベース、サーバーレスなどのワークロードを脅威から保護する | 実行中ワークロードへの攻撃検知、脆弱性評価、インシデント対応 |
重要なのは、Microsoft Defender for Cloudを「Azureのセキュリティ推奨事項を見る画面」とだけ捉えないことです。現在の位置づけは、クラウド資産、コード、ID、脆弱性、ワークロード保護を横断してリスクを優先順位付けする基盤に近づいています。
2026年5月上旬の更新で何が変わるのか
2026年5月上旬の公式更新で特に重要なのは、Defenderポータルへの統合が一般提供されたことです。Microsoft Learnのリリースノートでは、2026年5月5日付で、Microsoft Defender for CloudがMicrosoft Defenderポータルに統合され、クラウドセキュリティ体制管理と脅威保護を1つの体験にまとめると説明されています。対象はAzure、AWS、GCPを含むハイブリッド・マルチクラウド環境です。(Microsoft Learn)
| 変更点 | 内容 | 管理者への影響 |
|---|---|---|
| Defenderポータル統合の一般提供 | クラウドセキュリティのダッシュボード、資産インベントリ、推奨事項、攻撃パス、脆弱性をDefenderポータル側で扱える範囲が拡大 | SOCやセキュリティ運用チームは、クラウドリスクとインシデントを同じポータルで確認しやすくなる |
| 統合クラウドセキュリティダッシュボード | 姿勢の分析、リスクベースの優先順位付け、改善状況の追跡を提供 | 「どの推奨事項から直すべきか」をスコアやリスクで判断しやすくなる |
| クラウド資産インベントリの強化 | リスク、正常性、カバレッジ情報を含む資産ビューを提供 | Azure以外のAWS、GCP資産も含め、棚卸しと保護状況の確認が重要になる |
| MSEMとの統合 | Microsoft Security Exposure Management上で、Secure Score、推奨事項、攻撃パス、脆弱性を扱う | エンドポイント、ID、SaaS、クラウドを横断した露出管理の視点が必要になる |
| リスクベースのCloud Secure Score | より正確な評価と優先順位付けのため、Defenderポータル側でリスクベースのスコアを提供 | Azureポータル側の従来スコアと差分が出る可能性がある |
| 個別の推奨事項モデル | 従来のグループ化された推奨事項ではなく、より細かい個別の調査結果として扱う方向へ移行 | 推奨事項の件数やスコア変動の見え方が変わる可能性がある |
2026年5月6日には、Defender for ContainersセンサーのHelmインストール更新も案内されています。従来のインストールスクリプトではなく、Helmチャートを直接デプロイする流れになり、AKS、EKS、GKE向けの環境別コマンドが示されています。Kubernetes環境を運用している場合は、Defenderポータル統合だけでなく、センサー展開方式の確認も必要です。(Microsoft Learn)
Azureポータルが不要になるわけではない
今回の更新で誤解しやすいのは、「Defender for CloudはDefenderポータルに移ったので、Azureポータルはもう使わなくてよい」と考えてしまうことです。これは正しくありません。
MicrosoftのFAQでは、Defender for CloudのAzureポータル体験は現時点で維持され、Azureポータル側を廃止する予定はないと説明されています。また、新しいリソースへのセキュリティ追加は引き続きAzureポータル側で行うとされています。(Microsoft Learn)
実務では、次のように使い分けるのが現実的です。
| 用途 | 主に使うポータル | 理由 |
|---|---|---|
| セキュリティ運用、インシデント確認、クラウドリスクの横断監視 | Defenderポータル | クラウド、エンドポイント、ID、脅威検出をまとめて確認しやすい |
| Defenderプランの有効化、初期オンボーディング、環境接続、設定管理 | Azureポータル | 初期段階ではAzureポータルで開始する作業が残る |
| Azureリソース所有者による個別リソースの確認 | Azureポータル | Azureリソース管理と近い文脈で確認できる |
| SOCによるアラート、インシデント、脆弱性、攻撃パスの確認 | Defenderポータル | XDRやExposure Managementと連携した調査がしやすい |
特に移行期は、片方のポータルだけで判断しないことが重要です。Secure Score、推奨事項数、資産数は、ポータル間で表示や集計の考え方が異なる場合があります。
影響を受ける主な担当者
Microsoft Defender for Cloudの更新は、セキュリティ管理者だけで完結しません。クラウド運用、開発、SOC、監査対応まで影響します。
| 担当者 | 影響 | 確認すべきこと |
|---|---|---|
| セキュリティ管理者 | Defenderポータルでの統合ビュー、RBAC、Cloud Secure Score、推奨事項モデルの変更に対応する必要がある | Defenderポータルの権限、スコープ、既存ロールとの差分 |
| SOC担当者 | クラウド資産の情報をインシデント調査で参照しやすくなる | アラート調査時に資産インベントリ、攻撃パス、脆弱性情報を併用できるか |
| クラウド管理者 | Azure、AWS、GCPの接続状態やプラン有効化状況が可視化対象になる | サブスクリプション、AWSアカウント、GCPプロジェクトごとの保護状態 |
| DevOps・開発者 | コード、IaC、パイプラインのリスクがクラウドリスクと結び付けられる | GitHub、Azure DevOps、GitLab連携、シークレット露出、IaCミスの対応フロー |
| Kubernetes管理者 | Defender for Containersセンサーの展開方式やアップグレード管理に注意が必要 | AKS、EKS、GKEでHelm展開が必要か、既存デプロイと競合しないか |
| 監査・コンプライアンス担当 | 推奨事項の粒度やスコアの見え方が変わる可能性がある | 監査レポートで参照している指標が変わっていないか |
管理者が最初に確認すべき設定
Defenderポータル統合を利用する前に、まず現在の有効プランと権限を確認します。公式情報では、Defender for Cloudの有料プランを少なくとも1つ有効にしている顧客が、Defenderポータル側の新しい機能を利用できると説明されています。また、Defenderポータルでデータが表示されるまで最大24時間かかる場合があります。(Microsoft Learn)
有効化済みプランを棚卸しする
最初に確認するのは、どのDefenderプランを有効にしているかです。Defender for Cloudには、Defender CSPM、Defender for Servers、Defender for Containers、Defender for Storage、Defender for Databases、Defender for APIs、AI Servicesなど複数のプランがあります。公式ドキュメントでも、追加プランを有効化することでワークロード保護とカバレッジを拡張できると説明されています。(Microsoft Learn)
棚卸しでは、次の観点で確認します。
| 確認項目 | 具体的な見方 |
|---|---|
| 有効なDefenderプラン | サブスクリプション単位、AWSアカウント単位、GCPプロジェクト単位で有効化状況を確認 |
| 保護対象 | VM、Kubernetes、ストレージ、データベース、API、AIワークロードなどを分類 |
| 未保護の重要資産 | 本番環境、インターネット公開資産、機密データを扱うリソースを優先して確認 |
| コスト影響 | 追加プランを有効にする前に、対象リソース数と課金条件を確認 |
| 運用責任者 | 推奨事項を誰が修正するのか、チーム単位で責任を割り当てる |
「Defender for Cloudを有効にしている」だけでは不十分です。どのワークロードにどの保護が効いているかまで確認しないと、重要資産がスコア上は見えていても実際の脅威保護が不足している、という状態になりやすくなります。
Defenderポータルの権限をAzure RBACと分けて確認する
Defenderポータル統合で特に注意すべきなのが権限です。DefenderポータルのUnified RBACはAzure RBACとは別のモデルであり、ポータル間で権限が自動的に引き継がれるわけではありません。MicrosoftのFAQでも、AzureポータルとDefenderポータルでは異なるRBACモデルを使い、両方にアクセスするユーザーにはそれぞれの権限が必要と説明されています。(Microsoft Learn)
| やってはいけない設定 | 問題点 | 推奨される対応 |
|---|---|---|
| Azureの共同作成者権限を持つ人ならDefenderポータルも見られると考える | Defenderポータル側では別途権限が必要になる | DefenderポータルのUnified RBACを確認する |
| SOC担当者に広すぎるAzure権限を付与する | セキュリティ閲覧のためだけにリソース操作権限まで持たせてしまう | Defenderポータル側でセキュリティタスクに応じた権限を割り当てる |
| AWS/GCP担当者にAzureサブスクリプション権限を無理に付ける | マルチクラウド運用で権限設計が複雑になる | Cloud scopesを使って対象環境ごとの可視性を設計する |
権限設計では、「誰に何を見せるか」よりも「誰がどの推奨事項を修正し、どのインシデントに対応するか」から逆算すると失敗しにくくなります。
Cloud scopesはプレビューであることを前提に使う
Defenderポータルでは、Cloud scopesとUnified RBACにより、Azureサブスクリプション、AWSアカウント、GCPプロジェクト、DevOps組織、レジストリなどを論理的にグループ化し、最小権限でアクセスを割り当てられます。ただし、Cloud scopesはプレビュー機能として扱われており、制限事項もあります。(Microsoft Learn)
たとえば、事業部、地域、本番・検証環境、重要システム単位でスコープを作ると、セキュリティチームが必要な範囲だけを見られるようになります。一方で、スコープを細かく作りすぎると、権限レビューや棚卸しが複雑になります。
現場で使いやすい設計例は次の通りです。
| スコープ設計 | 向いているケース | 注意点 |
|---|---|---|
| Production / Staging / Test | 環境ごとに担当者や対応SLAが違う | 本番だけ強い権限を与えたい場合に有効 |
| Finance / Retail / R&D | 事業部ごとにセキュリティ責任者が違う | 組織変更が多い場合はメンテナンス負荷に注意 |
| Japan / EU / US | 地域や法規制の境界で管理したい | データ所在地や監査要件と合わせて設計する |
| Crown-Jewels | 最重要資産だけ別管理したい | 対象資産の定義を定期的に見直す |
まずは大きな単位で始め、機密性や運用責任の違いが明確な場合だけ細分化するのが現実的です。
Secure Scoreと推奨事項の見え方に注意する
2026年5月上旬の更新では、Cloud Secure Scoreと推奨事項の扱いも重要です。リリースノートでは、リスクベースのクラウドセキュリティスコアの日次計算が改善され、日次スコアは1日の平均ではなく、1日の終わりのスナップショットとして扱われると説明されています。履歴値もこの定義に合わせて再計算されるため、過去の傾向を比較すると小さな違いに気付く場合があります。(Microsoft Learn)
また、Azureポータルでは、従来グループ化されていた推奨事項が個別の推奨事項として一般提供され、従来のグループ化された推奨事項は2026年7月30日に削除予定とされています。(Microsoft Learn)
実務では、次のような影響が出やすくなります。
| 変化 | 起こりやすい混乱 | 対応 |
|---|---|---|
| スコア計算の考え方が変わる | 「先月より急にスコアが変わった」と見える | 更新前後の基準を分けてレポートする |
| 推奨事項が個別化される | 件数が増えたように見える | 件数ではなく、重大度・攻撃パス・公開範囲で優先順位付けする |
| DefenderポータルとAzureポータルで表示が異なる | どちらが正しいのか判断しにくい | 目的別に参照ポータルを決め、監査資料では参照元を明記する |
| リスクベースのスコアがDefenderポータル中心になる | 従来のSecure Scoreだけでは優先度を判断しにくい | Defenderポータル側のリスク文脈も確認する |
セキュリティ会議や月次報告では、「スコアが何点か」だけでなく、「スコア計算の変更があったか」「推奨事項の粒度が変わったか」を注記しておくと、経営層や監査担当者との認識ズレを防げます。
AzureポータルとDefenderポータルの機能差を確認する
Defenderポータルは統合体験として重要ですが、Azureポータルと完全に同じ機能を持つわけではありません。Microsoftの比較表では、データ可視化とレポートのAzure Workbooks、データエクスポート、ワークフロー自動化、クイック修復、ServiceNow統合、ガバナンスによる大規模修復、カスタム推奨事項などは、Defenderポータル側では利用できない、またはAzureポータル側に残る機能として示されています。(Microsoft Learn)
| 機能 | Azureポータル | Defenderポータル | 実務上の判断 |
|---|---|---|---|
| セキュリティ推奨事項 | 利用可能 | Exposure Managementに統合 | どちらで確認するかを運用手順に明記する |
| 資産インベントリ | 利用可能 | 利用可能 | Defenderポータルでは検出済みリソースの横断確認に向く |
| Secure Score | 従来モデル | 新しいリスクベースのCloud Secure Score | レポートではポータル名を明記する |
| Azure Workbooks | 利用可能 | 非対応 | 既存レポートがWorkbooks前提ならAzureポータルを継続 |
| データエクスポート | 利用可能 | 非対応 | SIEMや監査連携がある場合はAzureポータル側設定を確認 |
| ワークフロー自動化 | 利用可能 | 非対応 | 自動通知やチケット連携は既存設定を維持 |
| クイック修復 | 利用可能 | 非対応 | 修復作業はAzureポータル側で行うケースを想定 |
| Cloud scopes / RBAC | Azure RBAC中心 | Unified RBACとCloud scopes | 権限モデルを分けて設計する |
移行時に最も危険なのは、Defenderポータルで見えるようになったことを理由に、Azureポータル側の既存自動化やエクスポート設定を見落とすことです。特にSIEM、SOAR、ITSM、ServiceNow連携を使っている環境では、現行フローを必ず棚卸ししてください。
既知の制限事項と注意点
Defenderポータルの新しいクラウド機能には、いくつかの制限事項があります。公式ドキュメントでは、Defenderポータル体験を有効にしてもAzureポータル側の体験には影響しない一方で、新しいクラウド機能は現時点でパブリック/商用クラウドのみ対応、Government cloudでは未対応とされています。また、Foundational CSPMの無料レベルのみのサブスクリプションに紐づくリソースが表示されないなどの制限も示されています。(Microsoft Learn)
| 注意点 | 内容 | 対応 |
|---|---|---|
| データ表示に時間がかかる | 有効化後、データ反映まで最大24時間かかる場合がある | 初日の表示だけで失敗と判断しない |
| ポータル間で資産数が違う | Defenderポータルは完全な環境検出を見せるため、件数が異なる場合がある | 月次報告では参照元ポータルを固定する |
| Azure RBACは引き継がれない | DefenderポータルではUnified RBACを別途設定する必要がある | セキュリティ運用チーム用のロールを再設計する |
| Cloud scopesはプレビュー | API非対応や動的条件指定不可などの制限がある | 過度に複雑なスコープ設計を避ける |
| XDR側のスコープフィルターは完全ではない | インシデントやアラートでスコープフィルターが十分に効かない場合がある | 機密環境では表示範囲を検証してから展開する |
| 一部の資産はスコープ外で見える | IPアドレス、証明書、シークレット、サービスプリンシパルなどが細かくスコープ制御できない場合がある | 機密情報を扱う担当者の権限を慎重に設定する |
特に権限周りは、導入後にトラブルになりやすい領域です。「見えるべき人に見えない」よりも、「見えてはいけない人に見える」ほうが深刻な問題になるため、最小権限で段階的に展開してください。
Kubernetes環境ではHelm展開の確認が必要
AKS、EKS、GKEでDefender for Containersを使っている場合は、2026年5月6日の更新に注意が必要です。リリースノートでは、Defender for ContainersセンサーのインストールがHelmを使用し、インストールスクリプトの代わりにHelmチャートの直接デプロイを使う流れになったと説明されています。(Microsoft Learn)
Kubernetes管理者は、次の観点で確認してください。
| 確認項目 | 理由 |
|---|---|
| 対象クラスターがAKS、EKS、GKEのどれか | 環境ごとに必要なコマンドや識別子が異なる |
| 既存のDefenderセンサーがどの方式で入っているか | 自動プロビジョニング、拡張機能、Helmが混在すると競合しやすい |
| Helmでアップグレード管理する体制があるか | Helm方式ではバージョン管理とアップグレードタイミングの運用責任が増える |
| 名前空間や既存リソースの競合がないか | 既存デプロイと重複するとセンサーが正常に動作しない可能性がある |
| 検証環境で先に展開できるか | 本番クラスターでいきなり切り替えると検知やワークロードに影響するリスクがある |
コンテナーセキュリティは「導入したら終わり」ではありません。センサーのバージョン、検知対象、アップグレード手順、障害時のロールバックを運用手順書に含めておくべきです。
開発者・DevSecOps担当者が確認すべきこと
Microsoft Defender for Cloudは、開発ライフサイクルの早い段階にセキュリティを組み込む機能を持っています。公式ドキュメントでは、GitHub、Azure DevOps、GitLabなどのマルチパイプライン環境で、IaCの構成ミスや露出したシークレットなどのDevOpsセキュリティ調査結果を、クラウド側のセキュリティ情報と関連付けられると説明されています。(Microsoft Learn)
開発チームが確認すべきポイントは、次の3つです。
リポジトリ連携が有効か
GitHub、Azure DevOps、GitLabを使っている場合、Defender for Cloudと連携していなければ、コードからクラウドまでのリスクがつながりません。特にIaCを使ってAzureリソースやKubernetesマニフェストを展開している場合は、実行前の設定ミス検知が重要です。
シークレット露出を修正フローに乗せる
シークレット露出の検知は、通知だけでは意味がありません。検知後に、キーの無効化、再発行、影響範囲確認、履歴からの削除、再発防止までを誰が行うか決めておく必要があります。
推奨事項を開発チームに割り当てる
クラウド側で「脆弱なコンテナーイメージ」や「危険な構成」が見つかっても、修正するのは開発チームであることが多いです。セキュリティチームが指摘し、開発チームが修正し、クラウド管理者が展開を確認する流れを決めておくと、推奨事項が放置されにくくなります。
移行・展開時の実務チェックリスト
Defenderポータル統合を本番運用に取り込む場合は、いきなり全社展開するより、小さく検証してから拡大する方が安全です。
| 手順 | やること | 完了の目安 |
|---|---|---|
| 現状棚卸し | 有効なDefenderプラン、対象サブスクリプション、AWS/GCP接続、Kubernetesクラスターを一覧化する | 保護対象と未保護対象が分かる |
| Defenderポータルの有効化確認 | 対象テナントでDefenderポータル側のクラウド機能を確認する | Cloud securityのOverviewにデータが表示される |
| 権限設計 | Azure RBACとは別に、Unified RBACとCloud scopesを設計する | SOC、監査、開発、クラウド運用の権限が分離されている |
| スコア基準の確認 | AzureポータルとDefenderポータルのSecure Score、推奨事項数を比較する | レポートで参照する指標が決まっている |
| 既存連携の確認 | SIEM、SOAR、ITSM、ServiceNow、Azure Workbooks、データエクスポートを確認する | 既存自動化が止まらない |
| Kubernetes展開確認 | Defender for Containersセンサーの方式、Helm利用有無、アップグレード手順を確認する | 本番展開前に検証環境で確認済み |
| 運用ルール化 | 推奨事項の優先順位、担当者、期限、例外申請、監査ログを定義する | 修復が属人化しない |
小規模な検証では、まず本番以外のサブスクリプションや一部のクラウドスコープを対象にします。表示される資産、推奨事項、スコア、権限範囲、通知フローを確認してから本番環境へ展開すると、混乱を抑えられます。
よくある誤解と正しい判断
Defenderポータルに統合されたらAzureポータルは使わない？
使い分けが必要です。Defenderポータルはセキュリティ運用の一元化に向いていますが、初期オンボーディング、環境接続、設定管理、Azure Workbooks、データエクスポート、ワークフロー自動化などはAzureポータル側の確認が必要なケースがあります。(Microsoft Learn)
追加コストは発生する？
FAQでは、現時点でこの拡張による課金影響はなく、既存顧客は追加料金なしで新機能を体験できると説明されています。ただし、Defenderプランの有効化範囲や対象リソース数による通常の課金は別問題です。費用を判断する際は、必ず現在有効なプランと対象リソースを確認してください。(Microsoft Learn)
Secure Scoreが変わったらセキュリティが悪化したということ？
必ずしもそうではありません。スコア計算や推奨事項の粒度が変わると、実際の環境変更がなくても見え方が変わる場合があります。スコアの変動だけで判断せず、重大度、公開範囲、攻撃パス、資産の重要度を合わせて確認します。
Cloud scopesを細かく作れば安全？
細かすぎるスコープは運用負荷を増やします。最初は事業部、環境、本番重要資産など、安定した境界で設計し、必要に応じて細分化する方が管理しやすくなります。
まず取るべき次のアクション
Microsoft Defender for Cloudの今回の更新は、単なる画面変更ではありません。クラウドセキュリティ体制管理、脅威保護、脆弱性、DevOps、インシデント対応を、Defenderポータル中心に統合していく流れの一部です。
管理者はまず、次の5つを確認してください。
- 有効化済みのDefenderプランと未保護の重要資産を棚卸しする
- Defenderポータルでクラウド資産、推奨事項、Secure Scoreがどう見えるか確認する
- Azure RBACとは別に、DefenderポータルのUnified RBACとCloud scopesを設計する
- Azureポータルに残る機能、既存の自動化、データエクスポート、レポートを洗い出す
- AKS、EKS、GKEを使っている場合は、Defender for ContainersセンサーのHelm展開方針を確認する
特に、権限、スコア、推奨事項、Kubernetesセンサーは、運用開始後に手戻りが起きやすい領域です。Defenderポータルの新しい統合ビューを使い始める前に、既存運用との違いを明文化し、担当チームごとに「何を見るか」「何を直すか」「どこで設定するか」を決めておきましょう。
コメント