はじめに
Amazon Auroraを構築するとき、「データベースのパスワードってどう管理すればいいの？」という疑問にぶつかります。
調べてみると、選択肢がいくつも出てきます。
- AWS Secrets Manager を使う？
- Systems Manager Parameter Store を使う？
- パスワードローテーションは必要？
- Lambda関数がいるの？いらないの？
- IAMデータベース認証っていう別の方法もある？
対象読者
- Amazon Auroraを初めて構築する方
- パスワード管理の方法で迷っている方
- Secrets ManagerとParameter Storeの違いがわからない方
前提となる環境
この記事では、以下のような一般的なWebアプリケーション構成を想定しています。
- Amazon ECS on Fargate（アプリケーション）
- Amazon Aurora（データベース）
- パスワード管理サービス（これから決める）
そもそもパスワードローテーションとは
パスワードローテーションとは、データベースのパスワードを定期的に自動で変更する仕組みです。
たとえば「30日ごとにパスワードを自動で新しいものに変えて、アプリケーション側も新しいパスワードで接続できるようにする」というイメージです。
なぜ必要なのか
パスワードをずっと同じまま使い続けると、万が一漏洩した場合にいつまでも不正アクセスが可能な状態が続きます。定期的に変更することで、漏洩時の被害を限定できます。
また、以下のようなコンプライアンスフレームワークでは、自動化された認証情報のローテーションが求められる場合があります。
- PCI DSS（クレジットカード業界のセキュリティ基準）
- HIPAA（医療情報の保護に関する法律）
- SOC（内部統制の監査基準）
- FedRAMP（米国政府のクラウドセキュリティ基準）
ローテーションを実装すべきケース
以下に該当する場合は、パスワードローテーションの実装を検討しましょう。
- 機密データを含む本番データベース
- コンプライアンス要件の対象となる環境
- 認証情報の漏洩が重大な影響を与える可能性があるシステム
パスワード管理の選択肢を比較する
Auroraのパスワード管理には、大きく3つの選択肢があります。
1. AWS Secrets Manager + パスワードローテーション
最も推奨される方法です。パスワードの保存とローテーションの両方に対応しています。
[アプリ (ECS)] → [Secrets Manager] → パスワードを取得 → [Aurora]
↑
定期的にパスワードを自動変更
メリット
- パスワードの自動ローテーションに対応
- Aurora との統合が組み込まれている
- ユーザー名・パスワード・ホスト情報などをひとつのシークレットとしてまとめて管理できる
デメリット
- Parameter Storeと比較するとコストが高い
2. Systems Manager Parameter Store
パスワードの保存と取得はできますが、自動ローテーションには対応していません。
[アプリ (ECS)] → [Parameter Store] → パスワードを取得 → [Aurora]
↑
パスワードは手動で更新が必要
メリット
- コストが安い（基本機能は無料）
- シンプルな設定値の管理に向いている
デメリット
- 自動ローテーション機能がない
- キーバリュー形式のため、ユーザー名とパスワードを別々のキーとして管理する必要がある
3. IAMデータベース認証
パスワードの代わりに、IAMの認証トークン（有効期間15分）を使ってデータベースに接続する方法です。
[アプリ (ECS)] → IAMから認証トークンを取得 → [Aurora]
（パスワード不要・トークンは15分で失効）
メリット
- パスワードそのものが不要（ローテーションの心配がない）
- データベースにユーザー認証情報を保存する必要がない
- IAMによるアクセスの一元管理が可能
- SSL/TLSによる通信の暗号化
デメリット
- 1秒あたり200接続未満のアプリケーションに推奨（接続頻度が高いワークロードには不向き）
比較表
| 項目 | Secrets Manager | Parameter Store | IAM認証 |
|---|---|---|---|
| パスワードの保存 | ✅ | ✅ | 不要 |
| 自動ローテーション | ✅ | ❌ | 不要（トークン制） |
| コスト | やや高い | 安い（基本無料） | 無料 |
| Aurora統合 | ✅ ネイティブ統合 | ❌ | ✅ |
| 接続頻度の制限 | なし | なし | 200接続/秒未満を推奨 |
| 認証情報の形式 | JSON（まとめて管理） | キーバリュー（個別管理） | IAMトークン |
Secrets Managerのローテーション方式：マネージドとLambdaの違い
Secrets Managerでパスワードローテーションを行う場合、さらに2つの方式があります。
マネージドローテーション（推奨）
Auroraのマスターユーザーのパスワードをローテーションする場合は、Lambda関数なしで自動ローテーションが可能です。これをマネージドローテーションと呼びます。
Aurora ←→ Secrets Manager
（Lambda不要・サービスが自動で管理）
- Lambda関数のメンテナンスが不要
- Auroraがパスワードを生成し、Secrets Managerに保存
- デフォルトで7日ごとにローテーション（変更可能）
Lambda関数を使ったローテーション
マスターユーザー以外のデータベースユーザーのパスワードをローテーションする場合は、Lambda関数が必要です。
Secrets Manager → Lambda関数 → Aurora
（Lambda関数がパスワードの変更処理を実行）
AWSが公式にローテーション用のLambda関数テンプレートを提供しているため、ゼロから実装する必要はありません。
どちらを選ぶか
| ローテーション対象 | 方式 | Lambda |
|---|---|---|
| マスターユーザー | マネージドローテーション | 不要 |
| マスターユーザー以外 | Lambda関数によるローテーション | 必要 |
結局どれを選べばいい？フローチャート
パスワードローテーションが必要？
│
├── YES → Secrets Manager を使う
│ │
│ ├── マスターユーザーのみ → マネージドローテーション（Lambda不要）
│ └── それ以外のユーザーも → Lambda関数によるローテーション
│
└── NO → 接続頻度は1秒あたり200未満？
│
├── YES → IAMデータベース認証を検討
└── NO → Parameter Store でパスワードを管理
（ローテーションは手動）
まとめ
- 本番環境やコンプライアンス要件がある場合は、Secrets Managerによるパスワードローテーションが推奨
- マスターユーザーのローテーションはLambda不要（マネージドローテーション）
- マスターユーザー以外のローテーションにはLambda関数が必要
- Parameter Storeはシンプルで安価だが、自動ローテーション非対応
- IAMデータベース認証はパスワード不要だが、接続頻度が高いワークロードには不向き
- 迷ったらSecrets Manager + マネージドローテーションがバランスの良い選択