Secrets ManagerとParameter Storeを理解する

設定値の保管と秘密情報のローテーションを区別し、アプリ・保管サービス・DBの三者で値を整合させる設計を学びます。

この単元で学ぶこと

Parameter Storeの型と秘密管理の要件を区別する
秘密取得の権限とキャッシュを設計する
Lambda方式ローテーションの段階と対象更新を説明する

本文解説

1. 設定と秘密の違い設定値には環境名やAPIのURLのような非秘密情報と、DBパスワードのような秘密情報があります。Parameter Storeは階層名で設定を整理でき、String・StringList・SecureStringを扱います。秘密をKMSで暗号化して保管する型はSecureStringです。全ての型が同じ暗号化特性だと考えないようにします。

2. 保管と更新の要件 Parameter Storeにも秘密値を保管できますが、SecureStringへ入れるだけでDBパスワードが自動更新されるわけではありません。認証情報の周期的変更と対象DBへの反映を管理したい場合はSecrets Managerのローテーション機能を検討します。サービス管理の方式とLambdaによる方式があり、対象サービスに合わせて選びます。

3. 取得権限を限定するアプリは必要な秘密だけをAPIから取得します。秘密管理サービスの取得権限と、カスタマー管理キー利用時のKMS権限を確認します。kms:Decryptだけでサービス側のAPI許可になるわけではありません。ロールで取得し、平文をソースやログに残さない設計にします。

4. キャッシュの利点と期限秘密を毎回取りに行く代わりに適切にキャッシュすると、呼出し回数や待ち時間を減らせます。ただし値が変わってもアプリのメモリは必ず即時更新されるわけではありません。再取得の周期や認証失敗時の更新を設計し、古い値を無期限に使わないようにします。

5. Lambda方式の候補作成ここからはLambdaでDB認証情報を回転する方式を扱います。createSecretで新しい候補をAWSPENDINGとして用意し、再試行で同じ処理を重ねても壊れないようにします。AWSCURRENTは通常の取得で使う現在の版です。候補を保存しただけでDBが変更されたとは判断しません。

6. 対象を更新して試す setSecretは対象DBやサービスへ新しい認証情報を設定し、testSecretはその候補で実際にアクセスできるか試します。関数は正しい対象と利用者を確認して更新し、DBへの通信経路・セキュリティグループ・必要な権限も用意します。IAMの許可はネットワーク到達性の代用にはなりません。

7. 本番版への切替テスト後のfinishSecretで新しい版へAWSCURRENTを移し、前の版にはAWSPREVIOUSが付きます。以前の版が残っていても、その版を選ぶだけでDBの状態が元に戻るわけではありません。失敗時は保管値と対象の状態、アプリの接続状況を調べ、整合するよう復旧します。

8. パラメータポリシーの境界 Parameter Storeの高度なパラメータには期限削除や変更がないことの通知などのポリシーがあります。Expirationはパラメータの期限管理、NoChangeNotificationは変更がないことの通知であり、DB認証情報の更新を実装するものではありません。通知を受ける運用と自動更新の仕組みを分けて設計します。

図解

DBパスワード更新の四段階 — 保管サービスの値とDBの値が整合していることを、切替前に確かめます。

重要ポイント

SecureStringの保管とDB認証情報の更新は別。
取得許可・KMS許可・ネットワークを別に確認する。
候補作成→対象更新→テスト→本番切替の順で整合を保つ。

間違えやすい点

保存値を変えると接続先DBも自動で同じ値になると思う。
期限通知をパスワード更新と取り違える。

用語解説

SecureString: Parameter StoreでKMSにより暗号化して保管するパラメータ型。
AWSCURRENT: Secrets Managerで現在利用する版を示すステージラベル。
AWSPENDING: ローテーションで準備している候補版に付けるラベル。
ローテーション: 秘密値とその利用先の認証情報を計画的に更新すること。

参考資料

教材データに登録された参考リンクです。リンク先の内容や更新日は提供元でご確認ください。

確認問題の出題・採点や学習履歴の保存にはログインが必要です。