大手エンタープライズ企業が AWS Organizations を使用して 150 の AWS アカウントを管理しています。組織は複数の OU（Organizational Unit：組織単位）階層に分かれており、開発・ステージング・本番・セキュリティ・共有サービスの各 OU が存在します。セキュリティチームは年次監査の結果、以下の問題を特定しました。 【現状の問題】 1. Amazon GuardDuty が有効化されているアカウントは全体の 60% のみ（中央集権的な強制なし） 2. AWS Security Hub は 40 アカウントからの検出結果のみ集約しており、残り 110 アカウントが未カバー 3. ほぼすべてのアカウントにプログラムアクセスキーを持つ IAM ユーザーが存在し、一部のキーは 180 日以上ローテーションされていない 4. CloudTrail の設定がアカウントごとに異なる（S3 バケットの MFA 削除無効化、保持期間のばらつき等） 5. 開発アカウントの EC2 インスタンスに、ポート 22・3389 への全インターネット公開（0.0.0.0/0）セキュリティグループルールが存在 6. セキュリティチームが週次で手動レビューしており、自動修復の仕組みが存在しない 【新要件】 ・GuardDuty と Security Hub を全 150 アカウント（将来追加されるアカウントも含む）で自動的に有効化 ・開発アカウントの EC2 パブリックセキュリティグループルールを自動検出・自動修復 ・IAM アクセスキーのローテーションポリシーを強制（90 日超のキーを自動で無効化） ・統合されたセキュリティ態勢ダッシュボードの提供 ・新規アカウントが組織に参加した際に手動作業なしで上記が適用されること 上記すべての要件を最も包括的に満たすソリューションはどれですか？
GuardDuty・Security Hub の Organizations レベル委任管理者設定は新規アカウント参加時に自動有効化されるネイティブ機能であり、手動作業ゼロを実現します。Control Tower の Account Factory は新規アカウントのベースラインを保証し、Organizational Config Rules + SSM Automation により検出から自動修復まで一元管理できます。 選択肢BのCloudFormation StackSets は Organizations の Service Managed 権限で新規アカウントへの自動デプロイが可能ですが、GuardDuty・Security Hub の Organizations ネイティブ自動有効化と比べて設定が複雑であり、さらに Lambda によるチェックはアラート送信のみで自動修復が実装されていないため要件を満たしません。 選択肢CのGuardDuty 手動構成は 150 アカウント規模では非現実的で新規アカウント追加のたびに手動対応が残ります。 選択肢DのEventBridge + Lambda 方式はネイティブの自動有効化より信頼性が劣り、IAM キー無効化の自動修復も実装されていません。