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