2026年4月10日、Microsoft は Microsoft Defender for Cloud のマルチクラウド コネクタのベスト プラクティスを公開しました。結論から言うと、今回のメッセージは「Azure・AWS・GCP をとりあえず接続する」では不十分で、削除済み環境のコネクタを残さない、ID 連携を取り違えない、同じクラウド環境を二重登録しないという運用ルールまで含めて、接続の健全性を管理してほしい、というものです。(TECHCOMMUNITY.MICROSOFT.COM)
Defender for Cloud は Azure を管理基盤にしつつ、AWS と GCP を外部環境として取り込み、CSPM とワークロード保護を横断的に扱う設計です。この記事では、今回の公開内容を単なるニュースで終わらせず、企業が Azure・AWS・GCP 接続をどう強化すべきかを、導入判断と運用の注意点まで含めて整理します。(Microsoft Learn)
今回のベスト プラクティスで Microsoft が本当に伝えたこと
今回のブログは新機能の追加告知というより、計画ガイドや展開ガイドを踏まえたうえで、サポートで頻出する接続トラブルを整理した実務寄りのガイダンスです。つまり Microsoft が企業に求めているのは、次の4点に集約できます。(TECHCOMMUNITY.MICROSOFT.COM)
- Azure 側はサブスクリプションや管理グループで Defender for Cloud の土台をそろえ、設定のばらつきを減らすこと。(Microsoft Learn)
- AWS と GCP は、単一アカウント／単一プロジェクトでつなぐのか、管理アカウント／Organization で広くつなぐのかを先に決め、権限モデルまで設計してからオンボードすること。(Microsoft Learn)
- コネクタを「作って終わり」にせず、削除・再作成・重複防止まで含めてライフサイクル管理すること。(TECHCOMMUNITY.MICROSOFT.COM)
- コネクタ接続だけで全部が保護されるわけではないため、Servers・Containers・SQL など守りたい対象に応じて追加プランと依存コンポーネントをそろえること。(Microsoft Learn)
なぜ今、マルチクラウド コネクタの見直しが重要なのか
2026年3月29日には、Defender for Cloud の AWS/GCP 向けマルチクラウド カバレッジが拡張され、追加のリソース種別 discovery と約150の新しい推奨事項が導入されました。Microsoft は、この拡張に伴ってコンプライアンス結果が変わる可能性があると案内しています。対象が広がるほど、コネクタの設計ミスや運用漏れは「少し見えない」では済まず、評価の抜けや重複の原因になりやすくなります。(Microsoft Learn)
しかも、マルチクラウドの Regulatory compliance は、コネクタがあるだけではなく、コネクタが置かれたサブスクリプションまたはコネクタで少なくとも1つの Defender プランを有効にして初めて使えます。つまり「まず接続だけして、評価は後で」は、現場では意外と中途半端になりやすい進め方です。(Microsoft Learn)
Microsoft Defender for Cloud のコネクタで外しやすい3つの落とし穴
削除済み AWS・GCP 環境のコネクタを放置する
外部の AWS アカウントや GCP プロジェクトを削除しても、Defender for Cloud 側の security connector は自動では消えません。Azure 側に別オブジェクトとして残るため、接続済み環境や推奨事項に古いデータが残り続けます。組織レベルのコネクタだった場合は、管理アカウントのコネクタから先に削除し、その後に子コネクタを消すのが Microsoft の案内です。(TECHCOMMUNITY.MICROSOFT.COM)
さらに見落としやすいのは、Defender for Cloud 側でコネクタを削除しても、AWS の IAM ロールや GCP の workload identity pool / provider など、オンボード時に外部クラウド側へ作った資源までは自動削除されない点です。完全にオフボードするなら、Azure だけでなく AWS/GCP 側の後片付けも必要です。(TECHCOMMUNITY.MICROSOFT.COM)
AWS の ID 連携で Azure のディレクトリやサブスクリプションを取り違える
Microsoft が挙げている典型例は、CloudFormation テンプレートを生成したときの Azure directory / subscription が誤っている、またはテンプレートを別の AWS アカウントに展開してしまうケースです。このズレが起きると、OIDC identity provider や IAM trust policy が正しく結び付かず、コネクタは失敗状態になります。接続が正常化すると、AWS 環境は Healthy になり、リソースと推奨事項はおおむね1時間ほどで表示され始めます。(TECHCOMMUNITY.MICROSOFT.COM)
同じテナントで同じ AWS・GCP 環境を二重登録する
同じ Microsoft Entra ID テナント内では、1つの AWS アカウントまたは GCP プロジェクトに対して作成できるコネクタは1つだけです。すでに別の Azure サブスクリプションで同じ環境をオンボードしていると、hierarchyId 重複エラーで新しいコネクタは失敗します。複数チームが別々に接続作業を進める組織ほど、この事故は起きやすいポイントです。(TECHCOMMUNITY.MICROSOFT.COM)
同一 tenant 内の重複確認に使える例として、公式ブログでは次の Azure Resource Graph クエリが紹介されています。(TECHCOMMUNITY.MICROSOFT.COM)
resources
| where type == "microsoft.security/securityconnectors"
| project name, location, properties.hierarchyIdentifier, tenantId, subscriptionIdAzure・AWS・GCP 接続を強化する設計ポイント
Azure は管理グループからばらつきをなくす
Azure は AWS/GCP のような外部コネクタではなく、サブスクリプション自体で Defender for Cloud を有効化するのが起点です。サブスクリプション数が多い組織は、管理グループに Azure Policy を割り当てて一括オンボードしたほうが、設定漏れとばらつきを抑えやすくなります。(Microsoft Learn)
加えて、AWS/GCP のコネクタは Azure のサブスクリプションとリソースグループに Azure リソースとして作成されます。どのサブスクリプションにコネクタを置くかは、課金・権限・コンプライアンス表示に影響するため、セキュリティ運用の管理単位を先に決めてから接続を増やすのが安全です。(TECHCOMMUNITY.MICROSOFT.COM)
AWS はアカウント単位より先に「運用単位」を決める
AWS 接続では、Azure portal の Defender for Cloud > Environment settings からアカウントを追加し、監視対象リージョンとスキャン間隔を選びます。単一アカウントで始めることもできますが、複数アカウント運用を前提にするなら、管理アカウント接続で StackSets を使い、子アカウントのコネクタを自動作成させる設計のほうが後から伸ばしやすいです。(Microsoft Learn)
Default access と Least privilege access の選び分け
AWS では権限付与時に Default access と Least privilege access を選べます。公式説明では、前者は現在と将来の機能に必要な権限をまとめて付与し、後者は現時点で必要な権限だけを付与し、将来追加権限が必要になれば通知されます。実務的には、新機能を早く使いたい中央集権型の運用なら Default access、権限審査を厳密に回したい組織なら Least privilege access が向きます。(Microsoft Learn)
もう1つの盲点はログコストです。Defender CSPM は最新の推奨事項を出すために AWS Resource API を1日に複数回読み取りし、API コール自体に AWS 課金はありません。ただし read-event logging を有効にしていると CloudTrail に記録され、さらに外部 SIEM に転送している環境では取り込みコストが増える可能性があります。セキュリティ部門と運用部門で別々に設計すると見落としやすい点です。(Microsoft Learn)
GCP は project か organization かを最初に決める
GCP では、Single project で小さく始めるか、Organization 単位で広く接続するかを最初に決めるのが重要です。Organization 接続では 除外する project number や folder ID を指定できるため、全社一括ではなく段階的展開にも向いています。(Microsoft Learn)
認証は長期資格情報の保管ではなく、workload identity federation と service account impersonation を使う構成です。オンボード時のスクリプトは workload identity pool / provider、service account、project レベルの policy binding を作成し、iam.googleapis.com、sts.googleapis.com、cloudresourcemanager.googleapis.com など必要 API も前提になります。(Microsoft Learn)
GCP は作成後すぐに結果が出るとは限らず、新しい推奨事項の表示まで最大6時間かかるとされています。接続後は Environment settings の Connectivity status を確認し、問題があれば Environment details の説明や remediation script を追う運用が現実的です。(Microsoft Learn)
コネクタだけでできることと、できないこと
コネクタだけでできること
AWS/GCP を Defender for Cloud にオンボードすると、CSPM はエージェントレスで動き始めます。公式ガイドでは、AWS/GCP connector の成功したオンボードだけで業界標準に対する posture assessment が始まり、Security Posture Management plan は既定でオンになっており無効化できないと説明されています。(Microsoft Learn)
追加コンポーネントが必要なこと
一方で、サーバー・コンテナ・SQL まで深く守るなら別です。Defender for Servers / Containers / SQL on Machines では、Azure Arc agent、Microsoft Defender for Endpoint、脆弱性評価、Defender sensor、Azure Policy for Kubernetes、Kubernetes audit logs など追加コンポーネントが要ります。「コネクタが緑だから全部保護済み」ではない、というのが実務上の重要ポイントです。(Microsoft Learn)
しかも AWS/GCP 側に作られるロールや権限は、有効にした Defender プランに応じて変わります。先に守りたい対象を決めずに接続だけ進めると、後から権限再設計や監査説明が必要になりがちです。(Microsoft Learn)
企業が今すぐ確認したいチェックリスト
- Azure 側で Defender for Cloud の管理単位を、管理グループで統一するのか、サブスクリプション単位で運用するのか決める。(Microsoft Learn)
- AWS/GCP コネクタをどの Azure サブスクリプション・リソースグループに置くか整理する。(TECHCOMMUNITY.MICROSOFT.COM)
- 削除済み AWS アカウントや GCP プロジェクトの stale connector が Environment settings に残っていないか確認する。(TECHCOMMUNITY.MICROSOFT.COM)
- 同じ Microsoft Entra ID テナント内で
hierarchyIdが重複していないか確認する。(TECHCOMMUNITY.MICROSOFT.COM) - AWS/GCP で Default access と Least privilege access のどちらを選ぶか、選択理由を運用手順に明記する。(Microsoft Learn)
- Servers / Containers / SQL まで使うなら、Azure Arc、MDE、SSM Agent、GCP 必須 API、Kubernetes audit logs など依存関係を接続前に確認する。(Microsoft Learn)
- 接続後は Connectivity status を監視し、AWS は約1時間、GCP は最大6時間の反映差を見込んで確認する。(TECHCOMMUNITY.MICROSOFT.COM)
まとめ
Microsoft Defender for Cloud が今回示したマルチクラウド コネクタのベスト プラクティスの本質は、コネクタを「導入作業」ではなく「継続運用するセキュリティ資産」として扱うことです。Azure の管理単位、AWS/GCP の権限モデル、削除・再作成・重複防止、そして plan 依存の追加コンポーネントまで整理できていれば、Azure・AWS・GCP をまたぐ可視性はかなり安定します。まずは Defender for Cloud の Environment settings を開き、残骸コネクタ、重複、権限方式、Connectivity status の4点から棚卸しすると、今回の公開内容を実務に落とし込みやすくなります。(TECHCOMMUNITY.MICROSOFT.COM)
コメント