DATA LIFECYCLE / PRACTICAL DESIGN

保存から削除まで、
データの行き先を管理する。

暗号化した住所が、ログや検索インデックスに平文で残っていたら。削除した住所が、バックアップから戻ってきたら。保管庫の外側までつながる設計を説明します。

業務データと本人情報を分ける。

通販の例では、注文を扱うシステムには代理ID・注文番号・商品・配送状況を置き、氏名・住所・電話番号は保管庫で管理します。配送時だけ、認可された処理が代理IDを使って必要な本人情報を取得します。

注文システム：注文番号 / 代理ID / 商品 / 配送状況
保管庫      ：代理IDに対応する氏名・住所・電話番号の暗号文
配送処理    ：配送に必要な項目を、許可された期間だけ取得

注文DBだけを取得されても、住所まで直接読める構造を減らせます。ただし注文履歴や代理IDにも、他の情報と組み合わせて本人を特定できるリスクがあります。代理IDへの置き換えは、情報の匿名化を保証するものではありません。

この節の検索インデックス・連携先への削除通知・鍵の完全消去などは、連携を考えるための設計例です。現行の住所APIに検索、削除通知の自動配信、バックアップの即時物理消去を提供する機能はありません。実際のAPIと対応範囲は導入ガイドで確認できます。使い方・導入ガイド

ランダムなnonceを使う暗号化では、同じメールアドレスでも暗号文が変わります。そのまま通常の完全一致検索はできません。まず代理IDや注文番号で検索できる業務設計を優先します。本人情報で照合する必要がある場合は、別の検索用インデックスを設計します。

メールアドレスを定めたルールで正規化し、テナントと項目ごとに分離した検索鍵でHMACを計算します。検索時にも同じ計算をして候補を探し、認可後に元データを確認します。これは復号できる暗号文ではなく、照合用の値です。

単純なハッシュだけでは、候補のメールアドレスや電話番号を計算して照合され得ます。HMACも検索鍵が漏れれば推測照合が可能です。同じ値が繰り返されることや出現頻度は隠せず、検索API自体の大量照会にも制限が必要です。

部分一致・前方一致・範囲検索は追加の情報を露出させたり、処理量を増やしたりします。「どんな検索でも安全にできる」とせず、必要な検索機能、漏れる情報、速度を合わせて評価します。検索鍵の更新ではインデックスの再生成も必要です。

削除は画面から消すだけで終わりません。例えば退会した利用者の住所は、通常の取得を止めたあと、本体、検索用インデックス、キャッシュ、複製、連携先に反映します。バックアップの保持期限と復元時の扱いも記録します。

暗号学的消去は、対象データを復号する鍵を復旧不能にする方法です。対象専用の鍵であること、鍵のバックアップ、ラップ済み鍵、キャッシュ、管理サービスの復元機能も含めて再取得できないことが条件です。共有鍵を消すと他の利用者の情報まで読めなくなります。

鍵の無効化は、再び有効化できるなら不可逆な消去ではありません。また、すでに取り出された平文や別の鍵で保存されたコピーは消えません。取得停止・稼働データ削除・バックアップ期限到来を別の状態として記録します。

昨夜のバックアップを戻すと、今日削除した住所が再出現する可能性があります。復旧は隔離した環境で行い、削除記録と最新の失効状態を再適用し、完了を確認してから利用を再開します。削除記録も同じ古いバックアップだけに入っている構成では、最新の削除を再現できません。

RPO：失ってよいデータの時間幅: 例えば15分という目標なら、障害直前の最大15分の更新が失われ得ます。実際の複製・バックアップ方式と試験結果で確認します。
RTO：復旧までの時間: 例えば2時間という目標なら、DBだけでなく、鍵の利用、権限、削除記録の反映と動作確認を含めて測ります。ここでの数字は説明用で、サービス保証値ではありません。
復旧試験の確認: 有効なデータを復号できるか、削除した対象を取得できないか、古いトークンが拒否されるか、鍵障害時に情報を露出せず停止するかを確認します。
残す証跡: 処理の主体・対象参照・時刻・結果・鍵バージョンを記録します。本人情報や生のトークンをログに複製しないようにします。

データの所在図、復号できる主体の一覧、検索で露出する情報、削除対象と完了状態、復旧試験の結果。これらを確認すると、保管から利用・廃棄まで保護がつながっているかを判断できます。