DB パスワードや API キーをコードに直書きするのは、だいたい事故の入口です。
Git に残る。ログに出る。開発者のローカルに散らばる。退職者の端末にも残る。最悪なのは、漏れたあとに「どこを変えればいいのか」が分からなくなることです。
AWS で認証情報を扱うなら、まず検討するのが AWS Secrets Manager です。この記事では、Secrets Manager が何を解決するのか、Parameter Store とどう使い分けるのか、RDS の認証情報ローテーションで何に注意すべきかを整理します。
まず結論
Secrets Manager は、秘密情報を安全に保管し、必要に応じてローテーションするためのサービスです。
特に向いているのは次のような情報です。
- RDS のユーザー名とパスワード
- 外部 API キー
- OAuth クライアントシークレット
- アプリケーションが実行時に取得する機密設定
- 定期的に変更したい認証情報
Parameter Store も設定値や秘密情報を扱えますが、Secrets Manager は「シークレットのライフサイクル管理」に寄っています。RDS などの認証情報ローテーションまで含めて考えるなら、Secrets Manager のほうが自然です。
| 用途 | 向いているサービス | 理由 |
|---|---|---|
| 通常の設定値 | Systems Manager Parameter Store | 階層管理しやすい |
| 簡単な秘密値 | Parameter Store SecureString | KMS 暗号化で保管できる |
| DB パスワードなどの秘密情報 | Secrets Manager | シークレット管理に特化 |
| 自動ローテーション | Secrets Manager | Lambda と連携して回せる |
コード直書きが危険な理由
認証情報をコードに書くと、漏えい経路が一気に増えます。
たとえば、次のような状態です。
const db = connect({
host: 'example.cluster-xxxx.ap-northeast-1.rds.amazonaws.com',
user: 'app_user',
password: 'SuperSecretPassword123!'
});
これは分かりやすく悪い例ですが、現実にはもう少し見えにくい形で残ります。
- Git の履歴に残る
- CI/CD のログに出る
- Docker image に焼き込まれる
- .env ファイルが共有フォルダに置かれる
- Slack やチケットに貼られる
一度広がった秘密情報は、消すより入れ替えるほうが現実的です。だからこそ、最初から「保管場所」と「ローテーション手順」を決めておく必要があります。
Secrets Manager が提供するもの
Secrets Manager の役割は、単に文字列を隠すことではありません。
主なポイントは次です。
- シークレットを暗号化して保管する
- IAM ポリシーで取得権限を制御する
- CloudTrail で API 呼び出しを監査できる
- バージョンを管理できる
- Lambda と連携してローテーションできる
- RDS など一部サービスではローテーションの型が用意されている
アプリケーションは、実行時に Secrets Manager API からシークレットを取得します。
Application
-> IAM Role
-> Secrets Manager:GetSecretValue
-> DB credential
-> RDS connect
重要なのは、アプリケーションに長期固定のアクセスキーを配らないことです。EC2 なら IAM Role、ECS なら Task Role、Lambda なら Execution Role を使います。キーを配る設計に戻った瞬間、Secrets Manager を使う意味がかなり薄くなります。
Parameter Store との違い
Parameter Store SecureString でも、KMS で暗号化した秘密値を保存できます。では全部 Parameter Store でよいのか。そう単純ではありません。
| 観点 | Parameter Store | Secrets Manager |
|---|---|---|
| 主な用途 | 設定値管理 | 秘密情報管理 |
| 階層管理 | 得意 | 可能だが主目的ではない |
| SecureString | あり | あり |
| 自動ローテーション | 標準機能としては弱い | 得意 |
| RDS 認証情報管理 | 手作りになりやすい | 連携しやすい |
| コスト | 比較的軽い | シークレット単位で課金 |
判断基準は、その値を定期的に安全に入れ替える必要があるかです。
ただの設定値なら Parameter Store。漏れたら困る秘密情報で、ローテーションも含めて管理したいなら Secrets Manager。これくらいでまず分けると設計しやすいです。
RDS 認証情報ローテーション
Secrets Manager の強みが出る典型例が、RDS の認証情報です。
RDS のユーザー名とパスワードを Secrets Manager に保存し、Lambda を使って定期的にローテーションできます。
ローテーションでは、ざっくり次のような流れになります。
- 新しいパスワードを生成する
- RDS 側のユーザー認証情報を更新する
- Secrets Manager のバージョンを更新する
- アプリケーションが新しいシークレットを取得する
ただし、ここで雑にやるとアプリケーション接続が切れます。
注意点は次です。
- アプリケーション側でシークレットを永久キャッシュしない
- コネクションプールの再接続挙動を確認する
- ローテーション Lambda の権限を絞る
- 失敗時に前バージョンへ戻せる運用を用意する
- 本番前に検証環境で必ず試す
「自動ローテーションを有効にしたから安全」ではありません。接続する側が古い認証情報を握り続けるなら、普通に落ちます。便利機能を信じすぎると、だいたい夜中に起こされます。
アプリケーション側の実装で気をつけること
アプリケーションは Secrets Manager から毎リクエスト取得すればよい、という話でもありません。毎回 API を叩くと遅いし、コストも増えます。
現実的には、次のような設計にします。
- 起動時に取得する
- 一定時間キャッシュする
- 取得失敗時のリトライを入れる
- ローテーション後に再取得できるようにする
- IAM Role で最小権限を付ける
権限は、対象シークレットに絞ります。
{
"Effect": "Allow",
"Action": "secretsmanager:GetSecretValue",
"Resource": "arn:aws:secretsmanager:ap-northeast-1:123456789012:secret:prod/db/app-*"
}
全部の secret を読めるロールをアプリに渡すのは、かなり雑です。秘密情報を集中管理したのに、読み取り権限を全開にしたら意味がありません。
まとめ
Secrets Manager は、認証情報をコードから追い出すための保管庫ではありますが、それだけではありません。
- DB パスワードや API キーを安全に保管できる
- IAM と KMS でアクセス制御と暗号化を組み合わせられる
- CloudTrail で取得操作を監査できる
- RDS などではローテーション設計に使いやすい
- Parameter Store は設定値管理、Secrets Manager は秘密情報とローテーションに寄せると分かりやすい
大事なのは、秘密情報を「どこに置くか」だけでなく、「誰が読めるか」「いつ入れ替えるか」「入れ替えに失敗したらどう戻すか」まで決めることです。
コードからパスワードを消すのは第一歩です。そこで満足したら、まだ半分です。