グローバルな金融サービス企業は、AWS Organizations を使用して 250 の AWS アカウントを管理しています。OU 構造は Root > Corporate OU > Production OU（180 アカウント）および Sandbox OU（70 アカウント）です。セキュリティチームは以下の要件を実装する必要があります。 ① Production OU 内のすべてのアカウントにある ALB および CloudFront ディストリビューションに対して、AWS マネージドルールグループ（Core Rule Set、Known Bad Inputs）を含む標準 WAF WebACL を強制適用する ② 各アカウントのチームは自社アプリケーション固有の WAF ルールを追加できるが、標準マネージドルールグループを無効化・削除することはできない ③ Production OU に新規アカウントが追加されたとき、WAF ポリシーを自動的に適用する ④ すべてのアカウントで SSH（ポート 22）および RDP（ポート 3389）への 0.0.0.0/0 のインバウンドアクセスを許可するセキュリティグループルールを自動的に検出し修復する ⑤ WAF・セキュリティグループポリシーの管理は、管理アカウントではなく専用の「Security-Ops」アカウント（Corporate OU 内）から行う ⑥ すべてのアカウントのポリシー準拠状態を単一のダッシュボードで確認できる これらの要件を最小の運用オーバーヘッドで満たす実装として、最も適切なものはどれですか？
AWS Firewall Manager は Organizations と統合した WAF・セキュリティグループポリシーの一元強制に最適なサービスです。委任管理者として Security-Ops アカウントを指定することで管理アカウント分離を実現します。WAF ポリシーでは「強制ルール（First rule group）」にマネージドルールグループを配置し、チームの追加ルール枠を確保することで要件②を満たします。「新規アカウントを自動含める」オプションが要件③に対応し、セキュリティグループ コンテンツ監査ポリシーの自動修復が要件④を担います。 選択肢BのFirewall Manager には委任管理者機能が存在し、クロスアカウント IAM ロールで間接管理する構成は不正規です。また SNS アラートによる通知は手動対応を前提とした検知にとどまり、自動修復を満たしません。 選択肢CのStackSets はリソースの初期デプロイには適していますが、継続的なポリシー強制を自動で行う機能がありません。EventBridge + Lambda による新規アカウント対応は実装・維持コストが高く、最小運用オーバーヘッドの要件を満たしません。 選択肢DのSecurity Hub は脅威の可視化・集約には優れますが、WAF ポリシーの強制適用や WebACL の自動関連付けは行えません。