北京
一个项目从A组织转到B组织，页面上的归属变了，成员也复制过去了。但项目里创建的API密钥和部署令牌，仍然挂在项目ID上。认证中间件只检查一件事：这把钥匙是不是属于这个项目。至于它当初是谁签发的，没人问。
于是出现这样一幕：代理商给客户做完项目，把项目移交出去。一个月后，代理商的CI令牌还在往这个项目里推代码。新组织里没有任何人创建过这把钥匙，它在组织级密钥列表里也查不到，因为它是在旧组织名下签发的。
这不是某个环节写错了代码，而是转移流程本身漏了一层。转移更新了项目的组织归属，复制了成员名单，却没有把项目上挂着的每一份凭证当成一次权限变更来处理。钥匙跟着项目走，签发它的组织却被留在了原地。
两种修法摆在面前。一种是在转移过程中直接吊销项目作用域的密钥，干净利落，代价是接手方要重新签发。另一种是在每把密钥上存一个签发组织ID，当它和项目当前所属组织对不上时，直接拒绝。后者保留了可追溯性，也让转移不必以中断为代价。
转移完成后还有一步值得做：把幸存下来的密钥列给新组织的管理员看，标明每一把是谁创建的。这样他们能自己判断哪些该留、哪些该撤，而不是在不知情的情况下继承一批陌生人的访问权。
验证方式很直接。在A组织创建一个项目密钥，把项目转移到B组织，然后用旧密钥调用API。期望的结果是401或403。如果调用照样通过，说明旧组织还留着一条进来的路。
这类问题容易在收购和团队拆分时集中出现，因为转移往往被当成一次组织架构调整，而不是一次安全边界重划。项目换了主人，凭证的户口却没跟着迁。对做SaaS的团队来说，转移接口的测试用例里，恐怕得加上这一条。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
