機密情報はどこに置く?Secrets ManagerとParameter Storeの違いを整理した

おはようございます、YASUです。

以前、うっかりAWSのアクセスキーをGitHubにコミットしてしまう事故を防ぐgit-secretsや.gitignoreの話を書きました。あれは「コミットさせない」ための防御策でしたが、DVAの勉強を進めていて、もう一段手前の疑問にぶつかりました。「そもそも、パスワードやAPIキーは、アプリケーションからどこに置いて、どう読み込むのが正解なのか」という問いです。

結論

AWSには、機密情報を安全に預けておく場所として、Secrets ManagerとParameter Storeという2つのサービスがあります。どちらも暗号化の裏側ではKMSという鍵管理サービスを使っていて、セキュリティの強さ自体に差はありません。違いは「自動ローテーション(定期的な更新)を使いたいか」と「コストをどこまで抑えたいか」でした。

まず、なぜコードに直書きしてはいけないのか

以前の記事で触れた通り、アクセスキーのような機密情報をコードに直接書いてしまうと、Gitに一度でもコミットした時点で、履歴に残り続けてしまいます。.gitignoreやgit-secretsは、そこで食い止めるための「門番」でしたが、そもそもコードの中に機密情報を置かなければ、門番に頼る必要自体が減ります。コードの中には「機密情報の置き場所」だけを書いておき、実際の値は実行時に取りに行く、という設計が、DVAでも繰り返し問われる考え方でした。

KMS:すべての土台になる「鍵の管理人」

最初に混乱したのが、KMSの立ち位置でした。KMSは、暗号化に使う鍵そのものを作って管理するサービスで、Secrets ManagerやParameter Storeの裏側で、データを守るために使われています。

理解の助けになったのが「エンベロープ暗号化」という仕組みです。実際のデータは「データキー」で暗号化し、そのデータキー自体をKMSの鍵で暗号化する、という二段構えになっています。KMSの鍵が直接データを暗号化するのではなく、「データキーを守る鍵」として機能している、というのが、最初は意外でした。金庫の中身(データ)を守る小さな鍵(データキー)を、さらに銀行の大金庫(KMS)で保管している、というイメージです。

• AWS管理キー:AWSが自動で用意・管理してくれる鍵。追加料金なしで使える
• カスタマー管理キー:自分で作って管理する鍵。月額1ドル程度の料金がかかるが、監査要件などで「自社で鍵を管理している証明」が必要な場合に選ぶ

規制上の要件がなければ、AWS管理キーで十分とされています。

Parameter Store:低コストで使える「設定とシークレットの両方を置ける棚」

Systems Managerの一機能であるParameter Storeは、設定値と機密情報の両方を、階層的に整理して保存できる仕組みです。

/myapp/production/database/password
/myapp/production/api/key
/myapp/dev/database/password

このようにフォルダのような階層構造で整理でき、環境ごと(production、devなど)に値を切り替えるのも楽になります。機密情報を暗号化して保存する場合は「SecureString」というタイプを使い、裏側でKMSが働きます。

• Standardパラメータ:無料(パラメータ数は10,000個まで)
• Advancedパラメータ:1パラメータあたり月額約0.05ドル

ただし、保存した機密情報の自動ローテーション機能は備えていません。

Secrets Manager:機密情報に特化した「専用金庫」

一方のSecrets Managerは、シークレット管理に特化したサービスで、最大の特徴は自動ローテーション機能です。例えばRDSなどのデータベースのパスワードを、一定期間ごとに自動で更新してくれます。

• 料金:1シークレットあたり月額約0.40ドル+APIコール課金
• 自動ローテーション機能がある
• 複数リージョンへのレプリケーションが可能

Parameter Storeより料金は高くなりますが、パスワードの定期更新を人間が手動でやる必要がなくなる、という運用面のメリットが大きいと感じました。

よく混同する点:セキュリティの強さは同じ

最初、「Secrets Managerの方が高機能だから、セキュリティも強いのでは」と思い込んでいました。しかしAWS公式のFAQには、両者のセキュリティモデルに違いはなく、どちらも同じように安全だと明記されています。どちらもKMSでの暗号化に対応し、IAMでのアクセス制御もできます。違いはあくまで機能(ローテーションの有無など)とコストです。

使い分けの判断軸

自動ローテーションが必要(DBパスワードの定期更新など) → Secrets Manager
設定値とシークレットを1つの棚にまとめたい、コストを抑えたい → Parameter Store
監査などで「自社で鍵を管理している証明」が必要 → KMSのカスタマー管理キー

試験の問題文では、「パスワードを定期的に自動更新したい」というキーワードが出てきたらSecrets Manager、「コストを最小限にしたい」ならParameter Store、という具合に、要件のキーワードから逆引きする形になりそうです。

以前の記事とのつながり

以前のgit-secretsの記事で紹介した、AWSアクセスキーが流出して高額請求を受けたという事故は、機密情報をコードやファイルに直接置いてしまうことが根本原因でした。Secrets ManagerやParameter Storeに機密情報を預け、アプリケーションは実行時にそこから取得する、という設計にしておけば、そもそも「コミットしてしまう機密情報」自体が存在しなくなります。門番(git-secrets)に頼る前に、そもそも守るべきものを別の場所に置いておく、という二重の防御になる、と理解しました。

まとめ

• 機密情報は、コードに直書きせず、Secrets ManagerまたはParameter Storeに預けて実行時に取得する
• KMSは裏側で暗号化に使われる鍵の管理サービスで、エンベロープ暗号化という二段構えの仕組みで動いている
• Secrets ManagerとParameter Storeは、セキュリティの強さに差はなく、違いは自動ローテーションの有無とコスト
• 自動ローテーションが必要ならSecrets Manager、コストを抑えたいならParameter Store

これまでGitの記事でたびたび触れてきた「機密情報の扱い」というテーマが、DVAの範囲でもう一段深い形で繋がりました。それでは、また明日!