バックアップはあるのに鍵がない。復旧に必要な情報の管理

バックアップの所在だけでなく、誰がどの条件で復号し、復元できるかを確かめる。

データが残ることと、読み戻せることを分ける

AWS KMSの資料は、鍵の削除が暗号化した情報を読み戻せなくする場合の影響を説明しています。SONAEは、暗号化したバックアップについて、情報の保管先と、使う鍵、認証、復元の手順を対応付ける方法を提案します。保存容量が使われていることだけで、必要な資料を取り出せるとは判断しません。鍵の種類や製品の方式によって条件は異なります。利用している構成で何に依存するかを確認し、一般的な説明を実環境の達成結果と混同しないようにしましょう。

鍵の値を集めるのではなく、管理の関係を残す

台帳には、対象のバックアップ、暗号化の方式、正式な鍵の識別情報、管理先の参照、責任者を記録します。秘密の値そのものを通常の手順書や共有表へ貼りません。外部の鍵管理サービスでは、秘密を取り出して別保存することが想定されていない方式もあります。なんでも鍵をコピーすればよいという計画にはしません。必要な担当が正規の方法で利用でき、ほかの担当が条件を確認できるよう、情報の所在と権限の関係を整理します。

鍵を管理する権限と、復元の権限を見る

バックアップを読む担当、鍵を利用する担当、鍵の設定や利用終了を管理する担当を分けて確認します。一人へまとめる場合も、できる操作と不在時の条件を明らかにします。通常の業務アカウントが使えない場面を想定しているなら、回復の入口も同じ障害の影響を受けないかを確認します。必要以上に権限を配ることを解決策にせず、用途と承認に沿って正式な担当へ相談します。管理の便利さと、誤操作や侵害の影響を合わせて判断しましょう。

変更や終了は、残るデータから判断する

鍵の無効化、削除、契約終了、アカウントの整理が、どのバックアップへ影響するかを確認します。AWS KMSでも、削除を予定した状態と実際に削除された状態などの条件があるため、正式な資料で確認します。使っていないように見えることだけで、過去のバックアップに必要な鍵を終えないようにします。本記事は鍵を削除する手順を示すものではありません。必要な保存期間や復旧計画と照らし、影響と承認を記録して判断するための確認表です。

架空データで、正規の入口を通る計画を作る

演習では、架空の暗号化資料、検証用の鍵の参照、限定した復元先、正規の担当を想定します。秘密の値をチャットへ貼らずに、利用できる入口と承認、記録を説明できるかを確認します。実際の鍵を発行、無効化、削除する作業は、この記事の制作には含めません。復号できたかだけでなく、原本の版と内容が合うか、別の資料を誤って戻していないかも受入へ入れます。模擬の成功を実際の復元試験の成功として報告しないことが大切です。

担当者の交代で、依存を切らないようにする

後任へ渡すのは秘密の値の一覧ではなく、用途、保管の管理、権限、承認、復元、利用終了の条件です。完了の目安は、対象のデータがどの鍵と入口に依存し、必要な期間を誰が管理するかを会社が説明できることです。保持ロックがあるから鍵の管理まで守られるとは扱いません。情報や製品が変わったら台帳も更新し、次の復元試験で確かめる項目を残します。保管の担当と回復の担当が、同じ前提を共有できる形にしましょう。

相談前の確認表

• データと鍵の依存を対応付けた
• 秘密の値を共有台帳へ貼らない
• 鍵の終了と保存期間を照合する
• 担当不在の復旧入口を確認した

参考資料（確認日：2026年10月23日）：AWS KMS Developer Guide：Deleting keys ↗ ／ AWS S3 User Guide：Object Lock considerations ↗

一般的な説明とSONAEの運用提案です。製品の公式条件と自社の管理責任者の判断を確認してください。