変更要約: SCS-C02 第5章を深掘り（比較表・シナリオ・FAQ・ひっかけ・深掘り段落を各節に追加、図を日本語版に対応）
5.1KMS と暗号化
保存時暗号化の核——KMS、CMK（カスタマー管理キー）、エンベロープ暗号化、キーポリシー、キーローテーション、CloudHSM——を理解します。鍵を安全に管理し、データを暗号化します。
データ保護の中心は KMS です。鍵の管理・アクセス制御・暗号化の仕組みを正確に理解します。
5.1.1KMS の仕組み
- エンベロープ暗号化：CMK でデータキーを暗号化し、データはデータキーで暗号化する。
- CMK の種類：AWS マネージド と カスタマー管理（CMK）。後者はポリシー/ローテーションを制御。
- アクセス制御：キーポリシーが信頼の起点。IAM だけでは使えず、キーポリシーが IAM へ委譲している場合は IAM 側の許可も要る。
- CloudHSM：FIPS 140-2 Level 3/専有 HSM が必要な厳格な要件で使う。
「鍵管理/保存時暗号化＝KMS」「データキーを CMK で暗号化＝エンベロープ暗号化」「KMS のアクセス制御＝キーポリシー＋IAM」「専有 HSM/FIPS Level 3＝CloudHSM」「自動ローテーション」 は SCS-C02 で頻出です。KMS はキーポリシーで明示的に許可しないと、IAM 管理者でも鍵を使えない点に注意。
SCS-C02 の鍵管理は「KMS のアクセス制御・キー種別・ローテーション・グラント」を正確に問います。エンベロープ暗号化では、KMS が GenerateDataKey で平文＋暗号化済みのデータキーを返し、アプリは平文データキーでデータを暗号化後に平文を破棄、暗号文と暗号化済みデータキーを保存します（復号時は KMS に暗号化済みデータキーを送って平文を得る）。キーの種類は、AWS マネージドキー（サービスが自動作成・管理、ポリシー変更不可）、カスタマー管理キー（CMK）（キーポリシー/ローテーション/エイリアスを自分で制御）、AWS 所有キー（不可視）。CMK は対称/非対称、用途（暗号化/署名/HMAC）も選べ、マルチリージョンキーで他リージョンへ複製できます。アクセス制御は「キーポリシー＋IAM」の両建てで、キーポリシーが信頼の起点——キーポリシーで許可しなければ IAM 側で許可しても使えません（逆にキーポリシーが IAM への委任を許すと IAM で制御可能）。一時的・きめ細かい委任にはグラントを使います。ローテーションは CMK で自動ローテーションを有効化でき、周期は既定の年 1 回（約 365 日）に加え 2024 年以降は 90〜2560 日でカスタム設定可能です（旧バージョンも保持して復号可）。削除は待機期間（7〜30 日）を経て無効化できます（誤削除防止）。より厳格な FIPS 140-3 Level 3（CloudHSM 現行 hsm2m）や鍵の専有・カスタムキーストアが要るなら CloudHSM を使います。設計の要は、エンベロープ暗号化の流れ、キーポリシー＋IAM の二建て、CMK の制御性、ローテーション/削除待機、CloudHSM の使いどころを正確に押さえることです。
| 項目 | AWS マネージドキー | カスタマー管理キー（CMK） |
|---|---|---|
| キーポリシー制御 | 不可（自動） | 可（自分で制御） |
| ローテーション | 自動（既定） | 既定 年 1 回・90〜2560 日でカスタム可 |
| クロスアカウント共有 | 不可 | 可（キーポリシーで） |
| 用途 | 簡易・サービス既定 | 厳格な制御/監査が要る場合 |
シナリオ：別アカウントの S3 バケットを、自社の CMK で暗号化させ、鍵の利用を監査・制御したい。→ カスタマー管理キー（CMK）を作り、キーポリシーで相手アカウント/ロールに kms:Decrypt/kms:GenerateDataKey を許可（クロスアカウント共有）、相手側 IAM でも同操作を許可。S3 は SSE-KMS でその CMK を指定。鍵の使用は CloudTrail に記録されて監査でき、自動ローテーション（既定 年 1 回・90〜2560 日でカスタム可）を有効化、削除は待機期間で誤削除を防ぎます。
FAQ：KMS と CloudHSM はどう使い分ける？ ほとんどの暗号化要件は KMS（マネージド、AWS サービスと統合、低運用負荷）で満たせます。専有のシングルテナント HSM、FIPS 140-2 Level 3、独自の鍵階層、規制で鍵の物理的占有が必須といった厳格要件のときに CloudHSM を使い、KMS のカスタムキーストアとして連携することもできます。まず KMS、特別な要件のときだけ CloudHSM、が基本です。
ひっかけ：「IAM 管理者なら KMS の鍵を必ず使える」と考えるのは誤り——KMS はキーポリシーが信頼の起点で、キーポリシーで許可（または IAM への委任を許可）しない限り、IAM 側で許可しても鍵を使えません。また CMK は誤削除防止のため即削除できず待機期間があり、削除すると暗号化データが復号不能になる点も重要です（通常は無効化を選ぶ）。
5.1.2この節のまとめ
- 鍵＝KMS（CMK＋エンベロープ暗号化＋ローテーション）
- アクセス＝キーポリシーが起点（＋委譲時は IAM）／専有 HSM＝CloudHSM
進捗の記録にはログインが必要です。
理解度チェック
（軽い確認用）Q1. KMS の鍵を使えるかどうかの「信頼の起点」になるのはどれですか？
Q2. 専有のハードウェアセキュリティモジュールと FIPS 140-2 Level 3 が要件です。何を使いますか？
Q3. 大きなデータを効率よく暗号化する KMS の仕組みはどれですか？