KMSキーの種類と管理モデル — AWS管理・カスタマー管理・CloudHSM

KMSキーの3種類

AWS Key Management Service（KMS）のキーは管理主体によって3種類に分類される。

種類	管理者	ローテーション	キーポリシー変更	料金
AWS管理キー	AWS	自動（1年）	不可	無料
カスタマー管理キー (CMK)	ユーザー	手動 or 自動	可	$1/月/キー
カスタムキーストア (CloudHSM)	ユーザー（HSM）	手動	可	CloudHSM料金

AWS管理キー

aws/s3, aws/ebs, aws/rds のようにAWSサービスが自動的に作成・管理するキーだ。

# AWS管理キーの一覧
aws kms list-keys --query 'Keys[*].KeyId' | \
  xargs -I{} aws kms describe-key --key-id {} \
  --query 'KeyMetadata.{Id:KeyId,Manager:KeyManager,Alias:Description}'

制約：

キーポリシーを変更できない
キーの削除ができない（AWSが管理）
他のアカウントで使用できない
CloudTrailに記録はされるが、詳細な制御は不可

カスタマー管理キー（CMK）

最も柔軟な選択肢。キーポリシー、アクセス制御、ローテーションなどを完全に制御できる。

# 対称CMKの作成
aws kms create-key \
  --description "Application data encryption key" \
  --key-usage ENCRYPT_DECRYPT \
  --policy '{
    "Version": "2012-10-17",
    "Statement": [
      {
        "Sid": "Enable IAM User Permissions",
        "Effect": "Allow",
        "Principal": {
          "AWS": "arn:aws:iam::123456789012:root"
        },
        "Action": "kms:*",
        "Resource": "*"
      }
    ]
  }'

# エイリアスの作成
aws kms create-alias \
  --alias-name alias/app-data-key \
  --target-key-id arn:aws:kms:ap-northeast-1:123456789012:key/xxx

キーの種類（対称/非対称/MAC）

対称キー（Symmetric）

用途: 暗号化・復号（AES-256-GCM）
特徴: AWSサービスのサーバーサイド暗号化はほぼすべて対称キー
     キーマテリアルはAWS外に出ない

非対称キー（Asymmetric）

RSA: ENCRYPT_DECRYPT または SIGN_VERIFY
ECC: SIGN_VERIFY のみ
SM2: SIGN_VERIFY（中国リージョン）

用途:
- パブリックキーをダウンロードして外部で暗号化
- デジタル署名
- クライアントサイド暗号化

特徴: パブリックキーはダウンロード可能
     プライベートキーはAWS外に出ない

# 非対称キーの作成（RSA署名用）
aws kms create-key \
  --key-usage SIGN_VERIFY \
  --key-spec RSA_2048

# パブリックキーのダウンロード
aws kms get-public-key \
  --key-id alias/my-signing-key \
  --output text \
  --query 'PublicKey' | base64 -d > public_key.der

MACキー (HMAC)

用途: HMAC-based message authentication codes
     データの完全性検証
     トークン生成

キーのローテーション

自動ローテーション

# CMKの自動ローテーション有効化（年1回）
aws kms enable-key-rotation --key-id alias/app-data-key

# ローテーション状態の確認
aws kms get-key-rotation-status --key-id alias/app-data-key

自動ローテーションの重要な点：

バッキングキーマテリアルが新しくなるが、キーIDとARNは変わらない
古いキーマテリアルも保持される（古いデータを復号するため）
再暗号化不要（既存の暗号文はそのまま使える）

手動ローテーション

# 手動ローテーション: 新しいキーを作成してエイリアスを付け替える
NEW_KEY=$(aws kms create-key --query 'KeyMetadata.KeyId' --output text)

aws kms update-alias \
  --alias-name alias/app-data-key \
  --target-key-id $NEW_KEY

# 古いキーで暗号化されたデータは古いキーIDで復号する
# 新しいデータはエイリアス経由で新しいキーを使う

キーの削除

# キーの削除スケジュール（7〜30日の待機期間）
aws kms schedule-key-deletion \
  --key-id alias/old-key \
  --pending-window-in-days 14

# 削除をキャンセル（待機期間中のみ可能）
aws kms cancel-key-deletion --key-id alias/old-key

削除待機期間中はキーを使用できない。待機期間が過ぎると復元不可能。削除前にCloudTrailで最後の使用日時を確認することを推奨。

カスタムキーストア（CloudHSM）

AWS CloudHSMクラスターのHSM上でキーマテリアルを管理
規制要件（FIPS 140-2 Level 3等）に対応
HSMの障害でキーが使えなくなるリスクがある
コストが高い（CloudHSMクラスター料金 ≈ $1.60/時間）

キーポリシーの重要性

KMSキーポリシーには必ずアカウントルートへのAllow記述が必要だ（IAMポリシーでの制御を有効にするため）。

// 必須: アカウントルートへのAllow
{
  "Sid": "Enable IAM policies",
  "Effect": "Allow",
  "Principal": {"AWS": "arn:aws:iam::123456789012:root"},
  "Action": "kms:*",
  "Resource": "*"
}
// これがないとIAMポリシーでの制御が効かなくなる（ロックアウトリスク）

試験頻出ポイント

シナリオ	回答
キーポリシーを変更したい	カスタマー管理キー（CMK）
FIPS 140-2 Level 3準拠が必要	カスタムキーストア（CloudHSM）
ローテーション後も古いデータを復号できるか	できる（旧バッキングキーが保持される）
キー削除の最小待機期間	7日間
自動ローテーションの頻度	年1回

まとめ

KMSキーの選択は「誰が管理するか」と「コンプライアンス要件」で決まる。通常はカスタマー管理キーで十分だが、FIPS 140-2 Level 3等の規制要件にはCloudHSMを使う。キーポリシーへのルートAllow記述を忘れるとロックアウトになるため注意。

S	公式ソース確認済み
A	成功実績多数・失敗例少数
B	賛否両論
C	動作未確認・セキュリティリスク高
Z	個人所感