シークレット管理 とは？

設定ファイルに書いたパスワードがGitHubにプッシュされて大事故、というのは本当によくある話なんだ。AWSのアクセスキーがGitHubに公開されると、ボットが数分で検知して暗号通貨のマイニングに悪用するなんてことも起きている。だからシークレットはコードとは別の安全な場所に保管するのが鉄則だよ。

AWS Secrets Managerを例にすると、シークレットをAWSに暗号化して保存して、アプリからはAPIで取得する。コードにはシークレットの「名前」だけ書いて、実際の値は実行時にAPI経由でもらうんだ。誰がいつアクセスしたかのログも残るよ。

環境変数は設定ファイルよりはマシだけど、プロセスの環境変数は子プロセスに引き継がれるし、クラッシュレポートに含まれることもある。本番環境では専用のシークレット管理ツールを使う方が安全だよ。

ここがシークレット管理の中でも運用上一番やっかいなところでね。パスワードを定期的に変更するのは「漏洩していた場合の被害期間を限定する」ためなんだけど、実際にローテーションするとアプリの接続が切れるリスクがある。AWS Secrets ManagerはRDSのパスワードを自動ローテーションできるけど、そのタイミングでアプリが古いパスワードでDBに接続しようとして失敗するケースがある。「シークレット取得のキャッシュ期間」と「ローテーション間隔」のタイミングがずれると障害になるんだ。ダウンタイムなしのローテーションは「デュアルシークレット（新旧両方を一定期間有効にする）」パターンで対処するんだけど、これを全システムで統一的に実装するのは地味に難しいんだよ。