1. 课程导入与治理全景

在 Atlassian 平台（Jira、Confluence、Jira Service Management 等）中，权限与空间治理并不是“把用户加进某个组”这么简单。它本质上是一套围绕身份、资源、授权、可见性与生命周期展开的持续管理机制。随着组织从几十人扩展到几千人，项目空间、页面空间、服务台、自动化规则和第三方应用不断叠加，权限问题会从“能不能访问”演变为“谁在什么条件下、通过什么路径、对哪些内容拥有什么级别的操作能力”。如果缺少治理，常见后果包括：敏感信息被越权查看、离职人员仍保留访问、项目配置被误改、审计时无法解释授权来源，以及管理员被大量重复的权限申请淹没。

本课程的目标不是背诵 Atlassian 的菜单路径，而是建立一套可落地、可审计、可复用的治理方法。学完本课程后，你应该能够：

• 区分产品权限（如 Jira 的 Browse Projects、Confluence 的 View 空间权限）与平台级管理权限（如站点管理员、组织管理员、用户访问管理员）的边界；
• 理解用户、组、角色、权限方案、空间权限、页面限制之间的授权链路，并能定位一次访问请求最终由哪一层决定；
• 设计并维护空间/项目模板、权限方案模板、组命名规范，减少逐项手工配置；
• 建立定期复核、离职回收、外部协作方管理、审计日志检查等治理节奏；
• 在出现“看不到”“改不了”“不该看到却看到了”等问题时，按授权链路逐层排查，而不是盲目加权限。

为了把上述概念串起来，先看一张治理全景图。它展示了从“身份来源”到“资源访问”的完整链路，以及治理动作作用的位置。

上图把治理拆成四层：身份来源、组与角色、授权方案、资源空间，最终汇聚为访问结果。治理动作不是某一层的一次性配置，而是贯穿全链路的持续控制。理解这张图，后续每一章都会回到这条链路上定位问题。

为什么权限治理在 Atlassian 中特别容易失控

Atlassian 产品有一个显著特点：权限模型是“产品内自治”的。Jira 项目管理员可以在自己的项目里调整权限方案，Confluence 空间管理员可以修改空间权限，而这些操作往往不需要站点管理员介入。这种设计提升了灵活性，但也带来三个典型挑战：

• 授权来源分散：同一个用户可能通过组织组、站点组、项目角色、空间个人授权、页面限制五条路径获得访问权。排查“为什么他能看”时，必须逐条验证。
• 默认权限过宽：新建 Confluence 空间时，默认可能允许所有登录用户查看；新建 Jira 项目时，默认权限方案可能包含“任何登录用户”可浏览。如果不主动收紧，信息会随时间自然扩散。
• 组与角色混用：很多组织既把组直接加入权限方案，又把组映射到项目角色，导致同一用户在不同项目中权限不一致，审计时难以解释。

一个可落地的治理框架：四层控制 + 三个节奏

结合上述全景图，建议把治理工作组织为“四层控制”和“三个节奏”。四层控制对应链路中的四个位置：

1. 身份层控制：以 SSO/SCIM 为唯一身份源，禁止本地账户泛滥；离职、转岗由 HR 系统触发同步，而不是靠管理员手工删除。
2. 组与角色层控制：建立命名规范，例如 jira-<业务域>-<权限级别>、conf-<空间名>-<角色>；组只表达“人员集合”，角色只表达“在某个资源中的职责”，避免组名与权限级别强绑定后无法复用。
3. 授权方案层控制：为常见场景建立权限方案模板和空间模板。例如“内部公开项目”“受限项目”“外部协作空间”三类模板，新建时直接套用，减少逐项勾选。
4. 资源层控制：对敏感空间启用页面限制或项目级安全级别；对公开空间设置明确的“可查看范围”，避免默认全员可见。

三个节奏则是治理得以持续的时间机制：

• 入职/转岗节奏：新成员按岗位自动加入对应组，转岗时先移除旧组再加入新组，避免权限叠加。
• 季度复核节奏：每季度导出一次“组-权限-资源”对照表，重点检查外部协作方、高权限组、长期未使用账户。
• 事件驱动节奏：发生安全事件、审计要求、组织架构调整时，触发专项排查，而不是等到季度。

学习本课程时建议关注的判断依据

后续章节会反复出现一些判断依据，这里先建立统一口径，避免混淆：

最后需要强调：权限治理的目标不是“把权限收得越紧越好”，而是在业务效率与安全边界之间建立可解释的平衡。过紧会导致频繁申请、绕过流程、影子空间；过松会导致信息扩散和审计失败。本课程后续将围绕身份接入、组与角色设计、权限方案模板、空间生命周期、外部协作、审计与自动化等主题，逐层展开可执行的方法与示例。你现在需要建立的第一个认知是：每一次访问背后都有一条授权链路，治理就是管理这条链路，而不是管理某一个开关。