运维人员交接怎样收回权限？个人账号、自动化身份与旧会话
一位运维人员可能拥有云控制台、SSH、数据库、代码仓库、备份和监控平台的访问权。交接时只修改服务器密码，往往会遗漏其他入口；如果自动化任务长期借用个人凭据，直接关闭账号又可能让发布或备份失败。处理前需要把身份与业务依赖分别列清楚。
建立按身份而非按服务器的清单
围绕需要交接的人员，列出个人账号、所属组、授权角色、SSH 公钥、API 密钥、临时授权和管理设备。还要考虑跳板机、密码库、DNS 与证书平台等间接控制入口。只看云平台的账号列表，无法覆盖操作系统与第三方服务中的权限。
清单记录权限范围、维护者、用途和撤销方式，不保存秘密全文。对共享身份，先确认由哪些人或任务使用，再计划拆分。新负责人应得到自己的身份与必要授权，避免以长期复制旧个人账号作为交接结果。
分开处理个人操作与机器调用
个人用于登录和审阅的账号，与应用调用外部服务的身份应有不同责任边界。若发现定时任务使用即将停用人员的访问密钥，应先把任务迁移到有明确用途的机器身份，并按最小权限配置。不能为了避免影响任务，就把离任人员的账号无限期保留为管理员。
AWS IAM 移除或停用用户说明展示了密码、密钥和权限等不同入口需要分别处理的情况。其他平台的行为可能不同，应核对实际身份类型，尤其是企业统一登录、临时会话和应用令牌的失效方式。
先让新负责人完成实际任务
交接文档应包括资源归属、部署方式、备份恢复入口、告警接收和应急联系人。验收时让新负责人从自己的账号完成一次受控操作，例如查看日志、发布测试环境或读取备份清单，验证权限和说明足以完成工作。
拥有查看权限不一定能够处理关键故障，因此应按职责逐项验证。需要临时提权的流程也要说明由谁批准和如何记录。验收使用测试资源或已安排的窗口，不为了证明权限而对线上执行不必要的重启或删除。
撤销顺序结合业务和风险安排
一般交接可以先迁移任务、验证新身份，再收回旧权限；存在账号滥用或凭据泄漏风险时，可能需要优先暂停访问并安排受控恢复。顺序应由负责人与业务方明确，不能机械照搬一条通用时间表。
收回范围包括组与角色、个人密钥、授权应用、受信设备和恢复渠道。对于曾经共享的秘密，应考虑轮换，而不只是删掉一个成员名字。OWASP 认证说明可用于理解认证状态和敏感操作重新验证的设计原则，具体撤销仍以平台能力为准。
验证旧会话与直接访问路径
删除公钥通常影响后续认证，已经建立的会话是否立即结束需要另外处理。停用网页登录也不一定自动撤销独立 API 令牌。应核对各平台说明，并在授权范围内验证旧身份不能继续完成原来允许的操作。
验证记录写明账号标识、撤销时间、测试动作和结果，避免使用“全部已关闭”却没有可核对范围的结论。同时观察发布、备份和监控任务，确认它们已由新身份正常执行；若出现失败，定位遗漏依赖，避免简单恢复原个人管理员权限。
把交接变成可重复的维护流程
完成后由新负责人确认资料位置和任务归属，关闭临时授权，更新联系人与恢复资料。对仍需保留的记录设置明确的访问和保留安排，不把旧人员的个人设备作为唯一恢复入口。
定期复查权限清单，可以发现没有负责人、长期未使用或权限超过职责的身份。一次好的交接不只是收走钥匙，还应让团队知道每把钥匙对应哪扇门、谁需要使用，以及在下一次人员变化时如何可靠地重复整个过程。