权限不会跟着工牌一起交回来
小团队里最常见的安全事故之一，是“离职半年的人还能登录”。不是他破解了什么，而是根本没人想起来要关掉他的通道。访问权限像订阅服务，不会自动到期；而加密场景里多了一些常规 IT 清单覆盖不到的钥匙：交易所子账号、多签的一席、助记词的历史副本、云盘里当年的截图、代码仓库里硬编码的 API 密钥。等某天资金异常，翻遍设备才发现漏洞在三年前的一次交接里。
撤销工作要按“先盘点、再断供、后验证”的顺序执行，顺序错了会留下空窗或遗漏。
盘点：先画出“他能碰什么”
从四个抽屉翻起。交易所层：他持有或能看到的主账号、子账号、交易 API（有没有提币权限、白名单怎么配的）、防钓鱼码邮箱。链上层：他是不是某个多签地址的签名人、是否管过冷钱包、他的邮箱是否绑定过任何需要找回的账户、他的设备有没有登录过带资产的钱包。基础设施层：服务器 SSH、域名后台、DNS、RPC 服务、监控面板、CI 流水线密钥。信息层：文档库权限、群管理员身份、共同日程、共享密码库条目的访问史。盘点产出应该是一张清单：每一项通道写明最后使用时间与关闭责任人。这里有个反直觉的提醒：盘点时不要只列“他主动申请过的权限”，更要列“他能借道抵达的权限”——比如他虽无提币权，但他的邮箱是所有账户密码重置的接收点，那他的邮箱就是资金链路上的一环。离职者能抵达的路径往往比他名义上的职务宽得多，清单画得越接近真实拓扑，后面的断供才越没有死角。
断供：按暴露成本从高到低关闭
交易所 API 和提币白名单最先处理——这类权限能直接触发资产移动，轮换时生成新密钥、删除旧密钥，并检查白名单地址里有没有离职者添加过的条目。多签席位变更遵循“先加后减”：先补上替代签名人并完成一次小额验证，再移除离场者，任何时刻不跌破签名门槛；具体操作按所用多签实现官方文档执行。然后是改密与踢会话：所有共享账号改密码，全设备登出，重置认证器绑定，域名和邮箱后台的二级验证一并核对——历史上曾有团队因忘了改邮箱而让离职者通过密码重置链路重新拿回一切。助记词层面：只要离职者见过明文助记词或私钥，该地址体系就按失陷处理，资金迁移到全新派生地址，不做“只换设备”的半吊子处置；如果他在任期间做过签名人，他经手过的授权（无限 Approve、自动续费、代付设置）也逐条复查撤销。
验证：让清单闭环比写清单重要
关闭动作做完后做三件事。第一，回登验证：用离职者曾有的每一条通道尝试登录，确认全部失效；能验证的才算关闭。第二，事件回溯：查看交易所登录历史、链上签名记录、域名操作日志里有没有他账号产生的陌生操作，有的话按安全事件处理而不是默认无事。第三，补制度：把“离职撤销”写成入职当天的交接模板，新人的每一项权限登记在案，注销才有出处。团队规模再小，也值得留一张台账——多数泄露不需要黑客，只需要一个被遗忘的子账号。本文为安全防御科普，不构成投资建议；具体功能可用性以各平台官方说明为准。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。