Logo

安全與隱私白皮書（總覽）第 4 章

第 4 章 驗證、授權與存取控制

本章定義 FileBolt 的身分模型、權杖分層與存取控制邊界。 上傳與下載使用短效存取權杖（伺服器端工作階段、以查表為基礎、會過期、限定範圍）來管控密文與 manifest 的存取。 寄件者的管理操作則使用儲存在用戶端的長效登入權杖。系統 MUST 支援撤銷，且稽核資料 MUST 僅對寄件者可見。

4.0 摘要

  • 短效存取權杖：管控密文／manifest 的存取；伺服器端工作階段（查表）；MUST 綁定 transferId；MUST 限定範圍；MUST 會過期。
  • 長效登入權杖：用於寄件者管理（刪除／撤銷／稽核）；儲存在用戶端；收件者 MUST NOT 使用它來存取密文。
  • 金鑰與授權分離：權杖只控制密文的存取；解密能力來自 URL 片段中的 CEK（參見第 5 章）。

4.1 身分模型

  • 系統為寄件者管理提供付費使用者的身分模型。
  • 寄件者登入 MAY 使用一次性的魔法連結；驗證成功後，用戶端會儲存長效登入權杖。
  • 預設下載時，收件者不需要擁有帳號（參見 UX 文件）；存取由連結／權杖控制。

4.2 授權模型與權杖分層

系統使用兩種權杖，且職責嚴格區分：

  1. 短效存取權杖（工作階段／查表）：用於上傳／下載密文與讀取 manifest；MUST 綁定 transferId；MUST 會過期；MUST 依操作限定範圍。
  2. 長效登入權杖：用於寄件者管理操作；MUST NOT 授予解密能力。

4.2.2 範圍範例

  • upload_chunk：為特定 transferId 上傳密文分塊。
  • read_manifest：讀取特定 transferId 的 manifest。
  • download_chunk：為特定 transferId 下載密文分塊。

4.3 上傳授權

  • 上傳 API MUST 在接受密文之前，先驗證權杖範圍與 transferId 的綁定。
  • 分塊上傳 SHOULD 針對 (transferId, fileId, chunkIndex) 具備冪等性。
  • 遇到無效權杖或不一致時，系統 MUST 失敗即關閉。

4.4 下載授權

  • 存取 manifest 與密文 MUST 需要有效且限定範圍的權杖；權杖 MUST 有時效限制。
  • 收件者 MUST NOT 能夠列舉其他傳輸，或存取所綁定 transferId 以外的分塊。
  • 為防止濫用，MAY 套用速率限制（參見第 7 章），但不得破壞可續傳性。

4.5 撤銷與提前失效

  • 寄件者 MUST 能夠撤銷傳輸；撤銷 MUST 使權杖無法用於後續存取。
  • 在可行的情況下，撤銷 SHOULD 觸發密文的清理／加速 TTL 到期。
  • 收件者端的使用體驗 MUST 清楚顯示已撤銷／已過期的狀態，以及下一步（聯絡寄件者）。

4.6 稽核與權限隔離

  • 交付證據（下載、次數）預設 MUST 僅對寄件者可見。
  • 稽核 API MUST 要求寄件者驗證，且 MUST 與收件者的存取權杖隔離。

4.7 日誌與敏感資料最小化

  • 日誌 MUST NOT 包含 URL 片段、CEK 或可推導出的金鑰材料。
  • 日誌 SHOULD 將個人資料降到最低，並聚焦於與安全相關的事件（權杖失敗、撤銷、速率限制）。
  • 錯誤訊息 MUST 能讓人據以行動，但不得洩漏機密。

4.8 相關聲明 ID