把 Mac mini M4 当可调度构建节点时，真正会「一键接管队列」的往往是泄露的注册令牌或权限过大的 PAT，而不是 SSH 口令。本文为 2026 年可执行清单：先给轮换节奏与凭证存放边界，再给「泄漏场景—优先动作」矩阵，最后附八步应急响应与 CMDB 必填字段。文内含两张不同结构的表与至少八条带数字的阈值，可直接贴进值班手册。
若尚未完成 Runner 首次接入，请先读 Mac mini M4 自建 GitHub Actions。维护窗口与标签切换请与 Runner 排空与交接 对齐；多工作负载共享主机时参阅 CI 与 Agent 容量借调。需要远程控制台时打开 帮助中心 与 VNC 说明。
三类常见痛点：为什么令牌比密码更危险
- 注册令牌一次性误用：截图进 Slack、进工单附件后，任何人可在 60 分钟内把恶意 Runner 注册进同一池，队列仍显示绿色。
- PAT 范围过大：给构建机用的 token 若带
repo写权限外加工作流编辑，一次泄漏等于间接拥有所有密钥上下文。 - 凭证落盘明文：把令牌写进可被备份同步的
.env或 plist，轮换时只改云端忘了改镜像层，造成「以为已轮换」的假安全感。
轮换节奏与存放方式对照
| 凭证类型 | 建议最长寿命 | 推荐存放 |
|---|---|---|
| 组织/仓库 Runner 注册令牌 | 单次使用，≤1 小时窗口内消费 | CI 密钥管理器临时注入，不进镜像 |
| 细粒度 PAT（仅注册 Runner） | 90 天复审，30 天预警 | macOS 钥匙串 + 最小 scope |
| 用于 API 调试的宽 PAT | 7 天或禁止上构建机 | 仅个人笔记本，禁止写入 Runner 用户目录 |
泄漏场景优先动作矩阵
下列矩阵解决值班时最常见的争论：「先删 Runner 还是先吊销 token」。按行执行第一列动作，再进入八步清单。
| 已知泄漏面 | 第一动作 | 第二动作 | 验证 |
|---|---|---|---|
| 注册令牌文本在公开频道 | 吊销并重新生成组织级注册流程 | 审计过去 24 小时内新注册的 Runner ID | 未知主机全部移除 |
| PAT 可写仓与工作流 | 供应侧立即 revoke | 扫描异常 workflow 提交 | 默认分支保护规则仍生效 |
| 仅 Runner 会话 cookie 疑似失窃 | 下线对应主机并轮换机器级密钥 | 检查是否有非预期 outbound | 新会话仅从新令牌启动 |
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后缀便于审计。 - 验证工作流最小权限：跑一条只读克隆 + 空构建，确认无写仓权限外泄。
- 复盘写入 postmortem：说明为何凭证会出现在聊天工具，以及自动化缺口。
- 72 小时内二次扫描：检查是否仍有旧 PAT 在调用 API（按 OAuth app 维度）。
值班演练：每季度一次的「假泄漏」桌面推演
把注册令牌的一段假字符串贴进演练频道，计时看是否在 15 分钟内有人按矩阵执行吊销与 Runner 审计。多数团队第一次演练会卡在「谁有权限 revoke 组织 token」——这正是要提前修掉的单点。演练后更新联系人列表与备用审批人，避免真实事件发生在公共假期时无人可签。
桌面推演不必动真实生产：用 staging 组织与一台闲置 Mac mini 即可完成。记录每次推演的「决策耗时」与「误操作次数」，连续两次改进低于 10% 再考虑降低演练频率。该习惯与 预发与生产 Runner 池拆分 天然契合——泄漏演练只在隔离池打满火力，生产池只观察告警是否穿透。
与云 Mac 供应商协作时的边界
供应商负责物理机隔离与网络边界，你不应假设对方能看见 GitHub 组织内部的 PAT。把「令牌轮换」定义为应用层责任，在 RFP 里写清：谁生成注册令牌、谁保留审计日志。突发加机时，用 按区域定价 租用时，仍使用同一套最小权限 PAT，而不是临时放宽 scope「先跑起来再说」。
Mac mini M4 作为 Apple Silicon 独占物理机，便于你做「一机一 Runner 身份」与磁盘级隔离，减少邻居攻击面；统一内存也让密钥解析与编译并行时更少触发可疑交换。NodeMac 在香港、日本、韩国、新加坡与美国提供 SSH 与 VNC，适合在吊销后快速拉起干净节点；按需租赁降低采购周期，使令牌事件后的容量恢复与合规审计能同周完成。把节点当牲畜管理时，硬件交付速度与凭证周转速度同样决定 MTTR。