更换开发者 Mac，意味着要轮换代理凭据

更换开发者 Mac 是一次访问权限变更，而不是文件传输。编辑器设置、代码仓库、Shell 历史记录和本地构建缓存可以通过普通迁移工具转移。至于能让 AI 代理调用生产 API 或建立 SSH 会话的凭据，则需要单独制定计划。

我最常见的错误，是有人把旧 Mac 当成行李箱。开发者让新机器正常运行，启动 Migration Assistant，看到熟悉的桌面，就以为迁移完成了。实际发生的事情是，多年来积累的权限、缓存令牌、被遗忘的 SSH 身份和代理工具可能已经越过信任边界，而没有人检查究竟有哪些内容被保留下来。

将数据与权限分开迁移

文件只是副本。权限则是设备持续执行设备外部操作的能力。旧笔记本离开家之后，一个 API 令牌仍然可能创建部署。即使私钥已经被复制、备份或删除，服务器也可能继续接受对应的 SSH 公钥。云端会话可能不断刷新，直到签发方撤销它。

这个区别会改变替换设备的计划。源代码、笔记和非机密配置可以先复制，因为之后还能进行比对。至于权限，应等到你决定新 Mac 需要沿用同一凭据、换用新凭据，还是根本不需要凭据之后再处理。

代理工具让这个区别更加重要。普通开发者遇到过期令牌时，可能会手动输入命令来处理。自主编程代理则可以快速发起调用、重复执行，并在你注意其他事情时继续运行。代理不需要拿到明文机密才会带来风险。只要它还能通过某条路径执行接受旧设备权限的操作，就已经足够了。

合理的迁移应该有两本清单：

• 数据清单记录代码仓库、文档、配置文件、本地数据库、备份位置和许可证材料。
• 权限清单记录所有远程系统，只要旧 Mac 上存储、由旧 Mac 签发，或从旧 Mac 获得批准的某项内容仍然存在，这些系统就会接受相应操作。

不要把两份清单合并。一个代码仓库恢复两次通常不会造成问题。一个 bearer token 被复制两次，就会产生两个需要防守的位置。这就是为什么“先迁移，之后再清理”不适用于凭据。

Apple 将 Migration Assistant 描述为用于传输文档、应用、用户账户和设置的工具。它不会删除旧 Mac 上的信息。Apple 对普通迁移的描述没有问题，但这正说明它不是凭据退役流程。除非你有意移除旧设备的权限，否则旧机器仍然是一份正在运行的副本。

默认选择重新录入

重新录入通常更安全，因为它会迫使你明确决定替换后的 Mac 可以做什么。你重新登录，在服务支持的情况下创建新的令牌或 SSH 身份，为新设备授予它所需的最小角色，并在切换成功后移除旧设备的访问权限。

这种方式看起来更慢，因为它会暴露账户迁移隐藏起来的历史问题。你可能会发现一个归属于已离开团队成员的旧部署令牌，一个权限范围远大于任务所需范围的个人访问令牌，或者一把因为没人想打断发布流程而被复制到多台机器上的 SSH 密钥。这些发现很有价值。更换设备正是少数可以修复这些问题、又不必打断现有工作环境的时机。

出现以下任一情况时，应选择重新录入：

• 旧 Mac 被用于多个角色，例如个人工作、管理和生产支持。
• 你无法说出旧 Mac 能使用的每个凭据或远程账户。
• 旧设备曾被维修、共享、丢失一段时间，或以其他方式脱离你的控制。
• 凭据签发方可以创建设备专用的令牌、证书、应用密码或 SSH 密钥。
• 你正在更换雇主、团队、受管理的设备配置或 Apple 账户。

重新录入也能让回滚更清晰。如果新 Mac 在第一个工作日出现问题，可以暂时让旧 Mac 保持在线，同时修复访问权限。这样做有成本，所以要设定一个很短的截止时间并记录下来。保留两台设备的重叠期，是为了证明新机器能够工作，不是为了逃避决定何时撤销权限。

“轮换所有凭据会制造更多需要管理的凭据”并不是一个好的反对理由。短时间内保留两个有名称、有清单记录的凭据是可控的。长期处于无人知晓某个密码管理器条目、本地钥匙串记录、备份或代理保险库是否仍携带旧权限的状态，则不可控。

加密迁移的作用很有限

在重新录入会带来无法接受的运营风险、凭据签发方不支持干净替换，或者保险库产品为这种迁移提供了经过文档说明的导出和导入流程时，可以考虑加密迁移。仅仅因为重新输入凭据很麻烦，并不足以成为使用它的理由。

不要把操作系统加密的磁盘，与可移动的加密凭据包混为一谈。全磁盘加密是在存储设备仍受其常规保护模型管理时保护设备。迁移导出文件则是一个新的对象。你需要知道它是否有独立的加密方式、解密材料是否单独保存、文件会存在多久，以及是否有人能在第二台机器上恢复它而不被发现。

在允许加密保险库导出之前，先进行以下检查：

1. 写明导出格式，以及能够读取该格式的应用版本。
2. 确认导出文件本身的加密边界，而不只是存放它的磁盘的加密边界。
3. 决定切换期间导出文件存放在哪里，并设定删除截止时间。
4. 确认新保险库如何在不暴露机密值的情况下证明导入成功。
5. 决定导入后哪些凭据记录需要退役或轮换。

只要有一个答案含糊，就使用重新录入。安全迁移往往不是失败在顺利完成的向导步骤上，而是失败在那些含糊不清的地方。

还有一个令人不舒服的事实：加密导出文件可能伪装成备份。团队可能把它导入新 Mac，宣布迁移成功，却把归档文件留在 Time Machine、共享文件服务或外置硬盘中。这个导出文件仍然是凭据容器，需要和旧 Mac 一样做保留决策。

加密迁移和重新录入并不是互相排斥的选择。实际流程可以混合使用。必要时，可以通过有文档记录的加密路径迁移影响较小的服务凭据。生产令牌、特权 SSH 密钥、签名材料，以及任何能够触达客户数据的凭据，都应重新签发。应该按照后果分类，而不是按照机密是否容易复制来分类。

在操作新 Mac 前建立权限清单

趁旧 Mac 仍然能正常工作时完成清点。不要在迁移后依赖记忆，因为迁移的设置可能让新机器看起来很完整，即使重要访问权限并没有成功转移。清单应记录机密的引用信息，而不是机密值。

一个简单文件就够了。把它存放在私有的工作位置，不要让它成为公共代码仓库的一部分。

Service: production deployment API
Purpose: release automation
Credential form: bearer token
Old-device location: agent vault record deploy-prod
Issuer: deployment service administrator
Replacement method: create new device token
Cutover test: read release status only
Old-access action: revoke old token
Owner: platform team
Status: pending

Service: build host
Purpose: remote build troubleshooting
Credential form: SSH identity
Old-device location: agent vault record build-ssh
Issuer: build host authorized_keys
Replacement method: create a new SSH key pair
Cutover test: ssh hostname
Old-access action: remove old public key
Owner: build infrastructure
Status: pending

人们最容易漏掉的字段是“旧访问权限操作”。没有它，清单就会变成新 Mac 的购物清单，而不是旧 Mac 的移除计划。

清点开发者经常忘记的凭据位置：

• 代理保险库和代理配置文件。
• SSH 配置、SSH 代理状态、硬件保护的身份，以及远程 authorized key 列表。
• 用于云控制台和身份提供商的浏览器会话。
• 软件包注册表、代码托管工具、部署系统和 CI 管理账户。
• 本地环境文件、Shell 启动文件、密码管理器、备份归档和加密可移动硬盘。

不要把实际 bearer token、私钥、恢复代码或密码放进清单。清单之所以有用，是因为它提供了足够的信息，让你能够替换和撤销访问权限，同时不会变成另一个高价值机密存储库。

为每个条目写下破坏性最小的测试。部署凭据应该先读取状态，而不是创建发布。SSH 身份应该先执行受限命令，或者连接到没有生产权限的主机。如果唯一可用的测试会修改生产环境，那么该服务的访问设计本身就存在问题，值得在下一次更换硬件前修复。

新保险库必须证明的不只是登录成功

当你能够核对预期记录，在新设备的控制措施下解锁保险库，通过保险库执行一次范围受限的操作，并检查该操作的独立记录时，新的保险库才算准备就绪。在应用中看到熟悉的标签还不够。复制过来的标签可能指向过期记录、错误账户，或根本不存在的凭据。

对于存放代理凭据的保险库，应按明确顺序执行测试：

1. 锁定保险库并尝试执行无害操作。保险库锁定时，请求应该被拒绝。
2. 通过正常的本地控制解锁保险库，再次执行同一项无害操作。
3. 启动全新的代理进程，确认授权行为符合预期的会话设置。
4. 检查该调用的单次活动记录，以及代理运行的会话记录。
5. 在移除旧 Mac 上的任何源材料之前，验证审计轨迹。

Sallyport 将机密保存在加密的本地保险库中，并执行 HTTP 和 SSH 操作，而不会把明文凭据交给代理。保险库锁定时，Sallyport 会拒绝操作，因此上面的第一项测试具有实际意义，而不是形式上的检查。

将审计命令作为验收记录的一部分：

sp audit verify

在新 Mac 上完成测试调用后运行该命令，并在迁移工单或变更日志中记录日期、操作人员、测试目标和结果。这样做不是为了增加文书工作，而是为了保留证据，证明在销毁源设备前，新机器已经生成了有效的审计轨迹。哈希链审计记录可以发现日志是否被修改，但无法告诉你是否忘记录入某个凭据。权限清单负责解决这个问题。

测试要尽量小。如果某个凭据无法安全地执行只读请求，就为迁移创建专用测试端点或受限账户。人们常常使用真实的生产变更来证明迁移成功，因为那样结果很明确。但如果目标账户错误，它也会以最糟糕的方式明确地把迁移测试变成事故。

Migration Assistant 很有用，但不是保险库协议

当你需要从旧 Mac 获取应用、用户账户、文件和设置时，Migration Assistant 可以节省数小时。它也可以从 Time Machine 备份中传输完整的用户环境。Apple 对这两种用途都有说明。这种广泛的迁移能力有助于恢复工作站，但无法精确证明哪些包含凭据的文件、会话、缓存和应用记录被带了过来。

用它处理数据清单。对于每一项权限，在按照新机器的预期控制措施进行验证之前，都把它视为不存在。这样可以避免两个问题：相信敏感状态被意外迁移过来，以及浪费时间寻找那些本来就被正确设计为不会迁移的凭据。

常见的失败过程是这样的。开发者迁移账户，打开一个代理项目，看到代理成功发出 HTTP 调用，于是认为新保险库正常工作。实际上，这次调用使用的是从浏览器获得的云会话，或复制配置文件中仍然存在的令牌。一周后，会话过期。开发者匆忙添加替换凭据，却把复制过来的凭据留在原处。结果，旧 Mac、某个备份和新保险库都能访问同一个服务。

解决办法不是禁止使用 Migration Assistant，而是隔离验证过程。在测试代理之前，关闭无关的浏览器会话，不要使用复制来的环境文件进行测试，并使用你明确录入或明确导入的保险库记录。然后检查生成的活动记录。你必须知道究竟是哪条路径执行了这次操作。

Apple 还说明，Migration Assistant 不会删除旧 Mac 上的信息。围绕这一事实设计切换流程。迁移完成画面只表示复制结束，并不表示旧设备已经安全到可以交给别人。

在抹掉旧 Mac 前撤销权限

撤销有多个层次，把它们当成一个动作会带来虚假的安全感。结束代理运行可以停止进程。从身份提供商中移除设备可能会结束部分会话。撤销 bearer token 可以阻止之后使用 API。移除 SSH 公钥可以阻止通过该身份远程登录。更改密码可能会使部分会话失效，但根据服务不同，其他会话仍可能保持有效。

在开始前，把具体的撤销操作写到每一条清单记录中。不要满足于“停用旧设备”这样的说明。远程系统对设备访问没有统一定义。

实际操作顺序可以是：

1. 撤销正在运行的代理会话，并停止旧 Mac 上的本地代理进程。
2. 轮换或撤销旧设备上仍然有效的上游 API 令牌、应用密码、云会话和服务账户凭据。
3. 从所有接受这些密钥的服务器、跳板机和代码托管账户中移除旧 SSH 公钥。
4. 在身份系统提供相关控制的情况下，移除设备信任或浏览器会话。
5. 重新检查权限清单，并为每个条目标记撤销证据。

Sallyport 的 Sessions 日志可以立即撤销代理运行，而 Activity 日志则提供可检查的单次调用记录。可以用它处理正在运行的进程这一层，然后完成上游凭据的处理。撤销本地会话，并不会撤销外部服务仍然接受的令牌。

不要先抹掉设备，因为旧 Mac 可能保存着某个不常见服务账户、硬件令牌配对信息或主机别名，而这些信息可能是你移除权限时唯一的线索。在验证新 Mac 期间，让旧设备保持关机并处于你的实际控制之下。如果测试期间必须让它保持在线，不要在上面运行代理，不要向它添加凭据，并设定明确的切换截止时间。

确认撤销后，旧 Mac 的角色就变了。它不再是备用工作站，而是暂时保留的证据，以便在服务报告异常访问时进行核查，随后就可以抹掉。

设备处置是另一项安全控制

抹掉 Mac 不能代替撤销权限，撤销权限也不能代替抹掉 Mac。两者都需要完成。远程撤销限制复制出的凭据还能执行什么操作。抹除则删除设备上的本地数据、本地应用状态、下载的源代码、浏览历史以及可能残留的保险库材料。

对于配备 Apple silicon 的 Mac，或配备 T2 Security Chip 且运行受支持 macOS 版本的 Intel Mac，请打开“系统设置”，依次选择“通用”、“传输或还原”，然后选择“抹掉所有内容和设置”。Apple 表示，“抹掉助理”会移除用户账户、用户数据、已安装的应用、Apple 服务登录状态、“查找”和激活锁。它还会抹掉宗卷，而不只是当前用户账户。

如果没有这个选项，不要通过删除文件或快速格式化磁盘来临时处理。Apple 建议旧款不受支持的硬件使用相应的恢复模式和磁盘工具抹除流程。两种方法不同，是因为支持的硬件和安全模型不同。

抹除完成后，如果你准备出售、置换、赠送或回收这台 Mac，请停留在初始设置界面。Apple 特别建议在这种情况下不要继续完成设置。继续设置只会在一台即将离开你控制范围的电脑上创建另一个本地账户。

如果旧 Mac 丢失，或你怀疑它被篡改，不要把旧用户账户恢复到新机器上。Apple 警告说，如果重置设备的原因是怀疑遭到篡改，就不应从备份恢复，因为备份可能把不需要的软件一并恢复。在这种情况下，应优先远程撤销凭据，并对替换后的 Mac 进行干净设置。

让替换流程足够简单，能够重复执行

最好的硬件替换流程不依赖某个人对机密存放位置的惊人记忆。它每次都会产生相同的记录：一份数据清单、一份权限清单、新 Mac 上的范围受限测试、旧设备的撤销证据，以及抹除确认记录。

不要要求每位开发者都成为凭据取证专家。应要求服务尽可能签发设备专用凭据，为特权访问指定名称和负责人，为工程师提供只读测试路径，并让每项服务中的撤销操作都清晰可见。这些习惯会减少更换 Mac 的工作量，也让其他安全事件更容易控制。

替换后的 Mac 在第一天只应获得它能够证明有必要拥有的权限。如果这让人觉得不方便，就让旧设备继续关机，再多做一次验证。这个延迟的代价远低于几个月后才发现一台已经丢弃的笔记本仍然能进入生产环境。