誰會遇到問題：在六國節點的 Apple Silicon 遠端 Mac 上並行跑構建/籤名，卻總遇到一臺 match 能解密、另一臺 CI Job 讀不到 Profile，或在輪換 ASC API Key / CI Token後出現「能編譯卻不能上傳」的假健康狀態。本文結論：把密鑰族按倉庫級與機器級分層，用輪換事件發布單串起 match / ASC / SSH / CI Token，並配最小可驗證包 + 回滾窗口。結構：六類痛點 → 三張參數表 → 六步 Runbook → 三 KPI → 選型收束；並與《Fastlane 多機構建》《TestFlight 實務》並聯閱讀。
在 2025–2026 周期，iOS 發布工程裡「看得見證書」但「流水線突然全紅」，多數不是單一鑰匙串問題，而是憑證真相源漂移：match 倉庫滾動了一半、ASC API Key 在組織裡被回收但本地 lane 仍引用舊 ID、CI 使用個人 Token 卻因權限收斂導致 job 靜默失敗。下面六條是遠程多節點場景下最常翻車的方式。
known_hosts 指紋不一致會吞進「偶發 git 失敗」。fastlane lanes 列表，而不跑一條編譯→歸檔→上傳沙盒閉環，會把問題defer 到業務發版夜。如果你在評估 GitHub/GitLab 的 OIDC 與細粒度令牌，可以把「誰對哪條 workflow 能訪問哪組 ASC Secret」畫成矩陣：六國節點只是執行平面，身份平面仍應回到組織 IAM；否則換區擴容只會複製同一邏輯錯誤。與《自建 Runner 與密鑰隔離》並聯時，請顯式標出哪些 Secret 屬於輪換窗口的凍結集。
這張表用於寫輪換發布單前的自檢：哪些可以進 Git/密鑰倉，哪些必須落在單一機器的鑰匙串與個人授權裡。
| 對象 | 更適合「倉庫級 / 組織級」真相源 | 更適合「機器級 / 白名單」隔離 | 六國遠程節點的提示 |
|---|---|---|---|
| match 加密倉庫 | 證書/描述文件的單一解密出口 | 解密口令只落在 CI Secret 與受限交互機 | 新節點必須先跑 match readonly lane，再進並發池 |
| ASC API Key（Issuer ID / Key ID） | 組織內統一 Key 與權限角色配置 | 上傳與元數據變更可拆分多 Key 最小權限 | 與《TestFlight》篇的「上傳白名單機」綁定審計 |
| SSH 密鑰 | 只讀 deploy key（倉庫側） | 每臺構建機的 host-only 跳板密鑰 | 跨區域跳板建議獨立密鑰對，避免與人工共用 |
| CI Token / PAT / OIDC | 用倉庫級 Secrets + 環境矩陣命名前綴 | 交互式 notarize 或本地驗證碼步驟 | 無人值守 job 只用窄權限的 project token |
提示：與《跨時區接力 CI》一樣，建議把「能上生產的籤名動作」限制在少量標籤 Runner 上；本篇補齊的是「輪換時這些 Runner 的憑證如何同時切」。
下列不是固定周期合同，而是工程上常見的審計節拍區間；真實落地請以你們安全團隊與 Apple 帳號策略為準。
| 憑證 | 常見觸發事件 | 典型審計節拍（區間） | 輪換後第一驗證 |
|---|---|---|---|
| match 倉庫證書 | 新設備入庫、描述文件到期預警、私鑰洩露疑雲 | 與證書自然過期同屏評審；中間至少一次 Profile 對照 | 全量 Runner 跑一次 match(type: "development", readonly: true) 同類校驗 |
| ASC API Key | 成員離職、權限審計、上傳失敗碼突變 | 常見按季度或按重大發版窗復盤 | 最小上傳沙盒：變更構建號但非生產用戶可見 |
| SSH（Git/跳板） | 跳板機遷移、漏洞通告、指紋漂移報警 | 按基礎設施季度滾動；熱點期可加密出口後重配 | 受控 clone + git ls-remote 往返延遲記錄 |
| CI Token / PAT | 供應鏈審計、倉庫遷移、Runner 註冊變化 | 短生命周期 token 可能 30～90 天（依平臺） | 讀權限 dry-run + 單一 lane 綠 |
| 策略 | 適用場景 | 代價/風險 | 執行要點 |
|---|---|---|---|
| 凍結並發（Freeze） | 高風險 match/ASC 變更 | 短時間吞吐下降 | 輪換窗內禁止 autoscaling 新節點入池，直至校驗腳本全綠 |
| 藍綠池（Pool A/B） | 中長期六國資源池 | 需要雙倍預算窗 | 一池先全量更新 Secrets，再切流量標籤 |
| 逐區滾動（Canary） | 影響面不確定的小 Key 更新 | 排期複雜 | 先亞太再北美或反向，以主製品鏈路為準 |
archive、一次連接 ASC 的 API 調用成功、一次將構建號推到內部測試通道（非外測亦可）。# 例：輪換窗口內的「探針」片段（按你們 Fastlane 封裝改名）
# fastlane run verify_signing_consistency
# 期望：所有標記為 signing 的 Runner 輸出同一組 Profile 指紋摘要
# CI：限制並行，防 half-rollout
# concurrency-group: release-credentials-${{ github.ref }}
# cancel-in-progress: false
ORG_PROD_ASC / ORG_BETA_ASC 這類前綴，避免六國節點 job 誤讀環境。口徑說明：上述區間來自跨團隊發布實踐，非 Apple 官方固定 SLA；請與內部安全制度對齊後寫進 Runbook。
補充：若你們已在用短期峰值日租節點做發版對衝，請把「入池前 Secrets 快照」與「離池前證書緩存擦除」寫進同一張 check —— 避免因臨時節點提前釋放導致 match 解密狀態與組織真相源長期分叉。
憑證輪換的本質是變更管理：需要獨佔環境、可審計日誌與一致的磁碟/網絡出口。若六國節點只靠臨時借用、沒有標籤化 Runner 與租期上限，團隊會把 match 口令散進私人筆記本，或在未知機器上手工導入證書——短期看似省事，長期會放大合規與排障成本。
個人筆記本與非專屬共享機通常難以同時滿足鑰匙串邊界、固定出口與並發凍結策略；當組織要在亞太與北美之間分配「籤名白名單池」並維持可重複輪換節拍時，使用覆蓋多地區、可按月租/季租與存儲檔位組合的專業 Mac 雲主機，通常比手工協調更穩定。MACCOME 提供 Apple Silicon 物理節點與六國可選區位，適合承載「編譯池」與「籤名/上傳白名單池」分層；建議先閱讀公開的多地區選型與租賃價格說明，再把輪換 Runbook 落表。
試點建議：選兩臺分別貼近主 Git 與主協作區的遠程機構建機，跑通一次完整輪換窗口與回滾演練，再決定是否把峰值日租併入季度預算，而不是等到發版夜才發現某區節點仍未更新 Profile。
常見問題
match 與 ASC Key 應該同一天換嗎？
不一定。關鍵是依賴圖寫清：若上傳依賴新 Key，而 match 證書尚未分發到所有節點，應優先完成 match 只讀校驗後再切上傳鏈。需要節點與租期底表時可對照 多地區節點與租期指南。
六國節點上 SSH 指紋變了怎麼辦？
把指紋變更納入輪換事件，與跳板/製品機 owner 對齊；自動化鏈路建議啟用可預期指紋或限定跳板鏡像版本，避免「人工 yes 過去」混進 CI。幫助文檔見 幫助中心。
輪換後只失敗在 TestFlight 上傳，該先看哪篇？
上傳階段與證書編譯階段診斷路徑不同，建議並聯打開《TestFlight 與 Beta 分發實務》並對照 ASC 處理隊列，而不是僅重複跑 match。