SAA / SAP 攻略ナビ
ホーム データ保護・暗号化

AWS KMS — 暗号鍵管理とエンベロープ暗号化

AWS KMS のカスタマー管理キー、エンベロープ暗号化、キーポリシー、ローテーション、クロスアカウント利用を SAA 基礎から SAP 高度設計まで解説。

最終更新: 2026-07-27 カテゴリ: データ保護・暗号化

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) です。

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

SAA 試験のポイント

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

GenerateDataKey API の仕組み

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

アプリ → KMS: GenerateDataKey(CMK-ID)
KMS → アプリ:
  - PlaintextDataKey (平文のデータキー)
  - CiphertextBlob (CMK で暗号化したデータキー)

アプリ:
  1. PlaintextDataKey でデータを暗号化
  2. PlaintextDataKey をメモリから破棄
  3. CiphertextBlob と暗号化データを一緒に保存

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 の頻出シナリオです。

[アカウント A (データ所有)]
  S3 バケット ── 暗号化 ── [アカウント B (KMS 所有) の CMK]

必要な設定：

  1. アカウント B の CMK キーポリシー: アカウント A に KMS 権限を付与
  2. アカウント A のバケットポリシー: B の CMK を使用するよう指定
  3. アカウント 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 統合設計論点
S3SSE-KMS でバケット暗号化クロスアカウント時のキーポリシー
EBSボリューム暗号化CMK のリージョン性
RDSストレージ暗号化スナップショットの暗号化継承
Secrets Managerシークレット値の暗号化ローテーション時の KMS 呼び出し
Transit GatewayVPC 間トラフィック暗号化東西トラフィックの保護

S3 SSE-KMS のコスト影響

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

  1. KMS 利用料金が増加
  2. スループットクォータを消費 大規模バケットでは 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 で、 統合セキュリティ監視の設計に入ります。

スポンサーリンク（広告枠） 728×90