做企业用户管理这几年我周围最常见的一个需求不是“怎么建账号”而是“怎么在不给同事超级管理员权限的前提下把创建账号、批量分配角色这些日常操作安全地交出去”。很多人习惯开一个超管账号轮流用用了半年才发现登录记录乱、责任说不清最后又重新梳理权限。这件事的成熟解法在 Google Cloud 等企业身份体系中就是 Maintain Business Users 这一类角色。这篇指南会把这套流程完整拆开从角色的权限边界开始讲清控制台和 API 两种创建账号的方式再到我用过的三种批量角色分配套路最后把我踩过的“账号被标记”“手机号验证失败”“角色不生效”这些问题一起复盘给你一份可以直接抄作业的实战手册。1. Maintain Business Users 是什么先搞清楚它在解决什么问题1.1 角色定位与权限边界Maintain Business Users 是企业身份目录里一个预定义的委派管理角色和管理控制台的 IAM 角色列表能直接搜到的那类预置角色是一套逻辑。它和超级管理员最核心的区别是权限边界它管的是“人和角色”这个层面不碰平台本身的计费、安全配置、全局策略和数据导出。以 Google Cloud/Workspace 的身份目录为例这类角色通常包含以下能力创建、编辑、启用/停用企业用户账号查看组织单元结构和用户清单为用户分配应用许可和访问角色重置密码、维护账号的辅助验证信息而它默认不会包含的权限包括修改域名和 DNS 记录、管理结算和发票、修改全局安全策略、配置 SSO、导出平台后台日志等。这个边界不是我随便画的它是“最小权限原则”在账号管理场景里的具体落地日常维护需要的能力全部给到但一旦涉及平台级敏感操作必须走更高权限的角色。另外要特别说明Maintain Business Users 面向的是业务用户也就是真人账号和用来跑自动化任务的机器身份是两套体系别混着用。1.2 为什么需要它而不是直接用超级管理员我见过太多团队犯同一个错误怕麻烦直接给运维、客服、行政都开了超管。表面看省事实际上三个问题立刻暴露。第一责任无法追溯。出账异常了某个项目目录被清空了最后审计一看好几个人都有权限谁也说不清是谁动的。第二安全风险被放大。超管能做的事太多一个账号被钓鱼或者被离职员工带走影响面是全局性的。第三变更不可控。没有权限分离就没有“申请-审批-执行”的流程可言系统里想改什么就改什么。用委派角色比如 Maintain Business Users核心价值是用权限边界把“日常用户维护”和“平台级敏感操作”彻底切开。一线支持人员拿着这个角色可以干活出了事能精准定位到人而且真需要超管操作时再走临时提权流程流程清晰审计也好看。1.3 适用场景从实战来看这几类场景最值得引入这套角色中大型企业的 IT Helpdesk让他们自己处理入职、转岗的账号申请不用每次排队等超管。外包或供应商运维团队需要维护一批客户侧账号但绝不能让他们碰到平台核心配置。自动化脚本和集成服务用一个受控角色去跑账号同步、角色分配而不是把超管的密钥丢给脚本长期挂在背后。跨部门管理员比如市场部需要给自己的协作账号分配权限但平台的全局配置归平台团队管职责边界靠角色本身锁死。2. 动手前的准备权限、环境与账号规范2.1 前置条件清单在创建第一个账号之前先把下面几项确认好省得后面返工。企业身份目录必须已经开通。这是基础不管是 Workspace 还是 Cloud Identity用户账号都存放在统一的目录里而不是散落在各个应用各自的用户表里。目录没有就绪后面所有流程都没有落点。还要明确由谁授予 Maintain Business Users 角色。初始阶段往往需要一个超管完成第一次委派把角色分配给一线管理员之后他们就可以自己维护用户。这个过程在 IAM 角色管理页面操作搜索角色名后直接绑定到成员即可。如果打算用脚本或 API要确保 Admin SDK / Directory API 在后台已启用并且为服务账号配置了正确的授权范围。这个配置漏掉的话脚本运行后只会看到一个接一个的权限错误而且这些错误长得相差无几很难定位。最后提前想好角色分配的目标层级。角色是分配在项目级、组织单元级还是群组级这一步决定了后面批量下发的路径也是最容易被忽略的部分。很多人一开始就埋头建账号完全没想过角色挂在哪里等批量分配时才发现自己把路径选死了。2.2 命名规范与账号生命周期设计创建账号成本低但当账号多了之后命名混乱带来的维护成本才是大头。我建议在开始前就把规范写进团队的 SOP而不是等出了问题再靠人肉补救。邮箱前缀方面尽量使用“名.姓”或者“姓名缩写工号”这类稳定规则。有两点特别注意不要在邮箱里带职位信息比如 zhangjingli_HR因为职位会变邮箱一改所有关联的系统都要跟着改也不要把“临时”“兼职”这类状态词放进邮箱前缀这类状态应该靠目录字段来标识而不是靠改名字。账号生命周期至少要定义四个节点入职创建、转岗调整、离职禁用、到期清理。我强烈建议在目录里给每个账号打上外部 ID把 HR 系统的员工号映射进来。之后 HR 系统和目录之间的同步就靠这个 ID 对账比按姓名匹配靠谱得多。姓名有重名员工号是唯一的数据说话才硬气。2.3 验证方式的取舍企业目录 vs 消费级账号这里我必须说一个很多人没意识到的点企业用户管理根本不依赖个人手机号验证。那些“创建谷歌账号手机号无法验证”“账号被提示多账号创建或使用”的报错几乎都发生在消费级个人账号的批量注册场景里。而你用的是企业身份目录管理员创建用户时走的是目录 API 或管理控制台每个用户不需要单独接收短信验证码更不涉及消费级账号的“多账号一起创建或使用”风控策略。我经常遇到小团队负责人问能不能用个人账号批量注册省得开通企业服务的钱每次我都要拦下来。用表格对比一下这两条路差异非常清楚对比项消费级个人账号批量注册企业目录账号Maintain Business Users 维护创建方式网页逐个注册控制台/API/CSV 批量创建验证要求一般需要手机号验证管理员创建无需逐个短信验证批量支持有限且容易被风控原生支持大规模批量操作角色与许可管理个人设置为主统一的角色与许可体系使用风险容易触发“多账号”风控提示合规可控、可审计所以如果你发现自己正在用个人账号大量注册然后遇到验证失败或者“多账号”提示第一反应不应该是想方设法绕过验证而是确认自己是不是走错了路径。企业用户就该用企业目录的账号体系这也是 Maintain Business Users 这类角色存在的根本原因。3. 创建企业用户账号控制台到 API 的完整流程3.1 控制台创建单个账号控制台适合量小、偶尔手工操作的场景。大致步骤如下以企业身份目录的管理控制台为例登录管理控制台进入“目录 用户”页面。点击“添加用户”填写姓氏、名字和服务邮箱地址。邮箱前缀会直接生成主邮箱写错后缀会连带影响登录和收信。设置初始密码。建议选择“系统生成密码”并勾选“首次登录时修改密码”避免管理员长期持有用户的明文密码。选择组织单元。这一步看起来不起眼但它决定了用户默认继承哪些策略漏选的话用户会落到根部门权限策略可能完全不对。按需勾选成员资格或分配许可最后提交。提交后账号一般几秒内生效但某些应用比如邮件、日历的首轮同步可能需要几分钟这是正常现象。别急着频繁重建账号那样反而会制造一堆重复目录项。3.2 用 API 批量创建账号量一旦上来了比如入职潮一次来几百人控制台就撑不住了。这时候我强烈建议直接用 Directory API把创建过程脚本化。大致流程是准备好一个服务账号授予它调用目录接口的权限范围然后调创建用户接口。核心请求体大概长这样POST https://admin.googleapis.com/admin/directory/v1/users Authorization: Bearer 访问令牌 Content-Type: application/json { primaryEmail: zhang.weiliexample.com, name: { givenName: 伟力, familyName: 张 }, password: Tmp2025#Secure, changePasswordAtNextLogin: true, orgUnitPath: /Marketing, externalIds: [ { value: E10086, type: employeeId } ], suspended: false }实际写脚本时我会先把用户数据放在一个 CSV 里然后循环读取逐条调用接口创建。几个关键参数说明如下primaryEmail 是唯一标识创建后不能改所以一定要在数据准备阶段清洗一遍去重、校验域名、检查字符是否合法。password 建议由脚本随机生成强度至少 16 位并强制首次登录改密。代码里不要把固定密码硬编码万一泄露全部账号一起遭殃。orgUnitPath 必须显式传。这是我反复踩坑后总结出来的漏掉它用户全部落到根部门后面策略继承全乱排查成本极高。externalIds 里放员工号好处前面说了将来和 HR 系统对账、做生命周期联动都靠它。有几个性能细节也提一下。单次创建的并发不要拉得太高平台对速率有限制我一般控制在每秒 10 到 20 个以内量大就分批跑在循环里加个 sleep。另外这个接口不是天然幂等的重复创建会返回冲突所以脚本里要对“已存在用户”做好跳过或更新逻辑避免跑一半挂掉重新启动时大量报错。3.3 创建时的字段与密码策略字段不用全填但几个关键点要养成习惯。name 里的姓氏和名字分开填别图省事塞在一个字段里否则后续通讯录展示、排序、群组匹配都会乱。password 记得用系统生成的临时密码或者脚本随机生成的强密码别自己搞一套通用弱密码库。如果企业里已经有 SSO把密码策略和单点登录配合起来能不在网络上暴露密码就不暴露。recoveryInfo 也很重要。企业账号建议绑定企业邮箱或内部验证方式不要绑个人手机号避免员工离职后验证方式失控。我遇到过最麻烦的情况就是人走了半年辅助验证还绑在其个人手机上新接手的人想重置密码都卡在验证环节。再强调一次密码基线至少 16 位包含大小写、数字和特殊字符首次登录强制改密不允许密码与工号、生日相似。管理员的职责是提供安全基线而不是替用户记住密码。4. 批量角色分配实操三种成熟套路4.1 方式一CSV 批量导入与批量更新控制台提供“批量更新用户”功能本质上就是上传一个带固定头部的 CSV。角色分配的批量操作也走这条路先导出当前用户清单在 CSV 里补充或调整角色相关的列再上传回系统。具体步骤在用户管理页导出当前用户 CSV一般包含邮箱、姓名、组织单元等列。按模板追加角色或许可相关的列比如“分配的应用许可”“角色标识”。校验邮件地址列不要有前后空格编码存成 UTF-8。上传逐行检查处理报告。这里最容易出错的地方是列头。控制台对列名大小写敏感加列的顺序倒无所谓但列名必须和模板完全一致。我一般会先拿三五个测试用户跑一波确认处理报告里全是成功后再上全量。千万别拿全量数据直接冲失败行太多时定位原因能把人逼疯。4.2 方式二通过群组间接分配角色这是我最推荐的一种方式特别适合中大型企业先把角色分配给一个群组再把用户拉进群组用户就自动继承群组的角色从群组移出角色自动取消。好处非常明显。第一是动态维护新人入职只要把他加进“市场部”群组相关角色自动生效转岗时移出旧群组、加进新群组权限一次性切换。第二是支持嵌套部门群组套一层角色群组管理面收得很小不用逐个用户改。第三是审计清晰看群组成员列表就是看权限清单比翻几百条用户记录高效得多。代价就是群组管理必须有纪律。如果谁都可以随便建群、随便拉人这套机制很快会崩。我的做法是角色群组必须走“申请-审批”流程只有授权的维护者能管理普通用户只能申请加入不能自己拉人。关联到前面 3.2 的 API 创建流程创建用户时可以顺手指定 memberships 字段把用户拉进对应群组一步到位。这样“创建账号 分配角色”两个动作在脚本里一次性完成最省事。4.3 方式三用 API 直接改角色成员有些角色不是挂在群组上而是挂在项目或组织资源上比如某个云项目的 IAM 角色。这时候用脚本直接调角色管理接口最直接。以 IAM 角色为例给一批用户加角色本质上就是“读取现有策略、在 bindings 里追加 members、再写回”。示例请求体POST https://iam.googleapis.com/v1/projects/my-project:setIamPolicy Authorization: Bearer 访问令牌 Content-Type: application/json { policy: { bindings: [ { role: roles/editor, members: [ user:zhang.weiliexample.com, user:li.nanexample.com ] } ] } }特别注意setIamPolicy 是整包覆盖语义不是增量。我在生产环境里从来不会直接拿手写的 policy 去覆盖而是先 GET 当前 policy用代码追加 members 后再 POST 回去并且处理并发冲突。读取后如果策略被别人改了etag 对不上就重试。这一步写不好很容易把别人的权限覆盖掉属于生产事故级错误。批量分配时的节奏也要控制。一次把一个角色加给几百个用户策略体积会显著变大IAM policy 有大小上限成员太多要么拆多个角色要么用群组替代这里又是群组方案占优势。4.4 角色分配后的验证清单无论用哪种方式分配完不能直接宣布结束。我的验证清单大概是随机抽三五个用户登录后确认能看到对应入口或菜单而不是只看后台记录。确认许可状态是“已分配”而不是“待处理”或未分配。检查组织单元继承的策略是否正确尤其新建用户有没有落到根部门。对批量操作看处理报告里有没有“部分失败”失败原因如果是邮箱格式修正后重跑。若使用了群组继承确认用户确实出现在群组成员列表里且群组本身没有被误停用。这套验证看似繁琐但我可以负责任地说省掉它的代价远大于执行它的时间。我曾经因为没核对报告让 60 个失败账号沉默了三天直到用户报障才被发现。5. 常见问题与排查实录5.1 账号被提示“与多个其他账号一起创建或使用”这个提示几乎都出现在消费级个人账号上。触发原因一般是同一设备上短时间内注册了多个账号、注册信息如手机号或支付方式高度重合、或者通过脚本自动化注册。平台基于行为特征做了风控于是弹出“此账号似乎是与多个其他账号一起创建或使用的这违反了平台政策”之类的警告。在企业管理场景里正确的应对不是去申诉或者想各种绕过的办法而是从根上避免这类操作。企业大量使用个人账号批量注册本来就是错的做法正规路径就是回到第 2.3 节说的用企业身份目录创建账号管理员统一开通不需要个人手机号也不会触发消费级风控。如果你的业务流程已经出现这个提示说明要么在用个人账号承担企业职责要么在测试环境里反复注册一些不该注册的账号。这两种情况都建议马上叫停切换到企业目录方案。5.2 创建账号时手机号无法验证怎么办进一步说说手机号验证的问题。虽然企业目录内创建不需要手机号但很多人在小团队试水阶段还是习惯先用个人账号做验证然后就卡在“手机号无法验证”这一步。按我的排查经验十有八九是下面几种原因国家或地区区号选错或者手机号位数填错。短信通道被运营商拦截企业短信网关、物联网卡上尤其常见。同一号码在短时间内请求了太多次验证码被临时限流。该号码关联的历史账号太多平台风控不再允许它继续接收验证。号码本身是虚拟号段这类号码被识别后基本验证不过。排查顺序建议这样做先确认区号和号码格式换一个正常运营商的实体号码再试检查收件箱和垃圾短信箱确认验证码没有漏接把请求频次降下来隔一段时间再试仍然不行就走官方支持渠道申请人工审核。如果只是要开展小规模协作也可以直接评估申请企业身份目录的免费层级管理员直接开账号完全绕开个人手机号这条链路既快又省事。5.3 角色分配后不生效同步延迟还是配错了角色不生效我一般按这个顺序排查。先确认角色分配的目标对不对。是分配给了用户本人还是群组还是组织单元用户的实际权限等于直接分配加群组继承加组织单元继承三个来源任何一个漏了看起来都会是“没生效”。再查策略生效时间。大部分平台的 IAM 类和许可类变更在几秒到几分钟内传播偶尔遇到延迟到十分钟级别的情况先等别反复重做。反复重做只会制造更多矛盾记录让后续排查更乱。然后检查账号是否被停用或者是否存在多个同名账号。同名不同域是最隐蔽的坑你以为给 A 域用户加了角色用户登录用的却是 B 域的账号。最后去看管理员日志日志里的执行时间和执行结果能直接确认操作是真成功了还是只是在页面上看起来成功。5.4 常见问题速查表现象大概率原因快速解法账号被提示“多账号一起创建或使用”消费级账号批量注册触发风控改用企业目录账号体系管理员统一创建手机号无法验证区号或格式错误、短信被拦截、请求过频核对区号换实体号码降频走官方支持CSV 导入大量失败列头不一致、编码不对、邮箱重复下载官方模板UTF-8 编码邮箱去重用户创建成功但无许可创建时没分配许可或许可分配到别的部门批量更新用户补发许可角色分配后未生效同步延迟或分配目标错误等待查日志核对群组与组织单元继承密码重置后收不到通知通知邮箱设置错误或邮件延迟检查通知策略用备用管理员确认状态6. 安全与维护最佳实践6.1 最小权限与职责分离用 Maintain Business Users 管理的边界内还可以再细分创建账号的和分配角色的尽量不是同一个人至少大团队里要有审批环节。角色矩阵可以按这个思路设计操作责任角色说明创建、编辑用户一线管理员Maintain Business Users按入职通知执行分配、回收角色授权管理员或群组管理员必须有审批记录全局安全、计费配置保留给超管只在特殊流程下使用审计日志查看审计管理员与执行角色分离这套矩阵的价值在于任何一次账号变更都能回溯到具体操作人和审批记录不会出现“系统里多了个账号但没人认领”这种事。权限分离虽然增加了一点流程成本但比起出事后再追责的代价这点成本几乎可以忽略。6.2 审计与定期巡检不要等到出事才看日志。我建议至少每周做一次例行巡检拉取账号创建数、角色变更记录、异常登录尝试次数汇总成简单周报。有异常早暴露而不是等用户报障才被动发现。平台的管理操作日志要开启导出落到日志存档平台保留 180 天以上或按照企业合规要求执行。日志归档和查看的权限本身也要单独管理避免执行角色自己给自己清理痕迹。另有一个反直觉的点账号越多越要定期清理“幽灵账号”也就是离职未禁用的、长期不登录的、只有角色没有归属人的账号。很多权限事故根本不是外部攻击而是离职账号还留在角色里。我看过好几起真实案例最后追查下来都是清理不及时造成的。6.3 从入职到离职的完整闭环把前面的操作串成闭环整个体系才算真正成型。入职时HR 系统触发流程脚本调用 API 创建账号加入对应群组分配初始许可和角色再通知用户首次登录改密。转岗时移出旧群组、加入新群组调整组织单元和许可角色自动跟随群组变化。离职时先停用账号取消全部群组成员资格保留一段数据迁移期比如 30 天到期后再删除或转归档。需要说明的是这是基于常见实践补充的推荐节奏具体保留期要配合企业自己的数据合规要求。这个闭环里群组继承了大部分角色逻辑所以转岗和离职的“移出群组”动作会把权限收得很干净不用逐个角色去手动清理这正是批量管理最有价值的地方。写到最后还是想补一句这套流程里最让我受益的是我一直坚持“能通过群组继承的角色就不要直接挂在用户身上”。一开始图省事直接给用户绑了一堆角色半年后转岗一个同事收权限收了两个小时改成群组继承之后同样操作只要改群组成员一分钟搞定。另外还有一个小技巧创建账号的脚本里把 orgUnitPath 写在配置文件中不要写死在代码里。这样每次批量任务前只要改一个参数就不会发生“忘了改部门全建到根目录”的事故。希望这份从创建账号到批量角色分配的完整记录能帮你在企业用户管理这条路上少走几个来回。