SAP-C02-113 · セクション 13 / タスク 3.2
Secret / Credential Managementを改善する
AWS Secrets Manager / Systems Manager Parameter Store / Hard-coded Credential / Rotation / Temporary Credential / Access Control / Credential Lifecycle
Secrets Manager、Parameter Store、一時的な認証情報、ローテーションなどの基本的な役割は既習です。
既存環境を改善するときに重要なのは、それらをもう一度選び直すことではありません。
現在の環境には、
誰が使っているか分からない認証情報
コードへ埋め込まれた認証情報
新しい取得経路へ移行済みだが
まだ有効な旧認証情報
不要になった長期アクセスキー
全利用者から参照できるシークレットなどが残っている可能性があります。
ここでは、
現在状態を把握
↓
認証情報ごとの改善方針を決定
↓
利用者を安全に新方式へ移行
↓
正常性を確認
↓
旧認証経路を停止
↓
不要な認証情報と権限を削除という、既存環境を安全に改善完了まで持っていく手順を扱います。
ゴール
既存環境について、
- 認証情報と利用者の依存関係を把握する
- 認証情報ごとに「廃止・移行・継続管理」を判断する
- ハードコードされた認証情報を安全に移行する
- 長期AWS認証情報を削減する
- Secrets ManagerやParameter Storeへの移行を段階的に実施する
- シークレット取得権限を移行後の必要範囲へ合わせる
- ローテーション時の利用側への影響を管理する
- 旧認証情報・旧取得経路を確実に失効する
- 認証情報のライフサイクルを最後まで閉じる
ことを目指します。
1. 最初に認証情報と利用者の関係を把握する
既存環境では、
この認証情報を
誰が使っているのか分からないという状態が最も移行を難しくします。
認証情報ごとに、
どこに存在するか
誰が所有しているか
どのアプリケーションが使うか
どの処理から参照されるか
変更すると何が影響するか
現在も使われているかを整理します。
例えば、
DB認証情報
├─ ウェブアプリ
├─ 夜間バッチ
├─ 管理ツール
└─ レガシー処理という共有関係があるなら、ウェブアプリだけを新しい取得方式へ移して、すぐ旧認証情報を無効化することはできません。
まず、認証情報 → 利用者の依存関係を明らかにします。
2. 認証情報ごとに「今後どうするか」を決める
棚卸し後は、すべてを同じサービスへ移動するのではなく、認証情報ごとの最終状態を決めます。
| 現在状態 | 改善後の方向 |
|---|---|
| EC2から利用している長期AWSアクセスキー | IAMロールなどへ移行し、長期認証情報を廃止 |
| ハードコードされたDBパスワード | 管理対象シークレットへ移行 |
| ローテーションが必要なシークレット | Secrets Managerなどで管理 |
| 静的な設定値 | Parameter Storeなどへ分離 |
| 不要になった認証情報 | 利用確認後に失効・削除 |
| 過剰な取得権限 | 必要な認証情報だけ取得できる状態へ変更 |
ここで重要なのは、
どこへ保存するかだけではありません。
将来その認証情報を
存在させ続ける必要があるかから判断します。
3. 移行前に「完了状態」を決める
既存環境の改善では、変更を始める前に認証情報ごとの完了条件を決めます。
例えば、
現在
コード内のDBパスワード
目標
Secrets Managerから実行時取得
利用者
ウェブ / バッチ
完了条件
ウェブ / バッチとも新方式で正常動作
旧パスワードの利用なし
旧パスワード失効
コード・古い設定から削除という形です。
最低限、
現在状態
目標状態
利用者
切替方法
確認方法
旧認証情報の停止条件を明確にします。
これがないと、
新しい仕組みを追加した
↓
旧経路も残ったという状態になりやすくなります。
4. ハードコードされた認証情報は段階的に移行する
既にコードや設定ファイルへ認証情報が埋め込まれている場合、単にSecrets Managerへ同じ値を登録しても移行は完了しません。
また、同じ設定ファイルに、
固定のサービスエンドポイント
+
DBパスワードのように、通常の設定値と認証情報が混在している場合があります。
この場合は値の性質を分けて、
静的な設定値
→ Parameter Storeなどへ分離
認証情報
→ 管理対象シークレットへ分離します。
そのうえで、
現在の利用者を確認
↓
新しい取得先を準備
↓
利用側を新方式へ変更
↓
全利用者の切替を確認
↓
露出していた認証情報をローテーション
↓
旧値を無効化
↓
古い設定や成果物を整理と進めます。
古い値は、現在のソースコードだけでなく、
以前のビルド成果物
コンテナイメージ
デプロイ用ファイル
古い設定ファイルなどに残っている可能性もあります。
重要なのは、新しい保管場所を作ることではなく、以前の取得経路と露出した値を利用できない状態へ変えることです。
5. 長期AWS認証情報は「移動」ではなく「廃止」を目標にできる場合がある
例えばEC2上のアプリケーションが長期アクセスキーを使っている場合、
設定ファイル
↓
Secrets Managerと保存場所だけ変更しても、長期アクセスキー自体は残ります。
IAMロールなどへ移行可能なら、
新しい認証経路を準備
↓
アプリケーションを切替
↓
新経路で正常動作を確認
↓
旧アクセスキーが
実際に使われていないことを確認
↓
旧アクセスキーを無効化
↓
一定期間問題がないことを確認
↓
削除まで進めます。
一時的な認証情報の仕組みそのものは前提知識です。
ここでは、既存の長期認証情報をどの順序で安全に撤去するかを判断します。
6. 共有認証情報では利用者ごとの切替状況を管理する
1つの認証情報を複数のシステムが共有している場合があります。
例えば、
DB認証情報
├─ ウェブ
├─ バッチ
└─ 管理ツールを変更するとします。
ウェブだけ新方式へ切り替えた状態で旧認証情報を無効化すれば、バッチや管理ツールが停止する可能性があります。
そのため、
ウェブ 切替済み
バッチ 切替済み
管理ツール 未切替のように利用者単位で状態を確認します。
全利用者が新方式へ移行
↓
旧認証情報の利用なし
↓
旧認証情報を失効という終了条件を持たせます。
7. ローテーションでは利用側の影響も移行計画へ含める
ローテーション機能そのものは既習です。
既存環境では、
誰が利用しているか
どのタイミングで取得するか
キャッシュしているか
再起動などが必要かを移行前に把握します。
これはローテーションの仕組みを選ぶためではなく、認証情報変更によってどの利用者が影響を受けるかを移行計画へ反映するためです。
特にハードコードされていた認証情報では、
新しい取得方式へ全利用者を切替
↓
正常性を確認
↓
露出済みの旧値をローテーション
↓
旧値を利用不能化までを改善工程に含めます。
8. 中央管理後にアクセス経路を見直す
シークレットを中央管理した後、
全アプリケーション
→ 全シークレット取得可能のままでは改善が不十分です。
例えば、
アプリA
→ DB-Aだけ必要
アプリB
→ DB-Bだけ必要なら、移行後の状態もその依存関係に合わせます。
また、
値を利用する主体
と
作成・変更・ローテーションを
管理する主体を区別します。
IAM環境全体の最小権限設計ではなく、認証情報移行によって一時的に広げた取得経路や権限が、移行後も残っていないかを確認します。
9. 移行期間には終了条件を設定する
移行時には、一時的に新旧の認証経路が共存する場合があります。
例えば、
新方式
Secrets Manager
旧方式
設定ファイルを一定期間併用することがあります。
問題なのは共存そのものではなく、
いつ旧方式を止めるか
決まっていないことです。
移行計画には、
新方式の正常性確認
全利用者の切替確認
旧認証情報の利用確認
旧経路の停止日
問題発生時の戻し方を含めます。
10. ロールバック手段を「永久的な旧経路」にしない
安全な移行には、変更に問題があった場合の戻し方が必要です。
しかし、
念のため
旧アクセスキーを永続的に有効化しておくことは適切ではありません。
例えば、
移行
↓
検証期間
↓
問題なければ
旧認証情報を無効化
↓
一定期間問題なし
↓
削除のように、ロールバック可能期間にも終了条件を設けます。
11. 所有者不明の認証情報も放置しない
既存環境では、
誰のものか分からない
でも停止すると怖いという認証情報が残ることがあります。
この場合、
利用状況
呼び出し元
関連システム
運用担当などを調査して所有関係を明確にします。
目的は、
分からないから残すことではありません。
安全に停止できる条件を
明らかにすることです。
12. 改善完了は「新方式が動いた時点」ではない
例えば、
新しいIAMロールで正常動作
旧アクセスキーも有効なら、認証情報改善はまだ途中です。
同様に、
Secrets Managerから取得成功
旧ハードコード認証情報も有効でも完了ではありません。
また移行のため一時的に、
旧シークレット
新シークレット
両方への取得権限を付与した場合、その一時権限も改善後に残してはいけません。
改善完了の判断には、
新方式で正常動作
全利用者が切替済み
旧認証情報の利用なし
旧認証情報を失効
移行用の一時権限を削除
不要な保存場所を削除まで含めます。
13. 認証情報ごとのライフサイクルを閉じる
改善後も、
作った
↓
使っているだけでは管理できません。
認証情報ごとに、
所有者
利用者
現在の管理方式
変更方法
ローテーション条件
失効条件
削除条件を明確にします。
システムを廃止したら、
認証情報
取得権限
不要なシークレット
古い設定も合わせて終了させます。
14. 既存環境の改善パターン
長期AWSアクセスキー
↓
新しい認証経路へ段階的に切替
↓
旧キーの使用停止を確認
↓
無効化・削除ハードコードされたシークレット
↓
静的設定と認証情報を分離
↓
新しい取得方式へ全利用者を切替
↓
露出済み旧値をローテーション
↓
旧値を失効
↓
古い成果物も整理移行のため一時的に広げた権限
↓
切替完了後に縮小・削除これらは個々のAWSサービスの機能説明ではなく、現在の問題をどの終了状態へ持っていくかという改善パターンです。
15. 混同しやすいポイント
| 誤りやすい判断 | 正しい考え方 |
|---|---|
| 新しい管理サービスへ移せば完了 | 旧認証情報・旧経路の停止まで確認 |
| 長期認証情報を安全な場所へ移せば解決 | 可能なら長期認証情報自体の廃止まで進める |
| 新しい認証情報で動けば即座に旧値を削除 | 全利用者の切替を確認してから失効 |
| ハードコード値を保管先へ移せば完了 | 切替後に露出済み旧値をローテーションする |
| ロールバック用なので旧認証情報を永久保存 | ロールバック期間にも終了条件を設定 |
| 利用者不明なので変更しない | 依存関係を調査して安全な停止条件を作る |
| 移行用の広い権限は残してよい | 移行完了後は一時権限も削除する |
16. SAP-C02での判断手順
既存環境の認証情報問題では、
1. 問題のある認証情報は何か
↓
2. 誰が利用しているか
↓
3. 最終的に
廃止 / 移行 / 継続管理
のどれにするか
↓
4. 目標状態と
切替条件を決める
↓
5. 利用者を新方式へ移行
↓
6. 正常性と旧経路の利用状況を確認
↓
7. 必要なら露出済み旧値をローテーション
↓
8. 旧認証情報を失効
↓
9. 移行用の一時権限・保存場所を削除
↓
10. ライフサイクル管理へ移行試験では、
新しい仕組みを追加するだけの選択肢より、
既存利用者を安全に移行し
古い認証経路まで閉じる選択肢を確認します。
まとめ
既存環境のシークレット / 認証情報管理を改善する場合、
棚卸し
↓
依存関係把握
↓
目標状態決定
↓
段階的な切替
↓
利用側確認
↓
必要に応じて旧値をローテーション
↓
旧認証情報失効
↓
移行用の一時権限・旧経路削除までを1つの改善として考えます。
Secrets Manager、Parameter Store、一時的な認証情報、ローテーションなどの既習知識は、この改善を実現するための前提知識です。
ここでの決定打は、**「どのサービスを知っているか」ではなく、「既存認証情報をどの順序で安全に廃止・移行完了させるか」**です。