ある企業はdev・stg・prodの3環境を1つのAWSアカウント内で運用しており、EC2上のアプリケーションがSystems Manager Parameter StoreからデータベースパスワードやAPIキーを取得し

Question

ある企業はdev・stg・prodの3環境を1つのAWSアカウント内で運用しており、EC2上のアプリケーションがSystems Manager Parameter StoreからデータベースパスワードやAPIキーを取得しています。以下の要件を同時に満たす最もベストプラクティスに沿った設計はどれですか？
①環境を切り替える際にアプリケーションのコードや設定ファイルを変更しない。
②SecureStringパラメータにはカスタマーマネージドKMSキーを使用し、devチームのIAMユーザーがprodパラメータを復号できないようキーポリシーで制御する。

Accepted Answer

正解: 環境識別子を含む階層パス（例: /myapp/prod/db/password）でパラメータを構成し、アプリケーション起動時の環境変数（例: APP_ENV=prod）からパスプレフィックスを動的に構築する。SecureStringには環境ごとにカスタマーマネージドKMSキーを作成し、prodキーのキーポリシーでdevチームのアクセスを明示的に拒否する。階層パス設計（B）はAWSが推奨するParameter Storeのベストプラクティスです。/myapp/{env}/のパスプレフィックスを環境変数で注入することでコード変更ゼロで複数環境に対応できます。環境ごとのカスタマーマネージドKMSキーはキーポリシーとIAMポリシーの組み合わせで細粒度アクセス制御を実現します。

選択肢A（AWSマネージドキー）はキーポリシーで特定IAMユーザーを拒否できないため要件②を満たせません。

選択肢C（Secrets Manager への移行）はParameter Storeの階層化という基本機能を活用していません。

選択肢D（Parameter Store Advanced ティア + ポリシー）はParameter Storeの階層化という基本機能を活用していません。

Answer

すべての環境で同一パラメータ名（例: /app/db/password）を使用し、環境の切り替えはアプリケーション設定ファイルの書き換えで行う。暗号化にはAWSマネージドキー（aws/ssm）を使用してKMSキー管理コストを削減する — （AWSマネージドキー）はキーポリシーで特定IAMユーザーを拒否できないため要件②を満たせません。

Answer

Parameter Storeの利用を廃止してAWS Secrets Managerに移行し、環境ごとに異なるシークレット名（例: prod/myapp/db/password）を作成する。アプリケーションはSECRET_ARN環境変数を参照することで環境差異を吸収する — （Secrets Manager への移行）はParameter Storeの階層化という基本機能を活用していません。

Answer

Parameter StoreのAdvancedティアを使用してパラメータポリシー（有効期限・変更通知）を全パラメータに設定し、環境識別子はDescriptionフィールドに記載して管理台帳代わりに使用する — （Parameter Store Advanced ティア + ポリシー）はParameter Storeの階層化という基本機能を活用していません。

解説

解説