Summary

この文書の要点

どこが設計の難所か

ファイルアップロードを早く実装するために公開URLをそのまま保存すると、認証を通らずにアクセスできる経路が残ります。後から非公開化しようとしても、既存URLやキャッシュ、外部共有の扱いが問題になります。

画像プレビュー、PDFダウンロード、管理者確認、利用者自身の再取得など、ファイルの使われ方は複数あります。すべてをアプリ経由でストリーミングすると負荷が増え、すべてを公開URLにすると権限管理が弱くなります。

アップロードファイルは画像、PDF、CSVなど形式が違っても、業務上は権限、保持期間、ウイルスチェック、プレビュー、削除の扱いが問題になります。ストレージへ置くだけの実装では、誤公開や消し忘れが起きやすくなります。

ファイル本体はGCSやS3の非公開領域に置き、アプリDBに所有者、用途、MIMEタイプ、サイズ、保存パス、状態を保存します。閲覧時はアプリ側で権限を確認し、短時間だけ有効な署名付きURLを発行します。

設計では、ファイル本体はGCSやS3の非公開バケットへ置き、アプリDBには所有者、用途、MIME、サイズ、ハッシュ、状態、保持期限を保存します。利用者が閲覧する時だけ、権限確認後に短時間の署名付きURLを発行します。

アップロードは、アプリ経由と署名付きアップロードURLのどちらにするかをファイルサイズとUI要件で選びます。保存後にはMIMEタイプ、拡張子、サイズ上限を検証し、必要ならウイルススキャンや画像変換を非同期で行います。

アップロードは、予約レコード作成、署名付きURL発行、クライアントから直接アップロード、完了通知、検証、利用可能化の順に分けます。DB状態はpending、uploaded、verified、available、deletedのように持つと、途中失敗や再試行を扱いやすくなります。

検証では、権限のないユーザーがURLを推測しても取れないこと、期限切れURLが使えないこと、DBレコード削除後にストレージが掃除されることを確認します。大量ファイル時の一覧表示性能も見ます。

検証では、権限のないユーザーがURLを取得できないこと、期限切れURLが使えないこと、アップロード途中で失敗したファイルがavailableにならないことを確認します。大きいファイル、拡張子偽装、MIME不一致もテスト対象です。

署名付きURLは便利ですが、発行後の短時間はURLを知る人がアクセスできます。極めて機密性の高いファイルでは、アプリ経由で都度認証しながら配信する方が適する場合があります。

署名付きURL方式はアプリサーバーの負荷を下げますが、状態管理は複雑になります。アプリ経由で全ファイルを配信すると制御は単純ですが、容量と速度の制約が出ます。ファイルサイズと機密性で方式を分ける判断が必要です。

ファイル管理はアップロード画面だけの機能ではありません。非公開保存、権限確認、期限付き配信、削除の整合性をセットで設計することで、業務アプリの情報露出リスクを下げられます。

非公開ストレージの設計では、URLを隠すだけでは足りません。DB上の権限、状態、保持期間とストレージ上の実体を結び付けることが、安全なファイル運用の基盤になります。