CredentialとSecret管理

1. 長期AWS認証情報を保持する前に一時的な認証情報を評価する

AWS APIへアクセスするワークロードでは、長期アクセスキーをシークレット保管先へ移す前に、IAMロールなどで一時的な認証情報へ置き換えられるかを確認します。

AWSワークロード
↓
一時的な認証情報で代替可能？
├─ はい → 長期アクセスキーを保持しない
└─ いいえ → 例外としてライフサイクル管理

ここで重要なのはロールの仕組みを再確認することではなく、管理対象認証情報そのものを減らした状態からライフサイクル設計を開始することです。

2. 保管先選択の後にライフサイクルが本当に成立するかを見る

設定とシークレットでは、保存先を選ぶだけでなく、その後のライフサイクル要件まで確認します。

SecureStringで暗号化できることと、認証情報のローテーションワークフローを持つことは同じではありません。

3. ハードコードされた認証情報をアプリケーションアーティファクトから分離する

ソースコード、コンテナイメージ、AMI、ビルドアーティファクトへ認証情報を固定すると、認証情報のライフサイクルがリリースのライフサイクルへ結合します。

避けるソースコード / イメージ / アーティファクト
└─ 固定シークレット評価するアーティファクト
└─ シークレットを保持しない
        ↓
実行時
        ↓
認証されたワークロード
        ↓
シークレット保管先

新しい認証情報へ切り替えるために毎回ソースコード変更やイメージのビルドが必要な設計は、ローテーションを難しくします。

4. 実行時受け渡し方式がローテーションへの追従方法を決める

シークレット保管先と連携しているだけでは、アプリケーションが常に現在の認証情報を使うとは限りません。

5. ローテーションはシークレット保管先の値変更だけではない

データベースパスワードなどでは、シークレット保管先だけが新値になっても対象システムが旧値なら認証は失敗します。

新しい認証情報を準備
        ↓
対象システムへ反映
        ↓
新しい認証情報を検証
        ↓
現在へ切替
        ↓
利用側が新認証情報を取得
        ↓
古い認証情報を失効

つまり、ローテーションはシークレット保管先 + 対象システム + 利用側の3者で成立させます。

6. シークレットのバージョン切り替えを切替手順として理解する

Secrets ManagerのLambda関数によるローテーションでは、候補バージョンを準備して検証した後に現在へ昇格する切り替えがあります。

AWSCURRENT
    ↓
AWSPENDINGを準備
    ↓
対象へ反映・テスト
    ↓
新バージョンをAWSCURRENTへ
    ↓
旧バージョンはAWSPREVIOUSへ

重要なのはラベル名だけではなく、未検証の認証情報をいきなり現在へ置き換えず、準備・反映・検証・切替を分離することです。

7. ローテーション方式は対象認証情報の現行仕様から選ぶ

Secrets Managerへ保存できることと、その認証情報を自動ローテーションできることは別です。

認証情報/ 提供側
        ↓
現在で利用可能なローテーション方式は？
        ↓
必要権限/ 接続
        ↓
対象の更新可能？
        ↓
利用側の更新可能？

マネージドローテーション、外部提供側とのマネージドローテーション、Lambda関数によるローテーションなど、利用できる方式は対象シークレットによって異なります。方式名を固定暗記せず、現在のサービス機能を確認します。

8. パラメータポリシーは認証情報のローテーションエンジンではない

Parameter StoreのAdvanced Parameterのポリシーでは、期限や変更されていないパラメータに対する通知を設定できます。

有効期限
ExpirationNotification
NoChangeNotification
        ↓
ライフサイクル監視には使える
        ↓
対象データベース / API側の認証情報を変更する処理ではない

要件が対象認証情報の自動更新まで含むなら、パラメータポリシーだけで完了とは判断しません。

9. ECS 環境変数注入はローテーションへ自動追従しない

ECS タスク起動時にSecrets Managerの値を環境変数へ注入した場合、その時点の値がコンテナへ渡されます。

タスク起動
↓
シークレット取得
↓
環境変数その後シークレットローテーション
↓
既存タスクの値はそのまま

新認証情報へ追従させるには、新タスクの起動や新しいデプロイの強制、または要件に応じて実行時取得方式を評価します。

10. キャッシュ戦略は認証情報の鮮度と一緒に決める

実行時取得でも、毎リクエストでシークレット保管先へ問い合わせる必要はありません。キャッシュを使うことでレイテンシー、API 呼び出し、コストを抑えられます。

一方で、ローテーション後10分以内に切り替える要件があるのにキャッシュTTLが1時間なら不適合です。

ローテーション頻度
+
必要な更新時間
+
キャッシュTTL
        ↓
利用側の鮮度成立？

11. ローテーション中の可用性を先に決める

認証情報切替の瞬間に認証失敗を許容できるかで、ローテーション戦略が変わります。

ローテーション中も停止不可？
├─ はい → 古い / 新しいの切替期間や利用側の更新を含めて設計
└─ いいえ → 許容停止時間内で単純な切替も候補

データベースシークレットではシングルユーザー / 交代ユーザーなどの方式が候補になることがありますが、方式名より認証可用性要件を先に確認します。

12. シークレット取得権限もライフサイクルへ含める

中央管理したシークレットをすべてのアプリケーションが取得できる設計では、保管先を選んでも最小権限になりません。

アプリケーションA → シークレットA
アプリケーションB → シークレットB

認証情報の保存場所とは別に、どのワークロードアイデンティティがどのシークレットを取得できるかを制限します。

13. ライフサイクルは失効 / 削除まで閉じる

認証情報のライフサイクルはローテーションで終わりません。

作成
↓
取得
↓
利用
↓
ローテーション
↓
失効
↓
削除

新規アーキテクチャではワークロード廃止と認証情報廃止を関連付け、不要になったデータベースユーザー、APIキー、シークレット、取得権限を残さないライフサイクルを設計します。

14. 候補比較

15. 判断フロー

認証情報要件
        ↓
長期AWS認証情報をなくせる？
        ↓
保持が必要なシークレットだけを対象化
        ↓
アーティファクトへ固定していない？
        ↓
実行時受け渡し方式を決定
        ↓
ローテーション方式は対象に対応？
        ↓
保留中の認証情報準備
        ↓
対象更新・検証
        ↓
現在切替
        ↓
利用側の更新 / キャッシュ整合
        ↓
ローテーション中可用性成立？
        ↓
不要時失効 / 削除
        ↓
認証情報のライフサイクル成立

16. 混同ポイント

まとめ

認証情報を安全に保存
        ↓
だけでは不十分保持を減らす
↓
実行時受け渡し
↓
ローテーション
↓
対象の更新
↓
利用側の更新
↓
失効 / 削除
↓
認証情報のライフサイクル完成

Secrets ManagerやParameter Storeは目的ではなく、要件を満たすための制御です。最も重要なのは、認証情報の変更がシークレット保管先、対象システム、利用側の間で矛盾なく成立することです。

主要AWS公式資料

• AWS IAM — IAMのセキュリティベストプラクティス
• AWS Secrets Manager — AWS Secrets Managerのシークレットをローテーションする
• AWS Secrets Manager — Lambda関数によるローテーション
• AWS Secrets Manager — ベストプラクティス
• AWS Systems Manager — Parameter Store / パラメータポリシー
• Amazon ECS — Secrets Managerのシークレットを環境変数で渡す