安全與隱私白皮書(總覽)第 10 章
第 10 章:日誌、監控與事件應變
FileBolt 的可觀測性必須與零知識邊界保持一致:系統必須能夠找出故障、偵測攻擊並量化效能, 同時不引入新的敏感資料外洩途徑。本章定義哪些事件會被記錄、明確禁止記錄的資訊、告警與異常偵測的方法, 並詳述資安事件應變(IR)流程與對外溝通原則。
10.0 摘要
- SHOULD(應):日誌與監控僅涵蓋必要的營運與安全事件,並採用彙總與取樣,以盡量減少原始細節的保留。
- MUST NOT(不得):任何日誌、APM 或錯誤回報都不得包含 CEK、URL 片段(
location.hash),或含有片段的完整 URL。 - MUST NOT(不得):不得記錄明文內容、已解密的區塊,或可推導出的金鑰素材。
- MUST(必須):針對列舉、暴力破解、流量暴增與異常模式建立偵測與告警機制,並備妥遏止措施。
- MUST(必須):維持事件應變流程(分級研判、遏止、鑑識、補救、檢討、溝通)。
10.1 記錄的事件(極簡原則)
系統日誌與監控應(SHOULD)僅涵蓋「營運與安全所必需」的事件集合,避免將使用者內容或敏感憑證寫入可觀測性系統。 事件分為生命週期、驗證、儲存/網路與安全防護四類,並建議採用彙總方式記錄。
10.1.1 傳輸生命週期事件
- 建立傳輸(產生 transferId)
- 區塊上傳完成(以密文層級記錄,而非明文)
- 清單(manifest)寫入/更新
- 到期清理、使用者刪除/撤銷(包含清理任務的觸發與完成)
- 下載開始/完成(以密文下載層級計量)
10.1.2 驗證與授權事件
- 工作階段權杖的核發與驗證失敗(範圍不符、已過期、已撤銷等)
- 長效登入權杖驗證失敗(管理操作遭拒)
- 可疑的存取模式:401/403/404 異常暴增
注意:僅記錄「結果與原因碼」。不得(MUST NOT)記錄權杖明文、Authorization 標頭明文,或簽章參數明文。
10.1.3 系統健康與效能指標
- 請求延遲(p50/p95/p99)、錯誤率、吞吐量
- 物件儲存讀寫失敗率、回源失敗率、重試次數
- 邊緣節點異常、佇列積壓、背景清理任務成功率
- 頻寬與流量趨勢(彙總維度)
10.1.4 安全防護事件
- 速率限制觸發、WAF/防火牆規則命中
- 疑似列舉/暴力破解行為的門檻觸發
- 異常的並行與流量模式(同一來源的高並行、資源熱度異常)
10.1.5 彙總與取樣
- SHOULD(應):依分鐘/小時彙總計數與延遲分位數,以減少細粒度日誌。
- SHOULD(應):對高頻的成功請求進行取樣,僅在錯誤與異常路徑上保留必要的細節。
- SHOULD(應):對異常事件保留穩定的分類欄位(例如 eventType、reasonCode),以利稽核與機器分析。
10.2 禁止記錄的資訊(CEK、片段、憑證)
維持零知識承諾的關鍵,在於在所有可觀測性系統中嚴格落實「敏感資料禁止記錄」政策。 此政策必須涵蓋:伺服器日誌、APM、錯誤回報、第三方監控、用戶端日誌,以及瀏覽器主控台輸出。
10.2.1 伺服器端不得(MUST NOT)記錄
- CEK(內容加密金鑰)及任何可推導的素材
- URL 片段(
#...)、location.hash,以及含有片段的完整 URL - 明文內容:檔案明文、預覽內容、已解密的區塊,或任何明文摘要
- 敏感憑證明文:工作階段權杖、長效權杖、Authorization 標頭明文、簽署 URL 中的簽章欄位明文
若為除錯而必須記錄 URL:必須(MUST)先進行清理(移除片段;遮蔽或移除敏感的查詢參數),並在程式碼層級強制執行(而非仰賴人工約定)。
10.2.2 用戶端不得(MUST NOT)記錄
- 正式環境中不要輸出
location.href(可能包含片段) - 錯誤回報中不得包含帶有片段的 URL、CEK 或 noncePrefix
- 除錯日誌與開發工具輸出應預設停用或降到最低
SHOULD(應):在前端封裝統一的日誌/回報函式,於輸出/回報前,在內部完成 URL 清理與敏感欄位過濾。
10.3 監控指標與告警(可用性、效能、安全性)
10.3.1 可用性與效能告警
- 錯誤率告警:5xx 暴增、4xx 異常上升(需區分驗證失敗與濫用)
- 延遲告警:p95/p99 超過門檻、各區域回源異常
- 儲存告警:物件儲存寫入失敗增加、讀取逾時
- 清理任務告警:到期清理積壓、刪除任務重試次數過多
10.3.2 安全性告警
- 速率限制命中率異常上升
- 同一來源的 401/403/404 高頻出現,疑似列舉/暴力破解
- 單一資源的下載頻寬/並行數異常,疑似流量灌爆或盜連
- 關鍵政策變更(例如 WAF 規則、CSP/標頭變更)應觸發變更稽核與告警(如適用)
10.3.3 告警治理
- SHOULD(應):將告警分級(P0/P1/P2),並設定輪值/升級路徑。
- SHOULD(應):對雜訊較多的指標套用防抖動/時間窗彙總,避免告警疲勞。
- SHOULD(應):每則告警附上最小限度的診斷資訊(原因碼、趨勢圖、受影響的區域/路由),且不得包含敏感資料。
10.4 異常偵測與濫用識別
檔案傳輸服務天生就面臨列舉、暴力破解、流量灌爆與資源濫用的風險。本節概述可偵測的訊號與回應原則。 具體的門檻與策略必須依業務規模與誤判成本動態調整。
10.4.1 常見異常模式
- 列舉:短時間內大量探測 transferId/資源路徑,404/401/403 暴增。
- 暴力破解:對短碼/密碼/權杖進行高頻嘗試,失敗率曲線異常。
- 流量灌爆:單一資源的頻寬異常、同一來源大量並行連線、重複下載。
- 協定異常:區塊順序不合理、重複上傳、頻繁中斷/重試、異常的 UA 模式。
10.4.2 緩解策略(原則)
- SHOULD(應):採用速率限制、分級封鎖、挑戰機制(如適用),並依 ASN/地區/指紋動態調整政策。
- SHOULD(應):對容易誤判的路徑(一般使用者可能頻繁下載)採用較溫和的策略(例如延遲、分段節流)。
- MUST(必須):為所採取的處置保留可稽核的觸發依據(原因碼、門檻類別),並提供申訴支援管道(如適用)。
10.5 事件應變流程
FileBolt 必須(MUST)建立資安事件應變(IR)流程,以確保能迅速控制損害、可供事後檢討,並做到透明溝通。 可能影響零知識承諾的事件(例如 XSS、供應鏈注入、日誌洩漏片段)應視為最高優先。
- 分級研判(Triage):依影響範圍與嚴重程度分級(例如 P0/P1/P2),並界定升級路徑與負責人。
- 遏止(Containment):迅速隔離風險來源(封鎖攻擊來源、暫時停用功能、收緊政策、輪替金鑰/權杖)。
- 鑑識與檢討(Forensics & Review):依最小化的日誌與指標重建時間軸;記錄決策、影響、補救措施與改進項目。
- 補救與驗證(Remediation & Verification):部署修補、進行回歸測試與安全驗證,必要時重新進行第三方掃描。
- 溝通與揭露(Communication & Disclosure):在不擴大攻擊面的前提下,向使用者與大眾透明說明;必要時於狀態頁發布事件報告。
對外溝通應清楚說明:金鑰素材或明文是否可能已曝光、影響範圍、已採取的措施,以及使用者需要採取的行動(如有)。
10.6 資料保存與存取控制
日誌與監控資料本身就是敏感資產。應採用最短的有效保存期限與最小權限的存取控制,以降低外洩與濫用風險。
- SHOULD(應):為不同類型的日誌設定差異化的保存期限(錯誤與安全事件稍長,成功請求的細節則縮短或不保留)。
- SHOULD(應):日誌與監控平台採用最小權限存取(RBAC),並保留存取稽核紀錄。
- SHOULD(應):匯出/分享日誌時進行清理與最小化(禁止攜帶敏感憑證與個人識別資訊)。
10.7 第三方監控與整合原則
第三方 APM/錯誤追蹤工具預設可能蒐集 URL、標頭、表單欄位與裝置資訊。 若使用第三方監控,必須確保其蒐集範圍不違反零知識承諾。
- MUST(必須):不得在下載/解密頁面載入第三方腳本(與第 9 章一致)。
- MUST(必須):明確設定第三方的蒐集範圍:不含片段、不含敏感標頭明文、不含明文內容。
- SHOULD(應):統一回報時的 URL 清理;禁止或強力遮蔽可能含有敏感欄位的酬載。
- SHOULD(應):優先採用伺服器端的彙總指標,而非用戶端的細粒度追蹤,以縮小端點的資料蒐集面。
10.8 相關聲明編號(預留)
本章涵蓋「禁止記錄敏感資料、告警與事件應變、第三方監控限制」。 對應的聲明編號(Claim ID)將新增至 附錄:聲明編號總表, 並以該表作為唯一的權威來源。