APIキーやDBパスワードをどこに置くか悩んだことはありませんか？
AWSには「秘密情報を扱う」2大サービスがあります。Secrets Manager と KMS（Key Management Service） です。名前はどちらも “セキュリティ系” ですが、守るものも役割もまったく異なります。
この記事では、入門エンジニアが最初に知っておくべき概念・仕組み・使い分けを、歴史的背景も含めて解説します。
目次
- なぜこの2つが生まれたのか（歴史）
- KMS とは
- Secrets Manager とは
- 暗号化の仕組み ── エンベロープ暗号化
- 2つのサービスの違い
- ユースケース別の選び方
- 組み合わせパターン
- 一次ソース
1. なぜこの2つが生まれたのか
現在の設計を理解するために、まず歴史の流れを把握しましょう。
2006年 ── 鍵管理は「手作業」の時代
AWS S3・EC2 が登場した黎明期、暗号化の鍵をどう管理するかは各チームの自己責任でした。「コードにハードコード」「環境変数に平文で設置」「自前の HSM（Hardware Security Module）を構築」など、方法はバラバラで属人的でした。
2014年 ── KMS 登場
「鍵は作れるが、安全な置き場所がない」という課題を解決するため、AWS KMS がリリースされます。FIPS 140-2 準拠の HSM で鍵を保護し、IAM ポリシーによるアクセス制御を鍵レベルで実現しました。S3・EBS・RDS など多くのサービスの暗号化バックエンドとして採用されていきます。
2018年 ── Secrets Manager 登場
KMS は鍵を守りますが、「DBのパスワードをアプリに安全に配布・定期更新する」というオペレーション課題は別問題です。そこで Secrets Manager が登場。シークレットの保管・取得・自動ローテーションを提供し、その暗号化バックエンドには KMS を使用する設計になりました。
2021年 ── 用語改定
AWS はリソース種別としての “CMK（Customer Master Key）” 表記を廃止し、現在は 「KMS key」 と呼ぶ。その上でキーの管理主体に応じて「AWS managed key」「customer managed key」「AWS owned key」に分類される（旧 CMK はこれら全てを指す総称だった点に注意）。古いブログ記事で “CMK” とだけ書かれている場合、どの分類を指しているのかを文脈から判断する必要がある。
2023年〜 ── FIPS 140-3 対応
KMS の HSM が FIPS 140-2 から FIPS 140-3 Level 3 に移行。金融・医療・公共系の厳格なコンプライアンス要件にも対応しやすくなっています。
2. KMS（Key Management Service）とは
「暗号鍵そのもの」を安全に作成・保管・制御するマネージドサービス
KMS は「データを暗号化するサービス」ではなく、「暗号化に使う鍵を管理するサービス」 です。KMS の鍵（KMS キー）自体は平文で AWS 外に出ることはなく、鍵を使った暗号・復号・データキー生成といった操作は KMS 内部で行われます。一方、大容量データ本体の暗号化・復号は、KMS から受け取ったデータキーを使って呼び出し側のサービス／アプリケーションが実行します（詳しくは後述のエンベロープ暗号化）。
KMS キーの種類
| 種類 | 管理者 | コスト | 用途例 |
|---|---|---|---|
| AWS managed key | AWS が自動管理 | キー保管料は無料（KMS API リクエスト料金は発生） | S3 / Secrets Manager のデフォルト暗号化 |
| customer managed key | 自分で作成・管理 | $1/月/キー〜 | クロスアカウント、独自キーポリシー |
| AWS owned key | AWS がサービス内部で所有 | 無料（不可視） | DynamoDB 等の内部処理 |
3. Secrets Manager とは
「シークレット（秘密情報）の内容」を安全に管理するマネージドサービス
APIキー・DBパスワード・OAuthトークンなどをアプリケーションにハードコードせず、API 経由で安全に取得できます。
主な機能
① 安全な保管と取得
シークレットを暗号化して保存し、Lambda・EC2 などから IAM 権限で取得可能。コードへの平文埋め込みを排除できます。
② 自動ローテーション
RDS や Redshift のパスワードを Lambda 関数で自動更新。アプリを止めずに新しい値へ切り替えられます。
③ IAM によるアクセス制御
「この Lambda だけ読める」「この IAM ロールは更新不可」など、誰が何を操作できるかをきめ細かく制御できます。
④ CloudTrail による監査ログ
いつ・誰が・どのシークレットを取得したかが CloudTrail に記録されます。インシデント対応やコンプライアンスに有効です。
4. 暗号化の仕組み ── エンベロープ暗号化
よくある誤解
「Secrets Manager がシークレットを KMS キーで直接暗号化する」── これは正確ではありません。
実際には エンベロープ暗号化（envelope encryption） という二段階の仕組みが使われています。
暗号化フロー（シークレット保存時）
① Secrets Manager が KMS に GenerateDataKey をリクエスト
└─ KMS キー（aws/secretsmanager または customer managed key）を指定
② KMS が 256-bit AES 対称鍵（データキー）を生成し、2つ返す
├─ 平文データキー（メモリ内でのみ使用）
└─ KMS キーで暗号化されたデータキー
③ Secrets Manager が「平文データキー」でシークレット値を暗号化
└─ この処理は AWS KMS の外（Secrets Manager 内部）で実行される
④ 平文データキーをメモリから即削除
└─ 「暗号化されたデータキー」はシークレットのメタデータに保存
復号フロー（シークレット取得時）
① メタデータから「暗号化されたデータキー」を取り出す
② KMS に Decrypt をリクエストし、「平文データキー」を復元
└─ customer managed key を使っている場合は、呼び出し元に kms:Decrypt 権限が必要
（デフォルトの aws/secretsmanager キーでは追加の KMS 権限は不要）
③ 復元した平文データキーでシークレット値を復号し、呼び出し元に返す
└─ 平文データキーはメモリから即削除
なぜ直接 KMS で暗号化しないのか？
理由は2つあります。
- サイズ制限：KMS が直接暗号化できるデータは最大 4 KB。シークレット値を直接暗号化できないケースがある
- 被害範囲の最小化：エンベロープ暗号化により、同じ KMS キーを使っていてもシークレットごとに異なるデータキーで暗号化される。万一データキーが漏洩しても、被害は1シークレットに限定される
5. 2つのサービスの違い
| 観点 | KMS | Secrets Manager |
|---|---|---|
| 守るもの | 暗号鍵そのもの | シークレットの内容（パスワード等） |
| 主な操作 | 鍵の生成・暗号化・復号・署名 | シークレットの保管・取得・ローテーション |
| 自動ローテーション | AWS 生成の鍵マテリアルを持つ対称 customer managed key のみ（90〜2560 日、デフォルト 365 日）。インポート鍵・カスタムキーストア・外部キーストア（XKS）は非対応 | シークレット値の定期更新（設定可） |
| アクセス制御 | キーポリシー ＋ IAM | リソースポリシー ＋ IAM |
| 料金 | customer managed key: $1/月/キー〜 | $0.40/シークレット/月〜 |
| データサイズ制限 | 直接暗号化は最大 4 KB | シークレット値は最大 65,536 バイト |
| 関係性 | Secrets Manager は内部で KMS を使用（エンベロープ暗号化） | ← |
6. ユースケース別の選び方
Secrets Manager を使うケース
- Lambda から RDS のパスワードを安全に取得したい
- CI/CD パイプラインに API キーを渡したい
- DB パスワードを定期的に自動更新したい
- 「誰がいつパスワードを取得したか」を CloudTrail で監査したい
KMS（キー）を指定・管理するケース
- S3・EBS・RDS のストレージ暗号化で使う KMS キーを指定したい（暗号化処理自体は各サービスが KMS キーを使って行う。呼び出し側から見ると KMS API を直接叩くわけではない）
- キーポリシーで「特定の Lambda ロールにしか使わせたくない」と制御したい
- BYOK（Bring Your Own Key）で自前の鍵を持ち込みたい
- クロスアカウントで暗号化したデータを共有したい
- 鍵の使用ログを CloudTrail で詳細に監査したい
- アプリケーションから
Encrypt/Decrypt/GenerateDataKeyを直接呼びたい（独自のエンベロープ暗号化等）
ほとんどのケースでは、Secrets Manager に登録する際にデフォルトの
aws/secretsmanager（AWS managed key）で十分です。別アカウントからのアクセスや独自のキーポリシーが必要になったときに customer managed key を検討してください。
7. 組み合わせパターン
パターン1：デフォルト（最も一般的）
Secrets Manager ＋ aws/secretsmanager（AWS managed key）
Secrets Manager のシークレット料金（$0.40/シークレット/月〜＋ API リクエスト料金）は通常どおり発生しますが、KMS キーの追加料金はかかりません（aws/secretsmanager は AWS managed key のため無料）。ほとんどの用途はこれで十分で、KMS を意識する必要がありません。
パターン2：コンプライアンス・監査が厳しい場合
Secrets Manager ＋ customer managed key（KMS で自分が作成した鍵）
キーポリシーで「このシークレットは本番 Lambda ロールのみ復号可能」といった細粒度の制御が可能。金融・医療系で有効です。鍵の使用ログも CloudTrail で追跡できます。
パターン3：ストレージ暗号化を含む場合
Secrets Manager（接続情報管理）＋ KMS（S3/RDS データ暗号化）
「DB への接続パスワードは Secrets Manager で管理」「DB 自体のデータ暗号化は KMS キーで」という形で役割を分担する典型的なパターンです。
まとめ
- KMS は「鍵の職人」。暗号鍵を生成・保管・管理する基盤
- Secrets Manager は「秘密の執事」。シークレットの内容を安全に保管・配布・更新する
- Secrets Manager は内部で KMS を使っており、エンベロープ暗号化によって保護される
- 2つは「どちらか」ではなく、目的に応じて組み合わせるもの
8. 一次ソース
この記事の内容はすべて AWS 公式ドキュメントに基づいています。
- Secret encryption and decryption in Secrets Manager
- Data protection in Secrets Manager
- AWS KMS Concepts
- AWS KMS Overview
- Encryption best practices for Secrets Manager
作成日: 2026-04-14 ／ AWS 公式ドキュメントを一次ソースとして作成
用語は 2021年以降の AWS 公式表記（customer managed key / AWS managed key）に準拠