AWS Secrets Manager によるシークレット管理 - 自動ローテーションとアプリケーション統合

Secrets Manager の役割と Systems Manager Parameter Store との違い

Secrets Manager はデータベースパスワード、API キー、OAuth トークンなどの機密情報を安全に保存・管理するサービスです。類似サービスの Systems Manager Parameter Store (SecureString) との最大の違いは、自動ローテーション機能の有無です。Secrets Manager は RDS、Aurora、Redshift、DocumentDB のパスワードを Lambda 関数で自動的にローテーションする仕組みを標準で提供しています。Parameter Store は設定値やフラグの管理に適しており、シークレット 1 件あたり月額 0.40 USD の Secrets Manager に対して無料枠が大きい利点があります。自動ローテーションが必要な認証情報は Secrets Manager、それ以外の設定値は Parameter Store という使い分けが一般的です。

この分野について体系的に学びたい方は、関連書籍 (Amazon) も参考になります。

自動ローテーションの仕組み

自動ローテーションは Lambda 関数がシークレットの値を定期的に更新する仕組みです。RDS や Aurora の場合、AWS が提供するローテーション用 Lambda テンプレートを使用できます。ローテーションは 4 つのステップで実行されます。createSecret で新しいパスワードを生成し、setSecret でデータベースのパスワードを更新し、testSecret で新しいパスワードでの接続を検証し、finishSecret でシークレットのバージョンラベルを切り替えます。ローテーション間隔は 1 日から 365 日の範囲で設定でき、セキュリティポリシーに応じて 30 日や 90 日が一般的です。ローテーション中のダウンタイムを防ぐため、交代ユーザー戦略 (2 つのデータベースユーザーを交互に使用) を採用することを推奨します。

アプリケーションからの取得パターン

アプリケーションからシークレットを取得する基本パターンは、AWS SDK の GetSecretValue API を使用する方法です。Lambda 関数では、関数の初期化フェーズでシークレットを取得し、グローバル変数にキャッシュすることで、リクエストごとの API コールを回避します。AWS が提供するキャッシュライブラリ (Python の aws-secretsmanager-caching、Java の aws-secretsmanager-jdbc) を使用すると、TTL ベースのキャッシュとローテーション時の自動リフレッシュが組み込まれています。ECS タスクでは、タスク定義の secrets フィールドで Secrets Manager の ARN を指定すると、コンテナ起動時に環境変数として自動注入されます。CloudFormation テンプレートでは動的参照 ({{resolve:secretsmanager:MySecret}}) を使用し、テンプレート内にシークレットの値を直接記述することなく参照できます。

さらに詳しく知りたい方は、関連書籍 (Amazon) で理解を深められます。

まとめ

Secrets Manager は認証情報のライフサイクル管理を自動化するサービスです。自動ローテーションでパスワードの定期更新を強制し、IAM ポリシーでアクセスを制御し、KMS で暗号化することで、認証情報の漏洩リスクを多層的に低減します。コードやリポジトリにパスワードを埋め込む慣行を排除し、セキュリティのベストプラクティスを組織全体に適用できます。