AWS Secrets Manager によるシークレット管理 - 自動ローテーションとアプリケーション統合
RDS・Aurora のパスワードを Lambda 関数で自動ローテーションし、SDK キャッシュライブラリでアプリケーションからシームレスに取得する。Parameter Store との使い分けも紹介します。
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 という使い分けが一般的です。
自動ローテーションの仕組み
自動ローテーションは 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 の料金
Secrets Manager の料金はシークレット 1 件あたり月額約 0.40 ドルと、API コール 10,000 回あたり約 0.05 ドルです。自動ローテーション用の Lambda 関数の実行料金も発生しますが、ローテーション頻度 (30〜90 日ごと) を考慮すると少額です。Parameter Store の SecureString (標準パラメータは無料) と比較するとコストは高いですが、自動ローテーション機能の価値を考慮して選択します。Lambda のキャッシュライブラリで API コール数を削減し、コストを最適化します。
ローテーション設計の実際
シークレットの自動ローテーションは、定期的に認証情報を更新し、漏洩時のリスクを抑える仕組みです。データベースのパスワードなどでよく使われ、ローテーション処理は Lambda 関数が担います。データベースと連携する一般的な構成では、定義済みのローテーション機能を利用できますが、独自のシステムには自前のローテーション処理を実装します。更新の最中もアプリケーションが認証に失敗しないよう、新旧の認証情報を一時的に併存させる戦略を取ることもあります。ローテーションの頻度や方式を、システムの要件と無停止での更新を両立できるよう設計することが重要です。
クロスアカウントでの共有
複数のアカウントにまたがるシステムでは、同じシークレットを共有したい場面があります。Secrets Manager は、リソースベースのポリシーを使って、特定の他アカウントからのアクセスを許可できます。これにより、各アカウントで同じ認証情報を重複して管理する必要がなくなり、更新も一元化できます。共有する際は、暗号化に使う鍵の権限も合わせて設計し、許可したアカウントだけが復号できるようにします。アクセスを許す範囲は最小限に絞り、不要な共有を避けます。一元管理と適切な共有を組み合わせることで、分散したシステム全体で認証情報を安全に運用できます。
セキュリティのベストプラクティス
シークレットを安全に扱うには、いくつかの原則を徹底します。シークレットへのアクセス権限は、本当に必要なロールだけに最小限で付与します。保存時の暗号化に使う鍵を適切に管理し、復号できる対象を制御します。誰がいつどのシークレットを取得したかを記録し、監査できるようにすれば、不審なアクセスを検知できます。コードや設定ファイルに認証情報を直接書き込まず、必ず実行時に取得する設計にします。これらを組み合わせることで、認証情報が漏洩する経路をふさぎ、万一の際にも影響範囲を限定できる堅牢な管理を実現します。
取得の最適化と運用監視
アプリケーションがシークレットを頻繁に取得すると、API の呼び出しが増え、レイテンシやコストに影響します。取得した値を一定時間キャッシュして再利用すれば、呼び出し回数を抑えられます。ローテーションで値が更新されたら、キャッシュも適切に更新されるよう設計します。運用面では、ローテーション処理が失敗していないかを監視することが重要です。失敗に気づかず古い認証情報のまま運用すると、ある時点で認証エラーが発生する恐れがあります。ローテーションの成否を通知で把握し、失敗時にすぐ対応できる体制を整えることが、安定した運用につながります。
まとめ
Secrets Manager は認証情報のライフサイクル管理を自動化するサービスです。自動ローテーションでパスワードの定期更新を強制し、IAM ポリシーでアクセスを制御し、KMS で暗号化することで、認証情報の漏洩リスクを多層的に低減します。コードやリポジトリにパスワードを埋め込む慣行を排除し、セキュリティのベストプラクティスを組織全体に適用できます。