2. Atlassian站点架构与权限模型

在 Atlassian 云平台中，权限问题之所以经常让人困惑，根本原因在于它不是一个“单层权限系统”，而是由多个层级叠加而成的复合模型。同一个用户能否看到某个页面、能否编辑某个工作项、能否管理某个空间，往往同时受到组织层、站点层、产品层和容器层四个维度的共同影响。理解这些层级之间的包含关系与权限边界，是后续做空间治理、权限审计和最小权限设计的前提。

一、四层架构：从组织到容器

Atlassian 云的产品体系可以抽象为一条自上而下的包含链：组织（Organization）→ 站点（Site）→ 产品（Product）→ 项目/空间（Project / Space）。每一层既是上一层的成员，又向下承载具体的权限配置。

• 组织：最顶层的管理单元，通常对应一个企业或一个业务集团。组织负责管理账单、域名声明（domain claim）、用户生命周期（通过 Atlassian Guard / 目录同步）以及跨站点的安全策略。一个组织可以包含多个站点。
• 站点：用户实际访问的入口，形如 yourcompany.atlassian.net。站点是产品安装和用户许可（license）的边界，也是“站点管理员（Site Admin）”这一角色的作用范围。一个站点内可以启用 Jira、Confluence、Jira Service Management 等多个产品。
• 产品：站点内启用的具体应用，例如 Jira Software、Confluence、Jira Service Management。产品层决定用户是否拥有该产品的访问许可（product access），这是能否进入该产品的“门票”。
• 项目 / 空间：产品内部的实际工作容器。Jira 中叫项目（Project），Confluence 中叫空间（Space）。它们是权限配置最细、最频繁发生变更的层级。

需要特别强调的是：上层权限不会自动等于下层权限。拥有站点管理员身份，并不意味着能自动读取某个受限 Confluence 空间的内容；反过来，某个空间管理员也无法修改站点级的用户许可。这种“层级包含但权限不继承”的特性，正是 Atlassian 权限模型的核心难点。

二、全局权限与产品权限的边界

在站点层，Atlassian 区分了两类容易混淆的权限：全局权限（Global Permissions）和产品权限（Product Access / Product Permissions）。

全局权限作用于整个站点，决定用户能否执行站点级操作，例如：创建新站点、管理用户、管理账单、访问站点管理控制台。典型的全局权限组包括 site-admins、org-admins、user-access-admins。这些权限与具体产品无关，即使一个用户没有 Jira 或 Confluence 的许可，也可能拥有某些全局管理权限。

产品权限则决定用户能否进入某个产品，以及进入后能做什么。以 Confluence 为例，产品访问（Product Access）决定用户是否被授予 Confluence 许可；进入产品后，再通过空间权限（Space Permissions）决定对具体空间的操作能力。Jira 同理：产品访问决定能否登录 Jira，项目权限方案（Permission Scheme）决定在项目内能做什么。

三、实际场景：一次权限排查

假设运维同事反馈：用户 zhangsan@example.com 无法打开 Confluence 中的“支付平台”空间。按照层级模型，可以按以下顺序排查，而不是盲目改权限：

1. 组织层：确认该用户账号是否已被目录同步正确纳入组织，账号是否处于激活状态（未被 suspend）。
2. 站点层：确认该用户是否被授予了 Confluence 的产品访问许可。若未授予，用户登录后根本看不到 Confluence 入口。
3. 空间层：确认“支付平台”空间的权限设置中，该用户或其所属用户组是否被授予“查看（View）”权限。若空间设置了页面级限制（Page Restrictions），还需检查目标页面是否单独限制了该用户。
4. 全局层：确认该用户是否被误加入了某些全局权限组，导致其身份与预期不符（例如被加入 site-admins 后反而触发了更严格的审计策略）。

这个排查顺序体现了“从外到内、从粗到细”的原则：先确认账号与许可，再确认容器权限，最后检查全局身份。实际工作中，绝大多数“看不到内容”的问题都出在第 2 步或第 3 步，而不是全局权限。

四、治理视角下的层级设计建议

理解层级关系之后，治理策略就有了明确的着力点。建议在站点规划阶段就明确以下边界：

• 组织层只做身份与安全策略，不承载业务权限。用户生命周期、域名、SSO、审计日志放在这一层统一管理。
• 站点层控制产品启用与许可分配。避免把站点管理员权限随意授予业务人员，因为该角色可管理用户和产品配置。
• 产品层通过用户组（Group）批量分配产品访问，而不是逐个用户授权。组名建议与组织架构或职能对应，例如 jira-users-rd、confluence-users-pm。
• 容器层是权限治理的主战场。Jira 项目使用权限方案（Permission Scheme）统一模板，Confluence 空间使用空间权限与页面限制分层控制。避免在每个项目/空间里手工维护零散的用户授权。