あるSaaS企業が、Amazon ECS（Fargateタイプ）上で動作するマイクロサービスから外部決済APIへのアクセスに使用するAPIキーを管理しています。 セキュリティ方針として以下が定められています。 ・APIキーは90日ごとに自動ローテーションされること ・ローテーション中もECSタスクの停止・再起動なしに新旧キーの切り替えを行えること ・APIキーがコードやコンテナイメージに埋め込まれないこと これら3要件をすべて満たすアーキテクチャはどれですか？
AWS Secrets Managerは外部APIキーの自動ローテーションを含む包括的なシークレット管理機能を提供します。Lambdaローテーション関数を使用して90日ごとに外部決済プロバイダーのAPIキーを自動更新し、AWSCURRENT・AWSPENDING・AWPREVIOUSのステージングラベルによるバージョン管理によってローテーション中も旧キーへのフォールバックが可能なためダウンタイムがありません。ECSタスク定義のsecretsフィールドにSecrets ManagerのARNを指定することでAPIキーをコードやイメージに埋め込まずに安全に注入でき、アプリケーションが実行時にAWS SDK経由でAWSCURRENTを取得する構成にすることでタスク再起動なしの切り替えも実現できます。 選択肢BのECSタスク定義の環境変数方式はAPIキーをタスク定義のコンテナ設定に平文で記録するため「コードへの埋め込み禁止」要件に違反します。またローテーションのたびにECSサービスの再デプロイが必要になり「停止なし」の要件も満たせません。 選択肢CのSSM Parameter StoreはSecureStringで安全な保存が可能ですが、外部APIキーの自動ローテーション機能がなく、AWSCURRENT/AWPREVIOUSのようなステージングラベルによるゼロダウンタイム切り替えも実現できないため、要件を完全には満たしません。 選択肢DのKMS+S3による独自実装は暗号化保存自体は可能ですが、自動ローテーション・ゼロダウンタイム切り替え・ECSへの安全な注入をすべてアプリケーション側で実装する必要があり、Secrets Managerのマネージド機能と比較して運用コストと実装リスクが著しく高くなります。