7.27 Credential Rotation with Scoped Evidence 實作示範
Credential rotation with scoped evidence 的核心責任是把憑證輪替從一次性操作改成分域、可驗證、可回退的控制流程。
服務路徑與控制範圍
示範路徑是 webhook secret 與 service-to-service API token 輪替。這類變更常見錯誤是全域同批切換，導致無法快速定位失效範圍。
第一步先建 scope map：哪些服務、哪些環境、哪些第三方端點共用同一組 credential。再定義證據欄位：輪替前健康度、輪替中錯誤率、輪替後驗證結果與撤銷狀態。
實作步驟
- 盤點 scope map：服務、環境、憑證用途、到期日、owner。
- 設計輪替批次：先低風險租戶與非核心流量，再核心路徑。
- 建立雙軌驗證窗口：新舊 credential 並行期間記錄命中比例。
- 設定 rollback window：若驗證失敗可在時限內回退到舊憑證。
- 輪替後執行撤銷與稽核：確認舊 credential 不再可用並保留 audit evidence。
判讀訊號
| 訊號 | 判讀重點 | 對應動作 |
|---|---|---|
| 輪替後 webhook 驗簽失敗集中在單區域 | scope map 與部署批次不一致 | 暫停擴批，先修區域映射 |
| 新舊 credential 命中比例長期雙高 | 撤銷步驟未完成或有隱藏呼叫方 | 延長觀察並追來源，禁止結案 |
| 輪替成功率高但稽核鏈缺欄位 | 證據不完整，事後不可追蹤 | 補 audit 欄位再進 release gate |
| 回退後仍有驗簽錯誤 | 客戶端快取或第三方同步延遲 | 補回退窗口策略與客戶端同步公告 |
| 同一 key 在多服務超範圍使用 | credential scope 漂移 | 重新分域並建立到期輪替節奏 |
常見誤區
把輪替看成單次安全動作，會忽略它其實是跨服務變更管理。沒有 scope map 的輪替，出問題時只能全域停損。
把撤銷延後也會累積風險。舊 credential 長時間保留，會讓攻擊面與誤用窗口同時存在。
案例回寫
這條路徑可用 7.C9 反例：憑證輪替失敗 回寫。先看失敗是發生在分域、驗證還是撤銷，再回到本章補齊 scope map 與回退窗口。
這個案例主要支撐的是「輪替分域與證據鏈完整度」判讀，不直接支撐 incident 通訊節奏；外部通報回到 8.4/8.20。
控制面 token 事件的分域輪替壓力
控制面 token 事件的分域輪替壓力是 scope map 的最強壓測場景。當高權限 token 跨多個服務、多個 tenant、多個第三方端點共用、事件期間要回答「哪些必須先輪、哪些可以後輪、哪些必須同步輪」、缺 scope map 時這個排序只能靠 ad-hoc 判斷。
對應 7.C2 Cloudflare 控制面 token 2023 跟 Cloudflare 2023 follow-through：揭露控制面 token 事件的處置壓力 — 主 case 揭露三個策略方向（工作負載身份替代長期共享 token、強制 rotation 與細粒度 scope、把憑證事件寫入 release gate）、紅隊 case 補的具體 mechanism 是「分批恢復必要權限、前提是事先有 token 範圍 inventory」。
以下基於通用工程知識補充：分批恢復的工程意義是讓事件期間的可用性風險可控 — 用三個維度排序：業務優先序（核心交易 vs 內部工具）、依賴方向（上游 service 先恢復 / 下游後恢復）、權限等級（低權先恢復 / 高權後恢復）。三維度衝突時、業務優先序勝過權限等級、是常見的工程取捨點。粗粒度的「全部凍結再全部解封」是 fallback 選項、會把可用性代價拉滿。
CI 平台事件的輪替壓力
CI 平台事件的輪替壓力跟控制面 token 不同 — 範圍 已知 但 量大。CI 平台被入侵時、所有客戶端 secrets 都進入 可能洩漏 狀態、實際是否被使用要靠後續行為佐證；scoped rotation 要在「全部輪太貴」跟「分層輪會漏」之間找平衡。
CircleCI 2023 案例的範圍量級壓力 governance frame 在 [7.6 § CI secrets 集中化跟 blast radius](/backend/07-security-data-protection/secrets-and-machine-credential-governance/#ci-secrets-集中化跟-blast-radius)；本節聚焦 scoped rotation 視角下的實作示範 — 拿到 inventory 後如何排序 batch、用什麼 metadata 支撐分批決策。
CircleCI 2023 案例「可落地檢查點」標明事故中 mechanism 為「按分級快速輪替、並記錄 MTTR」，前提是「事先有 secrets inventory 跟 owner mapping」。實作示範視角的補充是：分級要落到具體 metadata schema、不只是規範性說法。
以下基於通用工程知識補充：tag 是事件期間的輪替排序前提 — metadata 完整時可從「high blast radius + critical tier」直接抽 subset 優先輪、再依資源展開。每個 secret 在 vault 裡帶 blast radius tag（local / shared / global）、business tier（critical / standard / experimental）、rotation cost（low / high）三維度。metadata 不足時排序退回全域輪替（成本高）或部分輪替（覆蓋風險）兩個 fallback。
跨模組路由
- 與 7.6 的交接：治理原則回到 Secrets and Machine Credential Governance。
- 與 7.7 的交接：稽核欄位與責任鏈回到 Audit Trail and Accountability Boundary。
- 與 6.8 Release Gate 的交接：高風險輪替變更進 release gate。
- 與 8.19 Incident Decision Log 的交接：輪替中止與回退判斷進 incident decision log。
下一步路由
要回到全模組實作串接，接著讀 Backend 學習路線 進入下一條服務路徑。