把 Mac mini M4 當可排程建置節點時，真正會「一鍵接管佇列」的往往是外洩的註冊權杖或權限過大的 PAT，而不是 SSH 密碼。本文為 2026 年可執行清單：先給輪換節奏與憑證存放邊界，再給「外洩情境—優先動作」矩陣，最後附八步緊急回應與 CMDB 必填欄位。文內含兩張不同結構的表與至少八條帶數字的閾值，可直接貼進值班手冊。
若尚未完成 Runner 首次接入，請先讀 Mac mini M4 自架 GitHub Actions。維護視窗與標籤切換請與 Runner 排空與交接 對齊；多工作負載共用主機時參閱 CI 與 Agent 容量借調。需要遠端主控台時開啟 幫助中心 與 VNC 說明。
三類常見痛點：為什麼權杖比密碼更危險
- 註冊權杖一次性誤用：截圖進 Slack、進工單附件後，任何人可在 60 分鐘內把惡意 Runner 註冊進同一池，佇列仍顯示綠燈。
- PAT 範圍過大：給建置機用的權杖若帶
repo寫入權限外加工作流程編輯，一次外洩等於間接擁有所有機密脈絡。 - 憑證落盤明文：把權杖寫進可被備份同步的
.env或 plist，輪換時只改雲端忘了改映像層，造成「以為已輪換」的假安全感。
輪換節奏與存放方式對照
| 憑證類型 | 建議最長壽命 | 建議存放 |
|---|---|---|
| 組織／儲存庫 Runner 註冊權杖 | 單次使用，≤1 小時視窗內消費 | CI 機密管理器暫時注入，不進映像檔 |
| 細粒度 PAT（僅註冊 Runner） | 90 天複審，30 天預警 | macOS 鑰匙圈＋最小 scope |
| 用於 API 偵錯的寬 PAT | 7 天或禁止上建置機 | 僅個人筆電，禁止寫入 Runner 使用者目錄 |
外洩情境優先動作矩陣
下列矩陣解決值班時最常見的爭論：「先刪 Runner 還是先撤銷權杖」。依列執行第一欄動作，再進入八步清單。
| 已知外洩面 | 第一動作 | 第二動作 | 驗證 |
|---|---|---|---|
| 註冊權杖文字在公開頻道 | 撤銷並重新產生組織級註冊流程 | 稽核過去 24 小時內新註冊的 Runner ID | 未知主機全部移除 |
| PAT 可寫倉與工作流程 | 供應端立即 revoke | 掃描異常 workflow 提交 | 預設分支保護規則仍生效 |
| 僅 Runner 工作階段 cookie 疑似遭竊 | 下線對應主機並輪換機器級機密 | 檢查是否有非預期對外連線 | 新工作階段僅從新權杖啟動 |
CMDB 最小欄位：每台建置 Mac 應紀錄 runner_id、關聯 PAT 指紋（hash）、最後輪換 UTC 時間、以及負責工程組。缺這四項時，平均定位時間會從 25 分鐘拖到數小時。
OIDC 工作流程身分與 PAT 的邊界（能不用 PAT 就不用）
2026 年愈來愈多團隊在 macOS Runner 上使用 OIDC 向雲端廠商換短期憑證，儲存庫側不再長期存放雲端金鑰。若你的流水線仍依賴高權限 PAT 拉子模組或呼叫組織 API，建議把「讀倉」與「部署」拆成兩個 job，前者用 GITHUB_TOKEN 預設權限即可，後者用 OIDC 或專用 deploy key。這樣即使 Mac 節點磁碟被映像帶走，攻擊者拿到的也只是短時脈絡。遷移到 OIDC 通常需要改 3～5 段 workflow 片段，但可把 PAT 輪換頻率從季度降到「僅應急」。
稽核側至少開啟組織級 audit log 匯出到 SIEM，並對 repo.*、org.register_self_hosted_runner 類事件設告警。沒有 SIEM 時，用排程腳本拉取最近 1 小時 API 變更也能涵蓋 80% 的誤註冊情境。
八步外洩回應清單
- 開立安全事件單：紀錄外洩載體（Slack／工單／日誌）、大致曝光時長。
- 依矩陣執行第一、第二動作：不要並行爭論優先順序。
- 凍結新 Runner 註冊：暫時關閉或縮窄組織政策，直到新權杖鏈就緒。
- 對可疑主機執行排空：參考排空 runbook，最長自然等待不超過你們 SLO（常見 60～90 分鐘）。
- 重新註冊乾淨 Runner：使用全新註冊權杖，主機名加
-rot-YYYYMMDD後綴便於稽核。 - 驗證工作流程最小權限：跑一條唯讀複製＋空建置，確認無寫倉權限外洩。
- 複盤寫入事後檢討：說明為何憑證會出現在聊天工具，以及自動化缺口。
- 72 小時內二次掃描：檢查是否仍有舊 PAT 在呼叫 API（依 OAuth 應用程式維度）。
值班演練：每季一次的「假外洩」桌面推演
把註冊權杖的一段假字串貼進演練頻道，計時看是否在 15 分鐘內有人依矩陣執行撤銷與 Runner 稽核。多數團隊第一次演練會卡在「誰有權限 revoke 組織權杖」——這正是要提前修掉的單點。演練後更新聯絡人列表與備用簽核人，避免真實事件發生在國定假日時無人可簽。
桌面推演不必動真實生產：用 staging 組織與一台閒置 Mac mini 即可完成。紀錄每次推演的「決策耗時」與「誤操作次數」，連續兩次改進低於 10% 再考慮降低演練頻率。該習慣與 預發與生產 Runner 池拆分 天然契合——外洩演練只在隔離池打滿火力，生產池只觀察告警是否穿透。
與雲端 Mac 供應商協作時的邊界
供應商負責實體機隔離與網路邊界，你不應假設對方能看見 GitHub 組織內部的 PAT。把「權杖輪換」定義為應用層責任，在 RFP 裡寫清：誰產生註冊權杖、誰保留稽核日誌。突發加機時，用 依區域定價 租用時，仍使用同一套最小權限 PAT，而不是暫時放寬 scope「先跑起來再說」。
Mac mini M4 作為 Apple Silicon 獨佔實體機，便於你做「一機一 Runner 身分」與磁碟級隔離，減少鄰居攻擊面；統一記憶體也讓金鑰解析與編譯並行時較少觸發可疑換頁。NodeMac 在香港、日本、韓國、新加坡與美國提供 SSH 與 VNC，適合在撤銷後快速拉起乾淨節點；按需租賃降低採購週期，使權杖事件後的容量復原與合規稽核能同週完成。把節點當可拋棄資源管理時，硬體交付速度與憑證周轉速度同樣決定 MTTR。
在臺灣與亞太區維運團隊常見的實務是：把 PAT 指紋與 Runner 主機序號一併登錄在變更管理系統，並在每次 macOS 小版本更新後複核 launchd 是否仍讀得到鑰匙圈項目；這能避免「系統更新後第一次建置就因憑證讀取失敗而人工貼權杖」的惡性循環。若你採用多區域備援，請在矩陣裡為每個區域各指定一名可簽核撤銷的負責人，避免跨時區事件卡在等待上層批核。