Secrets ManagerとParameter Storeのシナリオ判断

この単元で学ぶこと

• 保管型と更新要件から構成を評価する
• 取得失敗の権限・通信・キャッシュ原因を切り分ける
• 候補版から本番版への切替条件を判断する

本文解説

1. 設定を分類する アプリの環境名、接続先URL、DBパスワードを一つの設定ファイルで配っているとします。環境名等の非秘密設定とパスワードを分け、Parameter Storeを使うなら秘密はSecureStringで保管します。暗号化型を選ぶことと、そのパスワードを周期的に変えることは別の要件です。

2. 定期変更を具体化する 「毎月更新する」が必要なら、新値の作成、DBへの反映、接続テスト、アプリの新値取得までを定義します。Secrets Managerの対応方式で自動化できますが、保存先を移しただけでは更新されません。Parameter Storeの変更なし通知は運用への通知に使えますが、DB更新そのものの代わりにはなりません。

3. 取得APIが拒否される場合 アプリが秘密取得でAccessDeniedになる場合、どのAPIで拒否されたかを確認します。サービスの取得権限があるか、カスタマー管理キー利用時に必要なKMS許可があるかを別に調べます。暗号化されているから誰でも取得を許す、あるいはDecryptだけで取得を許せるという設計は避けます。

4. 関数がDBへ届かない場合 ローテーション関数にIAM権限があっても、VPC内DBへの経路やセキュリティグループが適切でなければ更新や試験が失敗します。秘密値を公開する回避策を取らず、必要なAPIとDBへの到達性を確認します。権限のエラーと接続タイムアウトを分けると調査が進みます。

5. 候補だけが残る失敗 Lambda方式のcreateSecretが成功しても、setSecretでDBを変更できなければ、保管した候補だけが残る場合があります。AWSPENDINGを本番値だとみなしてアプリへ配布せず、更新がどこまで進んだか確認します。testSecretで候補による接続が成功することを確かめてからfinishSecretへ進みます。

6. アプリが古い値を使う場合 DB更新とAWSCURRENT切替が成功しても、アプリが古い値をメモリに保持していれば認証エラーになります。キャッシュの更新や再取得を実装し、再試行が無制限に増えないようにします。新値をログへ出すことは調査を楽に見せても秘密の露出を増やすので、版や操作の情報で調べます。

7. ロールバックは両側を見る 以前の秘密版へラベルを戻すだけで、DBの認証情報が元へ戻るわけではありません。現在DBが受け付ける値、保管版、アプリの保持値を照合して復旧します。AWSPREVIOUSが存在することは、以前の値でどの時点でも必ずログインできる保証ではありません。

8. 更新後の受入確認 対象アプリの新値での接続成功と、不要な主体による秘密取得の拒否を確認します。Parameter StoreのExpirationを使う場合はパラメータ削除の影響も考え、DB側の値が勝手に変わる前提にしません。更新処理の記録には秘密本文を残さず、候補作成・対象更新・試験・切替の結果を追えるようにします。

図解

重要ポイント

• 設定移行だけでは認証情報更新は始まらない。
• 保管サービス・DB・キャッシュの三者を照合する。
• 秘密値を出さず版と工程で障害を追う。

間違えやすい点

• AWSPENDINGを無条件にアプリへ渡す。
• AWSPREVIOUSに戻すだけでDBも戻ったと判断する。

用語解説

キャッシュ

取得した値を一定期間アプリ側に保持して再利用する仕組み。

AWSPREVIOUS

直前の版に付くラベル。対象DBの状態を戻す機能ではない。

整合

保管値と認証先が受け付ける値、アプリの利用値が対応している状態。

関連教材

• Secrets ManagerとParameter Storeを理解する
• ACMとTLS証明書のシナリオ判断