2. Atlassian云平台身份模型
在Atlassian云平台中，权限治理之所以容易出错，根本原因往往不是“不会点按钮”，而是没有把身份模型中的四层对象分清楚：Atlassian账户、站点、组织、产品角色。它们不是同一维度的概念，而是从“人”到“资源”再到“授权”的逐层映射。理解这四层之间的关系，是后续做用户生命周期管理、访问审查和最小权限收敛的前提。
一、四层对象各自是什么
Atlassian账户是“人”的身份载体。它由邮箱唯一标识，是用户登录Atlassian云服务的凭证。一个自然人通常只有一个Atlassian账户，但这个账户可以同时属于多个站点、多个组织。账户本身不携带任何产品权限，它只是身份主体。
站点（Site）是产品的运行实例与资源边界。例如一个Jira站点、一个Confluence站点，或两者共用的站点。站点拥有自己的用户列表、产品订阅、项目空间和数据。站点是“资源在哪里”的答案，也是权限生效的边界——权限只在站点内部有意义。
组织（Organization）是管理边界，而不是资源边界。组织用于集中管理多个站点、统一控制账户、配置安全策略（如强制两步验证、会话时长）、管理域名声明和账单。一个组织可以包含多个站点，一个站点也可以被迁移到另一个组织下。组织解决的是“谁来统一管”的问题。
产品角色（Product Role）是授权层，决定用户在某个站点内能做什么。它分为两类：站点级角色（如User、Admin、Customer）和产品级角色（如Jira Administrator、Confluence Administrator、项目角色中的Administrator/Member/Viewer）。产品角色是“能做什么”的答案。
二、四层之间的映射关系
把四层串起来看，关系是：账户通过被加入站点获得访问资格，站点归属某个组织接受统一治理，用户在站点内被赋予产品角色从而获得具体权限。这里有两个关键点容易被忽略：
- 账户是全局的，站点是局部的。同一个账户在A站点是管理员，在B站点可能只是普通用户，权限互不影响。
- 组织不直接授予产品权限。组织管理员可以管理账户、策略和站点归属，但不能仅凭组织身份直接操作某个Jira项目——那需要站点内的产品角色。
下面这张图展示了四层对象的结构关系与授权流向，注意区分“管理边界”和“资源边界”两条不同的路径。
三、权限层级：从站点角色到项目角色
产品角色内部还有层级。以Jira为例，站点级角色决定用户能否进入站点、能否访问管理功能；项目级角色决定用户在具体项目中的操作范围。两者是叠加关系，不是替代关系。
| 层级 | 典型角色 | 作用范围 | 治理关注点 |
|---|---|---|---|
| 站点级 | User、Admin、Customer | 整个站点 | 谁可以登录、谁可以进管理后台 |
| 产品级 | Jira Administrator、Confluence Administrator | 单个产品 | 产品配置、全局方案、应用管理 |
| 项目/空间级 | Administrator、Member、Viewer | 单个项目或空间 | 具体业务数据的读写与配置 |
一个常见误区是：把用户设为站点Admin就以为他自动拥有所有项目权限。实际上，站点Admin可以管理用户和全局设置，但如果没有被加入某个项目，他仍然看不到该项目的内容（除非项目权限方案允许）。反过来，一个项目Administrator可能只是普通站点User，却能完整管理该项目。这说明站点角色和项目角色是两条独立的授权路径，治理时必须分别审查。
四、组织与站点的归属关系
组织与站点之间是“管理归属”关系，不是“包含”关系。一个组织可以管理多个站点，但站点内的数据、项目、空间仍然属于站点自身。组织管理员可以：
- 查看和管理组织下所有站点的用户账户；
- 强制安全策略，如两步验证、会话超时、密码策略；
- 声明域名，控制哪些邮箱可以自动加入站点；
- 管理账单和产品订阅；
- 将站点移入或移出组织。
但组织管理员默认不能直接进入某个站点的项目去修改权限方案——那需要该站点内的产品角色。这个边界在事件响应时尤其重要：当发生权限泄露时，组织层可以快速禁用账户，但清理项目级授权仍需站点管理员配合。
五、实际治理中的检查顺序
基于以上模型，做权限审查时建议按以下顺序推进，避免遗漏：
- 账户层：确认账户是否仍属于在职人员，邮箱是否有效，是否启用了两步验证。
- 组织层：检查账户是否在正确的组织下，安全策略是否覆盖，域名声明是否准确。
- 站点层：确认账户加入了哪些站点，是否仍需要访问该站点。
- 产品角色层：逐个站点检查站点角色和项目角色，识别过度授权。