4. 组与角色设计原则

在 Atlassian 体系（Jira、Confluence、Bitbucket 等）中，权限并不是直接授予某个人的，而是通过一条“身份 → 组 → 角色 → 权限方案”的链路逐层传递。权限蔓延（Permission Creep）几乎总是源于这条链路的某一层被随意扩张：有人被临时加进一个高权限组却从未移除，有人被直接授予项目角色而绕过了组管理，有人为了省事把“所有人”加进了某个权限方案。要避免这些问题，核心不是事后审计，而是在设计阶段就确定组、角色与权限方案三者的边界与映射关系。

三层职责：组管人、角色管事、权限方案管能力

先把三个概念区分清楚，这是所有设计决策的基础：

• 组（Group）：回答“谁是谁”。组是用户的集合，是身份治理的最小单位。组本身不携带任何权限，它只是把人聚合起来，便于批量管理。例如 dept-rd-frontend、contractor-vendor-a、jira-administrators。
• 项目角色（Project Role）：回答“在这个项目里，这个人扮演什么角色”。角色是项目级的，同一个用户在不同项目中可以是不同角色。例如某人在 A 项目是 Developers，在 B 项目是 Administrators。
• 权限方案（Permission Scheme）：回答“这个角色/组能做什么”。它把权限（如 Browse Projects、Edit Issues、Administer Projects）授予角色、组或用户。

正确的映射方向是：用户 → 组 → 项目角色 → 权限方案 → 权限。任何“用户 → 项目角色”或“用户 → 权限方案”的直接授予，都是绕过治理链路的捷径，也是权限蔓延的高发点。

组的设计：按“来源”而非“项目”划分

最常见的错误是“一个项目建一个组”，比如 proj-alpha-members、proj-beta-members。这种做法的直接后果是：组数量随项目线性增长，人员调动时需要在多个组之间反复增删，且无法回答“这个人为什么在这个组里”。

更稳健的做法是按身份来源划分组，让组反映组织事实而非项目事实：

• 部门/职能组：dept-rd、dept-qa、dept-ops，由 HR 系统或 IdP（如 Okta、Azure AD）自动同步。
• 雇佣类型组：employee-fulltime、contractor、intern，用于区分权限上限。
• 管理职能组：jira-administrators、confluence-admins，数量极少，成员需审批。

组名建议采用 来源-范围-用途 的命名约定，例如 dept-rd-frontend、contractor-vendor-a。这样在权限方案里看到组名时，能立刻判断其成员范围和风险等级。

项目角色的设计：角色映射组，不映射人

项目角色的成员来源有三种：用户、组、项目角色本身。设计原则是只使用“组”作为角色成员，把“用户”和“角色嵌套”都视为例外，需要审批和记录。

以一个典型研发项目为例，角色与组的映射可以这样规划：

这样设计后，人员变动只需在 IdP 或组层面调整，项目角色自动跟随，无需逐个项目修改。角色数量也应保持克制：一个项目通常 3～5 个角色足够，超过 6 个往往意味着职责边界不清。

权限方案的设计：少而稳定，按项目类型复用

权限方案是权限蔓延的“放大器”——一个方案被多个项目共享，方案里多给一个组，所有共享项目都会受影响。因此权限方案的设计要点是：

1. 按项目类型而非项目实例创建方案。例如“标准研发项目方案”“敏感合规项目方案”“公开社区项目方案”，而不是“Alpha 项目方案”“Beta 项目方案”。
2. 方案内只引用组和角色，不引用具体用户。Jira 权限方案允许直接添加用户，这是最隐蔽的蔓延入口，应在管理规范中明确禁止。
3. 定期做“方案-项目”影响面盘点。修改一个方案前，先查它被多少项目使用；影响面超过阈值（例如 20 个项目）时，应新建方案而非修改原方案。

落地检查：一份可执行的权限方案评审清单

设计完成后，用下面这份清单做一次自检，可以拦截绝大多数权限蔓延隐患：

把这份清单固化为新项目开通时的必过流程，权限蔓延就从“事后救火”变成了“事前拦截”。下一阶段，当组织规模扩大、项目数量增长时，还可以进一步引入基于项目模板的自动化开通，让组、角色、权限方案的映射关系以代码形式固化下来，减少人工配置带来的偏差。