忘れられる権利とファイル共有:必須知識

GDPR 第 17 条（忘れられる権利）は、ファイル共有サービスとその顧客に対し、特定の免除が適用されない限り、要求から 1 か月以内に個人データを削除することを義務付けています。サブプロセッサが保持するコピーやバックアップ内のコピーも対象に含まれます。ファイル転送においてこれが意味するのは、ホットオブジェクトストレージ、CDN キャッシュ、コールドバックアップ、ファイルをダウンロードした下流の受信者—すべてのストレージ層に届く削除メカニズムが必要だということです。7〜30 日の自動有効期限を持つサービスは、ほとんどの削除要求をデフォルトで対処します。無期限にファイルを保持するサービスには、文書化・テスト済みの削除ワークフローが必要です。

第 17 条（1）が実際に要求すること

第 17 条（1）は削除を発動させる六つの根拠を列挙しています。データが当初の目的にとって不要になった（a）、データ主体が同意を撤回した（b）、データ主体が第 21 条に基づいて異議を唱え、優先する正当な根拠が存在しない（c）、データが不法に処理された（d）、削除を義務付ける法的義務（e）、第 8 条（1）に基づいて収集された子供のデータ（f）。ファイル共有では（a）と（b）が主要な根拠です。クライアント納品物の「目的上必要な」デフォルト期間は、プロジェクト期間プラス紛争解決のための短いテール期間であり、通常 12 か月を超えません。

1 か月の応答期限

第 12 条（3）は管理者に 1 か月の応答期限を与え、複雑な場合はデータ主体への通知を条件として 2 か月の延長を認めています。これは応答の期限であり、技術的な削除の期限ではありません。しかし、JIRA チケットで手動削除しているなら受領から 3 週間後には間に合わない可能性があります。DELETE /transfers/{id} が 204 を返す API 駆動の削除があれば、残業なしに期限を守れます。チケットが承認されたとき自動的に削除呼び出しが発火するよう、GDPR リクエスト受付フォームに削除呼び出しを組み込んでください。

バックアップ・キャッシュと「カスケード」問題

プライマリストレージからファイルを削除しても、昨日のバックアップ、先週の CDN エッジキャッシュ、受信者のラップトップからは削除されません。第 17 条に関する EDPB ガイダンス（2019 年公開、2022 年改訂）は、バックアップには遅延があることを認めつつも、削除スケジュールを文書化すること—通常は 90 日以内のフル世代交代—と、バックアップデータをアクティブなシステムに復元しないというコミットメントを要求しています。CDN キャッシュについては、無効化呼び出し（ Cloudflare のパージ API、AWS CloudFront 無効化）を削除パイプラインに含める必要があります。受信者のコピーについては、第 17 条（2）に基づいて通知し、その通知を文書化してください。

構造的な削除としてのリンク有効期限

最もクリーンなコンプライアンス経路は、必要以上にファイルを保持しないことです。短期リンクを前提としたサービス—SwissTransfer（30 日）、Firefox Send（1〜7 日、現在はサービス終了）、WeTransfer Free（7 日）、 HexaTransfer（7 日）—は、誰かが要求したかどうかに関わらず自動的に削除します。これは第 25 条の「プライバシー・バイ・デザイン」です。転送ツールを構築または選択する際に、デフォルトの有効期限を 30 日未満に設定すれば、ファイルが既に存在しないため、ほとんどの削除要求はノーオペレーションになります。

第 17 条（3）の免除事項

第 17 条（3）は五つの免除を列挙しています。表現の自由（a）、保持ルールを含む法的義務（b）、健康における公共の利益（c）、公共の利益・科学的・歴史的研究のためのアーカイブ（d）、法的請求の設定または防御（e）。ファイル共有では（b）と（e）が発生します。クライアントと共有した PDF 契約書は、消費税規制上 7 年間または商法上 10 年間保持が必要な場合があります。保持法を文書化し、実行可能な範囲で仮名化し、要求に応じて削除しないでください。理由を法的根拠とともに書面で文書化してください。

改ざん防止ストレージのための暗号化削除

一部のストレージシステム（不変オブジェクトストレージ、WORM バックアップ、特定のブロックチェーン近接アーカイブ）は物理的にデータを上書きできません。暗号化削除—暗号文を回復不能にするために暗号化鍵を破棄すること—は、暗号が強力（AES-256-GCM 以上）で鍵が適切に保護されていた場合、ENISA と EDPB によって GDPR の目的においての削除と同等と見なされます。ファイルまたは転送ごとのキーを使用しているサービスは、キーを破棄することで削除要求に応えられます。残った暗号文は誰も復号できません。この方法はテラバイト単位の上書きより高速で、不変システムでも機能します。

削除ログと説明責任原則

第 5 条（2）は管理者にコンプライアンスを証明することを要求します。削除ログがその証拠になります。各削除について記録してください。要求日、データ主体の識別情報、チケット参照番号、対象システム（プライマリストレージ、バックアップ、CDN、受信者通知リスト）、削除方法（API 呼び出し、鍵破棄、上書き）、完了タイムスタンプ、オペレーター。ログ自体の 6 か月保持が一般的な基準です。一部のプロバイダはデータ主体に転送できる「忘れられる権利確認書」PDF を提供しています。監督機関からの問い合わせが想定される期間、通常 3 年間は記録を保持してください。

共有フォルダと下流の受信者

5 人の受信者に送ったファイルは、5 つのメールボックスプラス 5 台のローカルハードドライブに存在します。第 17 条（2）は管理者に、技術的措置を含む合理的なステップを取り、削除要求があったことを処理している他の管理者に通知することを要求します。「合理的」はリスクによって変わります。50 人のジャーナリストに送った公開エグゼクティブサマリーなら「合理的」はほぼゼロです。3 人の専門家に送った医療報告書なら、各専門家への削除要求メールが「合理的」です。通知を記録してください。義務は努力であり、成功ではありません。

削除権の自動化

効率的なパターンは、ユーザー識別子が与えられると、そのユーザーが関わるすべての転送（送信者または受信者のメールとして）を列挙し、プライマリとキャッシュ層全体でそれらを削除し、CDN エッジを無効化し、バックアップ抑制をトリガーし、コンプライアンス受領書を発行する単一の API エンドポイントです。 Tresorit、 Proton Drive、 Box Enterprise はその変形を公開しています。 HexaTransfer のモデル—クライアントサイド暗号化による 7 日間の自動有効期限—は問題を単純化します。要求が届いたとき、ほとんどのファイルはすでに消えており、残った暗号文はユーザーが保持するキーなしには役に立ちません。

削除を最初から設計に組み込めば、削除権は自然と解決します。

hexatransfer.comでお試しください — 無料、登録不要、最大10GB。