🔑 キーローテーションするとデータはすべて再暗号化されるのか？ — クラウドKMSの真実

「キーを定期的にローテーションしてください」という言葉は、聞くのは簡単ですが…テラバイト級のデータをすべて再暗号化するという意味でしょうか？ 😱

##

##

🎯 この記事で扱うこと

• クラウドKMSにおける「キーローテーション」が実際に意味すること
• エンベロープ暗号化（Envelope Encryption）の概念 — これを知らなければキーローテーションは絶対に理解できません
• AWS KMSとAzure Key Vaultのキーローテーション動作比較
• 自分で実装したキー（BYOK/CMK）をローテーションする際の注意点
• サービスごとに動作が異なる理由

---

📌 はじめに / 背景

クラウドセキュリティガイドを見ていると、必ず出てくる文章があります。

「暗号化キーは1年ごとに定期的にローテーション（Rotation）してください。」

初めてこのガイドを見る方が自然に抱く疑問があります。

「それでは、既存の暗号化されたデータをすべて新しいキーで再暗号化しなければならないのでしょうか？ S3に100TBも溜まっているのに、それをすべて処理するという意味ですか？」

結論から言うと、ほとんどの場合、そうではありません。その理由は、クラウドKMSがエンベロープ暗号化（Envelope Encryption）という構造を使用しているからです。この概念を理解すれば、キーローテーションがなぜ軽量で高速な作業なのかすぐに納得できます。

---

🔍 主要概念：エンベロープ暗号化（Envelope Encryption）

キーは2層構造である。

クラウドKMSはキーを一つだけ使う構造ではありません。2つの層に分かれています。

[ 실제 데이터 ]
       ↑ 암호화
[ DEK: Data Encryption Key ]   ← 실제 데이터를 암호화하는 키
       ↑ 암호화 (wrapping)
[ KEK: Key Encryption Key ]    ← DEK를 암호화하는 키 (KMS가 관리)

これを図式で表現するとこうなります。

• DEK (Data Encryption Key): 実際のデータを暗号化するキーです。通常、AES-256対称キーです。
• KEK (Key Encryption Key): DEK自体を暗号化（ラップ）して保護するキーです。KMS、Key Vaultのようなサービスが管理します。

ストレージに保存されるのは、暗号化されたDEK + 暗号化されたデータです。KEKはKMS内部にのみ存在し、外部には出ません。

「封筒」という比喩

手紙を書くことを考えてみましょう。

1. 手紙の内容（データ）を作成します。
2. 手紙を封筒（DEK）に入れて封をします。
3. 封筒をさらに別の安全な金庫（KEK）に入れて鍵をかけます。

キーローテーションは、金庫の鍵（KEK）だけを交換することです。封筒と手紙の内容はそのままです。

---

🔍 キーローテーション時に実際に起こること

AWS KMS — 自動キーローテーション（Automatic Rotation）

AWS KMSでCMK（Customer Managed Key）の自動ローテーションを有効にするとどうなるでしょうか？

# AWS CLIでキーの自動ローテーションを有効化
aws kms enable-key-rotation 
  --key-id arn:aws:kms:ap-northeast-2:123456789012:key/abcd-1234-...

有効にすると、AWSは1年ごとに新しいキーマテリアルを生成します。このとき重要な点：

• 既存のこのキーで暗号化されたデータは、自動的に再暗号化されません。
• 既存のデータは、過去バージョンのキーマテリアルで引き続き復号化できます。AWSが以前のバージョンを内部的に保持します。
• 新規の暗号化リクエストから新しいキーマテリアルが使用されます。

# boto3の例：KMSでデータを暗号化
import boto3

kms = boto3.client('kms', region_name='ap-northeast-2')

# 暗号化：KMSがDEKを生成し、KEK（CMK）でDEKをラップ
response = kms.generate_data_key(
    KeyId='arn:aws:kms:ap-northeast-2:123456789012:key/abcd-1234-...',
    KeySpec='AES_256'
)

plaintext_dek = response['Plaintext']      # 実際の暗号化に使用するDEK（メモリでのみ使用）
encrypted_dek = response['CiphertextBlob'] # 保存する暗号化されたDEK

# その後、plaintext_dekで実際のデータをAES暗号化
# plaintext_dekはメモリから即座に削除
# encrypted_dek + 暗号化されたデータを一緒に保存

復号化する際は：

# 復号化：保存されたencrypted_dekをKMSに送信してplaintext_dekを取得
decrypt_response = kms.decrypt(
    CiphertextBlob=encrypted_dek
    # KeyIdの明示は不要：AWSがどのバージョンキーで暗号化されたかを内部的に認識している
)
plaintext_dek = decrypt_response['Plaintext']
# plaintext_dekでデータを復号化

AWS KMSはCiphertextBlob内部にどのキーバージョンで暗号化されたかのメタデータが含まれているため、ローテーション後も以前のデータを問題なく復号化できます。

Azure Key Vault — キーバージョン（Key Version）方式

Azure Key VaultはAWS KMSとは異なり、キーをバージョン（Version）で管理します。

# Azure CLIで新しいバージョンのキーを作成（＝キーローテーション）
az keyvault key create 
  --vault-name myVault 
  --name myEncryptionKey 
  --kty RSA 
  --size 2048
# このコマンド実行時に新しいバージョンが作成され、自動的に「current」バージョンになる

# 現在のキーのすべてのバージョンを確認
az keyvault key list-versions 
  --vault-name myVault 
  --name myEncryptionKey

バージョンがローテーションされると：

• 以前のバージョンキー: 無効化することも可能ですが、既存データの復号化のために通常は有効のまま維持されます。
• 新規暗号化: 新しいバージョンキーを使用します。
• 既存データ: 再暗号化なし（以前のバージョンで復号化可能）

# 特定のバージョンで暗号化
az keyvault key encrypt 
  --vault-name myVault 
  --name myEncryptionKey 
  --version <old-version-id>   # 旧バージョンでも復号化可能
  --algorithm RSA-OAEP 
  --value "base64-encoded-data"

---

🔍 サービスごとに異なりますか？

はい、異なります。キーローテーション時の動作は、サービスと実装方法によって3つのケースに分かれます。

ケース1：完全自動 — データ再暗号化なし（最も一般的）

KMS/Key Vaultで管理されるエンベロープ暗号化ベースのサービスです。

サービスキー	ローテーション動作
AWS S3 SSE-KMS	KEKのみローテーション、データ再暗号化なし
AWS EBS ボリューム暗号化	KEKのみローテーション、既存ボリューム再暗号化なし
Azure Blob Storage (CMK)	新しいキーバージョンを指定、DEKを自動的に再ラップ
Azure SQL Database TDE	新しいプロテクターキーを指定、データ再暗号化なし

ケース2：自動DEK再ラップ — データ再暗号化なし

Azure Storage、Azure Disk Encryptionなど一部のサービスでは、KEKローテーション時に保存されたDEKを新しいKEKで自動的に再ラップします。DEK自体は変更されないため、データ再暗号化は行われません。

[이전] 데이터 ← DEK ← KEK(v1)
[이후] 데이터 ← DEK ← KEK(v2)  ← DEK가 새 KEK로 재래핑됨
       (데이터는 동일)

ケース3：完全再暗号化 — 稀だが存在する

これは、アプリでキーを直接管理する場合や、特定のデータベースでマスターキーをローテーションする場合です。

# アプリで直接キー管理する場合に再暗号化が必要なパターン
def rotate_dek(data_store, old_key, new_key):
    """
    앱이 직접 DEK를 관리할 경우, 기존 데이터를 모두 재암호화해야 함
    → 봉투 암호화를 쓰지 않는 경우의 안티패턴
    """
    for record in data_store.all():
        plaintext = aes_decrypt(record.ciphertext, old_key)  # 旧キーで復号化
        record.ciphertext = aes_encrypt(plaintext, new_key)  # 新キーで再暗号化
        data_store.save(record)

このようなケースは、エンベロープ暗号化を使用しない誤った設計であるか、意図的にデータ自体の暗号化キーを変更する必要がある場合です。クラウドマネージドサービスを正しく使用していれば、この状況はほとんど発生しません。

---

⚠️ 注意事項 / よくある間違い

🚨 BYOK（Bring Your Own Key）ローテーション時、以前のバージョンのキーを早まって削除してはいけません。

最もよくある間違いです。新しいキーにローテーションしたからといって以前のキーを削除すると、以前のキーで暗号化されたDEKを復号化できなくなり、既存データに永久にアクセスできなくなります。

# AWS KMS：キー削除には7〜30日の待機期間が存在（意図的な安全装置）
aws kms schedule-key-deletion 
  --key-id <old-key-id> 
  --pending-window-in-days 30  # 最低7日、最大30日

# Azure Key Vault：ソフトデリート + パージ保護の有効化を推奨
az keyvault update 
  --name myVault 
  --enable-soft-delete true 
  --enable-purge-protection true

🚨 キーローテーション ≠ データセキュリティレベルの即時向上

キーローテーションは、キーが流出した場合の被害範囲を減らすものであり、すでに流出したキーで復号化されたデータを再度保護するものではありません。流出が疑われる場合は、キーローテーションだけでは不十分であり、そのキーでアクセス可能だったデータ範囲自体を点検する必要があります。

🚨 アプリ側でキーバージョンをハードコーディングしないでください。

# 悪い例：特定のバージョンをハードコーディング
KEY_ID = "arn:aws:kms:...:key/abcd-1234"
KEY_VERSION = "version-2023-01"  # ローテーション後にアプリコードの修正が必要 → 危険

# 良い例：エイリアスを使用（AWS）、最新バージョンを自動参照（Azure）
KEY_ID = "arn:aws:kms:ap-northeast-2:123456789012:alias/my-app-key"
# エイリアスは常にcurrentキーを指す

---

✅ まとめ / 終わりに

質問	回答
キーローテーション時に既存データすべてを再暗号化するか？	❌ ほとんどの場合不要
ローテーション後も既存データは復号化可能か？	✅ 旧キーバージョンが維持されるため可能
ローテーション後の新規データは？	✅ 新しいKEKを使用
サービスごとに異なるか？	✅ 動作方式に違いあり（再ラップの有無など）
アプリが直接キー管理する場合？	⚠️ 再暗号化が必要となる場合がある

要点を一言でまとめるとこうなります。

エンベロープ暗号化構造において、キーローテーションはDEKをラップするKEKのみを交換するものであり、実際のデータ暗号化に使用されたDEKとデータ自体には手を触れません。

クラウドマネージドサービス（S3、EBS、Azure Blobなど）を正しく使用していれば、キーローテーションは軽量で安全な作業です。データをすべて再暗号化しなければならないという恐れは、エンベロープ暗号化を理解すればなくなります。

さらに学習を進める方向としては、HSM（Hardware Security Module）、FIPS 140-2/3準拠キーストア、そしてマルチリージョンキーレプリケーション戦略をお勧めします。