S3 や EBS、RDS の設定画面に「KMS キーで暗号化」の選択肢が出て、AWS 管理キーとカスタマー管理キーのどちらかで手が止まる。暗号化のチェックは入れたものの、その鍵が誰のもので、誰が使えて、消したらどうなるのかは説明できない。IAM で許可したはずなのに KMS で拒否される、という経験もあるかもしれません。この記事は、KMS が受け持つ範囲と、アクセスが決まる順番を整理します。
この記事の結論
- AWS KMS は暗号化や署名に使う鍵を作って管理するマネージドサービスで、KMS キーは KMS の外へ平文では出ません。
- 大きなデータは KMS キーで直接ではなく、データキーで暗号化します（エンベロープ暗号化）。S3 や EBS などの連携サービスがこれを代行します。
- KMS キーのアクセス制御は、キーポリシーが起点です。IAM ポリシーだけでは許可にならず、キーポリシーが IAM の利用を許している必要があります。
- 「暗号化されている」ことと「誰が復号できるか」は別の問いです。鍵の使い手を絞れることが、KMS を選ぶ主な意味になります。
- 料金とキーの種類ごとの細かい条件は変わりうるので、この記事では数値を書かず、公式ページで確認する前提にします。
AWS KMS とは何か｜暗号化の「鍵の置き場」を任せるサービス
AWS KMS（Key Management Service）は、暗号化に使う鍵を作り、保管し、使う操作を受け付けるサービスです。公式ドキュメントでは、鍵は HSM（専用のセキュリティ機器）で保護され、平文の鍵が KMS の外へ出ないことが説明されています。
ここで大事なのは、利用者が鍵を受け取らないという形です。アプリや AWS のサービスは「このデータを暗号化して」「この暗号文を復号して」と KMS に依頼します。鍵を預かるのも、鍵で計算するのも KMS の中です。鍵の置き場を自分で作って守る手間を、サービスに任せる形と言えます。
たとえるなら金庫番です。金庫（鍵）は金庫番のところにあり、頼めば開け閉めしてくれますが、金庫そのものは持ち出せません。正確な言い方に戻すと、「鍵の保管と、鍵を使う操作」を KMS が受け持ち、「誰が頼んでよいか」は利用者が決めます。
責任共有モデルでいえば、鍵を守る基盤は AWS の担当、どの鍵で何を暗号化し誰に使わせるかの設定は利用者の担当です。「暗号化のチェックを入れた」だけでは、後者の責任は果たせていません。
WHO HOLDS THE KEY鍵の階層
鍵は階層で守られ、自分が決めるのは上の2段
AWS KMS の基盤
- HSM — 鍵を物理的に守る機器
- KMS キー — 外へ平文で出ない
- データキー — データを暗号化する鍵
- データ — S3・EBS・RDS の中身
自分の設定
- HSM — 鍵を物理的に守る機器
- KMS キー — 外へ平文で出ない
- データキー — データを暗号化する鍵
- データ — S3・EBS・RDS の中身
自分で決めるAWS が守る
KMS キーとは何か｜AWS 所有・AWS 管理・カスタマー管理の違い
KMS で扱う鍵の入れ物を KMS キーと呼びます。S3 の設定画面で見える選択肢は、持ち主と管理のしかたで大きく3つに分かれます。
| 種類 | 誰が管理するか | キーポリシー | 向く場面 |
|---|---|---|---|
| AWS 所有のキー | AWS（利用者の画面には出ない） | 見えない・触れない | 追加の設定なしで保存データを暗号化したいとき |
| AWS 管理キー | AWS が作る（aws/s3 のような名前） |
利用者は編集できない | 連携サービスの既定の暗号化で足りるとき |
| カスタマー管理キー | 利用者が作る | 利用者が書く | 使える主体の絞り込み、別アカウントとの共有、ローテーションや無効化の自己管理が要るとき |
分かれ目は、キーポリシーを自分で書けるかです。カスタマー管理キーは自分でポリシーを書けるので、別のアカウントに使わせる設計ができます。一方で AWS 管理キーは、他のアカウントに使用を許可できません。たとえばアカウントをまたいでスナップショットや暗号化したデータを共有したい場面では、カスタマー管理キーで暗号化し直すことになります。
「どれを選ぶか」は、鍵に求める要件で決めます。要件が「保存時に暗号化されていること」だけなら AWS 管理キーで足りることもあります。「誰が復号できるかを自分たちで決めたい」「鍵の使用を追いたい」「アカウントをまたぎたい」ならカスタマー管理キーです。種類ごとの料金や細かい条件は、公式ページで確認してください。
CHECK 1ここまでの確認
KMS キーの中身（鍵の素材）を、平文のまま取り出して手元に保管できるか?
答えと解説
答え: 2. 取り出せない。KMS の外へ平文では出ない
KMS は鍵を HSM で保護し、平文を KMS の外に出さないことで成り立つサービスです。第2章「KMS キーとは何か」を読み直してください。
エンベロープ暗号化とは何か｜データキーが実際のデータを暗号化する理由
KMS キーは、動画やバックアップのような大きなデータを直接暗号化する用途には向きません。そこで使うのがエンベロープ暗号化です。データを暗号化する鍵（データキー）を別に作り、そのデータキーを KMS キーで暗号化して包みます。
流れは次の4つです。
- アプリが KMS に「データキーをください」と頼む。KMS は平文のデータキーと、KMS キーで暗号化済みのデータキーを返す
- アプリは平文のデータキーでデータを暗号化し、平文のデータキーはすぐ捨てる
- 暗号化済みデータと、暗号化済みのデータキーを一緒に保管する
- 復号するときは、暗号化済みのデータキーを KMS に渡して復号を頼み、返ってきたデータキーでデータを復号する
こうすると、手元に残るのは暗号化されたデータキーだけです。それを元の鍵に戻せるのは KMS だけで、KMS が「この呼び出しは許可されていない」と判断すれば、データは開きません。データそのものを KMS に送らずに済み、鍵の使用の可否は KMS の一点で制御できます。
ENVELOPE ENCRYPTIONエンベロープ暗号化
データはデータキーで、データキーは KMS キーで包む
-
データキーを要求
KMS が平文と暗号化済みの2つを返す
-
データを暗号化
平文のデータキーで。使い終えたら捨てる
-
一緒に保管
暗号化データ＋暗号化済みデータキー
-
復号は KMS へ依頼
許可されなければ開かない
CHECK 2ここまでの確認
大きなデータを暗号化するとき、KMS キーを直接使わずに何を使う設計が基本か?
答えと解説
答え: 1. データキー
データキーがデータを暗号化し、そのデータキーを KMS キーで保護します。この二段構えがエンベロープ暗号化です。第3章を読み直してください。
キーポリシーと IAM の関係｜IAM で許可したのに拒否される理由
KMS のアクセス制御で最もつまずくのが、ここです。IAM では、ユーザーやロールに付けたポリシーで許可すれば動くのが普通です。KMS のカスタマー管理キーでは、キーポリシーが主たるアクセス制御で、キーポリシーが IAM の利用を許していて初めて、IAM ポリシーの許可が効きます。
つまり、開発者の IAM ポリシーに kms:Decrypt を書いても、キーポリシーにその口が開いていなければ拒否されます。キーポリシーが「このアカウントの IAM ポリシーでこのキーを制御してよい」という趣旨の記述を含んでいれば、その後は IAM ポリシーで細かく付け外しできます。
| 状況 | 結果 |
|---|---|
| キーポリシーが IAM の利用を許し、IAM ポリシーも許可 | 許可される |
| キーポリシーが IAM の利用を許していない（IAM は許可） | 拒否される |
| キーポリシーが対象のロールを直接許可している | IAM ポリシーに関係なく許可される |
別アカウントに使わせるときは、キーを持つ側のキーポリシーで相手のアカウントを許可し、使う側の IAM ポリシーでもそのキーへの許可を付ける、という両側の許可が要ります。「バケットポリシーは許可したのに復号できない」という症状の多くは、キーの側の許可が抜けています。
一時的に限定した操作だけ委譲したいときは、キーポリシーを書き換えずに済む「グラント」という仕組みもあります。ここでは存在だけ押さえておきます。
KEY POLICY FIRSTキーポリシーの門
IAM の許可があっても、キーポリシーが開いていなければ通らない
キーポリシー（KMS キーの入口）
- IAMIAM で kms:Decrypt を許可 拒否されるキーポリシーは IAM を有効にしていない
- IAMIAM で kms:Decrypt を許可 通るキーポリシーが IAM の利用を許している
- ロールキーポリシーがロールを直接許可 通るIAM ポリシーは無くてもよい
CHECK 3ここまでの確認
IAM ポリシーで kms:Decrypt を許可したのに拒否された。最初に疑うのはどこか?
答えと解説
答え: 2. キーポリシーに、IAM ポリシーを有効にする記述があるか
KMS ではキーポリシーが起点です。キーポリシーが IAM の利用を許していないと、IAM の許可だけでは通りません。第4章を読み直してください。
S3・EBS・RDS はどう KMS を使うか｜連携サービスが代行するところ
S3、EBS、RDS などは KMS と連携していて、エンベロープ暗号化の手順をサービスが代わりにやってくれます。利用者が「データキーをください」と頼む実装を書く必要はなく、どの KMS キーを使うかを指定するのが利用者の仕事です。
S3 では、サーバー側の暗号化に主に2つの選び方があります。
| 方式 | 鍵の管理 | 向く場面 |
|---|---|---|
| SSE-S3 | S3 が管理する鍵。利用者の鍵管理は最小 | 保存時の暗号化が目的で、細かな制御や監査は要らないとき |
| SSE-KMS | KMS のキーを使う | 誰が復号できるかを鍵の側で絞りたい、鍵の使用を CloudTrail で監査したいとき |
SSE-KMS を選ぶ意味は、暗号化の強さではなく、鍵の使い手を絞れることと、使用の記録が残ることにあります。要件がなければ SSE-S3 で足りる、というのが記事冒頭の FAQ の答えです。
EBS にはアカウント設定として、新しいボリュームを既定で暗号化する機能があります。RDS も、暗号化の設定で KMS キーを選びます。どちらも、あとから使う側のロールが KMS キーを使えなければ、スナップショットの復元やインスタンスの起動で拒否されることがあります。「サービスが動かない」ときは、キーポリシーと使う側のロールの両方を確かめてください。
運用で押さえること｜ローテーション・削除の待機期間・CloudTrail での追跡
導入後に見る点を3つにまとめます。
- ローテーション: カスタマー管理キーは、自動ローテーションを有効にできます。鍵の素材が更新されても、キー ID は変わりません。古い素材も残るので、既存のデータを再暗号化しなくても復号できます。間隔など細かい条件は公式で確認してください。
- 削除: KMS キーの削除には待機期間があり、すぐには消えません。キーを消すと、そのキーで暗号化したデータキーが戻せなくなり、データも開けなくなります。削除ではなく「無効化」で様子を見る運用が安全です。待機期間の日数は公式で確認してください。
- 追跡: KMS の呼び出しは CloudTrail に記録されます。「誰が、いつ、どのキーを使ったか」を追えることは、SSE-KMS を選ぶ主な理由の一つです。
Cloudory 執筆者（AWS 認定 全冠）
KMS の設定で迷ったら、先に「誰に復号させたくないか」を書き出してください。その答えがそのままキーポリシーの下書きになります。暗号化のチェックだけで安心せず、鍵の使い手を言葉にしておくのが出発点です。
まとめ
KMS は、鍵を外に出さずに「暗号化を使う」ことを可能にするサービスです。大きなデータはデータキーで暗号化し、そのデータキーを KMS キーが守ります。アクセスはキーポリシーが起点で、IAM はその内側で効きます。次はアカウントをまたいで鍵を共有する考え方に進みます。
READ ALSO — プロフェッショナル向け・段4 設計
マルチアカウント設計｜アカウントを「境界」として使い、Organizations と SCP で組織のガードレールを引く
参照ソース
- AWS Key Management Service 開発者ガイド「AWS KMS とは」 — KMS の定義と、鍵が HSM で保護され平文で外へ出ないことの根拠
- AWS Key Management Service 開発者ガイド「KMS のキーポリシー」 — キーポリシーが主たるアクセス制御で、IAM の許可がキーポリシーに依存することの根拠
