KMSマルチリージョンキー — レプリカキー・クロスリージョン暗号化の設計

マルチリージョンキーとは

通常のKMSキーはリージョン固有で、別リージョンで復号するには再暗号化が必要だ。マルチリージョンキーを使うと、あるリージョンで暗号化したデータを別リージョンで直接復号できる。

通常のキー:
  リージョンA: KMSキーAで暗号化 → 暗号文A
  リージョンB: 暗号文AをリージョンBで復号 → 不可
              → ReEncryptでリージョンBのキーで再暗号化が必要

マルチリージョンキー:
  リージョンA: KMSキー（mrk-xxx）で暗号化 → 暗号文
  リージョンB: 同じキー素材のレプリカキーで直接復号 → 可

プライマリキーとレプリカキー

プライマリキー（例: ap-northeast-1）:
  - 最初に作成するキー
  - レプリカキーの作成元
  - キーポリシーはリージョンごとに独立
  - キー素材はすべてのレプリカと同一

レプリカキー（例: us-east-1）:
  - プライマリから複製したキー
  - 独自のキーポリシーを持てる
  - プライマリとは独立してIAM制御
  - レプリカをプライマリに昇格できる

マルチリージョンキーの作成

# プライマリキーの作成（マルチリージョン）
aws kms create-key \
  --description "Multi-region primary key" \
  --multi-region \
  --region ap-northeast-1

# 取得したキーIDを確認（mrk-で始まる）
# mrk-1234567890abcdef0

# レプリカキーを別リージョンに作成
aws kms replicate-key \
  --key-id mrk-1234567890abcdef0 \
  --replica-region us-east-1 \
  --description "Replica for US failover" \
  --region ap-northeast-1

クロスリージョン暗号化・復号の例

import boto3

# 東京リージョンで暗号化
kms_tokyo = boto3.client('kms', region_name='ap-northeast-1')
response = kms_tokyo.encrypt(
    KeyId='mrk-1234567890abcdef0',
    Plaintext=b'Sensitive customer data'
)
ciphertext = response['CiphertextBlob']

# バージニアリージョン（レプリカ）で復号（再暗号化不要）
kms_virginia = boto3.client('kms', region_name='us-east-1')
response = kms_virginia.decrypt(
    CiphertextBlob=ciphertext,
    KeyId='mrk-1234567890abcdef0'  # 同じキーID、同じキー素材
)
plaintext = response['Plaintext']
# → 東京で暗号化したデータをバージニアで直接復号できた

DynamoDB Global TablesとMRKの組み合わせ

DynamoDB Global Tablesはテーブルを複数リージョンにレプリケートするが、暗号化にカスタムKMSキーを使う場合は各リージョンにキーが必要だ。

通常のCMK（シングルリージョン）:
  グローバルテーブルの各リージョンで別々のCMKが必要
  → 管理が複雑

マルチリージョンキー:
  同一のキー素材を各リージョンで使用
  → キー管理がシンプル
  → アクセス制御の一貫性を保ちやすい

S3レプリケーションとMRKの組み合わせ

S3のCRR（クロスリージョンレプリケーション）とSSE-KMSを組み合わせる場合：

# レプリケーション設定でMRKを使用
aws s3api put-bucket-replication \
  --bucket source-bucket-tokyo \
  --replication-configuration '{
    "Role": "arn:aws:iam::123456789012:role/ReplicationRole",
    "Rules": [{
      "Status": "Enabled",
      "Filter": {},
      "Destination": {
        "Bucket": "arn:aws:s3:::dest-bucket-virginia",
        "EncryptionConfiguration": {
          "ReplicaKmsKeyID": "mrk-1234567890abcdef0"
        }
      },
      "SourceSelectionCriteria": {
        "SseKmsEncryptedObjects": {
          "Status": "Enabled"
        }
      }
    }]
  }'

MRKを使うとレプリカ側でも同じキー素材で復号でき、鍵管理が一元化される。

セキュリティ上の考慮

マルチリージョンキーのリスク:
- プライマリ削除でもレプリカは残る（レプリカの独立性）
- レプリカをプライマリに昇格できる（DR対策）
- 各リージョンで独立したキーポリシーを持つ（権限の分散管理が必要）

ベストプラクティス:
- 各リージョンのキーポリシーは一貫性を保つ
- プライマリとレプリカで異なる管理者を設定しない
- AWS CloudFormationで両方のキーを一元管理

通常のキーとMRKの使い分け

通常のCMK（リージョン固有）を使うべきケース:
  - データが単一リージョンに留まる
  - コンプライアンスでリージョン間のキー素材共有が禁止
  - シンプルさを優先

マルチリージョンキーを使うべきケース:
  - DR（災害復旧）でデータを別リージョンに復元する必要がある
  - グローバルアプリケーション（データが複数リージョンで使われる）
  - DynamoDB GlobalTablesやS3 CRRを使う
  - クロスリージョンでの再暗号化（ReEncrypt）を避けたい

試験頻出ポイント

• MRKは mrk- で始まるキーID
• プライマリとレプリカは同じキー素材を共有
• キーポリシーはリージョンごとに独立（異なる設定が可能）
• レプリカの削除はプライマリに影響しない
• レプリカはプライマリに昇格可能（DR用途）

まとめ

マルチリージョンキーはDR設計とグローバルアプリケーションの暗号化を大幅に簡素化する。通常のCMKではクロスリージョンでのデータ復号に再暗号化が必要だが、MRKを使えばそのコストと複雑さを省ける。ただし各リージョンのキーポリシー管理には一貫性が必要だ。