3. 用户生命周期管理

用户生命周期管理（Joiner-Mover-Leaver，简称 JML）是 Atlassian 身份治理的核心主线。它关注的不是某一次权限分配，而是账户从“被创建”到“被停用”的完整轨迹：谁在什么条件下获得访问权、权限如何随岗位变化而调整、离职时如何确保访问权被彻底回收。Atlassian 本身并不直接充当权威身份源，它依赖外部 IdP（如 Okta、Azure AD、Google Workspace）完成身份认证，再通过 SCIM 或用户预配把账户同步到 Atlassian Cloud。因此，JML 流程的设计必须同时考虑 IdP 侧的身份状态和 Atlassian 侧的账户、组、产品访问权三层结构。

一、生命周期三阶段与 Atlassian 对象映射

在 Atlassian Cloud 中，一个用户实际涉及四类对象：Atlassian 账户（全局身份）、产品访问权（Jira、Confluence 等产品的授权）、组（组织与权限的载体）、项目角色（项目级权限）。JML 的每个阶段，本质上都是对这四类对象的增、改、删操作。

• 入职（Joiner）：IdP 中创建用户 → SCIM 同步到 Atlassian → 加入默认组（如 all-employees）→ 授予产品访问权 → 按岗位加入职能组。
• 转岗（Mover）：IdP 属性变更（部门、岗位）→ 触发组变更 → 移除旧职能组、加入新职能组 → 复核项目角色与产品访问权。
• 离职（Leaver）：IdP 账户停用 → SCIM 同步停用 Atlassian 账户 → 撤销产品访问权 → 从所有组移除 → 保留审计记录。

关键原则是：Atlassian 侧不应成为权限的“源头”。所有身份状态变更都应由 IdP 驱动，Atlassian 只做接收与执行。这样才能避免“IdP 已停用、Atlassian 仍可登录”的治理缺口。

二、入职：从 IdP 到 Atlassian 的预配链

入职自动化的核心是“属性驱动”。以 Azure AD 为例，管理员在 IdP 中为用户填写 department、jobTitle、costCenter 等属性，SCIM 同步时这些属性会映射到 Atlassian 账户。Atlassian 的组规则可以基于这些属性自动计算成员资格。

一个可参考的配置示例：在 Atlassian Administration 中创建组 jira-developers，并设置动态规则：

group: jira-developers
rule: user.department == "研发部" AND user.jobTitle CONTAINS "工程师"
product_access: Jira Software (Standard)

当 SCIM 同步完成后，Atlassian 会自动把符合条件的用户加入该组，并继承组所绑定的产品访问权。这样，入职流程从“人工逐个添加”变为“属性匹配即自动加入”。需要注意的是，产品访问权应尽量绑定在组上，而不是直接授予个人，否则转岗和离职时容易遗漏。

三、转岗：权限的“减法”比“加法”更重要

转岗是 JML 中最容易被忽视的环节。很多组织只做了“加入新组”，却没有“移除旧组”，导致用户权限不断叠加，最终形成权限膨胀。Atlassian 的组规则是声明式的：当用户属性变化后，系统会重新计算组归属，不再匹配的组会自动移除成员。这正是动态组的价值所在。

但动态组只能覆盖“基于属性”的组。对于手工维护的组或项目角色，转岗时需要额外复核。建议在转岗流程中加入一个检查点：

• 确认旧职能组已移除（可在用户详情页查看组列表）。
• 确认新职能组已加入，且产品访问权符合新岗位。
• 复核项目角色：Jira 项目中的 Project Lead、Administrators 角色是否仍应保留。
• 检查个人访问令牌（PAT）和 API Token：转岗后旧令牌可能仍具有原权限，应要求用户重新生成或由管理员撤销。

四、离职：停用、撤销与审计闭环

离职流程的目标是“访问权归零”。在 IdP 中停用账户后，SCIM 会向 Atlassian 发送停用请求。Atlassian 账户被停用后，用户无法登录，但账户本身仍保留在系统中，以便审计和内容归属（如 issue 的 reporter、comment 的作者）。

离职操作的关键顺序是：

1. IdP 停用账户：这是唯一权威动作，其他系统跟随。
2. SCIM 同步：Atlassian 账户状态变为 suspended。
3. 撤销产品访问权：从产品授权中移除，释放许可证席位。
4. 从所有组移除：包括动态组和手工组。
5. 撤销 API Token / PAT：这些凭证不随账户停用自动失效，需单独处理。
6. 保留审计记录：Atlassian 的审计日志会记录停用时间、操作者，用于合规检查。

验证离职是否彻底，可以检查三个信号：用户尝试登录被拒绝、用户不再出现在任何组的成员列表中、产品许可证席位已释放。如果其中任何一项未达成，说明流程存在缺口。

五、自动化策略与常见陷阱

Atlassian 的 JML 自动化主要依赖三条链路：IdP 作为权威源、SCIM 作为同步通道、动态组作为权限计算引擎。三者配合，才能实现“入职自动开通、转岗自动调整、离职自动回收”。

常见陷阱包括：

• SCIM 同步延迟：IdP 变更后，Atlassian 侧可能延迟数分钟到数十分钟。离职场景下，这个窗口期是风险，建议在 IdP 侧先禁用登录，再等待同步。
• 手工组残留：动态组之外的组不会被自动清理，需要定期审计。
• API Token 遗漏：账户停用不等于 Token 失效，必须单独撤销。
• 产品访问权直接授予个人：绕过组会导致离职时遗漏，应统一改为组授权。

总结来说，Atlassian 用户生命周期管理的核心不是“在 Atlassian 里管用户”，而是“让 IdP 管用户，让 Atlassian 跟随”。入职靠属性驱动自动开通，转岗靠动态组自动调整，离职靠 SCIM 同步加人工复核实现彻底回收。只有把权限授予统一收敛到组，把身份状态统一收敛到 IdP，JML 流程才能真正做到可自动化、可审计、可验证。