導入
暗号化そのものはSAAでも学びますが、SAPでは「組織全体で数百のリソースを、誰が・どうキーを管理し、監査可能な形で暗号化するか」というガバナンス目線が問われます。
説明
AWS KMS（Key Management Service） はマネージド型のキー管理サービスで、暗号化キー（CMK/KMSキー）の作成・ローテーション・利用制御を行います。
| 概念 | 説明 |
|---|---|
| キーポリシー | KMSキー自体に付けるアクセス制御（デフォルトで最も強い制御） |
| グラント（Grant） | 一時的・プログラム的に他のプリンシパルへ利用権限を委譲する仕組み |
| マルチリージョンキー | 複数リージョンで同じキーマテリアルを共有するキー（リージョン間でのデータ複製・DRに必要） |
| CloudHSM | 専有のハードウェアセキュリティモジュール。FIPS 140-2 Level 3準拠が必要な場合や、キーマテリアルを完全に自分で管理したい場合に使う |
マルチリージョンキー が必要になる典型例が、Aurora GlobalやDynamoDB Global Tablesのようなリージョン間レプリケーションです。通常のKMSキーはリージョンに閉じているため、暗号化されたデータをそのまま別リージョンに複製して復号することができません。マルチリージョンキーは、プライマリキーと関連付けられたレプリカキーを各リージョンに作ることで、この問題を解決します。
flowchart LR
subgraph R1["リージョンA"]
K1["マルチリージョンキー<br/>（プライマリ）"]
D1["Auroraプライマリ"]
end
subgraph R2["リージョンB"]
K2["マルチリージョンキー<br/>（レプリカ）"]
D2["Auroraレプリカ"]
end
K1 -. "同じキーマテリアルを共有" .-> K2
D1 -- レプリケーション --> D2
KMSが「AWSが管理するマネージドなHSM基盤の上でキーを扱う」のに対し、AWS CloudHSM は顧客専有のHSMクラスタを提供します。KMSでは満たせない厳格なコンプライアンス要件（FIPS 140-2 Level 3の専有ハードウェアを要求される場合など）や、独自の暗号化エンジンを使いたい場合に選択します。
また、パスワードやAPIキーといったシークレットの管理には AWS Secrets Manager を使います。KMSが「暗号化キーの管理」であるのに対し、Secrets Managerは「認証情報そのものの保管・自動ローテーション」を担う点を区別してください（Systems Manager Parameter Storeとの違いも試験で問われやすく、Secrets Managerは自動ローテーション機能を持つ点が差別化ポイントです）。
具体例
グローバル展開する金融サービスの暗号化設計で、条件ごとに選ぶサービスが変わります。
- 「Aurora Globalで東京→大阪へ暗号化したままDBを複製したい」→ マルチリージョンキー … 通常のKMSキーはリージョンに閉じているため、東京で暗号化したデータを大阪でそのまま復号できない。→ プライマリ（東京）とレプリカ（大阪）で同じキーマテリアルを共有するマルチリージョンキーを使う。DynamoDB Global Tablesでも同じ。
- 「規制でFIPS 140-2 Level 3の専有ハードウェアが必須」→ CloudHSM … KMSの共有基盤では要件を満たせない。→ 顧客専有のHSMクラスタであるCloudHSM。
- 「DBの接続パスワードを30日ごとに自動ローテーションしたい」→ Secrets Manager … これはキー管理（KMS）ではなく認証情報の管理。自動ローテーション機能を持つSecrets Manager。
「リージョンまたぎの暗号化複製＝マルチリージョンキー、専有ハード/FIPS L3＝CloudHSM、パスワードの自動ローテーション＝Secrets Manager」を条件反射にしておきましょう。
読んでみよう
「複数リージョンにまたがるデータベースを暗号化したまま複製したい」→ マルチリージョンキー、「専有ハードウェア・FIPS 140-2 Level 3が必須」→ CloudHSM、「DBのパスワードを自動ローテーションしたい」→ Secrets Manager、という条件反射を作っておきましょう。