題幹與適用場景
請設計一個多租戶 Certificate Transparency（CT）日誌監控器。使用者提交一個或多個網域後，系統持續檢查公開 CT 日誌，發現符合的憑證或預憑證時發送告警；同時要能證明日誌資料沒有被靜默改寫，並在日誌停滯、證明失敗或超過最大合併延遲時告警。
這道題適合系統設計、平台安全和憑證基礎設施職位。回答重點是可驗證的資料管線與故障邊界，而不是堆砌微服務名稱。
面試官考察點
- 是否能區分監控器、瀏覽器策略和 CA 簽發流程。
- 是否理解簽名樹頭（STH）、Merkle inclusion proof、consistency proof 與 append-only 語義。
- 是否把最大合併延遲（MMD）轉成可觀測的排程與告警條件。
- 是否處理多日誌、重複拉取、日誌分叉、不可用和租戶隔離。
- 是否給出可複核的儲存、冪等、告警降噪和容量估算。
回答前需要釐清的問題
先確認四個邊界：
- 監控範圍是精確網域、註冊網域，還包括萬用字元與 SAN 中的名稱？
- 目標是近即時發現，還是允許分鐘級延遲？告警通道有哪些，是否需要值班升級？
- 需要監控公開日誌全集，還是只監控若干可信日誌？是否要求保存原始憑證和證明材料？
- 多租戶規模、保留週期、隱私要求與預算是多少？
若面試官沒有補充，可以假設監控 100 個日誌、每個日誌每分鐘輪詢一次，端到端發現延遲目標為 5 分鐘，並保留可稽核證據。
30 秒回答框架
我會把系統拆成日誌採集、密碼學驗證、憑證比對、告警和稽核五層。每個日誌維護已驗證的樹大小與最新 STH；採集器先驗證 STH 簽名，再按樹大小增量拉取條目，並用 inclusion 或 consistency proof 檢查 append-only。比對層解析 SAN、萬用字元和註冊網域，告警層按租戶策略去重和升級，稽核層保存原始條目、STH、證明和雜湊。核心指標是 STH 新鮮度、日誌延遲、證明失敗率、告警延遲和誤報率；日誌分叉或 MMD 違規會凍結該日誌的可信狀態並升級處理。
分步驟深入解答
1. 採集與狀態機
為每個日誌保存日誌識別、公鑰、目前可信樹大小、最後驗證 STH、最後拉取時間和狀態。排程器按日誌狀態分配任務；正常狀態增量拉取，短暫不可用採用指數退避，連續失敗進入隔離狀態。任務鍵使用日誌識別加目標樹大小，保證重試冪等。
2. 驗證 STH 與 Merkle 證明
採集器先用日誌公鑰驗證 STH 簽名和時間欄位，再檢查樹大小單調不減。首次同步可以取得完整快照；後續同步使用 consistency proof 證明新樹包含舊樹。每個符合條目再用 inclusion proof 證明它確實屬於該樹。證明失敗、樹大小回退或簽名錯誤都不能直接覆蓋舊狀態，應保留證據並把日誌標成可疑。
3. 增量讀取與完整性
按已確認樹大小請求新區間，寫入原始憑證、預憑證、日誌索引和接收時間。服務端按條目識別去重，但不丟棄同一憑證在不同日誌中的出現。超過 MMD 仍沒有可驗證的新 STH 時，記錄日誌延遲並發出平台告警；不能把「沒有符合憑證」誤判成「日誌沒有新條目」。
4. 憑證比對與告警
解析憑證 SAN、萬用字元、issuer、notBefore、notAfter 和憑證指紋。比對策略以註冊網域和明確名稱為主，避免簡單字串包含造成誤報。告警事件包含租戶、名稱、日誌、憑證指紋、首次觀察時間和證據連結。相同指紋在短時間內去重；新 issuer、短有效期、關鍵生產網域等策略可以提高嚴重級別。
5. 儲存、租戶和復原
熱狀態放在關聯式資料庫或鍵值庫，原始條目和證明放物件儲存，按日誌與樹大小建立索引。事件寫入不可變稽核流，便於重播驗證。租戶查詢只返回授權網域；採集器使用每日誌限速和全域並發上限，避免壓垮公開日誌。遺失本地狀態時，從最近可信 STH 復原，再用 consistency proof 追上，不直接信任最新未驗證游標。
6. 可觀測性與故障處理
監控 STH age、MMD lag、已確認 tree size、抓取吞吐、proof failure、日誌可用率、比對率、告警延遲和重複率。日誌服務不可用時繼續保留最後可信狀態並重試；日誌分叉或一致性證明失敗時，暫停該日誌的比對結果，切換到其他日誌並觸發安全事件。告警服務失敗時把事件寫入持久佇列，恢復後按事件 ID 投遞，避免重複通知。
高品質示範回答
我會先定義「可信進度」：只有簽名正確、樹大小單調、並通過一致性證明的 STH 才能推進某個日誌的游標。採集器為每個日誌維護這個游標，並在任務中記錄請求範圍和重試令牌。首次執行取得基線，之後按樹大小增量讀取；每個條目保存憑證指紋、SAN、日誌位置、原始回應和驗證證明。
比對服務將 SAN 正規化後與租戶關注名稱比較，支援精確名稱、註冊網域和明確的萬用字元規則。事件以「租戶加指紋加日誌」冪等鍵寫入佇列，通知服務按策略去重、升級和回執。稽核儲存保留 STH、proof、條目雜湊和驗證版本，使安全團隊可以獨立重播。
我會把日誌異常視為資料可信度問題：簽名錯誤、樹回退、一致性證明失敗或 MMD 超時都會生成高優先級平台事件，相關日誌進入隔離狀態，舊可信狀態不被覆蓋。容量上透過按日誌分片、限速、批量讀取和物件儲存控制成本；多租戶邊界由授權查詢和每租戶配額保證。最後用 STH 新鮮度、proof failure、發現延遲、告警誤報率和重播成功率驗收。
常見錯誤
- 只輪詢一個日誌，忽略憑證可能出現在多個日誌。
- 只看憑證文字，不驗證 STH 簽名與 Merkle proof。
- 用「最新請求成功」推進游標，導致未驗證資料污染可信狀態。
- 把 MMD 當成憑證有效期，或完全不設定日誌新鮮度告警。
- 用字串包含比對網域，誤報相似名稱和不相關 SAN。
- 發現同一指紋就全域去重，遺失跨日誌出現位置。
- 日誌異常時繼續發送「憑證未發現」的低置信度結論。
- 只保存最終告警，不保存原始條目、STH 和證明，無法稽核。
追問及應對
如果日誌返回了樹回退怎麼辦？
拒絕推進游標，保存新舊 STH 和回應，凍結該日誌並觸發一致性異常告警。只有人工確認或重新建立可信基線後才恢復。
如何降低近即時輪詢的成本？
按日誌分片、批量讀取新區間、動態調整輪詢頻率，並將冷證據放物件儲存。安全告警的延遲目標不能透過跳過驗證換取。
如何驗證網域歸屬？
監控建立時要求 DNS、HTTP 或組織授權證明；之後只允許授權主體修改比對規則，並記錄變更稽核。
監控器和瀏覽器 CT 策略有什麼區別？
監控器負責發現和證明公開日誌中的條目，瀏覽器策略負責決定憑證是否符合連線要求；兩者的失敗處理和信任邊界不同。
如何測試系統？
使用可控日誌或錄製回應注入簽名錯誤、proof 錯誤、樹回退、MMD 超時、重複條目和通知重試，驗證游標不會錯誤前進、事件冪等且稽核可重播。