如何在某人离职前重新分配资源所有权
内容提要
员工晋升或转岗后，云资源的所有者标签常被忽略，导致已不负责该职责的人仍能审批资源。建议用SQL查询比对所有者标签与IAM最后访问记录，找出90天无活动者；将所有权设为IAM角色而非标签，并用Rego策略强制要求有活跃所有者。流程上应先重新分配再撤销权限，避免内部调动造成所有权滞后。
延伸解读
内部转岗比离职更容易留下所有权盲区
文章指出，员工晋升或转岗时，HR和IT会更新头衔与门禁，但云资源的所有者标签常被忽略。Marcus晋升后，41个环境仍标记他为所有者，八个月后他仍收到审批请求并点击通过。内部调动不触发离职清单，却让原所有者不再合适，这种滞后比正式离职更隐蔽，也更常见。
用90天静默查询定位过期所有者
文章建议将所有者标签映射到IAM用户名，再与最后访问记录比对。AWS和Entra ID可直接关联，GCP则需借助Google Workspace登录记录。查询找出90天内无活动的所有者，作为需要人工确认的信号。这并非确凿证据，但能避免问题被搁置数月，值得花十五分钟核实。
把所有权从标签升级为可强制执行的IAM角色
仅靠标签无法阻止交接遗漏。文章主张将所有权设为IAM角色绑定、Kubernetes RoleBinding或IaC平台中的自定义角色，并用Rego策略强制要求资源至少有一个活跃所有者。这样在撤销或转移权限时，若未指定替代者，策略会立即拒绝，而不是等数月后被人发现。
流程上先重新分配，再撤销权限
文章强调，在撤销某人访问权限前，应先运行查询找出其仍拥有的资源，并交由经理或团队负责人重新分配。顺序不能颠倒：先重新分配，再撤销。否则内部调动后，原所有者可能仍保留审批权，造成所有权与职责脱节。这一步骤可嵌入现有离职或转岗流程，无需额外重组。
Q&A
员工晋升或转岗后，为什么云资源的所有者标签容易过期？
因为基础设施所有权的更新往往不被视为任何人的职责，HR和IT会更新职位和门禁，但资源标签却没人动，导致已不负责该职责的人仍能审批资源。
如何用SQL查询找出90天无活动的资源所有者？
将所有者标签中的邮箱映射到IAM用户名，并与IAM最后访问记录表关联，筛选出最后活动时间超过90天的资源。例如AWS中查询aws_iam_user_last_accessed_details，Entra ID中查询entraid_auditlogs_signins，GCP中查询googleworkspace_users。
为什么建议将资源所有权设为IAM角色而不是标签？
因为标签是未强制执行的字符串，而IAM角色可以被策略引擎看到并强制执行。将所有权作为角色分配（如云IAM绑定、Kubernetes RoleBinding）能确保资源始终有活跃所有者，避免审批请求误发给已不负责的人。
如何用Rego策略强制要求资源必须有活跃所有者？
编写Rego策略，检查资源的owner角色数量是否为零，若为零则拒绝。例如：deny[format(rego.metadata.rule())] { count(input.resource.roles.owner) == 0 }。该策略可在策略评估点运行，如OPA服务器或平台内置策略引擎。
在员工离职或转岗时，重新分配资源所有权的正确流程是什么？
先重新分配，再撤销权限。在撤销访问权限前，运行查询找出该员工拥有的资源，并将结果发送给其经理或团队负责人进行重新分配，避免所有权滞后。
内部转岗比离职更容易导致所有权问题吗？
是的，内部转岗更常见且往往不被重视。2024年近三分之一的职位由内部填补，但因为没有离职，不会触发离职检查清单，导致资源所有者不再合适却仍保留访问权限。
