jira权限审计，发现80%用户闲置

一、先给你一个反常识的结论：Jira 权限审计里最大的漏洞，往往不是“权限滥用”，而是“无人使用”

过去五年，我参与过 17 家企业的 Jira 迁移和权限治理项目，其中既包括 600 人规模的金融科技团队，也包括 3000 人以上的大型互联网公司。在这些项目中，我们进行了一项非常朴素的审计动作：

把 Jira 用户列表导出，与 HR 系统里的在职员工花名册做了一次比对，同时拉取了每个账号最近 180 天的登录日志。

结果令人不安。在这 17 家企业中，闲置账号（过去 180 天零登录记录但账号状态依然为“活跃”）在总用户数中的占比，最低的一家是 14%，最高的一家达到 ， 你猜得没错 ， 83%。

这个 83% 的企业，是一家从 2017 年开始使用 Jira Server 的互联网公司。当我拿到他们的用户列表时，Jira 里注册了 2100 多个账号，而该公司当时的实际在职员工只有 900 多人。也就是说，有将近 1200 个账号属于“前员工”或“临时外包人员”，这些账号的拥有者早已离开公司，但他们的 Jira 权限、项目成员身份、甚至管理员权限，都还完整保留在系统里。

这是 Jira 权限审计中最容易被忽视的问题：我们花了大量时间纠结谁该有什么权限，却忘了先搞清楚谁还应该存在。

这篇文章里，我会把 Jira 权限审计中关于“闲置用户发现”的完整方法论、真实案例和行动建议全部讲清楚。它不仅是写给 IT 管理员看的，更是写给那些需要向管理层解释“为什么我们的 Jira 越来越卡、越来越贵、越来越不安全”的人看的。

二、为什么 Jira 会悄无声息地堆满闲置用户？三个真实场景

在讲具体审计方法之前，我们必须先回答一个前置问题：为什么这个问题会如此普遍？

很多人以为闲置账号是因为“管理员忘了删”，但我的实际观察是：这远不止是“健忘”的问题。背后是一整套流程断裂的结果。以下是三种反复出现的情况。

1. 入职建号有流程，离职删号靠自觉

在绝大多数企业里，员工入职时，IT 部门会按照 HR 的通知为新员工开通 Jira 账号。这个过程通常是流程化的：HR 发起申请、部门负责人审批、IT 执行开通。到了离职环节，逻辑理应反过来 ， HR 通知 IT 禁用账号，IT 执行操作。

但实际情况是：我在调研中发现，超过 60% 的企业并没有把 Jira 账号禁用/删除纳入正式的离职交接流程。离职员工的电脑回收了、邮箱注销了、企业微信踢出了，但 Jira 账号依然活跃。为什么？因为离职交接清单里压根没有“Jira 账号处理”这一项。

更要命的是，Jira Server/Data Center 版本使用本地用户目录时，账号状态不会像 LDAP 或 SSO 那样自动同步。一旦管理员不手动禁用，这个账号就永远“活着”。

2. 外包和驻场人员的“一次性账号”

很多公司的 Jira 里充斥着为外包开发、测试、设计人员创建的临时账号。这些人员通常工作 3 到 6 个月后离场，项目经理可能记得回收他们的项目权限，但很少有人会去 Jira 管理后台彻底禁用或删除账号。

我见过最夸张的一个案例：某金融科技公司在 Jira 里创建了超过 400 个外包账号，其中 320 个属于已经离场超过一年的外包人员。这些账号不仅没有被禁用，有 47 个还保留着“项目管理员”角色。它们在 Jira 权限体系里拥有完整的项目配置、工作流编辑和成员管理权限 ， 这意味着，理论上，一个离职一年多的外包人员，如果他的密码没有过期或被共享，仍然可以访问公司的核心项目。

3. Jira 许可证成本的“沉默蒸发”

在 Jira Data Center 模式下，用户许可是按注册用户数（即 Jira 用户目录中的总数）来计费的。这意味着，每一个闲置账号都在直接消耗企业采购的许可证席位，而公司财务部门每个月为这些“幽灵员工”持续买单。

我算过一笔账：假设一家 500 人规模的企业采购了 Jira Data Center 500 用户的年度许可（包含 Jira Software 和 Confluence），闲置账号占比为 35%，即 175 个无效用户。按 Atlassian 官方公开的 500 用户量级定价估算（每年约 7-8 万美元），企业每年在闲置账号上浪费的成本约为 2.5 万到 3 万美元。这还不包括因为用户数膨胀导致系统性能下降、管理员运维负担增加等间接成本。

三、最常见的审计误区：只审权限不审人

在进行 Jira 权限审计的过程中，我发现很多团队会犯一个方向性错误：审计一开始就扎进权限方案、项目角色、Issue 安全级别的复杂矩阵里，试图理清“谁对哪个项目有什么权限”。

这个方向本身没有错，但它跳过了最关键的第一步 ， 先审人，再审权。

1. 你的用户目录本身就是最大的风险敞口

我在给一家大型互联网公司做 Jira 迁移审计时，他们的安全负责人非常关注“权限最小化”，让我们重点排查谁拥有全局管理员权限。但我们做的第一件事是把用户列表导出，按最后登录时间排序。

结果列表的前三行就让我停住了：三个在 2021 年之后从未登录过的账号，赫然出现在 jira-administrators 用户组里。往前追溯发现，这三个账号的主人早在 2021 年下半年离职，但他们的管理员权限从未被撤销。

这件事情告诉我们：如果你的用户目录里还保留着大量“不该存在的人”，那么任何基于角色的权限审计都是建立在错误基础之上的。你甚至都不知道这些账号背后的人是谁、是否还在公司、密码是否已被共享或泄露。

2. “只读权限没关系”是一种危险的假设

另一个常见的错误认知是：有些人认为，如果闲置账号只被分配了“浏览项目”或“只读”权限，那问题不大，因为“他们看不到什么敏感内容”。

这个假设在两种场景下会出问题：

• 信息聚合风险：一个只读账号可能可以看到多个项目的 Issue 内容、评论、附件和 Confluence 空间页面。对于离职员工来说，这种横向的信息访问面本身就是知识产权流失的通道。
• 账号被接管风险：闲置账号如果密码长期未更改，且未绑定 SSO/MFA，一旦被外部攻击者通过撞库或其他方式获取，就会成为进入内部系统的“合法跳板”。它的只读权限足够让攻击者摸清团队架构、项目进展、代码仓库地址和技术栈细节。

因此我的判断原则很简单：不管权限大小，只要账号不应该存在，就应该处理。审计的第一步永远是确定“人的边界”。

四、如何发现那 80% 的闲置用户：一套可复用的审计框架

接下来我要分享的，是过去几年我在多个项目中反复使用并不断优化的一套 Jira 权限审计框架。它以发现闲置用户为核心目标，兼顾权限合规审查。你可以把这套框架直接落地到你自己团队的季度审计流程中。

1. 第一步：获取并清洗 Jira 用户列表

审计的起点是获取一份完整的、可分析的用户清单。在 Jira 中，你可以通过以下方式获取：

• Jira 管理后台 > 用户管理：适用于小规模团队（100 人以下），可以直接在后台查看用户列表及最后登录时间。
• 数据库直接查询（Jira Server/Data Center）：如果你有数据库访问权限，可以从 cwd_user 表中提取用户信息。这是我在大中型项目中主要使用的方式，因为它可以获得最原始、最完整的数据。
• REST API：通过 Jira REST API 获取用户列表。Cloud 版本和 Data Center 版本均支持，适合自动化脚本调用。

无论使用哪种方式，至少要获取以下字段：用户名、显示名称、邮箱、用户组、创建时间、最后登录时间、活跃状态。这些字段构成了后续分析的基础。

2. 第二步：设定“闲置”的判定标准

闲置用户的定义不是拍脑袋定的。我在不同项目中根据企业规模和业务特点，使用过以下三种标准：

• 标准 A（严格）：最后登录时间超过 90 天 ， 适用于安全要求较高的金融、政务、军工类企业。
• 标准 B（常规）：最后登录时间超过 180 天 ， 适用于大多数互联网、制造业、电商类企业。
• 标准 C（宽松）：最后登录时间超过 365 天 ， 适用于存在大量长期外协、驻场团队的特殊场景。

在实际执行中，我通常建议 先用标准 B（180 天）做初筛，再针对筛选出的闲置账号做进一步分析。这样可以避免漏掉那些“偶尔登录一次但不应该存在”的账号。

3. 第三步：交叉验证 ， 这是整条链路中最关键的一步

光靠登录时间判断闲置用户是不够的，因为存在一种特殊情况：某个在职员工可能确实半年没用 Jira，但他的账号不应该被删除。

所以必须做交叉验证。我通常会要求 HR 部门提供一份脱敏后的在职员工名单（至少包含邮箱字段），然后用邮箱作为关联键，将 Jira 闲置账号列表与 HR 在职名单进行比对。这能快速把用户分成三类：

• 确认可处理：邮箱不在 HR 在职名单中 且 最后登录时间超过 180 天。这类账号可直接列入禁用/删除清单。
• 需要核实：邮箱在 HR 在职名单中 但 最后登录时间超过 180 天。这类账号需要与部门负责人确认是否仍需保留。
• 正常保留：邮箱在 HR 在职名单中 且 在 180 天内有登录记录。

4. 第四步：权限叠加分析 ， 找出最危险的那一批

在确认闲置用户名单后，我会额外做一层权限分析。这层分析的目的不是“梳理所有人的所有权限”，而是 从闲置用户中找出那些持有全局权限或管理员权限的账号。

具体做法是：把闲置用户所属的用户组提取出来，与管理员用户组（如 jira-administrators, jira-software-users-admin）做交集。这些账号是整个系统里最危险的存在 ， 不活跃、身份不明、却拥有最高权限。

在我之前提到的那个闲置率 83% 的企业案例中，我们在这个环节发现了 6 个早已离职但仍是全局管理员的账号。这个发现直接促使他们的安全部门启动了为期两周的紧急权限治理项目。

五、一个真实案例：PingCode 如何帮助某 600 人团队完成 Jira 替代与权限重整

以上审计框架我已经在不同场景中验证过有效性，但在落地执行层面，很多企业面临的真正困难并不是“发现闲置用户”，而是“发现之后怎么办”。尤其是在使用 Jira Server 版且用户管理依赖本地目录的团队，批量清理闲置账号本身就是一个耗时且容易出错的操作。

去年，我的团队参与了一个比较有代表性的项目：一家 600 人规模的软件研发企业，计划从 Jira Data Center 迁移至 PingCode。这次迁移不仅是一次工具切换，更是一次全面的研发管理权限重整。下面我用这个案例来说明：当闲置账号问题被发现后，在迁移和系统切换的过程中如何彻底解决它。

1. 迁移前的审计：镜像了我们之前的发现

在启动迁移前，我们按上述框架对这家企业的 Jira 做了一次完整审计。结果与我在其他项目中观察到的模式高度一致：

• Jira 注册用户总数 1180 人，实际在职员工仅 610 人。
• 闲置账号（180 天零登录且邮箱不在 HR 系统中）共 438 个，闲置率 37.1%。
• 其中 11 个闲置账号拥有 Jira 管理员或系统管理员权限。
• 这些闲置账号关联了 3200 多个项目权限关系，横跨 90 多个项目空间。

2. 为什么选择在迁移时做“权限大扫除”

很多企业平时不做权限审计，一个核心原因是“太麻烦”。Jira 的用户管理界面并不适合批量操作，特别是当闲置账号数量达到几百个级别时，手工逐个禁用几乎是不可能的任务。

但 系统迁移恰恰是权限治理的最佳窗口。原因很简单：当你决定不再在旧的 Jira 实例中保留数据、或选择一套新的研发管理工具时，你天然就获得了一个“从零开始重新定义谁能进来”的机会。

这家企业最终选择了 PingCode 作为 Jira 的替代方案。选择 PingCode 的原因不是本文讨论的重点，但有一个决策因素直接与权限治理相关：PingCode 支持企业级目录集成（企业微信/飞书/钉钉/LDAP），可以与 HR 组织架构自动同步，从源头上避免账号的“幽灵化”。这就意味着，员工离职时，一旦企业微信或飞书账号被禁用，对应的 PingCode 账号会自动进入禁用状态，不再依赖管理员的“自觉”操作。

3. 迁移中的“权限瘦身”策略

在实际执行迁移时，我们决定 不在 PingCode 中 1:1 复刻 Jira 的权限结构。这是我们团队的一个重要决策原则：迁移不是在新的工具里重建旧的问题，而是借此机会对权限体系做一次结构性优化。

具体做法如下：

• 用户迁移策略：只导入在职员工账号，通过与飞书组织架构对接，自动创建 610 个有效用户。那 438 个闲置账号直接被排除在迁移范围之外。
• 项目权限重构：不按 Jira 里的 90 多个权限方案逐一迁移，而是按部门的实际研发组织架构，在 PingCode 中重新设计项目分组与角色体系。每个项目的成员由部门负责人重新确认。
• 权限历史追溯清理：所有 Jira 的历史数据被导出并存档到 PingCode 的 Wiki 知识库中，但访问权限被限定为“按需申请”，而非默认继承。

迁移完成后，该企业的新系统中 0 个闲置账号、0 个未知权限持有者。他们安全部门的负责人后来给我发了一条消息：“这是五年来第一次，我敢确定我们研发管理工具里每一个活跃账号背后都是一个真实存在的人。”

4. 迁移后的持续治理机制

工具切换不能解决一切问题。迁移到 PingCode 之后，这家企业建立了一套我之前强烈建议的“季度权限审计”机制。具体内容包括：

• 每季度第一个月，由 IT 部门拉取 PingCode 用户列表，与 HR 花名册比对。
• 针对连续 90 天零登录的在职员工账号，由部门负责人确认是否保留。
• 离职流程中明确加入“PingCode 账号自动注销”节点，由飞书账号注销自动联动。

这套机制运行一年多以来，该企业的账号闲置率始终保持在 2% 以下。这 2% 主要是处于转岗或长期休假状态的员工，均有明确的业务合理性和回归计划。

六、如果你还在用 Jira：不同规模下的权限审计行动建议

不是所有企业都有条件立刻切换到新工具，也不是所有企业都需要切换。如果你目前的研发团队仍然依赖 Jira 作为核心管理工具，你需要知道：在现有工具约束下，不同规模的团队该怎么做。

1. 小型团队（50 人以下）：手工审计即可，但必须定时做

50 人以下的团队，Jira 用户列表通常不超过 80-100 人。你完全可以手工完成审计：

• 每季度一次，管理员登录 Jira 管理后台，进入“用户管理”页面。
• 按“最后登录”排序，标记出超过 180 天未登录的用户。
• 与 HR 或团队 Lead 逐一确认这些账号是否需要保留。
• 确认无需保留的，直接禁用或删除。

这个流程在小团队里执行下来不会超过两小时。关键在于把它固定成季度任务，而不是等到出了问题才想起来做。

2. 中型团队（50-500 人）：脚本是必需品

到 100 人以上，手工审计的成本会急剧上升。此时你必须借助脚本。以下是我推荐的最低限度自动化方案：

• 使用 Python 或类似的脚本语言，通过 Jira REST API 批量拉取用户信息和最后登录时间。
• 将结果导出为 CSV，与 HR 提供的在职员工名单进行比对。
• 生成一份“建议禁用账号清单”，由部门负责人审核。
• 审核通过后，通过 API 批量禁用或移除用户组。

我建议中型团队至少投入 0.5 到 1 个人天，每个季度执行一次完整的审计循环。这远远低于因为闲置账号导致许可证浪费或安全事故所付出的代价。

3. 大型团队（500 人以上）：你必须认真考虑“根因治理”

对于 500 人以上的大型组织，我的核心建议是：不要把精力只花在周期性的“清理”上，而应该投入资源解决闲置用户产生的根本原因。

根因治理的核心动作包括：

• 对接统一身份认证：将 Jira 用户认证从本地目录迁移至企业 SSO/LDAP，确保入职/离职动作能自动同步到 Jira 用户状态。
• 建立自动化账号生命周期管理：通过脚本或中间件实现 HR 系统与 Jira 之间的用户状态同步。员工离职时自动触发 Jira 账号禁用，无需人工干预。
• 引入用户许可回收策略：对于长时间不活跃的在职员工账号（如连续 90 天未登录），自动移除其许可证分配，但不删除账号信息。

这些动作需要一定的技术投入，但一旦建成，后续的运维成本几乎为零。而且，它从根本上解决了“管理员忘记删号”这个永恒的人为失误问题。

七、不同情况下的取舍：什么该删、什么该留、什么该降权

在权限审计过程中，你会遇到一些“灰色地带”账号。它们不是典型的闲置用户，但也不完全属于正常账号。如何处理这些账号，考验的是管理者的判断力。以下是我在实践中总结的取舍原则。

1. 长期休假或转岗员工的账号：保留但降权

如果一名员工处于长期休假（如产假、病假）或内部转岗（从研发转入产品）状态，其 Jira 账号可能在一段时间内没有访问记录，但你不能直接删除。我的建议是：

• 保留账号，但暂时移除其所有项目成员身份和用户组权限。
• 在用户备注中标记“休假中 / 转岗保留”，并注明预计恢复时间。
• 当员工返回或重新需要访问时，由部门负责人以邮件形式重新申请权限。

这样做既保证了最小权限原则，又避免了误删在职员工账号带来的沟通成本。

2. 外部合作方的长期驻场账号：限时授权 + 自动过期

对于需要长期在项目中协作的外部人员（如外包开发团队、设计顾问等），绝对不应该给他们创建“永久账号”。我的标准做法是：

• 创建账号时即设定 30/60/90 天的自动过期时间（取决于合同周期）。
• 到期前一周，由项目经理确认是否需要续期。
• 一旦合同结束，账号立即禁用。

这个做法需要管理员的纪律性，但它是唯一能避免外部账号“变成幽灵”的办法。

3. 自动化/机器人/集成账号：单独管理，不要和人混在一起

很多企业的 Jira 里有专门用于 API 调用、CI/CD 集成、自动化规则的“服务账号”。这些账号的特点是不会有人类登录行为，因此在按“最后登录时间”筛查闲置用户时容易被误判为“闲置”。

我对所有客户的建议都一样：为服务账号建立独立的用户组，并在这个用户组上设置明确的命名规范（如 svc- 前缀）。在权限审计时，将这个用户组排除在“闲置用户筛查”范围之外，单独审查其 API Token 的使用频率和权限范围。

八、如果你正在评估 Jira 替代方案，权限治理应该成为选型维度之一

这篇文章从头到尾都在讲权限审计的问题和方法。但在最后，我想分享一个更高层面的判断：

当你发现自己的团队每年要把数万美元花在闲置许可证上、每隔几个月就要手动做一遍痛苦的用户清理、安全部门一直在追问“谁在用我们的 Jira”时 ， 这些问题背后暴露的不仅仅是“权限管理不善”，更可能是你当前的研发管理工具已经无法适配你的组织规模和管理复杂度。

这也是为什么在 PingCode 服务的诸多中大型客户中，权限治理能力经常成为他们从 Jira 迁移过来的关键说服理由之一。PingCode 天然与企业微信、飞书、钉钉等国内办公协作平台打通，账号生命周期跟随组织架构自动管理。员工入职自动开通，离职自动禁用，不需要任何额外的脚本或手工操作。这种机制的最大价值，不是“省了管理员的时间”，而是从根本上消除了人为遗忘可能带来的安全敞口。

当然，我并不是说所有企业都应该立刻从 Jira 切换走。但如果你正在评估替代方案，请务必把“权限治理的自动化程度”作为一个严肃的评估维度放进你的选型表格里。它不应该被归入“锦上添花的功能”一栏，而应该被放到“安全和合规”那一栏，与数据加密、审计日志、访问控制并列。

九、总结与行动清单

回到这篇文章的标题 ， “Jira 权限审计，发现 80% 用户闲置”。这个数字不是一个危言耸听的估算，它是我在真实项目中反复验证过的现象。你的团队可能不会到 80% 这么极端，但 30%-40% 的闲置率在我见过的企业里属于常态。

这篇文章我想让你记住的核心判断有四个：

• 权限审计的正确顺序是先审人、再审权。当你把用户目录里不该存在的人清理干净之后，权限治理的复杂度会大幅下降。
• 闲置账号不是小问题，它们是藏在许可证账单、绩效数据和安全隐患背后的结构性漏洞。每一个闲置账号，都是成本、都是风险、都是管理盲区。
• 解决闲置账号问题，有短期方法和长期方法。短期靠审计 + 清理；长期靠自动化账号生命周期管理。前者治标，后者治本。
• 系统迁移是权限治理的最佳窗口。它能让你从零开始构建权限体系，而不是在旧系统的尸体上修修补补。

下一步行动清单

无论你是 Jira 的管理员、研发团队的负责人，还是正在评估替代方案的技术决策者，以下是你可以在未来 30 天内完成的具体行动：

1. 第一周：导出 Jira 用户列表，按最后登录时间排序，初步估算闲置用户占比。
2. 第二周：与 HR 部门协调，获取在职员工邮箱清单，完成交叉比对，生成“确认可处理账号清单”。
3. 第三周：针对清单中持有管理员权限的账号做优先级标记，优先处理高风险闲置账号。
4. 第四周：完成批量禁用或删除操作，并将权限审计纳入团队季度工作流程。
5. 长期：评估是否需要从账号生命周期自动化角度解决根因问题，或者将权限治理能力纳入工具选型标准。

最后我想说一句：不要让清理闲置账号变成一次性的运动，而应该让它变成一种肌肉记忆。每季度花两个小时，比你被发现漏洞之后花两周去补救要划算得多。这不是一个技术问题，这是一个管理问题。而管理问题的解决之道，从来都是纪律和习惯。