CLOUD SECURITY LAB

🔐 AWS KMS キーローテーション、正しく理解して使っていますか？ — 自動再暗号化サービス総まとめ + セキュリティインシデント発生時のキー交換実践ガイド

—

by

cslab
in

“キーをローテーションしたから、セキュリティは万全だろう？”

この考えが、実際のセキュリティインシデント発生時に破滅の始まりとなる可能性があります。

>

🎯 この記事で扱うこと

  • AWS KMS 自動キーローテーションが実際にすることとしないこと
  • ローテーション時に自動再暗号化されるサービス vs 手動で実施する必要があるサービス比較
  • セキュリティインシデント発生時の「キー交換」がローテーションとどう違うのか
  • セキュリティインシデント対応時のサービス別キー交換手順実践整理

📌 導入 — 「ローテーションをオンにしたから安全だ」という誤解

AWSのセキュリティガイドを見ると、いつも出てくる言葉があります。「KMS CMKの自動ローテーションを有効にせよ。」多くの方がこの設定一つでキーセキュリティが完結すると考えていますが、実はこれは半分しか正しくありません。

キーローテーションがオンになっていても、既に暗号化されたデータが自動的に新しいキーに変わらないサービスがほとんどです。そしてさらに重要なのは、実際のセキュリティインシデントが発生してキーを完全に交換しなければならない状況では、ローテーションだけでは何も解決しません。全く異なる手順が必要だからです。

今からこの二つの点を明確に整理してみましょう。

🔍 AWS KMS キーローテーションとは？ — 正確に何が起こるのか

ローテーションの実体：キーIDはそのまま、中身の素材だけ交換

KMSで自動キーローテーション(Automatic Key Rotation)を有効にすると、毎年（または設定した周期ごとに）バッキングキー素材(Backing Key Material)が新しく生成されます。重要なのは以下の点です：

  • ✅ KMS Key ID / ARNは変化しません → 既存のアプリケーション設定変更は不要
  • ✅ 以前のキー素材はKMS内部にそのまま保管されます → 過去に暗号化されたデータも引き続き復号化可能
  • ✅ 新しく暗号化するデータは新しいキー素材で暗号化されます
  • ❌ 既存の暗号化データを自動的に新しいキー素材で再暗号化しません

簡単に例えると、アパートの部屋番号（Key ID）はそのまま、鍵（Key Material）だけ新しく作られますが、既存の鍵（暗号化されたデータ）は依然として古い鍵でロックされた状態です。ただし、KMSが古い鍵のコピーも持ち続けているので、ドアは開きます。

ローテーション方式二種類

자동 로테이션: KMS가 주기적으로 키 소재 자동 생성
  → Customer Managed Key (CMK)에서 설정 가능
  → AWS Managed Key는 자동으로 3년마다 로테이션

수동 로테이션: 사용자가 직접 새 KMS 키를 생성 후 서비스에 연결
  → 침해사고 시 필요한 방식
  → Key ID/ARN이 완전히 바뀜 → 재암호화 필수

📊 自動ローテーション時のサービス別再暗号化動作

✅ ローテーション時に既存データを自動的に再暗号化してくれるサービス

サービス 再暗号化 動作条件
AWS Secrets Manager シークレット値のKMSキーを変更すると即座に再暗号化 update-secret –kms-key-id 実行時
AWS Systems Manager Parameter Store SecureStringパラメータ更新時に再暗号化 パラメータ値を再度putする時
Amazon Redshift クラスター暗号化キー交換機能内蔵 rotate-encryption-key APIを使用

これらのサービスの共通点は、「キー交換 = データ再暗号化」が単一の作業として設計されていることです。オペレーターが別途データを移行する必要はありません。

❌ 自動再暗号化がされないサービス — 手動で実施する必要があります

サービス 既存データ状態 再暗号化方法
Amazon S3 既存オブジェクトはそのまま維持 s3 cp または S3 Batch Operations
Amazon EBS 既存ボリューム/スナップショットはそのまま維持 スナップショットコピー + 新規ボリューム作成
Amazon RDS / Aurora 既存DBインスタンスはそのまま維持 スナップショット復元 + 新規KMSキー指定
Amazon DynamoDB テーブルのKMSキー変更不可 エクスポート → 新規テーブル作成 → インポート
Amazon EFS 既存ファイルシステムはそのまま維持 新規EFS作成 + データ移行
AWS Lambda 環境変数 既存の暗号化値は維持 関数更新時に自動再暗号化

> 💡 S3、EBS、RDSが「再暗号化されない」からといって、セキュリティに問題が生じるわけではありません。KMSが以前のキー素材を保管しているため、復号化は常に可能です。ただし、古いデータが古いバージョンのキー素材で暗号化されたまま残るという意味です。

⚡ セキュリティインシデント発生時の「キー交換」 — ローテーションとは全く異なる話

ローテーション vs キー交換、何が違うのか

項目 自動ローテーション セキュリティインシデント時のキー交換
Key ID/ARN 変化しない 完全に新しいキーを生成
既存キー素材 KMS内部に保存 廃棄対象 (攻撃者が知っているため)
目的 一般的なセキュリティ衛生 露出したキーの影響を遮断
再暗号化の必要性 オプション 必須
ダウンタイム なし サービスによって発生する可能性あり

セキュリティインシデントで「キー交換」が必要な理由は単純です。攻撃者がキー素材（またはキーを使用できるIAM認証情報）を取得した場合、ローテーションで新しいキー素材を作成しても、攻撃者は依然としてKMS APIを通じて復号化できます。既存のキー素材がKMS内に生きており、攻撃者の権限がまだ残っているなら意味がありません。

真のキー交換は以下の順序で行われるべきです。

🛠️ セキュリティインシデント発生時のキー交換手順

Step 1 — 隔離：既存キーと権限を即時遮断

# 既存のKMSキーを無効化（即時復号化をブロック）
aws kms disable-key --key-id <compromised-key-id>

# そのキーを使用していたIAMロール/ユーザー権限を直ちに回収
aws iam detach-role-policy --role-name <role> --policy-arn <policy-arn>

# CloudTrailで最近のキー使用履歴を確認
aws cloudtrail lookup-events 
  --lookup-attributes AttributeKey=ResourceName,AttributeValue=<key-id>

⚠️ キーを無効化すると、既存の暗号化データも即座に復号化不可能になります。再暗号化計画を先に立ててから進めてください。

Step 2 — 新しいKMSキーの作成

# 新しいカスタマー管理キーを作成
aws kms create-key 
  --description "replacement-key-after-incident" 
  --key-usage ENCRYPT_DECRYPT 
  --key-spec SYMMETRIC_DEFAULT

# エイリアスを設定
aws kms create-alias 
  --alias-name alias/new-data-key 
  --target-key-id <new-key-id>

# 自動ローテーションを有効化
aws kms enable-key-rotation --key-id <new-key-id>

Step 3 — サービス別再暗号化

S3 — S3 Batch Operationsを活用

# 方法1: 単一バケットオブジェクトのコピー (SSE-KMSキー交換)
aws s3 cp s3://my-bucket/ s3://my-bucket/ 
  --recursive 
  --sse aws:kms 
  --sse-kms-key-id <new-key-id> 
  --metadata-directive REPLACE

# 方法2: 大規模な場合はS3 Batch Operations Jobの作成を推奨
# (マニフェスト → コピー操作 → 新しいKMSキーを指定)

EBS — スナップショットコピー方式

# 1. 既存ボリュームのスナップショットを作成
aws ec2 create-snapshot 
  --volume-id vol-xxxxxxxx 
  --description "pre-key-rotation-snapshot"

# 2. スナップショットを新しいKMSキーでコピー（再暗号化）
aws ec2 copy-snapshot 
  --source-region ap-northeast-2 
  --source-snapshot-id snap-xxxxxxxx 
  --encrypted 
  --kms-key-id <new-key-id> 
  --description "reencrypted-snapshot"

# 3. 新しいスナップショットからボリュームを作成 → 既存ボリュームを交換
aws ec2 create-volume 
  --snapshot-id <new-snap-id> 
  --availability-zone ap-northeast-2a 
  --volume-type gp3

RDS — スナップショット復元方式

# 1. 手動スナップショットを作成
aws rds create-db-snapshot 
  --db-instance-identifier mydb 
  --db-snapshot-identifier mydb-snapshot-for-rekey

# 2. スナップショットをコピー（新しいKMSキーで再暗号化）
aws rds copy-db-snapshot 
  --source-db-snapshot-identifier mydb-snapshot-for-rekey 
  --target-db-snapshot-identifier mydb-snapshot-reencrypted 
  --kms-key-id <new-key-id>

# 3. 新しいスナップショットからDBインスタンスを復元
aws rds restore-db-instance-from-db-snapshot 
  --db-instance-identifier mydb-new 
  --db-snapshot-identifier mydb-snapshot-reencrypted

Secrets Manager — 最も簡単

# KMSキー交換 + 即時再暗号化 (単一コマンド)
aws secretsmanager update-secret 
  --secret-id my-secret 
  --kms-key-id <new-key-id>

DynamoDB — 最も複雑、ダウンタイム発生

# 1. 既存テーブルのPoint-in-Time RecoveryまたはS3へのエクスポート
aws dynamodb export-table-to-point-in-time 
  --table-arn arn:aws:dynamodb:...:table/MyTable 
  --s3-bucket my-export-bucket

# 2. 新しいKMSキーで新しいテーブルを作成
aws dynamodb create-table 
  --table-name MyTable-New 
  --sse-specification Enabled=true,SSEType=KMS,KMSMasterKeyId=<new-key-id> 
  # ... その他のテーブル設定

# 3. S3からデータをインポート
aws dynamodb import-table 
  --s3-bucket-source S3Bucket=my-export-bucket,S3KeyPrefix=... 
  --input-format DYNAMODB_JSON 
  --table-creation-parameters ...

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

🚨 間違い 1 — 既存キーを早すぎる削除

침해사고라고 해서 기존 키를 즉시 삭제하면 
재암호화 전 데이터가 영구 손실됩니다.

올바른 순서: 비활성화 → 재암호화 완료 → 삭제 예약(최소 7일)

🚨 間違い 2 — ローテーションだけでセキュリティインシデント対応完了と誤解

攻撃者がkms:Decrypt権限を持つIAM認証情報を奪取した場合、キーをローテーションしても意味がありません。IAM権限回収 + 新規キー作成 + 再暗号化がセットです。

🚨 間違い 3 — 全てのサービス再暗号化後、既存キーの状態を放置

# 再暗号化完了確認後、必ず削除を予約
aws kms schedule-key-deletion 
  --key-id <old-key-id> 
  --pending-window-in-days 30

🚨 間違い 4 — DynamoDBキー交換の過小評価

DynamoDBは既存テーブルのKMSキーを直接変更するAPIがありません。エクスポート → 再生成 → インポートの過程でダウンタイムまたはデータ整合性問題が発生する可能性があるため、変更管理手順を必ず確立してください。

✅ まとめ / 締めくくり

AWS KMSキー管理の核心を一句でまとめるとこうなります。

ローテーションは未来を保護し、キー交換は現在を保護する。

状況 正しい対応
一般的なセキュリティ衛生 自動ローテーション有効化
認証情報露出の疑い 即時無効化 + 新規キー作成 + 再暗号化
再暗号化自動サポート Secrets Manager, Parameter Store, Redshift
再暗号化手動必要 S3, EBS, RDS, DynamoDB, EFS

次のステップとしては、AWS Config RuleでCMKローテーション未設定の検出自動化、CloudTrail + EventBridgeでキー使用異常兆候アラート構築を合わせて構成することで、KMSベースのセキュリティ体制を完成させることができます。

Comments

コメントを残す

メールアドレスが公開されることはありません。 ※ が付いている欄は必須項目です