題幹與適用場景
一個多租戶平台已保存稽核事件，但資安團隊需要獨立判斷歷史記錄是否遭刪除、重排，或由擁有主資料庫權限的人重算。請設計驗證協定，重點說明規範化、分段雜湊鏈、簽章、外部錨定、驗證輸出和無法驗證區間的處置。
追加日誌和雜湊鏈可以讓事後修改留下證據，但不能證明事件在最初寫入時就真實。題目考察威脅模型、證據鏈和可維運性，不能把「存到不可變物件儲存」當完整答案。
面試官考察點
重點看事件 schema 是否包含主體、目標、動作、時間、來源和結果；寫入是否與業務交易可靠關聯；雜湊鏈如何分段和錨定；租戶隔離、查詢索引、金鑰權限、保留刪除和驗證工具是否清楚。
回答前需要釐清的問題
- 威脅主體能否同時修改事件庫、雜湊目錄、簽章金鑰和錨定媒介？
- 驗證目標是發現刪除、修改和重排，還是也要證明事件來源？
- 驗證由平台本身、資安團隊還是外部稽核方執行？
- 允許多長的待錨定視窗，缺口出現後業務與調查流程如何降級？
30 秒回答框架
「我先把稽核事件定義為不可變規範記錄，由業務交易透過 outbox 可靠發布到隔離寫入器。寫入器按租戶和時間分段，把規範化事件串成雜湊鏈，定期將鏈頭提交到獨立的只追加儲存或透明帳本。查詢走派生索引，不修改證據日誌；驗證器重新計算鏈並比對錨點。權限、保留和故障恢復都記錄為可稽核操作，日誌完整性與事件真實性分別由鏈和業務證明。」
分步驟深入解答
第一步：定義威脅模型和證據目標
假設應用管理員或資料庫管理員可能嘗試刪除、重排或改寫記錄；外部錨點服務也可能不可用。明確要偵測缺失、修改、重排，還是證明某個主體確實執行動作。稽核日誌不能取代存取控制。
第二步：設計規範化事件
欄位包括事件 ID、租戶、主體和身份來源、動作、資源識別、前後摘要、請求 ID、發生時間、寫入序號、結果和策略版本。對 JSON 等欄位使用固定規範化，避免序列化順序造成不同雜湊。敏感值只存摘要或受控引用。
第三步：保證業務與日誌關聯
業務交易寫入 outbox，提交成功後由可靠消費者產生稽核事件；不能依賴「先寫業務再 best effort 記錄」。消費者重試使用事件 ID 冪等，失敗進入隔離佇列並告警。日誌延遲可以接受，但不可靜默遺失。
第四步：構建分段雜湊鏈
每筆記錄保存前一筆雜湊、規範化事件和目前雜湊，例如 H(previous || event || metadata)。按租戶、日期或大小滾動分段，記錄段首、段尾和序號。跨分片排序使用伺服器序號和接收時間，不能把客戶端時間當唯一順序。
第五步：外部錨定與金鑰管理
週期性把每段鏈頭寫入權限隔離的只追加介質，並記錄錨點時間、段 ID 和簽名。若用簽名，私鑰放在受控金鑰服務，輪換和撤銷本身也要稽核。外部錨點防止擁有主庫寫權限的人重算整條鏈而不留痕。
第六步：查詢與權限隔離
在搜尋索引或唯讀副本建立主體、資源、動作和時間索引；索引可重建，證據日誌不可更新。查詢介面按租戶、角色和目的限制，匯出結果帶驗證摘要。任何讀取、匯出或驗證操作都產生新的稽核事件。
第七步：保留、刪除和隱私
按法規設定保留期限、WORM 或物件鎖策略。需要刪除個人資料時，使用加密抹除、欄位脫敏或不可逆摘要，同時保留「曾發生刪除」的證明；不能靜默改寫歷史。備份、快取和錨點的保留策略要一致。
第八步：驗證、恢復和監控
驗證器檢查鏈連續性、序號、規範化雜湊、簽名和外部錨點。定期抽樣全量驗證，監控缺口、延遲、重複、錨定失敗和驗證耗時。恢復時從最後可信錨點重播 outbox 和只追加段，隔離無法證明的區間。
深入取捨與邊界
#### 單鏈還是分段鏈
單鏈查詢簡單但恢復和並行寫入困難；分段鏈便於租戶隔離、並行驗證和保留管理，卻需要段間錨點和順序目錄。
#### 雜湊鏈還是簽章日誌
雜湊鏈成本低，能發現改寫；簽名增加外部驗證能力和金鑰治理成本。通常組合使用，取決於是否需要跨組織證明。
#### 完整性還是真實性
鏈只能證明記錄關係和錨點一致，不能證明事件內容真實。真實性仍依賴業務身份、授權、交易記錄和獨立來源。
失敗演練與演進計畫
#### 刪除中間記錄
從物件儲存刪除一筆記錄，驗證器應報告序號缺口和鏈斷裂，並定位到段與錨點。
#### 資料庫管理員重算雜湊
重寫整段並替換鏈頭，確認獨立錨點拒絕新鏈，舊鏈仍可取回調查。
#### 外部錨點暫時不可用
斷開錨點服務，確認本地段進入待錨定狀態、業務不遺失事件，恢復後按順序補錨定並告警。
高品質示範回答
「我會先定義驗證邊界：攻擊者可能修改事件庫與索引，但不能同時改寫獨立錨點或取得驗證金鑰。寫入端把事件轉換為確定性的規範表示，按租戶與時間分段，為每筆記錄計算前序雜湊、序號與目前雜湊；段尾再簽章，並把鏈頭定期提交到權限隔離的只追加媒介。
獨立驗證器從可信錨點開始，重新計算規範化雜湊，檢查序號連續性、段間連結、簽章、錨點時間與保留策略。刪除會產生序號缺口，修改會造成雜湊不一致，重排會破壞前序連結，擁有主資料庫權限的人重算整段也無法符合外部錨點。驗證結果必須輸出已驗證範圍、第一個失敗位置、待錨定視窗與證據引用，不能只回傳布林值。若發現無法驗證區間，我會凍結相關匯出、保留原始物件並通知資安團隊；雜湊鏈證明的是記錄完整性，事件是否真實仍要由身分、授權與業務交易證據支持。」
常見錯誤
- 只把資料放進 WORM 儲存，沒有定義誰能寫入、誰能修改保留策略。
- 直接雜湊原始 JSON，忽略欄位順序、編碼與時間格式的規範化。
- 把雜湊鏈一致等同於事件真實，遺漏身分與業務交易證據。
- 驗證失敗後自動重建並覆蓋原鏈，破壞調查所需的原始證據。
追問與應對
外部錨點解決什麼問題？
它阻止擁有主資料庫寫入權限的人在事後重算整段並無痕替換鏈頭。錨點媒介必須使用獨立權限與保留策略。
如何證明某筆記錄遭刪除？
驗證器會同時發現序號缺口與後續雜湊斷裂，並用最近的可信錨點限定缺失區間；只靠搜尋索引找不到記錄不能證明刪除。
錨點服務暫時不可用怎麼辦？
繼續寫入帶序號的本地分段並標記為待錨定，恢復後按順序補交。待錨定視窗必須出現在驗證結果與警示中，不能被宣稱為已完整驗證。
如何處理無法驗證區間？
隔離相關匯出，保留原始物件、簽章與錨點證據，通知資安團隊並記錄處置。復原流程不得自動把未知區間標記為完整。