AWS Key Management Service (KMS) は、暗号化鍵の作成・管理・使用 を行うマネージドサービスです。 AWS のデータ保護の中核であり、エンベロープ暗号化の理解が SAA/SAP 両方で必須です。本記事では KMS の仕組みと設計を SAA / SAP 両面から整理します。

SAA レベル：基礎概念

KMS キーの種類

KMS には複数のキー種別があります。この分類は SAA の超頻出です。

キー種別	説明	課金	管理者
AWS マネージドキー (aws/service-name)	AWS サービスが自動作成・管理	無料（データ転送のみ）	AWS
カスタマー管理キー (CMK)	ユーザーが作成・管理	月額 + 利用料	ユーザー
カスタマー管理キー (CloudHSM)	CloudHSM クラスタ内のキー	高額	ユーザー

SAA レベル：基礎概念

KMS キーの本質的区別は 「AWS 管理かユーザー管理か」 です。

AWS マネージドキー: 無料だが、ローテーションやキーポリシーを制御不可
カスタマー管理キー (CMK): 有料だが、キーポリシー、ローテーション、監査を完全制御コンプライアンス要件がある場合は CMK が必須。この使い分けが SAA の核心です。

エンベロープ暗号化

KMS の最も重要な概念が エンベロープ暗号化 (Envelope Encryption) です。

データキー (Data Key): 実際のデータを暗号化する鍵（大量データ向けに高性能）
CMK (Customer Master Key): データキーを暗号化する鍵（KMS が管理）
暗号化されたデータキー: データと一緒に保管、使用時に KMS で復号

SAA 試験のポイント

エンベロープ暗号化は 「データを直接 CMK で暗号化せず、データキーを CMK で暗号化する」 2 段構えです。これは CMK は 4KB までしか直接暗号化できない 制約への対応と、 KMS API 呼び出し回数を減らす ための最適化です。SAA で必ず問われます。

GenerateDataKey API の仕組み

エンベロープ暗号化の中核 API が GenerateDataKey です。

SAA 頻出

GenerateDataKey は平文キーと暗号化キーの両方を返します。アプリは平文キーで暗号化後、平文キーを破棄し、暗号化キーだけを保存します。復号時は Decrypt(CiphertextBlob) で平文キーを取り出して使います。このフローが SAA で頻出します。

KMS のスループット制限

KMS には リージョンごとのスループットクォータ があります。

対称 CMK: リクエストクォータ（例: 5500〜50000 req/s、リージョンによる）
非対称 CMK: より低いクォータ
超過時: ThrottlingException

スループット制限の影響

KMS は スループット制限 があるため、高頻度で暗号化/復号するシステムでは エンベロープ暗号化で KMS 呼び出しを最小化 する設計が必須です。 CMK で直接毎回暗号化するとスロットリングが発生します。SAA でも設計論点として出ます。

SAP レベル：高度な設計シナリオ

キーポリシー (Key Policy) の設計

CMK には キーポリシー が必須で、これがアクセス制御の根幹です。

SAP レベル：高度な設計シナリオ

CMK のアクセス制御は キーポリシー + IAM ポリシーの AND で決まります。キーポリシーで許可され、かつ IAM ポリシーで許可されて初めてアクセス可能。この「双方向の許可」を設計するのが SAP の KMS ガバナンス論点です。

{
  "Version": "2012-10-17",
  "Id": "key-policy-example",
  "Statement": [
    {
      "Sid": "Enable IAM permissions",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::ACCOUNT_ID:root"
      },
      "Action": "kms:*",
      "Resource": "*"
    },
    {
      "Sid": "Allow service X to use the key",
      "Effect": "Allow",
      "Principal": {
        "Service": "s3.amazonaws.com"
      },
      "Action": [
        "kms:Decrypt",
        "kms:GenerateDataKey"
      ],
      "Resource": "*"
    }
  ]
}

ルートプリンシパルの意味

キーポリシーの Principal に arn:aws:iam::ACCOUNT_ID:root を指定すると、 そのアカウントの全 IAM エンティティ に権限を委任できます。これで アカウント内の IAM ポリシーで KMS 権限を個別制御 できるようになります。これをしないと IAM ポリシーだけで KMS 権限を付与できません。SAP の定石です。

クロスアカウントでの CMK 利用

S3 バケット等を 別アカウントの CMK で暗号化 する設計は SAP の頻出シナリオです。

必要な設定：

アカウント B の CMK キーポリシー: アカウント A に KMS 権限を付与
アカウント A のバケットポリシー: B の CMK を使用するよう指定
アカウント A の IAM: S3 と KMS の権限を付与

クロスアカウント KMS の落とし穴

「バケットポリシーだけでは不十分」 です。CMK 側のキーポリシーでもアクセス元アカウントを許可する必要があります。これを忘れると「バケットにはアクセスできるが復号できない」という状態になります。 SAP で典型的な落とし穴です。

キーローテーション

CMK の 自動ローテーション はセキュリティのベストプラクティスです。

項目	説明
対称 CMK の自動ローテーション	1 年ごとにバッキングキーを自動交換
AWS マネージドキー	3 年ごとに自動ローテーション（制御不可）
カスタマー管理キー (対称)	ユーザーが有効化可能、1 年周期
非対称 CMK / インポート済みキー	自動ローテーション不可

ローテーションの挙動

キーローテーションは CMK の ARN は不変 で、バッキングキーだけが交換されます。既存の暗号化データは 古いバッキングキーで復号可能 なまま維持されます。新規暗号化は新しいバッキングキーで行われます。この透過性が SAA/SAP 両方で問われます。

CloudHSM と KMS の統合

セキュリティ要件が極めて厳格な場合は CloudHSM でキーを管理します。

CloudHSM: 専用 HSM クラスタ、鍵はユーザー専有
KMS カスタマーキーストア: CloudHSM のキーを KMS から利用
FIPS 140-2 Level 3: CloudHSM はより高い認証レベル

SAP レベル：高度な設計シナリオ

コンプライアンス要件で 「鍵を AWS から完全に独立管理」 が必要な場合、 CloudHSM + KMS カスタマーキーストアを使います。KMS API はそのまま使えるため、アプリ側の変更を最小化しつつ HSM ベースの鍵管理を実現できます。この使い分けが SAP の高度論点です。

サービス別の KMS 統合

主要サービスと KMS の統合パターン：

サービス	KMS 統合	設計論点
S3	SSE-KMS でバケット暗号化	クロスアカウント時のキーポリシー
EBS	ボリューム暗号化	CMK のリージョン性
RDS	ストレージ暗号化	スナップショットの暗号化継承
Secrets Manager	シークレット値の暗号化	ローテーション時の KMS 呼び出し
Transit Gateway	VPC 間トラフィック暗号化	東西トラフィックの保護

S3 SSE-KMS のコスト影響

S3 で SSE-KMS を使うと KMS API 呼び出しが発生 し、

KMS 利用料金が増加
スループットクォータを消費大規模バケットでは SSE-S3（無料）か CMK かの判断が SAP のコスト論点です。

キーの削除とリカバリ

CMK の削除は 7〜30 日の保留期間 を挟む仕様です。

スケジュール削除: 即時削除不可、保留期間を設定
リカバリ: 保留期間中はキャンセル可能
削除完了後: 復旧不可（暗号化データは永久に読めない）

CMK 削除の壊滅的影響

CMK を削除すると、そのキーで暗号化された全データが永久に読めなくなります。 S3 バケット、EBS ボリューム、RDS スナップショット等がすべて影響を受けます。削除保留期間を最大 30 日に設定し、二重確認プロセスを入れるのが SAP の鉄則です。

監査と CloudTrail

KMS の全操作は CloudTrail に記録されます。

イベント	意味	監査論点
`Encrypt/Decrypt`	暗号化/復号実行	異常な大量呼び出しの検知
`GenerateDataKey`	データキー生成	エンベロープ暗号化の監査
`PutKeyPolicy`	キーポリシー変更	設定変更の検知
`DisableKey`	キー無効化	意図的/悪意の無効化検知
`ScheduleKeyDeletion`	削除スケジュール	削除リクエストの検知

削除スケジュールの監視

ScheduleKeyDeletion イベントを EventBridge で検知し、 承認されていないキー削除リクエスト を即座にアラートする構成が SAP の定石です。削除保留期間中に気付けばキャンセルできるため、この監視は極めて重要です。

制約とクォータ

項目	制約
CMK で直接暗号化可能なデータ	4 KB まで
リージョン性	リージョンごとに独立
削除保留期間	7〜30 日
自動ローテーション	対称 CMK のみ、1 年周期
スループット	リージョンごとにクォータ

まとめ

SAA: KMS キー種別（AWS 管理 / CMK）、エンベロープ暗号化、 GenerateDataKey のフロー、スループット制限を理解する。
SAP: キーポリシー設計、クロスアカウント利用、キーローテーション、 CloudHSM 統合、削除保護、監査設計が求められる。

次は Config / Security Hub / GuardDuty / Macie で、統合セキュリティ監視の設計に入ります。