概要
AWS KMS（Key Management Service）のカスタマーマスターキー（CMK）は、EBSボリュームやS3バケットなど複数のサービスでデータ暗号化に使用されます。CMKが削除されると、そのキーで暗号化されたすべてのデータは復号できなくなり、事実上のデータ損失となります。
たとえば、退職した従業員がCMKの削除をスケジュールしていたケースを考えます。EBSボリュームとS3バケットが同一のCMKで暗号化されている場合、CMKが完全に削除されると両方のデータにアクセスできなくなります。このようなインシデントに対して、どのように対処すべきかを正確に理解しておくことが重要です。
待機期間中であれば CancelKeyDeletion APIで削除をキャンセルできます。しかし、待機期間が過ぎてCMKが完全に削除された後は、AWS Supportに削除されたCMKの復元とデータの復旧を依頼する必要があります。
本記事では、KMS CMKの削除メカニズムと復旧方法を解説し、実際にAWSコンソールでCMKの削除スケジュールとキャンセルの操作を体験します。
KMSの暗号化キーの種類と特徴については、AWS暗号化キーの使い方 – 3種類の特徴と選び方を参照してください。
この記事のメリット
- KMS CMKの削除メカニズム（待機期間、PendingDeletion状態）を正確に理解できる
- CMK削除後に暗号化データが復号不能になる影響範囲（EBS、S3など）を把握できる
- 待機期間中の
CancelKeyDeletionによる復旧手順と、削除後のAWS Supportへの依頼方法を区別して理解できる - CloudWatch AlarmやSCPを使ったCMK削除の予防策を習得できる
- SCS試験でCMK削除に関するインシデント対応の問いに正確に答えられるようになる
執筆者とキャラクター紹介
執筆者：土肥（とひ）
株式会社ジェニュインの代表であり元エンジニア。これまでオンプレミスと AWS 環境のインフラ業務を担当。AWS 認定資格の学習で得た知識を、ハンズオンとともに解説するのが得意。直近では新人の教育も行っており、これから技術を学ぶ方が納得できる解説を心がけています。基礎編・Cloud Practitioner の記事では、解説役としても登場します。
クラウドおさる
クラウドおさるはじめましてでござる。弊猿はクラウドおさる。IT インフラが異常に発達した猿山から、雲に乗って地上の AWS を学びに降りてきたのでござる。
クラウドおさる基礎編や Cloud Practitioner の記事では、とひさんに素朴な疑問をぶつける役でござるな。Security - Specialty などの記事では、要所でワンポイントや注意点をひとこと添えるでござる。
クラウドおさる猿山にもデータセンターや監視当番があって、地上で起きることはだいたい猿山にも同じ仕組みがあるのでござる。例え話がつい猿山に寄るのは、弊猿の癖でござる。
技術解説
KMS CMKの削除メカニズム
KMS CMKの削除は、誤操作によるデータ損失を防ぐために即時削除ではなく、待機期間を設けた2段階のプロセスで行われます。
ScheduleKeyDeletion API
CMKの削除は ScheduleKeyDeletion APIを呼び出すことで開始されます。このAPIでは、7日から30日の間で待機期間（Waiting Period）を指定します。デフォルトは30日です。
aws kms schedule-key-deletion \
--key-id arn:aws:kms:ap-northeast-1:123456789012:key/xxxx-xxxx-xxxx \
--pending-window-in-days 7待機期間中のCMKの状態
削除がスケジュールされると、CMKの状態は Enabled から PendingDeletion に変わります。PendingDeletion 状態のCMKには以下の制約があります。
| 操作 | 可否 | 説明 |
|---|---|---|
データの暗号化（Encrypt） | 不可 | キーが無効化されているため使用できない |
データの復号（Decrypt） | 不可 | キーが無効化されているため使用できない |
キーの状態確認（DescribeKey） | 可能 | KeyState が PendingDeletion であることを確認できる |
削除のキャンセル（CancelKeyDeletion） | 可能 | 待機期間中に限り、削除をキャンセルできる |
| キーポリシーの変更 | 不可 | キーの管理操作も制限される |
重要な点として、PendingDeletion 状態になった時点で暗号化・復号の操作は即座に使用不可となります。待機期間の満了を待たずに、暗号化データへのアクセスは失われます。
CMK削除後のデータへの影響
CMKが完全に削除されると、そのキーで暗号化されたすべてのデータは復号できなくなります。
| サービス | 影響 |
|---|---|
| EBSボリューム | ボリュームのデータを読み取れなくなる。スナップショットからの復元もできない |
| S3バケット | SSE-KMSで暗号化されたオブジェクトをダウンロードできなくなる |
| RDS | 暗号化されたデータベースのデータにアクセスできなくなる |
| EFS | 暗号化されたファイルシステムのデータを読み取れなくなる |
CMKは複数のサービスで共有して使用されることがあるため、1つのCMKの削除が広範囲に影響する可能性があります。
CMKの復元方法
CMKの復元方法は、削除プロセスの段階によって異なります。
待機期間中の場合: CancelKeyDeletion
待機期間中であれば、CancelKeyDeletion APIで削除をキャンセルできます。
aws kms cancel-key-deletion \
--key-id arn:aws:kms:ap-northeast-1:123456789012:key/xxxx-xxxx-xxxxキャンセル後、CMKの状態は PendingDeletion から Disabled に変わります。キーを再び使用するには、EnableKey APIで明示的に有効化する必要があります。
aws kms enable-key \
--key-id arn:aws:kms:ap-northeast-1:123456789012:key/xxxx-xxxx-xxxx削除後の場合: AWS Supportへの依頼
待機期間が終了してCMKが完全に削除された場合、CancelKeyDeletion は使用できません。この場合は、AWS Supportに削除されたCMKの復元とデータの復旧を依頼します。AWS Supportが対応可能かどうかはケースバイケースですが、これが唯一の復旧手段です。
対処方法の比較
CMK削除に伴うデータ復旧について、考えられる対処方法を比較します。
| 対処方法 | 有効性 | 説明 |
|---|---|---|
| AWS Supportに削除されたCMKの復元を依頼する | 有効 | CMKが完全に削除された場合の唯一の復旧手段。CMKが復元されれば、EBS・S3の両方のデータを復号できる |
| AWS Supportに暗号化されたS3データのリカバリを依頼する | 部分的 | S3のデータのみの対処であり、EBSボリュームの復旧には対応できない。CMK自体を復元する方が根本的な解決になる |
| 暗号化されたEBSボリュームを別リージョンにコピーする | 無効 | CMKが使用不可の状態では、ボリュームのコピー操作自体が失敗する。復号にCMKが必要なため回避策にならない |
| 以前のバッキングキー（キーマテリアル）で復号する | 無効 | CMKが削除されるとすべてのバッキングキーも削除される。個別のバッキングキーを使って復号することはできない |
最も適切な対処は、AWS SupportにCMK自体の復元を依頼することです。CMKが復元されれば、そのキーで暗号化されたすべてのリソース（EBS、S3など）のデータを復号できるようになります。
予防策
CMKの誤削除や悪意のある削除を防ぐために、以下の予防策を講じることが推奨されます。
1. CMK削除権限の制限
IAMポリシーで kms:ScheduleKeyDeletion アクションを明示的に拒否し、CMKの削除をスケジュールできるユーザーを制限します。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DenyKeyDeletion",
"Effect": "Deny",
"Action": "kms:ScheduleKeyDeletion",
"Resource": "*"
}
]
}2. CloudWatch Alarmによる削除スケジュール検知
CloudTrailのログをCloudWatch Logsに連携し、ScheduleKeyDeletion イベントが発生した際にアラームを発報する設定を行います。これにより、CMKの削除がスケジュールされた時点で即座に検知し、待機期間中にキャンセルできます。
メトリクスフィルターのパターンは以下の通りです。
{ ($.eventName = "ScheduleKeyDeletion") }3. SCPによる組織全体での削除禁止
AWS Organizationsを使用している場合、SCP（サービスコントロールポリシー）で kms:ScheduleKeyDeletion を組織全体で禁止できます。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DenyKMSKeyDeletion",
"Effect": "Deny",
"Action": "kms:ScheduleKeyDeletion",
"Resource": "*"
}
]
}SCPによる制御は、個別のIAMポリシーよりも強力で、組織内のすべてのアカウントに適用されます。
実践
ここでは、KMS CMKの削除スケジュールとキャンセルの操作を体験します。CMKの状態が PendingDeletion になると暗号化・復号ができなくなることを確認し、CancelKeyDeletion で復旧する手順を実施します。さらに、CloudWatch Alarmによる削除スケジュールの検知設定も行います。
前提条件
- リージョン:
ap-northeast-1（東京） - 以下のリソースが作成済みであること
| リソース種別 | リソース名 | 用途 |
|---|---|---|
| KMS CMK | lab-cmk（対称暗号化キー） | 削除スケジュール・キャンセルの操作対象 |
| CloudTrail 証跡 | （任意の名前） | KMS APIイベントの記録用 |
| CloudWatch Logs ロググループ | （CloudTrailの配信先） | メトリクスフィルター作成用 |
手順1: CMKの削除をスケジュールする
AWSマネジメントコンソールにログインし、リージョンが ap-northeast-1（東京）であることを確認します。
上部の検索バーに KMS と入力し、表示された「Key Management Service」を選択します。
左側ナビゲーションの「カスタマー管理型のキー」を選択します。
キーの一覧から lab-cmk を選択します。
「キーのアクション」ドロップダウンから「キーの削除をスケジュール」を選択します。
「キーの削除をスケジュール」画面が開きます。以下を設定します。
- 待機期間 (日数):
7（7〜30日の範囲で指定できます。ここでは最短の7日で動作確認を行います） - 「確認」セクションのチェックボックスにチェックを入れる（待機期間に入力した日数がそのまま文面に反映されます）
「削除をスケジュール」をクリックします。
手順2: 待機期間中のキーの状態を確認する
削除がスケジュールされると、キー一覧に戻ります。lab-cmk のステータスが「削除保留中」に変わっていることを確認します。
lab-cmk を選択して詳細画面を開きます。
「一般設定」セクションで以下を確認します。
- ステータス:
削除保留中（PendingDeletion） - スケジュールされた削除日: 現在日時から7日後の日時が表示されている
手順3: 暗号化されたリソースへのアクセス試行
PendingDeletion 状態のCMKで暗号化操作ができないことを確認します。
上部の検索バーに CloudShell と入力し、表示された「CloudShell」を選択します。
CloudShellで以下のコマンドを実行し、PendingDeletion 状態のCMKで暗号化を試みます。<キーID> は lab-cmk のキーIDに置き換えてください。
aws kms encrypt \
--key-id <キーID> \
--plaintext "TestData" \
--region ap-northeast-1以下のようなエラーが表示されます。
An error occurred (KMSInvalidStateException) when calling the Encrypt operation:
arn:aws:kms:ap-northeast-1:123456789012:key/xxxx-xxxx-xxxx is pending deletion.
このエラーにより、PendingDeletion 状態のCMKでは暗号化操作が拒否されることが確認できます。復号操作（Decrypt）も同様に失敗します。KMSInvalidStateException は「キーの状態が、そのリクエストを受け付けられる状態ではない」ことを表すエラーです。
手順4: CancelKeyDeletionでキー削除をキャンセルする
上部の検索バーに KMS と入力し、表示された「Key Management Service」を選択します。
左側ナビゲーションの「カスタマー管理型のキー」を選択し、lab-cmk を選択します。
「キーのアクション」ドロップダウンから「キーの削除をキャンセル」を選択します。確認ダイアログは表示されず、その場でキャンセルが実行されます。
キーの状態が「無効」（Disabled）に変わります。削除はキャンセルされましたが、キーはまだ無効な状態です。
手順5: キーが再び使用可能になったことを確認する
キーを再び使用するには、明示的に有効化する必要があります。
lab-cmk の詳細画面で「キーのアクション」ドロップダウンから「有効」を選択します（Disabled のキーではこの項目が「有効」、Enabled のキーでは「無効」と表示されます）。
確認ダイアログは表示されず、ステータスが「有効」（Enabled）に変わります。
CloudShellで再度暗号化を試みます。
aws kms encrypt \
--key-id <キーID> \
--plaintext "TestData" \
--region ap-northeast-1今度はエラーなく暗号化が成功し、CiphertextBlob が返されることが確認できます。
手順6: CloudWatch Alarmでキー削除スケジュールを検知する設定
CMKの削除がスケジュールされた際に即座に検知できるよう、CloudWatch Alarmを設定します。
上部の検索バーに CloudWatch と入力し、表示された「CloudWatch」を選択します。
左側ナビゲーションの「ログ」→「ログ管理」を選択します。
CloudTrailのログが配信されているロググループを選択します。
メトリクスフィルターの作成
ロググループの詳細画面下部にある「メトリクスフィルター」タブを選択し、「メトリクスフィルターを作成」をクリックします。3ステップのウィザードが開きます。
「ステップ 1: パターンを定義」で以下を入力します。
- フィルターパターン:
{ ($.eventName = "ScheduleKeyDeletion") }
入力候補のドロップダウンが開いたままだと下の項目が隠れるので、Esc キーか画面の余白をクリックして閉じます。
「次へ」をクリックし、「ステップ 2: メトリクスの割り当て」で以下を設定します。
- フィルター名:
KMSKeyDeletionScheduled - メトリクス名前空間:
CloudTrailMetrics（既存の名前空間がない場合は「新規作成」がオンのまま入力します） - メトリクス名:
KMSKeyDeletionScheduledCount - メトリクス値:
1 - デフォルト値 – オプション:
0
「次へ」をクリックし、「ステップ 3: プレビューと作成」で内容を確認して「メトリクスフィルターを作成」をクリックします。
アラームの作成
メトリクスフィルターの一覧に戻ったら、作成した KMSKeyDeletionScheduled の行を選択します（行を選択するまで「アラームを作成」は押せません）。
「アラームを作成」をクリックすると、別タブでアラームの作成ウィザードが開きます。メトリクスは選択したフィルターのものが自動で入っています。
「ステップ1: メトリクスと条件の指定」で以下を設定します。
- 統計:
合計（デフォルト） - 期間:
5 分（デフォルト） - しきい値の種類:
静的（デフォルト） - アラーム条件:
以上（デフォルトは「より大きい」） - しきい値:
1
「次へ」をクリックし、「ステップ2: アクションの設定」で通知を設定します。
- アラーム状態トリガー:
アラーム状態（デフォルト） - 次の SNS トピックに通知を送信: 「既存の SNS トピックを選択」で既存のトピックを選ぶか、「新しいトピックの作成」でトピック名と通知先メールアドレスを入力します
「次へ」をクリックし、「ステップ3: アラームの詳細の追加」でアラーム名を設定します。
- アラーム名:
KMSKeyDeletionScheduledAlarm
「次へ」をクリックし、「ステップ4: プレビューと作成」で内容を確認して「アラームの作成」をクリックします。
作成直後はまだメトリクスのデータ点がないため、アラームの状態は「データ不足」と表示されます。
この設定により、ScheduleKeyDeletion APIが呼び出されると5分以内にアラームが発報され、SNS経由で通知が送信されます。通知を受けたら、待機期間中に CancelKeyDeletion を実行してCMKの削除をキャンセルできます。
まとめ
KMS CMKの削除は、暗号化データへのアクセスを永久に失うリスクがあるため、適切な対処と予防策が重要です。
| 状況 | 対処方法 | 結果 |
|---|---|---|
| 待機期間中（7-30日） | CancelKeyDeletion APIで削除をキャンセル | キーは Disabled 状態になる。EnableKey で再有効化が必要 |
| 待機期間終了後（CMK削除済み） | AWS Supportに削除されたCMKの復元を依頼 | CMKが復元されれば、暗号化データを再び復号できる |
| 予防策 | IAMポリシー / SCP で ScheduleKeyDeletion を拒否 | 権限のないユーザーによる削除スケジュールを防止 |
| 検知策 | CloudWatch Alarm で ScheduleKeyDeletion を検知 | 削除がスケジュールされた時点で即座に通知を受けられる |
CMK削除のインシデント対応で最も重要なポイントは以下の通りです。
PendingDeletion状態になった時点で暗号化・復号は即座に使用不可になる- 待機期間中であれば
CancelKeyDeletionで復旧できる - CMKが完全に削除された場合は、AWS SupportにCMK自体の復元を依頼する（S3やEBS個別のデータリカバリではなく、CMKの復元が根本的な解決策）
- CloudWatch AlarmやSCPによる予防策を事前に設定しておくことで、インシデント自体を防止できる
参照先
- AWS Key Management Service の概念
- AWS KMS キーの削除
- AWS KMS keys の削除のスケジュールとキャンセル
- キー状態が暗号化オペレーションに及ぼす影響
- AWS KMS での AWS CloudTrail の使用
- CloudWatch Logs でのメトリクスフィルターの作成
