安全なリンク共有のベストプラクティス：ダウンロードURLを保護

安全なダウンロードリンクは、URL 自体を鍵の一部として扱います。スラッシュ以降のスラグは最低でも128ビットのエントロピー（例：hexatransfer.com/d/7Kj9xQmN2vP8rBwLsE4fT）を持ち、日単位ではなく時間単位で有効期限が切れ、ダウンロードを1〜2回に制限し、そして唯一の秘密であってはなりません。これをパスワード導出の AES-256-GCM 鍵と組み合わせ、その鍵を URL フラグメント（# の後）に置けば、サーバーのアクセスログに届きません。これにより Slack のプレビューや企業のプロキシアーカイブなど、最も一般的なリンク漏洩経路のほとんどを遮断できます。

エントロピー：推測可能性の数学

6文字のスラグ（英数字）には 36^6 = 21億通りの組み合わせがあります。大きく聞こえますが、ボットネットが CDN に対して毎秒10万の URL をテストできることを考えると、認証されていない攻撃者は約6時間でその全空間を網羅できます。128ビット（base64url で22文字）に増やすと、推測に要する時間は太陽の熱的死を超えます。crypto.getRandomValues() を使い、Math.random() は絶対に使わず、データベース ID をエンコードすることもしないでください。連番トークンは、1週間間隔で2つのサンプルを収集するだけで転送量を誰にでも漏らします。

鍵をパス部分ではなくフラグメントに置く

URL の # 以降はフラグメント識別子で、ブラウザはサーバーに送信しません。復号鍵をそこに保存することは Firefox Send が先駆けたパターンです（例：/#k=abc123xyz）。サーバーには不透明なダウンロードスラグのみが見え、そのアクセスログや SIEM エクスポートや侵害ダンプには鍵素材が含まれません。CDN エッジキャッシュもペイロードを復号できません。 Slack のアンファールは URL をプローブする際にフラグメントを削除するため、プレビューボットは鍵を見ることがありません。このたった一つの対策で、実用的なリンク傍受攻撃の80% をブロックできます。

脅威に合わせた有効期限の設定

7日間のデフォルト有効期限はほとんどの用途には長すぎます。ワークフローに合わせて調整してください。銀行への送金 .pdf には15分のウィンドウ、契約書のレビューには4時間、写真アルバムには24時間、非同期の国際コラボレーションのみに7日間です。有効期限を署名済み URL ペイロード内の絶対 UTC タイムスタンプとして表現し、サーバーサイドで強制してください。クライアントサイドの時計は信用してはいけません。有効期限が切れたら、ディスク上の暗号文をゼロで上書きします（NVMe では blkdiscard 経由が理想）。これにより後から行われたディスクフォレンジクスでは何も見つかりません。

実際に機能するダウンロードカウンター

1回ダウンロードのリンクは万全に見えますが、ブラウザが部分的な転送を積極的に再試行することを考えると問題があります。 Chrome が80% で切断して新しい Range リクエストで再開した場合、これは2回のダウンロードとカウントされるでしょうか。カウンターは HTTP リクエストごとではなく、ファイル完了の境界で実装してください。最終バイトが送信され、認証タグが検証されたときにのみインクリメントします。あるいは10分のウィンドウで一意のセッション ID を追跡します。1セッション = 1ダウンロード、Range リクエストの数に関わらず。 WeTransfer はこれらを混同しており、リンクが消費済みと誤って表示されると批判されてきました。

短命トークンによる署名付き URL

エンタープライズのフローでは、ダウンロード URL を（スラグ、有効期限、最大ダウンロード数、発行者 ID）に対する HMAC-SHA256 署名でラップします。サーバーはバイトを提供する前に署名を検証します。S3 の事前署名 URL はこれをネイティブに実行し、R2 と Backblaze B2 も同じパターンに従います。Slack に漏洩した署名付き URL はまだ危険ですが、短い有効期限（例：5分）が被害を制限します。IP バインディングと組み合わせることで、署名が予想する /24 プレフィックスを含むリンクの地理的な転送を阻止できます。

リファラーとプレビューからの漏洩を防ぐ

ダウンロードページに Referrer-Policy: no-referrer を設定しない限り、ブラウザはリファラーヘッダーにフル URL（フラグメント除く）を送信します。このヘッダーがなければ、ダウンロードページから外部リンクをクリックすることで、宛先のすべてのトラッカーにスラグが漏洩します。また X-Robots-Tag: noindex, nofollow を設定し、/d/ をブロックする robots.txt を設定することで、フォーラムに誤ってリンクが貼られても Googlebot がリンクをアーカイブしないようにします。 Slack や Teams のプレビューには、アンファールボットに一致する User-Agent に対して 204 No Content を返します。

転送制御と受信者バインディング

Alice が Bob にリンクを送ったら、Bob はそれを誰にでも転送できます。これを防ぐには、リンクを Bob の身元にバインドします。強度の増す順に選択肢を示します。メール認証（bob@firm.com へのワンタイムトークン）、SMS 認証（電話番号への OTP）、初回訪問時のパスキー登録、Bob の Google Workspace 経由の OIDC ログイン。各ステップはフリクションと引き換えに封じ込めを強化します。GDPR 第15条の本人開示レスポンスにはメール認証で通常十分です。HIPAA 規制の検査結果にはパスキーまたは OIDC が適切です。

オンデマンドの取り消し

すべての対策を講じても、何かうまくいかないことがあります。ラップトップの盗難、請負業者の解雇、誤った受信者。リンクを即座に無効化する取り消しボタンが重要です。実装として、スラグハッシュをキーとする取り消しリストを保持し、ダウンロードのたびに確認します。Cloudflare の /zones/:id/purge_cache などのパージ API 経由で60秒以内に CDN エッジに伝播させます。 HexaTransfer は送信者のダッシュボードで取り消しを提供しています。 Dropbox Transfer と Smash もサポートしていますが、追加料金がかかります。取り消し機能を四半期ごとにテストしてください。インシデント時に機能しない取り消しボタンは、ないよりも悪いです。

監視はするが監視社会にはしない

不正使用を検出するのに十分なだけログを取り（IP ハッシュ、User-Agent ファミリー、タイムスタンプ、提供バイト数）、受信者の身元を再構成できるほどは取りません。IP は日次ローテーションキーでハッシュ化し、相関の時間窓を短くします。URL フラグメントは絶対にログに記録しないでください。30日間の保持期間は SOC 2 Common Criteria 7.2 を満たしつつ、監視アーカイブを作らずに済みます。ダッシュボードで送信者に不正使用カウンターを公開し、「AS15169 からの3回のパスワード試行失敗」を見たら取り消すべきとわかるようにします。

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