backup-retention-erasure

バックアップの保持と消去の管理

概要

バックアップおよびアーカイブシステムでは、データの保持と消去に関するコンプライアンスにおいて、特有の課題が生じます。個々のレコードを選択的に削除できるプライマリシステムとは異なり、バックアップメディアでは通常、復元せずに部分的な変更を行えない一括データセットとしてデータが保存されます。データ主体がGDPR第17条に基づく消去の権利を行使した場合や、保持期間が終了した場合、組織はバックアップに保存されている個人データに対処する必要があります。バックアップから粒度の細かい削除を行うことが技術的に困難である点は、認識されている制約ですが、組織の義務が免除されるわけではありません。バックアップのローテーション、または復元して削除する手順によって最終的に削除するまでの暫定措置を文書化する必要があります。このスキルでは、保持および消去義務に基づいてバックアップデータを管理するための運用フレームワークを提供します。

法的背景

GDPR前文第66項 — オンライン環境における消去

消去の権利は、管理者が個人データを公開した場合にも適用されるべきです。管理者は、そのデータを処理している他の管理者に知らせるため、合理的な措置を講じるべきです。バックアップの文脈では、この原則により、即時の削除が技術的に困難な場合でも、消去義務をバックアップコピーにまで適用する必要があります。

GDPR第17条(1) — 消去の権利

管理者は、個人データを「不当に遅滞することなく」消去しなければなりません。EDPBおよび各国のDPAは、バックアップシステムではより長い期間が必要になる場合があることを認めていますが、期限のない例外は認めていません。バックアップの削除は、次回のバックアップローテーションサイクル内に行うことが求められています。

バックアップの削除に関するICOガイダンス

英国のICOは、バックアップシステムからデータを直ちに消去することが技術的に不可能な場合、組織は以下を行うべきであると述べています。

1. バックアップデータを「利用不可」の状態にする。つまり、いかなる目的でもアクセスまたは利用できないようにします。
2. 次回バックアップが上書きまたはローテーションされる際に、データが削除されるようにします。
3. 対応方法と期間を文書化します。
4. バックアップデータの削除予定をデータ主体に通知します。

EDPBの見解

欧州データ保護会議は、さまざまなガイドラインにおいて、バックアップシステムでは消去に技術的な課題が生じる場合があることを認めています。一般的な見解は以下のとおりです。

• 稼働中のシステム／プライマリシステムからは、直ちに削除することが求められます。
• バックアップの削除は、バックアップローテーションサイクルに沿った合理的な期間内に行うべきです。
• 暫定期間中、バックアップ内のデータは「利用不可」の状態、つまり、いかなる目的でもアクセスされない状態でなければなりません。

バックアップシステムの種類と消去方法

バックアップの種類別消去戦略

バックアップの種類	説明	粒度の細かい削除が可能か	消去方法	一般的なサイクル
フルバックアップ（ディスクベース）	すべてのデータをディスクストレージに完全にコピーします	一般的に不可（フルバックアップを復元して選択的に削除することは可能ですが、リソースを大量に消費します）	ローテーションサイクルを待ちます。緊急のリクエストには復元して削除する方法を実施します	週次〜月次
増分バックアップ（ディスクベース）	前回のバックアップ以降の変更のみを保存します	不可	ローテーションサイクルを待ちます	日次
差分バックアップ（ディスクベース）	前回のフルバックアップ以降の変更を保存します	不可	ローテーションサイクルを待ちます	日次
テープバックアップ（LTO）	データを磁気テープに順次書き込みます	不可（テープは順次アクセス方式のため、全体を書き換えない限り選択的な削除はできません）	テープのローテーションサイクルを待ちます。長期保存用のテープについては、復元して削除する方法を検討します	月次〜年次
クラウドバックアップ（マネージド）	クラウドベースのバックアップサービス（例：AWS Backup、Azure Backup、Veeam Cloud Connect）	ベンダーによって異なります。一部では項目単位の復元と削除に対応しています	ベンダーの機能を確認します。粒度の細かい削除に対応していない場合は、保持ポリシーの期限切れを待ちます	設定されたポリシーに準拠
スナップショットベースのバックアップ	ストレージボリュームの特定時点のコピーです	不可（スナップショットは変更できません）	スナップショット保持ポリシーの期限切れを待ちます。ポリシーが保持スケジュールと一致していることを確認します	日次〜週次
データベースバックアップ（論理）	SQL ダンプ、エクスポートファイル	不可（ダンプファイルは単一のファイルです）	ローテーションを待ちます。または、一時的な環境に復元して削除し、再エクスポートします	日次〜週次
アーカイブ（コールドストレージ）	コールドストレージ／オフラインストレージでの長期アーカイブ（例：AWS Glacier、Azure Archive、テープ保管庫）	不可	消去リクエストには復元して削除する方法を実施します。または、アーカイブ保持ポリシーの期限切れを待ちます	年次〜複数年

バックアップ保持期間の整合

バックアップサイクルと保持スケジュールの整合

バックアップの保持期間は、適用される最長のデータ保持期間を超えてはなりません。バックアップが保持スケジュールを超えてデータを保持すると、組織は保存期間の制限原則に違反した状態でデータを保有することになります。

Orion Data Vault Corp のバックアップ保持設定

バックアップレベル	保持期間	ローテーションサイクル	保持スケジュールとの整合
日次増分	30日	30日後に最も古い日次バックアップを削除	すべてのデータカテゴリーの保持期間より短く、準拠しています
週次フル	90日	90日後に最も古い週次バックアップを削除	すべてのデータカテゴリーの保持期間より短く、準拠しています
月次フル	12か月	12か月後に最も古い月次バックアップを削除	ほとんどの保持期間より短いものの、CCTV（30日）と不採用応募者のデータ（6か月）は個別に除外する必要がある場合があります
四半期アーカイブ	24か月	24か月後に最も古い四半期アーカイブを削除	マーケティングデータ（2年）をカバーします。保持期間がより短いカテゴリーが不必要に含まれていないことを確認する必要があります
年次アーカイブ	7年	7年後に最も古い年次アーカイブを削除	最長の法定保持期間（財務記録：6〜7年）に整合しています

ギャップ分析

[For each data category in the retention schedule]
         │
         ▼
[What is the retention period?]
         │
         ▼
[Is this data included in backup sets that are retained longer than the retention period?]
   │
   ├── No ──► Compliant — backup rotation will delete data before or at retention expiry
   │
   └── Yes ──► COMPLIANCE GAP
               │
               ├── Option A: Exclude this data category from long-retention backup sets
               │     (segregate data by retention tier; back up separately)
               │
               ├── Option B: Reduce backup retention to match the shortest data category
               │     (may conflict with business continuity requirements)
               │
               └── Option C: Accept interim retention in backups with protective measures
                     (document "beyond use" controls; delete at next rotation)
                     MAXIMUM acceptable overshoot: 90 days beyond retention period

復元して削除する手順

バックアップの削除をローテーションサイクルまで待てない場合（例：緊急の第17条リクエスト、DPA による執行）は、次の手順を実施します。

PROCEDURE: RESTORE-AND-DELETE
Organization: Orion Data Vault Corp
Procedure ID: BKP-RAD-001

TRIGGER: Art. 17 erasure request where data exists only in backups
         and backup rotation will not occur within an acceptable timeframe

PREREQUISITES:
- All primary system deletion confirmed complete
- Backup system granular deletion confirmed infeasible
- DPO has approved restore-and-delete approach
- Next backup rotation > 90 days away

PROCEDURE:

Step 1: Identify Relevant Backup Sets
   - Query backup catalog for sets containing data subject's data
   - List all relevant backup sets with dates and storage locations
   - Estimated effort: [hours/days]

Step 2: Provision Isolated Restore Environment
   - Create isolated network segment (no connectivity to production)
   - Provision temporary storage sufficient for backup restoration
   - Apply access controls (authorized personnel only)
   - Enable full audit logging

Step 3: Restore Backup to Isolated Environment
   - Restore the backup set(s) to the isolated environment
   - Verify restoration integrity (checksum validation)

Step 4: Execute Granular Deletion
   - Identify and delete the data subject's records from the restored data
   - Verify deletion (query for data subject's identifiers — zero results expected)

Step 5: Create Replacement Backup
   - Export the cleaned data as a replacement backup set
   - Verify replacement backup integrity
   - Store replacement backup in the same tier as the original

Step 6: Destroy Original Backup
   - Delete or overwrite the original backup set containing the data subject's data
   - If tape: degauss and destroy the original tape
   - If disk: secure overwrite of original backup files
   - Generate destruction confirmation

Step 7: Decommission Restore Environment
   - Securely wipe the isolated restore environment
   - Release temporary storage
   - Disable the isolated network segment

Step 8: Documentation
   - Record all steps in the deletion confirmation record
   - Update the data subject's erasure request file with backup deletion confirmation
   - Log total time and resources consumed (for future planning)

ESTIMATED TIMELINE: 5-15 business days depending on backup size
ESTIMATED COST: [Track for each execution — informs cost-benefit analysis]

暫定的な保護措置（「利用停止」）

ローテーションまたは復元して削除するまで個人データがバックアップに残る場合は、次の暫定措置を実施する必要があります。

「利用目的外」の管理策

管理策	実装	検証
アクセス制限	プライマリシステムから削除済み、または保持期間を超過したデータのバックアップ復元リクエストには、DPO の承認が必要です	バックアップ復元リクエストを四半期ごとに監査
目的の制限	バックアップデータへのアクセスは、災害復旧または事業継続の目的に限ります。運用、分析、またはデータ主体からのリクエストには使用しません	ポリシーを文書化し、スタッフに研修を実施
復元時のスクリーニング	削除済みデータを含むバックアップを災害復旧のために復元する必要がある場合、本番環境に移行する前に、復元した環境から削除済みレコードを再削除する必要があります	復元手順に削除チェックリストを含める
抑制リスト	プライマリシステムからデータが削除されたデータ主体の抑制リストを維持します。バックアップを復元する際に照合し、再削除を確実に行います	復元のたびに抑制リストを確認
暗号化	すべてのバックアップメディアを暗号化します（AES-256）。暗号鍵は別途管理します。極端な場合、暗号鍵を破棄することでバックアップデータを復元不能にできます	鍵管理を年次監査
ログ記録	すべてのバックアップへのアクセス、復元、削除のイベントを改ざん不可能な監査証跡に記録します	監査ログを毎月確認

バックアップ復元手順（消去要件への準拠）

災害復旧のためにバックアップを復元する必要があり、プライマリシステムから削除済みのデータが含まれている場合：

[Disaster Recovery Event — Backup Restoration Required]
         │
         ▼
[Select Appropriate Backup Set for Restoration]
         │
         ▼
[Check: Does this backup pre-date any completed erasure requests or retention expiry deletions?]
   │
   ├── No ──► [Restore normally — no erasure compliance action needed]
   │
   └── Yes ──► [Retrieve Suppression List]
               │
               ▼
         [Restore backup to production environment]
               │
               ▼
         [IMMEDIATELY execute deletion of all records matching suppression list]
               │
               ├── Automated: Run deletion script against suppression list
               │   (pre-built script must exist — test quarterly)
               │
               └── Manual (if automated script fails): Assign to data team
                   with 24-hour SLA for completion
               │
               ▼
         [Verify deletion — zero records for suppressed data subjects]
               │
               ▼
         [Log re-deletion event in erasure confirmation records]
               │
               ▼
         [Resume normal operations]

コンプライアンスの監視

四半期ごとのバックアップ保持監査

確認項目	方法	期待される結果
バックアップの保持期間が保持スケジュールに準拠している	バックアップの保持設定を現在の保持スケジュールと照合する	該当する最長の保持期間を超えてデータを保持するバックアップ層がない
「利用目的外」の管理策が有効である	バックアップ復元のアクセスログを確認し、削除後のバックアップの復元すべてについて DPO の承認を得ていることを検証する	不正な復元がゼロ
抑制リストが最新である	抑制リストに、最も古いバックアップセットの日付以降にプライマリシステムから削除されたすべてのデータ主体が含まれていることを検証する	100%網羅
ローテーションへの準拠	最も古いバックアップセットの日付が想定されるローテーション日と一致していることを検証する	想定されるローテーション日から7日以内
暗号化の検証	すべてのバックアップメディアが暗号化されていることを検証する	暗号化率100%
復元後の削除の実行	保留中の復元後削除オペレーションについて、進捗状況とスケジュールを検証する	すべてのオペレーションが確約したスケジュール内

DPO への報告指標

指標	目標	頻度
バックアップ保持期間の平均超過日数（保持スケジュール超過分）	≤ 90日	四半期ごと
復元後の削除の完了時間	≤ 15営業日	実行ごと
抑制リストの件数（有効なエントリー）	推移を追跡	毎月
再削除が必要なバックアップ復元イベント	件数を追跡	四半期ごと
保持期間を超過したデータを含むバックアップセット	ゼロ（ローテーションサイクル後）	毎月