ファイル転送ツール向けプライバシー・バイ・デザイン原則

ファイル転送ツールにおけるプライバシー・バイ・デザインとは、ユーザーが設定を一切変更しなくても、デフォルトの状態で個人データが保護されている構造を指します。 GDPR 第25条はこれを2種類に分類しています。第25条第1項「設計段階からのデータ保護」は、計画フェーズから適切な技術的措置を製品に組み込むことを義務付けます。第25条第2項「デフォルトによるデータ保護」は、初期設定が必要最小限のデータのみを処理し、必要な人にのみ共有し、必要な期間だけ保持することを求めます。転送ツールに当てはめると、クライアントサイド暗号化のデフォルト有効化、30日未満の有効期限、最小限のメタデータ収集、ワンクリックでのリンク無効化が必須要件となります。

Cavoukianの7原則をファイル転送に適用する

Ann Cavoukianが1990年代に提唱したフレームワーク — 事後対応ではなく予防的、デフォルトでプライバシー保護、設計への組み込み、全機能の維持、エンドツーエンドのセキュリティ、可視性と透明性、ユーザーのプライバシー尊重 — はファイル転送のアーキテクチャに直接対応します。予防的であるとは、SAST（静的解析ツール）でデプロイ前に脆弱な暗号を検出することです。デフォルト保護とは、 AES-256-GCM をオプトアウト不可で有効化することです。設計への組み込みとは、暗号化がアップロードパイプラインで行われ、別ステップにならないことです。全機能の維持とは、暗号化ファイルでもクライアントサイド復号によりプレビューが可能なことです。エンドツーエンドとは、プラットフォームが平文に触れないことです。可視性とは、暗号化仕様を公開することです。ユーザー尊重とは、保持期間と有効期限をユーザーが制御できることです。

第25条第1項：設計フェーズの義務

第25条第1項は「処理手段の決定時および処理時の両方において」措置を取ることを求めています。つまり、プライバシー義務はアーキテクチャ設計の段階で生じ、後から付け加えるものではありません。最初のコードを書く前に、トランスポートプロトコル（ TLS 1.3 を使用した HTTPS ）、暗号スイート（ AES-256-GCM または XChaCha20-Poly1305 ）、鍵導出関数（600,000回反復の PBKDF2-SHA-256 または Argon2id ）、ストレージリージョン（ EU ）を選択してください。将来のエンジニアが制約を理解できるよう、アーキテクチャ決定記録にこれらの選択を文書化することが重要です。

第25条第2項：デフォルト設定の義務

第25条第2項は4つのデフォルト要件を定めています。収集する個人データ量の制限、処理の制限、保持期間の制限、アクセス可能性の制限です。転送ツールに具体的に当てはめると、送信者と受信者のメールアドレスのみを収集（氏名・電話番号・住所は不要）、ファイルを一度処理したら削除、保持期間は7日間（無期限ではない）、検索エンジンにインデックスされる公開 URL ではなく特定の受信者のみアクセス可能、となります。 WeTransfer の無料版の公開共有リンクは便利ですが、追加的な保護措置なしでは第25条第2項に準拠しているとは言えません。

アップロードフローにおけるデータ最小化

送信者のアップロードフォームがデータ最小化の出発点です。悪い設計とは、送信者氏名・会社名・電話番号・受信者氏名・受信者会社名・メッセージを入力させることです。各フィールドが保存・分析される個人データになります。良い設計とは、メールアドレスのみ、オプションのメッセージ欄、トラッキングピクセルなし、です。 SwissTransfer と HexaTransfer はともに最小限のフォームを実装しています。 WeTransfer や Dropbox Transfer はより多くの情報を収集します。画像からはサーバーサイドで EXIF メタデータを除去してください。ファイル名に個人データが含まれる場合はログに記録せず、監査証跡にはハッシュ値を使用し、マッピングはサーバーサイドのみで管理します。

パフォーマンスを言い訳にしないデフォルト有効暗号化

2020年代のノートPCにおいて、ブラウザの Web Crypto API 経由で AES-256-GCM を実行すると約200〜500 MB/s の速度が出ます。100 MB のファイルの暗号化は1秒以内に完了します。 Libsodium の XChaCha20-Poly1305 も同等の速度です。「パフォーマンスの問題があるから暗号化はオプション」という言い訳はもはや通用しません。ユーザーが保持する秘密（パスワードまたは URL フラグメントに埋め込まれたランダムキー）から導出したファイルごとのキーを使用してください。 URL フラグメント（ # の後）はサーバーに送信されないため、サーバーはキーを知ることができません。 Firefox Send（2017〜2019年）のアーキテクチャが実証済みのパターンとして参考になります。

可能な範囲での仮名化

GDPR 第4条第5号が仮名化を定義しており、前文第28項ではその活用が推奨されています。ファイル転送においては、仮名化はシステムメタデータ内の直接識別子を置き換えることを意味します。監査ログでは sender@company.com を SHA-256 ハッシュに変換し、マッピングテーブルをより厳格なアクセス制御のもとで別途保管します。受信者も同様です。攻撃者が監査ログだけを侵害しても、連絡先グラフではなくハッシュ値しか見えません。マッピングテーブルは小規模で別のヴォールトに置かれ、異なるキーとアクセスポリシーで保護されます。

公開されたアーキテクチャによる透明性

第25条はオープンソースを義務付けてはいませんが、透明性はプライバシー・バイ・デザインの原則です。公開すべき内容：暗号化仕様（暗号アルゴリズム、 KDF 、反復回数、認証タグ長）、データフロー図、サブプロセッサーリストと管轄地域、保持スケジュール、侵害通知タイムライン、監査ログスキーマ。 Proton 、 Tresorit 、 HexaTransfer はいずれも技術的なホワイトペーパーを公開しています。「軍事級暗号化」のような検証不可能な曖昧なセキュリティ主張は危険信号です。暗号アルゴリズムを明示しないプロバイダーは、セキュリティが弱いと考えるべきです。

プレミアム機能ではなくデフォルトとしてのユーザー制御

プライバシー・バイ・デザインは、制御機能が有料プランの裏に隠れた時点で台無しになります。パスワード保護リンクに追加料金が必要であってはなりません。ダウンロード制限がプレミアム機能であってはなりません。リンクの無効化にサポートへの問い合わせが必要であってはなりません。最低限のプライバシー保護 — 有効期限、パスワード、無効化、ダウンロード通知 — は無料で利用可能であるべきで、有料プランはスケール（ストレージ、チーム管理）や利便性（ブランドリンク、長期保持）で差別化すべきです。これは GDPR 対応としても、商業的観点からも正しい姿勢です。

プライバシー原則に沿ったログ記録

監査ログ自体が個人データです。記録しすぎると新たな侵害リスクが生まれ、少なすぎると第33条を満たせず、第5条第2項に基づくコンプライアンス証明も困難になります。適切な記録内容：イベント種別、タイムスタンプ、ファイル ID ハッシュ、アクター ID ハッシュ、結果。完全な IP アドレスはログに残さず、 IPv4 は /24 、 IPv6 は /64 に切り詰めます。ユーザーエージェントはブラウザファミリーとメジャーバージョンのみを抽出します。セキュリティとコンプライアンス上必要な最小限の期間（通常6か月）保持した後、削除します。ログパイプライン自体をエンドツーエンドで暗号化し、ログへのアクセスもイベントとして記録します。

ローンチ前のポスチャーテスト

ビルドに関与していない新しいエンジニアがデータフロー監査を実施してください。各システムについて、どの個人データが通過するか、どこに保存されるか、どのくらいの期間か、誰がアクセスできるか、アクセスはどのようにログに記録されるか、どのように削除されるかを確認します。回答を DPIA に文書化された第25条のコミットメントと比較してください。記載されたアーキテクチャに対してペネトレーションテストを実施し、サーバーが実際に暗号文しか見ていないか、 URL フラグメントのキーが本当にログから除外されているかを確認します。プライバシー・バイ・デザインの主張が曖昧なサービスはこうしたテストで素早く破綻します。 HexaTransfer の7日間有効期限とクライアントサイド AES-256-GCM のアーキテクチャは、ドキュメントが設計の通りに動作しているため生き残ります。

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