用户账号开通流程图（入职、调岗、离职）
用户账号开通流程图：人力资源事件触发，在目录中创建身份，发放凭证并注册 MFA，推导岗位权限包，特权权限由责任人审批，创建下游账号，核验与定期复审。
什么是用户账号开通流程图（入职、调岗、离职）流程
用户账号开通是悄悄失效的，所以它通常是在一次审计之后才被修好，而不是之前。入职那一半是看得见的：新员工第一天没有邮箱，他会抱怨，总有人去处理。其余的都看不见。权限是照着上一个坐这个位子的人复制过来的，于是一个本就授权过度的账号成了整个部门的基线。外包人员来的时候没有人力资源记录、没有到期日，当初引进他的人也早已离职。半数系统在单点登录后面，是自动开通的；另外半数——那套财务软件、某个团队自己刷卡买的工具、供应商门户——是一条没人统计的人工队列。而一次内部调岗只做加法、从不做减法，因为没有任何地方会报出那些仅仅是变得不再必要的权限。这些都不会立刻酿成事故。它们积累成的，是几年之后才浮出水面的一条权限审计发现、一次没通过的控制测试，或者一个早已离职的人的账号仍然能够登录成功。
本图画的是身份与账号的机制，不是申请单，也不是审批链。一位已经在岗的员工再要一项权限，连同围绕它的审批与定期复审，属于 /zh/templates/访问申请流程 上的访问申请流程；同样一件事若由人力资源的入职或调岗事件触发、并由岗位画像界定范围，则在 /zh/templates/员工访问申请流程 上。对某一份数据集的访问——由数据责任人依据分级与使用目的来判断，而不是依据岗位——在 /zh/templates/数据访问申请流程 上。本图里的离职路径是有意画短的，画到交接就停：完整的权限回收流程，包括共享账号与服务账号、停用与删除之别，以及证据留存，在 /zh/templates/用户访问权限回收流程 上。合同、背景调查、设备与第一天的安排，属于 /zh/templates/员工入职流程。剩下的，就是从事件到一组可用、已核验、已留档的账号之间的全部内容——身份、凭证、权限包、下游系统——再加上以上那些页面都不覆盖的一类人群：完全没有人力资源记录就来了的非员工。以控制项来说，这里对应的是 ISO/IEC 27001:2022 附录 A 中身份的那一半——A.5.16 身份管理，管的是一个身份的整个生命周期；A.5.17 鉴别信息，管的是针对它签发的凭证——而不是 A.5.15 与 A.5.18，那两条管的是这个身份随后被允许触及什么。
多数账号开通程序留作默认的三个判断，在这里被明确画了出来。“是员工还是非员工？”排在身份被创建之前，因为一名外包人员需要一位具名的担保人和一个到期日，而人力资源的数据流永远不会提供这两样；缺了它们创建出来的身份，正是两年后权限审计翻出来的那个孤儿账号。“是否在标准权限包内？”把流程一分为二：岗位权限包之内的一切都自动开通，路径上不站任何人，只有特权权限或包外的额外权限才会送到权限责任人那里——正是这一点，才让审批不至于退化成盖在邮箱上的一枚橡皮图章。而“已开通权限与申请是否一致？”是一道关卡，而不是收尾时的形式：它把目标系统实际授予的权限回读出来，与当初申请的内容相比对；那些没有经过审批却落了地的权限，从来不会有拿到它的人主动来报。调岗分支加上了第四个判断，“是否存在新权限包之外的旧权限？”，定期复审加上第五个，“权限是否仍与岗位相符？”——两者都汇入同一个回收步骤，于是无论移除的需要是怎么发现的，一项权限的出口都只有一个。
本流程图涵盖的内容
本模板包含
- 六个阶段——触发、身份、权限、开通、核验、变更与复核——铺在五条泳道上：人力资源或担保人、身份管理团队、直属经理、权限责任人、信息安全。
- 一个入口，五种事件。“属于哪类身份事件？”把入职、调岗、离职、应急提权申请和定期复审这五条路都送进同一张图，于是这套机制是共用的，而不是每一种情况各自重造一遍。
- 完整的身份阶段：“是员工还是非员工？”把外包人员、劳务派遣人员和服务伙伴引向“登记担保人与到期日”——这是唯一一个给他们一位可问责的责任人和一个终止日期的步骤——之后两条路在“在目录中创建身份”与“发放凭证并注册 MFA”处汇合。
- “是否在标准权限包内？”——标准那一支直通“自动开通标准权限包”，路径上没有审批人；特权权限与包外的额外权限则走向“权限责任人是否批准？”，其拒绝分支终止于“权限申请被拒并关闭”。
- 按图中实际运行的先后顺序开通：先“自动开通标准权限包”，然后“在下游系统中创建账号”，自动化的与人工的系统一视同仁，再到“已开通权限与申请是否一致？”，其不一致分支会经过“纠正多授或少授”再回来重查，而不是直接关掉工单。
- 变更那一半：调岗会被问“是否存在新权限包之外的旧权限？”，查到的一律送往“回收已被取代的权限”，再回到“是否在标准权限包内？”；离职则走到“转交权限回收流程”；而“权限是否仍与岗位相符？”会把已偏离的答案送往同一个回收步骤。
何时使用本模板
- 你们要写 IT 运维手册里的身份与访问章节，需要用一张图说清楚从一个人力资源事件到一组可用账号之间发生了什么。
- 你们准备采购或配置一套身份治理工具，希望在供应商的默认流程替你们定下之前，先把分支定下来——什么自动开通、什么必须有责任人审批、什么仍然是一条人工队列。
- 权限审计一次次翻出员工几年前那份工作留下的权限，你们需要把调岗时的回收步骤画出来，并给它配上责任人和期限。
- 你们的系统里到处是非员工——外包人员、劳务派遣人员、审计师、合作伙伴、服务账号——而他们都不来自流程其余部分所依赖的那条人力资源数据流。
- 审计师、客户的安全问卷或 ISO 27001 的审核员问到：身份是怎么创建的、权限是怎么授予的，以及你们凭什么知道现存的权限就是当初批准的权限。
运作方式
把泳道改成你们自己的角色
把人力资源或担保人、身份管理团队、直属经理、权限责任人和信息安全换成你们真实存在的角色。人力资源与担保人是有意放在同一条泳道里的：它们是同一份工作，只是面向不同人群，把它们拆开正是非员工最后无人负责的原因。权限责任人这条泳道，是多数组织发现自己填不满的一条。如果你们今天叫不出特权权限的责任人是谁，那是一条审计发现，而不是一个画图问题——这条泳道应当留在图里，明晃晃地空着，直到它被补上。
写明你们的权威数据源，以及它不包含谁
本图假定存在一条权威的入职、调岗、离职数据流。写下它是哪个系统、它带哪些字段——岗位、经理、入职日期、变更生效日期、最后工作日——以及一次变更多久才会出现在里面。然后写下谁不在里面。外包人员、董事、劳务派遣人员、实习生和机器身份通常都不在，而他们每一类都需要自己的一本台账和一位担保人，流程其余部分才跑得起来。
在发布之前先把权限包写出来
“推导岗位权限包”在权限包真正存在之前是空转的。先从你们招聘最频繁的十个岗位入手，写下每一个岗位第一天真正需要什么。如果手上有登录或最近使用的数据，就按现任者实际用到的来搭，而不是按他们手上持有的来搭；两者之间的差距通常很大，而这正是权限包值得写的全部理由。把每一个权限包当作下限而不是上限，这样任何在它之外的东西都还足够显眼，值得专门去申请一次。
定下需要责任人审批的门槛
只有当判定标准就摆在它旁边时，“是否在标准权限包内？”才起作用。走审批分支的典型触发条件是：管理员与 root 权限、生产环境访问、支付或薪酬系统、个人信息与健康数据，以及任何能改变他人权限的东西。发布之前，拿这份清单去对照上个季度实际授予的权限检验一次：一条能命中其中大多数的标准，不是标准。如果什么都路由给权限责任人，审批到达的速度会超过任何人读得完的速度，这道控制就变成了一条大家学会一路点过去的队列。
把调岗时的回收变成可追踪的义务
“回收已被取代的权限”这一步，决定了权限会不会在你们组织里越积越多。给它和授予同样的工单、同样的责任人、同样的期限，并且只有当两半都做完时，这次调岗事件才算关闭——一张在授予那一半就关掉的工单，正是回收永远不会发生的机制本身。本图有意把这次比对放在直属经理而不是身份管理团队那里：团队能列出差异清单，但只有经理知道某一项权限是真的已被取代，还是交接期间仍然需要。
找真正在跑这个流程的人走一遍，然后发布一个版本
在发布之前，先把默认没人认领的两条分支定下来。决定谁可以在非工作时间发起应急提权、事后由谁来查会话日志；也决定在定期复审时，谁来处理“已偏离”这个答案、在什么期限之前处理完——一次只产出清单、却没有人据此回收的复核，比不做复核更糟。然后带着这张图去找一位服务台工程师、一位近期招过人的直属经理，以及上一次做权限审计的那个人，按他们实际的做法改正它。发布改好的版本，保留此前的版本可读，并在你们的访问控制制度里引用它。
常见问题
用户账号开通流程包含哪些步骤？
从权威数据源取得一条入职、调岗或离职事件；判断这个人是员工还是非员工，并给非员工配上担保人和到期日；在目录中创建或匹配一个身份，其标识符永不复用；针对该身份发放凭证并注册多因素认证（MFA）；按岗位推导权限包；权限包之内的一切自动开通，特权权限或包外的额外权限则送交权限责任人审批；在下游系统中创建账号，自动化的和人工队列里的都要建；核验系统实际授予的权限与当初申请的是否一致；由直属经理确认；再把权限记录到该身份名下。此后流程仍在继续：调岗会重新推导权限包，并回收旧岗位不再能支撑的部分；离职则停用并转交回收流程；定期复审则周期性地检查权限与岗位是否仍然一致。
什么是岗位基线权限包？
它是一份工作在第一天就需要的那组权限，挂在岗位上而不是挂在人身上：邮箱与日历、内网、该职能的核心业务系统、该团队的共享盘。正因为它是由岗位推导出来的，才可以在路径上没有审批人的情况下授予——这正是它的意义所在：把日常性的授予从审批队列里拿走，剩下的例外才会被认真读。有两条规则能让权限包保持诚实。一是按这份工作真正需要什么来搭，绝不靠导出上一任持有者的权限来搭，那样会把他积累的每一样额外权限连同必需品一起复制过来。二是给每个权限包一位具名责任人和一个复审日期，因为没有责任人的权限包只会不断变大：每一个不好拒绝的申请都被加进去，两年之内它授予的东西，就远远超过任何一份工作真正所需。
用户账号开通流程与访问申请流程有什么不同？
两者在中间相遇，各管一半。/zh/templates/访问申请流程 上的访问申请流程，起点是一位已经在岗、又需要多用一个系统的人：他提出申请，直属经理与系统负责人批准，然后开通，之后进入定期复审。/zh/templates/员工访问申请流程 上的员工访问申请流程，覆盖的是同一件申请由人力资源的入职或调岗事件触发、并由岗位画像界定范围的情形。这两者讲的都是怎么决定。本页讲的是怎么做到：创建身份、发放凭证并注册多因素认证、推导权限包、在每一个下游系统里创建账号，以及把权限从目标系统里回读出来，核对它们是否就是被批准的那些。如果你们要设计的是申请单或审批链，请用那两份。如果你们要建设或记录它们背后的开通机制，包括外包人员的身份和内部调岗的回收那一半，请用这一份。如果问题是对某一份数据集而不是某个系统的访问，见 /zh/templates/数据访问申请流程。
用户账号开通到底能自动化到什么程度？
比多数组织已经做到的更多，但永远不会是全部。单点登录背后的系统可以做到无需工单：目录里的身份由人力资源记录生成，岗位的权限包随之应用，用户组随之归位。真正让全覆盖落空的，是那些当初没被规划进来的系统——没有 API 的薪酬系统、自己维护一份本地用户名单的实验室仪器、靠回一封邮件就能开户的合作伙伴外网。它们需要一条有具名责任人和时限的队列，而且必须被列进清单，因为一个不在清单上的人工系统，入职时会开通得很晚，离职时会被彻底遗漏。维护一份哪些系统已对接、哪些还没对接的登记表，每次有新采购就更新一次，并把缩短人工清单当作真正要做的那项工作。只把授予自动化、却不把回读自动化，本身就是一个陷阱：连接器会无声失败，这也正是核验步骤要从目标系统读权限、而不是从工单读权限的原因。
外包人员和其他非员工的账号该怎么开通？
和员工的办法一样，只不过上游没有任何东西会告诉你他们存在。外包人员、劳务派遣人员、审计师、合作伙伴的工程师、实习生和机器身份很少出现在人力资源系统里，所以让一个身份可管理的那两个属性，必须刻意采集：一位对它负责的、具名的内部担保人，以及一个取自合同或项目约定、而不是就这么敞着的到期日。让到期自动生效——账号到日子自己停用，续期是担保人的一次明确动作，并附上新的结束日期。担保人离职时要重新指派担保关系，因为担保人已经走掉的身份，恰恰就是没有人复核的那个账号。非员工通常也应当配更紧的权限包，以及比在编员工更短的复审周期，因为他们的工作面更窄、流动也更快。权限审计翻出来的孤儿账号，多数属于这个组织从来没有雇用过的人。
此流程所处的位置
在大多数组织中，此流程紧随医疗服务人员资质审核流程图之后，并交接给用户访问权限回收流程图（权限注销）。
它是访问权限治理中的一个步骤。
第 1 步: 用户账号开通流程图（入职、调岗、离职） 当前位置
用户账号开通流程图：人力资源事件触发，在目录中创建身份，发放凭证并注册 MFA，推导岗位权限包，特权权限由责任人审批，创建下游账号，核验与定期复审。
第 2 步: 访问申请与权限开通流程图
访问申请流程图：基于角色的申请、直属主管与系统负责人审批、职责分离检查、按最小权限开通，以及定期重新认证。
第 3 步: 员工访问申请流程图（入职与调岗）
第 4 步: 用户访问权限回收流程图（权限注销）