Microsoft Defender for CloudでAWSアカウントを接続すると、AWS上のEC2、EKS、RDS、S3などのリソースをMicrosoft Defender側で検出し、セキュリティ推奨事項・アラート・資産インベントリとしてまとめて管理できます。今回の公式情報で管理者がまず確認すべきポイントは、AWSネイティブコネクタの接続方式、CloudFormationテンプレートの更新要否、Defenderプランごとの前提条件、CloudTrail取り込みとコスト影響、Microsoft Sentinel連携済み環境での競合回避です。
特に既存のAWS環境をMicrosoft Defender for Cloudに接続済みの企業は、「接続できているか」だけでなく、選択しているDefenderプランとAWS側に展開したIAMロール・CloudFormation Stack・Azure Arc・SSM Agentが現在の要件に合っているかを点検する必要があります。Microsoft Learnの公式ドキュメントでは、AWSアカウントまたはAWS管理アカウントをネイティブAWSコネクタで接続し、接続後にAWSリソースの検出、セキュリティ態勢評価、推奨事項とアラート表示を行う流れが示されています。(GitHub)
Microsoft Defender for CloudのAWS接続で何ができるのか
Microsoft Defender for CloudのAWSアカウント接続は、Azureだけを守る機能ではありません。AWS環境をMicrosoft Defenderの管理対象に加え、マルチクラウド環境のセキュリティ状態を一元的に確認するための機能です。
接続後は、主に次のような管理が可能になります。
| できること | 実務上の意味 |
|---|---|
| AWSリソースの検出 | AWSアカウント内の対象リソースをDefender for Cloud側で把握できる |
| セキュリティ推奨事項の表示 | 設定ミス、露出、脆弱性、権限リスクなどを優先順位付きで確認できる |
| アラートの確認 | AWSワークロードに関する脅威検出をMicrosoft Defenderの運用に組み込める |
| Defenderプラン別の保護 | Servers、Containers、SQL、Open-source databases、CSPMなどを用途別に有効化できる |
| CloudTrailログ取り込み | CIEMや構成変更検出に、実際のAWS操作ログを活用できる |
重要なのは、AWSアカウントを接続しただけで全機能が自動的に最大範囲で有効になるわけではない点です。どのDefenderプランを有効にするか、どのAWSリージョンを対象にするか、どの権限方式で展開するかによって、保護範囲・コスト・必要なAWSリソースが変わります。
今回の公式情報で管理者が確認すべき変更点
2026年6月上旬のMicrosoft Defender for Cloud関連情報では、AWS接続そのものの手順に加え、EKS、RDS、CloudTrail、CloudFormationテンプレート更新など、既存運用に影響する項目が目立ちます。特にAWSを本番利用している組織では、セキュリティ担当だけでなく、AWS管理者、Azure管理者、SOC、開発基盤チームで確認しておくべき内容です。
| 確認項目 | 影響を受けやすい環境 | 対応ポイント |
|---|---|---|
| AWS管理アカウント接続 | AWS Organizationsを利用している企業 | 委任管理者アカウントではなくAWS管理アカウントを使う |
| CloudFormationテンプレート更新 | 既存のAWSコネクタを運用中の環境 | 新しいDefenderプラン追加、リージョン変更、自動プロビジョニング変更時に更新要否を確認する |
| Defender for Servers | EC2を保護対象にしている環境 | Azure Arc、AWS SSM Agent、必要な拡張機能を確認する |
| Defender for Containers | EKSを利用している環境 | EKSクラスター、Kubernetes APIアクセス、SQS・Firehose・S3などの依存リソースを確認する |
| Defender CSPM / CIEM | 権限管理・攻撃経路分析を使う環境 | Microsoft Entra ID側のロールとAWS IAM権限を確認する |
| CloudTrailログ取り込み | Sentinelや外部SIEMへCloudTrailを送っている環境 | SQSの単一コンシューマー問題、SNS fan-out、取り込みコストを確認する |
公式ドキュメントでは、Defenderプランの有効化やプラン構成の変更、選択リージョンの変更、Microsoftが新しいテンプレートをリリースした場合、またはAccessDeniedやLambdaランタイムエラーなどが発生した場合に、AWS側のCloudFormationテンプレート更新が必要になると説明されています。(GitHub)
AWSアカウント接続の基本構成
Microsoft Defender for CloudでAWSを接続する場合、AzureポータルのDefender for Cloudから「Environment settings」に進み、「Add environment」からAmazon Web Servicesを追加します。接続方式は大きく分けて、単一AWSアカウントとAWS管理アカウントの2種類です。
単一アカウントと管理アカウントの違い
| 接続方式 | 向いているケース | 注意点 |
|---|---|---|
| 単一アカウント | 検証環境、小規模AWS利用、特定アカウントのみ保護したい場合 | アカウントが増えるたびに個別管理が必要になりやすい |
| AWS管理アカウント | AWS Organizations配下の複数アカウントをまとめて管理したい場合 | オンボードにはAWS管理アカウントを使う。委任管理者アカウントはサポート対象外 |
AWS Organizationsを使っている場合は、管理アカウント接続を選ぶことで、検出されたメンバーアカウントや新しく作成されたアカウントに対してコネクタを自動作成できます。ただし、公式ドキュメントでは管理アカウントのオンボードにはAWS管理アカウントのみを使用し、委任管理者アカウントはサポートされないと明記されています。(Microsoft Learn)
実務ではここを間違えやすいです。AWS Control TowerやOrganizationsを運用している企業では、セキュリティ用の委任管理者アカウントを日常運用に使っていることがあります。しかしDefender for Cloudの管理アカウントオンボードでは、その前提がそのまま使えないケースがあります。接続前に、AWS組織設計と運用権限を確認しておきましょう。
認証方式は長期シークレットではなくフェデレーション信頼
AWS接続で気になるのが、「Microsoft側にAWSアクセスキーを保存するのか」という点です。公式ドキュメントでは、AWSアカウント接続時にMicrosoft Defender for Cloudはフェデレーション信頼と短期資格情報を使ってAWSに認証し、長期間有効なシークレットは保存しないと説明されています。(Microsoft Learn)
オンボード時には、CloudFormationテンプレートによってAWS側に次のような認証関連リソースが作成されます。
- Microsoft管理のMicrosoft Entraアプリケーションに紐づくOpenID Connect IDプロバイダー
- Defender for CloudがWeb IDフェデレーションで引き受けるIAMロール
- 有効化するDefenderプランに応じた追加のAWSリソースや権限
この構成では、AWS STSによる短期資格情報を使ってAWS APIを呼び出します。管理者は「アクセスキーを発行して渡す」発想ではなく、IAMロール、信頼ポリシー、最小権限、CloudFormationの差分管理を中心に確認する必要があります。
接続前に確認すべき前提条件
AWSアカウント接続の前提条件は、単にAzureサブスクリプションがあればよいというものではありません。公式ドキュメントでは、Azureサブスクリプション、Defender for Cloudの有効化、AWSアカウントへのアクセス、対象Azureサブスクリプションへの共同作成者レベルの権限、CIEMを有効にする場合の追加権限が必要とされています。(Microsoft Learn)
接続作業の前に、次のチェックリストを使うと失敗を減らせます。
| 確認項目 | 確認内容 | 不足していると起きる問題 |
|---|---|---|
| Azureサブスクリプション | セキュリティコネクタを作成するサブスクリプションが決まっているか | 接続先や課金管理が曖昧になる |
| Azure側権限 | 共同作成者以上の権限があるか | コネクタ作成や設定変更ができない |
| AWS側権限 | CloudFormation、IAM、CloudTrail、S3、SQSなどを操作できるか | テンプレート展開やログ連携で失敗する |
| Defenderプラン | CSPM、Servers、Containers、SQLなど、何を有効にするか決めているか | 余計なコストや保護漏れが発生する |
| 対象リージョン | 保護対象リソースが存在するAWSリージョンを把握しているか | リソース検出や推奨事項の対象外が出る |
| 既存SIEM連携 | CloudTrailをSentinelや外部SIEMに送っているか | ログ通知の競合や取り込みコスト増につながる |
なお、AWSコネクタはAzure Governmentや21Vianet運営のMicrosoft Azureなど、各国政府クラウドでは利用できないとされています。商用クラウド以外での利用を検討している場合は、最初にクラウド環境の対応可否を確認してください。(Microsoft Learn)
Defenderプラン別の影響範囲
Microsoft Defender for CloudのAWS接続では、どのDefenderプランを有効にするかで、必要なAWSリソース、権限、エージェント、コストが変わります。ここを曖昧にしたまま「全部オン」にすると、あとから請求や権限レビューで問題になりやすくなります。
Defender CSPM
Defender CSPMは、クラウドのセキュリティ態勢管理を強化する有料プランです。Foundational CSPMはDefender for Cloudサブスクリプションに含まれ既定で有効ですが、Defender CSPMは攻撃経路分析、リスク優先順位付け、エージェントレススキャン、CIEMなどの高度な機能を使う場合に関係します。CSPMには無料のFoundational CSPMと有料のDefender CSPMがあり、Microsoft Learnでは、Defender CSPMがAzure、AWS、GCP、オンプレミス、DevOps領域にまたがる高度な姿勢管理機能を提供すると説明されています。(Microsoft Learn)
AWS環境でDefender CSPMを使う場合は、次を確認します。
- Microsoft Entra ID側で必要な管理者ロールがあるか
- AWS IAMで監視ロールを引き受ける権限があるか
- CIEMを有効化するか
- CloudTrailログ取り込みを使うか
- 課金対象となるAWSリソースを把握しているか
特にCIEMを有効にする場合は、権限リスクの評価だけでなく、CloudTrailの実操作データを取り込むことで、未使用権限や休眠ID、権限昇格経路の分析精度を高められます。
Defender for Servers
AWS上のEC2を保護する場合は、Defender for Serversの前提条件を確認します。公式ドキュメントでは、EC2インスタンス、Azure Arc for servers、AWS SSM Agent、Microsoft Defender for Endpoint、脆弱性評価ソリューションなどが要件として示されています。また、SSM Agentが存在しない、または削除されている場合、Arcの自動プロビジョニングは進行できません。(Microsoft Learn)
実務で特に確認したいのは次の3点です。
1つ目は、EC2にSSM Agentが入っているかです。AWSの標準AMIでは入っているケースもありますが、カスタムAMIや古いイメージでは未導入・停止・権限不足の可能性があります。
2つ目は、Azure Arcのネットワーク要件を満たしているかです。プロキシ、アウトバウンド通信制御、閉域網、NAT構成によって、Arc登録や拡張機能配布が失敗することがあります。
3つ目は、Log Analytics Agent依存からの移行状況です。公式ドキュメントでは、Log Analytics Agentは2024年8月に廃止され、それに依存する機能はDefender for Endpoint統合またはエージェントレススキャンへ移行していると説明されています。(Microsoft Learn)
Defender for Containers
EKSを使っている場合は、Defender for Containersの前提条件を確認します。公式ドキュメントでは、Kubernetes APIサーバーにアクセスできるEKSクラスター、同一リージョン内にAmazon SQS、Kinesis Data Firehose、Amazon S3バケットを作成できることが要件として示されています。(GitHub)
2026年6月2日の公式リリース情報では、Kubernetesノードの脆弱性評価がEKSとGKEにも拡張され、Azure Kubernetes Serviceと同様の可視性に近づくことが示されています。この機能はKubernetesノードVMのOSレベル脆弱性を検出し、「Upgrade Kubernetes nodes」の推奨事項として修復を案内します。利用にはAWSまたはGCPがDefender for Cloudにオンボードされ、エージェントレススキャンが有効である必要があります。(Microsoft Learn)
EKS利用企業では、次を確認してください。
| 確認項目 | 見るべきポイント |
|---|---|
| EKSクラスターの登録状況 | Defender for Cloud側で対象EKSが検出されているか |
| エージェントレススキャン | 必要なスキャン設定が有効か |
| ノードグループ | 脆弱性推奨事項が出た場合にアップグレードできる運用設計か |
| 本番展開ルール | ノード更新時のPod退避、メンテナンスウィンドウ、影響範囲を整理しているか |
| コスト | 追加スキャン対象の増加により課金が変わる可能性を確認しているか |
「推奨事項が出たらすぐ更新」ではなく、EKSのバージョン、AMI、ノードグループ、Pod Disruption Budget、オートスケーリング設定まで含めて、更新手順を運用チームと合意しておくことが重要です。
Defender for SQL / Open-source databases
AWS上でSQL ServerをEC2またはRDS Custom for SQL Serverで運用している場合は、Defender for SQLの対象になります。公式ドキュメントでは、EC2インスタンスまたはRDS Custom for SQL Server、Azure Arc for servers、AWS SSM Agent、Defender for Endpoint、脆弱性評価ソリューション、Defender for SQL拡張機能などが要件として示されています。(Microsoft Learn)
また、AWS RDSのオープンソースリレーショナルデータベースについては、Defender for open-source relational databasesがAurora PostgreSQL、Aurora MySQL、PostgreSQL、MySQL、MariaDBなどのサポート対象エンジンに対して脅威保護とセキュリティ分析情報を提供します。2026年6月1日のリリースでは、AWS RDS向けMicrosoft Defender for Open-Source Relational Databasesが一般提供になり、プレビューでオンボード済みのAWS RDSインスタンスは課金対象へ移行することが示されています。(Microsoft Learn)
データベース管理者は、次を確認しましょう。
- 対象RDSが本当に保護対象に含まれているか
- プレビュー時代に有効化した設定が残っていないか
- 2026年7月以降の請求に影響が出る可能性があるか
- 本番・検証・開発環境を同じプランで扱うべきか
- 機密データ検出や脅威検出の運用担当が決まっているか
CloudFormationテンプレート更新が必要になる場面
AWSコネクタで最も見落としやすいのが、CloudFormationテンプレートです。最初に接続できたとしても、後からDefenderプランを追加したり、機能を有効・無効にしたり、リージョン設定を変えたりすると、AWS側の権限やリソースが現在の要件とずれることがあります。
公式ドキュメントでは、次のような場合にCloudFormationテンプレートを更新するとされています。(GitHub)
| 更新が必要になりやすい場面 | 具体例 |
|---|---|
| 新しいDefenderプランを有効化した | Defender CSPM、Defender for Databases、Defender for Containersを追加した |
| プラン構成を変更した | 自動プロビジョニングを有効化、対象リージョンを変更した |
| Microsoftが新しいテンプレートをリリースした | 新機能対応、バグ修正、ランタイム更新が入った |
| デプロイエラーが出た | AccessDenied、EntityAlreadyExists、Lambdaランタイムエラーなど |
更新時は、Defender for Cloudで最新テンプレートを生成またはダウンロードし、AWS CloudFormationで既存スタックを更新します。既存パラメーターは、Defender for Cloud側から新しい値が提示されない限り維持するのが基本です。
StackSet利用時の注意点
AWS管理アカウントに対してCloudFormation StackSetを実行する場合、You must enable organizations access to operate a service managed stack setというエラーが出ることがあります。これはAWS Organizationsの信頼されたアクセスが有効になっていないことを示します。公式ドキュメントでは、CloudFormation StackSetsページで信頼されたアクセスを有効にしてからテンプレートを再実行する手順が案内されています。(GitHub)
このエラーは、権限不足と誤解されがちです。IAMポリシーだけを見直しても解決しない場合があるため、AWS Organizations側の設定も確認してください。
S3バケットのSSL推奨事項に注意
CloudFormationテンプレートを「テンプレートファイルのアップロード」で展開すると、AWS側でテンプレート保存用のS3バケットが自動作成される場合があります。この構成では、S3 buckets should require requests to use Secure Socket Layerの推奨事項が出る可能性があります。公式ドキュメントでは、SSL以外の通信を拒否するバケットポリシーで修正できると説明されています。(GitHub)
本番環境では、自動作成バケットをそのままにせず、S3バケットポリシー、暗号化、ブロックパブリックアクセス、ライフサイクル、タグ付けを確認しておくと運用が安定します。
CloudTrailログ取り込みの影響
AWS CloudTrailログ取り込みは、Defender CSPMやCIEMを高度に活用したい環境で重要です。公式ドキュメントでは、Defender for CloudがAWS CloudTrailの管理イベントを収集し、ID操作、権限変更、制御プレーン上の活動に関する可視性を高めると説明されています。CloudTrail取り込みは、単一AWSアカウントと集中ログを利用するAWS Organizationsで利用できます。(Microsoft Learn)
CloudTrail取り込みを有効にすると、主に次の流れでデータが処理されます。
| 処理 | 内容 |
|---|---|
| CloudTrail | AWSアカウントの管理イベントを記録 |
| S3 | CloudTrailログファイルを保存 |
| SQS | 新しいログ配信を通知 |
| Defender for Cloud | SQSをポーリングし、ログ参照を取得 |
| CIEM / CSPM | ログテレメトリを使って権限リスクや構成情報を強化 |
既存のCloudTrail証跡を使う場合、S3バケットARNとSQSキューARNを指定します。必要に応じて、Defender for Cloudが提供するCloudFormation Stackのデプロイまたは更新が必要です。新しいCloudTrailを作成する場合は、CloudFormationまたはTerraformテンプレートを展開し、作成されたSQS ARNをDefender for Cloudに入力します。(Microsoft Learn)
90日分の履歴収集と再有効化に注意
既存のCloudTrail証跡を選択すると、Defender for Cloudは最大90日分のCloudTrail管理イベントを一度だけ収集します。CloudTrail取り込みを無効にすると、その履歴データは削除され、再度有効にすると新たな履歴収集が行われます。(Microsoft Learn)
運用上は、検証目的でオン・オフを繰り返すのは避けたほうが安全です。履歴データの扱い、検証環境と本番環境の分離、SOC側の分析ルールへの影響を整理してから有効化しましょう。
CloudTrailと外部SIEMのコスト影響
Defender CSPMは推奨事項の状態を表示するためにAWSリソースAPIを1日に複数回クエリします。読み取り専用API呼び出し自体に追加料金は発生しませんが、CloudTrailの読み取りイベント証跡を有効にしている場合はCloudTrailに記録されます。外部SIEMへエクスポートしている場合、ログ量増加により取り込みコストが増える可能性があります。公式ドキュメントでは、必要に応じてDefender for Cloudユーザーまたはarn:aws:iam::[accountId]:role/CspmMonitorAwsからの読み取り専用呼び出しをフィルターすることが推奨されています。(Microsoft Learn)
これは見落とされやすいポイントです。Defender側の料金だけを見ていると、AWS CloudTrail、S3、SQS、外部SIEM、ログ分析基盤側の費用増に気づきにくくなります。
Microsoft Sentinel接続済みAWSアカウントの注意点
すでにAWS CloudTrailログをMicrosoft Sentinelに送っている環境では、Defender for Cloudとの接続に注意が必要です。公式ドキュメントでは、Microsoft Sentinelに接続されているAWSアカウントは、そのままDefender for Cloudに接続できないため、専用手順に従う必要があると説明されています。(Microsoft Learn)
理由は、Amazon SQSキューが単一コンシューマーを前提にするためです。Microsoft SentinelとDefender for Cloudの両方がCloudTrailイベントを受け取るには、Amazon SNSを使ったfan-out構成を作り、両サービスが並行して通知を受け取れるようにします。(Microsoft Learn)
Sentinel連携済み環境での確認ポイント
| 確認項目 | 対応 |
|---|---|
| 既存のSentinel SQSキュー | どのS3バケット通知を受けているか確認する |
| SNSトピック | CloudTrail通知をfan-outする標準SNSトピックを作成する |
| Defender用SQSキュー | Defender for Cloudが参照するSQSキューを作成する |
| Sentinel用SQSポリシー | SNSトピックからのSQS:SendMessageを許可する |
| S3イベント通知 | S3から直接SQSではなくSNSへ通知する構成に変更する |
| Raw message delivery | SNSサブスクリプションで有効化する |
この作業を途中で止めると、Sentinel側のCloudTrail取り込みが止まる恐れがあります。SOCでMicrosoft Sentinelを運用している場合は、Defender for Cloud担当者だけで設定変更せず、検証時間帯・ロールバック手順・取り込み確認クエリを決めてから作業してください。
権限は「既定のアクセス」と「最小特権アクセス」から選ぶ
AWS接続時のアクセス許可は、既定のアクセスと最小特権アクセスから選択できます。公式ドキュメントでは、既定のアクセスは現在および将来の機能に必要なアクセス許可を付与し、最小特権アクセスは現時点で必要な権限のみを付与すると説明されています。最小特権を選んだ場合、後から追加アクセスが必要になった際に通知を受ける可能性があります。(GitHub)
選び方の目安は次の通りです。
| 権限タイプ | 向いている組織 | 注意点 |
|---|---|---|
| 既定のアクセス | 迅速に機能展開したい、Microsoft Defenderの新機能を積極的に使いたい | 権限レビューで説明できるよう、IAMロールとポリシーを記録しておく |
| 最小特権アクセス | 権限統制が厳しい、金融・公共・大企業など | 後から機能追加時にテンプレート更新や権限追加が必要になりやすい |
セキュリティの原則としては最小特権が望ましい一方、Defender for Cloudは新機能追加やプレビュー機能の拡張が多いサービスです。組織のリスク許容度に応じて、「本番は最小特権、検証は既定のアクセス」といった分け方も現実的です。
展開方法はCloudFormationとTerraformを使い分ける
AWS側への依存リソース展開には、CloudFormationとTerraformが利用できます。公式ドキュメントでは、AWS CloudFormationまたはTerraformを選び、画面の指示に従ってAWS側の依存関係を完了するとされています。ただし、管理アカウントを選択した場合、UI上ではTerraformオンボードのタブが表示されない一方、Terraformオンボード自体は引き続きサポートされています。(GitHub)
実務では、次のように選ぶと分かりやすいです。
| 展開方法 | 向いているケース | 注意点 |
|---|---|---|
| CloudFormation | AWS標準の変更管理に合わせたい、手早く公式テンプレートで展開したい | StackSet、IAM変更、S3バケット設定を確認する |
| Terraform | 既存のIaC管理に統合したい、レビュー・承認・差分管理を徹底したい | UI上の案内とTerraform運用の差分をチームで把握する |
| S3 URL指定 | テンプレート保存用S3のセキュリティ設定を自社管理したい | バケットポリシー、暗号化、アクセス制御を明示的に管理する |
| テンプレートファイルアップロード | 手軽に展開したい | 自動作成S3バケットに推奨事項が出る可能性がある |
本番環境では、ポータル操作だけで終わらせず、CloudFormation StackやTerraform stateをどのリポジトリ・どの変更管理フローで扱うかまで決めておくべきです。
接続後に必ず確認すること
AWSアカウントを接続したら、数時間後にセキュリティ推奨事項が表示されると説明されています。ただし、表示されたから完了ではありません。接続後は、コネクタの正常性、カバレッジ、推奨事項、アラート、ログ取り込みを確認します。公式ドキュメントでは、Defender for CloudのEnvironment settingsでAWSアカウントを探し、Connectivity status列を確認し、問題があれば詳細画面で構成や権限の問題、推奨される修復手順を確認できるとされています。(Microsoft Learn)
接続後チェックリスト
| チェック | 確認内容 |
|---|---|
| Connectivity status | AWSコネクタがHealthyか、権限エラーがないか |
| Resource inventory | 期待したAWSリソースが検出されているか |
| Coverage workbook | 有効化したDefenderプランが対象リソースに適用されているか |
| Security recommendations | 新しい推奨事項が出ているか、重大度と所有者を確認したか |
| Alerts | 既存のSOC運用に通知・調査フローを組み込んだか |
| CloudFormation Stack | UPDATE_COMPLETEなど正常状態か |
| IAMロール | 監視ロール、OIDCプロバイダー、信頼ポリシーが期待通りか |
| CloudTrail / SQS | CloudTrail取り込みを使う場合、S3・SQS・KMS権限が正しいか |
カバレッジ確認には、Defender for CloudのCoverage workbookが役立ちます。どのサブスクリプションやリソースでどのプランが有効かを確認できるため、「有効化したつもりだが一部リソースが対象外」という状態を見つけやすくなります。(Microsoft Learn)
管理者・開発者が失敗しやすいポイント
AWS接続は一度成功すると安心しがちですが、運用フェーズで問題が出ることが少なくありません。特に以下の失敗はよく起きます。
接続アカウントを間違える
AWS Organizations環境で、委任管理者アカウントからオンボードしようとして失敗するケースです。管理アカウントオンボードではAWS管理アカウントを使う必要があります。接続前に、AWS Organizationsの管理アカウント、セキュリティアカウント、ログアーカイブアカウントの役割を整理してください。
プラン追加後にCloudFormationを更新しない
Defender CSPMやDefender for Containersを後から有効化したのに、AWS側テンプレートを更新していないケースです。結果として、推奨事項が出ない、スキャンが不完全、権限エラーが出るといった問題につながります。
EC2保護でSSM AgentやArc要件を見落とす
Defender for Serversでは、EC2にAzure ArcやSSM Agentが関係します。AWS側のサーバー管理とAzure側のセキュリティ管理が別チームの場合、責任分界が曖昧になりがちです。EC2保護を有効化する前に、SSM Agent、IAMインスタンスプロファイル、アウトバウンド通信、Arc登録状況を一覧化しましょう。
CloudTrail連携でSentinel取り込みを止めてしまう
Microsoft Sentinelが既にCloudTrailログを取り込んでいる環境で、S3通知やSQS構成を変更すると、SOCの監視が止まる恐れがあります。SNS fan-outを設計し、Sentinel用SQSとDefender用SQSの両方に通知が届くことを確認してから切り替える必要があります。
コスト影響をDefender側だけで見積もる
Defenderプランの料金だけでなく、CloudTrail、S3、SQS、Kinesis Data Firehose、外部SIEM、ログ分析基盤、追加スキャン対象の増加も確認が必要です。特にEKSやRDSを広く使っている環境では、対象リソース数が増えるほど影響が大きくなります。
既存環境で今すぐ確認すべき実務アクション
既にAWSアカウントをDefender for Cloudへ接続している場合は、次の順番で確認すると効率的です。
| 優先度 | 作業 | 担当の目安 |
|---|---|---|
| 高 | Environment settingsでAWSコネクタのConnectivity statusを確認 | Azure / セキュリティ管理者 |
| 高 | 有効なDefenderプランとAWSリソースのカバレッジを確認 | セキュリティ管理者 |
| 高 | CloudFormation Stackが最新要件に合っているか確認 | AWS管理者 |
| 高 | Microsoft Sentinel接続済みAWSアカウントの有無を確認 | SOC / SIEM担当 |
| 中 | EC2のSSM Agent、Azure Arc、Defender for Endpoint状態を確認 | サーバー管理者 |
| 中 | EKSのノード脆弱性評価、エージェントレススキャン設定を確認 | Kubernetes基盤担当 |
| 中 | RDS保護と課金対象の変化を確認 | DB管理者 / FinOps |
| 中 | CloudTrailログ取り込みと外部SIEMコストを確認 | SOC / FinOps |
| 低 | コネクタ名、タグ、リソースグループ、運用ドキュメントを整理 | 運用管理者 |
新規導入の場合は、いきなり本番AWS Organizations全体を接続するのではなく、代表的な単一アカウントで検証し、推奨事項、アラート、コスト、ログ量、CloudFormation差分を確認してから管理アカウント接続へ進むのが安全です。
まとめ：AWS接続は「つなぐ作業」ではなく継続的な設定管理
Microsoft Defender for CloudのAWSアカウント接続は、AWSリソースをMicrosoft Defenderの管理下に入れ、マルチクラウドのセキュリティ態勢を一元化するための重要な設定です。ただし、実務上のポイントは接続手順そのものよりも、接続後の権限、プラン、テンプレート、ログ、コスト、運用責任を継続的に管理することにあります。
管理者はまず、AWSコネクタの正常性、現在有効なDefenderプラン、CloudFormationテンプレート更新要否、Sentinelや外部SIEMとのCloudTrail連携、EC2・EKS・RDSごとの前提条件を確認してください。開発者や基盤チームは、EKSノード更新、EC2のArc登録、RDS保護、IaC管理への組み込みを運用フローに落とし込むことが重要です。
次に取るべき行動は明確です。Defender for CloudのEnvironment settingsでAWSコネクタの状態を確認し、現在有効なプランとAWS側CloudFormation Stackの差分を点検することです。そのうえで、CloudTrail取り込み、CIEM、EKS脆弱性評価、RDS保護など、必要な機能を段階的に有効化していきましょう。
コメント