AWS KMS (Key Management Service)

は、暗号化に使う暗号鍵を作成、管理、利用するためのです。、、、、、など、多くの AWS サービスの保存時暗号化で使われます。

SAA では、KMS を「暗号化サービス」として覚えるだけでは不十分です。どの鍵を選ぶか、誰が鍵を使えるか、KMS キーと権限の両方が必要な場面、監査やローテーション、をまたぐ設計を判断できることが重要です。

Point

KMS = Key Management Service の略です。
Key は「鍵」、Management は「管理」という意味です。
KMS は「暗号化に使う鍵を安全に管理し、AWS サービスから利用できるようにするサービス」と覚えます。
和訳
- Key: 鍵
- Management: 管理
- Service: サービス
- Weblio英和辞書「key」

概要

は、データそのものを長期保存するサービスではなく、データを暗号化するための鍵を管理するサービスです。たとえばオブジェクトをで暗号化する場合、S3 は KMS キーを使って暗号化処理を行います。利用者は、暗号化対象のサービス権限だけでなく、KMS キーを使う権限も必要になる場合があります。

SAA では、暗号化方式そのものの数学的な仕組みよりも、「と SSE-KMS の違い」「KMS キーポリシーとポリシーの関係」「やで鍵をどう扱うか」を問われます。

見るポイント	代表的な判断
鍵管理を細かく制御したいか	AWS managed key ではなく customer managed key を検討します。
監査や権限分離が必要か	とキーポリシー、IAM ポリシーを確認します。
AWS サービスから暗号化したいか	そのサービスが KMS 連携に対応しているかを確認します。
クロスアカウントで使うか	キーポリシー、IAM ポリシー、必要に応じてグラントを確認します。
をまたぐか	multi-Region key が必要か、レプリカキーの運用を考えます。

主要技術

①KMS キーと鍵の種類

で中心になるリソースは KMS キーです。以前は customer master key と呼ばれることがありましたが、現在は KMS key という名称で扱います。 KMS キーは、暗号化、復号、生成、署名、検証などの用途に使われます。

鍵の種類	管理主体	主な用途	SAA での判断ポイント
AWS owned key	AWS	AWS サービス側で透過的に使用	利用者が直接管理しません。細かい制御や監査には向きません。
AWS managed key	AWS サービス	サービスごとの標準的な KMS 暗号化	利用は簡単ですが、キーポリシーを細かく変更できません。
Customer managed key	利用者	厳密な権限制御、監査、ローテーション管理	SAA でよく問われます。キーポリシーを自分で管理します。
key store	利用者寄り	専用管理要件	SAA では深掘りより、より厳格な鍵管理要件で候補になる程度です。
External key store	外部鍵管理システム	AWS 外部で鍵を管理したい場合	高度な統制要件向けです。SAA では選択肢として押さえます。

Customer managed key は、鍵の有効化・無効化、エイリアス、タグ、ローテーション、削除スケジュール、キーポリシーを利用者が管理できます。監査、権限分離、利用、特定の CMK を使う要件では customer managed key が候補になります。 AWS managed key はキーポリシーを変更できないため、別アカウントへ利用を許可する用途には使えません。暗号化したやシークレットを別アカウントと共有するなら customer managed key で暗号化します。

非対称 KMS キーは、署名と検証、または公開鍵暗号に使います。秘密鍵は KMS の外に出ませんが、公開鍵はダウンロードできるため、AWS の認証情報を持たない社外の相手でも、その公開鍵で署名を検証できます。

Point

HSM = Hardware Security Module の略です。
暗号鍵を安全に保護する専用ハードウェアです。
CMK = Customer Master Key は旧称として出ることがあります。
- 現在のドキュメントでは主に KMS key と呼びます。
和訳
- Hardware: ハードウェア
- Security: セキュリティ
- Module: 部品、モジュール
- Weblio英和辞書「module」

⚠️ 頻出: 「鍵の利用者、ローテーション、削除、監査を自分で管理したい」なら customer managed key を選びます。単にサービス側で暗号化するだけなら AWS managed key で足りる場合があります。

②エンベロープ暗号化とデータキー

は大量データを直接すべて暗号化する用途より、を生成し、そのデータキーを KMS キーで保護する設計で使われます。この方式をエンベロープ暗号化と呼びます。

エンベロープ暗号化では、実データはデータキーで暗号化します。そのデータキー自体を KMS キーで暗号化して保存します。これにより、大容量データを効率よく暗号化しながら、鍵管理は KMS に任せられます。

用語	意味	試験での見方
KMS key	データキーを保護する上位の鍵	権限、監査、ローテーションの対象です。
Data key	実データを暗号化する鍵	アプリケーションや AWS サービスが使います。
Encrypted data key	KMS key で暗号化されたデータキー	暗号化データと一緒に保存できます。
Encryption context	追加の認証データ	復号時の条件や監査情報として役立ちます。

、、などの AWS サービスは、利用者が詳細な暗号化処理を実装しなくても、KMS と連携して保存時暗号化を提供します。一方、独自アプリケーションでクライアント側暗号化を行う場合は、AWS Encryption や KMS の利用が関係します。

⚠️ 頻出: 「KMS は大容量ファイルを直接すべて暗号化するサービス」と考えると誤りです。実データはデータキーで暗号化し、データキーを KMS キーで保護する設計を理解します。

③キーポリシー、IAM ポリシー、グラント

の権限管理では、キーポリシーが必須です。ポリシーだけで KMS キーの利用を完結できるわけではなく、キーポリシー側で IAM ポリシーによる許可を有効にする設計が基本になります。

制御	付ける場所	主な用途
キーポリシー	KMS キー	鍵を管理・使用できる主体を定義します。KMS では必須です。
IAM ポリシー	ユーザー、ロール、グループ	主体側から KMS 操作を許可します。
グラント	KMS キー	AWS サービスや一時的な利用者に限定的な使用権を委任します。
		アカウント全体の最大権限を制限します。

KMS キーを使うには、暗号化対象サービスへの権限と、KMS キーへの権限の両方が必要になることがあります。たとえばで暗号化されたオブジェクトを読む場合、s3:GetObject だけでなく kms:Decrypt も必要です。さらに、KMS キーポリシーがその利用を許可している必要があります。

グラントは、AWS サービスが利用者に代わって KMS キーを使う場合などに使われます。たとえば、、など、サービス連携で KMS キーを使うときに関係します。試験では、普段の権限設計はキーポリシーと IAM ポリシーを中心に考え、AWS サービス連携ではグラントが裏側で使われることを押さえます。

キーポリシーでは、鍵を管理する主体 (キー管理者) と、暗号化・復号に使う主体 (キーユーザー) を別のステートメントに分けて書けます。キー管理者にはポリシー変更や無効化などの管理操作だけを許し、kms:Decrypt を与えなければ、鍵を管理する人がデータを読めない職務分離になります。 kms:ViaService 条件キーを使うと、「S3 経由の要求のときだけ」のように、特定の AWS サービスを通した要求に限って鍵の使用を許可できます。利用者が KMS を直接呼んで復号することを防げます。

⚠️ 頻出: KMS 暗号化データへアクセスできない問題では、対象サービスの IAM 権限だけでなく、KMS キーポリシー、IAM の kms:Decrypt、SCP、設定を確認します。

④AWS サービス連携と暗号化方式の選択

は多くの AWS サービスと連携します。 SAA では、、、、、、、、、などで、保存時暗号化と KMS 権限の関係が問われます。

サービス	KMS が関係する場面	判断ポイント
Amazon S3	、DSSE-KMS	S3 権限に加えて KMS 権限が必要です。監査や鍵管理要件がある場合に選びます。
Amazon EBS	ボリューム、暗号化	やスナップショット共有時の KMS キー権限に注意します。
Amazon RDS	DB インスタンス、スナップショット暗号化	暗号化の有効化タイミングやスナップショット共有で確認します。
DynamoDB	テーブル暗号化	標準暗号化または KMS キーの管理要件で判断します。
Secrets Manager	シークレット暗号化	シークレットの取得権限と KMS 復号権限を確認します。
CloudTrail	ログファイル暗号化	監査ログ保護とキーポリシーが重要です。
SQS / SNS	メッセージ暗号化	送受信主体と KMS キー権限を合わせて確認します。

S3 の暗号化では、、SSE-KMS、、クライアント側暗号化を区別します。 SSE-KMS は、KMS キー管理、監査、キーポリシー、KMS 利用に伴うコストやの影響を考えます。

暗号化方式	鍵の管理	向いている要件
SSE-S3	S3 管理	シンプルにサーバー側暗号化したい場合です。
SSE-KMS	KMS	鍵の権限制御、監査、ローテーションを重視する場合です。
SSE-C	顧客	顧客自身が鍵を AWS に保存させず管理したい場合です。
クライアント側暗号化	アプリケーション側	AWS に平文を渡したくない場合です。

⚠️ 頻出: 「S3 オブジェクトは読める権限があるのに復号できない」場合、S3 権限だけでは不足します。SSE-KMS では KMS キーの kms:Decrypt とキーポリシーを確認します。

⑤ローテーション、無効化、削除、監査

Customer managed key では、自動ローテーションを有効にできます。ローテーションは、今後の暗号化に使う鍵素材を更新する機能です。過去に暗号化されたデータを復号できるよう、古い鍵素材は内で保持されます。

操作	目的	注意点
ローテーション	鍵素材を定期的に更新	既存データの復号を壊さずに鍵素材を更新します。
無効化	一時的に鍵を使えなくする	暗号化データの復号やサービス連携が失敗する可能性があります。
削除スケジュール	鍵を最終的に削除する	削除後は復号できなくなるため慎重に扱います。
エイリアス	鍵に分かりやすい名前を付ける	アプリケーションや運用で鍵の参照を簡単にします。
タグ	管理やコスト配賦	プロジェクト、環境、所有者などで整理します。

KMS の利用はに記録されます。鍵の作成、無効化、削除スケジュール、暗号化、復号などの操作を監査できます。セキュリティ要件がある問題では、KMS と CloudTrail を組み合わせて「誰がいつ鍵を使ったか」を追跡できる点が重要です。

KMS キーを無効化または削除すると、その鍵で保護されたデータを復号できなくなる可能性があります。削除は待機期間を設定してスケジュールされますが、試験では「削除した鍵で暗号化されたデータは復旧困難」というリスクを重視します。

自動ローテーションの周期は、既定の 365 日のほか 90〜2,560 日の範囲で指定できます。計画外にすぐ更新したい場合はローテーションを実行できます。AWS managed key は AWS が毎年自動でローテーションし、利用者は周期を変更できません。自動ローテーションに対応するのは、KMS が鍵素材を生成した対称です。非対称キー、HMAC キー、カスタムキーストアのキーは、新しいキーを作ってエイリアスを付け替える手動ローテーションで更新します。

削除をスケジュールすると、7〜30 日 (既定 30 日) の待機期間のあいだキーは「削除保留中」になり、暗号化にも復号にも使えません。待機期間中なら削除を取り消せます。まだ使われているか分からない鍵は、先に無効化して影響を確かめるか、待機期間中にキーが使われたら通知するを設定します。

⚠️ 頻出: KMS キーの削除や無効化は、暗号化データの可用性に直結します。不要そうに見える鍵でも、過去データやの復号に必要な場合があります。

⑥マルチリージョンキーとクロスアカウント利用

キーは基本的に内のリソースです。別リージョンで暗号化や復号を行う場合は、そのリージョンの KMS キーを使う設計になります。 multi-Region key を使うと、同じキー ID と鍵素材を持つ関連キーを複数リージョンに作成できます。

設計	用途	判断ポイント
単一リージョンキー	通常のリージョン内暗号化	多くのワークロードの基本です。
Multi-Region key	複数リージョンで同じ暗号化データを扱う	、グローバルアプリ、クライアント側暗号化で検討します。
利用	別アカウントの主体に鍵利用を許可	キーポリシーとポリシーの両方を確認します。

multi-Region key は、リージョン間で鍵素材を共有する関連キーですが、各リージョンに独立した KMS キーとして存在します。すべてのリージョン暗号化要件で必要になるわけではありません。クロスリージョンやコピーでは、コピー先リージョンの KMS キーや権限設定も確認します。

クロスアカウントで KMS キーを使う場合は、鍵を所有するアカウントのキーポリシーで外部アカウントの利用を許可し、利用側アカウントの IAM ポリシーでも KMS 操作を許可します。対象サービス側のリソースポリシーやサービス固有の共有設定も必要になる場合があります。

⚠️ 頻出: クロスアカウントで暗号化スナップショットや S3 オブジェクトを扱う場合、リソース共有だけでなく KMS キーの利用権限も必要です。

試験対策

SAA では、はデータ保護、監査、、バックアップ、の問題でよく登場します。まず「どのサービスのデータを暗号化しているか」を確認し、次に「暗号化方式が KMS を使っているか」「誰が KMS キーを使う必要があるか」を考えます。

、暗号化、暗号化、、ログ暗号化では、対象サービスの権限だけではなく KMS キーの権限が必要です。特に復号エラー、共有、クロスアカウントアクセスでは、キーポリシーとポリシーをセットで確認します。

問題文のキーワード	優先して考える機能	理由
鍵の利用者を細かく制御したい	Customer managed key	キーポリシー、ローテーション、削除、監査を管理できます。
オブジェクトを KMS で暗号化	SSE-KMS	S3 権限に加えて KMS 権限が必要です。
暗号化データにアクセスできない	`kms:Decrypt` とキーポリシー	対象サービスの権限だけでは不足する場合があります。
誰が鍵を使ったか監査したい	CloudTrail	KMS の利用履歴を追跡できます。
外部アカウントに暗号化スナップショットを共有	KMS キーのクロスアカウント許可	スナップショット共有だけでは復号できません。
鍵素材を定期的に更新	自動ローテーション	既存データを復号可能なまま鍵素材を更新します。
グローバルアプリで複数復号	Multi-Region key	同じ鍵素材を持つ関連キーを複数リージョンで使えます。
鍵を無効化したらアプリが失敗	KMS キーの可用性確認	暗号化データの復号に鍵が必要です。

よくある誤答は、IAM ポリシーだけを見て KMS キーを使えると判断することです。 KMS ではキーポリシーが重要で、クロスアカウントでは鍵所有側と利用側の両方の許可が必要です。また、や明示的 Deny がある場合は、KMS 権限が付いていても拒否されます。

コスト面では、KMS キーの保有、API リクエスト、ローテーションやサービス利用に伴う呼び出しが影響します。 SAA では具体的な料金暗記より、SSE-KMS はよりも権限制御や監査性が高い一方で、KMS 権限設計、API 呼び出し、運用負荷を考慮する点を押さえます。