AWSの暗号化キー、自分で持つべきか — マネージドキーとカスタマー管理キーの分かれ目と、キーポリシー設計の実務
保存時暗号化の“次”＝キー設計。AWSマネージドキーとカスタマー管理キー(CMK)の分かれ目、キーポリシーとIAMの役割分担、ローテーションとマルチアカウント共有を、監査で説明できる形に落とす。
- #AWS
- #セキュリティ
- #KMS
- #暗号化
- #キーポリシー
- #IAM
- #監査
EBS、S3、RDSなど、AWSの多くのサービスでは保存時の暗号化（データをディスクに書く時点で暗号化する仕組み）をチェックボックス1つで有効にできます。ところが、セキュリティレビューや監査で問われるのはその先です。「そのキーは誰が持っているのか」「誰がそのキーで復号できるのか」を説明できないまま、暗号化を“オンにしただけ”で止まっている構成は珍しくありません。本記事は、この空白を2つの判断に分けて埋めます。1つは、いつ自分でキーを持つべきか（カスタマー管理キーを採用する判断軸）。もう1つは、そのキーを誰が使えるかをどう統制するか（キーポリシー・IAM・grantによる二重統制）です。対象は本番データを扱うインフラ・SRE・バックエンドの担当者と、監査対応を任される小規模チームのリードを想定しています。なお、秘密情報そのものの保管先の選び方は別レイヤーの話で、ここでは扱いません。
「暗号化オン」の次の問い — KMSキーには3種類ある
AWSの保存時暗号化の多くは、AWS KMS（Key Management Service＝暗号鍵を管理するマネージドサービス）が土台になっています。そして守りの実体は「暗号化したかどうか」ではなく、「その鍵を誰が使えるかをどう統制したか」にあります。暗号化を有効にしても、復号できる主体を絞れていなければ、データへの到達経路はふさがっていません。
KMSで使う鍵（KMSキー）には、制御の度合いと運用責任が異なる3種類があります。
- カスタマー管理キー：利用者が自分で作成・所有し、キーポリシー・IAM・grantによるアクセス制御、ローテーション、削除予約までを完全に管理できるキーです。月額の保管料と使用料がかかります。
- AWSマネージドキー：各サービスが代理で作成する
aws/<サービス名>形式のキーです。閲覧と監査はできますが、変更・ローテーション・削除はできません。月額無料で、新規には作成されないレガシー型です。 - AWS所有キー：AWSが複数顧客向けに保有するキーで、利用者のアカウントには存在せず、閲覧も監査もできません。完全に無償です。
公式が示す軸は中立で、「制御が重要ならカスタマー管理キー、容易さ最優先ならAWS所有キー」と書き分けられています。なお、これらのKMSキーは旧称をCMK（customer master key、カスタマーマスターキー）と呼んでいましたが、現在は「KMSキー」へ呼称が改められています（概念は変わりません）。本記事では以降、総称を「KMSキー」、自分で作るキーを「カスタマー管理キー」と表記します。
キーを自分で持つべきか — カスタマー管理キーの採用判断
最初の判断は「そのデータのキーを、自分で持つべきか」です。判断材料は次のいずれかが要るかどうかに集約できます。キーポリシーによる細かなアクセス制御、CloudTrailなどでのキー使用の監査、別アカウントへのクロスアカウント共有、そして規制やコンプライアンス上の要件です。これらが要るなら、選択肢はカスタマー管理キーになります。逆に、こうした制御が不要で「とにかく簡単に暗号化したい」が最優先なら、AWSマネージドキーやAWS所有キーで十分です。
ここで外せないのが、カスタマー管理キーは“タダで強い”わけではないという点です。自分で持つ以上、月額の保管料に加えて、キーポリシーの設計、ローテーションの運用、削除予約の管理といった運用責任が付いてきます。そのため、現実的な着地は「重要データから順にカスタマー管理キーへ切り替える」であって、「すべてをカスタマー管理キーにする」ではありません。制御が要る対象とそうでない対象を仕分け、要件に応じて使い分けるのが公式の立場とも整合します。
キーを誰が使えるか — キーポリシー×IAM×grantの二重統制
キーを自分で持つと決めたら、次は「そのキーを誰が使えるか」を設計します。ここがこの記事の芯です。KMSのアクセス制御は、他のリソースとは決定的に異なる構造を持っています。
まず、すべてのKMSキーは必ず1つのキーポリシー（そのキーへのアクセスを定めるリソースベースのポリシー）を持ちます。そして、rootユーザーやキーの作成者であっても、キーポリシー・IAM・grantのいずれかで明示的に許可されない限り、そのキーに対する権限はゼロです。一般のリソースのようにアカウントへ自動で権限が付与されることはありません。
二重構造の核心は次の点です。キーポリシーが明示的に許可しない限り、IAMポリシーでそのキーへのアクセスを許可することはできません。言い換えると、キーポリシー側が「IAMへの委任を許す」と宣言して初めて、IAMでキーを制御できるようになります。役割を分けると、キーポリシーは「誰が使えるか（can）」を、IAMは「誰が実際に使うか（does）」を担います。ただし例外があり、IAMの“拒否（Deny）”は常に有効です。キーポリシーが許可していても、IAMのDenyは上書きします。
デフォルトのキーポリシーには Enable IAM User Permissions という記述が含まれます。これはPrincipalにアカウントのroot ARN、Actionに kms:* を指定したものですが、意味するのは「特定のIAMプリンシパルに権限を渡す」ことではありません。「このアカウントが、IAMポリシーでキー権限を委任してよい」という許可です。この1文があるからこそ、IAM側でキーの利用権限を細かく設計できるようになります。
3つ目の grant（グラント）は、一時的で粒度の細かい許可です。「作って、使って、消す」という短命な権限付与に向き、AWSサービスが代理で作成して用済みになると retire（取り消し）します。grantは許可のみで拒否は表現できず、別アカウントに対しても発行できます。
設計上の注意として、この統制を変更できる管理者権限の配り方そのものがリスクになります。kms:PutKeyPolicy（キーポリシーを書き換える権限）や CreateGrant（grantを発行する権限）を広く配ると、キーへのアクセスを後から自由に開けられてしまいます。これらの強い権限こそ最小限の主体に絞る対象です。
エンベロープ暗号化 — なぜKMS呼び出しが要るか
大きなデータを直接KMSキーで暗号化するわけではありません。実際には2段階です。まず平文をデータキー（その場で使う暗号鍵）で暗号化し、そのデータキー自体をKMSキーで暗号化します。これがエンベロープ暗号化です。GenerateDataKey を呼ぶと、平文のデータキーと、KMSキーで暗号化済みのデータキーが返ります。平文のデータキーは暗号化に使った後で破棄し、暗号化済みのデータキーをデータと一緒に保存しておきます。復号時にはこの暗号化済みデータキーをKMSへ渡して平文に戻し、本体を復号します。データへアクセスするたびにKMS呼び出しが要るのはこのためで、だからこそ「キーを誰が使えるか」の統制がそのままデータの守りに直結します。
ローテーションとマルチアカウント
鍵は定期的に新しくする（ローテーション）ことで、1つの鍵マテリアルが使われ続けるリスクを下げられます。カスタマー管理キーの自動ローテーションは任意で、有効化すると既定では365日（約1年）周期になります。RotationPeriodInDays で周期を設定できるため、「毎年固定」と断定はできません。必要に応じてオンデマンドで即時実行することも可能です。一方、非対称キー・HMACキー・カスタムキーストアのキーは自動ローテーションに対応せず、新しいキーを作ってエイリアス（キーへの別名）を付け替える手動ローテーションになります。AWSマネージドキーは自動で、周期は約1年です（2022年5月に3年から1年へ変更されたため、古い「3年」という記載には注意が必要です）。
ローテーションしても、古い鍵マテリアルは保持され、過去に暗号化したデータは引き続き復号できます。キーIDも変わらないため、アプリケーションの改修は不要です。
複数アカウントにまたがってキーを共有する場合は、二段構えになります。キー所有側のキーポリシーで相手アカウントを許可し、かつ利用側アカウントのIAMで利用を許可する、その両方が必要です。どちらか片方だけでは使えません（前述の can と does の関係がアカウントをまたいでも同じく効きます）。grantもクロスアカウントで発行できます。なお、S3のSSE-KMSでクロスアカウント共有を行う場合、AWSマネージドキーの aws/s3 では共有できず、カスタマー管理キーが必須になります。アカウント層全体の統制とキー共有の関係は、マルチアカウント・ガバナンスの解説（公開後に相互リンク予定）と合わせて押さえると整理しやすくなります。
どこまでカスタマー管理キーにするか — 取得・監査の実務
線引きの実務は、やはり「全部カスタマー管理キー」ではありません。コストと運用負荷で対象を絞ります。料金は構造で捉えるのが要点で、(1) キー保管の月額（カスタマー管理キー単位・時間割）と、(2) APIリクエスト課金、の2層です。AWSマネージドキーは月額なしのリクエスト課金、AWS所有キーは無償です。ローテーションは保管コストが2回目まで加算された後は頭打ちになります。具体的な金額・無料枠の件数・grantの上限・最新のクォータは変わりうるため、設計に入れる前に公式の最新情報を確認してください。
S3を例にすると、暗号化の選択は監査要件で分かれます。
| 観点 | SSE-S3 | SSE-KMS |
|---|---|---|
| キーの管理 | S3が管理（利用者は触れない） | KMSキー（aws/s3 または自分のカスタマー管理キー） |
| キーポリシー制御 | できない | できる |
| キー使用のCloudTrail監査 | できない | できる |
| ローテーション制御 | 利用者は不可 | カスタマー管理キーで可 |
| 追加費用 | なし（基準暗号化） | KMSの保管・リクエスト課金 |
SSE-S3は2023年1月5日以降の全バケットで基準として有効になっており追加費用はかかりませんが、利用者がキーポリシーで制御したり、CloudTrailでキー使用を監査したりはできません。キーの制御・ローテーション・監査が要るなら、カスタマー管理キーを使うSSE-KMSを選びます。SSE-KMSはS3からKMSへのリクエストが増えるため、S3 Bucket Keys（バケット単位の中間キーでKMS呼び出しを束ねる機能）でS3からKMSへのリクエストを最大99%削減でき、コスト構造のレバーになります。
参考までに、3種のキーを役割で対比すると次のように整理できます。
| 観点 | カスタマー管理キー | AWSマネージドキー | AWS所有キー |
|---|---|---|---|
| 作成・所有 | 利用者 | サービスが代理作成 | AWSが複数顧客向けに保有 |
| キーポリシー制御 | 可（完全制御） | 不可（閲覧のみ） | 不可（存在が見えない） |
| ローテーション | 自動／手動を制御 | 自動（約1年・制御不可） | AWS管理 |
| 監査（CloudTrail） | 可 | 閲覧・監査は可 | 不可 |
| 料金 | 月額＋リクエスト | 月額なし・リクエスト課金 | 無償 |
キーをカスタマー管理キーにする実利の1つが、CloudTrailでキー使用を証跡として残せることです。「いつ・誰が・どのキーで復号したか」を後から監査できる状態は、保存時暗号化の前提となるデータ保護を支えます。この前提については AIエージェントのセキュリティ設計 でも、保存時・転送時の暗号化とキー統制をデータ保護の起点として扱っています。あわせて、秘密情報そのものの保管先の設計（姉妹記事・秘密の保管とその暗号化キーの関係）や、IAM最小権限・CloudTrail監査の個別解説とも接続する領域です。
まとめ
KMSのキー設計は、次の順序で小さく始められます。
- 重要データのキーを1つ、カスタマー管理キーに切り替える。 制御・監査・共有・コンプラ要件があるものから対象にします。
- キーポリシーで「誰が使えるか」を最小権限で書く。 rootすら明示許可がなければ権限ゼロで、IAMへの委任を許して初めてIAMが効くという構造を踏まえます。
- ローテーションを有効化し、CloudTrailでキー使用を見る。 周期は要件に合わせて設定し、使用の証跡を監査できる状態にします。
「暗号化＝安全」でも「全部カスタマー管理キー＝正解」でもありません。守りの実体は鍵のアクセス統制にあり、制御の要否とコストで対象を選ぶこと。これが監査で説明できる着地です。料金・周期・上限などの数値は変わりうるため、設計に入れる前に公式の最新情報を確認してください。
AWSのセキュリティ・基盤設計は、専門特化で高単価帯にあたる分野です。こうしたキー設計やアクセス統制のスキルを案件で活かしたい場合は、AWSの高単価（専門特化）案件を見る・相談することができます。