第3章 システムアーキテクチャとデータフロー

ドキュメントのメタデータ

ホワイトペーパーのバージョン

v1.0

最終更新日

2026-01-14

3.1 コンポーネント

• クライアント：ファイルのチャンク分割、暗号化と復号、URL フラグメント内の CEK の管理を行います。
• API/エッジ：スコープ付きのトークンを発行・検証し、マニフェストと暗号文のチャンクを配信します。
• オブジェクトストレージ：暗号化されたチャンクとマニフェストを保存します。平文の機密性の観点では、信頼できないものとして扱います。
• 状態ストア：最小限のメタデータで、転送の状態（アップロードの進捗、有効期限、取り消し）を管理します。

3.2 データオブジェクト

• マニフェスト：チャンクの取得と組み立てに必要な公開パラメータ（cryptoVersion、チャンクサイズ・チャンク数、対応関係）。CEK を含んではなりません（MUST NOT）。
• チャンク：暗号化されたファイルの断片（暗号文）と、最小限のメタデータ（長さ・etag）。（transferId, fileId, chunkIndex）で特定されます。
• 状態：認可、TTL、取り消し、再開に関するサーバー側のレコード。

3.3 アップロードのフロー

1. クライアントは転送を作成し、transferId に紐づく、有効期間の短いスコープ付きアップロードトークンを受け取ります。
2. クライアントは、ファイルごとの CEK をローカルで生成し、ファイルを固定サイズのチャンクに分割して、各チャンクを AEAD で暗号化します。
3. クライアントは暗号文のチャンクを並列でアップロードします。再試行はチャンク単位で冪等です。
4. クライアントはマニフェスト（公開パラメータのみ）をアップロードします。必要な部分がそろうと、サーバーは転送を READY とします。

3.4 ダウンロードのフロー

1. 受信者が共有リンクを開きます。URL フラグメント（CEK の素材）はブラウザー内にとどまり、サーバーには送信されません。
2. クライアントは、スコープ付きのダウンロードトークンでマニフェストを取得し、チャンクの取得計画を決定します。
3. クライアントは暗号文のチャンクをダウンロードし（必要に応じて並列で）、AEAD の認証を検証してから、平文のファイルを組み立てます。
4. 失敗した場合、クライアントは不足しているチャンクだけを要求して再開します。完全性の検証に失敗した場合は、フェイルクローズしなければなりません（MUST）。

3.5 送信者による管理と監査のフロー

• 送信者は、管理操作のために、（クライアントに保存された）有効期間の長いログイントークンで認証します。
• 管理 API では、転送の一覧表示、配信の証跡の確認、転送の取り消しや削除ができます。
• 監査データは送信者のみが閲覧できるように設計されており、既定では受信者には公開されません。

3.6 可視性と最小化

• サーバーとストレージが扱うのは暗号文と必要な公開パラメータのみで、CEK がなければコンテンツを復号できません。
• ログと分析は最小限にとどめることが望まれ（SHOULD）、URL フラグメントや CEK の素材を含めてはなりません（MUST NOT）。
• メタデータの収集は、目的を限定することが望まれます（SHOULD。配信の証跡、不正利用の防止、運用上の信頼性）。