Vendor / Platform 清單

實作時的常用選擇見 vendors — T1 收錄 OpenTelemetry / Prometheus / Grafana Stack / Datadog / Elastic Stack / Honeycomb / AWS CloudWatch / GCP Cloud Operations / Sentry，每個 vendor 有定位、適用場景、取捨與預計實作話題的骨架。Error tracking 是獨立子維度（Sentry），跟 metrics / logs / traces 三角互補。

進入 vendor 比較前，先回到 觀測、可靠性與事故服務選型 判斷目前缺的是訊號層、驗證層、響應層還是閉環層。可觀測性 vendor 選型只處理訊號層與部分告警入口；可靠性驗證與事故協作要交給可靠性與事故流程。

Deep article（vendor 自身的配置、故障、容量）跟 migration playbook（跨 vendor 遷移流程）的撰寫進度見 vendors/ 的「內容覆蓋進度」段。

暫定分類

選型入口

可觀測性選型的核心判斷是團隊缺少哪一種操作訊號。當工程師需要還原事件脈絡時先看 log；需要趨勢與容量判斷時先看 metrics；需要跨服務路徑時先看 trace；需要共同操作入口時先看 dashboard；需要主動通知時先看 alert。

Log aggregation 適合查單一事件與錯誤脈絡；metrics 適合觀察 error rate、latency、throughput 與 queue lag；tracing 適合拆解跨服務 request path；dashboard 適合整合 SLI/SLO 與容量趨勢；alert 適合把需要動作的異常送到負責者面前，並連到 alert runbook。

接近真實網路服務的例子包括 checkout 變慢、queue lag 上升、WebSocket 斷線增加、Redis timeout 增加與下游 API 錯誤率上升。這些場景的共同問題是從症狀回到原因，因此本模組會先處理欄位、關聯、metric cardinality、查詢、視覺化與告警規則。

訊號情境庫

本模組收的是可重複套用的訊號情境，不收服務級案例庫。服務的長期時間線與事故史，留給可靠性驗證與事故處理兩個模組；可觀測性平台只保留能反覆套用在不同服務上的觀測判讀樣式，讓讀者先知道「該看哪種訊號、如何辨識失真、下一步交給誰」。

這種情境庫的責任是定位訊號，服務史由可靠性驗證與事故處理承接。當讀者需要的是平台能力與判讀路由，可觀測性模組的範圍就夠了；當需要的是某個服務怎麼一路演進、怎麼歷次驗證與恢復，那是可靠性與事故模組的工作。

跟可靠性與事故模組的串接

可觀測性是「觀測 → 驗證 → 事故」閉環的起點，但閉環是雙向的：

• 觀測 → 事故：訊號（log spike、SLO burn rate、error rate）觸發告警、進入事故響應流程。判讀邊界由可觀測性定義、響應節奏由事故處理定義。
• 觀測 → 驗證：SLO / SLI 量測由可觀測性提供、是 SLO 政策與 chaos hypothesis 的 baseline。沒有可信訊號就沒有可信驗證。
• 驗證 → 觀測：驗證需求驅動訊號設計 — chaos experiment 需要新 metric、load test 需要新 dashboard、SLO 政策需要新 alert rule。
• 事故 → 觀測：每次事故 post-incident review 揭露偵測缺口（symptom-based alert 缺、訊號太晚、cardinality 不足），回寫到訊號治理。
• 資安 → 觀測：資安偵測、稽核證據與資料外洩風險會形成新的 log schema、audit log、alert 與 evidence chain 需求。尤其 偵測覆蓋率與訊號治理 會回寫到訊號治理閉環。
• 觀測 → 資安：log、trace、audit log 與 service topology 提供資安 triage 的事實基礎，讓 稽核追蹤與責任邊界 能把責任鏈落到可查證資料。
• 詳細閉環說明：見 Observability / Reliability / Incident Response 閉環。

跟 Monitoring 模組的串接

Monitoring 模組 聚焦非 server 端 runtime — mobile app、web 頁面、本機腳本的行為蒐集、錯誤回報與 SDK 設計。本模組聚焦 server-side observability。兩者的交叉點是 trace context propagation 和 event transport format。

• 4.10 Client-side / Synthetic / RUM：概念定位、RUM 與 synthetic 的 server-side 整合
• 4.24 Client-to-Server 觀測串接：從 browser click 到 server span 的完整 trace 鏈路
• 監控資料的雙重用途：同一份 event data 如何同時服務行為分析（monitoring/08）與訊號治理（04）
• 0.15 跨模組 Checkout Episode：從 DB write 到 observability evidence 的四層端到端串聯

與語言教材的分工

語言教材處理如何產生穩定欄位與執行環境訊號。Backend observability 模組處理收集、儲存、查詢、視覺化、告警與跨服務關聯。

企業案例補充

可觀測性的案例補充重點是「訊號平台為什麼這樣設計」，不是工具比較表。閱讀時先抓資料規模、查詢延遲、保留策略與多租戶治理，再對照本模組章節。

若要擴充企業案例，先到 0.14 企業選型案例圖譜 依「企業型態 × 規模階段」挑樣本，再把觀測面教訓回寫到 4.16-4.21。這樣案例擴充會先補齊覆蓋度，再補單點技巧。

第一批缺口回填建議先做三條觀測題目：FinTech 補 audit log completeness 與 evidence traceability（回寫 4.12、4.20）；Gaming 補高峰時段 signal freshness 與 cardinality guardrail（回寫 4.7、4.17）；Healthcare 補資料主權相關的 access evidence 與留存邊界（回寫 4.12、4.18）。

第一批案例正文入口見 可觀測性案例正文，可直接對應 4.12 / 4.17 / 4.18 / 4.20 的回寫欄位。

第二批觀測遷移案例已補： 4.C4 X-Ray 到 OTel 轉換 與 4.C5 Cloud Trace OTLP 導入。兩者可直接回寫到 4.11 telemetry pipeline、4.17 telemetry data quality 與 4.18 operating model。

反例與規模對照入口： 4.C9 反例 / 4.C10 對照。

回退判讀寫法見 0.C4 回退判讀寫法，觀測案例要優先保留訊號語意、採樣策略、告警偏差與 SLO 判讀差異。

跨語言適配評估

可觀測性使用方式會受語言的 logger 生態、trace context、exception/error model、執行環境 metrics 與 instrumentation SDK 影響。同步 runtime 要保留 request context 與 thread-local 邊界；async runtime 要確認 trace context 能跨 task 傳遞；輕量並發 runtime 要觀察 task/goroutine 數量、queue lag 與下游等待。動態語言要特別管理 log schema 穩定性；強型別語言則要避免過度包裝導致 trace 與 error chain 斷裂。

章節列表

註：4.1-4.24 已完成概念層、實作示範與端到端串接正文，案例庫可支援 06 與 08 的路由引用。後續工作重點為案例深挖與跨模組回寫密度提升，而非章節補齊。

個案前拓展空間

個案前拓展的責任是補足讀案例時需要的判讀框架。04 適合補「訊號是否足以支援判讀」這類跨服務能力，不適合展開單一服務的事故史。

本輪先完成這四個前置控制面，讓後續 06 與 08 文章有穩定的訊號前提可引用。若服務案例暴露的是訊號分類問題，回寫 4.16；若暴露的是資料品質問題，回寫 4.17；若暴露的是 owner 與治理問題，回寫 4.18；若暴露的是架構本身難以診斷，回寫 4.19。

後續深化方向

04 後續深化以「案例反例補強、跨模組回寫、證據欄位對齊」為主。可觀測性是 06 與 08 的輸入層，重點在提高 evidence package、data quality 與 incident write-back 的銜接精度。

實作探討入口

進入實作層時，04 建議先從一條最小切片開始：同一個 user journey 建立 SLI + dashboard + alert + evidence query 四件組，再把欄位直接接到 6.23 Verification Evidence Handoff 與 8.19 Incident Decision Log。

首篇示範已完成： 4.22 Checkout API Evidence Package 實作示範。

完成條件是每篇都能回答四件事：判讀訊號、風險代價、控制面邊界與下一步路由。這樣 06 的 SLO / readiness / experiment safety 與 08 的 intake / decision log / impact assessment 才能引用 04，而不需要在各自章節重寫觀測前提。

跟 Infra 可觀測性的分界

Infra 模組六：可觀測性與 log 處理基礎設施層的訊號 — log group、CloudWatch metric、alarm 跟資源同生命週期的 IaC 管理。本模組處理應用層的訊號 — 服務的延遲、錯誤率、trace、業務指標。分界的判讀是：這個訊號是「資源建立時就該存在」還是「功能開發時才埋」——前者進 infra 的 IaC，後者進本模組的應用程式碼。事故排查時兩層合流：infra alarm 告訴你哪個資源異常，本模組的 trace 告訴你哪個請求路徑受影響。

事故角色

事故處理的角色是把「出了問題之後怎麼做」變成可預期的協作節奏。這一層不負責追究誰做錯，也不負責寫修復程式，而是負責把啟動、分工、止血、通訊、復原與復盤串成同一條路徑。

當一個事故被定義成流程，讀者才會看懂 severity 是路由，ICS 是角色分工，post-incident review 是下一次演練與改進的輸入。這些詞彙的責任，是讓事故從臨場反應變成可交接的制度。

問題節點

問題節點先描述事故環節，再描述決策責任。這樣做可以讓讀者先知道哪裡出現風險，再知道應該把判讀輸給哪個角色或流程。

這張表的目的是讓事故先變成路由。當路由成立後，服務案例庫才有意義，因為案例可以直接提供真實時間線、對外更新與復原節奏。

案例庫讀法

案例庫的責任是保留不同型態的事故節奏。AWS S3、Cloudflare、GitHub、GCP、Atlassian、Roblox 與 Fastly 這些 T1 案例，各自代表控制面、路由、資料一致性、多租戶復原與 edge 擴散的不同樣本。

讀這些案例時，先看它是哪一種事故，再看它如何收斂。第一步是判斷事故屬於控制面還是資料面。第二步是看影響面是否還在擴大。第三步是看對外通訊與內部復原是否同步。這三步會把讀者導向不同的案例頁，也會把讀者導回可觀測性、部署平台、可靠性驗證或資安約束的交接節點。

第一輪案例驅動路由

第一輪 T1 案例已補到「每個服務至少一篇可引用事故頁」。這些案例的用途是把 04 的觀測證據、06 的驗證邊界、08 的指揮與通訊串成同一條教學路徑，堆疊事件本身沒有教學價值。

若要繼續擴案例，不要只沿同一家公司加事件；先回到 0.14 企業選型案例圖譜 補「企業型態 × 規模階段」覆蓋，再把新增事故映射到本章的問題節點（8.1-8.5、8.18-8.22），才能同時強化案例多樣性與教學路由。

第一批缺口回填建議先做三條事故題目：FinTech 補交易中斷時的 impact 分級與對外通訊節奏（回寫 8.1、8.10、8.20）；Gaming 補高峰活動期間的 multi-incident 協調與長事故交接（回寫 8.12、8.14）；Healthcare 補資料與服務雙重事件的 evidence triage 與責任分流（回寫 8.17、8.18、8.19）。

Vendor / Platform 清單

實作工具見 vendors — T1 收錄 On-call（PagerDuty / Opsgenie / Grafana OnCall）、IR 平台（incident.io / FireHydrant / Rootly）、Status page（Atlassian Statuspage / Instatus）、Postmortem（Jeli）共 9 個 vendor 骨架。跟 cases/ 是不同維度（cases 是公開事故案例來源、vendors 是實作工具）。

進入工具比較前，先回到 觀測、可靠性與事故服務選型 判斷目前缺的是響應層能力，還是缺少可觀測性的證據來源或可靠性驗證的事前演練。事故工具選型要以「事故能否被接住、分工、通訊與回寫」為主軸，on-call 或 IR 平台功能清單只是落地選項。

Deep article（vendor 自身的配置、故障、容量）跟 migration playbook（跨 vendor 遷移流程）的撰寫進度見 vendors/ 的「內容覆蓋進度」段。

規劃方向

本輪規劃的核心是把模組從「章節列表」升級成「問題節點 + 服務級案例庫」兩層結構：

1. 問題節點先行：8.1-8.10 主章定義事故環節的問題、判讀訊號與責任邊界，不綁特定 stack。
2. 服務級案例庫：以公開事故報告（AWS / Cloudflare / GitHub / GCP / Atlassian / Roblox / Fastly 等）作 cases，每個服務一個資料夾、累積架構脈絡與多次事故的 longitudinal pattern。
3. 資安事故是其中一類：跟 07 的交接點維持，但 07 的紅藍隊框架不外推到本模組 — IR 自有 Severity / ICS / post-incident review 等 first-class 詞彙、不需要藉攻防隱喻表達。

不經實作即可推進的理由：事故處理的價值在「協作節奏與決策模型」，這層跟具體服務技術解耦，公開 post-mortem 案例豐富，符合先建概念層的條件。

模組方法

問題驅動方法的核心是讓案例退到證據角色，讓知識網以事故環節問題為主體。

1. 先定義事故環節問題與責任邊界。
2. 再定義判讀訊號（影響面、擴散速率、降級空間）與升級條件。
3. 接著定義交接路由與前置控制面。
4. 最後在問題觸發時引用對應服務的事故案例。

模組分工定位

本模組提供觀念、判讀與路由。實作細節由對應模組承接，確保概念層與實作層分工清晰。

• backend/04-observability：可觀測性模組，負責訊號偵測、判讀與告警治理實作。
• backend/05-deployment-platform：切換、回滾、流量控制與隔離實作。
• backend/06-reliability：可靠性驗證模組，負責事故前驗證、演練與回復排練實作。
• backend/07-security-data-protection：權限、稽核與高風險操作約束實作。

從章節到實作的 chain

各章節交付三樣：問題節點清單、判讀訊號、控制面 link。判讀完成後沿兩條 chain 進入 implementation：

1. Mechanism chain：點問題節點表的 [control-name] link 進 knowledge-cards，那層展開機制 / 邊界 / context-dependence。例：[incident-command-system] 的 knowledge-card 是該 control 的 mechanism SSoT。
2. Delivery chain：章節「交接路由」欄位指向下游模組，包括可觀測性（訊號）、部署平台（切換 / 回滾）、可靠性驗證（演練 / 回復排練）與資安資料保護（權限 / 稽核）。

兩條 chain 走完，控制面交付完整。Implementation 強度取決於兩條 chain 的完成度，章節閱讀本身完成 routing 階段。

跟既有模組的串接

本模組是「觀測 → 驗證 → 事故」閉環的收口、承接資安概念判讀、把問題地圖轉成可執行事故節奏。資安事故僅是事故的一個子集、其他多數事故是可用性 / 容量 / 變更類。

觀測、驗證與事故閉環交接基線：

• 來自 可觀測性平台：訊號（SLO burn / error rate / latency spike）是事故啟動條件、判讀脈絡的主要來源。
• 餵給 可觀測性平台：post-incident review 揭露的偵測缺口（訊號太晚、cardinality 不足、symptom-based alert 缺）回寫到訊號治理。
• 來自 可靠性驗證流程：事前演練（game day / DR rehearsal / chaos experiment）作為事中決策的肌肉記憶與 runbook 來源。
• 餵給 可靠性驗證流程：post-incident review action items 回寫成新 chaos / DR 演練題目、事故型態變成 chaos 與 DR 演練的場景輸入。
• 詳細閉環說明：見 Observability / Reliability / Incident Response 閉環。

07 資安交接基線：

• 來自 7.2 身分與授權邊界：承接身分事件分級與收斂順序。
• 來自 7.3 入口治理與伺服器防護：承接入口事件止血、隔離與驗證節奏。
• 來自 7.4 資料保護與遮罩治理：承接外送事件通報與影響盤點節奏。
• 來自 7.7 稽核追蹤與責任邊界：承接證據結構與復盤責任閉環。
• 來自 7.16 從公開事故到工程 Workflow：承接事故案例如何回寫控制面。

主章規劃

註：8.1-8.23 已完成概念層與第一篇實作示範正文，案例庫可支援 intake、decision、impact、write-back 的完整路由。後續重點為多事件對照與跨模組回寫精度提升。

個案前拓展空間

個案前拓展的責任是先建立事故案例的閱讀欄位。事故處理模組適合補 intake、evidence、decision、impact 與 automation boundary 這類跨事故骨架，不適合直接把公開事故故事當正文主軸。

本輪先完成這四個個案前拓展章，讓公開事故案例可以被拆成可重用素材。若案例重點是「事故從哪裡被發現」，回寫 Incident Intake & Evidence Triage；若重點是「事中決策如何形成」，回寫 Incident Decision Log；若重點是「客戶影響如何量化」，回寫 Customer Impact Assessment；若重點是「流程工具是否幫上忙」，回寫 Incident Workflow Automation Boundary。

後續深化方向

08 後續深化以「同服務多事件對照、decision/evidence 欄位標準化、跨模組閉環回寫」為主。事故處理承接 04 的觀測證據與 06 的驗證結果，並持續回寫上游控制面。

實作探討入口

進入實作層時，08 建議先建最小 incident artifact 套組：intake sheet + decision log + customer impact note + write-back record，並固定連到 4.20 與 6.23。

首篇示範已完成： 8.23 Control Plane Decision Log and Write-back 實作示範。

完成條件是每篇都能回答四件事：輸入來源、判讀欄位、決策責任、回寫路由。這樣 08 才能把事故從臨場反應整理成可演練、可復盤、可交接的流程。

服務案例庫規劃

服務作為案例單位、累積架構脈絡與多次事故的 longitudinal pattern。每個服務一個資料夾、收錄該服務的事故時間線、共通失敗模式與引用源。資料夾位置：content/backend/08-incident-response/cases/{vendor-service}/。

T1（必寫、公開素材豐富、教學價值高）

T2（補不同型態）

T3（補完，視時間）

既有可引用卡片

• runbook
• alert runbook
• runbook link
• on-call
• playbook
• game day
• symptom-based alert
• alert fatigue
• downtime
• degradation
• failover
• fallback plan
• replay runbook
• incident severity
• incident command system
• escalation policy
• incident timeline
• blast radius
• impact scope
• rollback strategy
• post-incident review
• action item closure
• RCA
• RTO
• RPO
• MTTR
• status page
• stakeholder mapping
• toil

模組完成狀態

主章 8.1-8.23 已完成首輪正文，服務案例庫第一批正文已補齊（Cloudflare / AWS S3 / GitHub / GCP / Atlassian / Roblox / Fastly，以及 Slack / Datadog / Discord / Azure AD / Heroku / Reddit / Microsoft 365）。目前重點從「補案例檔案」轉為「補多事件對照與決策路徑精度」。

案例正文入口見 事故案例庫。每篇案例至少要能回寫一個事故控制面章節（例如 8.18、8.19、8.20、8.21、8.22），避免只停在事故時間線描述。

第二批案例深挖已補 AWS 第二事件： 2021 US-EAST-1 Control Plane Degradation。這篇重點回寫 8.3 / 8.4 / 8.20 與 4.18 / 4.20，補齊 control plane 退化與通訊節奏的判讀。

深挖批次 B 已補 Cloudflare 第三事件： 2023 Workers KV Deployment Tool Misconfiguration。這篇重點回寫 8.19 / 8.22 / 6.24，把控制面變更擴散與 decision log 的治理責任接回主章。

第三批案例補強已補 AWS 第三篇： 2023 Control Plane Accountability and Communication Pattern。這篇重點回寫 8.19 / 8.20 / 8.4 / 4.20，補齊控制面事故的責任邊界與對外節奏樣式。

後續推演大綱

推演資產化的完成條件是讓讀者能從一個事故壓力出發，找到對應問題節點、服務 case 與回寫章節。完成後事故模組才進入穩定維護狀態。

Tripwire

• 寫 T1 服務第 3 個時、若 case 之間無共通分類軸 → 改用單服務獨立檔，不開資料夾。
• 寫到第 9 主章發現章節覆蓋 60%+ → 軸線過於相似、合併或重切。
• 進服務實作模組時 routing chain 走不通 → 回頭補對應主章。

本文的判讀錨點是：developer 和 DBA 分工要讓每個決策有清楚 owner、evidence、review gate 與 rollback，而非把資料庫丟給某一方。

Ownership Map

Ownership map 的核心責任是定義誰能改什麼、誰要驗證什麼。

這張表的重點是 shared gate。Developer 最懂產品語意，DBA / platform 最懂資料庫風險；正式變更需要兩邊的 evidence 合併。

Schema and Migration

Schema and migration 的核心責任是讓 application release 與 database change 同步。Developer 應提供 business invariant、compatibility window、read/write path；DBA / platform 應審查 lock、index build、table rewrite、replica lag 與 rollback。

Migration review 要從 failure mode 開始。若 migration 卡住，誰停止 rollout；若 backfill 造成 lag，誰降速；若 app 新舊版本同時存在，哪個 schema 能兼容兩者。

Query and Capacity

Query and capacity 的核心責任是把 query shape 和 database resource 對齊。Developer 負責避免 N+1、長交易、無界查詢與錯誤 pagination；DBA / platform 負責 index、statistics、vacuum、work_mem、connection 與 storage。

Query review 的最小 evidence：

1. SQL text 或 repository method。
2. Expected cardinality 與資料量。
3. EXPLAIN / EXPLAIN ANALYZE 結果。
4. Index 依賴與 fallback plan。
5. Timeout、pagination、transaction boundary。

Capacity review 要把 query 放進 workload。單一 query 快不代表整體穩定；高頻 query、batch job、migration backfill、CDC consumer 都會共享 I/O、CPU、lock 與 WAL。

Incident Roles

Incident roles 的核心責任是讓資料庫事故有分工。Incident 發生時，developer 看 workflow、feature flag、traffic 與 recent deploy；DBA / platform 看 lock、replica、WAL、disk、pooler 與 backup。

Incident command 要保留決策紀錄。資料庫事故常有高壓操作，例如 kill session、promote replica、drop slot、restore backup；每個操作都要記錄原因與回復路線。

Review Cadence

Review cadence 的核心責任是把資料庫品質納入日常。建議節奏如下：

Review cadence 要跟服務風險對齊。高交易量或合規服務需要更短週期；內部工具可以更輕量，但仍要保留 backup / restore evidence。

Handoff Artifact

Handoff artifact 的核心責任是讓下一位維護者能接手。

最小內容：

1. Database owner、application owner、platform owner。
2. Schema migration process 與 rollback route。
3. Query review checklist。
4. Connection / pooler policy。
5. Backup / PITR / DR evidence。
6. Security / role / audit owner。
7. Incident escalation route。

這份 artifact 應連回 PostgreSQL overview、Schema Migration Evidence Lab 與 PITR Restore Drill。

下一步路由

責任分工建立後，migration gate 讀 Online Schema Change；連線責任讀 Connection Pooler Comparison；安全責任讀 Security / RLS / Audit Logging。

mTLS 的核心是把系統身分綁到 X.509 憑證與私鑰，而不是可重用的 shared secret。介紹文章常把它簡化成「雙向 TLS 憑證、適合金融醫療」，但實際落地時，設計責任會立刻延伸到 CA 階層、憑證生命週期、撤銷與基礎設施整合：

• 自簽 CA 還是商業 CA？
• 憑證放哪、怎麼 rotate？
• 怎麼撤銷？CRL 還是 OCSP 還是 short-lived cert？
• nginx 設定怎麼寫、service mesh 怎麼整合？
• 跟 API Key、OAuth 比，什麼情境適合承擔 mTLS 的運維成本？

這些是 mTLS 第一次部署就要處理的基本問題。若只知道「雙向憑證」而沒有 lifecycle 設計，系統會在過期、撤銷或 mesh 升級時失去可預測性。

本文拆解 mTLS 的工程實務：

1. CA 階層：為什麼要分層、Root CA / Intermediate CA / Leaf cert
2. 憑證生命週期：簽發、儲存、rotation、撤銷
3. 基礎設施整合：nginx / envoy / service mesh 設定模式
4. 跟其他 Layer 2 方案的取捨：何時 mTLS 才是對的選擇

本文位置：本文是 API 認證的三層信任邊界 Layer 2 的深入篇之一。主文聚焦「為什麼系統間要獨立 credential」、本文聚焦「用 mTLS 實作這層的具體工程細節」。

mTLS 解什麼問題

跟一般 TLS 的差異

一般 TLS（HTTPS）是單向認證：client 驗證 server 身分，server 再透過 API Key、token 或 session 辨識 client。

1client ────"我要連 example.com"────▶ server
2       ◀───server 出示憑證───────── server
3       驗證:"這是真的 example.com 嗎"
4       ↓
5       建立加密通道

client 驗證 server、但 server 不驗證 client。Client 是匿名的、靠後續 API Key / token 認證。

mTLS 加上反向驗證：server 也在 TLS handshake 階段驗證 client 憑證，把系統身分提前到連線層建立。

1client ──"我要連 example.com、這是我的憑證"──▶ server
2       ◀──server 出示憑證───────────────────── server
3       
4       雙方驗證對方憑證：
5       client: "這是真的 example.com 嗎"
6       server: "這個 client 是被授權的嗎"
7       ↓
8       建立加密通道、且雙方都已認證

每個 client 有自己的憑證、server 用 CA 信任鏈驗證 client 憑證是否合法。Client 的身分綁定在 X.509 憑證上、不需要額外的 API Key。

mTLS 解的具體威脅

mTLS 的核心優勢是：client 端的 private key 是 scope-bound、不跨系統共用。私鑰理論上不離開 client，且驗證憑藉的是 CA 簽章而非可重用字串；相較 shared API Key，一個 client 的私鑰外流通常可被限制在該 client 的憑證與授權範圍內。

代價是：PKI 基礎建設複雜、憑證生命週期管理重、運維成本高。

CA 階層設計

為什麼要分層

CA 分層的核心責任是降低最高信任根的暴露頻率。直覺做法是「用一張 Root CA 直接簽 client 憑證」：

1Root CA ──signs──▶ client-A.crt
2        ──signs──▶ client-B.crt
3        ──signs──▶ client-C.crt
4        ...

Root CA 私鑰是整個 PKI 的最高信任根，通常需要離線、HSM 與多人簽核。它一旦洩漏，所有信任這個 Root 的系統都要重新建立信任；Root CA 又通常活 10-20 年，撤換成本極高。

如果 Root CA 私鑰要常常拿出來簽 client cert、暴露風險就大幅提高。

解法：分層。Root CA 只簽 Intermediate CA、Intermediate CA 負責日常簽發 client cert：

1Root CA (offline, 20 年)
2    ↓ signs (一次性 / 5-10 年)
3Intermediate CA (online, 1-5 年)
4    ↓ signs (日常、每張 90 天-1 年)
5Leaf certificates (client / server)

Root CA 通常完全離線（air-gapped 機器、硬體 HSM）、私鑰一年只拿出來簽幾次（簽 Intermediate）。Intermediate CA 才是 online、處理日常簽發。

階層帶來的好處

三種典型部署模式

模式 A：自管 CA

完全自己跑 CA infra：

• Root CA：離線 HSM、年度作業簽 Intermediate
• Intermediate CA：online、用工具如 step-ca、cfssl、Vault PKI、Smallstep
• Leaf cert：自動化簽發、短 TTL

適合：純內部系統、不需 public trust、要完全控制 CA infrastructure。

模式 B：商業 CA（DigiCert / Sectigo / Entrust）

買商業 CA 服務、商業 CA 已預埋進所有 OS / browser trust store：

• 適合：需要 public trust（HTTPS server cert、SSL/TLS for end users）
• mTLS client cert 通常在自己的封閉系統內驗證，public trust 的價值較低，因此較少使用商業 CA

模式 C：Cloud-managed PKI

雲廠商提供 managed PKI：

• AWS Private CA（ACM PCA）— managed Root + Intermediate
• GCP Certificate Authority Service
• Azure Key Vault Certificates

適合：已在某朵雲、不想自管 CA infra、可接受 vendor lock。

自管 CA 的最小工具鏈

如果走模式 A、推薦工具：

step-ca 是最低門檻的起手選擇 — 一行 step ca init 建好整套 CA、自動發 ACME 給 client。

憑證生命週期

簽發

Server cert 簽發流程：

11. Server 產生 private key (RSA 2048+ 或 ECDSA P-256)
22. Server 用 private key 產生 CSR (Certificate Signing Request)
33. CSR 送給 CA
44. CA 驗證 CSR 內容（DN、SAN、用途）
55. CA 用 Intermediate CA 私鑰簽 cert
66. 把簽好的 cert 回給 server
77. Server 部署 cert + 自己的 private key

Client cert 簽發流程：跟 server 一樣，但 SAN 通常是 client identifier（service name、device ID），而非 hostname。

私鑰留在產生端

關鍵安全原則是：private key 在哪產生、就只在那裡存活。CA 只收 CSR（裡面只有 public key），簽完 cert 回去；client private key 全程留在 client 的受控環境。

失效模式：

• CA 幫 client 產生 keypair、把 private key 跟 cert 一起寄給 client（密鑰在 CA 經手了）
• 把 private key 跟 cert 打包成 PKCS12 用 email 寄
• 把 keypair 放進公共 git repo

操作路由：

• Client 端產生 keypair、只送 CSR 給 CA（CSR 只含 public key）、簽完 cert 回來、private key 全程不離開 client

儲存

Private key 的儲存等級：

Production server cert 私鑰至少應該 OS 層保護（檔案權限 + 加密磁碟）、高敏感場景上 HSM。

Rotation

mTLS 憑證的 rotation 跟 shared secret rotation 概念類似、但有具體差異：

實務上的 rotation 模式：

短 TTL + 自動續發（推薦）：

• Leaf cert TTL 設短（24 小時 ~ 7 天）
• 用 ACME protocol（如 Let’s Encrypt 的協定）讓 client 自動續發
• rotation 由續發流程承擔，過期前自動換新

工具：cert-manager（K8s）、step-ca + step、certbot。

中 TTL + 半自動（傳統）：

• TTL 1 年、年度手動 rotation
• 用工具列管所有 cert 的 notAfter、過期前 30 天自動告警
• 適合舊架構、無法跑短 TTL 的場景

長 TTL（不建議）：

• TTL 多年、近乎不 rotate
• 私鑰暴露窗極長、被洩漏到察覺的時間差大
• 唯一情境：IoT 設備、無法 OTA 更新

撤銷

當 cert 在 notAfter 前需要失效（私鑰洩漏、員工離職、合約終止）、需要撤銷機制。有三種主流方案：

CRL（Certificate Revocation List）

CA 維護一份「已撤銷憑證 list」、定期發佈（小時級到天級）。Client 端要：

1. 下載最新 CRL
2. 連線時檢查對方 cert 是否在 CRL 內

優點：簡單、infrastructure 輕。

缺點：

• CRL 大、下載成本高
• Cache 期內撤銷不生效（最差幾小時）
• Client 沒下載 CRL、撤銷完全沒效

OCSP（Online Certificate Status Protocol）

Real-time 查詢、client 每次連線時即時 query OCSP responder：「這張 cert 還有效嗎？」

優點：Real-time、撤銷即時生效。

缺點：

• 每次連線增加一次 OCSP query、延遲
• OCSP responder 是 single point of failure
• Privacy 顧慮（每次連線都告訴 CA 你在連誰）

進階：OCSP Stapling — server 預先 query OCSP、把結果 staple 在自己的 cert chain 裡、client 不需自己 query。解決延遲跟 privacy、但 server 端要實作。

Short-lived cert（不撤銷、讓它過期）

最現代的做法：cert TTL 極短（小時、甚至分鐘）、不實作撤銷機制、靠過期自然失效。

優點：

• 可省略 CRL / OCSP infrastructure
• 撤銷窗 = TTL（小時級）、可預期
• Privacy 友善

缺點：

• 需要可靠的自動續發機制
• Client 無法續發時直接斷線

工具：SPIFFE/SPIRE 主推這個模式、cert TTL 設小時級。

三種撤銷方案的選擇

基礎設施整合

nginx 設定 mTLS server

最常見的場景：nginx 當 reverse proxy、要求 client 出示憑證。

 1server {
 2    listen 443 ssl;
 3    server_name api.example.com;
 4
 5    # Server cert (出示給 client)
 6    ssl_certificate     /etc/ssl/certs/api.crt;
 7    ssl_certificate_key /etc/ssl/private/api.key;
 8
 9    # 要求 client 出示憑證、用這個 CA 驗證
10    ssl_client_certificate /etc/ssl/ca/client-ca-chain.pem;
11    ssl_verify_client on;            # 強制 client 出示憑證、否則拒絕
12    ssl_verify_depth 2;              # 驗證 chain 深度、視 PKI 階層調 (Root → Intermediate → Leaf)
13
14    location / {
15        # 把 client cert 資訊傳給後端 application
16        proxy_set_header X-Client-DN  $ssl_client_s_dn;
17        proxy_set_header X-Client-Verify $ssl_client_verify;
18        proxy_pass http://backend;
19    }
20}

關鍵 directive：

nginx 設定 mTLS client（呼叫上游）

當 nginx 是 client、要呼叫上游 mTLS server：

1location /upstream {
2    proxy_pass https://upstream.example.com;
3    proxy_ssl_certificate     /etc/ssl/certs/client.crt;
4    proxy_ssl_certificate_key /etc/ssl/private/client.key;
5    proxy_ssl_trusted_certificate /etc/ssl/ca/upstream-ca.pem;
6    proxy_ssl_verify on;
7}

Envoy / API Gateway 整合

Envoy 是 service mesh 的常見 data plane、mTLS 設定模式：

 1listeners:
 2- name: api_listener
 3  address: { socket_address: { port_value: 443 } }
 4  filter_chains:
 5  - transport_socket:
 6      name: envoy.transport_sockets.tls
 7      typed_config:
 8        "@type": type.googleapis.com/envoy.extensions.transport_sockets.tls.v3.DownstreamTlsContext
 9        common_tls_context:
10          tls_certificates:
11          - certificate_chain: { filename: /etc/ssl/api.crt }
12            private_key:      { filename: /etc/ssl/api.key }
13          validation_context:
14            trusted_ca: { filename: /etc/ssl/client-ca.pem }
15        require_client_certificate: true

上方只展 inbound listener 的 DownstreamTlsContext。Envoy 作為 client 呼叫上游 mTLS server 時、要在對應的 cluster 配 transport_socket + UpstreamTlsContext（含 client cert + private key + trusted CA）、不在這份 listener 設定裡。

跟 nginx 比、Envoy 的優勢：

• 動態設定（xDS API、不需 reload）
• 支援 SDS（Secret Discovery Service）動態取憑證
• 跟 Istio / Linkerd 等 mesh 整合

Service Mesh（Istio / Linkerd）

Service mesh 內建 mTLS：

1# Istio: 強制 mesh 內所有 service 走 mTLS
2apiVersion: security.istio.io/v1beta1
3kind: PeerAuthentication
4metadata:
5  name: default
6  namespace: production
7spec:
8  mtls:
9    mode: STRICT

機制：

• Mesh control plane（Istio: Istiod / Linkerd: identity）內建 CA、自動發每個 pod 一張 cert
• Sidecar proxy（Envoy / Linkerd proxy）handle TLS termination、application code 完全不感
• Cert TTL 短（Istio 預設 24 小時、視版本而定）、自動續發
• mTLS identity 綁定 K8s ServiceAccount

優點：application 完全不用改 code、不用管 cert、不用管 rotation — mesh 全包。

缺點：綁定整套 mesh 架構、運維 mesh 本身是大事、學習曲線陡。

為 application 直接做 mTLS

某些場景（沒 mesh、需要 application 級控制）需要 application 直接做 mTLS：

1# Python requests 範例 - mTLS client
2import requests
3
4response = requests.get(
5    'https://api.example.com/data',
6    cert=('/path/to/client.crt', '/path/to/client.key'),
7    verify='/path/to/server-ca.pem',
8)

 1// Go net/http 範例 - mTLS client
 2cert, err := tls.LoadX509KeyPair("client.crt", "client.key")
 3if err != nil { return err }
 4
 5caCert, err := os.ReadFile("server-ca.pem")
 6if err != nil { return err }
 7caCertPool := x509.NewCertPool()
 8caCertPool.AppendCertsFromPEM(caCert)
 9
10client := &http.Client{
11    Transport: &http.Transport{
12        TLSClientConfig: &tls.Config{
13            Certificates: []tls.Certificate{cert},
14            RootCAs:      caCertPool,
15        },
16    },
17}
18resp, err := client.Get("https://api.example.com/data")

每個語言的 stdlib 都有對應 API、寫法大同小異。但 application 要自己處理 cert reload、過期、rotation — 比 service mesh 麻煩很多。

跟其他 Layer 2 方案的成本比較

mTLS 在三層信任邊界的 Layer 2 是安全強度高、運維責任也重的選項。是否採用，要看威脅模型、合規要求、私鑰保護能力與自動化成熟度。

mTLS 適合的場景

mTLS 成本偏高的場景

常見失敗模式

失敗 1：忘記 Intermediate CA、chain 不完整

症狀：server 設定看似正確、但 client 連線時報 certificate verify failed。

根因：server 端只放了 leaf cert、沒附 Intermediate CA。Client 端只信任 Root、無法 chain 到 Root。

緩解：server 端 ssl_certificate 要放完整 chain（leaf + intermediate、不含 root）：

1cat leaf.crt intermediate.crt > chain.crt
2# nginx 用 chain.crt 而非單獨 leaf.crt

失敗 2：Cert 過期造成連線中斷

症狀：cert notAfter 過了、所有 client 突然連不上。

緩解：

• 監控 cert 過期時間、提前 30 天告警、提前 7 天緊急告警
• 用自動續發機制（cert-manager / step-ca / ACME）
• 過期防護應由系統監控與自動續發承擔，而不是依賴人工記憶

失敗 3：私鑰權限過寬、被同機其他 user 讀走

症狀：security audit 發現 /etc/ssl/private/server.key 是 644、所有 user 可讀。

緩解：

• Private key 一律 chmod 600、owner root 或 application user
• 用 systemd 跑的 service、private key 放 LoadCredential= 而非 file path
• 定期 audit /etc/ssl/ 權限

失敗 4：撤銷後 cert 仍能用

症狀：cert 撤銷了、但 client 還能連上。

根因：

• CRL 設定但 server 沒 enable CRL check
• OCSP 設定但 client 沒 query
• 用 short-lived cert 但 TTL 太長、撤銷窗不可接受

緩解：撤銷機制要端到端測試、不只「設定上有」、要驗證「實際生效」。

失敗 5：Service mesh upgrade 後 mTLS 中斷

症狀：Istio 升級後、cluster 內部分 service 互相連不上。

根因：mesh control plane 的 CA 換了、舊 cert chain 不通。

緩解：

• Mesh upgrade 走 staged rollout，分批驗證 cert chain
• Mesh 提供的 CA migration 流程要完整執行
• Staging 環境先跑升級流程

收尾

mTLS 是「用 PKI 換掉 secret 管理」的設計 — 私鑰不離 client、身分綁在 X.509 cert 上、不依賴可重用的字串。安全等級高、但代價是要建立 CA infrastructure、處理 cert 生命週期、整合到各種基礎設施。

幾個核心判斷：

1. CA 分層是基本盤 — Root + Intermediate + Leaf，讓最高信任根維持低暴露
2. 私鑰留在產生端 — CA 只簽 CSR、不碰 private key
3. 撤銷方案要實證可用 — CRL / OCSP / Short-lived 三選一，並驗證實際生效
4. Service mesh 是 cloud-native 的低成本入口 — Istio / Linkerd 把 mTLS 變成基礎設施，application 改動較小
5. mTLS 是高責任方案 — 對外開放 API、小規模、無 mesh 場景，OAuth / API Key 往往更容易維運

延伸閱讀：

• API 認證的三層信任邊界 — 本文的主篇、mTLS 在「Layer 2 系統層」的位置
• Shared Secret 安全輪替設計 — 不用 mTLS 走 secret-based 認證的對應 lifecycle 問題
• Laravel Sanctum 的 Bearer Token 設計剖析 — Layer 1 使用者層的 token 機制、跟 mTLS 解的問題不同

Shared Secret rotation 的核心責任是讓 credential 換新時維持可用性、可追蹤性與可撤銷性。它表面上像是一行 SQL update，實際上牽涉 server 與多個 client 的切換時序：

• 兩邊不同時切、就斷線
• 多 client 場景下、總有一兩個沒升級
• 緊急洩漏要立即撤換、同時控制服務中斷範圍
• Rotation 中途失敗、舊新 secret 都不通

這些是維運層的真實痛點。只說「定期 rotate your secret」只能描述目標，還需要雙密期、測試、監控、通知與回退流程，才能把 rotation 變成可執行的操作契約。

本文聚焦三件事：

1. 雙密過渡期：怎麼讓 client 可以在任意時點切換、不會斷線
2. 自動化工具：AWS Secrets Manager / HashiCorp Vault / GCP Secret Manager 各自的 rotation 機制
3. 緊急 vs 定期：兩種流程的差異、何時用哪個

本文位置：本文是 API 認證的三層信任邊界 Layer 2 的深入篇。主文聚焦「為什麼系統間要獨立 credential」、本文聚焦「Shared Secret 輪替的工程實務」。

Rotation 解決什麼威脅

Rotation 是縮短 secret 暴露窗與清理殘留 access 的 lifecycle 控制。它降低三種具體威脅：

Rotation 本身有成本與風險，切換設計不完整時會造成斷線。所以實務目標是「在切換可控的前提下，選一個能接受的頻率」。

常見定期頻率：

頻率取決於威脅模型與操作能力：NIST SP 800-63B 對多數場景認可 30-90 天足夠、過於激進的 rotation 反而提高出錯機率。7-14 天適用於合規條款明文要求或私鑰可硬體保護的場景；多數 SaaS 可以停在 30-180 天區間。

「事件觸發才換」也有合理情境。純內部 cron job、secret 外流管道少、rotation 成本大於風險時，可以選擇以事件觸發取代固定排程；重點是留下 owner、inventory 與重新評估條件。

核心機制：雙密過渡期（Dual-secret Rollover）

直接 atomic 切換的失效點

最直覺的 rotation 流程是：

1T0: 兩邊都是 secret_v1
2T1: server 端換成 secret_v2
3T2: client 端換成 secret_v2

失效點出在 T1 到 T2 之間：server 只認 v2，但 client 還在用 v1，這段窗口內的 request 都會 401。即使窗口只有幾秒，production 流量也可能產生大量錯誤。

更糟的是「client 更新後忘了 reload process」這種情境 — 配置檔已改、但跑著的 server / worker process 還握著舊 secret 在記憶體裡、直到下次重啟才生效。窗口可能拉長到幾分鐘到幾小時。

解法：server 端同時接受新舊兩把

雙密過渡期把 rotation 分成 3 個階段：

 1T0：穩態
 2  server: [v1]
 3  client: [v1]
 4  狀態：v1 工作
 5
 6T1：發新 secret、server 雙密期開始
 7  server: [v1, v2]   ← server 同時接受 v1 跟 v2
 8  client: [v1]
 9  狀態：兩個都 work、client 還沒切
10
11T2：通知 client 切到 v2
12  server: [v1, v2]
13  client: [v2]       ← client 升級、開始用 v2
14  狀態：v2 work、v1 也仍 work（過渡期）
15
16T3：確認所有 client 都切完、關閉 v1
17  server: [v2]       ← 移除 v1
18  client: [v2]
19  狀態：穩態、只 v1 失效

關鍵在於 server 在 T1-T3 之間同時接受兩把 — 不論 client 在這段期間用哪一把都能通過驗證。client 可以在自己的時程內升級、不需要跟 server 切換同步。

雙密期的長度設計

雙密期是一個可用性與暴露窗的取捨。兩把同時有效時，系統需要同時保護兩把 secret，也需要追蹤兩個版本的使用比例；時間拉太短會造成 client 來不及切換，時間拉太長會擴大舊 secret 的有效窗口。

設計建議：

監控指標：在雙密期內、應該追蹤「用 v1 vs 用 v2 的 request 比例」 — 當 v1 比例降到 0%、且持續穩定一段時間後、才安全地關閉 v1。

怎麼實作「同時接受兩把」

實作模式有兩種：

模式 A：array 比對

 1VALID_SECRETS = [
 2    os.environ['SHARED_SECRET_CURRENT'],
 3    os.environ['SHARED_SECRET_PREVIOUS'],  # 可選、若在雙密期
 4]
 5
 6def verify(received):
 7    for secret in VALID_SECRETS:
 8        if not secret:
 9            continue
10        if hmac.compare_digest(secret, received):
11            return True
12    return False

這個模式適合內部固定夥伴與少量服務，因為驗證邏輯簡單、沒有額外狀態。主要風險是兩把 secret 都要部署到 server，env var / config 變多，且每個 instance 都要確認讀到相同版本。

模式 B：secret store + version

1def verify(received):
2    current_version = secret_store.get_version('shared_secret', 'current')
3    previous_version = secret_store.get_version('shared_secret', 'previous')
4    return hmac.compare_digest(current_version, received) or \
5           hmac.compare_digest(previous_version, received)

這個模式適合對外 API 或 client 數量較多的系統，因為 secret 集中管理、版本狀態可查。主要風險是驗證流程依賴 secret store，需要設計 cache、fallback 與 store 失效時的行為。

對外開放 API 通常用模式 B、可結合 AWS Secrets Manager / Vault 等工具。內部固定夥伴系統可以用模式 A 起步、複雜後再遷移。

自動化 Rotation 工具

純手動 rotation 在 client 數量增加後不可持續 — 自動化工具的價值是把「產生新 secret → 部署到 server → 通知 client → 撤銷舊 secret」整套流程程式化。

AWS Secrets Manager

機制：

• 註冊一個 Rotation Lambda、AWS 排程觸發（例如每 90 天）
• Lambda 跑 4 階段流程：createSecret → setSecret → testSecret → finishSecret
• 每個階段都有 retry、失敗會回到上一個穩態

Lambda 範例責任分工：

雙密期天然存在：AWSCURRENT + AWSPREVIOUS 兩個 staging label 同時可讀。Client 在 rotation 進行中、可以拿到 AWSPREVIOUS 作為 fallback。

適合場景：AWS 生態系、目標 service 是 RDS / Redshift / DocumentDB（有 native rotation Lambda template）或自定義（custom Lambda）。

HashiCorp Vault

Vault 有兩種 rotation 策略：

Static Secrets + Rotation Periodic：傳統 shared secret、Vault 每 N 天自動換、puts 到 vault path、client poll 拿。

Dynamic Secrets：Vault 不存 long-lived secret、每次 client 請求時臨時產生（DB credential、AWS IAM credential 等）、TTL 短（小時到天）、過期即廢。Dynamic secret 沒有 rotation 概念 — 因為每個 secret 都只活一小段時間、洩漏窗本來就有限。

適合場景：multi-cloud、不想綁 AWS、需要 dynamic secret 跨多種 backend。

GCP Secret Manager

機制較簡單 — Secret Manager 提供 versioning、每個 secret 有多個 version、client 可指定要「latest」還是特定 version。

Rotation 流程通常自己實作（GCP 沒提供類似 AWS 的 Rotation Lambda template）：

1. addSecretVersion(name, new_secret) — 加新 version
2. 部署到 server（server 同時讀 latest + previous）
3. 通知 client / 等 client 升級
4. destroySecretVersion(name, old_version) — 撤銷舊 version

雙密期靠 client 端邏輯（同時試 latest 跟 previous）實現。

適合場景：GCP 生態系、自有 rotation 邏輯不想被 vendor opinion 綁住。

三者比較

自建 rotation 系統的最小元件

小規模系統可以自建最小 rotation 元件，前提是 secret 系統本身也被視為敏感基礎設施。最小元件包含：

1. Secret 存儲：DB table secrets(id, version, value, created_at, retired_at)
2. 發放 API：GET /secrets/current 回 latest active version
3. 驗證邏輯：應用層讀 current + previous 兩個 active version
4. 排程：cron job 觸發 rotate(secret_name) — 產新 version、標記舊版 retired、設 retired_at
5. 監控：log 每個 version 被驗證的次數、舊版降到 0 後關閉

這個方案適合內部小規模系統。判斷是否可行時，要同步檢查 DB encryption at rest、access log、權限分離與備援；否則自建系統可能把 rotation 風險轉移成 secret store 風險。

緊急 rotation：洩漏發生時的流程

跟定期 rotation 的差異

定期 rotation 目標是「不中斷服務」、所以雙密期長、給 client 充分時間切換。

緊急 rotation 目標是「最快讓舊 secret 失效」 — 即使犧牲部分可用性也要立刻撤銷。兩者流程完全不同：

緊急 rotation 流程模板

 1T0: 偵測或回報洩漏
 2   ↓
 3T0+0~15min: 評估
 4   - 確認洩漏範圍（哪些 secret、影響哪些 client）
 5   - 評估「立即斷舊 secret」對 production 的影響
 6   - 決定是否走緊急流程 vs 縮短的定期流程
 7   ↓
 8T0+15min~1hr: 部署新 secret
 9   - 產生新 secret
10   - 部署到 server、開啟雙密期
11   - 主動 push 新 secret 給已知 client（內部用 channel 通知、外部 client email + dashboard）
12   ↓
13T0+1hr~24hr: 強制切換
14   - 監控用舊 secret 的 request 比例
15   - 跟未升級的 client 個別聯繫
16   - 視情境設「強制斷線時間點」並提早警告
17   ↓
18T0+24hr~72hr: 撤銷舊 secret
19   - 即使仍有 client 在用舊 secret、也斷
20   - 接受部分服務中斷、優先於 secret 繼續暴露
21   ↓
22事後: 檢討
23   - 洩漏怎麼發生（log 翻查、code audit）
24   - 偵測機制能否更快
25   - 流程哪裡可以改進

關鍵權衡：「斷線成本」vs「secret 繼續暴露的損害」。對金融、醫療等高敏感場景、寧可斷線；對非關鍵內部服務、可能可以拉長雙密期。沒有通用答案、要場景判斷。

偵測洩漏的訊號

緊急 rotation 的前提是「知道洩漏發生了」 — 但很多洩漏直到攻擊者開始用 secret 才被發現、間隔可能是幾個月。

主動偵測手段：

把這些設成監控告警、是降低「洩漏到察覺」窗口的關鍵。

多 client 的同步難題

問題本質：client 不在你的控制範圍

對外開放 API 的場景，Shared Secret 散落在第三方 client 的 server。Rotation 因此變成「怎麼讓第三方在你的時程內配合」的協調問題，不只是技術問題。

常見痛點：

• 通知 email 進垃圾匣、第三方沒看到
• 第三方的工程師離職、新接手者不知道有 rotation 排程
• 第三方的 deploy 流程慢、提前一週通知還是來不及
• 第三方根本不在線（小型客戶、半年才用一次 API）

Grace period 設計

Grace period 是「舊 secret 撤銷後、給 client 緩衝期重新申請」的機制。比硬性 deadline 更彈性：

1T0: 公告 rotation、雙密期開始
2T0+30天: 雙密期結束、舊 secret 撤銷
3T0+30~60天: Grace period
4   - 用舊 secret 的 request 回 410 Gone（或 401 + 可讀的 error code，視 API 慣例）+ 連結到 "secret expired" 頁
5   - 提供 self-service 重設 secret 的流程
6   - 仍然斷線、但 client 知道怎麼自己救
7T0+60天: 完全關閉、需要重新申請新 client account

Grace period 的關鍵是在拒絕舊 secret 的同時，提供足夠資訊讓 client 自助修復。判讀訊號是錯誤回應是否能指出 secret 已過期、去哪裡重設、何時完全關閉；若只回無上下文的 401，client 仍會被導向錯誤排障路徑。

強制升級的工具

對於必須統一升級的場景（例如安全合規要求）、有幾種強制手段：

失敗模式與緩解

失敗 1：雙密期太短、client 沒升級

症狀：rotation 後第二週，某 client 開始 401，才發現他沒收到通知或尚未升級。

緩解：

• 雙密期至少覆蓋「最大已知 client 的 deploy cycle」
• 雙密期內監控「用舊 secret 的 client 數量」、降到 0 才關
• 緊急 rotation 例外、要事先評估可接受的斷線成本

失敗 2：rotation 中斷、新舊都不通

症狀：deploy 新 secret 到 server 中途失敗、一半 server 是新、一半是舊 — request 隨機 401。

緩解：

• 部署用 rolling update、確認每個 instance 都生效再進下一個
• 部署前確認「server 是雙密 mode」、即使部署到一半也能容錯
• 保留快速 rollback 機制（10 分鐘內能 revert）

失敗 3：新 secret 沒測通就上線

症狀：新 secret 部署完、第一個 client 試了發現格式不對 / 長度限制 / 特殊字元編碼問題、大量 401。

緩解：

• Rotation 流程加 testSecret 階段（AWS Lambda 模式）— 切換前用新 secret 跑一輪驗證 request
• Staging 環境先跑完整 rotation 流程、再上 prod
• 新 secret 的 format 跟舊一致（同長度、同字元集）、減少 client 端的 parsing 風險

失敗 4：Rotation 缺少 owner、secret 長期暴露

症狀：上次 rotate 已是 3 年前，原本的負責人離職，接手者不知道有這個 secret 存在。

緩解：

• Secret 管理工具強制設 expires_at、過期前自動提醒
• Inventory 表：所有 production secret 列管、定期 audit
• Rotation 排程進 calendar、輪值負責

失敗 5：rotation 後 audit log 沒更新

症狀：洩漏發生、要追「這個 secret 給過誰用」、但 audit log 只記了「secret 被用了」、沒記版本、無法區分新舊。

緩解：

• Audit log 記 secret version、不只 secret 本身
• Rotation 事件本身也要 log（誰、什麼時候、為什麼）
• Log 保留期跨多次 rotation cycle、避免歷史追溯斷鏈

收尾

Shared Secret rotation 的本質是有意識管理 secret 的 lifecycle。從發放、儲存、輪替到撤銷，每個階段都有對應的工程設計與監控訊號。

幾個核心原則：

1. 雙密過渡期是底層機制 — 任何 rotation 方案都建立在「server 能同時接受兩把」之上
2. 自動化工具值得投資 — 規模小用 secret manager（AWS / Vault / GCP），規模大可以自建，避免停在純手動
3. 定期跟緊急是兩套流程 — 定期重不中斷，緊急重立刻撤，流程、通知與回退標準要分開
4. 多 client 是協調問題 — 比技術問題難解、grace period + 強制升級工具是常用解法
5. 失敗模式要演練 — production 第一次跑 rotation 前，先在 staging 演練完整流程與回退路徑

延伸閱讀：

• API 認證的三層信任邊界 — 本文的主篇、Shared Secret 在「Layer 2 系統層」的位置
• Laravel Sanctum 的 Bearer Token 設計剖析 — Layer 1 使用者 token 的儲存原則（hash + constant-time）也適用於 Layer 2
• mTLS 實際怎麼設定與運維 — 不用 shared secret 的另一條路、憑證 lifecycle 跟 secret lifecycle 的對照

核心論點

共同控制面的核心概念是同一項能力同時承擔安全與穩定責任。共同控制面明確後，團隊能避免重複建設與交接斷層。

共同控制項

控制欄位對齊

控制欄位對齊的責任是讓兩個模組共享決策資料。共同欄位可包含 trigger、owner、action、validation、rollback condition 與 write-back target。

演練與驗證

演練與驗證的責任是讓控制在壓力情境保持可用。共同演練可同時驗證安全處置與可靠性恢復，並記錄雙方指標。

交接路由

交接路由的責任是把控制決策推進到 06 模組。交接資料可包含風險分級、處置結果、回退證據與後續改善任務。

與 04 / 06 / 08 的組合路由

組合路由的責任是讓共同控制面同時接上訊號、驗證與事故流程。7.23 不只把資安控制交給可靠性驗證，也把證據需求交給 04、把處置節奏交給 08。

Evidence chain 在真實服務中會落到誰在什麼時間看過什麼資料、哪個 token 被使用、哪個服務產生異常輸出。04 承接資料可觀測性，06 驗證 evidence replay 是否可重播，08 在事故 timeline 中使用同一組證據做決策與復盤。

Detection gap 在真實服務中通常表現為資安事件被客訴、成本異常或下游故障先發現。04 補 alert 與 dashboard，06 把缺口轉成 chaos hypothesis 或 release gate，08 把觸發條件寫進 severity 與 runbook。

Containment 在真實服務中同時是資安隔離與可靠性限縮。04 提供 blast radius 與 service topology，06 驗證隔離後核心服務是否維持，08 決定封鎖、切流、降級與恢復順序。

Rollback 在真實服務中需要把風險變更退回到穩定狀態。04 提供 rollback 前後的健康訊號，06 定期演練回退路徑，08 記錄誰在什麼條件下做出 rollback 決策。

Degradation 在真實服務中是保留核心功能、放棄次要能力。04 觀察容量與延遲訊號，06 驗證 degraded mode 的承載能力，08 負責對內外說明目前服務狀態與恢復節點。

判讀訊號與路由

必連章節

• 7.B3 資安控制驗證
• 7.B6 Incident Triage Loop
• 7.18 資安控制面如何交接到部署與事故流程
• 04 模組：可觀測性
• 06 模組：可靠性
• 08 模組：事故處理

完稿判準

完稿時要讓讀者能列出共同控制面與交接欄位。輸出至少包含控制項、雙責任、驗證方式與交接路由。